Functional Viewpoint ofApplication Scenario
Value-Based Service
DISCUSSION PAPER

In collaboration with

Functional Viewpoint of Application Scenario ValueBased Service
1.

Introduction ............................................................................................................................................ 3
1.1 Background ......................................................................................................................................... 3
1.2 Objectives ........................................................................................................................................... 3

2.

Additional Information ............................................................................................................................ 5
2.1 Introduction to IIRA ............................................................................................................................. 5
2.2 Introduction to Application Scenario Value-Based Service................................................................. 6
2.3 Overview of Usage Viewpoint of Application Scenario Value-Based Service .................................... 6

3.

Functional Viewpoint of Application Scenario Value-Based Service ..................................................... 8
3.1 Introduction ......................................................................................................................................... 8
3.2 Elements of IIoT system...................................................................................................................... 9
3.3 Actors ................................................................................................................................................ 11
3.4 Scenarios .......................................................................................................................................... 14
3.5 Information exchanged...................................................................................................................... 29
3.6 Requirements .................................................................................................................................... 31

Annex A. ...................................................................................................................................................... 39
A.1 Relationship between steps and functional requirements (matrix version) ...................................... 39
A.2 Relationship between steps and information exchanged (matrix version) ....................................... 40
A.3 Relationship between information requirements and information exchanged (matrix version) ........ 41
A.4 Relationship between both functional/information requirements and functional domains and (matrix
version).................................................................................................................................................... 42
References .................................................................................................................................................. 43
Authors and Guests .................................................................................................................................... 43-2-

1. Introduction
1.1 BackgroundIn the context of Industrie 4.0 and Connected Industries for some time now, the recognition is aware that– in addition to a technologically driven bottom-up approach – one must complement the topic of digitization in manufacturing industries also by a top-down driven approach. In such a top-down approach thestarting point are possible future business scenarios, from which more technically use case descriptions
are derived. These use cases are the basis to derive new products, solutions, and services as well as
standardization requirements.
It is recognized that the application scenarios of Plattform Industrie 4.0, see [1], provide a representative
overview of the new business opportunities in the context of the digitization in manufacturing industries.
Therefore, need for action from a methodological point of view is less at the level of the business scenarios, but to now concretize these business scenarios from a technical point of view.
The separate document "Usage Viewpoint of Application Scenario Value-Based Service" developed by
VDI/VDE-GMA, Robot Revolution Initiative and Standardization Council Industrie 4.0 see [2], shows someusage views of that particular scenario as examples of the concretization. In order to express how technically a system for such usage cases can be designed, even still in an abstract level, and to identify what
technology and/or standards can be used, one more breaking down analysis with functional views is required.

1.2 Objectives
Our goal is to describe on a technical level in the form of use cases the interplay of actors with a technicalsystem. We have set the scope of our consideration according to the application scenario of Plattform
Industrie 4.0 "Value-Based Service", see [3], and to usage activities described in "Usage Viewpoint ofApplication Scenario Value-Based Service" [2].

-3-The first target audience of this document is system designers who want to draw system architecture,function to work and information to share in the system, and necessary interactions between them for
Value-Based Service application. Use case descriptions in Clause 3 in this document can be references
to those engineers as a design guide, although described steps are not in implementation level.
The second target audience is standard developers who support building, operation and maintenance ofsuch system by providing enhanced and/or newly developed standards. Standard developers may wantto promote currently available standards to Value-Based Service business players when their roles are
implemented in same scenarios as use cases. Standard developers can also find some requirements for
new standardization work out of these use cases, once use case scenarios, or part of the scenarios,
seem to be supported by standards which do not exist now.
The Germany-Japan cooperation team works on this requirement analysis together with IEC TC65 Smart
Manufacturing standardization activities.

-4-

2. Additional Information
2.1 Introduction to IIRA
The Industrial Internet Reference Architecture (IIRA), see [4], provides guidance and assistance in thedevelopment, documentation, communication, and deployment of IIoT systems. The corresponding document is primarily for IIoT system architects, which can use the IIRA systematically as an architectural
template to define their unique IIoT system requirements and design concrete architectures to address
them.
At the core of the IIRA are the so called IIRA viewpoints, see Figure 1:

Figure 1: Industrial Internet Architecture Viewpoints (according to [4])

-5-







Business viewpoint – attends to identification of stakeholders and their business vision, values, andobjectives in establishing an IIoT system in its business and regulatory context.
Usage viewpoint – addresses expected system usage. It is typically represented as sequences ofactivities involving human or logical users that deliver intended functionality to ultimately achieve thefundamental system capabilities.
Functional viewpoint – focuses on the functional components in an IIoT system, their structure andinterrelation, the interfaces and interactions between them, and the relationships and interactions of
the system with external elements in the environment, to support the usages and activities of theoverall system.
Implementation viewpoint – deals with the technologies needed to implement functional components,
their communication schemes, and their lifecycle procedures. These elements are coordinated by activities (usage viewpoint) and support the system capabilities (business viewpoint).

There are cause and effect dependencies between the viewpoints. Typically a viewpoint guides the design of the viewpoint below and a viewpoint serves for validation of the viewpoint above.
We will use this framework for our description.

2.2 Introduction to Application Scenario Value-Based Service
Today typically a product provider delivers a product to a customer and does not have any feedback fromthe usage of his product by the customer. The application scenario Value-Based Service is based on theinnovation hypothesis that in the future delivered products will be connected to a so-called service platform, data from the usage of the product by the customer will be fed to the service platform, and based on
the usage data a service provider can offer (data-driven) value-added services to the customer. Figure 2
illustrates the participating stakeholders, the underlying value network, and the new information flow fromthe customer to the service platform as the basis for new data-driven services.

Figure 2: Value-network of application scenario Value-Based Service (Plattform Industrie 4.0)

2.3 Overview of Usage Viewpoint of Application Scenario Value-Based Service
Since the discussions are ongoing we will give a short introduction to the business viewpoint of the application scenario Value-Based Service to keep this document consistent and self explanatory. Figure 3
illustrates how we apply the application scenario Value-Based Service as shown in Figure 2. The productunder consideration is a machine. We distinguish two different business stakeholders indicated by the twodifferent colors: the supplier of the machine (green) and the operator of the machine (orange).

-6-Figure 3: Usage of application scenario Value-Based Service (according to [3])The application scenario introduces two additional business roles: the operator of the service platform
and the provider of data-driven services. Now it has to be discussed who will implement these additional
business roles in the future. It would be possible that the existing business stakeholders, namely the supplier of the machine or the operator of the machine, implement these roles, but it is also conceivable that
other business stakeholders will do this.
As described in [5] a variety of different business setups is possible. For each business setup there areother value-networks and value propositions. Figure 4 illustrates some of the possible business setups. In
this figure same colors indicate that the respective roles are implemented by the same business stakeholder.

Figure 4: Examples for variety of different business setups (based on [5])-7-

3. Functional Viewpoint of Application Scenario Value-Based Service
3.1 Introduction
In Clause 3, the functional viewpoint of application scenario Value-Based Service is introduced. From thisviewpoint, the functional requirements of an IIoT system designed for the application scenario are analyzed regarding each element of the IIoT system, and interactions of actors with the IIoT system are also
analyzed in terms of information exchanged.
Figure 5 shows correspondences between the concepts used in the functional viewpoint and relevant
concepts appeared in the references such as the usage viewpoint and functional viewpoint of IIRA [4], theusage viewpoint of application scenario Value-Based Service [2], and IEC 62559-2 [6]. How the concepts
used in this functional viewpoint are related to (and comparable with) the concepts appeared in the references is summarized below, although each concept is explained in detail later.


Elements of IIoT system: Elements of IIoT system are crucial in realizing communication and interaction among actors. Similar to the usage viewpoint of application scenario Value-Based Service, themeaning of IIoT system elements are adopted from the IIRA. They are similar to system actors in IEC
62559-2. Their functional requirements are specified in the functional viewpoint presented in thisclause.
Actors: Following the definition in IEC 62559-2, actors are entities that communicate and interact.
Actors in the functional viewpoint here are more specifically business actors (e.g., people) and distinguished from system actors (e.g., devices and applications). Actors in the functional viewpoint are also similar to roles in the usage viewpoint of application scenario Value-Based Service. Roles in theusage viewpoint are given in specific scenarios and assumed by parties, which are strongly depending on the business setup and the internal organization of a company involved.

-8-







Scenarios: A scenario describes sequences of activities/processes about interactions among actors.
Scenarios in the functional viewpoint mostly correspond to the activities in the usage viewpoint of application scenario Value-Based Service, but some scenarios are extended so that the scenarios cannaturally derive some functional requirements of an IIoT system discussed among the authors. The
description format of scenarios in the functional viewpoint partly follows the use case template in IEC
62559-2. In particular, requirements regarding functions of the IIoT system and interactions of actors
with the IIoT system in terms of information exchanged, are analyzed following the template. In relation to the usage viewpoint and functional viewpoint of IIRA, mapping from scenarios to functional requirements in the functional viewpoint corresponds to mapping from activities to functional components in the IIRA. (Implementation map to implementation components is not considered in the functional viewpoint presented here.)
Information exchanged: Since application scenario Value-Based Service is concerned with how information obtained from assets in the use stage is utilized for value creation for users and operatorsof an IIoT system, information exchanged among the actors interacting with the IIoT system is explicitly described. The description format of information exchanged follows the information exchanged in
the use case template of ICE 62559-2.
Requirements: Functional requirements of an IIoT system in context of application scenario ValueBased Service are described regarding each element of the IIoT system. The description format of afunctional requirement follows the use case template in IEC 62559-2. These requirements are further
mapped to the functional domains introduced in the functional viewpoint of IIRA. Furthermore, somecrucial properties of information exchanged (see below) are organized as information requirements.
UV-IIRAElement of IIoT system

