SIST-TP CEN/TR 17859:2022
(Main)Service Modelling Language
Service Modelling Language
This specification defines constructs for a Service Modelling Language (SML) for Virtual
Manufacturing Enterprises (VMEs). There is no language standard in ISO or CEN for the
modelling of service systems. Existing service modelling languages mainly focus on IT–
related services or web services. Most existing enterprise modelling languages have some
relevance for services for a VME and can be reused to model part of a service system in this context. However the concepts of those modelling languages need to be integrated and mapped one to another in order to cover the whole modelling requirements for service system engineering.
A standardized Service Modelling Language (SML) and its associated meta-model is seen as an important issue to avoid costly and fragmented development in this domain. SML is focusing on modelling of manufacturing services that a company can develop to support its
products. Compared to ISO 19440-2, SML employs less constructs and a simpler structure. The SML can be considered a specialization of the more general modelling language proposed in ISO 19440-2 .
The modelling constructs of this Technical Specification are complementary to
those constructs and support the design and implementation of future enterprise systems
providing extended products (products + services) to the market.
This Technical Specification specifies:
a) a Model Driven Service Engineering Architecture (MDSEA),
b) a set of constructs for a Service Modelling Language for (Virtual) Manufacturing
Enterprises developed under MDSEA.
Five annexes are provided addressing the basics concepts of service modelling, service
modelling languages, tools and MDSEA and industrial pilots to validate the SML, Annex
D and Annex E.
The MDSEA architecture is derived from MDA [1] and MDI [2] with necessary adaptation and extension to cover the modelling of service (and its system) in its most general forms.
The modelling language addressed in this Technical Specification is specified only at the Business Service Modelling (BSM) level of MDSEA. This specification applies to manufacturing enterprises but can also apply to other classes of enterprises. It is intended for use by system engineers, IT and research specialists who are concerned with developing and deploying product related services in VMEs and Ecosystems.
The constructs specified in this document are also intended to be used by those business
users who are making decisions based on business rather than technical concerns. For this reason, many of the details are simplified or omitted compared to their equivalents (where they exist) in IS 19440:2.
The main added value of the proposed SML will be threefold:
i) Identification of the language constructs needed to define services needed by the
business user.
ii) Integration of existing modelling languages constructs into one coherent meta-model.
iii) Definition of an MDSEA framework based on MDI/MDA to host the language and offer
methods of model transformation between the modelling levels.
Sprache zur Modellierung von Dienstleistungen
No Scope Available
Langage de Modélisation de Service
No Scope Available
Jezik za storitve modeliranja
Ta specifikacija opredeljuje konstrukte jezika za storitve modeliranja (SML) za virtualna proizvodna podjetja (VME). Za modeliranje storitvenih sistemov ni jezikovnega standarda ISO ali CEN. Obstoječi jeziki za modeliranje storitev se večinoma osredotočajo na storitve, povezane z informacijsko tehnologijo, ali spletne storitve. Večina obstoječih jezikov za modeliranje podjetij ima določen pomen za storitve za virtualna proizvodna podjetja in jih je mogoče ponovno uporabiti za modeliranje dela sistema storitev v tem kontekstu. Vendar je treba koncepte teh jezikov modeliranja povezati in preslikati med seboj, da se zajamejo vse zahteve glede modeliranja za načrtovanje storitvenih sistemov.
Standardiziran jezik za storitve modeliranja (SML) in z njim povezan meta-model sta pomembna za preprečevanje dragega in razdrobljenega razvoja na tem področju. Jezik za storitve modeliranja je osredotočen na modeliranje proizvodnih storitev, ki jih lahko podjetje razvije v podporo svojim izdelkom. V primerjavi s standardom ISO 19440-2 ima jezik za storitve modeliranja manj konstruktov in preprostejšo strukturo. Jezik za storitve modeliranja se lahko obravnava kot specializacija splošnejšega jezika za modeliranje, predlaganega v standardu ISO 19440-2 .
Modelirni konstrukti iz te tehnične specifikacije dopolnjujejo druge konstrukte ter podpirajo načrtovanje in izvajanje prihodnjih poslovnih sistemov, ki trgu zagotavljajo razširjene izdelke (izdelke + storitve).
Ta tehnična specifikacija določa:
a) arhitekturo načrtovanja storitev na podlagi modelov (MDSEA),
b) nabor konstruktov za jezik za storitve modeliranja za (virtualna) proizvodna
podjetja v okviru arhitekture načrtovanja storitev na podlagi modelov.
Na voljo je pet dodatkov, ki obravnavajo osnovne koncepte modeliranja storitev, jezike za modeliranje storitev, orodja in arhitekturo načrtovanja storitev na podlagi modelov ter industrijske pilotne projekte za potrditev jezika za storitve modeliranja (dodatka D in E).
Arhitektura načrtovanja storitev na podlagi modelov izhaja iz MDA [1] in MDI [2] s potrebnimi prilagoditvami in razširitvami, da zajema modeliranje storitve (in njenega sistema) v najsplošnejših oblikah.
Modelirni jezik, obravnavan v tej tehnični specifikaciji, je določen samo na ravni modeliranja poslovnih storitev (BSM) v okviru arhitekture načrtovanja storitev na podlagi modelov. Ta specifikacija se uporablja za proizvodna podjetja, vendar se lahko uporablja tudi za druge vrste podjetij. Namenjen je sistemskim inženirjem, informatikom in raziskovalcem, ki se ukvarjajo z razvojem in uvajanjem storitev, povezanih z izdelki, v virtualnih proizvodnih podjetjih in ekosistemih.
Konstrukti, določeni v tem dokumentu, so namenjeni tudi tistim poslovnim uporabnikom, ki se odločajo na podlagi poslovnih in ne tehničnih vprašanj. Zato so v primerjavi z ustreznicami (če obstajajo) v standardu ISO 19440:2 številne podrobnosti poenostavljene ali izpuščene.
Glavna dodana vrednost predlaganega jezika za storitve modeliranja bo trojna:
i) identifikacija jezikovnih konstruktov, potrebnih za opredelitev storitev, ki jih potrebuje poslovni uporabnik;
ii) integracija obstoječih konstruktov jezikov za modeliranje v enovit meta-model;
iii) opredelitev okvira arhitekture načrtovanja storitev na podlagi modelov, ki temelji na MDI/MDA in gosti jezik ter ponuja metode preoblikovanja modela med ravnmi modeliranja.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TP CEN/TR 17859:2022
01-september-2022
Jezik za storitve modeliranja
Service Modelling Language
Sprache zur Modellierung von Dienstleistungen
Langage de Modélisation de Service
Ta slovenski standard je istoveten z: CEN/TR 17859:2022
ICS:
35.060 Jeziki, ki se uporabljajo v Languages used in
informacijski tehniki in information technology
tehnologiji
SIST-TP CEN/TR 17859:2022 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TP CEN/TR 17859:2022
---------------------- Page: 2 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859
TECHNICAL REPORT
RAPPORT TECHNIQUE
July 2022
TECHNISCHER REPORT
ICS 35.240.50
English Version
Service Modelling Language
Langage de Modélisation de Service Sprache zur Modellierung von Dienstleistungen
This Technical Report was approved by CEN on 10 July 2022. It has been drawn up by the Technical Committee CEN/TC 310.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17859:2022 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms, definitions, abbreviated terms and construct labels . 6
3.1 Terms and definitions . 6
3.2 Abbreviated terms . 7
3.3 Construct labels . 7
4 Service Modelling Architecture and Language . 8
4.1 Overview . 8
4.2 Model Driven Service Engineering Architecture (MDSEA) . 8
4.3 Service modelling language (SML). 10
4.4 Actor construct representing an Organization’s or a Person’s role . 10
4.5 SML Use Case Example . 11
4.6 Service modelling templates. 15
4.6.1 Overview of constructs . 15
4.6.2 Templates and their usages . 16
4.6.3 Ordering of Templates . 17
4.6.4 Modalities of template attributes and class relationships. 17
5 SML Constructs. 17
5.1 Service . 17
5.2 Decision . 19
5.3 Functionality . 19
5.4 Value . 20
5.5 Performance Indicator . 21
5.6 Product . 21
5.7 Process . 22
5.8 Resource . 23
5.9 Service Level Agreement (SLA) . 24
5.10 Organization . 25
5.11 Person . 26
5.12 Service Vendor . 27
5.13 Customer . 27
5.14 User . 28
5.15 Service Provider . 29
5.16 Stakeholder . 30
Annex A (informative) Basic concepts of service modelling at BSM level . 31
Annex B (informative) Service modelling languages, tools and MDSEA . 34
Annex C (informative) Example of a service modelling at BSM level . 37
Annex D (informative) Industry Pilots to in the MSEE and PSYMBIOSYS Project . 41
Annex E (informative) From BSM to TIM and to TSM levels . 43
Bibliography . 45
2
---------------------- Page: 4 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
European foreword
This document (CEN/TR 17859:2022) has been prepared by Technical Committee CEN/TC 310
“Advanced automation technologies and their applications”, the secretariat of which is held by BSI.
During its preparation, contributions have been received from the European FP7 Integrated Project
Manufacturing Service Ecosystem (MSEE) and from the H2020 project PYMBIOSYS.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
3
---------------------- Page: 5 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
Introduction
It is generally considered that Manufacturing Enterprises will progressively migrate from traditional
product-centric business to product-based, service-oriented virtual enterprises and ecosystems. This is
a long and complex process that needs to be carefully assessed, prepared and planned. In particular, it
would be necessary for a company that decides to pursue a manufacturing servitization project, to know
clearly where it is (the current position) and where to go (the target position) so that strengths,
weaknesses and needed investments can be identified. Enterprise Modelling offers the basic concepts for
models, methods and tools to support this servitization process.
Benefits for the user result from a coordinated use of a common modelling language in the design and
operation of service system. This leads to considerable quality improvement in the design process and
cost reduction in the system operation.
A standardized Service Modelling Language (SML) is expected to foster the development of more
compatible products in enterprise service modelling and hence reduce problems in the interoperation of
such ICT products. SML will facilitate not only the modelling of services and service systems but will also
support the development of interoperable software among co-operating organizations.
In addition, the SML will have a positive impact on improving interoperability of model based, service-
oriented products, enabling European virtual factories and enterprises to adapt to the future internet
infrastructure.
The SML with its associated meta-model reduces costly and fragmented development in this domain. SML
focuses on modelling of manufacturing services that a company can develop to support its products.
The main added value of the proposed SML will be threefold:
i. Identification of the language constructs needed to define services needed by the business user.
ii. Integration of existing modelling languages constructs into one coherent meta-model.
iii. Definition of an MDSEA framework based on MDI/MDA to host the language and offer methods of
model transformation between the modelling levels.
Three categories of enterprises are considered for this SML Technical report:
a) SMEs or large companies active in model based servitization or in the process of designing business
models that include servitization aspects. The benefits of an SML standard are seen in a contribution
to ease enterprise interoperability between organisations without the need of strong
(re)engineering.
b) National/Regional projects or IT consultancies willing to integrate an SML standard in their
project/domain. This business model together with the MSEE Toolbox (as described in Annex D) will
enable the transfer of MSEE technology to other projects beyond those already existing. Four use
cases deploying the MSEE technology in SMEs of the industry sectors Machine Tools, Observation,
Furniture and Textile elaborated in the European PSYMBIOSYS project are presented in Annex D. The
use cases demonstrate the applicability and the benefits of (SML) standard-based solutions
c) Large industrial enterprises, who need business models aimed at offering IT assets to other large
industrial partners who are looking for standards-based solutions. A standard for language
modelling will ease enterprise interoperability between the partners of such enterprise network and
create measurable value.
This specification applies to manufacturing enterprises but can also apply to other classes of enterprises.
It is intended for use by system engineers, IT and research specialists who are concerned with developing
and deploying product related services in VMEs and Ecosystems. The constructs specified in this
4
---------------------- Page: 6 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
document are also intended to be used by those business users who are making decisions based on
business rather than technical concerns. For this reason, many of the details are simplified or omitted
compared to their equivalents (where they exist) in ISO 19440:2020.
Compared to ISO 19440:2020, SML employs fewer constructs and has a simpler structure. The SML can
be considered as a derivation (but not a formal specialization) of the more general modelling language
proposed in ISO 19440:2020. The modelling constructs of this proposed Technical Report are
complementary to those constructs and support the design and implementation of future enterprise
systems providing extended products (products + services) to the market.
NOTE Where SML constructs have the same name as those in IS19440, their meaning is the same, but their
attributes are simplified (and sometimes rephrased) to include only those relevant to service modelling.
This document specifies a Service Modelling Language defined according to a Model Driven Service
Engineering Architecture (MDSEA), to support the design and implementation of the service system in a
virtual manufacturing enterprise environment. It also specifies a set of constructs for a Service Modelling
Language.
Five annexes are provided addressing the basics concepts of service modelling, service modelling
languages, tools and MDSEA, an example of service modelling at BSM level, industrial pilots to validate
the SML and the progression between MDSEA levels.
The MDSEA is derived from [1] with necessary adaptation and extension to cover the modelling of service
(and its system) in its most general forms. The modelling language addressed in this document is
specified only at the Business Service Modelling (BSM) level of MDSEA.
5
---------------------- Page: 7 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
1 Scope
This document specifies constructs for modelling and specifying product-related service systems in
general business terms, recognising the service environment and the product lifecycle. The constructs
and their meta-model are consistent with the Model Driven Service Engineering Architecture (MDSEA).
They are intended for use by business users to address their business concerns and decision-making, and
by systems engineers and IT/researchers using a model-driven engineering approach in the design,
development and deployment of service systems in Virtual Manufacturing Enterprises (VMEs), business
ecosystems and other application areas.
2 Normative references
There are no normative references in this document.
3 Terms, definitions, abbreviated terms and construct labels
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1 Terms and definitions
3.1.1
construct-based modelling language
set of constructs and rules for valid groupings, which define the syntax of the modelling language
3.1.2
construct template
common structure that allows the identification and description of distinct modelling language
constructs and the assignment of their properties
3.1.3
extended product
product enriched with associated product related services
3.1.4
manufacturing service ecosystem
manufacturing system of products bundled with associated services
3.1.5
service modelling language
set of constructs and rules for valid groupings of enterprise services, which define the syntax of the
modelling language
3.1.6
servitization
process in a manufacturing enterprise to augment the value of products with services to better satisfy
customer needs and sustainability
[SOURCE: ISO 19440:2020, modified]
6
---------------------- Page: 8 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
3.2 Abbreviated terms
BSM Business System Modelling
GRAI Graphs with Results and Actions
ICT Information and Communication Technology
IT Information Technology
MDA Model Driven Architecture
MDI Model Driven Interoperability
MDSEA Model Driven Service Engineering Architecture
MSEE Manufacturing Service Ecosystem
SME Small- and/or Medium-size Enterprise
SML Service Modelling Language
TIM Technology Independent Modelling
TSM Technology Specific Modelling
UML Unified Modelling Language
VMA Virtual Manufacturing Enterprise
3.3 Construct labels
CUST Customer
DECN Decision
FUNC Functionality
ORG Organization
PERS Person
PI Performance Indicator
PR Product
PROC Process
RE Resource
SLA Service Level Agreement
SRV Service
STK Stakeholder
SVPR Service Provider
SVVN Service Vendor
USER User
VAL Value
7
---------------------- Page: 9 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
4 Service Modelling Architecture and Language
4.1 Overview
A modelling language is defined by a set of modelling constructs. Construct(s) are represented, as
illustrated in Figure 1, by a graphical representation, a template description and text. A template contains
a header part to identify a construct instance, and a body part to describe the particular instance with
descriptive and relationship properties. The proposed service modelling language is consistent with the
enterprise modelling language representation concepts defined in ISO 19440:2020 [3].
Figure 1 — Modelling language constituents (from ISO 19440:2020)
Using this template, this document specifies in Clause 5 a set of core Business Service Modelling
constructs to model Service System at BSM level (which is the first level of the MDSEA).
4.2 Model Driven Service Engineering Architecture (MDSEA)
A Model Driven Service Engineering Architecture (MDSEA) is elaborated on the basis of [1] and [2] to
support modelling of the three types of service system components (IT, human and physical means). This
MDSEA is considered as an adaptation and extension of MDA and MDI to the engineering of product
related services in virtual manufacturing enterprise environment.
As in MDA and MDI, the proposed MDSEA defines three abstraction levels as illustrated in Figure 2.
a) Business System Modelling (BSM), which specifies the models, at the global level, describing the
running of the enterprise or set of enterprises as well as the links between these enterprises.
8
---------------------- Page: 10 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
b) Technology Independent Modelling (TIM), which are the models at a more detailed level of
abstraction, identifying needed resources and the capability independent from the technology used
to implement the system.
c) Technology Specific Modelling (TSM) that combines the specification in the TIM model with details
that specify how the system uses a particular type of technology (such as for example IT platform,
physical means or organization with particular human profiles).
Figure 2 — MDSEA architecture
One result of Technology Specific Modelling is technical specifications of the three types of components
(resources) to use to build the required service system: IT type for information handling, Machine type
for material handling, and Human type for both information and material handling as well as the
organisation. One example is the servitization project carried out in 2018 by the Renault car
manufacturer in Paris Ville called Renault Mobility car service. In collaboration with Paris Municipality
and other service providers in a framework of a virtual enterprise, a network of automated Renault car
renting stations has been implemented in Paris. This service system is built with the three types of
components:
— car information management system implemented by IT type components (computers, software
applications and sensors, etc.);
— parking/Recharging stations implemented with Machine type components (robots, recharging
facilities, etc.); and
— car maintenance system (repairing, cleaning, etc.) implemented with Human type components
(cleaning workers, technicians, etc.).
The relationship between the MDSEA modelling levels (BSM, TIM, TSM) and the Service System lifecycle
phases (user-requirements, design and implementation) have been established. One of the important
9
---------------------- Page: 11 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
innovations in MDSEA is to define the integration between domain components at the BSM level in order
to ensure that these integration aspects will be addressed at the other levels.
4.3 Service modelling language (SML)
The concepts identified in 4.2 are adopted as modelling constructs to represent a Service System at BSM
level. Figure 3 is an overview illustrating the Service concept and relationships with other concepts. This
figure is elaborated to show all SML constructs in Figure 5. In Clause 5, each construct is further described
by a template, and text to explain specific concerns and details.
Figure 3 — Modelling constructs and relationships at BSM level
The kind of service considered in this document is that relating to a manufactured product. To develop
such a service, it is necessary to build a Service System. Various entities are involved in such a
development, ranging from the intended Customer who will consume the service to the Service Vendors
and the Service Providers. Other entities such as technical centres, research centres and banks could be
involved. All these other entities are called Stakeholders and all of them may express their specific
concerns. A Service is used by Customers. A Service System provides functions that are utilities to fulfil
customer’s needs. The provided Service can be evaluated by a set of Performance Indicators, which are
related to a set of decisions that control the Service System, i.e., are related to a set of objectives and
decision variables.
4.4 Actor construct representing an Organization’s or a Person’s role
Persons and Organizations can have several roles and a role can generally be undertaken by either an
Organization or a Person. Construct relationships (and their underlying class diagrams) need to cover
this requirement without proliferating relationship links between Person/Organization and each role
that they can possibly assume. This is achieved by using an abstract ‘Actor’ class model as illustrated in
Figure 4.
10
---------------------- Page: 12 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
Figure 4 — Organization, Person and Actor roles
NOTE 1 Attributes which concern a particular role of an Organization or Person, e.g., usage of a service, have now
migrated to attributes of the Actor specialization, e.g., to the User construct. All Actor role specializations then have
the associated attributes and . Whether a role is undertaken by an Organization or Person
is determined by the Identifier and Name of the Actor specialization.
NOTE 2 Figure 4 is a view on a UML model and since the and attributes are inherited
from Actor they do not need to be shown explicitly as attributes for the Actor specializations. They are shown here
(and in Figures 7 and 8) for consistency with the templates and completeness (since Actor is abstract and so not
included in Clause 5).
4.5 SML Use Case Example
NOTE This clause is an extract adapted with permission from [9].
In today’s service development, it is usual to have combination of services provided by different provides
working together. The use case considered covers different kinds of services, approaches and solutions
in the context of Industry 4.0, Internet of Things, Cyber Physical Systems, Cloud Computing and
integration/federation of services of enterprise applications such as SCM, ERP, MES.
A central component of this use case is a matching service, which provides opportunities to create
partnerships like value or supply chains but also purchasing pools and other networks within the hyper-
connected ecosystem. A matching service running in a cloud infrastructure and using other services has
been selected as one focus for the use case. The complete use case scenario considers cloud
infrastructures, a matching service, a service to provide partner information to different service
providers, a pump producer and a product service provider for water supply as well as a list of part
suppliers (as illustrated in Figure 5).
11
---------------------- Page: 13 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
Figure 5 — Use case scenario for service modelling
The pump producer produces a pump and offers this pump to the customer as part of a water supply
service. An example of a possible customer could be a state water supply authority. This implies several
services to produce the pump and to deliver the service with several contracts with suppliers of parts
and services.
A matching service helps to find the suppliers but also customer networks. The matching service uses a
profile service that provides information about potential business partners. However, these two services
run on cloud service infrastructures. The cloud service provides also the infrastructure to deliver the IT
components of the water supply service such as monitoring the amount of water, potential maintenance,
breakdowns, replacements as well as payment. Maintenance also invokes the matching service
concerning potential material and local maintenance service providers. This creates a far-reaching
network of services and dependencies on a legal, business and technical level.
This use case illustrates the challenges and dynamic arising in the design of a service infrastructure. The
current model is in development and includes the following main elements in terms of instantiated SML
constructs.
This TR defines “Actor” as an abstract class related to persons or organisation and incorporates service
providers, vendors, stakeholders and other roles, for example:
— Pump producer and water supply provider;
— Matching service provider;
— Cloud infrastructure provider;
— Provider of partner profile services;
— Suppliers (parts and maintenance services).
The service construct covers all kinds of services in the use case such as IT services and product as a
service and services around a product:
— Services;
— Water supply service;
— Cloud infrastructure service;
12
---------------------- Page: 14 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
— Matching service;
— Portfolio service;
— Maintenance service.
In the current work, UML is used to express the elements of the use case via instances of SML constructs.
Each SML construct has a related template. Table 1 illustrates an example of such template for the
matching service construct.
Figure 6 shows the part of the use case concerned with the cloud service and the matching service as a
UML model. Each class corresponds to an SML template instance, The example provides an indication of
how to interrelate the service level agreements like the information technology infrastructure library
(ITIL) between providers, sellers, users, services and products in the context of cloud infrastructures.
NOTE Figure 6 is adapted from Figure 2 in [9].
Figure 6 — Use case partial model
The matching service requires the cloud service to provide its functionality. Therefore, the matching
service provider is at the same time a customer of the agreement (SLA) between the cloud service
provider and the matching service provider. The model also shows a further SLA between the matching
service provider and the pump producer using the matching service. Both SLAs are decoupled in terms
of contracting but the integrated view illustrates that they related because if the cloud service disappears
also the SLA of the matching service is affected. The construct of SLAs in the SML is a placeholder for
various regulations such as data ownership, data security and data privacy.
In terms of modelling, the matching services and the cloud service are modelled separately and then
orchestrated in one model thanks to common SML modelling. The example related to the SLAs is just one
usage for the model. SML provides a structured method for modelling a service that provides a better
understanding of the service components. It also helps to include the required elements into the service
blueprint.
13
---------------------- Page: 15 ----------------------
SIST-TP CEN/TR 17859:2022
CEN/TR 17859:2022 (E)
Table 1 provides a template example for the matching service and each of its properties.
Table 1 — Example of Service construct template
Header
Construct label SRV
Identifier SRV_0001
Name Matching service
Body
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.