ISO 16100-2:2003

Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 2: Profiling methodology

ISO 16100-2:2003 specifies a methodology for constructing profiles of manufacturing software capabilities, and is applicable to software products used in the manufacturing domain. It is an integral part of ISO 16100 (all parts), a series of International Standards for the computer-interpretable and human readable representation of a software capability profile. The goal of ISO 16100 (all parts) is to provide a method to represent the capability of manufacturing software relative to its role throughout the life cycle of a manufacturing application, independent of a particular system architecture or implementation platform.

Systèmes d'automatisation industrielle et intégration — Profil d'aptitude du logiciel de fabrication pour interopérabilité — Partie 2: Méthodologie d'élaboration de profils

General Information

• Status: Published
• Publication Date: 03-Nov-2003
• ICS: 25.040.01 - Industrial automation systems in general
• Technical Committee: ISO/TC 184/SC 5 - Interoperability, integration, and architectures for enterprise systems and automation applications
• Drafting Committee: ISO/TC 184/SC 5/WG 4 - Manufacturing software and its environment
• Current Stage: 9060 - Close of review
• Start Date: 04-Mar-2025

Relations

• Consolidated By: ISO 15007-1:2014 - Road vehicles — Measurement of driver visual behaviour with respect to transport information and control systems — Part 1: Definitions and parameters
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 16100-2
First edition
2003-11-01

Industrial automation systems and
integration — Manufacturing software
capability profiling for interoperability —
Part 2:
Profiling methodology
Systèmes d'automatisation industrielle et intégration — Profil d'aptitude
du logiciel de fabrication pour interopérabilité —
Partie 2: Méthodologie d'élaboration de profils



Reference number
ISO 16100-2:2003(E)
©
ISO 2003

---------------------- Page: 1 ----------------------
ISO 16100-2:2003(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2003
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 ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2003 — All rights reserved

---------------------- Page: 2 ----------------------
ISO 16100-2:2003(E)
Contents

Foreword .iv
Introduction .v
1  Scope .1
2  Normative references.1
3  Terms and definitions.1
4  Abbreviated terms.3
5  Capability profiling method.3
5.1  Capability profiling concept.3
5.2  Capability profiling process.4
5.3  Software requirements analysis process.5
5.4  Software unit selection and verification, or creation process .5
6  Elements and rules for capability profiling .6
6.1  Taxonomy.6
6.2  Capability classes and their content.6
6.3  Capability templates and rules .11
6.4  Capability profiles and rules .12
6.5  Software unit profile database.13
6.6  Rules for matching capability profiles.13
6.7  Interoperability criteria .13
7  Conformance.13
Annex A (informative) Reference methods.14
A.1  Extensible Markup Language (XML).14
A.2  Vocabularies, definitions and interchange formats for software packages: Open Software
Description (OSD) and Channel Definition Format (CDF) .14
A.3  Distributing software services: Open Distributed Processing (ODP) and Common Object Request
Broker Architecture (CORBA).15
Bibliography.17


© ISO 2003 — All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 16100-2:2003(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 16100-2 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and
integration, Subcommittee SC 5, Architecture, communications and integration frameworks.
ISO 16100 consists of the following parts, under the general title Industrial automation systems and
integration — Manufacturing software capability profiling for interoperability:
 Part 1: Framework
 Part 2: Profiling methodology
 Part 3: Interface protocols and templates
 Part 4: Conformance test methods, criteria and reports
iv © ISO 2003 — All rights reserved

---------------------- Page: 4 ----------------------
ISO 16100-2:2003(E)
Introduction

The motivation for this International Standard stems from the industrial and economic environment noted in the
strategic plan of ISO/TC 184/SC 5, in particular:

a) a growing base of vendor-specific solutions;
b) user difficulties in applying standards;
c) a need to move to modular sets of system integration tools;
d) a recognition that application software and the expertise to apply that software are assets of the enterprise.
ISO 16100 (all parts) is an International Standard for the computer-interpretable and human readable representation
of a software capability profile. Its goal is to provide a method to represent the capability of manufacturing software
relative to its role throughout the life cycle of a manufacturing application, independent of a particular system
architecture or implementation platform.

