IEC SRD 63459:2026

IEC SRD 63459 ®
Edition 1.0 2026-06
SYSTEMS REFERENCE
DELIVERABLE
Template for smart manufacturing use cases

ICS 25.040.01  ISBN 978-2-8327-1332-7

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a
publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.

Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviated terms . 8
3.1 Terms and definitions . 8
3.2 Abbreviated terms. 9
4 Distribution of SM UCMR specification using the template . 9
5 Saving use cases to UCMR using the template . 10
6 Requirements for the template for SM use cases . 10
6.1 Requirements from other SDOs . 10
6.2 Functional requirements . 12
7 Template for SM use cases . 13
7.1 Structure of the template for SM use cases . 13
7.1.1 UC identification . 13
7.1.2 UC scope and objectives . 14
7.1.3 UC relationships list . 14
7.1.4 UC narrative . 14
7.1.5 Use case precondition list . 15
7.1.6 Scenarios and step by step analysis . 15
7.1.7 UC information objects list . 16
7.1.8 UC requirements list . 16
7.2 Guideline for filling the template for SM use cases . 16
7.2.1 General. 16
7.2.2 UC identification . 16
7.2.3 UC scope and objectives . 17
7.2.4 UC relationships list . 20
7.2.5 UC narrative . 20
7.2.6 Use case precondition list . 21
7.2.7 Scenarios and step by step analysis . 22
7.2.8 UC information objects list . 23
7.2.9 UC requirements list . 24
7.3 Requirement for the template items for SM use cases . 25
Annex A (informative) Sample filled-in SM UC template using IEC TR 63283-2:2022 . 26
A.1 General . 26
A.2 Use case . 26
A.2.1 UC identification . 26
A.2.2 UC scope and objectives . 26
A.2.3 UC narrative . 27
A.2.4 Scenarios and step by step analysis . 30
A.2.5 UC requirements list . 30
A.3 Comparison conclusion . 31
Annex B (informative) Example of SM use cases . 32
B.1 General . 32
B.2 Use case . 32
B.2.1 UC identification . 32
B.2.2 UC scope and objectives . 32
B.2.3 UC narrative . 33
B.2.4 Scenarios and step by step analysis . 35
B.2.5 UC requirements list . 36
Bibliography . 37

Figure 1 – Development process of SM use case template . 6
Figure 2 – Use of UCMR . 7
Figure 3 – Derivation flow for the specification of UCMR through the design of the
template for SM use cases . 9
Figure 4 – Saving use cases to UCMR using the template for SM use cases . 10
Figure A.1 – Business context of "Flexible scheduling and resource allocation". 28
Figure A.2 – Technical perspective of "Flexible scheduling and resource allocation" . 28
Figure B.1 – Business context of "Flexible and smart production" . 34
Figure B.2 – Technical perspective of "Flexible and smart production" . 34

