MDSEA/MSTB

CG SLMTB (Service Lifecycle ManagementTool Box) created following the MSEE project (FP7 – 284860) (Manufacturing SErvice Ecosystem) based on two results: a method/architecture called MDSEA (Model Driven Services Enterprise Architecture) and a software support, the SLMTB (Service Lifecycle Management Tool Box). The participants are currently three owners of SLMTB (University of Bordeaux (IMS Lab, UNINOVA, INTEROP-VLab). This CG will be to be opened to others. The Goal is to create a consultancy service around the software and the Architecture/Method. Already there was some interesting results by the use of MDSEA and SLM TOOL BOX in other European Projects:

OSMOSE project: contribution to the architectures’ specifications and transformation model
PSYMBIOSYS project: POLIMI and I-VLab models the business processes for PIACENZA and FTI (pilots)
BEInCPPS project: modeling the cyber part of the Cyber Physical System.

To download the toolbox

CG SLM Tool Box Workspace

Introduction

MDSEA supported by SLMTB, developed in the MSEE project (Manufacturing SErvice Ecosystem, project no 284860 in FP7 FoF-ICT-2011.7.3, Virtual Factories and Enterprises), which allows to:

Realise the modelling of manufacturing service components (the Service, the Service System to produce the service, the resources to support the delivery of the service, the governance of the service system, the Performance Indicators implementation and a simple simulation to evaluate the performances). SLMTB is also well adapted to support the modelling of manufacturing system for product. From this modelling, it will be possible to determine the Business Requirements.
Facilitate the alignment of the Business Requirements with the ICT solutions but also with organizational resources and Technical means.

MDSEA supported by SLMTB will be used at the level of “requirement” and “design” of the service engineering process. It also facilitates:

The development of an interface between two systems in order to solve the problem of Enterprise Interoperability.
The support of the implementation of Performance Indicators.
The improvement of the performance of the system by supporting the transformation from the AS-IS Modelling to the TO-BE modelling.

SLMTB is a software tool:

developed in Eclipse environment (Eclipse public license).
• associated with an architecture, called MDSEA (Model Driven Service Engineering Architecture):decomposed by abstraction levels. Three abstraction levels are defined: Business System Model (BSM), Technology Independent Model (TIM) and Technology Specific Model (TSM):
including modelling formalisms concerning each of the above abstraction levels. These modelling formalisms could be supported by languages.
supported by a set of methods for the modelling using the formalisms.
using Model Transformation Techniques for the transformation of models between the abstraction levels.

We call this set of elements MDSEA components. Hereafter, the components of MDSEA which are proposed for this project are presented and the related concepts are discussed.

Figure 1: MDSEA Architecture (I-VLab, 2015)

Model Driven Service Engineering Architecture (MDSEA)

MDSEA architecture, illustrated in Figure 1, takes in account the various aspects of the manufacturing system from the real world to the technical world and human world but also along the life cycle of the system, product and services:

Business System Model (BSM): Models at this level represent the real world (user point of view). BSM describes the running of the manufacturing system at a conceptual level (concepts: functions, processes, activities, data, information/physical flows, resources, objectives, decisions, performance indicators …) independent of any specifications concerning human or technical resources. At this level, the GRAI (Graph with Results and Activities Interrelated) model is used to structure the concepts.

Technology Independent Model (TIM): This level is obtained from BSM by identifying the concepts of BSM belonging to 3 domains: IT (IT tool or IT development), Physical Means (Machines or tools development) and Human (Definition of competences/skills). In fact, these concepts are transformed from BSM to TIM by Model Transformation Techniques. Detailed specifications should be added to obtained TIM models.

Technology Specific Model (TSM): The TSM is the last and detailed level of modelling. The models are obtained separately, through Model Transformation, from each TIM domain model. Detailed specifications should be added to obtained TSM models depending on the specific technologies in order to develop or provide software, recruit or train personnel or purchase of machines or means of production.

In MDSEA, vertical alignment between models from different levels (from BSM to TSM) is provided by several Model Transformations types which depend on the considered domains. In fact, the Model Transformation is a succession of Top-Down and Bottom-Up iteration.

MDSEA was originally developed to model companies wishing to move from a product economy to a service economy. However, this architecture was designed generic enough to be applicable to any type of manufacturing context (MSEE, 2012). Therefore, we seek to apply MDSEA in this project which is positioned in this context, particularly to elaborate requirements of the pilots. For this purpose, we focus on BSM level.

Business Service Model (BSM)

The BSM level is based on Enterprise Modeling Techniques (EMTs). These techniques have been developed in USA in 1980s in order to improve the competitiveness of the US manufacturing industry. The most known tool is IDEF (Integrated DEFinition: IDEF0, … IDEFx). EMTs allow designing the model of an Enterprise System (ES) or a part of it. These techniques can be applied not only on manufacturing enterprises, but also in other domains such as Transport, Education, Health …

At BSM level, among the existing EMTs (CIMOSA (Computer Integrated Manufacturing Open System Architecture), IDEFx, GRAI (Graph with Results and Activities Interrelated), EIM (Enterprise Integration Modelling)…), we have selected GIM (GRAI Integrated Methodology) which offers several formalisms (particularly for decision structure modelling) and methods (for Performance Indicators definition and implementation).

GRAI decomposes the manufacturing system into three sub-systems: Control (Decisional) system, Controlled (Physical) System and Information System and.

The first principle is the system control (supporting the management of the physical system), (Figure 2):

Figure 2: Manufacturing three sub-systems

The controlled system (or the physical system) transforms the inputs (materials and information) into outputs (new information, products or services) to be mainly delivered to the customers. The manufacturing

The control system (or the decisional system) manages the above transformation based on the received feedback information from the controlled system and delivers actions or adjustments according the objectives.

The information system includes information from the physical system (feedback information) and from the customers, suppliers and other stakeholders (external environment) and manages the information flow between the control and controlled systems.

All the above systems can be modelled using formalisms/languages already supported by Service Lifecycle Management Service Tool Box (SLMTB):

Physical System modelling using formalism: Extended Actigramme Star (EA*). The EA* diagrams are transformed, using Model Transformation, to BPMN 2.0 diagrams at TIM level.
Information System modelling using formalism class diagrams issued form UML.
Decisional (Control) System modelling using GRAI grids and GRAI nets (decisional process).

In fact, this set of formalism allows describing the manufacturing system as it is (AS-IS situation). Then, it is possible to describe the TO-BE situation.

Extended Actigram Star (EA*)

In order to model the Physical sub-System of a Manufacturing System, we use Extended Actigram Star (EA*) formalism developed in the frame of MDSEA. Hereafter, we present:

first, the representation of the process using EA* formalism,
second, an example of process models,
third, the method to elaborate the models.

EA* formalism is mainly made up of the following concepts (see figure 3):

Activity graphically represented by boxes (transformation of inputs into outputs). Each activity is defined by a verb entitling an action.
Flow (of physical, information or financial entities) graphically represented by arrows connecting activities.
Connector graphically represented by ovals. It is a part of the model (a domain) which is not yet described by processes but is able to be a start or end point of a process.

There are 4 types of flows:

Input, connected on the left side of an activity, represents the flow of entities which will be transformed.

Output, connected on the right side of an activity, represents the flow of entities which has been transformed. It is important to verify the coherence of the transformation between the input and output flows.
Control, connected on the upper side of an activity, represents the conditions or circumstances that govern the transformation (objectives, constraints …). Controls are constant and are not transformed.
Resource, connected on the bottom of an activity, represents the resources necessary to perform the transformation. Resources are constant and are not transformed.

Figure 3 – Extended Actigram Star (EA*) formalism

At first, the global system could be represented by a Process (A0-0) with a single activity (see Figure 4): it represents the system which will be studied. At this level, we identify the main objectives, inputs, outputs and resources.

Figure 4 – Model of “Optimization of the Injection Schedule” process using SLMTB – (Global level: A0-0)

The above process could be decomposed, at a second level (A0), into several activities (see Figure 5). This decomposition can be pursued to reach a level with sufficient details allowing understanding of the system running. It is recommended to have a limited number of decomposition levels.

Figure 5 – Model of “ Optimization of the Injection Schedule” process using SLMTB – (First decomposition level: A0

GRAI Grid

The GRAI grid is a formalism which represents the Decisional sub-System of a Manufacturing System. It is a matrix in which (see Figure 6):

The functions of the Manufacturing System are represented vertically according the manufacturing system life cycle. The functions group a set of activities having a same identified finality (commercial, engineering, purchasing, planning, producing, delivery, quality, maintenance, recycling …).
The decision levels (strategical, tactical and operational) for these functions are represented horizontally. The levels are defined by the horizon (H: validity of the decision) and the period (P: interval of time to revise the planned decision).
Each cell represents a decision centre. For example, for the function “purchasing”, a decision centreat strategic level describes the decisions taken at this level such as Make or Buy decision. The decision centres are controlling a part of the physical system more or less global depending on the decision level (more or less at a high level), the whole GRAI Grid controlling the whole physical system. The strategic decision centres control the whole company and the operational decision centres control a detailed part of the company: shops, production units…
The bold blue arrows are the decision frames which represent the hierarchical links between decisions. The dotted arrows represent information flows.

Figure 6- Example of a GRAI grid for managing a Manufacturing System, a provisional proposition for Pilot Validation Scenario 1 (P1VS1)

The GRAI grid, illustrated in Figure 6, aims at representing an example of Decisional sub-System. Here, the main decisions are related to the function “To Plan” Make Injection Schedule (F2). It should be mentioned that this grid represents the manufacturing Decisional sub-System which controls the Physical sub-System modelled in part C of this section.

The decisions are made by Company Planner at three levels for the optimization:

Injection Aggregate Plan (every third month)
Injection Master Plan (monthly)
Injection Sequencing Plan (daily)

The “To Plan” function can be completed by two other functions: “to manage purchasing” (F1) and “to manage resources” (F3).

In the frame of the GRAI model, it will be possible to determine the Performance Indicators using ECOGRAI method. This method is applied with the implication of the decision makers of the organisation. There are two main steps in this method: design and implementation. The results of the design step are a coherent set of performance indicators covering the various business processes or functions and the verious decision levels from the strategic to the operational. These indicators are materialised using specification sheets descibing each Performances Indicators (Indicators, concerned actors, required information and processing …).