SW1 part page - Wiley...Architecture extended from Model Driven Architecture developed by OMG and Model Driven Interoperability approach developed in INTEROP Network of Excellence[3]

Workshop 1

Model Driven Services Engineering Architecture(MDSEA): A Result of MSEE Project

COPYRIG

HTED M

ATERIAL

An Architecture for Service Modelling inServitization Context: MDSEA1

Yves Ducq

IMS, UMR 5218, University of Bordeaux351 Cours de la libération, 33405 Talence Cedex, [email protected]

ABSTRACT: Currently, manufacturing enterprises are progressively migrating from traditionalproduct-centric business to product-based service-oriented virtual enterprise. This paperaims at presenting the service modelling architecture that is proposed in the frame of a FP7project: MSEE. The proposed Model Driven Service Engineering (MDSE) architecture isadapted from MDA developed by OMG and from MDI model developed in INTEROPNetwork of Excellence. This architecture defines the various modelling levels and the relatedconstructs to model based on servitization principles. The proposed modelling languages torepresent these constructs at each level of MDSE will be presented at the same time.Templates to describe each concept will be also illustrated in example. Conclusions andperspectives are given in the end of the paper.

KEYWORDS: service system modelling, enterprise modelling, MDI/MDA approaches

1. This paper is elaborated on the basis of MSEE deliverable D12.1: Service concepts, modelsand method: Model Driven Service Engineering – second version, WP1.1, MSEE consortium,2013.

4 Enterprise Interoperability

1. Introduction

In the economic context moving continuously, manufacturing enterprise,including SME’s, are progressively migrating from traditional product-centricbusiness to product-based service-oriented virtual enterprise and ecosystems [1]. Inthis sense, traditional companies have to cooperate in one or several virtualenterprises, considered as service systems dedicated to support the service design,development, and implementation. In order to facilitate this migration process,service system that will provide desired services around the product will have to bemodelled, designed, implemented, tested and managed along its entire lifecycle inorder to ensure the correct migration of the company.

This paper presents a second version of a model driven architecture withassociated modelling formalisms which are the results of a research work performedin the frame of the FP7 MSEE Integrated Project [2]. Particularly, the goal of thiswork is to develop service system modelling language to support service systemengineering and implementation. The approach adopted is to use EnterpriseModelling techniques as a basis under the Model Driven Service EngineeringArchitecture extended from Model Driven Architecture developed by OMG andModel Driven Interoperability approach developed in INTEROP Network ofExcellence [3].

So, in a first part, the servitization process and the definition of what a servicesystem is will be developed as well principles of system modelling. Then, the ModelDriven Service Engineering Architecture will be presented insisting on its interestfor the implementation of a coherent and complete virtual enterprise based onbusiness models and on the description of each modelling level. The various levelsof the architecture will be detailed as well as the required constructs to represent ateach level based on the previous servitization principles. Then, enterprise modellinglanguages will be proposed to represent the constructs at each level. Finally, theperspectives of this work will be proposed.

2. Servitization and virtual organization as a service system

The studies and researches in the domain of Service have been mostly devoted tosupport tertiary sector domains (e.g. banking & finance, tourism, trade, publicadministration), with an obvious focus on ICT. At the end of the nineties, theconcept of Service in Manufacturing appeared and the evolution from an economyof products towards an economy of services round the products becomes more andmore important in manufacturing: this evolution is called Product Service System(PSS) or Servitization.

Model Driven Services Engineering Architecture 5

According to Wikipedia “a service is to make available a technical or intellectualcapacity” or “to supply a work which will be useful for the user without materialtransformation”.

Most of the time a service is opposed to a good. The following list characterizesa service [4]:

- A service is not owned, but there is a restricted access.

- Services have intangible results.

- Customers are involved in the service production process.

- Other persons than the customers can be involved in the service process asstakeholders, sub-contractors, etc.

- Quality in service is difficult to control while increasing productivity and alsodifficult to apprehend

- Service cannot be stored.

- Service delivery delay is crucial.

- Service delivery integrates physical and electronic way.