© ISO 2003 — All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 16100-2:2003(E)

Industrial automation systems and integration — Manufacturing
software capability profiling for interoperability—
Part 2:
Profiling methodology
1  Scope
This part of ISO 16100 specifies a methodology for constructing profiles of manufacturing software capabilities, and
is applicable to software products used in the manufacturing domain.
2  Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO 16100 (all parts), Industrial automation systems and integration ― Manufacturing software capabr ility
profiling for interoperability
REC-xmlschema-1-20010502, XML Schema Part 1: Structures ― W3C Recommendation 02 May 2001
REC-xmlschema-2-20010502, XML Schema Part 2: Datatypes ― W3C Recommendation 02 May 2001
3  Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 16100-1 and the following apply.
3.1
association
semantic relationship between two or more classifiers that specifies connections among their instances
[ISO/IEC 19501-1]
3.2
base specification
base standard or widely accepted and available specification
© ISO 2003 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 16100-2:2003(E)
3.3
capability class
element within the capability profiling method that represents software unit functionality and behaviour with regard
to the software units role in a manufacturing activity
3.4
capability profile integration
process in which two or more software units interoperate using equivalent interfaces that are configured in a
compatible manner as indicated by their capability profiles

3.5
classifier
mechanism that describes behavioural and structural features [ISO/IEC 19501-1]
NOTE Classifiers include interfaces, classes, data types, and components.
3.6
element
atomic constituent of a model [ISO/IEC 19501-1]
3.7
entity
any concrete or abstract thing of interest [ISO/IEC 10746-2]
3.8
interface
abstraction of the behaviour of an object that consists of a subset of the interactions of that object together with a
set of constraints on when they may occur [ISO/IEC 10746-2]
3.9
object
model of an entity [ISO/IEC 10746-2]
NOTE  An object is characterized by its behaviour and by its state. An object is distinct from any other object. An object is
encapsulated, i.e. any change in its state can only occur as a result of an internal action or as a result of an interaction with its
environment. An object interacts with its environment at its interaction points. Depending upon the viewpoint, the emphasis may
be placed on behaviour or on state. When the emphasis is placed on behaviour, an object is informally said to perform functions
and offer services (an object which makes a function available is said to offer a service). For modeling purposes, these functions
and services are specified in terms of the behaviour of the object and of its interfaces. An object can perform more than one
function. A function can be performed by the co-operation of several objects.

3.10
profile
set of one or more base specifications and/or sub-profiles, and, where applicable, the identification of chosen
classes, conforming subsets, options and parameters of those base specifications, or sub-profiles necessary to
accomplish a particular function, activity, or relationship
NOTE This definition is adapted from ISO/IEC TR 10000-1.
3.11
role
named specific behaviour of an entity participating in a particular context [ISO/IEC 19501-1]
NOTE A role may be static (e.g. an association end) or dynamic (e.g. a collaboration role).
3.12
taxonomy
classification scheme for referencing profiles or sets of profiles unambiguously [ISO/IEC TR 10000-1]
2 © ISO 2003 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 16100-2:2003(E)
4  Abbreviated terms
CORBA Common Object Request Broker Architecture
IDL  Interface Definition Language
OMG Object Management Group
PSL  Process Specification Language
UML Unified Modeling Language
XML eXtensible Markup Language
5  Capability profiling method
5.1  Capability profiling concept
The main focus of ISO 16100 is manufacturing software interoperability. Figure 1 depicts the use of a capability
profile concept to integrate interoperable software.

Manufacturing
Software
Requirements
Based on Software
ISO 16100-4
Conformance
Conformance Requirements
Testing and Software Unit
Test Methods, Criteria, Analysis
Registration Capability
(see Figure 3)
and Reports
Profile
Database