Table 1 – Comparison of use case templates . 11
Table 2 – Requirement for the template items for SM use cases . 25
Table A.1 – Comparison of the template items for SM use cases . 31

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Template for smart manufacturing use cases

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC SRD 63459 has been prepared by IEC systems committee SyC SM: Smart Manufacturing.
It is Systems Reference Deliverable.
The text of this Systems Reference Deliverable is based on the following documents:
Draft Report on voting
SyCSM/127/DTS SyCSM/136/RVDTS
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Systems Reference Deliverable is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
INTRODUCTION
The collection, storage and distribution of use cases are intended to show the characteristics
of smart manufacturing (SM), including but not limited to the following:
– vertical integration of networked manufacturing systems within enterprises;
– horizontal integration crossing enterprises;
– end-to-end integration of the whole value chain;
– short time-to-market of the new product;
– enhanced engineering and operational efficiency;
– openness for integration;
– self-optimization;
– new business model;
– resource optimization and cost savings;
– flexibility in production;
– sustainability.
In addition, managing a collection of use cases has the following goals:
– to organize use cases according to different aspects such as life cycle, hierarchy;
– to make access to a required use case easy;
– to assist in deepening the understanding of the use cases.
Use cases in SM are developed by many organizations, such as standardization bodies and
consortia. With the wide spread of manufacturing Internet of Things (IoT), it is expected that
many use cases will continue to be created.
The benefits from use case collection include the following aspects from different perspectives:
– to show how SM related technologies can be used to express business needs and to capture
user requirements;
– to derive standardization requirements and improve the capability to use standards;
– to gather experts who are interested in SM;
– to support and promote SyC SM work;
– to help people to understand standards by related use cases.
The benefits for users of identified or analysed use case collections include the following:
– to easily access target use cases using keys corresponding to user concerns or interests;
– to effectively develop the application with use cases;
– establishment of a fundamental platform (repository) for expanding the usage of SM use
cases.
In addition, the benefits for IEC itself are as follows:
– to draw attention to the usage of use cases related to SM;
– to provide the potential data query service.
The initial task of the previous SyC SM AHG 2 was the identification of SM use cases which
were already available in the IEC and ISO technical work.
It is difficult to compare or contrast catalogues of use cases from different standards
development organizations (SDOs) since they are developed from separate sources with
different templates for different purposes. It will be useful if they can be tied to a unified
framework within the SM landscape.
Therefore, to facilitate the collection of smart manufacturing use cases, SyC SM WG 1 was set
up as a subsequent group carrying over the outcomes from the SyC SM AHG 2. It was requested
to collaborate with TCs and SCs, ISO/SMCC, other SDOs and external organizations.
The SM use case template is based on SM reference architecture (refer IEC 63339:2024),
taxonomy (refer ISO/IEC TR 63306-1:2020), terminology (refer IEC TR 63283-1:2022), and
current use cases. The development of the SM use case template follows the V-model shown
in Figure 1. The SM use case template is analysed and designed based on the requirement
from SDG users, IEC SyC SM WG 3, industry users, etc. Then, it will be verified by WG 1 using
use case data, and validated by related SDOs and industry users.

Figure 1 – Development process of SM use case template
It is important to encourage SDOs and industry users to compile the SM use case based on the
SM use case template described in 7.1. A guideline for drafting the use cases is provided in
7.2. Use cases from various sources will be brought into the proposed use case management
repository (UCMR) for ease of access and reference by standards developers, and industry
users of SyC SM applications, shown in Figure 2.
Figure 2 – Use of UCMR
IEC Guide 125 on application of the use case (UC) methodology is under development. It is
based on IEC 62559-2, which gives an overview of the individual parts of the IEC 62559 series,
provides the background and basics for the use case approach defined therein (like terms or
use case types), and introduces processes for collaborative use case collection within IEC.
IEC Guide 125 will be the basis for a common use case repository, used to gather use cases
within IEC on a common collaborative platform. The SM use case template has the same
structuring methodology as IEC Guide 125 and it can be one of the profiles for different domains.

1 Scope
This document specifies the template for smart manufacturing use cases. It is developed for
easier storage, search, comparison, and retrieval of use cases from different SDOs and others
by having a unified template of use cases.
The storage of SM use cases in IEC UCMR follows the template requirements in this document.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology 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.1
use case
specification of a set of actions performed by a system, which yields an observable result that
is, typically, of value for one or more actors or other stakeholders of the system
[SOURCE: ISO/IEC 19505-2:2012, 16.3.6]
3.1.2
use case template
form which allows the structured description of a use case in predefined fields
[SOURCE: SG-CG/M490/E:2012-12; 3.2]
3.1.3
user
entity which makes use of the use case template or the services and/or facilities of a database
based on the use case template
EXAMPLE SM system developer, SM standard developer and SM application developer.
3.1.4
repository
place where information like use cases can be stored
Note 1 to entry: The information is usually stored as a database (refer to use case repository).
[SOURCE: SG-CG/M490/E:2012-12; 3.12, modified – Supplementary information has been
moved to a note to entry.]
3.2 Abbreviated terms
AAL active assisted living
ISO/SMCC Smart Manufacturing Coordinating Committee at ISO
SDO standards development organization
SM smart manufacturing
SyC systems committee
UCMR use case management repository

