New paradigms for a product oriented modelling: Case study for traceability

Salah Baına a,b,*, Herve Panetto b, Gerard Morel b

a ENSIAS (Ecole Nationale Superieure en Informatique et Analyse des Systemes), Universite Mohamed V – Souissi, Rabat, Moroccob CRAN (Research Centre for Automatic Control) UMR 7039, Nancy-University, CNRS, Faculte des Sciences et Techniques, BP 239, Vandoeuvre-les-Nancy 54506, France

Computers in Industry 60 (2009) 172–183

A R T I C L E I N F O

Article history:

Available online 20 January 2009

Keywords:

Product representation

Intelligent product

Product oriented approach

Manufacturing systems

A B S T R A C T

Nowadays, product information management is a key issue for traceability and quality management but

also for state-of-the-art technologies such as intelligent and autonomous product technologies. Due to

these needs, product information design and management are becoming one of the most important steps

in order to control quality of services and products that aim at customer satisfaction. However, there is

no real method that exists to build the exhaustive representation of product information throughout

their production cycle. In this paper, a product oriented modelling approach is proposed in order to

provide a complete method for product representation. This modelling approach aims at covering all

aspects related to product information and its management.

� 2009 Elsevier B.V. All rights reserved.

Contents lists available at ScienceDirect

Computers in Industry

journa l homepage: www.e lsev ier .com/ locate /compind

1. Introduction

For many, a product is simply the tangible, physical entity thatthey may be buying or selling. However, since the end of thenineties, the nature of products and even the nature of enterpriseshave changed due to radical changes in the environment. Indeed,the enterprise environment attended the creation of severalenterprise networks or extended enterprises, in particular net-works of suppliers and sub-contractors organized around custo-mers. Products developed by these networked enterprises are theresult of a set of geographically distributed and heterogeneousprocesses.

In marketing terms, a product consists of three separatedimensions, that, when combined, form the final product. In orderto actively explore the nature of a product further, those threedifferent views should be considered: the core product, the actual

product, and finally the augmented product, these are known as thethree levels of a product [1,2] (Table 1 gives examples of differentlevels of product.).

� T

d’

M

01

do

he core product is not the physical product; it represents thebenefit of the product that makes it valuable to customer.

� T he actual product is the tangible, physical product. � T he augmented or increased product is the non-physical part of

the product. It may contain information and detailed represen-tations of the actual product.

* Corresponding author at: Ecole Nationale Superieure d’Informatique et

Analyse des Systemes. Universite Mohammed V – Souissi. B.P. 713 agdal -Rabat.

orroco. Tel.: +212 19 33 25 94.

E-mail address: sbaina@ensias.ma (S. Baına).

66-3615/$ – see front matter � 2009 Elsevier B.V. All rights reserved.

i:10.1016/j.compind.2008.12.004

Regarding this classification and regarding the distributedarchitecture of production systems, product information manage-ment and product lifecycle management lie on heterogeneoussystems and multiple data storage systems with potentiallyconflicting formats. Moreover, the actual product, the augmented

product and the core product could be designed, manufactured andsold in different places.

Due to the geographical and institutional separation betweenthe different systems involved in the product lifecycle, it isdifficult to query, to exchange and to maintain consistency ofproduct information inside the extended enterprise. By analogywith the definition of ‘‘Interoperability’’ as the ability of two ormore systems to exchange information and have the meaning ofthat information accurately and automatically interpreted bythe receiving system [3,4], we introduce ‘‘product oriented

interoperability’’ as the ability of different enterprise systems tomanage, exchange and share product information in a completetransparency to the user and utilize essential human labour only(cf. Fig. 1).

In this paper, in order to consider information featuresembedded into the product, a product oriented modellingapproach is proposed. This approach enables a structured methodfor designing product information. The main objective is thesynchronisation of product material flows and product informa-tion flows in a given manufacturing environment in the modellingphase. Throughout its lifecycle, the product evolves in a dual way, aphysical product and a informational product that handles allinformation related to the lifecycle of the product. On one hand, thephysical product interacts with physical entities in the manufac-turing environment (processes, machines, transport equipments,etc.), on the other hand, the digital product interacts with the

Table 1Example of a product detailed according to its three dimensions.

Core product Actual product Augmented product

The benefits or solutions provided by the product: The physical product: The extended product–features and attributes (tangible and intangible):

A comfortable night’s sleep for two people A double bed Brand name: Comfy

Price: $2000

Quality: High

Size options: Single, Queen

Colour: Pink

Dimensions: 120 cm � 190 cm

Labelling: Australian made

Warranty: 2-years

Delivery: Free delivery

S. Baına et al. / Computers in Industry 60 (2009) 172–183 173

computational environment for production control, qualityassessment and traceability management.

The structure of the paper is detailed in the following. Section 2presents some concepts related to intelligent product andinformation management capabilities; this section aims atcomparing our conceptualisation of the product and somedefinitions of the intelligent product. In Section 3, we introduceconceptual foundations that are used in our formalisation of theproduct oriented modelling approach. Section 4 presents conceptsand meta-models of our product oriented modelling approach. InSection 5, a model-driven interoperability is proposed. Thisinteroperability is based on exchange of product oriented modelsinstantiated according to the proposed meta-models. Section 6shows a case study where our proposal has been used in order toachieve a product traceability management system in a flourproduction enterprise. Finally, a summary of the paper is given inSection 7.