Taxonomy
Software Unit
and Domain Required Software
Capability Profile
Ontology
Unit Capability
Based on
Profiles
Based on
ISO16100-3
Capability
Interface
Profiling
Software Unit
Protocols
(see Figure 2)
and Templates
Selection and Verification,
New
or Creation
Complements
Software
Based on
(see Figure 4)
Unit


Based on
ISO 16100-2
Profiling

ISO 16100-1 Methodology
Based on
Integrated
Framework

Interoperable
Based on
Manufacturing
Software

 Key   information flow
    relationship between conceptual elements
Figure 1 ― Concept of capability profile for software interoperability
© ISO 2003 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 16100-2:2003(E)
The interoperability of software units can be described in terms of their capabilities that are associated with the
aspects of functionality, interface and structure. These aspects, based on the framework and domain specific
application system model defined in ISO 16100-1, are defined in Clauses 5 and 6, and are further detailed in
ISO 16100-3.
A manufacturing process has a structure that is both nested and hierarchical. At each level, the manufacturing
software requirements can be modelled as a set of capability classes organized in a similar structure.
Manufacturing software requirements are met by the integration of several manufacturing software units.
In this methodology, manufacturing software requirements shall be expressed in terms of software unit capability
profiles. The profiling of a software unit involves the generation of a concise statement of manufacturing capabilities
enabled by the software unit in terms of the functions performed, the interfaces provided, and the protocols
supported as required by the target manufacturing capability.
The capability profiling methodology shall be defined in terms of the rules and elements provided in Clause 6. The
methodology shall make use of the domain-specific attributes and methods associated with each specific software
unit to describe capability profiles in terms of unit name, manufacturing functions, and other needed class
properties.
The required profiles are compared to existing profiles in the database. When a match occurs, the software unit
being profiled shall be considered to be ready for integration. When no match occurs, a new software unit with the
required capabilities shall be developed, profiled, and registered in the capability profile database.
The software units capability profile definition shall be registered in an appropriate database after passing the
conformance test which will be provided with the conformance test methodology and its abstract test suites to be
defined in ISO 16100-4.
The profile database shall have a set of taxonomies for use in describing the capability profiles.
5.2  Capability profiling process
The part of the concept of capability profile for software interoperability shown in Figure 1 related to the capability
profiling process is detailed in Figure 2.
A software unit to be profiled shall be analyzed in terms of the supported paths within the capability class structure,
the concept for which is described in 6.2.1. The structure itself is defined in ISO 16100-3.
The supported paths shall then be used in the search for a matching template from the database. When a matching
template is found, the fields of the template shall be filled to make a profile. When no matching template is found, a
new template shall be formed using the set of capability classes.

Corresponding
Class Path(s)
Search for
Analyze Capability
Software Fill in
template
Software Profile
Unit template
Unit
Create
Capability Class Structure
Templates in
Template if
in Database
Database
missing

Figure 2 ― Capability profiling process
4 © ISO 2003 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 16100-2:2003(E)
5.3  Software requirements analysis process
The part of the concept of capability profile for software interoperability shown in Figure 1 related to the software
requirements analysis process is detailed in Figure 3.
Capability profiles for each manufacturing software unit shall be derived from manufacturing software requirements
in the software requirements analysis process. As a first step, manufacturing software requirements shall be
decomposed into several primitive requirements which are fulfilled by capability classes that are selected from the
database. When a template that corresponds to the class exists, the template shall be filled with specific
requirements in order to generate a required capability profile. When such a template does not exist, a new
template shall be created based on rules for template creation described in 6.3.

Required
Capability
Manufacturing Classes
Required
Decompose Search for
Software Fill in each
Template for
Requirements Software Unit
Template
Requirements
Each Class
Capability
Profiles
Create any
Capability Classes from
Templates from
missing
Database
Database
Templates to
Templates
database
Figure 3 ― Software requirements analysis process
5.4  Software unit selection and verification, or creation process
The part of the capability profile integration related to the software unit selection and verification, or creation
process shown in Figure 1 is detailed in Figure 4.

if existing
Chosen
Software Units

Software Units
& Capabilities
Manufacturing
Verify Software Units
Required
Select
Search Database
Software