4 Distribution of SM UCMR specification using the template
This Clause 4 describes relationship among SDOs in the process of design of the template for
SM use cases, and the relationship between the template, the specification for implementation
of SM UCMR and the UCMR. Figure 3 shows derivation flow for the specification of UCMR
through the design of the template. The content in the blue circle is the task of
IEC SyC SM/WG 1.
The main structure of the template for SM use cases is based on IEC 62559-2, which is
transferred to IEC Guide 125, and adopts items that reflect the characteristics of SM. The
process of development of the template will include referring to the reference architecture of
IEC TC 65/JWG 21, studying the typical SM use cases and templates from other SDOs, and
utilizing the terminology from IEC SyC SM/WG 2 and taxonomy of OF1. The use case templates
from other domains, such as IEC TC 8, SyC AAL, SyC Smart Cities, ISO/IEC JTC 1, IEEE, will
be referred to as well.
One of the results from WG 1 is the specification for implementation of SM use case
management repository (UCMR). The template for SM use cases will provide the requirements
for this UCMR. The specification will provide the design of UCMR as one input from SM domain.

Figure 3 – Derivation flow for the specification of UCMR
through the design of the template for SM use cases
5 Saving use cases to UCMR using the template
This Clause 5 describes the process of how the template for SM use cases is used by SDOs.
Figure 4 shows data flow using the template for SM use cases.
Based on the collection scheme to be provided by WG 1, SM use case data from different SDOs,
such as IEC TC 65/WG 23, ISO/TC 184/WG 6 and ISO/SMCC, will take the template for SM
use cases developed by WG 1 to be saved in UCMR. In this way, users can easily search,
compare, and learn the use cases by the key factors of this template.