2. Enterprise urbanization and product modelling

In the last few years, enterprise urbanization (or city planning)became one of the main criteria for good process management andthe race for performance. Enterprise city planning is a processreengineering task aiming at aligning business oriented views ofthe enterprise and IT oriented views. To achieve this objective,enterprise city planning is generally supported by cartographymethods and tools that enable the capture of the as-is organizationof processes inside the enterprise. This cartography is formalisedinto models. The second element necessary to enterprise cityplanning is the engineering and reengineering methods thatenable transforming the current state of business processes and

Fig. 1. A unified product view to federate enterprise information systems (APS: Advance

Enterprise Resource Planning system; MES: Manufacturing Execution System; SCE: Sup

manufacturing processes, into a best solution more adapted tostrategic goals of the enterprise.

The process city planning approach can also be applied forproduct information capture and rationalization. Indeed, theproblem of product information management and productmodelling in general is the alignment of business oriented conceptof the product (the core product) and its IT representation (the

augmented product).Organization city planning approaches are supported by a set

of models that are linked together into a model-driven archi-tecture. As an example, the following presents the Zachmanframework [39] which provides a highly structured way ofdefining and representing an enterprise. The Zachman framework(cf. Fig. 2) uses a two-dimensional classification model basedaround the six basic communication interrogatives (What, How,Where, Who, When, and Why) intersecting six distinct modeltypes which relate to stakeholder groups (Visionary, Owner,Designer, Builder, Implementer and Worker) to give a holisticview of the enterprise.

� W

d

p

hat: important data and objects of the enterprise.

� H ow: process and functions performed in the enterprise. � W ho: human actors in the enterprise. � W here: places, sites and locations where enterprise activity is

performed.

� W hy: motivations that lead business and manufacturing

behaviour.

� W hen: events that launch activities in the enterprise.

Often enterprise city planning approaches focus on processesand organizational units (see the Zachman framework). Product

Planning and Scheduling system; SCM: Supply Chain Management system; ERP:

ly Chain Execution).

Fig. 2. Grid representation of the Zachman framework.

S. Baına et al. / Computers in Industry 60 (2009) 172–183174

oriented models and product information modelling issues arefrequently somehow omitted.

The objective of our work is to propose a product orientedmodel-driven approach based on the Zachman framework. Ourproposal takes into account, not only product information modelsbut also models of manufacturing processes that interact with theproduct among its lifecycle [35,40]. The Zachman framework isconsidered as an important departure from traditional techniquesin such areas as software engineering, system engineering and dataengineering.

3. Improving product oriented models

During the last decade, the concept of ‘‘Intelligent Product’’ hasbeen widely used in manufacturing systems. This concept is oftenused to indicate a product equipped with a specific technologythat enables it to develop certain capacities. Indeed, according to[5] an intelligent product possesses all or some of the followingfeatures:

1. A

unique identity. 2. T he capacity of communication with its environment. 3. T he capacity to retain or store data about itself. 4. T he capacity of using a language to display its features,

requirements, etc.

5. T he capacity of participating in or making decisions relevant to

its own destiny.

Using these features, [5] categorises product intelligence intotwo levels:

Level 1: information oriented intelligence that enables theproduct to be conscious of its status, and to be able tocommunicate about it. This level of intelligence is ensured bythe first three features of the previous list.Level 2: In this case the product is able to influence and controloperations related to its manufacturing. This level of intelli-gence is said to be decision oriented. To achieve this level ofintelligence the product should ensure all features of the listbelow.

New technologies such as RFID, Auto-ID, UPNP enableidentification and information embedding on the product itself(see [6,7]). Moreover, technologies related to multi agent systemsmake it possible to involve the product in decision makingprotocols at the shop floor level. The product then becomes anactive entity in the decision making process, able to take control ofits own destiny (see [8–10]).

This paper focuses on information related to the product andthe design of this information. Products considered are assumed tobe Intelligent Level 1 (information oriented) [5]. Indeed, the mainconcern of our proposal is how to decide what kind of informationis needed for the product, what should be the knowledgeembedded on the product and what information should it retain?Since the product is assumed to be a physical-digital entityevolving in a pervasive computing system achieving manufactur-ing purposes, engineers need adapted tools and methods that helpthem managing this new artefact [11]. From the decisional andoperational points of view, the product is no longer viewed as astatic inactive entity in the shop floor. Moreover, the product, at afinal stage, exists only due to interactions between intermediary

S. Baına et al. / Computers in Industry 60 (2009) 172–183 175

products and computational or physical processes. The deploy-ment of intelligent products carrying information and commu-nication needs adapted modelling methods and approaches.Current modelling techniques consider either manufacturingspecifications of the product in process oriented models or productinformation features in computational models. The considerationof intelligent products that combine both information andcomputational features in addition to physical components ofthe manufactured product implies modelling approaches thatintegrate all aspects of the intelligent product.