UV-VBS-

Role (assumed by Party)

Element of IIoT system

FV-VBS (This document)-

Role (assumed by Party)

Element of IIoT system

IEC 62559-2
-

Actor

System actor
Business actor

Activity-

Activity-

Scenario-

Scenario

Task

-

Task

-

Step

-

Step

Functional component map

Service-

Service

Information producer-

Information producer

FV IIRA

Information receiver-

Information receiver

Functional domains

Information exchanged-

Information exchanged

Requirement-

Requirement

Outputs of the analysis of FV-VBS

Figure 5: The concepts used in the functional viewpoint analyzed in this document and their relations to part of theusage viewpoint of IIRA (UV-IIRA), the functional viewpoint of IIRA (FV-IIRA), the usage viewpoint of application
scenario Value-Based Service (UV-VBS), and the use case template in IEC 62559-2.

In summary, as sub-clause 3.5 and 3.6 in this document show, the main outputs of the analysis of thefunctional viewpoint are the functional requirements mapped on the functional viewpoint of IIRA and information exchanged using the use case template of IEC 62559-2.

3.2 Elements of IIoT system
Functional requirements of an IIoT system, which are identified and analyzed in the document, are organized regarding each element of the IIoT system. The elements of an IIoT system are consistent withthose introduced in the usage viewpoints of application scenario Value-Based Service, namely, connected asset, service platform, and application (See. Figure 6). Selection of these elements does not indicate
the architecture of an IIoT system for application scenario Value-Based Service. Various architecturessatisfying the functional requirements can be proposed. Nevertheless, the organization of functional re--9-quirements with these three elements can be mapped to the three tier IIoT system architecture describedin the implementation viewpoint of IIRA [4]. The architecture is composed of the edge tear (i.e., edge
nodes such as machines and gateways), the platform tear managing data flow and control flows, and theenterprise tear implementing domain specific applications for end-users of the IIoT system.

Figure 6:.Elements of an IIoT System for Usage Viewpoint of application scenario Value-Based Service (according to[2])

In practice, there are a number of instances of these elements of an IIoT system (i.e., various types ofconnected assets and applications with diverse functionality). The description of three elements describedhere is type (class) description rather than instance description (Service platform can be regarded as asingleton).
Each element of an IIoT system is specified by name and description. It is briefly explained below following the description in the usage viewpoint of application scenario Value-Based Service, and function requirements of each element identified and analyzed in this document are summarized later.

Element name

Description

Connected asset

An integral part of a production system (synonymously factory or
plant). The production system has been designed to manufacture (orproduce) a product. In addition to this role the production system
may be connected to a service platform in order to improve the usage of the asset based on the analysis of usage data of the asset.

Service platform

The center of the logical structure is a so-called service platformorganized in three layers:Connectivity layer: This layer offers the capabilities to connect
assets distributed all over the world and to collect usage datafrom the connected assets. We assume that the connection ofassets requires similar capabilities as the integration of assets
into a technological process, e.g. the integration of machines into
a production system.
Infrastructure layer: This layer offers the capabilities to manage
and analyze data collected from the connected assets and provides the necessary computing execution capabilities, e.g. cloudinfrastructure (public, private, or on-premise). The capabilities for
managing and analyzing the data will be offered in form of function blocks to be used by applications. The infrastructure layer
offers development capabilities to create such function blocks
and to embed function blocks developed outside of the service
platform. The creation of such function blocks requires in particular programming and data analytics skills. In addition, the infra-- 10 -



Application

structure layer will offer capabilities to configure applications.
Application layer: This layer comprises the various applications.
These applications can be configured based on the capabilities
provided by the infrastructure layer; furthermore, the applications
can be executed based on the execution and computing capabilities of the infrastructure layer. The applications can make useof the data collected from the assets and the data analysis capabilities offered by the function blocks provided by the infrastructure layer. We assume that no specific programming skills
are necessary to engineer these applications, i.e. the applications can be created by configuration of the function blocks offered in libraries and it is not necessary to program new function
blocks.

The basis from a technical perspective in order to offer data-driven
services as described in the business viewpoint.

3.3 Actors
Actors are entities that communicate and interact. Actors are specified by name and description.
Actor name: It is a unique identifier of each actor. Actor name is also consistently used across all
scenarios in this document.
Actor description: Description of each actor specifying concrete roles, and required qualifications andskills.

It is preferred that actors are commonly used in diverse use cases, as long as their assumed roles are
similar. Nevertheless, new actors can be introduced in describing a use case when an actor with appropriate role for the use case are not found in the list of existing actors. (In IEC 62559-2, actors are maintained across diverse use cases in the form of an actor list referred to by diverse use cases.)
Actors can be classified into groups in order to provide a better overview of actors.
Grouping: Classification of actors
Group description: Description of each group

The actors used in the functional viewpoint are those used in the usage viewpoint of application scenario
Value-Based Service. Similar to the description in the usage viewpoint, the actors are classified into threegroups (the term group is used in IEC 62559-2, but the term cluster is used in the usage viewpoint). Actors in the first group are concerned with the usage of assets (asset is an element (class) of IIoT system
explained later). They include operator of an asset, production manager, supplier of an asset, and asset
integrator. Actors in the second group are related to the infrastructure layer of the service platform andconcerned with the usage of the service platform. They include developer of a function block, operator of
the service platform, and computing resource. Actors in the third group are related to the application.
Here, asset usage advisor is an actor belonging to the third group.

ActorsGrouping

Group description

Asset usagerelated roles

Actors concerned with usage of assets.

Actor name

Actor description- 11 -

Operator
an assetofThis is the operator of an asset, typically a machine or the entire plant. He uses
the asset according to a given usage profile and schedule provided by the production manager, monitors the actual process-data related to the asset, guarantees
quality assurance with respect to the manufactured product, he executes service
and maintenance tasks related to the asset and needs support in case of anomalies (e.g. unplanned events, trends, etc.).

Production
manager (ofthe manufacturing company)

He manages the overall manufacturing process (planning and scheduling of the
production), he plans and initiates maintenance activities to keep the assets up todate, he designs and initiates major asset reconfiguration activities triggered bybusiness considerations (e.g. changing the capacity of the plant because of market demands, offering other products to the market, etc.), and finally he decides on
and initiates the implementation of recommendations provided by the role “asset
usage advisor”.

Supplier of an
asset

He is the supplier of the physical asset and is an expert of the (technical) capabilities of the asset.

Asset integrator

He is able to connect an asset to a service platform using the capabilities offeredby the connectivity layer of the service platform. The connection is developed
based on the specific requirements delivered by some stakeholder, mainly by the
production manager. As already mentioned in the description of the connectivity
layer of the service platform we assume that the connection of assets re-quires
similar capabilities as the integration of assets into a technological process, e.g.
the integration of machines into a production system.

Grouping

Group description

Platformrelated roles

Actors related to the infrastructure layer of the service platform and concernedwith the usage of the service platform

Actor name

Actor description

Developer ofafunctionblock

He is able to design, implement, test, and improve a function block using the development capabilities offered by the infrastructure layer of the service platform.
He has to combine data analytics skills (analyzing the usage data of the connected assets) and domain knowledge (typically delivered by the supplier and operatorof an asset and/or the asset usage advisor) with computer sciences and modelingskills to develop algorithms and integrate the algorithms into a function block.

Operatoroftheservice
platform

He manages and operates all capabilities provided by a service platform. This
includes support and consulting activities for the usage of the different layers of aservice platform.

Computingresource

A computer used to execute applications in an automatic way in order to provide
the necessary computing execution capabilities of the service platform.

Grouping

Group description

Applicationspecific roles

Actors specific to applications

Actor name

Actor description

Asset

This is an expert role, who transforms the insights of the technical analysis of theusage- 12 -

advisor

usage data of connected assets into some recommendations offered as a service
to the operator of the asset. He is involved based on schedule or spontaneously
on request. A combination of various expertise is requested, but especially assessment skills are necessary. He has to turn information about an asset into actionable recommendations for the operator of an asset including explaining thebenefits and risks of his recommendations. He will be supported by appropriate
applications. These applications will be configured by the expert himself using thelibraries of function blocks and configuration tools offered by the infrastructure
layer of the service platform.

- 13 -

3.4 Scenarios
Scenario consists of several steps indicating interactions (or works) of actors with elements of IIoT system.
Each step represents the finest-grained description level of interaction. The concept and description levelof scenario and step are consistent with activity and task described in the usage viewpoint of application
scenario Value-Based Service as explained below. Functional requirements of an IIoT system, whoseusage is described in the usage viewpoint, are clarified through describing and analyzing scenarios.
A scenario is described with Scenario ID and short description. A scenario is described in detail in thesteps belonging to each scenario.


Scenario ID: It is a unique identifier given to each scenario. In this document, Scenario ID is definedby SCN**, where ** is two decimal digits. The number does not specify causality or order of execution.
Scenario name: It summarizes the interactions of actors with the IIoT system occurred to in this scenario. Scenario name starts with a verb.