Since a decade, new research thinking has been emerging, trying to systematizethe multi-disciplinary knowledge involved in service systems. On their web page,IBM describes service science as “a growing multi-disciplinary research andacademic effort that integrates aspects of established fields like computer science,operations research, engineering, management sciences, business strategy, social andcognitive sciences, and legal sciences” [5].

In the computer science domain, Service Oriented Architectures (SOA), haverevolutionized information systems, by providing software engineers with powerfulmethodologies and tools for decomposing complex systems into autonomouscomponents. The final aim of such evolution is to support enterprise vital processesand workflows, by simple orchestrations and compositions in the hand of businessspecialists.

Clearly the servitization of manufacturing companies covers different levels ofservice provision and consequently different stages can be followed to evolve.

In servitization, the product is considered as the core element of the service todeliver to customers and subsequently we follow a manufacturing approach takinginto account the market pressure that oblige to create new models in order to meetthe servitization challenge. An appropriate concept to link products, product relatedservices and the needs of the users is the “Extended Product” (EP) [6].


The Extended Product concept belongs to the category of Product-ServiceSystem. The Extended Product-Service is characterized by a layer model based onmanufacturing product and defining the process extensions. The Extended Product isa complex result of tangible and intangible components.

The Core Product is the physical product that is offered to the market; while theProduct Shell describes the tangible “packaging” of the product (e.g. one enterprisesells machine-tools and will add the maintenance which can be done by anothercompany). Supporting Services are intangible additions, which facilitate the use ofthe product (e.g. maintenance plans or mobility guarantees). Differentiating Servicesprovide individualization of the Extended Product on the market.

Then product extensions are described by the tangible and intangible aspects of a“utility package” to satisfy the customers’ needs. They can be used to gaincompetitive advantage by offering added value to the customer. While in the pastproduction costs, marketing, quality and reliability or time to market have been keysuccess factors, nowadays innovation is the decisive characteristic [7].

The resulting Extended Product would be the specific solution satisfying thecustomers demand. As the solution can become very complex, several businesspartners may be collaborating for the provision of the EP in the frame of anEcosystem.

Customers are looking for solutions and benefits (not only to acquire products)or even more they are requesting intangibles like leadership on the market, success,fame, etc. Manufacturers need to package their core products with additionalservices to make them more attractive.

The different stages of service provision are shown in Figure 1.

SupportingServices

Tangible Product Shell

Core Product (Tangible)

Differentiating Services

TangibleProduct

Product+Service

Product2Service

Product andsupportingServices

Product anddifferentiatingServices

Product as aService

b) Servitization process

a) Extended Product concept

Figure 1. From extended product conceptto servitization process


The first stage is the selling of a product (e.g. a machine tool).

The second stage which initializes the servitization process and the evolutiontoward Product+Service, start by adding a simple service (Product and supportingservice) (e.g. the company will add a device on the machine-tool allowing to checkcontinuously the running of the machine etc.).

The third stage (Product and differentiating service) is an evolution of theprevious one. The service is more elaborated and increases the differentiation (e.g.the company can propose to sell the machine plus a service which guaranties a highpercentage of availability of this machine).

The fourth stage, Product2Service scenarios are in contrast sharply decouplingmanufacturing of goods and selling of services, where in most cases physical goodsremain the property of the manufacturer and are considered as investment, whilerevenues come uniquely from the services (e.g. the company does not sell themachine-tools but sells hours of running of the machine-tool).

However, in this context, this is difficult for most of the companies to workalone in the Product2Service scenario but need to be associated to other companiesall along the service life cycle. Working together in design and production networksresults in an extension of companies’ “ability to reach” e.g. wider markets andknowledge spheres, a higher level of the companies agility, as well as the possibilityto share risks and resources. An industrial model for collaboration to exploit thevarious opportunities is a Virtual Manufacturing Enterprise (VME) (figure 2).

Figure 2. Virtual Manufacturing Enterprise


A virtual manufacturing enterprise (VME) is an enterprise that marshals moreresources than it currently has on its own, using collaborations both inside andoutside of its boundaries, presenting itself to the customer as one unit. It is a set of(legally) independent organizations that share resources and skills to achieve amission/goal.