In addition, each process and operation in the enterprise is able tostate information that can be useful for product related decisions;nevertheless, the holistic view of the product is missing. The holisticview of the product is the conceptualisation of what informationshould be carried out on the product, on RFID tags for example.Product specific views used locally for each process, operation orapplication can be conflicting, redundant and inconsistent; theconstitution of a holistic view of the product should improve productinformation management. The holistic view of the product is acomplete informational representation that takes into accountinformation relevant for all processes that are involved in theproduct lifecycle; those processes could be design, manufacturing,commercialising or even end life recycling processes. This holisticview of the product can then be seen as the representation of thisproduct as it is in the manufacturing environment. This representa-tion is the result of conceptual product information trackingthroughout processes at modelling phase.

In order to enable a synchronous modelling of the productmaterial flows and product information flows in a givenmanufacturing environment, different aspects of the productshould be considered: the physical product that is subject ofphysical processes in a manufacturing environment, and the digitalor informational product that is aware of all information related toits lifecycle. The design of such a product should take into accountall aspects related to specifications of the physical product, those ofthe informational product, and interactions of both facets of theproduct with their direct environments. This design should bebased on a product oriented approach that handles the differentaspects of the product.

Fig. 3. Relation between the concept, the rea

4. Holons and BWW ontology for product representation

The word Holon is a combination of the Greek word holos,meaning whole, and the suffix on meaning particle or part. A holonis an identifiable part of a system that has a unique identity, yet ismade up of subordinate parts and, in turn, is part of a larger whole.As such, a holon is recursive. It has two main features: autonomyand cooperation. In the manufacturing context, a HolonicManufacturing System (HMS, [12]) is seen as an autonomousand co-operative building block of a system for transforming,transporting, storing and/or validating information and physicalobjects [13]. In this context, several adaptations of the holonconcept for the product have been proposed in literatures [14–16].For our purpose, and in order to design a unique representation ofthe product, there are some critical features that are mandatory inthe holonic representation of a product.

To conceive our dual view of the product (information andmaterial), we propose an adaptation of the holon concept. In ourproposal, a holon is considered as the aggregation that combinesboth the material part of a given product and the set ofinformation related to the product (cf. Fig. 3). In fact, our holonbased modelling aims at achieving a complete representation ofthe product, defined by a set of properties and their values. Thisrepresentation can be reused for different concerns and indifferent applications.

In Fig. 3, we illustrate the three dimensions of the product thatshould be considered in our modelling approach. This classificationis an analogy of the three levels of product that have beenidentified by Kotler [1]:

� T

lit

he concept of the product: what one should expect of a givenproduct and how one can imagine its utility.

� T he tangible product: the physical object considered as product. � T he representation of the product: the informational part

associated to the product.

In our approach, the holon construct is used to represent theconcept of the product (the core product) wherever a productillustration is needed.

y and the representation of a product.

S. Baına et al. / Computers in Industry 60 (2009) 172–183176

To formalise our perception of the product using the holonconcept, we adapt some constructs from the well known BWWontology to our specific purpose. Our analysis is based on theontology initially introduced by Bunge [17,18] and adapted byWand and Weber for the information systems field [19,20]. TheBWW ontology has its roots in the fundamental problems ofconceptual modelling. Wand and Weber recognized that thequality of conceptual models is always dependent on thecorrespondence between the model and what the model is about.They assumed that this correspondence will be greatly supportedby using a conceptual modelling language that provides theconstructs that are (nearly) the same as the concepts people use tostructure their conceptions of the world [20]. To improve the BWWmodel clarity, Rosemann and Green developed a meta-model of theBWW-model [21]. For the sake of comprehensiveness, thefollowing introduces some of the main constructs of BWW [22]:

� T

hing: ‘‘The world is made of things that have properties’’. � C omposite thing: ‘‘A composite thing may be made up of other

things (composite or primitive)’’.

� C onceivable state: ‘‘The set of all states that the thing may ever

assume’’.

� T ransformation of a thing: ‘‘A mapping from a domain

comprising states to a co-domain comprising states’’.

� S table state of a thing: ‘‘A state in which a thing, subsystem or

system will remain unless forced to change by virtue of theaction of a thing in the environment (an external event)’’.

� P roperty: ‘‘We know about things in the world via their

properties’’.

In the following section, we present some of the importantfeatures for product representation; some of them have beeninspired directly from the BWW ontology.

5. A generic product representation

In order to propose a method for product information design, ameta-model for a generic and unified product representation hasto be proposed. This meta-model should group all mandatoryfeatures that are connected to the product, its composition and itsdescription. The following introduces those important features.

5.1. Product structure

In our context, manufacturing products are represented byholon constructs. Each holon represents what BWW calls a thing.

Holons are made by successive composition or transformation ofraw or intermediary materials. We call product structure, orproduct composition, the tree structure whose nodes representraw or intermediary materials used to make the product located atthe root. Arcs of this tree structure represent a compositionrelationship between different nodes. To take in account thisnotion of structure, our holon adaptation should consider the linkof composition between objects.

Holons can be classified into two categories: (i) simple holonsand (ii) complex holons. On one hand, simple holons (elementary

holons) are the combination of a single informational part and asingle physical part. On the other hand, complex holons (compositeholons) are the result of the processing and treatment of one ormore other holons, this processing can be a transformation of one

holon to obtain a new one, or integrating a set of holons in order tocompose a new one. Each composite holon can be defined as theoutput of the execution of a manufacturing process on one or moreless complex holons. If a holon is composed only of one uniqueholon, then the composition should be seen as a transformationprocess.

5.2. Product features