The description of scenarios is based on the description of the activities in the usage viewpoint of application scenario Value-Based Service. The correspondence between these descriptions is shown below. The
scenarios from SCN01 to SCN05 belong to the setup (configuration) stage, and the scenarios from
SCN06 to SCN13 belong to the use (operation and maintenance) stage as introduced in the usage viewpoint. In order to describe some functional requirements of an IIoT system discussed in the author team,
the following modifications have been made. .
Activity “Collection and analysis of usage data of an asset” has been divided to SCN06 and SCN07
A scenario SCN13 has been introduced.
SCN11 and SCN12 have been extended.

Activity name appeared in the usage
viewpoint of Value-Based Service [2]ScenarioID

Scenario name

Connection of an asset

SCN01

Connection of an asset

Reconfiguration of an asset

SCN02

Reconfiguration of an asset

Configuration of an application

SCN03

Configuration of an application

Development of a library of function
blocksSCN04

Development of a library of function
blocksDevelopment of a service platform

SCN05

Development of a service platform

Collection and analysis of usage data ofan asset

SCN06

Collection of usage data of an asset

SCN07

Analysis of usage data of an asset

Recording additional data on spontaneous request

SCN08

Recording additional data on spontaneous request

Operation and maintenance of a service
platform

SCN09

Operation and maintenance of a service platform

Generation of recommendations resp.
requests for action

SCN10

Generation of recommendations resp.
requests for action

Execution of recommendation resp. request for action

SCN11

Execution of recommendation resp.
request for action

Benchmarking of assets

SCN12

Benchmarking of assets

SCN13

Continuous update of an asset model
for improving usage data analysis ofassets- 14 -

The contents of each step in a scenario are Step ID, Name, Description, Actors, Requirements, Information producer, Information receiver, and Information exchanged. The contents Name, Description,
Requirements, Information producer, Information receiver and Information exchanged correspond areused in the use case template of IEC 62559-2. The content Actors correspond to Roles in each task ofactivities in the usage viewpoint of application scenario Value-Based Service.













Step ID: It is a unique identifier given to each step. In this document, Step ID is defined by SCN**-x,
where SCN** is the Scenario ID and x is a decimal digit. Unless specified, the digit indicates the natural order of execution of steps in a scenario. The corresponding content in the use case template of
IEC 62559-2 is Step No.
Name: Label that would appear in, for instance, a diagram. Unique label should be assigned to eachstep in all scenarios considered.
Description: This describes what action takes place in this step. The focus should be on the behaviorof actors and elements of IIoT system, and interactions and information exchanged among them.
Actors: Name of the actors that interact with other actors (or elements of IIoT system) in this step.
The overall role and other characteristics of each actor should be mentioned in the actor list described in Sub-clause 3.3.
Requirement IDs: IDs of the functional requirements of elements of IIoT system (functional requirements are described in Sub-clause 3.6). Multiple requirements can be given in each step (comma
separated in case of multiple requirements). Requirements can be empty in some steps, because interactions among the actors are described in these steps and they do not refer to elements of IIoT
system and thus their functional requirements.
Service: This column identifies the characteristics of the information originated, transferred, or processed in each step in terms of the type of Service. The types of service are introduced in IEC 625592 as shown below [6], which is partly derived from IEC 61968-100:2013, 6.2.2 (Service can be empty
in case information exchanged is not observed in the corresponding step).
 CREATE means that an information object is to be created at the Information producer.
 GET (this is the default value if none is populated) means that the Information receiver requests information from the Information Producer (default).
 CHANGE means that information is to be updated. The information producer updates the Information receiver’s information.
 EXECUTE is used when a complex transaction is being conveyed using a service, which potentially contains more than one verb.
 REPORT is used to represent transferral of unsolicited information or asynchronous information flows. Producer provides information to the Receiver.
Information producer: The value of this column in each step is one of the actors or elements of IIoT
system. The role of information producer is specified by the type of service (see above). It can be
empty in case Service in the step is not specified.
Information receiver: See the description in Information producer.
Information exchanged IDs: This briefly describes information to be exchanged between the two actors – information producer and information receiver. Information exchanged is specified by its ID.
The detail of information exchanged is described in Sub-clause 3.5. It is allowed to list several information exchanged in one step, comma separated. The value can be empty in case Service in thestep is empty.

- 15 -

SCN01 – Connection of an asset
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
01-1

Define data
to be transferredDefine data to be transferred to service platform(including transfer protocol) based on the requirements of the production manager

asset integrator &supplier of asset

FRca-1,
FRca-2

CRE
ATE

Asset
integrator
(*1)

Asset

InfEx-2,
InfEx-3

SCN
01-2

Connectasset
toservice
platform

Connect asset to service platform (including
providing configuration capabilities to manage avirtual representation of the asset over its lifecycle in the service platform)

asset integrator

FRca-3,FRca-4GET

AssetService
platform

InfEx-1,
InfEx-3

SCN
01-3

Provideaccess tousage data

Provide access to usage data of asset

operator of service platform

FRca-2,
FRsp-2CRE
ATE

Operatorof service
platform

Service
platform

InfEx-3

SCN
01-4

Validateconnection

Validate connection of asset

asset integrator &operator of service platform &supplier of asset

FRsp-1

GET

Service
platform
(*2)

Asset
integrator

InfEx-3

SCN
01-5

Acceptconnection

Acceptance of connection of an asset

asset integrator &production manager

(*3)

GET

Asset
integrator

Production
manager(*4)

InfEx-3(*1) Asset integrator receives the requirement from production manager, and transforms the requirement to asset-specific data definition (with help of supplierof asset) in advance.
(*2) Asset communicates with service platform and then asset integrator checks the results of communication (i.e., whether communication is successful or
failed).
(*3) In some steps, information is exchanged between actors without involvement of the IIoT system. Function requirements of the IIoT system are not specified in such steps.
(*4) Production manager confirms and accepts the connection of the asset with service platform based on the requirement.

- 16 -

SCN02– Reconfiguration of an asset
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
02-1

Identify
asset model in service
platform

Identify the virtual representation of the asset in
the service platform to be reconfigured

Asset integrator(or operator of
asset)

FRca-5,
FRsp-4

GET

Service
platform

Asset
integrator(*1)

InfEx-3

SCN
02-2

Reconfigure asset

Reconfigure the asset, i.e. execute necessary
work to be done with the asset, this includes
work in the physical world as well as in the digital world, but no activities related to the service
platform

Asset integrator(or operator of
asset)

FRca-6,
FRca-7

CHA
NGE

Asset
integrator
(*1)

Asset

InfEx-1

SCN
02-3

Updatereconfigured asset
model

Update the virtual representation of the asset in
the service platform according to the reconfiguration of the asset according to SCN02-2 (inorder to be able to deliver the data-driven services)

Asset integrator(or operator of
asset)

FRca-8,FRca-9,FRsp-3,
FRsp-4

CHA
NGE

Asset
integrator(*1)

Service
platform

InfEx-1

SCN
02-4

Acknowled
ge reconfiguration

Acknowledge the reconfiguration of the asset

Production manager (or operatorof asset)

GET

Asset
integrator(*1)

Production
manager(*1)

InfEx-3(*1) According to the type of reconfiguration, operator of asset may be able to perform and acknowledge reconfiguration.

- 17 -

SCN03 – Configuration of an application
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
03-1

Designapplication

Design a concept for an application based on
the business requirements (traditional designtask)

asset usage advisor

FRca-1,
FRsp-6 (*1)

CRE
ATE
(*2)

Asset
usage
advisor-InfEx-7,
InfEx-8,

SCN
03-2

Configureapplication

Configure the application using the configuration
capabilities offered by the infrastructure layer ofthe service platform

asset usage advisor

FRsp-4,

CHA
NGE

Asset
usage
advisorService
platform

InfEx-9,SCN
03-3

Deploy andtest application

Deploy and test the application using the capabilities provided by the service platform

asset usage advisor

FRsp-4,
FRsp-7

GET

Service
platform

Asset
usage
advisorInfEx-9

SCN
03-4

Improveapplication

Continuous improvement of the application
based on the gained experiences and evolving
business requirements (traditional improvementtask)

asset usage advisor

FRsp-4,FRapp-1

CHA
NGE

Asset
usage
advisorService
platform

InfEx-7,
InfEx-8(*1) If an application is designed for specific service platform or asset, the specifications of the service platform or asset are necessary in the design process
and they should be available to asset usage advisor.
(*2) A design process can be interpreted following the definition of a service type CREATE as “information exchanged (i.e., design concept of an applicationin this case) is created at (the place of) asset usage advisor”. Same interpretation is used in SCN04-1 and SCN05-01- 18 -

SCN04 – Development of a library of function blocks
Step
ID.

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
04-1

DesignfunctionblocksDesign a concept for a library of function blocks
based on the business requirements and technological opportunities (traditional design task)

developeroffunction block

FRapp-2,
FRsp-8CRE
ATE

Developeroffunctionblock-

InfEx-11,
InfEx-12SCN
04-2

Developand embed
functionblocksDevelop the function blocks (or embed function
blocks developed outside of the service platform) using the development capabilities offeredby the infrastructure layer of the service platform

developeroffunction block

FRsp-4,
FRsp-9CHA
NGE

Developeroffunction
block

Service
platform

InfEx-13

SCN
04-3

Deploy andtest function blocks

Deploy and test the library of function blocks
based on the capabilities provided by the service plat-form

developeroffunction block

FRsp-4,
FRsp-9GET

Service
platform

Developeroffunctionblock

InfEx-13

SCN
04-4

ImprovefunctionblocksContinuous improvement of the library of function blocks based on the gained experiences,
new technological opportunities, and evolving
business requirements (traditional improvementtask)

developeroffunction block