However, such a virtual organization must be implemented differently in thedifferent phases of a service life cycle in order to support the service system asshown in figure 3 below.

So from a common Ecosystem (Service Manufacturing Ecosystem) composed ofseveral kinds of companies as research centres, SME’s, large companies,consultants…, it is possible to select the companies which will be virtualized foreach stage of the life cycle.

Service design phase Service Developmentphase

Service realisationphase

Service life cycle

Virtualisation

Virtualisation

Virtualisation

VME for service design VME for servicedevelopment

VME for service realisation

RealVME

VMEmodels

Managenon-compliance

(NC)

Manufacturingstrategy Delivery Strategy Quality strategy

Managingresources: Real

allocation

ManagementReview

manage inventoryand carriers

Manage resources:Projectedallocation

Manage finishedproduct inventory

Manufacturingequipmentinvestment.Training.

Customerrelationship quality

Planning Delivery Daily reportCustomer

Weekly reportCustomer

Quarterly reportCustomer

Activity interimreport

Market -Available

Technologies

Short-termplanning

(scheduling)

Managenon-compliance

(NC)

Short-termintervention(emergency)

Industrial strategicplan

Industrialequipmentinvestment.

Industrial Training

Manufacturingmethod .Validate

documents

WorkloadCustomer / SC

relationship quality.Release orders

MPSAnnual Budget

Content QMSDeadline for

implementation.Management

Review

Quality strategyIndustrializationstrategy

IISC2EI SC2 SC2 SC3 SC3 SC3

Internal Information

II

Manageindustrialization

SC2

Externalinformation

EI

30-OP

H = 6 moisP = 1 semaine

20-TA

H = 1 anP = 3 mois

10-ST

H = 5 ansP = 6 mois

Manage overallcoordination andsynchronization

SC2

Manage Quality

SC2

40-OP

H = 2 semainesP = 1 jour

Manage Quality

SC3

Manage deliveries

SC3

ManageManufacturing

SC3

H=5 yearsP=6 months

H=1 yearP=3 months

H=6monthsP=1 week

H=2 weeksP=1 day

modelling

Daily reportCustomer

Weekly reportCustomer

Quarterly reportCustomer

Activity interimreport

Market -Available

Technologies

Managingresources short

termReal allocation

Planning DeliveryManage

non-compliance(NC)

Short-termintervention(emergency)

Order TrackingShort-termplanning

(scheduling)

Downstreamlogistics strategy

Workload

MPSAnnual Budget

Industrial strategicplan

Manage inventoryReviving suppliers

Acceptingcommand

Revision of theprovisional plan

Choose answ er callfor tenders.

Negotiate offersOrder book

Forecast sales plan

Industrialequipmentinvestment.

Industrial Training

Manufacturingmethod .Validate

documents

Manage resourcesthrough termProjectedallocation

Ordering suppliesManage the stock

Manage finishedproduct inventory

Customerrelationship quality.Release orders

Volume of finishedproduct inventory

Frameworkcontract carriers

Manufacturingequipmentinvestment.Training.

Recruitment

Select ing suppliersControl critical

supplies

Content QMSDeadline for

implementation.Management

Review

Quality strategyUpst ream logisticsstrategy

Resourcesstrategy

IndustrializationstrategyBusiness Strategy

IIMMRMIMCREI MS MD GQMCS

Internal Information

II

Managemanufacturing(resources)

MMR

Manageindustrialization

MI

Manage customerrelationship

MCR

Externalinformation

EI

30-OP

H = 6 moisP = 1 semaine

20-TA

H = 1 anP = 3 mois

10-ST

H = 5 ansP = 6 mois

Manage supplies

MS

Manage deliveries

MD

Manage Qualit y

GQ

40-OP

H = 2 semainesP = 1 jour

Manage overallcoordination andsynchronization

MCS

H=5 yearsP=6 months

H=1 yearP=3 months

H=6 monthsP=1 week

H=2 weeksP=1 day

INFORM.EXTERNES

H= 5 ansP= 1 an

H = 21moisP= 6 mois

H = 12mP= 3 m