The informational part of the holon should describe the set offeatures of a specific product, these features can be distinguishedinto two categories:

� C

haracteristics describing intrinsic properties of the physicalproduct. These properties are substantial to the physical part ofthe product (example: weight, height, and material). � C haracteristics describing information that is assigned to the

product throughout the design phases; each piece of informationis of a specific domain and a specific use (e.g. identifier,production date, etc.)

To distinguish both concepts, we call ‘‘attributes’’ character-istics of the first category, and we call ‘‘properties’’ characteristicscorresponding to the second category.

5.3. Product states

During manufacturing phases, a product passes throughoutseveral states that describe its history. The management of the setof states of a specific product and relationships between themenable product traceability and genealogy management [23]. Thestate of a holon is then defined using tuples (attribute, value andpropriety, value). Each operation processed on a holon implies astate change.

All those constructs have been formalised in a meta-modeldescribing elements that are involved in the definition of a holonrepresenting a physical-digital product [24] (cf. Fig. 4). Thismeta-model has been expressed in the UML class diagramformalism [25].In order to preserve the semantic consistency ofmodels resulting from the instantiation of the holon meta-model (Fig. 4), we propose a set of semantic constraints thatensure coherence and validity of models. These constraintshave been formalised in the OCL formalism which is thelanguage that expresses semantic rules and constraints to berespected by UML classes. OCL is based on object oriented firstorder logic compatible with UML [26]. The following shows twoexamples of constraints that have been defined for the holonicmodelling.

5.4. Constraint 1

The first constraint expresses the fact that only composedholons exist without a physical part that belongs directly to them: «A holon entity that is not linked to a physical part is necessarily acomposed holon».

In OCL this constraint is expressed as the following:

5.5. Constraint 2

The second constraint expresses that each elementary holonhas necessarily a physical part and an informational part. This

Fig. 4. Holon meta-model expressed in UML formalism.

S. Baına et al. / Computers in Industry 60 (2009) 172–183 177

constraint ensures that the decomposition of holons endscorrectly, and that leafs of the composition tree structure of agiven holon are elementary holons.

The next section focuses the use of holon based product modelsas product oriented knowledge bases gathering all productinformation. Indeed, enterprise systems such as ERP, CRM1 andMES for example store product information for internal use intheir specific data warehouses or databases. Most of the time, theyalso need to share information [27–30]. Instantiated models canbe used as reference models for product oriented interoperability.Indeed, they capitalise on information that is to be sharedbetween all different information systems involved in theenterprise.

6. A model-driven approach for product orientedinteroperability

In order to establish product oriented interoperability betweendifferent enterprise systems, we propose a model-driven approachbased on model transformations [31]. This approach is based on aunified reference model that represents the product.

1 CRM: Customer Relationships Management.

The principle of reference model approach for interoperabilityis the following [32]: there can be as many local specific models asneeded (e.g. one for each system), local models remain as they are,

and only transformation rules are defined in order to enableinformation synchronisation between local models and thereference model [33]. The consideration of a new application thatneeds to interoperate and to exchange product information withother applications is transparent to existing applications. Adding anew specific local model implies no changes for existing models,but only definition of new transformation rules between the newlocal model and the reference model. Those transformation rulesdescribe relationships between concepts and entities of the localmodels (source) and reference model (target) [33,34]. These rulesare defined at meta-model level in order to enable transformationsat model level.

On the basis of the conceptual model of each system,transformation rules can be defined between the holon basedrepresentation of the product in one hand, and each one of theapplication’s conceptual levels on the other hand. Establishingtransformation rules between those models enables exchangingproduct information between different enterprise applications andsystems. This information exchange capacity is what we callproduct oriented interoperability [31]. This interoperability aims

S. Baına et al. / Computers in Industry 60 (2009) 172–183178

at enabling different systems for managing, exchanging andsharing product information in a complete transparency to theuser and utilizing only essential human labour [3].

Our approach for product oriented interoperability is a model-driven approach based on a unified product representation(reference model), and a set of semantic transformation rules. Thisinteroperability enables product information mappings betweenthe different applications using a holonic model as a gateway.

This unified representation is then translated for specific useand specific applications. The need of transformations is due to thedifference of concerns of enterprise applications and systems.Indeed, while manufacturing oriented enterprise systems areinterested in physical features of products, business orientedsystems are more interested in a service oriented representation ofthe product more related to informational aspects of products [35].

While well known model-driven architecture (MDA) [36,37] andmodel-driven engineering (MDE)[35,38] propose frameworks basedon OMG specifications, highlighting different abstraction levels of agiven system from an application development point of view, wecontribute to this domain by proposing a framework that combinesvarious points of view of a given system linking manufacturing viewsof a system at the ‘‘business to manufacturing’’ level.

Our approach provides a method for product informationdesign and collection, starting from the conceptual model of theproduct and the manufacturing processes that interact with it,until the definition of product information data models that can beused for product information management (product qualitycontrol, traceability or genealogy).

In this context, we define a product oriented process model as aconceptual model that aims on one hand at defining relations andexchanges and interactions between processes of a manufactur-

Fig. 5. Part of the product oriented

