Model-driven Service Engineering Towards the Manufacturing

Liquid-sensing Enterprise

Carlos Agostinho

, Michele Sesana

, Ricardo Jardim-Gonçalves

1,3

and Sergio Gusmeroli

Centre of Technology and Systems, CTS, Uninova, 2829-516 Caparica, Portugal

TXT e-solutions, 20126 Milan, Italy

Department of Electrical Engineering, Faculty of Science and Technology, NOVA University of Lisbon,

2829-516 Caparica, Portugal

Keywords: MDA, MDSEA, Enterprise Interoperability, Sensing Enterprise, Liquid Enterprise, Business Process.

Abstract: Information and communication technology (ICT) has facilitated the introduction of mass customisation

capabilities into the traditional Enterprise, especially in the domain of manufacturing. Currently individual

end-customers are allowed to design and order a product that is uniquely tailored to their preferences.

Servitization and product-based services have been gaining momentum to support the integration of

products and services with customers. This has enabled companies to maintain a competitive advantage in

contemporary markets. However, such capabilities demand more efficient processes, information systems to

enable resources optimization, maximized collaborations along the value chains, and interoperable

information flows. The FInES Research Roadmap 2025 identifies both Sensing Enterprise and Liquid

Enterprise as two Qualities of Being that are strategic for any future enterprise. In fact, the enterprise needs

to become self-aware not only in terms of their networked ecosystem but also in face of their inner sub-

systems and devices. This paper develops the concept of the liquid-sensing enterprise, exploring how

modelling and model-driven development can support the transition and services implementation.

1 INTRODUCTION

There are clear signs that Western countries, and

Europe in particular, cannot proceed practicing

‘business as usual’. It is required a change of

paradigm to maintain (and improve) the current

standard of life (FInES Research Roadmap Task

Force, 2012). In fact, the traditional view on

manufacturing industry has always been associated

with the physical transformation of materials and

assembly of components to produce products. As a

consequence, production processes, production

machinery and the software to control such systems

had been the focus so far. This represents an

immense opportunity for Future Internet (FI)

technologies (including IoT) to make an impact.

Nevertheless, in some cases, products are

already morphing into services and products

themselves are becoming platforms for services,

leading to the creation of highly personalized

markets to be exploited, which in turn demand

restructuring value chains and changing the

relationship with the customer. The companies

mastering this scenario will excel, while enterprises

anchored in traditional manufacturing values will

suffer with more virulence the competition of BRIC

countries (Baines et al., 2009).

Relying closely on the IoT, the new Web-based

service economy will merge the digital and physical

worlds opening up a multitude of niches and value

propositions. Hence, we are in the verge of a digital

transformation that needs to take place. Westerman

et al. (2011) claim that industries are using digital

advances such as analytics, social media and smart

mbedded devices to improve their use of traditional

technologies such as ERP, as well as to perfect

customer relationships, internal processes, and value

propositions. Indeed, enterprises are individually

starting digital transformation addressing key areas

of their enterprises, namely customer experience,

operational processes and business models.

The Sensing Enterprise and Liquid Enterprise

concepts envisioned in the FInES 2025 roadmap can

complete that digital transformation, delivering to

manufacturing industries across the various sectors

the required enablers to connect and use FI

technologies, customizing them to address customer

608

Agostinho C., Sesana M., Jardim-Gonçalves R. and Gusmeroli S..

Model-driven Service Engineering Towards the Manufacturing Liquid-sensing Enterprise.

DOI: 10.5220/0005406606080617

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MDE4SI-2015), pages 608-617

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

experience, operational processes and business

models. New envisaged services are based upon the

convergence of networks, embedded computing,

control, content, and sensor feedback. Although

smart business systems can be described as an

evolution of the IoT, the evolution of traditional

enterprises into digital liquid or sensing enterprises

represents a fundamental change in the business

models that such enterprises will support and will be

able to implement.

In this context, a model driven approach can be

particularly valuable to support the formalization of

the liquid-sensing enterprise based on the fact it uses

enterprise models acknowledged by professionals

and standard institutions. An approach such as the

Model-driven Service Engineering Architecture

(MDSEA) is a perfect candidate to help in the

system re-engineering (Ducq et al., 2012). It can

support the enterprise processes modelling towards

the new sensing and liquid services design and

implementation. In section 2, this paper introduces

the liquid-sensing enterprise (LSE) concept in the