H= 6 moisP= 2 sem.

INFOSINTERNES

H= 2 sà 1mP= 1 j à 1 s

H = 2,5moisP= 1 jour

GERER LACONCEPTION

GERER LESPRODUITS PLANIFIER

GERER LESRESSOURCES GERER LA

MAINTENANCEAPPROSACHATS Hum.Techn.

H = 2 joursP= 1 jour

T.R.

PLANSTRATEGIQUE

P.L.T.

BUDGET

P.M.T.

P.C.T.

CALCULBESOINS

NETS

ACHATS

PROGRAMMEACHATS

PREVISIONSBUDGET

-MARCHES-

PREVOIRMARCHES

PLAN LTPRODUITS

FINIS

ESTIMERLES

BESOINS

CONCEPTIONMACRO-GAMMES- NOMENC.PAR GTF

Prévisionscommerciales

par GTF

Spécif.client

(maquette)

CONCEPTION. GAMME. NOMENC.SPECIF.

PAR PRODUIT

Commandescomm.- fermes

- anticipées

Autorisations

PREVISIONSESSAIS

Sortiesstocks

Lancement

fabrication

Affect.prévision.

Prévisonsmaintenance

Planannuelinvest.

Plan inv.stratég.

Stratégieressourc.humaines

Planmaintenancepréventive

Suiviréalisation O.E.

Suiviprésences

màj stocksMP / PI

P.E.A.

Affect.perso.

Adaptationemploi

maind'œuvre

P.E.A.

Customer

Bivolino

Problem of the customer

To collect info to create N. service (obj)

demo

Idea of Services

PartnerKW Bivolino

Infos on solution

proposition

Product and Services

KW Bivolino

Business Plan

mpl.Phase

Customer order

input customer

Analysis ofcustomer needs

ACNFeasibility study

FS

Negotiationand Agreement

NA

Technical designof the "solution"

TDS

Elaboration ofBusiness Plan

Proc

INFORM.EXTERNES

H= 5 ansP= 1 an

H = 21 moisP= 6 mois

H = 12 mP= 3 m

H= 6 moisP= 2 sem.

INFOSINTERNES

H= 2 s à1mP= 1 j à1 s

H = 2,5 moisP= 1 jour

GERER LACONCEPTION

GERER LESPRODUITS PLANIFIER

GERER LESRESSOURCES GERER LA

MAINTENANCEAPPROSACHATS Hum.Techn.

H = 2 joursP= 1 jour

T.R.

PLANSTRATEGIQUE

P.L.T.

BUDGET

P.M.T.

P.C.T.

CALCULBESOINS

NETS

ACHATS

PROGRAMMEACHATS

PREVISIONSBUDGET

-MARCHES-

PREVOIRMARCHES

PLAN LTPRODUITS

FINIS

ESTIMERLES

BESOINS

CONCEPTIONMACRO-GAMMES- NOMENC.PAR GTF

Prévisionscommerciales

par GTF

Spécif.client

(maquette)

CONCEPTION. GAMME. NOMENC. SPECIF.

PAR PRODUIT

Commandescomm.- fermes

- anticipées

Autorisations

PREVISIONSESSAIS

Sortiesstocks

Lancement

fabrication

Affect.prévision.

Prévisonsmaintenance

Planannuelinvest.

Plan inv.stratég.

Stratégieressourc.humaines

Planmaintenancepréventive

Suiviréalisation O.E.

Suiviprésences

màj stocksMP / PI

P.E.A.

Affect.perso.

Adaptationemploi

maind'œuvre

P.E.A.

Service requirement phase

VME for servicerequirements definition

Virtualisation

Figure 3. Virtualisation of enterprises and modellingfor each phase the service life cycle

Then, the implementation of each VME must be done with agility and withoutspending too much cost, reaching an interoperable organisation. In order to do so,


modelling of each VME will be done through a set of modelling languages used inthe frame of a common model driven architecture. In this sense, the next part willpresent the proposed architecture, describing in detail each modelling level and therequired constructs to represent based on the servitization principles.

3. Model Driven Service Engineering Architecture