ing environment; on the other hand it aims at specifyinginformation related to a product during its lifecycle and itsevolution through the set of processes involved in its manufactur-ing. Regarding this, a product oriented process model combinesconstructs defined in the holonic meta-model for productrepresentation and constructs defined in standard processdiagrams such as processes, activities, flows and messages.Fig. 5 shows a subpart of the meta-model describing constructsinvolved in our product oriented process modelling approach.Inaddition to the use of holons for product representation, thismeta-model emphasizes also interactions between holons andprocesses. Those models show relevancy of product informationfor processes by linking each process to pieces of information thatit uses or produces. According to the Zachman framework, thiskind of models covers both the ‘‘What’’ and the ‘‘How’’ columns ofthe conceptual level of the Zachman grid, since it describesinformation schema related to products and in the same timeorganization of processes and exchanges between them. Themodel-driven approach led by the Zachman framework gives anexact idea about kinds of models and information that needs to beprovided at a conceptual level in order to maintain coherencebetween different representations in different enterprise sys-tems. At the logical level of the ‘‘What’’ column, automaticallygenerated UML class diagrams can be used to express informa-tional models related to the product.

7. Holons into the Zachman framework

To summarize the approach used in the case study developed inthis section, we propose a reference method based on the Zachmanframework. The Zachman framework has been used as a strategy

process modelling meta-model.

Fig. 6. Used strategy and mapping with the Zachman framework.

S. Baına et al. / Computers in Industry 60 (2009) 172–183 179

support in order to achieve the product traceability system. Indeed,the Zachman framework in its initial definition does not advocateany specific diagram or modelling tool, we tried to place each oneof the models and modelling approaches that have been usedduring our case study in the more adequate Zachman cell where itfits. The use of the Zachman framework ensures a pragmaticapplication of the MDA. Indeed, Zachman’s contextual andconceptual levels represent computational-independent models(CIM) level in MDA. The platform-independent models (PIM) levelof the MDA is represented by the logical level in Zachman. Theplatform specific models (PSM) level is represented by the physical

technology models and the out-of-context detailed representations.By definition of the Zachman framework, the product of a given

enterprise belongs to the scope of the ‘‘What’’ column thatdescribes objects that are important from the enterprise point ofview. Enterprise applications and enterprise systems handleinformation about the product; each one of those systems has aspecific representation of the product. Using retro-engineeringtechniques, a precise logical representation of the product viewhandled by each system can be produced. However, a genericrepresentation of the product is needed at the conceptualenterprise model level to unify all logical views of the productand to enable then a unified product modelling approach.

The first activity concerns the interviewing of enterpriseemployees in order to collect information that should help theachievement of our product traceability system. This taskdetermines objects and processes that are in the scope of oursystem. It corresponds to the ‘‘contextual level’’. After completinginterviews, conceptual product oriented models based on our

holonic modelling approach have been designed. These models fitin the conceptual level of the Zachman framework, they cover theWhat and the How columns of the Zachman grid. Using generationrules implemented in MEGA, product oriented models are derivedinto logical models formalised in UML (Zachman Logical level)representing product data models. In order to implement theproduct traceability database, the logical models are thentransformed into a relational schema corresponding the structureof the relational database to be produced. The use of SQL [41]facilities in MEGA enables an automatic generation of script codeneeded to create the product traceability database.

Fig. 6 synthesizes the correspondence between the Zachmanframework (as a support) and the model-driven approach that wepropose to achieve traceability systems.

8. Case study

The proposed case study is the result of a collaboration projectwith a flour milling enterprise. The company transforms wheatinto flour and packs flour into bags of 25 or 50 kg. To meet qualityand traceability requirements, the company has decided toimprove product information tracking at shop floor level. Fromthis statement, collaboration has been started in order to modelthe actual flour milling system in a one of the 10 mills of thecompany. The purpose of this modelling is to specify informationrelated to each important enterprise object that is involved inproducts release (resources, customers, raw material, etc.). Theseentities are starting blocks for product traceability systemimplementation.

Fig. 7. Start point of products tracking.

Fig. 8. Example of conceptual map for the product oriented approach.

S. Baına et al. / Computers in Industry 60 (2009) 172–183180

Interviews with employees of the company have beenperformed in order to identify precisely the parts of operationalsystem that should be covered by our modelling approach. Theseinterviews have permitted identification of processes, actors,exchanges and events involved in flour manufacturing andbagging. In order to take into account not only physical objecttraffic but also informational parts related to these objects(products, documents, orders), we decided to apply our productoriented process modelling approach based on holon concepts andfeatures. An implementation of our meta-model has beenproposed under the MEGA2 case tool which is a commercialmodelling environment that offers several tools for enterpriseapplication design and development. Constructs related to holonsand flows have integrated in the meta-model of MEGA in order toinstantiate them in MEGA diagrams. In this case study, holonsrepresent objects (products and documents) between exchangedprocesses throughout all phases of the flour milling activity. Thoseobjects are described using attributes and properties that defineexplicitly pieces of relevant information. To take into accounttraceability issues, both dependency between objects and struc-tural composition of objects have to be modelled as well. Linksbetween objects enable tracking the set of elements related to agiven product, a given delivery or a given customer order. Ourapproach starts from the first interaction with the customer; thisinteraction is launched by the arrival of a ‘‘product order’’ sent bythe customer to customer relationship management. From thisevent, the tracking of all exchanges, activities and processesresulting from the interaction with the customer are modelledusing our product oriented approach in order to map processes,equipment and humans that act during product manufacturingcycle. This first model obtained is a very generic one representing aglobal view of the production system.