scope of OSMOSE research project (www.osmose-

project.eu). Then the authors analyse how the

MDSEA architecture can be applied to the LSE

(section 3), and section 4 presents the advancements

on LSE modelling. Finally an example is included in

section 5 and 6 concludes.

2 LIQUID-SENSING

ENTERPRISE (LSE)

An enterprise is a complex artefact. ISO 15704

defines it as a set of one or more organisations

sharing a specific mission, goals and objectives to

offer a product or a service (ISO TC184/SC5, 2000).

Its unique anatomy is composed of very different

passive tangible and intangible elements, and active

systems such as the Human or the artificial ICT

components. However, with the evolution of

business models and the growing of complexity, one

must face the idea that humans should (will) no

longer have a complete control over all the

operations acting on the produced artefacts, gaining

themselves a certain level of autonomy and

awareness. This is naturally true also for enterprises,

which need appropriate mechanisms to keep their

systems stable and optimized.

Following this vision, also shared by the 2025

roadmap for Future Internet Enterprise Systems

(FInES Research Roadmap Task Force, 2012),

today’s traditional engineering disciplines do not

appear adequate. Systematic methods, based on

advanced modelling techniques and model-driven

development, are required to correctly address the

activities carried out at the different phases of the

operational dimension. For instance, Business

Process Modelling and Management (Ko et al.,

2009) need to be complemented by the autonomic

capacity to react to unexpected events (e.g. through

Complex Event Processing (Michelson, 2006)).

In this context, both Sensing Enterprise and

Liquid Enterprise as two Qualities of Being that are

strategic for any future enterprise. The Liquid

Enterprise refers to the blurring of the enterprise

boundaries, where it is not easy to distinguish the

‘inside’ and the ‘outside’, the employees and the

partners, the competitors and the collaborators. It is

an enterprise having fuzzy boundaries, in terms of

human resources, markets, products and processes.

The Sensing Enterprise is a complementary

concept that emerges with the evolution of the

Internet of Things (IoT). It follows the need to

decentralise intelligence, moving to a scenario

where the enterprise is seen as a smart complex

entity capable of sensing and reacting to (business)

stimuli. The idea is to bring to organizations the

tremendous possibilities offered by the cyber worlds,

when objects, equipment’s, and technological

infrastructures will exhibit advanced networking and

processing capabilities, actively cooperating to form

a sort of 'nervous system' (Arthur, 2011).

Santucci et al. (2012) expect that the confluence

of both concepts enable the shift from the “walled

manufacture” to “liquid manufacture”, and

contribute to the vision of the Future Enterprise.

2.1 OSMOSE: IoT-enabled Metaphor

from Physics

The European Research Cluster on the Internet of

Things (IERC) recognizes that ICT development is

generating more and more things/objects embedded

with sensors, which are gaining the ability to

communicate with each other. This is renovating the

real physical world into an augmented information

and knowledge system. Hence, IoT is enabling

objects in our environment to become active

systems, sharing information with many

stakeholders, and gaining the skills for recognizing

events in their surroundings, to which they are acting

and reacting autonomously (IERC, 2011). Each IoT

object system has therefore a physical presence in

the Real World (RW), a model in the Digital World

(DW) specifying predefined pattern or behaviour,

and an image in the Virtual World (VW) to project

Model-drivenServiceEngineeringTowardstheManufacturingLiquid-sensingEnterprise

609

hypothetical what-if scenarios ruled by some laws

and policies (e.g. simulating the performance of a

production plant given some dynamic inputs).

In this context, the following metaphor can be

used to explain the OSMOSE concept, i.e. the

implementation of the liquid-sensing enterprise by

interconnecting Real, Digital and Virtual Worlds in

the same way as a semi-permeable membrane

permits the flow of liquid particles through itself:

Let us imagine the LSE as a pot internally

subdivided into three sectors by means of three

membranes delimiting the Real-Digital-Virtual

sectors. A blue liquid is poured into the bottom

sector (RW), a red liquid into the middle sector

(DW) and a green liquid into the top sector (VW). If

the membranes are semi-permeable, then following

the rules of osmosis the liquid particles could pass

and influence the neighbouring world, so that in

reality the blue RW also would have a red-green

shadow ambassador of the DW/VW, and similarly

for the other Worlds (Figure 1). An entity (person,

sensor network, an intelligent object) in the blue RW

should have control of their shadow images in the

red DW and in the green VW, keeping them

consistent and passing them just the needed