The main interest of model driven approaches is to separate the differentpreoccupations from the business view of the product-service system to the technicalpreoccupations.

The proposed Model Driven Service Engineering (MDSE) Architecture iselaborated as an adaptation and an extension of MDA/MDI [8],[9] for theengineering of product related services in virtual enterprise environment.

The Model Driven Architecture (MDA) was defined and adopted by the ObjectManagement Group (OMG) in 2001, and is designed to promote the use of modelsand their transformations to consider and implement different systems. It is based onan architecture defining four levels, which goes from general considerations tospecific ones.

- CIM Level (Computation Independent Model) is focusing on the whole systemand its environment. It is also named “domain model”, it describes all work fieldmodels (functional, organisational, decisional, process…) of the system with anindependent vision from implementation.

- PIM Level (Platform Independent Model): model the sub-set of the system thatwill be implemented.

- PSM Level (Platform Specific Model): that takes into account the specificitiesrelated to the development platform.

- Coding Level The last level consists in coding or more generally enterpriseapplications (ESA: Enterprise Software Application).

To complete this description, a Platform Description Model used for thetransformation between PIM level and PSM level is added to these four kinds ofmodels corresponding to four abstraction levels.

The “Model Driven Interoperability” (MDI) consists in the early consideration ofinteroperability between enterprises models. Then it guides keeping the modelsinteroperable regardless of their abstraction level rather than only facing thatproblem at the coding step as it is frequently done in IT domain.


The MDI works were realised in the frame of the Task Group 2 (TG2) ofINTEROP-NoE dedicated to define an approach inspired from OMG MDA. Thegoal is to tackle the interoperability problem at each abstraction level defined inMDA and to use models transformations techniques to link vertically thedifferent levels of abstraction or horizontally to ensure interoperability of models ateach level. The main goal of this methodology, based on model transformation,is to allow a complete follow-up from expressing requirements to coding of asolution and also a greater flexibility thanks to the automation of thesetransformations.

These architectures are presented in figure 4 below.

ComputationalIndependant Model

Platform IndependantModel

Platform Specific Model

a) Model Driven Architecture (OMG)

Enterprise E2Enterprise E1

ESA 1 ESA 2InteroperabilityModel (PIM)

PIMLevel

PSMLevel

ESA 1 ESA 2InteroperabilityModel (PSM)

CodeLevel

ESA 1 ESA 2Interoperabilitycode

InteroperabilityModel (BCIM)

Bottom CIMLevel

transformation

transformation

transformation

transformation

transformation

transformation

ESA 1 ESA 2InteroperabilityModel (TCIM)

Top CIMLevel

transformation

transformation

transformation

ESA 1 ESA 2

transformation

transformationtransformation

b) Model Driven Interoperability (INTEROP NoE)

Figure 4.MDA (a) and MDI (b)developed architectures

Although MDA/MDI approached are more focused on IT system deployment,MDSE architecture aims to allow supporting the needs of modelling the three typesof service system components (IT, Human and Physical Means). The main benefitsof this model driven approach is to allow a continuum in the modelling from thebusiness to the realisational level and to specify and implement a set of componentcoherent with the chosen strategy of collaboration in the virtual enterprise.

The adapted MDSE architecture is shown in figure 5.


Figure 5.MDSE architecture

Similar to MDA/MDI, the proposed MDSE defines a framework for servicesystem modelling around three abstraction levels: Business Service Modelling,Technology Independent Modelling and Technology Specific Modelling.

3.1. The Business Service Modelling level and related constructs and languages

The Business Service Modelling (BSM) aims to model the service system, at theglobal level, describing the running of the virtual enterprise, i.e. the running of thecollaboration between the considered enterprises. The models at the BSM level mustbe independent to the future technologies that will be used for the various resources.In this sense, it’s useful, not only as an aid to understand a problem, but also it playsan important role in bridging the gap between domain experts and the developmentexperts that will build the service system (adapted [9]). In fact we develop the BSMin two sub-levels: the Top BSM and the Bottom BSM. The Top BSM sub levelmodels the enterprise and its environment at a global level in order to analyse thepossibilities to develop the System Service. The Bottom BSM will allow to model indetails the domain concerned by the servitization process (we can use the languagesdefined by the local modeling). Based on this first analysis, the service system willbe decomposed in the various components domains (IT, Organisation/Human andPhysical Means) with a detailed description. For instance, at the BSM level (top andbottom), the decisions are listed but not the related decision makers are relateddecision support systems. Similarly, the type of resources doing the activities islisted but not the precise name or location of these resources. The concepts