FRsp-4,
FRsp-10CHA
NGE

Developeroffunction
block

Service
platform

InfEx-11,
InfEx-12,- 19 -

SCN05 – Development of a service platform
Step
ID

Name

Description

ActorsSCN
05-1

Designservice
platform

Design a concept for a service platform basedon the business requirements and technologicalopportunities (traditional design task)

Operator of service platform

SCN
05-2

Developand implement service
platform

Develop the layers of the service platform andimplement all required capabilities

Operator of service platform

SCN
05-3

Deploy andtest service
platform

Deploy and test the service platform

SCN
05-4

Improve
service
platformContinuous improvement of the service platform
based on the gained experiences, new technological opportunities, and evolving business
requirements (traditional improvement task)

Service

Information
producer

CRE
ATE

Operatorof service
platform

FRsp-11CRE
ATE

Operatorof service
platform

Service
platform

InfEx-16

Operator of service platform

FRsp-11

GET

Service
platform

Operatorof service
platform

InfEx-16

Operator of service platform

FRsp-11,
FRsp-12CHA
NGE

Operatorof service
platform

Service
platform

InfEx-14,
InfEx-15- 20 -

Requirement IDs

Information
receiver

Informationexchanged
IDs
InfEx-14,
InfEx-15,

SCN06 – Collection of usage data of an asset
Step
No.

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
06-1

Collect
usage databy asset

Asset monitors and records its own state (including results of operations performed by operator of asset)

Asset

FRca-6,
FRca-10,
FRca-11

GET
(*1)

Asset

Asset

InfEx-4

SCN
06-2

Collect
usage databy operatorof asset

Operator of asset records and observes thedata of asset (without assuming specific application)

Asset andOperator of asset

FRca-12

GET

Asset

Operatorof asset

InfEx-4,
InfEx-5

SCN
06-3

Collect
usage databy service
platform

Asset upload its data to service platform (byscheduled execution of the associated applications such as a data-collection algorithm)

Asset, Service
platform andComputing resource

FRca-3,FRca-13,
FRsp-13,
FRsp-14,
FRsp-15,
FRapp-3 ,FRapp-4,
FRapp-5
FRapp-6

GET

Asset

Service
platform

InfEx-4(*1) Collection of usage data of asset by itself is interpreted following the definition of a service type GET that “Asset (as the information receiver) requests
information from Asset (as the information producer)(*2) This step assumes that some assets may not have function to collect its usage data and transfer the data.

- 21 -

SCN07 – Analysis of usage data of an asset
Step
ID

Name

Description

ActorsSCN
07-1

Analyzeusage databy asset

Asset analyzes its usage data by itself

SCN
07-2

Generatean
alarm
by asset

Asset generates special notification in a casethat some threshold is passed (with monitoring
and alarm generation applications installed on
asset)

Operator of asset
or asset usage
advisorSCN
07-3

Analyzeusage databy operatorof asset

Operator of asset analyzes the usage data of anasset locally

Operator of asset

SCN
07-4

Requestanalysis ofusage dataof asset

Operator of asset requests asset usage advisor
to analyze asset

Operator of asset& asset usage
advisorSCN
07-5

Generatean
alarmby service
platform

Service platform generates an alarm in the casethat some threshold is passed (with monitoring
and alarm generation applications installed on
platform)

Computingresource & asset
usage advisor

SCN
07-6

Analyzeusage databy
asset
usage advisor

Asset usage advisor analyzes the usage data ofan asset on service platform

Asset usage advisor & computing resources- 22 -

Requirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

EXECU
TE

Asset

FRca-11,
FRca-14,FRapp-7,

REPOR
T

Asset

FRca-6,
FRca-11,
FRca-14EXECU
TE

Operatorof asset

REPOR
T

Operatorof asset

Asset
usage
advisorInfEx-23

FRsp-5,
FRsp-13,
FRsp-15,
FRapp-7,

REPOR
TService
platform

Asset
usage
advisorInfEx-10,
InfEx-18

FRsp-4,
FRsp-13,
FRapp-6

EXECU
TE

Asset
usage
advisorInfEx-4

Operatorof assetor asset
usage
advisorInfEx-6,
InfEx-10,

InfEx-4

InfEx-4

SCN08 – Recording additional data on spontaneous request
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
08-1

Requestadditional
data

Request for specific data

Asset usage advisor

REPOR
T

Asset
usage
advisorOperatorof asset

InfEx-23

SCN
08-2

Select sensors

Select suitable sensor(s)Operator of asset

FRca-1

SCN
08-3

Connect
sensors

Connect sensor(s) to asset

Operator of asset

FRca-5SCN
08-4

Recordadditional
data

Record required data

Computingsourcere-FRca-10

GET

Asset
(*1)

Computing resource

InfEx-4

SCN
08-5

Provideadditional
data

Provide recorded data to asset usage advisor

Computingsourcere-FRsp-15

GET

Computing resource

Asset
usage
advisorInfEx-4

SCN
08-6

Disconnect
sensors

Disconnect sensor(s) from asset

Operator of asset

FRca-5SCN
08-7

Analyze
additionaldatabyasset usage advisor

Analyze the additional data (this may require theconfiguration of appropriate applications)

Asset usage advisor

FRsp-4,
FRsp-13,
FRapp-6

EXECU
TE

Asset
usage
advisor(*1) Additional sensor collects usage data of asset, and the data is eventually sent to computing resource connected with service platform.

- 23 -InfEx-4

SCN09 – Operation and maintenance of a service platform
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
09-1

Measureperformance ofservice
platform

Perform measures to guarantee requested service level of service platform

Operator of service platform

FRsp-13,
FRsp-16

GET

Service
platform

Operatorof service
platform

InfEx-17- 24 -

SCN10 – Generation of recommendations resp. requests for action
Step
ID

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
10-1

Generate
recommendation

Transforming specific events into a recommendation for resp. request for action by the operator of the asset

Computingresource & asset
usage advisor

FRsp-5,
FRapp-5,
FRapp-7

REPOR
T

Computing resource

Asset
usage
advisorInfEx-18

SCN
10-2

Providerecommendation

Provision of recommendation to production
manager or operator of the asset

Asset usage advisor

FRapp-3
(*2)

GET

Asset
usage
advisor

Production
manager(*1)

InfEx-24

SCN
10-3

Discuss
recommendation

Discussion of recommendation with production
manager or operator of the asset

Asset usage advisor & production manager or
operator of asset

FRapp-3(*2)

GET

Production
manager
(*1)

Asset
usage
advisorInfEx-25

SCN
10-4

Do
accounting ofrecommendation
service

Accounting of delivered service

Asset usage advisor & production manager

GET

Production
manager

Asset
usage
advisorInfEx-29(*1) Operator of asset may be able to receive and discuss recommendation(*2) Application run on service platform visualizes recommendations- 25 -

SCN11 – Execution of recommendation resp. request for action
Step
ID.

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
11-1

Schedulingexecutionof actions

Rescheduling of actions of relevant assets following given recommendation (e.g., production
scheduling and maintenance scheduling)

Production manager

FRca-13,
FRsp-17,
FRsp-18

CHA
NGE

Production
manager

Asset
(*1)

InfEx-26

SCN
11-2

Request of
informationfor execution of actions

Request of information regarding execution ofactions of relevant assets following the given
recommendation (e.g., maintenance instruction).

Operator of asset

FRca-13,

GET

Asset

Operatorof asset(*2)

InfEx-27

SCN
11-3

Executionof actions

Execution of actions of relevant assets following
the given recommendation (e.g., isolation andmaintenance of asset)

Operator of asset

FRca-7EXECU
TEOperatorof asset

Asset

(*3)

SCN
11-4

Acknowledgment ofexecutionof actions

Acknowledge execution with respect to asset
usage advisor

Production manager or operatorof asset

FRapp-3

GET

Production
manager

Asset
usage
adviser

InfEx-28(*1) Execution schedules of actions of assets may be rescheduled via service platform.(*2) Requested information may be obtained via service platform.(*3)
Execution of actions in this step mainly causes physical effects rather than information exchanged.

- 26 -

SCN12 – Benchmarking of assets
Step
ID

Name

Description

ActorsSCN
12-1

Provide benchmarking application

Providing an appropriate benchmarking application based on management plan (e.g., application for computing KPIs of facilities, which isused for successive improvement [kaizen])

Asset usage
advisorSCN
12-2

Compute actual
performance

Transforming the specific information about theusage of an asset into a general performanceindicator of the asset

Computingresource

SCN
12-3

Display actualand target performances

Provision of the concrete actual and target performance indicator value of an asset to the production manager; this concrete value is related
to the (anonymous) distribution of the values ofall other comparable connected assets

Computingresource

SCN
12-4

Display performance distribution

Displaying the computed information via an
appropriate dashboard delivered by the benchmarking application

Computingresource
production
manager

SCN
12-5

Recommend
improvement
plan

Recommendation of improvement plans (i.e.,kaizen processes) to achieve the target basedon displayed information.

SCN
12-6

Update projectplan
followingrecommendations

SCN
12-7

RecordlearnedlessonService

Information
producer

Information
receiver

Informationexchanged
IDs

CRE
ATE

Asset
usage
advisorComputing resource

InfEx-7

FRca-16,
FRapp-5

EXECU
TE

Computing resource

FRsp-4,FRapp-3,
FRapp-5

GET

Computing resource

Production
manager

InfEx-19,
InfEx-20

FRca-17,
FRapp-3,
FRapp-5

GET

Computing resource

Production
manager

InfEx-21