Figure 4 – Saving use cases to UCMR using the template for SM use cases
6 Requirements for the template for SM use cases
6.1 Requirements from other SDOs
The main structure of IEC 62559-2, is a general guide of use case template for different domains.
It is important to specify the items of the use case template to reflect the aspects of SM, such
as life-cycle management, manufacturing intelligence, etc. Since SM is concerned with system
engineering, the logical relationships between actors should be analysed. The items in the SM
use case template will be determined and clarified in this document to help users to complete
the template and so the data can be stored in the repository.
The templates used in IEC TR 63283-2, IEC TS 63134 and ISO/IEC TR 24030 are derived from
IEC 62559-2, but are different because of specific considerations from each domain. The
comparison of these templates is shown in Table 1.
From the comparison in Table 1, the following requirements can be derived.
a) The use case template will include two parts, which are common items and special
requirements for its domain.
1) Common items can include:
i) description of the use case: name of use case or ID, version management, narrative;
ii) diagrams of use case to depict the use case;
iii) technical details: actors, references;
iv) requirements for standardization.
2) Special requirements for SM use cases can include:
i) level of criticality;
ii) application domain;
iii) technical aspect: data security and privacy, conformity aspects, system's threats and
vulnerabilities, etc.
Table 1 – Comparison of use case templates
IEC 62559-2:2015 IEC TR 63283-2:2022 IEC TS 63134:2020 ISO/IEC TR 24030:2024
1 Description of the use
objective Level of criticality ID
case
Name of use case
AAL function and service
layer
1.1 Name of use case overview Use case name
AAL system component
composition
Application domain
1.2 Version management business context Version management Deployment model
Status
Basic information to use
case Scope of use case
1.3 Scope and objectives of
use case
Scope and objectives of Objective(s)
use case
1.4 Narrative of use case Narrative of use case Narrative
Actors: people,
components, systems,
integrated systems,
applications and
1.5 Key performance
organizations
indicators (KPI)
Issues: legal contracts,
legal regulations,
constraints and other
1.6 Use case conditions
1.7 Further information to
Relation with other known
the use case for
use cases
classification/mapping
1.8 General remarks General remarks
Drawing or diagrams
depicting the use case
2 Diagrams of use case
(sequence moved here)
Data security and privacy
Conformity aspects
3 Technical details Technical perspective
(common international
assessment methodology/
critical requirements)
Stakeholders
User requirements and
3.1 Actors Interaction of roles interactions with other
Stakeholders' assets,
actors
values
Referenced standards
and/or standardization
3.2 References
committees (sequence
moved here)
IEC 62559-2:2015 IEC TR 63283-2:2022 IEC TS 63134:2020 ISO/IEC TR 24030:2024
System's threats and
vulnerabilities
4 Step by step analysis of
Key performance indicators
use case
(KPIs)
Features of use case
4.1 Overview of scenarios
4.2 Steps – Scenarios
Expected change and
5 Information exchanged
impact
Standardization
opportunities/requirements
Requirements for
6 Requirements (optional)
standardization Challenges and issues
Societal concerns
7 Common terms and
definitions
8 Custom information
(optional)
b) The template used in IEC 62559-2 is difficult to reflect specific requirements of different
domains such as SM domain. Therefore, the template used in different TC/SCs takes the
general frame of IEC 62559-2 and modifies the detailed template as needed.
c) Most of these templates are designed to more easily collect use cases and further derive
their analysis results. The requirements for future storage and analysis are not their focus.
d) The use case methodology in SM domain is targeted to provide clear guidance on how to
apply this methodology in the context of standardization. It can be the basis for the
development of SM use case, but further work on defining specific items for SM use case is
needed. This document will be a profile of the use case methodology.
There are also requirements from SDOs, tool developers, industry users, etc.
e) The items in the template should be clarified to help the users to fill in the SM use case
template.
f) The purpose of the SM use case template is to facilitate comparison, storage, and search
of use cases from different SDOs.
6.2 Functional requirements
The use case can be used to identify system requirements and actors that make up a reference
architecture of complex system of systems that serves as a basis for standardization. The use
case methodology is already widely used within IEC as well as other standardization bodies,
such as smart grids, smart cities, smart homes and buildings, active assisted living (AAL)
systems, etc. It shows the usage of different technologies in different scenarios and makes sure
that existing work is taken into account.
The development of complex systems requires people from different domains to be involved.
Therefore, use cases can serve as a common denominator for communication, standards
development and as a basis for interoperability tests. In addition to that, a collection of use
cases around several systems can allow SDOs to identify gaps in their standardization portfolio.
Identified gaps can serve as the basis for suggesting new work item proposals.
The use case methodology leads to a collaborative platform between different TCs or SDOs
and defines the status of use cases, which are collected and published in the UCMR shown in
Figure 4. Benefits of use cases include the following.
– In system engineering projects, they provide a tool to gather requirements and information
in a standardized and structured form.
– They build up a common understanding between different stakeholders, committees or even
organizations.
– They manage the complexity of standards development in complex systems based on
different roles in the use case.
– They support the standards development in the design and definition phase, such as
interoperability, terminology, safety, and security.
– They encourage the development of interoperability.
– They provide guidance for standards users since use cases can be combined with reference
architectures and help users to find the gaps of the current standard system.
To enhance these benefits of use cases, the functional requirements for the SM use case
template include the following.
– The template shall be machine readable and understandable. Since one of the most
important purposes of the template is to support the UCMR of related use cases, it shall
comply with UCMR store requirement.
– The template shall be clear and easily filled in. The template will be used by different SDOs
to contribute the UCMR. It must be easy to understand and fill in.
– The template shall include the basic information, such as unique ID, version management,
categories, technical details, requirements for standardization, etc.
– The template shall include important key items reflecting SM characteristics. Given that SM
is one application domain, the use case template will be improved according to the specific
requirements of SM, which are represented as these SM key items.
7 Template for SM use cases
7.1 Structure of the template for SM use cases
7.1.1 UC identification
UC name:
UC local ID (localUcID):
UC version history:
UC version number UC version date UC author's names Changes UC edition status

7.1.2 UC scope and objectives
UC area/ domain(s)/ zone(s):
UC scope:
UC objectives:
UC business rationale justification(s):
UC role business rationale description business rationale justification
brVoicingUCRole businessRationale.description brJustification

UC role (ucRole(*)):
UC role name UC parent role UC role contextualization
ucRole.name parentRole ucRoleContextualization

UC KPIs (ucKPI(*)):
KPI ID KPI name KPI description Targeted KPI performance
ucKPI.mRID ucKPI.name ucKPI.description targetedKPIPerformance

7.1.3 UC relationships list
7.1.3.1 UC relationships overview
Text or drawing introducing the relationships overview of the use case.
7.1.3.2 UC relationships
UC relationship type referred UC UC relationship comment

7.1.4 UC narrative
7.1.4.1 Short description
Text or drawing introducing the short description of the use case.
7.1.4.2 Long description
Text or drawing introducing the long description of the use case.
7.1.4.3 UC references
UC reference name UC reference UC reference UC reference UC reference URI
status type originator
7.1.5 Use case precondition list
7.1.5.1 UC assumptions
assumption
No.
ucAssumption
7.1.5.2 UC prerequisites
No. prerequisite
ucPrerequisite
7.1.6 Scenarios and step by step analysis
7.1.6.1 UC scenarios overview
Text or drawing introducing the scenarios and their relationships.
7.1.6.2 UC scenarios list
UC scenario index UC scenario name UC scenario description