identified on the basis of the principles of servitization and virtual organization aspresented previously are listed below:

o Service

o Product

o Value

o Customer

o Partner

o Stakeholder (provider, intermediary, designer,…)

o Functionality

o Resource (Human type, Physical mean type, IT type)

o Process (business)

o Organization (responsibility, authority)

o Decision

o Decision structure

o Performance indicator

This list of concepts is considered as a list of core concepts.

Based on these concepts, several modelling languages can be used to representthe virtual organization at the BSM level as indicated in the figure 6 below:

ResourceFunctionality

Stakeholder

DecisionPerformanceindicatorProductValue

provide

measured byrelated tohavecontrol

relate to

have concern

apply

Customer

consume

Partner contribute

have Organization

Decisionstructurelinked

to

applyService Process

have

apply

Extended Actigrams Star concepts

GRAI grid and nets and ECOGRAI

Figure 6.Modelling languages at the BSM level


MDSEA proposed to associate relevant modeling languages at each level inorder to represent confidently the existing system and the future service product andservice system. To achieve this goal, the standards for process modeling are gainingmore and more importance, which gave rise to several process modeling languagesand tools to enhance the representation of enterprise processes. To choose amongthe languages, the level of abstraction required is important.

At the BSM level, the modeling language must be simple to use, powerful andunderstandable by business oriented users. Moreover, this (or these) language(s)must cover process and decision with coherent models.

As indicated in figure 6, for process modeling at business level, ExtendedActigrams Star (EA*) extended, from GRAI extended Actigram, that was itselfderived from IDEF0, was chosen to model processes at BSM level due to itsindependence regarding IT consideration, its hierarchical decomposition and the factit can model three supported resources: material, human and IT.

Moreover, GRAI Grid and nets were selected for modeling governance in aservice system. GRAI Grid aims at proposing a cartography of company’s decisionswhich controls business processes, as proposed for instance in the ISO 9000-2008standard. The interest of GRAI Grid is to represent all decisions and theircoordination, from the strategic to the operational levels. This representation is veryimportant for business users because the results of decision making are also at theorigin of performance evolution and achievement. GRAI nets allow us to detail thedecision process execution, as the procedure description for the BP.

3.2. The Technology Independent Modelling level and related constructs andlanguages

Technology Independent Modelling (TIM) aims to represent the models at asecond level of abstraction independent from the technology used to implement thesystem. It gives detailed specifications of the structure and functionality of theservice system that do not propose technological details. More concretely, it focuseson the operation details while hiding specific details of any particular technology inorder to be suitable for use with several different technologies. At TIM level, thedetailed specification will be elaborated with respect to the components in thedomains of IT, Organisation and Human and Physical means for a service system.So, the IT related modelling part aims at detailing the model of the enterpriseapplication, but mainly in terms of functionalities which will be implemented andwithout defining which application will be chosen. The functionalities will be ofcourse derived from the models at the BSM level. These functionalities will beclassified according to their importance in order to prepare the future selection at the


lower level. The functionalities can also cover the requirements in terms ofinteroperability with other systems implemented in one company of the ecosystem.The Physical mean part will be related to the means to add value to the product andto support the service production. At this level, the functionalities of a specificmachine and the expected performances can be proposed but no name of specificmachine is proposed. As for the IT part, the functionalities can be prioritized andsynthetized in order to propose a questionnaire that would be sent to the variousmachine providers.

This is obvious that the functionalities are derived from the models, in particularthe models of the physical system and business processes. The human resource partaims at defining the kinds of skills that are required according to the models. At thislevel, the name of a specific resource is not given but his/her place in theorganization, his/her role in this organization and performance to reach must bedetailed. This is obvious that this information can be derived, mainly from thedecisional modelling and the business process modelling as well as from thephysical models mainly for the persons directly involved in the productmanufacturing and the service distribution. Moreover, this information will be suedfor the recruitment or the move of specific human resource as well as for theplanning of the training of existing resource.