Production
manager

EXECU
TE

Asset
usage
advisor

Production
manager

InfEx-20,
InfEx-22

Updating and execution of the installation plan
based on recommendations (e.g., putting kaizen
process into practice)

Production
manager

EXECU
TE

Production
manager

Asset

InfEx-26

Recording lesson learned from benchmark inservice platform for knowledge sharing anditerative improvement of performance

Production
manager

EXECU
TE

Production
manager

Service
platform

InfEx-22

GET

Production
manager

Asset
usage
advisorInfEx-29

SCN
12-8

Make payment Making payment to the data-driven benchmark- Production
for benchmark- ing service provider
managering service
SCN13 – Continuous update of asset models for improving usage data analysis of assets- 27 -

Requirequirement IDs&

FRsp-14InfEx-19

Step
ID.

Name

Description

ActorsRequirement IDs

Service

Information
producer

Information
receiver

Informationexchanged
IDs

SCN
13-1

Developmentof
updatedasset modelContinuous update of the digital representationof an asset throughout the life cycle (without
assuming specific applications)

Supplier of asset

FRca-9,FRca-15CRE
ATE

Supplierof asset-

InfEx-1,
InfEx-2,

SCN
13-2

Deliver
updatedasset model

Delivery of the updated digital representation ofan asset

Supplier of asset& Asset integrator (or operator of
asset)

FRca-4GET

Supplierof asset

Asset
integrator(*1)

InfEx-1

SCN
13-3

Reconfigure updated
asset
model

Reconfiguration of the updated digital representation of an asset

Asset integrator(or operator of
asset)

FRca-6,
FRca-7

CHA
NGE

Asset
integrator
(*1)

Asset

InfEx-1

SCN
13-4

Uploadupdatedasset model

Upload the updated digital representation ofasset on the service platform

Asset integrator(or operator of
asset)

FRca-8,FRca-9,FRsp-3,
FRsp-4

CHA
NGE

Asset
integrator(*1)

Service
platform

InfEx-1(*1) Similar to SCN02, operator of asset may be able to perform the role of asset integrator- 28 -

3.5 Information exchanged
The detailed description of information exchanged, which is identified in analyzing scenarios, is shown
here. The format of information exchanged follows the format of Information Exchanged in the use case
template in IEC 62559-2, which organizes information exchanged as a table with the following columns.






Information exchanged ID: It is a unique identifier given to each information exchanged. In this document, information exchanged ID is defined by InfEx-Number, where Number is a number (e.g., InfEx1, InfEx-2, …)
Name of information exchanged: A name of the information exchanged starting with a noun. Similar
to information exchanged ID, names of information exchanged should be unique. It would appear invisualization scheme, for instance, a diagram.
Description of information exchanged: A detailed description of this information exchanged.
Requirement IDs: IDs of information requirements referring to information exchanged, and listed in
Sub-clause 3.6. Multiple requirements can be given in each information exchanged (comma separated in case of multiple requirements).
Step IDs: …

Informationexchanged
ID

Name ofmationinfor-InfEx-1

Asset model

InfEx-2

Specifications
asset

Requirement
IDs

Step IDs

The virtual representation of asset
situated in various locations in IIoT
systemIR-2

SCN01-2,
SCN02-2,
SCN02-3,
SCN13-1,
SCN13-2,
SCN13-3,
SCN13-4ofSpecifications of asset regardinge.g., interface, local data storage,
local computational power

IR-3

SCN01-1,
SCN13-1

InfEx-3

Setup informationof asset

Information exchanged during
setup between asset and service
platform or actor (e.g., identifier ofasset, updated configuration ofasset)

IR-1, IR-4

SCN01-1,
SCN01-2,
SCN01-3,
SCN01-4,
SCN01-5,
SCN02-1,
SCN02-4

InfEx-4

Usage
asset

of

Usage data of asset (e.g., numberof production, down time, energy
consumption, and evaluation criteria of its performance) that includes effects of operations on
asset performed by various actors

IR-2

SCN06-1,
SCN06-2,
SCN06-3,
SCN07-1,
SCN07-3,
SCN07-6,
SCN08-4,
SCN08-5,
SCN08-7,

InfEx-5

Implicit description
about state of
asset

State of asset that is not measurable with conventional sensing
technology (e.g., abnormality ofasset recognized by implicit
knowledge of experts )IR-3

SCN06-2

data

Descriptionchangedof- 29 -

informationex-InfEx-6

Message generated by asset

Message (such as warning, alarm,
application specific notification)that are generated by asset (withspecific application running)

IR-1,
IR-6

InfEx-7

Application

Executable program run on service
platform and/or asset

IR-2

SCN03-1,
SCN03-4,
SCN12-1

InfEx-8

Specifications
applicationofSpecifications of application suchas usage of computing power

IR-3

SCN03-1,
SCN03-4

InfEx-9

Setup informationof application

Information exchanged during
setup stage of application (e.g.,
configuration and test result of
application)

IR-1, IR-4

SCN03-2,
SCN03-3,

InfEx-10

Output of application

Specific result of applications (e.g.,fault prognostics, diagnostics,
quality control, etc.)

IR-1,
IR-3,
IR-5, IR-6

SCN07-2,
SCN07-5

InfEx-11

Function blocks

Definition of function blocks used
for composing applications run onservice platform and informationexchanged in developing them

IR-2,
IR-5

SCN04-1,
SCN04-4

InfEx-12

Specifications offunction blocks

Specifications of function blocks
such as usage of computing power

IR-3

SCN04-1,
SCN04-4

InfEx-13

Setup informationof function blocks

Information exchanged during
setup stage (development, configuration) of function blocks

IR-1, IR-4

SCN04-2,
SCN04-3

InfEx-14

Service platform

Design concept and implementation of software platform of service
platform including application neutral algorithms run on service platform

IR-2

SCN05-1,
SCN05-4

InfEx-15

Specifications ofservice platform

Specifications of service platform
such as condition of usage

IR-3

SCN05-1,
SCN05-4

InfEx-16

Setup informationof service platform

Information exchanged during
setup stage (development, update)of algorithms run on service platform

IR-1

SCN05-2,
SCN05-3,

InfEx-17

Performanceofservice platform

Application-neutral performance ofservice platform (such as service
level, usage of computational resource)

IR-3, IR-4

SCN09-1

InfEx-18

Generic message
generated by service platform

Application-neutral message generated and reported by service
platform (e.g., generic warning andalarm, performance of service
platform, computed recommendation)

IR-1,
IR-3,
IR-5, IR-6

SCN07-5,
SCN10-1

InfEx-19

Actualmance

The actual value of performanceindicator of asset comparable with

IR-3, IR-4

SCN12-2,
SCN12-3

perforvalue of- 30 -

IR-5,

IR-3,

SCN07-2

assetthat of comparable but anonymous
assets (e.g., KPIs, smart manufacturing maturity level which include
kaizen process capability)

InfEx-20

Targetmance
asset

perforvalue of

The target value of performanceindicator of asset (see above)

IR-3

SCN12-3,
SCN12-5

InfEx-21

Distributionofperformance values of assets

Distribution of performance indicator values of assets comparable
one another.

IR-3

SCN12-4

InfEx-22

Lesson learned

Knowledge about future actions toimprove performance value of
asset gained from analysis of asset on service platform

IR-2

SCN12-5,
SCN12-7

InfEx-23

Requests of information to actor

Request of information (e.g., additional usage data of asset) to actor , sent from an actor to otheractor (outside of the IIoT system)

IR-3

SCN07-4,
SCN08-1

InfEx-24

Recommendations

Recommendations
generatedbased on the analysis of usage
data of asset

IR-2

SCN10-2

InfEx-25

Evaluation of recommendations

Evaluation of recommendations

IR-3

SCN10-3

InfEx-26

Schedule of actions of asset

Schedule of future actions of asset(e.g.,
manufacturing
order,
maintenance tasks)
based onrecommendations

IR-1, IR-4

SCN11-1,
SCN12-6

InfEx-27

Guidance for actions related to
asset

Information that helps actor(s)perform actions related to asset(e.g., information for maintenanceassistance) based on recommendations

IR-2, IR-3

SCN11-2

InfEx-28

Acknowledgment

Acknowledgement of execution ofactions related to an asset (e.g.,maintenance) based on recommendations

IR-3

SCN11-4

InfEx-29

Accounting
service

Accounting of service proposed
and agreed between actors

IR-3, IR-5

SCN10-4,
SCN12-8of

3.6 Requirements
In this document, two types of requirements, functional requirements and information requirements, areconsidered.
First, functional requirements of an IIoT system are described following the format of Requirement in theuse case template in IEC 62559-2. These requirements are categorized regarding elements of an IIoT
system used in Sub-clause 3.4. These requirements are classified to functional domains introduced in
the functional viewpoint of IIRA. The functional domains are, namely, control, operations, information,
application, business domains. Data flows and control flows take place in and across functional domains.
In the functional viewpoint of IIRA assigns various functions to these five domains as listed below.

- 31 -

Control domain: Sensing, Actuation, Communication, Entity Abstraction, Modeling, Asset Management, Executor
Operations domain: Provisioning and Deployment, Management, Monitoring and Diagnostics, Prognostics, Optimization
Information domain: Data, Analytics
Application domain: Logics and Rules, APIs and UIBusiness domain: ERP, CRM, PLM, MES, HRM, Asset Management, Service Life Cycle Management, Billing and Payment, Work Planning and Scheduling