2 MEGA Suite, MEGA International, http://www.mega.com.

Fig. 7 presents the contextual part of our analysis, describingvery abstract view of what our use case is about. From that model,we start investigating in order to define all flows and processes thatinteract with different phases of preparation, planning, andexecution of production. The aim is to map enterprise activitiesand processes that are involved in product release. During thismodelling phase, we apply our product oriented approach byfocusing mainly on objects and their features (attributes orproperties).

Fig. 8 shows the result of the process cartography phase. Theoutput model describes shop floor processes and flows exchangedbetween those processes. Each flow is decomposed in terms ofholon instances carried out from one process to another. In thiscase study, customer orders are grouped by type of flour to beproduced, production bags of each category of flour are organizedinto ‘‘Bagging tasks’’. Each task is decomposed into ‘‘Missions’’, eachmission is executed by a set of ‘‘Executed tasks’’ (or subtasks). Eachsubtask corresponds to a specific ‘‘Production Order’’ called PO

Bagging. The result of the execution of those Production orders is aset of flour palettes. Each palette corresponds to a certain categoryof flour and is described by a set of information.

An automated tool extracts data from conceptual level modelsand generates a UML diagram describing ‘‘Logical Models’’ thatrepresents entities (products, documents, and important objectsfor the enterprise) and relationships between them (cf. Fig. 9). Theresulting class diagram has been used as relational schema for atraceability management system.

The proposed method is based on production process urbaniza-tion and cartography. The advantage of this method in comparisonto the other approaches is the association between processes andinformation, this association ensures information use traceability.Indeed, contrary to already existing traceability databases in thehost enterprise, the proposal presented in this section has beenobtained by a methodological approach based on a product

Fig. 9. Automatically generated class diagram.

3 www.capgemini.com/.

S. Baına et al. / Computers in Industry 60 (2009) 172–183 181

oriented modelling of activities of the enterprise. Due to ourapproach, a diagnosis phase has been achieved using the obtaineddatabase and data collected on the shop floor. This diagnosis hasconcluded that improvement of data collection is needed. Indeed,some pieces of information are not well filled, which impliesimportant loss of information and loss of connections betweenelements. Improvements proposed enable a consistent and reliabletraceability management.

9. Discussion and conclusion

According to a recent study by Capgemini,3 more than 50% of theitems in company systems contain incorrect data. This analysisfound that half of consumer units were incorrect and one-third oftraded units were inaccurate. It also reported that nearly 75% of

S. Baına et al. / Computers in Industry 60 (2009) 172–183182

suppliers of consumer units had incorrect items, and 57% ofsuppliers of traded units had errors. The report further stated: ‘‘Theuse of new enabling technology such as EPC-enabled RFID tags,which will provide previously unimagined visibility across thesupply chain, simply will not bring their promised benefits unlessthey are built upon a foundation of quality information.’’

The issue of product information management is one of themost recurrent problems faced inside manufacturing enterprises.Indeed, in actual companies, product information is usually storedin various enterprise applications throughout different geogra-phies, operating units and departments ranging from manufactur-ing to marketing and customer service. Information may vary fromlocation to location, creating discrepancies that must be resolvedto enable smooth business-to-business electronic commerce. Theissue of product information management is tightly linked toproduct traceability, product lifecycle management, productoriented interoperability, etc. More than a specific model forrepresenting the product, what is needed is a global approachbased on a bird eye view of the enterprise that proposes a completemethod for building product models (business oriented models,manufacturing oriented models, computational models). A solu-tion to this problem should solve the problem by gatheringinformation from all locations, integrating it into a consistentformat, and storing it in a centralized internal repository that isupdated as information changes. Such a solution should alsoensure that all product information is kept consistent across allinformation channels while also offering the important benefit ofretaining departmental autonomy. The main objectives of productinformation management are to:

� E

nable the utilization of product information to the right user atthe right time across the enterprise. � R emove duplicate product information throughout the organi-

zation.

� P rovide business process discipline and relevant structure to

product information within a company and across their valuechain.

� M anage the product centric information and relationships of

customers, suppliers and the enterprise.

In this paper, a product information management approach hasbeen proposed, in order to provide a structured strategy to build acomplete and consistent representation of product information.Product representation resulting of our method can be used as arepository for product information management (traceabilitymanagement, product information design, and product informa-tion storage). The product oriented modelling approach has beeninspired from the use of holon construct in product modelling. Ouradaptation of the holon concept defines it as an aggregation of atangible physical part of a given product, and the informationalpart that corresponds.

To validate our approach, an implementation and a case studyapplication has been proposed.

Our approach has been implemented in the MEGA suitemodelling environment to enable instantiation of product drivenmodels. Moreover, to provide a fully model-driven approach, wepropose using the Zachman framework in order to guide userprogression and the use of adequate models.

Thecasestudy has beenperformedincollaborationwitha leadingFrench enterprise in flour milling. The objective of the collaborativeproject was the application of our product oriented modellingapproach to achieve a unified product representation and toimplement it using a database that stores product data. The resultingdatabase is used as a source for product traceability management.

The tool proposed enables product oriented modelling thatcovers both process requirements, and product data representa-

tion. The combination of both issues enables a unified representa-tion of products and important objects for business processmanagement by taking into account information that are used andproduced at each point of the process execution.