Based on these principles, the following constructs are proposed to berepresented in the models at this level:

o Service

o Process

o Organisation

o Resource

o Organisation unit

o Enterprise Application

o Information

o Human

o Physical mean.

Based on these concepts, several modelling languages can be used to representthe virtual organization at the TIM level as indicated in figure 7 below:


Resource

provide composed of

have Organization

is a

Enterprise application PhysicalmeanHuman

Information

used by

is a is a

Organizationunit

responsible to

Service Process

BPMN 2.0concepts

used by

Decisionsapply

UMLconcepts

GRAI Netsconcepts

Figure 7.Modelling languages at the TIM level

At the TIM level, BPMN 2.0 was chosen in particular because this languageoffers a large set of detailed modeling construct, including IT aspects and benefitsfrom the interoperability of many BPM IT platforms allowing the deployment andautomated transformation to execution of BPMN processes. Moreover, BPMNenables also to represent human and technical resources which are required in theMDSEA principles of representation. BPMN has also the advantage to provide ameta-model developed by OMG which facilitates the implementation of thelanguage. GRAI nets are proposed in order to detail the decision processes incoherence with the decisions identified in the GRAI Grid but with adding technicaland organization information as the decision rules, the decision makers, and thedecision support modules.

UML models are also proposed in order to model the enterprise applicationsrelated to information and human resources.

3.3. The Technology Specific Modelling level and related constructs andlanguages

Technology Specific Modelling (TSM) aims to combine the specification in theTIM model with details that specify how the system uses a particular type oftechnology (such as for example IT platform, Physical Means or Organisation withHuman profile). At TSM level, modelling and specifications must provide sufficient


details to allow developing or buying software/hardware components, recruitinghuman operators / managers or establishing internal training plans, buying andrealizing machine devices, for supporting and delivering services in interaction withcustomers. For instance for IT component, TSM adds to the TIM, technologicaldetails and implementation constructs that are available in a specific implementationplatform, including middleware, operating systems and programming languages. So,the IT related modelling part aims at detailing the model of the enterpriseapplication, but mainly in terms of detailed functionalities which will be bought ordeveloped in the chosen enterprise application. The functionalities will be of coursederived from the functionality modelling at the TIM level. The detailedfunctionalities can also cover the requirements in terms of interoperability with othersystems implemented in one company of the ecosystem. The Physical mean part willbe related to the choice of a specific physical mean. At this level, the functionalitiesof a specific machine and the expected performances will be verify and tested. Asfor the IT part, the functionalities will be very detailed and detailed actigrams couldbe used. This is obvious that the functionalities are derived from the models at theTIM level. The human resource part aims at defining the specific resource whichwill be selected, to verify the appropriateness with his/her place in the organization,his/her role in this organization and performance to reach defined at the TIM level.This is obvious that this information can be derived, in coherence with the decisionalmodelling and the organization models at the TIM level

Based on the specifications given at TSM level, the next step consists in therealization and the implementation of the designed service system in terms of ITcomponents (including coding) for automated information processing,machine/device components for material handling, and human resource andorganization ensuring human related tasks/operations.

Based on these principles and the strong relationship with the TIM level, thefollowing constructs are proposed to be represented in the models at this level:

o Service

o Process

o Organisation

o Resource

o Organisation unit

o Enterprise Application

o Information

o Human


o Physical mean,

o Layout

Based on these concepts, several modelling languages can be used to representthe virtual organization at the TSM level as indicated in figure 8 below:

Resource

provide composed of

have Organization

is a

Physicalmean HumanEnterprise application

Information

used by

is a is a

Organizationunit

responsible to

Service Process

-EN/ISO19440-SmartNetwork

EN/ISO19440

UML

BPEL

InternalSchemaPhysicalSchema

WSDLREST

Layout

implemented in

USDL

ServLab

Figure 8.Modelling languages at the TSM level