Second, necessary properties common to some of information exchanged are organized as information
requirements. Information requirements are assigned to information exchanged regardless of the scenarios and steps, in which information exchanged appears.
Requirements are organized in terms of categories. In this document, each category is described with thefollowing information.
Category ID: Category ID is a number uniquely given to each category.
Category name: Category name is uniquely given to each category. In this document, the category offunctional requirements is defined in terms of elements of IIoT system. Category names are FRca,
FRsp, FRapp, in which FR means Functional Requirement, and small capital letters indicate an abbreviation of elements of IIoT system (i.e., ca: connected asset, sp: service platform, and app: application), respectively. Information requirements are organized within a category IR.
Category description: Brief explanation of this category.

For each category, requirements are specified with requirement ID, requirement name, functional domains, requirement description, and Step ID. The ID, name, and description also appeared in the format
of Requirement in the use case template in IEC 62559-2. In addition, function domains are given to eachrequirement following the functional viewpoint of IIRA. Step ID is a pointer to the description of Scenario
in Sub-clause 3.4.






Requirement ID: It is a unique identifier given to each requirement. In this document, Requirement ID
is defined by CategoryName-*, where CategoryName is the name of the category, to which this requirement belongs, and * is a number (e.g., FRca-1, FRsp-2, FRapp-3).
Requirement name: A name of the requirement, starting with a noun. Similar to requirement ID, requirement names should not be as same as other requirement names.
Functional domains: This column gives functional domain(s) of the requirement following the functional viewpoint of IIRA. A requirement can be assigned to multiple functional domains (i.e., cross cutting functions). In this case, multiple functional domains can be listed, comma separated.
Requirement description: A description of requirement.
Reference: Reference to part of the description in this document, where this requirement is introduced. In case of functional requirements, Step ID appeared in Scenarios (Sub-clause 3.4) is regarded as reference. In case of information requirements, Information exchanged (Sub-clause 3.5) is regarded as reference.

- 32 -

Requirements

CategoryID

Category nameCategory description

1

FRca

Functional requirement for connected asset

Requirement ID

Requirement name

Functional
mains

FRca-1

Disclosure of specifications of asset

FRca-2Controllability
data transfer

FRca-3

Data transfer
asset

FRca-4

Requirement description

Reference (Step IDs)

Asset management (Control)

Asset should disclose information about asset (e.g.,transferable data types and available data transfer
interface).

SCN01-1,SCN031,SCN08-2

in

Communication(Control)Asset should be able to (and allow service platform to)authorize and control data transfer from itself to specific actors and vice versa.

SCN01-1,SCN01-3

byCommunication(Control)Asset should be capable of data transfer between itself
and specific actors (with e.g., data transfer interface)

SCN01-2,SCN06-3

Portability of asset
model

Asset management (Control)