information under pre-defined but flexible privacy

and security policies (Spirito et al., 2014).

Figure 1: OSMOSE Metaphor.

2.2 Osmosis Processes

In the OSMOSE system, we assume that events

could be generated in any of the three worlds of a

LSE and that they should be propagated to the other

two worlds by interaction and negotiation of the

respective stakeholders. A chain reaction of events

could also be generated from a set of six processes

(osmosis processes):

• Virtualization - the Actor-Avatar process

which allows to provide data for simulation

of hypothetical RW situations;

• Augmentation – annotates RW objects with

VW data, allowing projections to be

superimposed to the RW and providing the

user with unprecedented experience of

mixing smart physical and virtual objects;

• Digitalization – supports modelling and

representation of RW data in a computer-

tractable form, providing the basis for

integration of Event Driven Architectures

(EDA) with service orientation;

• Actuation - the Agent-Actor osmosis process

that is able to plan and implement highly

distributed decision-making;

• Simulation – the Agent-Avatar process that is

able to run hypothetical scenarios fed by DW

models, knowledge and rules.

• Enrichment - extends the computational and

experiential capabilities of the DW with

annotations and projections coming from

simulations and hypothetical scenarios.

Figure 2: OSMOSE LSE Framework.

A triangular diagram (Figure 2) is used to

pictorially represent these processes. As explored

along this paper, the use of different IoT/ICT

technologies such as the EDA and MDSEA is

required for managing the osmosis processes.

Traditionally, representing and implementing the

interactions between the three worlds is achieved by

means of interoperable models and tools.

Nevertheless, there should be some automatic, real-

time but context-based mechanism for consistency

keeping and reconciliation of the shadow images.

Thus, regular interoperability techniques for

exchanging information should be substituted by a

integrated intelligent entities visible through the

gates of each World (as in the 1994 Stargate movie

teleportation device - imdb.com/title/tt0111282/).

Virtual

World

popula on

Digital

World

popula on

Real

World

popula on

Fuzzy

Boundaries

Sensing

Devices

OSMOSE

Virtual

World

popula on

Digital

World

popula on

Real

World

popula on

Digital World

Real Physical World Virtual Cyber World

Virtualization

Augmentation

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

610

2.3 Event-Driven Architectures (EDA)

An event indicates a significant change in the state

of the universe (Chandy et al., 2007). Sensor data,

network signals, or application processing

information, are examples of simple events, while a

complex event is an aggregation of related events

(simple or complex). Papadopoulos et al. (2010)

describes the importance of complex event

representation and semantic enrichment for

managing and reviewing emergency incident logs. In

that example and others alike, extensive manual

effort is necessary to identify critical information,

such as person names and locations, in order to align

and merge the incoming log entries to make them

suitable for managerial decisions.

Generally, IoT applications are characterized by

producing a high volume of fine-grained data, which

is emitted by sensors. Therefore they must deal with

continuously arriving event streams. (Luckham,

2001) Due to the high volume of events and their

complex dependencies, no predefined workflow can

be specified, and as opposed to traditional DEBS

(Distributed Event- Based Systems) IoT creates a

highly dynamic application environment. Also,

current software architectures such as service-

oriented architectures (SOA) do not target event-

based systems, because they are based on a process-

oriented control flow, which is not appropriate for

event-driven systems. In recent years, EDA has been

proposed as a new architectural paradigm for event-

based applications (Michelson, 2006). The main idea

lies in the processing of events as the central

architectural concept, i.e. to use complex event

processing (CEP) as the process model for event-

driven decision support. Event streams generated by

sensors contain a large volume of different events,

which must be transformed, classified, aggregated

and evaluated to initiate appropriate actions.