7.1.6.3 UC scenario detailed description
UC scenario number:
UC scenario name:
UC scenario description:
UC scenario assumptions:
No. UC scenario assumption
UC scenario prerequisites:
No. UC scenario prerequisite
UC scenario resulting system status:
UC scenario steps:
7.1.7 UC information objects list
Name Namespace Description Registration status Context of use

7.1.8 UC requirements list
(Details are not needed if the requirement is already registered in the requirement library.)
requirement ID requirement name requirement description

7.2 Guideline for filling the template for SM use cases
7.2.1 General
Each part of the use case template is presented with content descriptions. Some additional
information about this content is presented if necessary. Annex A gives a sample filled-in SM
UC template using IEC TR 63283-2:2022, and Annex B gives an example of SM use cases from
industry.
7.2.2 UC identification
UC name:
A UC name (name attribute inherited from IdentifiedObject) is typically a short name, which
should be unique within the domain and which refers to the activity of the use case itself using
"Verb + description".
Step index
step trigger
step name
step
description
step service
information
sender
information
receiver
exchanged
information
descriptions
exchanged
information
names
scenario step
requirements
list
UC local ID (localUcID):
The identifier of the UC local ID (or UCsLibrary) shall be unique. The following coding sequence
should be used: SM-UC-YYYY-MM-XXXX, where SM-UC will be mandatory, YYYY-MM shows
the issue date of this use case, and XXXX is the sequence number.
UC version history:
UC version number UC version date UC author's names Changes UC edition status

The UC version history reflects the history list of the most recent versions of the use case.
Version number: Sequential number to identify the version of the document.
Version date: Date of latest update of the version, in the format YYYY-MM-DD.
Author's name: This field is used to document who has provided the current version. It can be
a person, organization, such as TC or WG. May be multiple.
Changes: The differences with respect to the previous version. Multiple changes are separated
with paragraphs.
UC edition status: Current status of this use case, such as published, in progress, etc.
7.2.3 UC scope and objectives
Here the background or motivation of this use case is described.
UC area/ domain(s)/ zone(s):
Use cases can be used in various areas (e.g. smart manufacturing). Within these areas,
different domains are used to define or determine a more specific subgrouping. Zones can
describe additionally zones within an automation system or a reference architecture. The author
can select one or more domains and zones, comma separated, as it is usual that use cases are
crossing different domains and zones.
For the smart manufacturing system, according to the reference model in IEC PAS 63088:2017,
RAMI 4.0 is taken as an example here, and the following domains and zones are suggested:
Area: Smart manufacturing
Domains:
– Product
– Field device
– Control device
– Station
– Work centre
– Enterprise
– Connected world
Zones:
– Type: development, maintenance/usage
– Instance: production, maintenance/usage
UC Scope:
Define the specific domain of application of the UC (refining the UC domain attribute) and
possibly its limits (what is not in the scope). It describes where the UC is intended to be
executed.
UC objectives:
Express the main of objectives of the use case, in term of value created for the main role(s)
interacting through the UC. It describes what the UC intends to perform or provide or bring.
UC business rationale justification(s):
Element justifying for each business rationale, in which respects the execution of the UC helps
reaching a given business rationale of the project. It describes the "why" of the UC. May be
multiple.
UC role business rationale description business rationale justification
brVoicingUCRole businessRationale.description brJustification

UC role:
Roles which are involved in the use case are listed and described. These can for instance
include people, systems, applications, data, devices, etc. May be multiple.
UC role name UC parent role UC role contextualization
ucRole.name parentRole ucRoleContextualization