Software Unit Software Unit
for Each Profile
Capability
if not existing
Profiles

 Capabilities
Existing Capability Profiles Based on

interoperability
Develop criteria
Software Unit
Capability Profiling Process

Newly Developed
Software Units

Key    flow within the process
    flow entering from, or leaving to, another process within the capability profiling concept of Figure 1
Figure 4 ― Software unit selection and verification, or creation process


© ISO 2003 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 16100-2:2003(E)
For each required capability profile, a search of matching capability profiles that represent available software units
shall be performed. Matching shall be performed according to the rules given in 6.6. When a match exists, the
software unit shall be added to a list of candidates. When a match does not exist, one of the following shall occur:
a) a new software unit is developed to meet the required profile;
b) the required profile is decomposed into a combination of several profiles;
c) requirements are reconsidered against existing profiles.
The profile for the new software unit shall be registered to the database according to the profiling process in 5.2.
The selected software units shall be verified against the manufacturing software requirements according to
interoperability criteria.
6  Elements and rules for capability profiling
6.1  Taxonomy
A key aspect of a taxonomy for capability profiles is its ability to identify the contents that constitute a capability
class definition. A taxonomy shall be constructed that provides a means for the interchange of the capability
information.
The taxonomy shall describe a partial set of activities undertaken within the lifecycle of a manufacturing enterprise.
If there is a need to add a new activity to the taxonomy, then the capability class associated with the new activity
shall be constructed according to the rules in 6.2.
6.2  Capability classes and their content
6.2.1 Software unit capability class content
The capability of manufacturing software unit shall be expressed in terms of capability classes. These classes shall
be derived from the manufacturing activities noted in ISO 16100-1, Figure 4. These classes shall also denote the
manufacturing function, resource, and information handled by the manufacturing software unit according to the
requirements of the manufacturing process.
The contents of a software unit capability class shall include, but may not be limited to, the following:
a) type of manufacturing domain;
b) type of manufacturing activity as differentiated by the process it is part of, the resources involved in conducting
the activity, and the information types exchanged during the activity;
c) type of computing system as differentiated by the operating environment, the software architecture, and the
design pattern used;
d) type of services, protocol, and data types used in running the software unit;
e) supplier name, software version, and change history;
f) performance benchmarks;
g) reliability indices;
h) service and support policy;
i) pricing terms and conditions of use.
More capability class content rules and their details are described in ISO 16100-3.
6 © ISO 2003 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 16100-2:2003(E)
A conceptual structure for a capability class is shown in Figure 5.


Class Name
Attributes
Type of Manufacturing Domain
Type of Manufacturing Activity
List of Resource Types
List of Information Types
List of Sub Capabilities
Function Type
Methods
List of services supported
(see ISO 16100-3)
Figure 5 ― Conceptual structure for a capability class
6.2.2  Manufacturing application domain
6.2.2.1 Manufacturing application activity model
The domain specific manufacturing application activity model and its three associated models for information,
processes, and resources shown in ISO 16100-1, Figure 4 use the common requirements and the software
interoperability framework for the entire set of software units offered as the solution for an application’s
requirements and framework.
As an offered software unit may cover only some portion of the entire application, the target part in the entire model
shall be labeled appropriately using the taxonomy registered and the sequence and layer number of the activity
models.
EXAMPLE (See ISO 16100-1, Figure 2)
A) Manufacturing Activity
AA) Develop Products
AA1) Design Product
AA11) Develop Conceptual Design
AA111) Define Product Functions and Constraints
AA112) Generate Product Behaviours
AA113) Decompose Functions Constraints and Behaviours
AA114) Specify Product Configuration
AA12) Develop Detailed Design
AA121) Design System/ Component
AA122) Analyze System/ Component
AA123) Evaluate System/ Component Design
AA124) Optimize Design
AA125) Finalize System/ Component Design
AA126) Produce Assembly Drawings
AA2) Engineer Process
AA21) Develop Conceptual Process Plan
AA211) Select Manufacturing Process
AA212) Select Manufacturing resources
AA2121) Select Machines
AA2122) Select Tools/ Fixtures
AA2123) Select labor Skills
AA213) Estimate manufacturing Cost/ Time
AA22) Develop Detailed Process Plan
AA221) Generate Process Sequence
AA222) Generate Operations
AA2221) Determine Intermediate Machining Features
AA2222) Specify Part Setups and machining Resources
AA2223) Calculate Intermediate Machining Tolerances
AA2224) Develop machining Instructions
© ISO 2003 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 16100-2:2003(E)
AA223) Define Manufacturing Parameters
AA224) Generate Control Programs
AA2241) Generate Tools Paths
AA2242) specify Process Control Parameters
AA2243) Generate Machine Control Program
AA225) Generate Shop Floor Routing
AA2251) Determine Shop Floor Configuration
AA2252) Determine Means for Transportation
AA2253) Specify Timing
AA3) Plan Enterprise Resources
AA4) Acquire Resources
AA5) Execute Manufacturing Orders
AA51) Develop Operation Sequence & Detailed Schedule
AA52) Dispatch Production Units
AA53) Track Production Units& Resources
AA54) Manage Factory- Floor Data/ Document
AA6) Control Equipment & Process