The Esper (http://esper.codehaus.org) CEP

engine supports events in XML, Java -objects and

simple attribute value pairs. There are also many

CEP vendors such as Tibco, Coral8/Aleri,

StreamBase or Progress Apama providing tool suites

including a development environment and a CEP

engine. Most of the described systems use different

SQL-like or XML based complex event pattern

definitions, which makes it more difficult to

understand and read them. Neither of them provide

the knowledge support for event/process/service

model-driven integration, capable of satisfying the

integration of the entities in each of the three

OSMOSE worlds.

3 MODEL-DRIVEN SERVICE

ENGINEERING

Embracing the servitization integrated view on

product-service systems and extended products,

services concern physical products and objects as

well as the associated technology, people and

knowledge (Chesbrough & Spohrer, 2006). In fact,

to deploy an enterprise service, especially in

manufacturing, it will be necessary to involve

several partners and manage knowledge crossing

different boundaries of the enterprise (Zdravkovic et

al., 2013), much alike the LSE.

OMG’s model-driven architecture (MDA) and

model-driven interoperability (MDI) are amongst the

pioneer and most prominent technologies for model-

based enterprise development and integration (Chen

et al., 2008). MDI is more detailed and targeting

interoperability. Other approaches exist in the

domain of service (e.g. SOMF (Arsanjani, 2004))

but they are all still dedicated to ICT and not

manufacturing services. Therefore, to better define,

implement, and support the service life cycle, it is

necessary to separate the user point of view from

technical and from the physical means to realize it.

Figure 3: MDSEA (Ducq et al., 2014).

Therefore, the MDSEA architecture was first

presented by Ducq, Chen, et al. (2012) to model and

guide the transformation continuum from the

business requirements of the service system (BSM

level) into detailed specifications of components that

must be implemented to support the servitization

process (TSM level) was proposed. It follow the

MDA/MDI principles (Agostinho et al., 2014), and

as illustrated in

Figure 3

, combines that with the

Model-drivenServiceEngineeringTowardstheManufacturingLiquid-sensingEnterprise

611

manufacturing servitization needs, supporting

modelling of three types of components (IT,

Organization/Human and Physical Means).

In order to operationalize service engineering

using MDSEA, it is necessary to follow a precise

method, which begins at the strategic level of

companies that want to evolve towards service-

oriented business methods. The approach implies

that the different models, obtained via model

transformation from the upper-level ones, should use

dedicated service modelling languages that represent

the system with the appropriate level of description.

GRAI Integrated Modelling and BPMN 2.0 (OMG,

2011) have been considered as a reference. The

MDSEA architecture provided the building blocks

for service system development in the scope of an

ecosystem of collaborating enterprises, providing:

 The capability to transform a business specific

model into a functional one that can then be

perfected by a system architect detailing the

ICT, Human and Physical components;

 The capability to transform a functional model

into a technology specific one envisaging the

generation of concrete services.

3.1 Discussion on Service System

Design at the LSE

Being a new paradigm for the enterprise, the LSE

also requires, as in servitization, modelling to

support the formalization of knowledge and

facilitate the interoperability with partners. Also, one

can consider that the design of services is inherent to

the manufacturing LSE. This will be addressed in

more detail in the next section, but both MDSEA

and LSE need to specify enterprise business

processes, identify resources, while relating those

with services. Hence, the LSE design could benefit

from the methodology behind MDSEA in order to

accelerate the transition of the traditional enterprise

to the “internet-friendly” and context-aware

organization envisaged in OSMOSE. The major

question resides on the fact whether the LSE concept

and MDSEA strategy are compatible.

The similarity with the strategy for the

separation of concerns behind the LSE real and

digital worlds is evident. For instance, there is the

clear notion that objects on the MDSEA’s “Physical

Means” domain need to have a shadow image on the

“IT” to enable the full design of the service system.

The “Organization and Human” domain is somehow

spread along both RW and DW with the person and

enterprise system belonging to the RW, but with

their associated knowledge and structure available at

the DW. The VW is not directly apparent in this

structure, but for example, methods for simulation of

business processes can be derived directly from

TIM’s IT models (Bazoun et al., 2014).

Hence, even though the initial objectives where

different, one can hypothesise that the MDSEA can

be applied to support the modelling of the

manufacturing liquid-sensing enterprise. The role

and complexity behind the enterprise ecosystem that

collaborates to co-create the manufacturing services

is taken by the 3 worlds in the OSMOSE framework,

which need to be integrated. MDSEA might need to

be extended to cover aspect such as events and event

processing, but it can support the generation of

liquid-sensing services implementing the 6 osmosis

processes for each enterprise instance. Thus, even if

not all LSE concepts are covered by the current

version of the MDSEA, it serves to accelerate and

guide the LSE modelling and implementation.

4 OSMOSIS PROCESSES FOR A

MODEL-DRIVEN LSE

As introduced in section 2.2, the osmosis processes

are a special type of process used to moderate the

information exchange among the real, digital, and

virtual worlds. We distinguish six osmosis processes

that, when instantiated will enable to seamlessly

integrate the LSE, connecting events across the 3

worlds, triggering services to provide the enterprise

full knowledge about its inner systems, and create

awareness concerning the interactions with the

business partners.

The OSMOSE LSE objectives and the

implementation of the semi-permeable membrane

require modelling at the various levels of the

enterprise (business, platform, implementation).

Indeed, constructs such as the ones of Resource,

Service, Event, or Enterprise Process need to be

specified at a certain point of the model-driven

continuum. Together, these constructs enable the

creation of a distributed knowledge architecture able

to manage the integration of the 3 worlds. Figure 4

depicts the relation among the modelling constructs

relevant to an Osmosis Process, in the scope of

business process modelling. The figure makes clear

that these special processes extend the enterprise

processes running in the different worlds, to

moderate the flow between them, crossing the

membrane. They can be associated to certain

Services (through Activity), which in turn can trigger

Events as well as act upon enterprise’s Resources.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

612

Resources are tangible elements of the

Organization. They can assume the form of machine

or Human systems when they exhibit certain

behaviour or functionality, but can also be products

or parts. However, all of them can have shadow

images in each of the OSMOSE worlds. A Human,

for example, is an Actor in the RW, and can have a

shadow Avatar in the VW, or Agent in the DW.

Services, Events, and Processes are different in the

sense that they can exist in any of the worlds but are

only associated to a single world instance.

Figure 4: Modelling Constructs: relation with business

process modelling.

The Service construct does not consider only

software services. As addressed along the paper, the

manufacturing enterprise can also specify certain

services such as product measurement service

provided by a certain machine, or a pilot training

service for the flight simulator etc. This way,

Resources may provide Services, which in turn, act

upon Resources. Finally, Events are closely related

with Services. Together they define a chain of

Event-Service action-reaction along the 3 Worlds

(Events executing Services and Services triggering

Events). An Event can be defined as a significant

change in state (modification event), a notification

of abnormal situation (alarm event), or any other

informative occurrence about a certain Resource.

4.1 Representation of Real, Digital and

Virtual Worlds

The Real, Digital and Virtual worlds are represented

as a set of enterprise processes and sub-processes,

with their internal tasks and events generated. Every

actor (system or person) is seen as a process and

every action is generating a set of events, which can

either refer to usual process oriented operations (e.g.

start, end or terminate) or be originated during

activities execution by actors of the world; for

example from IoT system, one can get the value of

the room temperature or the average of humidity

during the day; from a software it is possible to

extract usage of the memory or a software exception.

Figure 5 shows a simple abstract process that is

originating a set of events during the execution.

Figure 5: Real, Digital and Virtual Worlds representation.

4.2 Events Typology

We do not commit to a complete event description

(i.e. a specific event definition language) but rather

assume that the events that are passed between

processes provide meta-information, which allows

the process to retrieve all data that is relevant for

handling it. The meta-information defines an

envelope used to send post and receive events to and

from the CEP. The information in the envelope

allows the receiver to find all details needed for

dealing with the event. The following schema

provides technical representation details of a

possible envelope:

<domain> Automotive Manufacturing </domain>

<worldID> Real World </worldID>

<eventType> Critical Error </eventType>

In order to uniform events coming from different

worlds, a taxonomy of events is adopted. The first

level of the taxonomy is derived from the events

available in the business process domain and defined

in BPMN2.0 (OMG, 2011). The taxonomy needs, of

course, to be extended in order to cover RW, DW

and VW requirements to recognize and manipulate

events. For example a signal is a non-interrupting

event in the process chain that can be extended in

order to monitor the temperature level in a certain

instant of time as temperatureSignal. Taxonomy is

also extended in order to cover membrane needs; for

example Danger Event extends Error Event.

Osmosis

Process

Event

Service

Enterprise

Process

has

calls

Resource

applies

provides

triggers

executes

hasSub

triggers

Organiza on

applies

hasSub

executes

Osmosis

World

moderatesFlowBetween

has

ac ons

Ac vity

has

provides

actsUpon

Model-drivenServiceEngineeringTowardstheManufacturingLiquid-sensingEnterprise

613

4.3 Osmosis Meta-templates

Similarly to what has been provided for MDSEA,

also the main LSE constructs are firstly modelled at

meta-level following a template to gather data. Due

to space constraints, only the templates for Osmosis

Process and Service are presented (Table 1 and

Table 2). They extend the original MDSEA

templates available at Doumeingts et al. (2012).

Table 1: Osmosis Process Template.

Header

Identifier [Identifier of the process instance]

Name [Name of the process instance]

Type [Virtualization; Augmentation;

Actuation; Digitalization; Enrichment;

Simulation]

Body

Objective [Description of the process instance]

Causing Events [List of events that caused the

triggering of the osmosis process (e.g.

temperature higher than 100ºC)]

Resources

[List of system and other resources

that are addressed by the process

pre/post-actions (e.g. simulator)]

Mode of

Operation

[Description of how far the process is

automated]

Functionality [Short textual description of the

activities composing the process]

Representation [Graphical representation of sub-

functions (e.g. BPMN)]

Table 2: Service Template.

Header

Identifier [Identifier of the service instance]

Name [Designation of the service instance]

Type [Software service; manufacturing

service; support service; etc.]

Body

Description [Short description of this instance]

Functionality [Short textual description]

Constraint [Short textual description]

Mode of

Operation

[How far the service is automated]

Access [Specify how, where and when is a

service made available]

Consumption [Specify what is expected where and

when by different parties participating

in service]

Business Value [Short textual description (if any)]

Performance

Indicators

[List of PI’s (if any)]

4.4 Modelling Osmosis Processes and

the LSE Membrane

After gathering meta-information for LSE

constructs, it is time to detail them using the selected

representation format. At the TIM level, BPMN 2.0

is a natural selection, but modelling should begin at

higher level (e.g. using Extended Actrigram * or

GRAI GRID) in the case new enterprise services are

to be deployed (natural case of MDSEA). In the

case it is only supporting the transition towards an

LSE (focus of the paper), then only the services

assisting the osmosis processes are new, and TIM is

an acceptable starting point. Nevertheless it is

important to note that the use of an enterprise or

software architect is recommended.

The membrane process is implemented as

illustrated in Figure 6; it acts as a listener component

that, at the time events are received, checks their

context and nature (type of the event as discussed

before) and decides whether an event is “osmiotic”

or not. If it is the case, then corresponding osmosis

process(es) is/are started. Otherwise, the system can

decide to do nothing or to start an intra-world

enterprise process needed to manage the event in the

scope of the world that originated it. In the osmiotic

case, a call to an intra-world process can happen

aside the osmosis process; for example to react to a

serious error in the real world the machine is stopped

launching a RW process (intra-world) and the

virtualization is started in parallel (inter-world).

4.5 Model-driven Generation of LSE

Services

Having all the models recreated at the TIM level

(Figure 6 extended with all details), one will already

have specified the enterprise behaviour in a platform

independent level. Hence, MDSEA enables the

generation, though top-down model transformations,

of the osmosis services necessary to have all the

information integrated and accessible through the

gates of the different worlds (with different views

targeted for different actors). Agostinho et al.

(2014), in his paper about MDSEA model

transformations, goes into more detail how the

information is generated with the detail necessary to

reach an actual software service.

5 VIRTUALIZATION CASE IN

MANUFACTURING

The overall reason to have VW is to allow users to

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

614

Figure 6: Membrane Monitoring of OSMOSIS events.

investigate hypothetical situations. In many cases

these situations are investigated with the help of

simulations that use models, which are linked to RW

entities. The purpose of virtualization is, on the one

hand to create virtual artefacts that represent or at

least correspond to RW entities, and to provide the

data, which allows re-creating virtual situations that

are close to situations actually occurring in the real

world. Important concepts for virtualization are

therefore physical entities, measurement of physical

entities, and (3D) models derived from RW entities.

Depending on whether the model of the VW

already exists and does not need to be changed at the

level of modelling, the process might run completely

automated or completely manual, where manual

does not means that is not computer supported with

adequate modelling tools. In cases where no (or only

a partial) model is available and a new model needs

to be created, the process of virtualization needs to

be executed by human experts. For example, it is

possible to provide accurate 2D or 3D scans but

without further modelling effort only the pure data

can be visualized. Automated checks and processing

might be done on this data. However, checks and

processing needs to be predefined together, and with

this the process of virtualization.

With respect to virtualization, the LSE aims at

generic virtualization processes that can be flexibly

instantiated for different situations. In many cases

this might basically mean that the data the process is

acting upon is coming from different RW entities.

5.1 RW Events

Real world events monitored by the membrane are

correlated to (non–exhaustive list):

• HW execution system (danger, error, warning,

advancement info, config. settings debug);

• SW execution system (running, error, warning);

• Structural measurement (strengthens measured,

surface, 3D scan);

• Position (GPS positioning, logistic position);

• Environment (temperature, humidity,

brightness, policy)

• Availability (broken/available/updated).

Some of the events are the starting point for both

virtualisation and digitalisation processes while

others are correlated to just one of the osmosis

process.

5.2 Example

This section reports the Activities and Services that

need to be executed and/or generated to support the

virtualization process following certain events. “HW

Danger” and also “HW Warning” are exemplified.

For each process, the generic set of steps is detailed

in the following form. Services, events or processes

that need to be generated are indicated.

HW Exec DANGER Event Subsequent Steps:

1. Block the system (internal process)

2. Activate notification (alarm event) to the

environment (human and/or things)

3. Activate safety procedure (internal process)

4. Collect data about environment (GPS

positioning and tracing of objects people,

information about positioning of object,

settings of machineries) (service)

5. Save data (service)

6. Prepare session for the virtual recreation of

the situation (process)

7. Inform target system in VW (service).

HW Exec WARNING Event Subsequent

Steps:

1. Activate notification (alarm event) to the

environment (human and/or things)

2. Collect data about execution (service)

3. Save data (service)

4. Prepare session for the virtual recreation of

the situation (process)

5. Inform target system in VW (service).

Model-drivenServiceEngineeringTowardstheManufacturingLiquid-sensingEnterprise

615

The above sequences can be applied in multiple

situations. The first one could be illustrated with a

simple situation taken from a manufacturing shop

floor environment, i.e., “after an accident/incident,

a what-if simulation of the manufacturing

environment can be done in order to understand

how the situation has been generated; verify if it has

been well managed and better organize shop floor

workplace and machineries configuration for the

future”. We could illustrate the second with a

warning in a production line. For instance “an over

threshold temperature of some components can be

acceptable allowing the system to continue working

(so remaining a warning without becoming an error)

if the system is used with some constraints like, for

example keeping a lower speed during execution.

The constraints will be determined during what-if

simulations and fed back to the system by

augmentation process”.

6 CONCLUDING REMARKS

The paper analysed the needs behind industry’s

digital transformation and how it can be capitalized

by implementing the sensing and liquid enterprise

concepts proposed by the FInES 2025 roadmap. The

paper presented the status quo of the modelling and

design of the OSMOSE liquid-sensing enterprise

vision, as well as the realisation on the osmosis

process and connected events and services.

The general modelling approach towards LSE

osmosis processes realisation has been provided and

MDSEA has been proposed. Due to the proximity of

some of the inner construct behind manufacturing

servitization design and LSE design, the model

driven approach could be adapted to facilitate the

transition between the traditional enterprise and the

future LSE. The realisation of the activities, events

handling, monitoring, recognition of osmosis, and

the reaction by osmosis processes, is currently

modelled at the MDSEA TIM level. Model

transformations are applied to semi-automatically

derive technology specific models and accommodate

the specific needs of every enterprise and reach an

actual software service that supports the LSE

osmosis.

Implementing the OSMOSE digital

transformation will provide companies the digital

capabilities to capitalize on the FI and IoT,

improving customer experience, operational process,

business models. Next steps target the osmosis

processes deployment into real pilots and further

study on how to integration CEP middleware with

the generated services is needed. Also governance

models need to be studied for a proper realization of

the LSE at the BSM level. Based on the feedback

received, the final version of the modelling approach

will be produced.

ACKNOWLEDGEMENTS

Authors would like to acknowledge the European

funded Projects MSEE (FP7 284860) and OSMOSE

(FP7 610905) that supported the development of

various ideas, concepts and use case presented.

REFERENCES

Agostinho, C., Bazoun, H., Zacharewicz, G., Ducq, Y.,

Boye, H. & Jardim-Goncalves, R. (2014) Information

Models and Transformation Principles applied to

Servitization of Manufacturing and Service Systems

Design. In: ModelsWard 2014.

Arsanjani, A. (2004) Service-oriented modeling and

architecture. IBM developer works, pp.1–15.

Arthur, W.B. (2011) The Second Economy. McKinsey

Quarterly. Available from: <www.mckinsey.com/

insights/strategy/the_second_economy>.

Baines, T.S., Lightfoot, H.W., Benedettini, O. & Kay,

J.M. (2009) The servitization of manufacturing: A

review of literature and reflection on future challenges.

Journal of Manufacturing Technology Management,

20 (5), pp.547–567.

Bazoun, H., Bouanan, Y., Zacharewicz, G., Ducq, Y. &

Boye, H. (2014) Business process simulation:

transformation of BPMN 2.0 to DEVS models (WIP).

In: DEVS ’14.

Chandy, K.M., Charpentier, M. & Capponi, A. (2007)

Towards a theory of events. In:DEBS ’07. NY,USA.

Chen, D., Doumeingts, G. & Vernadat, F. (2008)

Architectures for enterprise integration and

interoperability: Past, present and future. Computers in

Industry, 59 (7), pp.647–659.

Chesbrough, H. & Spohrer, J. (2006) A research manifesto

for services science. Communications of the ACM, 49

(7), p.35.

Doumeingts, G., Lieu, C., Chen, D., Ducq, Y., Alix, T.,

Zacharewicz, G., Bourrières, J.P., Vallespir, B.,

Jardim-Goncalves, R., Agostinho, C., Silva, E.M.,

Hirsch, M., Heller, M. & Friesen, A. (2012) MSEE

Deliverable D11.1: Service concepts, models and

method at CIM-PIM-PSM level. MSEE IP Project

(FP7 FoF-ICT 284860).

Ducq, Y., Agostinho, C., Chen, D., Zacharewicz, G. &

Jardim-Goncalves, R. (2014) Generic Methodology

for Service Engineering based on Service Modelling

and Model Transformation State of the art in model

driven approaches and model transformation. In: S.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

616

Wiesner, C. Guglielmina, S. Gusmeroli, & G.

Doumeingts eds. Manufacturing Service Ecosystem:

Achievements of the European 7th Framework

Programme FoF-ICT Project MSEE: Manufacturing

SErvice Ecosystem (Grant No. 284860). Verlag-

Mainz, pp.41–49.

Ducq, Y., Chen, D. & Alix, T. (2012) Principles of

Servitization and Definition of an Architecture for

Model Driven Service System Engineering. In: IWEI

2012. Harbin, China, Springer.

FInES Research Roadmap Task Force (2012)

FInESResearch Roadmap 2025: version 3.0.

IERC (2011) Internet of Things: Pan European Research

and Innovation Vision.

ISO TC184/SC5 (2000) Industrial Automation Systems—

Requirements for Enterprise-reference Architectures

and Methodologies (ISO 15704).

Ko, R.K.L., Lee, S.S.G. & Wah Lee, E. (2009) Business

process management (BPM) standards: a survey.

Business Process Management Journal, 15 (5),

pp.744–791.

Luckham, D.C. (2001) The Power of Events: An

Introduction to Complex Event Processing in

Distributed Enterprise Systems. Addison-Wesley

Longman Publishing Co.

Michelson, B. (2006) Event-Driven Architecture

Overview. Patricia Seybold Group. Available from:

<http://www.customers.com/articles/event-driven-

architecture-overview> [Accessed 9 Dec 2014].

OMG (2011) Business Process Model and Notation

(BPMN) - version 2.0 (formal/2011-01-03).

Papadopoulos, S., Scherp, A., Ireson, N., Tsampoulatidis,

I. & Kompatsiaris, Y. (2010) Using event

representation and semantic enrichment for managing

and reviewing emergency incident logs. In: EiMM ’10.

New York, USA, ACM Press, p.41.

Santucci, G., Martinez, C. & Vlad-câlcic, D. (2012) The

Sensing Enterprise. In: FInES Workshop at FIA 2012.

Aalborg, Denmark.

Spirito, M., Pastrone, C., Soldatos, J., Giaffreda, R.,

Doukas, C., Muñoz, L., Polidura, V.G., Gusmeroli, S.,

Sola, J. & Agostinho, C. (2014) Internet of Things

Applications - Research and Innovation to Market

Deployment (Chapter 7). In: O. Vermesan & P. Friess

eds. Internet of Things – From Research and

Innovation to Market Deployment. River Publishers,

pp.243–286.

Westerman, G., Calmėjane, C. & Bonnet, D. (2011)

Digital Transformation: A Roadmap for Billion-Dollar

Organization.

Zdravkovic, M., Panetto, H. & Trajanovic, M. (2013)

Semantic Interoperability for Dynamic Product-

Service. In: ICIST 2013. Kopaonik, Serbia.

Model-drivenServiceEngineeringTowardstheManufacturingLiquid-sensingEnterprise

617