References

[1] P. Kotler, Marketing Management: Analysis, Planning, Implementation andControl, Prentice-Hall International, Englewood Cliffs, 1988.

[2] M. Khosrowpour, Managing information technology resources in organizations inthe next millennium, in: Information Resources Management Association Inter-national Conference, Hershey, PA, USA, 1999.

[3] P. Wegner, Interoperability, ACM Computing Survey 28 (1) (1996) 285–287.[4] H. Panetto, Towards a classification framework for interoperability of enterprise

applications, International Journal of CIM 20 (December (8)) (2007) 727–740(Taylor & Francis, ISSN: 0951-192X).

[5] C.Y. Wong, D. McFarlane, A. Ahmad Zaharudin, V. Agarwal, The intelligent productdriven supply chain, 2002 IEEE International Conference on Systems, Man andCybernetics 4 (6–9) (2002), 6 pp.

[6] D. McFarlane, Auto-ID Based Control—An Overview, Auto-ID Center, University ofCambridge, 2002.

[7] D. McFarlane, S. Sarma, J.L. Chirn, C.Y. Wong, K. Ashton, The Intelligent Product inManufacturing Control and Management, in: 15th Triennial World Congress,Barcelona, Spain, 2002.

[8] M. Caridi, S. Cavalieri, Multi-agent systems in production planning and control: anoverview, Production Planning and Control 15 (2) (2004) 106–118.

[9] A.C. Montalvo, A.G. Higuera, RFID enhanced multi-agent based control for amachining cell, in: Proceedings of Stimulating Manufacturing Excellence in Smalland Medium Enterprises 2005 (SMESME’05), 2005.

[10] S. Bussman, N.R. Jenning, M. Wooldridge, Multiagent System for ManufacturingControl. A Design Methodology, Springer Series on Agent Technology, 2004.

[11] F. Siegemund, C. Florkemeier, Interaction in pervasive computing settings usingbluetooth-enabled active tags and passive RFID technology together with mobilephones, in: IEEE PerCom 2003, IEEE Computer Society, 2003.

[12] HMS, HMS Requirements, in http://hms.ifw.uni-hannover.de/, HMS Server, 1994.[13] D. Seidel, M. Mey, IMS—Holonic Manufacturing Systems: Glossary of Terms, in: D.

Seidel, M. Mey (Eds.), IMS—Holonic Manufacturing Systems: Strategies, Univer-sity of Hannover, Germany, 1994.

[14] E. Bajic, F. Chaxel, Towards a holon-product oriented management, in: The 4th IFACWorkshop on Intelligent Manufacturing Systems (IMS’97), Seoul, Korea, 1997.

[15] H. Van Brussel, et al., Reference architecture for Holonic Manufacturing Systems:Prosa, Computers in Industry 37 (3) (1998) 255–274.

[16] P. Valckenaers, Special issue on Holonic Manufacturing Systems, Computers inIndustry 46 (October (3)) (2001).

[17] M. Bunge, Treatise on Basic Philosophy, Ontology I: The Furniture of the World,Reidel, Boston, 1977.

[18] M. Bunge, Treatise on Basic Philosophy, Ontology II: A World of Systems, Reidel,Boston, 1979.

[19] Y. Wand, R. Weber, On the ontological expressiveness of information systemsanalysis and design grammar, Information Systems Journal 3 (1993) 217–237.

[20] Y. Wand, R. Weber, On the deep structure of information systems, InformationSystems Journal 5 (1995) 203–223.

[21] M. Rosemann, P. Green, Developing a meta model for the Bunge–Wand–Weberontological constructs, Information Systems Journal 27 (2) (2002) 75–91.

[22] P. Fettke, P. Loos, Ontological evaluation of the specification framework proposedby the ‘‘Standardized Specification of Business Components’’ memorandum -some preliminary results, in: S. Overhage, K. Turowski (Hsrg.), 1st InternationalWorkshop on Component Engineering Methodology, Erfurt, Germany, 2003.

[23] S. Terzi, Elements of product lifecycle management: definitions, open issues andreference models, These de doctorat de l’Universite Henri Poincare Nancy I encotutelle avec le Politecnico di Milano (en Italie), 27 mai 2005.

[24] S. Baına, H. Panetto, G. Morel, A towards a product oriented process modelling forenterprise applications synchronisation and interoperability, in: IFAC/IFIP I-ESA’06, 2nd Interoperability for Enterprise Software and Applications Conference,March, Bordeaux, France, 2006.

[25] UML, The Unified Modelling Language specifications 1.5, OMG, 2003.[26] J. Warmer, A. Kleppe, The Object Constraint Language: Precise Modeling with

UML, Addison-Wesley, 1999 ISBN 0-201-37940-6.[27] B. Selk, S. Kloeckner, A. Albani, Enabling interoperability of networked enterprises

through an integrative information system architecture for CRM and SCM, in: The3rd Business Process Modelling Conference, Nancy, France, September 5–8, 2005.

[28] A. Tursi, H. Panetto, G. Morel, M. Dassisti, Ontology-based products informationinteroperability in networked manufacturing enterprises, in: IFAC Cost EffectiveAutomation in Networked Product Development and Manufacturing, Monterrey,Mexico, October 2–5, 2007.