6.2.2.2  Manufacturing process model and its profile
The manufacturing process model class is the (automated function) model derived from the implementation of the
required specific application activities with its appropriate taxonomy and index number (see example in 6.2.2.1) in
the system with specific resources and its information flow.
Using a modeling language such as IDEF0, the activity model describes the requirements and data flow of the
application system.
The process model depicts the automated functions with the selected resources and information flow between
them. The process model shall be named and labeled appropriately using the taxonomy registered and the
sequence and layer number of the related (targeted) activity models.
Each process model shall be represented as an appropriate profile.
6.2.2.3  Manufacturing resource model and its profile
The manufacturing resource model is the model representing the selected resources such as devices, equipment,
communication networks, humans, and materials used in the process model to fulfill the requirements of the
information model which specifies the information flow among the resources.
The resource model shall be named and labeled appropriately using the taxonomy registered and the sequence
and layer number of the related (targeted) activity models.
Each resource model shall be represented as an appropriate profile.
6.2.2.4  Manufacturing information model and its profile
The manufacturing information model represents the data types of the events and the data exchanged between
resources in the process model representing the specific scope of activities in the application activity model.
The information model shall be named and labeled appropriately using the taxonomy registered and the sequence
and layer number of the related (targeted) activity models.
Each resource model shall be represented as an appropriate profile.
6.2.3  Computational model and its associated class
The computational model is a model representing the mapping of the process model, the resource model, and the
information model described in 6.2.2.
8 © ISO 2003 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 16100-2:2003(E)
6.2.3.1  Class representation of the software unit
6.2.3.1.1 Class name
The information model shall be named and labeled appropriately using the taxonomy registered and the sequence
and layer number of the related (targeted) activity models.
6.2.3.1.2 Class attributes
The derived attributes of the class shall be listed with its data type and capability for external access.
6.2.3.1.3 Class operations
The derived operations of the class shall be listed with its signature and capability for the external service.
The software unit may be a package consisting of multiple subsequent classes. In such a case, all the included
classes shall be listed.
6.2.3.2  Associated software architecture, software design pattern class used
The typical property of the software architecture as well as the software design pattern to be used for the software
unit’s framework shall be listed along with the role the software unit performs.
1)
Architecture design patterns and examples of its structure and role are listed below.
a) Layering architecture
EXAMPLE Structure: applications that can be decomposed into groups of sub-tasks in which each group of sub-tasks is at
a particular level of abstraction. Role: N layer entity with a role to service for N+1 layer entity.
b) Broker architecture
EXAMPLE Structure: distributed software systems with decoupled components that interact by remote service invocations.
Role: clients, servers, brokers, bridges, client- side proxies, server-side proxies.
c) Model-View-Controller architecture
EXAMPLE Structure: the model contains the core functionality and data, views display information to the user, c
...