Asset model (i.e., digital representative of asset)
should be portable (so that the service platform cantimely download and manage asset model.

SCN01-2,SCN13-2

FRca-5

Identifiability
asset

of

Asset management (Control)

Asset and its model should be identifiable from service
platform and applications.

SCN02-1,SCN08-3,
SCN08-6

FRca-6

Capability of asset
in receiving messages

APIs and UI (Application)

Asset should be able to receive external messages orcommends sent by actors in various input modes (e.g.,APIs, buttons)

SCN02-2,SCN06-1,
SCN07-3,SCN13-3

FRca-7

Reconfigurability of
asset

Modeling (Control), Asset management(Control)Asset and its model should be reconfigurable (in response to implicit change of environment (e.g., operation condition) and explicit messages sent by actors,
service platform, and applications

SCN02-2,SCN11-3
SCN13-3

FRca-8

Consistency
tween asset
asset modelDatamation)Consistency should be maintained between an asset
and its digital representation in the service platform

SCN02-3,SCN13-4

beand

do-

(Infor-- 33 -

FRca-9Compatibilityofasset model withvarious versions

Data
mation)(Infor-Asset should allow existence of various versions ofasset model (for providing an appropriate model version according to specification of applications).

SCN02-3,SCN13-1,
SCN13-4

FRca-10

Temporary storageof usage dataDatamation)(Infor-Asset should be able to store usage data of asset (incl.
data collected with additional sensors) and other information possessed by asset.

SCN06-1,SCN08-4

FRca-11

Capability of asset
in executing applications

Executor
trol)

(Con-

Asset should be able to execute applications (e.g.,
data collection, monitoring) based on the given schedule or conditions.

SCN06-1,SCN07-2,
SCN07-3

FRca-12

Observability
asset

Sensing (Control)

Asset should make its state observable according to
the interest of operator of machine

SCN06-2

FRca-13Capability of asset
in scheduling actions of asset

Executor
trol)

(Con-

Asset should enable service platform and application
to schedule authorized actions of asset (e.g., datatransfer, application execution, machining tasks).

SCN06-3,SCN11-1,
SCN11-2

FRca-14

Capability of asset
in reporting state ofasset

APIs and UI (Application)

Asset should be able to report messages to authorizedtarget actors (sometimes through service platform andapplications)

SCN07-2,SCN07-3

FRca-15

Updatability of asset

Asset management(Control),Modeling (Control)

Asset and its model should be upgradable throughout
the life cycle

SCN13-1

FRca-16

Comparability
asset

of

Monitoring
anddiagnostics (Operations), Prognostics (Operations)

Asset should provide data useful for comparison of itwith the other assets.

SCN12-2

FRca-17

Anonymity of asset

Asset management (Control)

Asset should be able to assure and control anonymity

SCN12-4

CategoryID

Categories for requirements

Category description

2

FRsp

Functional requirement for service platform

Require-Requirement name

Functional

of

do-

Requirement description- 34 -

Reference (Step IDs)

ment R-ID

mains

FRsp-1

Verifiability of connections between
asset and service
platform

Provisioning and
Deployment (Operations)

Service platform should provide capabilities in verifying
connection between asset and service platform (without
special skills)

SCN01-4

FRsp-2Controllabilityofdata transfer byservice platform

Datamation)(Infor-Service platform should provide capabilities for configuring data access and transfer between asset and service
platform

SCN01-3

FRsp-3

Managementofvarious versions ofasset models

Datamation)(Infor-Service platform should provide capabilities to update
and manage various versions of asset models (easily for
actors without special skills)

SCN02-3,SCN13-4

FRsp-4

Configurabilityofservice platform byreceiving messages

APIs and UI (Application)

Service platform should possesses user interface toallow definition, reconfiguration (by receiving message),
and acknowledgement, and analysis of information (e.g.,
application, function blocks, asset model, usage data ofan asset etc.) in service platform

SCN02-1,
SCN02-3,
SCN03-2,
SCN03-3,
SCN03-4,
SCN04-2,
SCN04-3,
SCN04-4,
SCN07-6,
SCN08-7,
SCN12-3, SCN13-4

FRsp-5

Capability of service platform insending messages

APIs and UI (Application)

Asset should be able to (autonomously) send messages
to authorized target actors (sometimes through connected assets and applications)

SCN07-5, SCN10-1

FRsp-6Disclosure of specifications of service
platform

Provisioning and
Deployment (Operations)

Service platform should provide its specifications toauthorized actors (regarding e.g., function blocks libraryfor developing applications)

SCN03-1

FRsp-7

Verifiability of functions of applications

Provisioning and
Deployment (Operations)

Service platform should provide environment to verify
functions of application

SCN03-3

FRsp-8Basic
analytical
functionalityoffunction blocks

Monitoring
andDiagnostics (Operations), Prognostics (Operations), Analytics(Information)

Service platform should provide function blocks for basic
data analytics on which application-specific algorithms
are built.

SCN04-1

FRsp-9Functionblock
development andtesting

APIs and UI (Application), Analytics (Information)

Service platform should provide environment (application) to develop and test function blocks used for building application

SCN04-2, SCN04-3- 35 -

FRsp-10

Updatability
function blocks

FRsp-11ofManagement(Operations)

Service platform should make its function blocks updatable, while maintaining execution of application built withold function blocks.

SCN04-4

Service
platform
development andtesting

APIs and UI (Application), Analytics (Information)

Service platform should provide environment for developing and testing itself

SCN05-2,
SCN05-4

FRsp-12Updatability of service platform

Management(Operations)

Service platform should be updatable

SCN05-4

FRsp-13

Runtime adaptability of service platform

Management(Operations)

Service platform should be able to execute applications(e.g., data collection, alarm generation, analysis) considering the availability of power of computing resource

SCN06-3,
SCN07-6
SCN09-1

FRsp-14Maintainabilityofcollected
informationDatamation)(Infor-Service platform should be able to store and organize
collected information such as the usage data of assets
for executing applications through life cycle of assets
and the history of recommendations and decisions performed by actors

SCN06-3, SCN12-7

FRsp-15

Data transfer byservice platform

Datamation)(Infor-Service platform should provide information transfer
between service platform and an asset

SCN06-3,
SCN08-5

FRsp-16

Measurabilityofperformanceofservice platform

Management(Operations)

Service platform should provide performance measures(regarding e.g., service level)

SCN09-1

FRsp-17

Temporalconsistency
amongconnected assets

Management(Operations)

Service platform should be able to maintain temporalconsistency among connected assets

SCN11-1

FRsp-18

Interoperability ofservice platform inbusiness domain

ERP, PLM, Assetmanagement(Business)

Service platform should be able to communicate withsystems in business domain (e.g., ERP, PLM)

SCN11-1

CategoryID

Categories for requirements

Category description

3

FRapp

Functional requirement for application

Requirement R-ID

Requirement name

Functional
mains

do-

Requirement description- 36 -

SCN05-3,

SCN07-5,,SCN08-7,

SCN07-5,

Reference (Step IDs)

FRapp-1

Updatability of application

Management(Operation)

Application should be updatable through its life cycle

SCN03-4

FRapp-2Composability
application

of

Data,
Analytics(Information)

Application should be composed of functional blocks
offered by the service platform

SCN04-1

FRapp-3

Configurability
applicationofAPIs and UI (Application)

Application should provide user interface to define dataacquisition schedule, data analysis schedule, and reporting condition (e.g., threshold or schedule) and show
(visualize) its output information (e.g., recommendation)
so that the output information of actors’ interest is interpretable by actors

SCN06-3,
SCN10-2,
SCN10-3,
SCN11-4,
SCN12-3, SCN12-4

FRapp-4

Runtime adaptability of application

Logic & Rules(Application),Management(Operations)Application should be adaptable to changing the availability of power of computing resource and service platform-specific characteristics.

SCN06-3

FRapp-5

Application specificfunctionality

Logic & Rules(Application),
Optimization(Operations)Application should be able to run algorithms with application-specific functionality (e.g., data collection, analysis, recommendation, benchmarking) as expected intime.

SCN06-3,SCN10-1,
SCN12-2,
SCN12-3,
SCN12-4

FRapp-6

Disclosure of specifications of applications

Provisioning and
Deployment (Operations)Application should provide its specifications to service
platform (regarding e.g., usage of computational power
and memory) and authorized actors (regarding e.g.,reliability and response time) in advance of its execution

SCN06-3,
SCN08-7

SCN07-6,

FRapp-7

Capability of application in reporting
messages

APIs and UI (Application)

Application should be able to report messages to authorized target actors (sometimes through service platform and connected assets)

SCN07-2,
SCN10-1

SCN07-5,CategoryID

Categories for requirements

Category description

4

IR

Requirement related to information exchanged

Requirement ID

Requirement name

Functional
mains

IR-1

Validity

Actuation (Control),Executordo-

Requirement description

Reference(Informationexchanged ID)

Conformity of information exchanged regarded as
input data of IIoT system element should be carefully

InfEx-3, InfEx-6, InfEx-9,
InfEx-10, InfEx-13, InfEx-- 37 -

(Control)

validated regarding the format and contents, both
expected and unexpected.

16, InfEx-18, InfEx-26

Intellectual property of information exchanged should
be protected. (e.g., License, Patent)

InfEx-1, InfEx-4, InfEx-7,
InfEx-11, InfEx-14, InfEx22, InfEx-24, InfEx-27

IR-2

Intellectual property

IR-3

Presentation

Modeling (Control), APIs and UI(Application)

Information exchanged that may be presented to actors should be shown in useful and ergonomic way.

InfEx-2, InfEx-5, InfEx-8,
InfEx-10, InfEx-11, InfEx12, InfEx-15, InfEx-17,
InfEx-18, InfEx-19, InfEx20, InfEx-21, InfEx-23,
InfEx-25, InfEx-27, InfEx28, InfEx-29

IR-4

PrivacyDatamation)(Infor-Privacy of information exchanged that may data andknow-hows owned by specific actors should be protected. (Information exchanged should be accessibleby authorized actors).

InfEx-3, InfEx-9, InfEx-13,
InfEx-17, InfEx-19, InfEx26

IR-5

Generality

Modeling
trol)

(Con-

Information exchanged should be independent ofspecific applications and use cases.

InfEx-6, InfEx-10, InfEx11, InfEx-18, InfEx-29

IR-6

Notifiability

APIs and UI (Application)

Generation of information exchanged should be explicitly notified to intended information receivers (e.g.,
alarms)InfEx-6, InfEx-10, InfEx18- 38 -

Annex A.

Disclosure of specifications of asset

Controllability in data transfer

Data transfer by asset

Portability of asset model

Identifiability of asset

Capability of asset in receiving messages

Reconfigurability of asset

Consistency between asset and asset model

Compatibility of asset model with various versions

Temporary storage of usage data

Capability of asset in executing applications

Observability of asset

Capability of asset in scheduling actions of asset

Capability of asset in reporting state of asset

Updatability of asset

Comparability of asset

Anonymity of asset

Verifiability of connections between asset and service platform

Controllability of data transfer by service platform

Management of various versions of asset models

User interface of service platform

Capability of service platform in sending messages

Disclosure of specifications of service platform

Verifiability of functions of applications

Basic analytical functionality of function blocks

Function block development and testing

Updatability of function blocks

Service platform development and testing

Updateability of service platform

Runtime adaptability of service platform

Maintainability of usage data of assets

Data transfer by service platform

Measurability of performance of service platform

Temporal consistency among connected assets

Interoperability of service platform in business domain

Updatability of application

Composability of application

Configurability of application

Adaptability of application

Application specific functionality

Disclosure of specifications of applications

Capability of application in reporting messages

FRca-3FRca-4FRca-5FRca-6

FRca-7

FRca-8FRca-9FRca-10

FRca-11

FRca-12

FRca-13

FRca-14

FRca-15

FRca-16

FRca-17

FRsp-1

FRsp-2

FRsp-3

FRsp-4

FRsp-5

FRsp-6

FRsp-7

FRsp-8

FRsp-9FRsp-10

FRsp-11

FRsp-12

FRsp-13

FRsp-14

FRsp-15

FRsp-16

FRsp-17

FRsp-18

FRapp-1

FRapp-2

FRapp-3

FRapp-4

FRapp-5

FRapp-6

FRapp-7

Name
Define data to be transferred
Connect asset to service platform
Provide access to usage data
Validate connection
Accept connection
Identify asset model in service platform
Reconfigure asset
Update reconfigured asset model
Acknowledge reconfiguration
Design application
Configure application
Deploy and test application
Improve application
Design function blocks
Develop and embed function blocks
Deploy and test function blocks
Improve function blocks
Design service platform
Develop and implement service platｆorm
Deploy and test service platform
Improve service platform
Collect usage data by asset
Collect usage data by operator of asset
Collect usage data by service platform
Analyze usage data by asset
Generate an alarm by asset
Analyze usage data by operator of asset
Request analysis of usage data of asset
Generate an alarm by service platform
Analyze usage data by asset usage advisor
Request additional data
Select sensors
Connect sensors
Record additional data
Provide additional data
Disconnect sensors
Analyze additional data by asset usage advisor
Measure performance of service platform
Generate recommendation
Provide recommendation
Discuss recommendation
Do accounting of recommendation service
Scheduling execution of actions
Request of information for execution of actions
Execution of actions
Acknowledgment of execution of actions
Provide benchmarking application
Compute actual performance
Display actual and target performances
Display performance distribution
Recommend improvement plan
Reschedule and execute improvement plan
Recording improvement plan
Do accounting of benchmarking service
Development of updated asset model
Deliver updated asset model
Reconfigure updated asset model
Upload updated asset model

FRca-2

Step ID
SCN01-1
SCN01-2
SCN01-3
SCN01-4
SCN01-5
SCN02-1
SCN02-2
SCN02-3
SCN02-4
SCN03-1
SCN03-2
SCN03-3
SCN03-4
SCN04-1
SCN04-2
SCN04-3
SCN04-4
SCN05-1
SCN05-2
SCN05-3
SCN05-4
SCN06-1
SCN06-2
SCN06-3
SCN07-1
SCN07-2
SCN07-3
SCN07-4
SCN07-5
SCN07-6
SCN08-1
SCN08-2
SCN08-3
SCN08-4
SCN08-5
SCN08-6
SCN08-7
SCN09-1
SCN10-1
SCN10-2
SCN10-3
SCN10-4
SCN11-1
SCN11-2
SCN11-3
SCN11-4
SCN12-1
SCN12-2
SCN12-3
SCN12-4
SCN12-5
SCN12-6
SCN12-7
SCN12-8
SCN13-1
SCN13-2
SCN13-3
SCN13-4

FRca-1

A.1 Relationship between steps and functional requirements (matrix version)

○ ○
○ ○
○

〇
○
○

〇
○ ○
○ 〇

○ 〇

〇

○
○
〇
〇

○
○
○

〇
〇
〇

○
○
○
○
○
○
〇 ○

○

○ ○
○

〇

○
○
○

○

○ ○ ○

○ ○ ○ ○

○
〇

〇

〇
○

○
○

○

〇
〇

○
○
○
○
〇
○

○
〇

〇
○

〇

○
○
○

○
〇

○ ○

〇
○
○
〇

○
○

○

〇
○

○

○
〇 ○
○ 〇

○ 〇

- 39 -○〇〇○

Asset modelSpecifications of asset

Setup information of asset

Usage data of asset

Implicit description about state of asset

Message generated by asset

Application

Specifications of application

Setup information of application

Output of application

Function blocks

Specifications of function blocks

Setup information of function blocks

Service platform

Specifications of service platform

Setup information of service platform

Performance of service platform

Generic message generated by service platform

Actual perfor-mance value of asset

Target performance value of asset

Distribution of performance values of assets

Lesson learned

Requests of information to actor

Recommendations

Evaluation of recommendations

Schedule of actions of asset

Guidance for actions related to asset

Acknowledgment

Accounting of service

InfEX-3

InfEX-4

InfEX-5

InfEX-6

InfEX-7

InfEX-8

InfEX-9

InfEX-10

InfEX-11

InfEX-12

InfEX-13

InfEX-14

InfEX-15

InfEX-16

InfEX-17

InfEX-18

InfEX-19

InfEX-20

InfEX-21

InfEX-22

InfEX-23

InfEX-24

InfEX-25

InfEX-26

InfEX-27

InfEX-28

InfEX-29

Name
Define data to be transferred
Connect asset to service platform
Provide access to usage data
Validate connection
Accept connection
Identify asset model in service platform
Reconfigure asset
Update reconfigured asset model
Acknowledge reconfiguration
Design application
Configure application
Deploy and test application
Improve application
Design function blocks
Develop and embed function blocks
Deploy and test function blocks
Improve function blocks
Design service platform
Develop and implement service platｆorm
Deploy and test service platform
Improve service platform
Collect usage data by asset
Collect usage data by operator of asset
Collect usage data by service platform
Analyze usage data by asset
Generate an alarm by asset
Analyze usage data by operator of asset
Request analysis of usage data of asset
Generate an alarm by service platform
Analyze usage data by asset usage advisor
Request additional data
Select sensors
Connect sensors
Record additional data
Provide additional data
Disconnect sensors
Analyze additional data by asset usage advisor
Measure performance of service platform
Generate recommendation
Provide recommendation
Discuss recommendation
Do accounting of recommendation service
Scheduling execution of actions
Request of information for execution of actions
Execution of actions
Acknowledgment of execution of actions
Provide benchmarking application
Compute actual performance
Display actual and target performances
Display performance distribution
Recommend improvement plan
Reschedule and execute improvement plan
Recording improvement plan
Do accounting of benchmarking service
Development of updated asset model
Deliver updated asset model
Reconfigure updated asset model
Upload updated asset model

InfEX-2

Step ID
SCN01-1
SCN01-2
SCN01-3
SCN01-4
SCN01-5
SCN02-1
SCN02-2
SCN02-3
SCN02-4
SCN03-1
SCN03-2
SCN03-3
SCN03-4
SCN04-1
SCN04-2
SCN04-3
SCN04-4
SCN05-1
SCN05-2
SCN05-3
SCN05-4
SCN06-1
SCN06-2
SCN06-3
SCN07-1
SCN07-2
SCN07-3
SCN07-4
SCN07-5
SCN07-6
SCN08-1
SCN08-2
SCN08-3
SCN08-4
SCN08-5
SCN08-6
SCN08-7
SCN09-1
SCN10-1
SCN10-2
SCN10-3
SCN10-4
SCN11-1
SCN11-2
SCN11-3
SCN11-4
SCN12-1
SCN12-2
SCN12-3
SCN12-4
SCN12-5
SCN12-6
SCN12-7
SCN12-8
SCN13-1
SCN13-2
SCN13-3
SCN13-4

InfEX-1

A.2 Relationship between steps and information exchanged (matrix version)

○

○ ○
○
○
○
○
○

○
○
○
○ 〇
○
○
○ 〇
○ 〇
○
○
○ 〇
○ ○
〇
〇
○ ○
○
〇 ○
○
〇
〇

〇

〇
○
○

○

○
○

○
○
○
〇
○
○
○
○
○
○
○
○
○
〇 〇
○
○

○
○
○
○

○ 〇
○
○
○

- 40 -

Asset modelSpecifications of asset
Setup information of asset
Usage data of asset
Implicit description about state of asset
Message generated by asset
Application
Specifications of application
Setup information of application
Output of application
Function blocks
Specifications of function blocks
Setup information of function blocks
Service platform
Specifications of service platform
Setup information of service platform
Performance of service platform
Generic message generated by service platform
Actual performance value of asset
Target performance value of asset
Distribution of performance values of assets
Lesson learned
Requests of information to actor
Recommendations
Evaluation of recommendations
Schedule of actions of asset
Guidance for actions related to asset
Acknowledgment
Accounting of service

InfEX-2
InfEX-3
InfEX-4
InfEX-5
InfEX-6
InfEX-7
InfEX-8
InfEX-9
InfEX-10
InfEX-11
InfEX-12
InfEX-13
InfEX-14
InfEX-15
InfEX-16
InfEX-17
InfEX-18
InfEX-19
InfEX-20
InfEX-21
InfEX-22
InfEX-23
InfEX-24
InfEX-25
InfEX-26
InfEX-27
InfEX-28
InfEX-29

Information
Requirement ID
Requirement description
IR-1
Validity
IR-2Intellectual property
IR-3
Presentation
IR-4
PrivacyIR-5
Generality
IR-6
Notifiability

InfEX-1

A.3 Relationship between information requirements and information exchanged(matrix version)

○
○
○

○
○
○

○

○
○
○
○ ○

○
○
○ ○ ○

○
○ ○
○

- 41 -

○
○

○

○

○
○
○

○ ○ ○ ○ ○
○
○
○
○
○

○

○
○
○
○ ○ ○

○
○

A.4 Relationship between both functional/information requirements and functional domains and (matrix version)

Function
Requirement
ID
Name

Control
Asset management
ControlCommunication
Control
Modeling
Control
Executer
ControlSensing
Control
Entity abstraction
Control
Actuation
Operations Monitoring and diasnostics
Operations Prognostics
Operations Provisioning and deployment
Operations Management
Operations Optimization
Information Data
Information Analytics
Application APIs and UIApplication Logic & Rules
Business ERP, PLM, Asset management

Domains

Disclosure of specifications of asset

FRca-2Controllability in data transfer

FRca-3

Data transfer by asset

FRca-4

Portability of asset model

FRca-5

Identifiability of asset

FRca-6

Capability of asset in receiving messages

FRca-7

Reconfigurability of asset

FRca-8

Consistency between asset and asset model

FRca-9Compatibility of asset model with various versions

FRca-10

Temporary storage of usage data

FRca-11

Capability of asset in executing applications

FRca-12

Observability of asset

FRca-13Capability of asset in scheduling actions of asset

FRca-14

Capability of asset in reporting state of asset

FRca-15

Updatability of asset

FRca-16

Comparability of asset

FRca-17

Anonymity of asset

FRsp-1

Verifiability of connections between asset and service platform

FRsp-2Controllability of data transfer by service platform

FRsp-3

Management of various versions of asset models

FRsp-4User interface of service platform

FRsp-5

Capability of service platform in sending messages

FRsp-6Disclosure of specifications of service platform

FRsp-7

Verifiability of functions of applications

FRsp-8

Basic analytical functionality of function blocks

FRsp-9Function block development and testing

FRsp-10

Updatability of function blocks

FRsp-11

Service platform development and testing

FRsp-12Updateability of service platform

FRsp-13

Runtime adaptability of service platform

FRsp-14Maintainability of usage data of assets

FRsp-15

Data transfer by service platform

FRsp-16

Measurability of performance of service platform

FRsp-17

Temporal consistency among connected assets

FRsp-18

Interoperability of service platform in business domain

FRapp-1

Updatability of application

FRapp-2Composability of application

FRapp-3

Configurability of application

FRapp-4

Adaptability of application

FRapp-5

Application specific functionality

FRapp-6

Disclosure of specifications of applications

FRapp-7

Capability of application in reporting messages

IR-1

Validity

IR-2Intellectual property

IR-3

Presentation

IR-4

PrivacyIR-5

Generality

IR-6

Notifiability○

FRca-1

○ ○
○ ○

○
○

○

○

○

○ ○ ○
○
○
○

○
○
○
○

○

○ ○
○ ○
○ ○
○
○

○ ○
○
○

○
○
○ ○
○ ○
○ ○

○
○

○
○
○
○
○

○ ○

○

○
○

○

○

○
○

○

○

- 42 -

References[1] Aspects of the Research Roadmap in Application Scenarios, Link
[2] Usage Viewpoint of Application Scenario Value-Based Service, Link
[3] Exemplification of the Application Scenario Value-Based Service following IIRA Structure, Link
[4] The Industrial Internet Reference Architecture Technical Report, Link
[5] Benefits of Application Scenario Value-Based Service, Link
[6] IEC 62559-2 Use case methodology-Part 2: Definition of the templates for use cases, actor list andrequirements list (edition 1.0)

Authors and Guests
From Japan side, document contents were developed by the following members of the “Use Case Task
Force” in International Standardization Action Group, Robot Revolution Initiative:










Prof. Fumihiko Kimura; The University of Tokyo
Toru Ishikuma; Azbil Corporation
Dr. Hitoshi Komoto; National Institute of Advanced Industrial Science and Technology
Hirozumi Eki; JTEKT Corporation
Dr. Kiyotaka Takahashi; Hitachi, Ltd.
Takenori Baba PE, PEjp; Mitsubishi Electric Corporation
Hiroyuki Itoh; DAIKIN INDUSTRIES, Ltd.
Dr. Shigetoshi Noritake; Toyota Central R&D Labs., Inc.
Yutaka Manchu; Robot Revolution Initiative

Advisors

Shinji Oda; Yokogawa Electric Corporation
Dr. Youichi Nonaka; Hitachi, Ltd.
Mitsushiro Fujishima; Mitsubishi Electric Corporation

From German side, some texts and figures shown in Usage Viewpoint of Application Scenario ValueBased Service were shared to be used in this document. Some additional ideas were also contributed by
the following members:








Dr. Annerose Braune; TU Dresden
Guido Hüttemann; RWTH Aachen University
Matthias Klein; Universität Stuttgart
Dr. Ulrich Löwen; Siemens AG, Erlangen
Tobias Manger; evosoft GmbH, Nürnberg
Dr. Michael Okon; Fraunhofer-Institut IOSB, Karlsruhe
Mario Thron; ifak – Institut für Automation und Kommunikation e.V., Magdeburg- 43 -