[29] H. Panetto, A. Molina, Enterprise integration and interoperability in manufactur-ing systems: trends and issues. In: A. Molina, H. Panetto (Eds.), Special Issue onEnterprise Integration and Interoperability in Manufacturing Systems, Computersin Industry, vol. 59, no. 6, Elsevier, June 2008, ISSN: 0166-3615.

[30] D.S. Linthicum, Enterprise Application Integration, Addison Wesley, 1999 ISBN0201615835.

[31] S. Baina, H. Panetto, K. Benali, Product oriented modelling and interoperabilityissues, in: Y. Manolopoulos, J. Filipe, P. Constantopoulos, J. Cordeiro (Eds.),Enterprise Information Systems VIII, 8th International Conference, ICEIS 2006,

S. Baına et al. / Computers in Industry 60 (2009) 172–183 183

Paphos, Cyprus, May 23–27, 2006, Revised Selected Papers, Lecture Notes inBusiness Information Processing, vol. 3, Springer, Berlin, 2008, , pp. 293–308,ISBN: 978-3-540-77580-5.

[32] F.B. Vernadat, Enterprise Modelling and Integration: Principles and Applications,Chapman & Hall, 1996 ISBN: 978-0-412-60550-5.

[33] R. Lemesle, Transformation rules based on meta-modelling, in: EDOC’98, La Jolla,California, November 3–5, (1998), pp. 113–122.

[34] M. Blaha, W. Premerlani, A catalog of object model transformations, in: 3rdWorking Conference on Reverse Engineering, Monterey, California, November8–10, 1996.

[35] S. Baına, H. Panetto, G. Morel, A holonic approach for application interoperabilityin manufacturing systems environment, in: The 16th IFAC World Congress,Prague, CZ, July 4–8, 2005.

[36] S.J. Mellor, S. Kendall, A. Uhl, D. Weise, Model Driven Architecture, Addison-Wesley Pub Co., 2004 ISBN 0201788918.

[37] OMG/MDA, http://www.omg.org/mda.[38] S. Kent, Model driven engineering, in: IFM 2002 Third International Conference

on Integrated Formal Methods, Springer-Verlag, Turku, Finland, 2002, , LNCS2335.

[39] J.A. Zachman, A framework for information systems architecture, IBM SystemsJournal 26 (3) (1987) 276–292.

[40] H. Panetto, S. Baına, G. Morel, Mapping the IEC 62264 models onto the Zachmanframework for analysing products information traceability: a case study Journalof Intelligent Manufacturing, Springer Verlag, 2006 ISSN: 0956-5515.

[41] J.R. Groff, P.N. Weinberg, The Complete Reference SQL, Osborne/McGraw-Hill;Bk&CD Rom edition (March 1, 1999).

Dr. Salah Baina is Professor at ENSIAS Engineer School of

Computer Science and System Analysis in Rabat,

Morocco. He received his PhD on computer science

and production engineering in 2006 at Nancy-University.

The subject of his PhD thesis was ‘‘MODEL DRIVEN

NTEROPERABILITY: A Product Oriented Approach for

Enterprise Systems Interoperability’’. He also obtained in

2003 an Engineering degree in Computer Science and

Applied Mathematics at ENSIMAG, Grenoble France. He

is skilled in information systems interoperability and

modelling. His research interests are Information

Systems Interoperability, Business/IT Alignment and

Business Process Modelling and refactoring. He

participated in the FP6 INTEROP NoE (Interoperability Research for Networked

Enterprises Applications and Software).

Dr. Herve Panetto is Professor at Nancy-University

where he teaches Information Systems at ESIAL

Engineering school and conducts research at CRAN

(Research Centre for Automatic Control), laboratory

associated with CNRS. He received his PhD on produc-

tion engineering in 1991 and he has been accredited for

directing research (Habilitation a Diriger des

Recherches) in 2006. He has strong experience in

information systems modelling and database develop-

ment. His research field is based on information

systems modelling for enterprise applications and

processes interoperability, with applications in enter-

prise modelling, manufacturing processes modelling,

furniture data modelling. He is working in ERP and MES integration from a business

to manufacturing perspective. He is an expert-evaluator for the European

Commission in the domain of ICT. He is editor or guest editor of books and special

issues of international journals. He is author or co-author of more than 70 papers in

the field of Automation Engineering, Enterprise Modelling and Enterprise systems

integration and interoperability. He is currently Chair of the IFAC Technical

Committee 5.3 ‘‘Enterprise Integration and Networking’’.

Dr. Gerard Morel is Professor at Nancy University and

co-director of CRAN, the Research Centre for Automatic

Control of Nancy, which is an associate unit of the CNRS

(National Centre for Scientific Research). He directed

about 30 PhD Thesis and Accreditations to Supervise

Research. He published over 150 articles in the area of

‘Systems and Automation Engineering’. He held

research positions in national and international net-

works of research and served in several positions in

IFAC and with the European Commission. He is

currently Europe Editor of the International Journal of

Intelligent Manufacturing and Associate Editor of the

IFAC International Journal of Real-Time Automation on

Engineering Applications of Artificial Intelligence as well as evaluator for the French

Agency for the Evaluation of Research and Higher Education. He is also Director of a

master degree on ‘Systems Engineering’ as well as member of the French chapter of

the International Council on Systems Engineering.