role name, parent role:
Within one repository, roles from an existing roles list (roles library) should be used. In this
case, type and description do not have to be filled in again. In the use case repository, a roles
list is integrated. Missing actors can be defined and suggested for the overall roles' list. The
aim of the list is to avoid duplications. For classification, search function and further services
of a use case repository, it will be very useful to provide predefined actors.
EXAMPLE IEC TR 63283-2:2022 provides four parent roles: business roles, human roles, technical roles acting as
object only, and technical roles acting as subject or object. Different roles related to SM are listed as follows.
Business roles: purchaser, manufacturing company, non-physical asset supplier, software application supplier,
broker, computing and connectivity infrastructure operator, collaboration platform operator, decentralized energy
network operator, service provider, secure identity provider, standardization body, community, etc.
Human roles: employee, customer, product developer, production system architect, system integrator, production
coordinator, production resource operator, service and maintenance provider, software developer, data scientist,
software integrator, software orchestrator, IT administrator, cyber security architect, cyber security coordinator, etc.
Technical roles acting as object only: product, asset, product series, planned production system, product order,
production order, library, information about non-physical asset, information about physical asset, simulation model
of non-physical asset, simulation model of physical asset, energy price, software application, interface, legal contract,
revenue model, standard, CERT telegram, external information, solution board, challenge board, etc.
Technical roles acting as subject or object: development organization, production system, production resource,
device, decentralized energy network, design for manufacturing, request/order management, asset management,
production management, production execution, condition prediction, machine learning, prediction model execution,
pattern recognition, rules engine, improvement indicators, value-based service, software application store,
collaboration enablement, customizing enablement, secure identity management, identity and capability
management, engineering tool, exploration tool, computing infrastructure, computing and connectivity infrastructure,
production resource integration layer, virtual reality platform, presentation logic, operation infrastructure, etc.
UC author(s) can suggest new roles to add to the roles library, if the role was defined in
conformance with this template.
The names of the roles as listed in this table shall be consistently used throughout the document
(specifically in the roles definitions table, scenario conditions, preconditions and assumptions
and scenarios). If not using an automatic selection box in the repository, writers shall check
their descriptions for common capitalization, small differences in usage, abbreviations versus
whole words (e.g. AGV and elsewhere Automated Guided Vehicle), etc.
role contextualization:
Additional information on the role activity in the context of this use case.
UC KPIs(ucKPI(*)):
A KPI is a key performance indicator, associated with the objectives of the UC, aiming at
providing quantifiable measure of performance resulting from the execution of the UC. May be
multiple.
KPI ID KPI name KPI description Targeted KPI performance
ucKPI.mRID ucKPI.name ucKPI.description targetedKPIPerformance

ID: Unique identifier for the key performance indicator (KPI).
Name: Short name that describes the KPI which is shown in above table.
Description:
The description specifies the KPI and the calculation of these targets. According to
IEC TR 63283-1, KPIs of SM can include but are not limited to the following aspects:
– Agility
– Efficiency
– Safety
– Security
– Sustainability
Targeted KPI performance: Includes specific targets in relation to one of the objectives of the
use case.
EXAMPLE Reduce the overall equipment effectiveness of production by 5 %.
7.2.4 UC relationships list
7.2.4.1 General
This element includes all elements specifying the relationships set between this use case and
other ones. It also proposes an overview of these relationships.
7.2.4.2 UC relationships overview
Text or drawing introducing the relationships of the use case.
7.2.4.3 UC relationships
Expression of a relationship between this UC and other UCs. May be multiple.
UC relationship type referred UC UC relationship comment

UC relationship type: Type of relationship, such as "includes", "is part of", "is a specialization
of", "is a generalization of", "extends".
referred UC: The UC related to this UC.
UC relationship comment: Additional information for this UC relationship.
7.2.5 UC narrative
7.2.5.1 General
The UC narrative element contains all elements supporting the textual description of this use
case, including the references.
7.2.5.2 Short description
Text or drawing introducing the short description of the use case.
Short text intended to explicitly summarize the main purpose and content of the UC, i.e. should
show how the expected value is created for the main role. Such description is intended to
summarize the main idea as a service for the reader who is searching for a use case or looking
for an overview.
This short description should have not more than 150 words.
7.2.5.3 Long description
Text or drawing introducing the long description of the use case.
Provides a complete narrative of the use case from a user's point of view, describing what
occurs when, why, with what expectation, and under what conditions. This narrative should be
written in plain text so that non-domain experts can understand it.
The length of the long description can range from a few sentences to a few pages, depending
on the complexity and/or newness of the use case. This description often helps the domain
expert to reflect about the requirements for the use case before getting into the details in the
next sections of the use case t
...