4. Templates to describe the concepts at the BSM level

For each modeling construct defined in Figures 6 to 8, a template is also definedto describe in detail its attributes. The use of the whole or part of attributes isdetermined by each case and the objectives of the modeling.

The advantage of using the template is to avoid the ambiguity in the constructsemantic.

The example of service construct template is given below in figure 9. Theservice template aims at describing service information collected from end-users.Because the service is here defined as a complementarity of the product, the conceptis different than the one used in IT in the SOA approach or in the Service OrientedModelling.


HeaderConstruct label ['Service']Identifier [Identifier of the service instance]Name [name of the service instance]BodyDescription [Short textual description of this service instance]Objective [Short textual description]Constraint [Short textual description]Relationships to other modelelements

PRODUCT [Identifier/name of Product concerned by the service:described by Product template]

FUNCTIONALITY [Identifier/name of functionality of the service: describedby Functionality template]

RESOURCE [Identifier/name of Resource providing the service:described by Resource template]

PROCESS [Identifier/name of Process providing the service: describedby Process template]

CUSTOMER [Identifier/name of Customer consuming the service:described by Customer template]

PERFORMANCEINDICATOR

[Identifier/name of the performance of the service:described by Performance template]

VALUE [Identifier/name of the Value of the service: detail will bedescribed by Value template]

STAKEHOLDER [Identifier/name of the Stakeholder: detail will be describedby Stakeholder template]

PARTNER [Identifier/name of the Partner: detail will be described byPartner template]

Other RelationshipsRELATED TO MODELLEVEL [Refer to BSM, TIM, TSM modeling level]: BSM

RELATED TO SLM PHASE [Refer to service lifecycle phases]: Requirement

Figure 9. Service template at the BSM level

5. Conclusion

In order to face the competitiveness, companies must progressively migrate fromtraditional product-centric business to product-based service-oriented virtualenterprise and ecosystems. In order to do so, they must create different virtual


manufacturing enterprises all along the service life cycle. To support the migration,enterprise modelling must be used to allow a progressive implementation of theseVME in the frame of a common architecture as MDSE architecture proposed in thiswork with ensuring a continuum in the modelling, coherent from the business to thetechnological level and to separate the preoccupations of different actors of thesystem design and exploitation. The related constructs required to represent at eachmodelling levels are derived from the servitization and virtual organizationprinciples. Chosen modelling languages are proposed at each modelling level as wellas templates to detail each concept and avoid misunderstanding in the modelling.

Several applications are now conducted to apply the MDSEA and the relatedmodelling languages.

The main perspectives of this work concern the transformation of languagesfrom BSM to TIM and from TIM to TSM in order to reach the final implementationof the service system.

6. References

FP7 – FoF-ICT-2011.7.3 -Manufacturing SErvice Ecosystem Project- Annex 1 description ofwork – July 29th 2011

http:// www.ibm.com/ developerworks/spaces/ssme.

Jagdev, H. S.; Browne, J.: “The Extended Enterprise. A Context for Manufacturing”. In:Production Planning & Control, 9 (1998) 3, S. 216-229

Lovelock, Christopher, Jochen Wirtz and Denis Lapert - Marketing des Services, Paris,France: Prentice Hall, 2004, 2nd ed., pp 619 ISBN 2-7440-7026-2

MDA - The Architecture of Choice for a Changing World [Online] // Object ManagementGroup. - January 2008. - http://www.omg.org/mda/.

MDI: Model Driven Interoperability; Available at: http://www.modelbased.net/mdi/;Accessed on: 15th March 2010.

Thoben, K.-D., Jagdev, H., Eschenbächer, J. (2001) Extended Products: evolving traditionalproduct concepts. In: K.-D. Thoben, F. Weber and K.S. Pawar (ed.) Proceedings of the7th International Conference on Concurrent Enterprising: “Engineering the KnowledgeEconomy through Co-operation” Bremen, Germany, June 2001.

Documents

SW1 part page - Wiley...Architecture extended from Model Driven Architecture developed by OMG and Model Driven Interoperability approach developed in INTEROP Network of Excellence[3]