Machinery Information Base Data Structure
Rainer Beudert
Marketing Director
Schneider Electric

Ludwig Leurs
Ethernet Convergence
Bosch-Rexroth

Steve Zuponcic
Technology Manager
Rockwell Automation

Presented at the ODVA2015 Industry Conference & 17th Annual Meeting
October 13-15, 2015
Frisco, Texas, USA
Abstract

The Special Interest Group (SIG) for Machinery Information seeks to optimize theintegration of manufacturing machines within the industrial ecosystem. The SIG isdeveloping guidelines for exchange of information between machines and supervisorysystems. A basic machinery Information description and a data model to organize thebase machinery information for exchange with upper level systems was created. An
extended data structure that allows the mapping of other data model (e.g. ODVA’s CIP
Energy model) has been proposed for addition to the base machinery data model.
This paper will discuss the basic data structures that have been defined for machine tosupervisory information exchange as well as the extended data models that convey
additional information about the machinery or the process. The data is given context interms of state and status of the machine. The types of machines and supervisorysystems for which the data models, states, and statuses are intended are outlined.
These data structures will be mapped to CIP, Sercos, and OPC UA to meet the needsof the industrial market and to make conversion of inter-network data transfers easier.

2015 ODVA Industry Conference

1©2015 ODVA, Inc.

1. Introduction
Machinery is central to the production process and manufacturers strive to optimize how
it integrates with other machines and supervisory systems in their business enterprise.
The Internet of Things is exposing many new opportunities to extract value frommachines and processes through revealing valuable information from otherwise
stranded data from sensors and actuators. Analyzing that new data helps in making
better decisions. Manufacturers traditionally benchmark their high-value equipment byasset turnover, which measures how efficiently a company’s assets generate revenue.
In today’s economy, however, production professionals and business executives needto have a more holistic focus. In addition to asset (i.e., machinery) turnover,
manufacturers must measure the ability of assets to help the enterprise meet overallbusiness goals and adapt to rapidly changing market demands. Ease of integration is
an important element of this equation.
ODVA supports optimizing machinery integration using an open and interoperable
framework for communication which is comprehensive, scalable, secure, open andinclusive for both manufacturers and machine builders. To that end, ODVA has
introduced the Optimization of Machine Integration initiative to define this frameworkand has engaged both OPC Foundation and Sercos International to foster crosscollaboration and innovation.
For machine builders, Optimization of Machine Integration (OMI™) provides
opportunities for creating additional value through simplified communication between
machines and from machines to supervisory systems such as SCADA and MES. Bytransforming data into information, OMI will provide tools for dynamic decision-making,thus maximizing machine productivity, improving machine performance and enhancing
the preventive maintenance of machinery assets. As a result, OMI will create morevalue from machines, extend machinery life cycles, and will emerge as a natural sweet
spot to help manufacturers meet their overall business objectives, including workforce,
profitability and sustainability goals.
The purpose of this document is to give an update and preview of the work that ODVA’s
Machinery Information SIGSIG’s is doing on OMI. This document defines a data modeland data structure for machine-to-supervisory system interaction. This data model will
be mapped to CIP, Sercos, and OPC-UA in order to meet the needs of the industrial
market and to make conversion of inter-network data transfers easier.
2. Overview of the machinery information model
The Machinery Information SIG workplan defines two basic use cases driving the need
for OMI and standardized data models as an ODVA deliverable. The first use case isfor machine to machine communications and the second is for machine to supervisorycommunications. Of these two cases, machine to supervisory communications wasprioritized as the starting point for this standards work and, hence, this whitepaper isfocused solely on that topic. Machine to machine communications will be defined later.
2015 ODVA Industry Conference

2©2015 ODVA, Inc.

2.1. Architectural framework, requirements and specific use cases
In an environment characterized by multiple networks and communication technologies,
a key machine integration problem is how to streamline data transfer acrossheterogeneous communication interfaces. One driving motivation is to enable standard
reporting methods and tools that would aid in the management of machines and themonitoring of their states. Without such reporting methods and tools, manufacturers
must rely on customized, and often proprietary, solutions in order to exchange machine
information across systems or transmit data back and forth with the machine. In thepast, user groups have proposed some partial solutions to this problem, such as
PackML and GEM.
The user-driven solutions do not always include standard definitions for how to put thedata on a network in a consistent and seamless manner. An opportunity exists for a
vendor-driven effort to complement the user-driven efforts to develop these standard
definitions for the use cases for the integration of machines as described above. To
take advantage of this opportunity, a protocol-neutral data model is needed that allows
for flexibility in the propagation of machine information across multiple platforms that
may or may not be on the same network.
Figure 1 represents an architectural example for machine-to-supervisorycommunication. In this illustration there are four coordinated machines composed of two
machine pairs, plus two independent machines. The machines are part of one
production line and the coordinated machine pairs are managed by a single line
controller. In this case, the first machine pair is connected to the line controller overstandard Ethernet, (green line.) The second pair is connected via EtherNet/IP, (blueline.) The line controller (LC) can also play a role in the transfer of data between
machines and supervisory systems (e.g., MES). In each of these scenarios, the abilityof each machine pair to communicate between themselves remains possible. A numberof methods may be applied to transfer data between the machine level and the MESlevels: Individual machines can exchange data the directly with the MES; or, machines can communicate to the MES via the line controller (LC). In this casethe LC aggregates data from multiple subordinated machines and exchanges
relevant data with the MES. The LC can either be a separate physical component
in the architecture, as depicted in Figure 1, or it may be an embedded function
within one of the machine sections.

2015 ODVA Industry Conference

3©2015 ODVA, Inc.

The captions for each of the four scenarios describe the relevant data exchange basedon the architecture depicted in accompanying figure.

LegendFigure 1 – Machine to Supervisory Communication with Separate Line Controller
Figure 1 depicts machine-to-supervisory communication with machine data that iscommunicated to the MES layer following various paths using an OPC UA server overstandard TCP/IP or a native industrial communication protocol like EtherNet/IP. In this
scenario, the external line controller can also serve as a data aggregator to the MES
layer while also leveraging the data for its own use. The line controller can either be a
separate physical component in the architecture, as depicted in Figure 1, or it may be
an embedded function within one of the machine sections.
3. Base data structure
The ODVA machinery information data model consists of two parts. The first is thebase machinery information data structure that is described in this section. The second
is the extensible data structures for disciplines such as energy and condition monitoring
as described in section 4.
The base machinery information data structure is foundational to the extensible data
structures and is core to all data that would be communicated to the upper levelsystems. It contains all identifying information for the machine and is an important,
integral, component of the organizational framework for every extended data structurethat would be combined with it.
2015 ODVA Industry Conference

4©2015 ODVA, Inc.

3.1. Description
The base machinery information data structure defines the information that is
exchanged between a machine and another system to identify the core operational andinformational capabilities of the machine. The base machinery data is the combinationof the machine name plate data and the mandatory set of common information thathelps define the specific machine.
3.2. Sources of data (machine types)
ODVA has identified the following list of machine types as the primary targets forapplication of this model. All machine types are candidates, and Table A below is a
representative sample of machinery used in the manufacturing space and their North
American Industry Classification System (NAICS) code numbers1.
Table A – Machinery Types
Machinery classes
Food Product Machinery Manufacturing
Packaging Machinery Manufacturing
Plastics and Rubber Industry Machinery Manufacturing
Machine Tool (Metal Cutting Types) Manufacturing
Oil and Gas Field Machinery and Equipment Manufacturing
Engine, Turbine, and Power Transmission Equipment Manufacturing
Conveyor and Conveying Equipment Manufacturing
Paper Industry Machinery Manufacturing
Semiconductor Machinery Manufacturing
Mining Machinery and Equipment Manufacturing
Printing Machinery and Equipment Manufacturing
Mounting and Handling Machines

NAICS Code33329433399333322033351233313233361
333922333291333295333131333293not classified

1.1. Users of data (MES, supervisory systems, etc.)
Many Manufacturing Execution System (MES) or Manufacturing Operations
Management (MOM) applications require basic information about the machinery andequipment from which they are gathering data. Each MES/MOM software system has
its unique functionality and method for collecting, storing, and analyzing the data. Table
B is a representative sample of the classes of MES/MOM or supervisory control
applications that will use the base machinery data described by the ODVA model.

1

http://www.census.gov/eos/www/naics/

2015 ODVA Industry Conference

5©2015 ODVA, Inc.

Table B – Users of Data
Applications that use machinery data (MES/MOM)
Administration
Alarms/events
ANDON
Batch/recipe management
Condition monitoring
Data exchange
Energy management
Laboratory management
Machine data access (MDA)
Maintenance management
Material management
Order management
Performance management
Process data access (PDA)
Quality management
Time-series data (historian)
Tool management
Traceability/genealogy
Version management

3.3. Machine states and status
3.3.1. Machine State Model and Machine Status Reporting
In industrial automation, machine states can be used to determine machine availability,
the need for manual intervention, and more diagnostic information from the machine –generally called base machine status. Several machine state models are defined instandards for different areas of the industry, for example PackML [1] for packaging,
Weihenstephan for beverage [2], GEM for semiconductor, and MTConnect for machine
tools [3]. All standards have either been derived from or mapped to the ANSI/ISA 88 [4]standard. . (Reference “ISA-88.00.02-2001 Batch Control Part 2: Data Structures andGuidelines for Languages “)From the manufacturing control area, two different requirements for machine status canbe distinguished:
1. A coarse status that needs only information about the production state and theavailability of the machine. Controlling the machine using this model is notneeded, and because of the simplifications, control might not be possible.
2. A detailed status that is able to report problems in the production process.
Production is often specific to the industry branch so the appropriate data model
is mapped from the branch standard into the base machine data as an extension.
This model also enables control of the machine and is able to determine
measures to bring the machine back to the desired state.
For the purpose of associating the proper context of delivered information to the MES
system or other systems receiving information from the machine, only the coarse status
information is required to supply the needed reference or context. For this reason, a
consolidated status model that combines states of several common state machines into
2015 ODVA Industry Conference

6©2015 ODVA, Inc.

a single status output model has been developed. The basic machine state model
depicted in

Figure2: Basic Machine State Modelconsists of four machine states, and four basic colors have been selected to represent thestates for status reporting:
1. Idle: The machine is powered and ready to operate. There is no production running. The
machine is ready to receive the “start” command to start production. The color selected
for this state is yellow, because this state signals “ready to operate”.
2. Execute: The machine is processing material and producing the desired products. The
color of this state is green, because production is running.
3. Stopped: The machine has either stopped or paused production. There can be a varietyof reasons for this such as the completion of a production cycle, lack of material, producttailback, operator interaction, or others. As the effort to get the machine back to execute
is considered relatively small, the color orange has been chosen for this state.
4. Aborted: The machine has stopped production because an error or an abort command
occurred. Before the machine can go back to production, the error conditions have to becleared and/or the abort command acknowledged. Because of the manual interaction
necessary, the color red was chosen for this state.
The transitions between states in Figure 2 are for explanation only and not to be used forcontrolling the machine.
Different industries have standardized machine states for their specific use. The simple fourcolor model unifies the reporting machine status.
Table C shows the mapping of PackML, Weihenstephan, GEM and MTConnect to ANSI/ISA 88.
Transient states are considered to belong to the preceding steady state for status reporting
purposes. The standards specific to dedicated industries define the states in detail as data typeand values. This might be due to independent development of the standards or to special
requirements for the industry specific MES.

2015 ODVA Industry Conference

7©2015 ODVA, Inc.

Table C – Machine Status Reporting Cross Reference
ANSI/ISA 88
executePackML

Weihenstephan
Machine States

execute (6)operating (128)GEM
executing

MTConnect
activepausing

Base Machine Status
Machine Statusgreen (execute)green (execute)pausedidle
stoppedstarting
suspending

idle (4)stopped (2)starting (3)suspending (13)suspendedsuspended (5)un-suspending
stopping
aborting

un-suspending (14)stopping (7)aborting (8)abortedaborted (9)holding
held
un-holding
completingcomplete
resettingclearing

holding (10)held (11)un-holding (12)completing (16)complete (17)resetting (15)clearing (1)idle (32768)
stopped (1)starting (2)prepared (4)lack (8)tailback (16)lack in branch line (32)idlingidle
stoppedinitializing

pausing

interrupted

tailback in branch line (64)stopping
abortingorange (stopped)
yellow (idle)orange (stopped)
yellow (idle)
green (execute)orange (stopped)orange (stopped)orange (stopped)
red (aborted)

equipment failure (1024)
external failure (2048)
emergency stop (4096)
holding (8192)
held (16384)-

emergency

feed holdred (aborted)
green (execute)orange (stopped)orange (stopped)
green (execute)orange (stopped)orange (stopped)
red (aborted)setting up

Note: It is intended that the Base Machine Status model will be a formal part of the ODVA specification as this construct
becomes drafted into a CIPSE document.

2015 ODVA Industry Conference

8©2015 ODVA, Inc.

1.1. Base data definitions
In an effort to promote a consistent means of communicating important data between
machines and supervisory systems, a base data structure model has been developed.
The data that is defined in the structure is intended for machine and equipment builders
to organize relevant data in their machine control systems and for supervisory systemcreators and users to organize data in their applications. The Machinery Information
SIG will create a CIP object definition that will make this data available as a standard,
driving common data interfaces. The common definitions will help reduce the potential
mismatch of data and the extra effort required to convert and translate data between
systems.
1.1.1. Machine Data Flow
The data in the base machine structure consists of machinery configuration parameters
or conditions, input data, and output data as shown in Figure 3. Various configuration
parameters defined in Table D through Table G are exchanged between machinery andsupervisory systems, typically during machine commissioning as the machine is being
integrated with the plant supervisory system(s). Operational data required to setup orcommand the machinery is defined as input data in Table H and Table I. Similarly,
operational data from the machinery that is relevant to the supervisory system(s) isdefined as output data in Table J and Table K.
Machine Identifier
Commands

Mode, Status, etc.
Tracking ID

MachineMaterial

Material
Tracking ID

EventsEnergyConfiguration

Figure 2 – Machine Data Flow2015 ODVA Industry Conference

9©2015 ODVA, Inc.

Table D – Machinery Configuration Data
This table defines all of the attributes required to describe fundamental identifying
information of the machine
Attribute Name

Need in
Implementation

Data Type

Description of
Attribute

Semantics of Value

AssetID

Required

INT

End-User supplied
unique ID string

The combination of the Asset
ID and the Vendor Machine
Serial Number form the
Universally Unique Identifier(UUID). This represents themachine instance within thetype.

EquipmentType

Required

STRING

End-User suppliedmachine type

Name of machine given by
end-user per their standards.

MacnineVendorId

Required

STRING

End-User supplied
unique ID string forthe machine builder

Vendor ID number as used by
the end-user.

EndUserDescription

Required

EUDescript[xx]End-User information
not otherwise defined

Relevant information the end
user may assign to themachine.

VendorName

Required

STRING

Machine builder'sname

Machine builder’s name.

VendorModel

Required

STRING

Machine builder'smodel name for themachineThis represents the machine
type.

VendorMachineSerialNumber

Required

STRING

Machine builder'sunique ID string forthe machine

The combination of the Asset
ID and the Vendor Machine
Serial Number form the
Universally Unique Identifier(UUID). This represents themachine instance within thetype.

VendorContact

Required

VendContact[xx]Machine builder's
address/contact info

Relevant information about themachine builder.

VendorInstallDate

Required

STRING

Machine builder'sYear, Month, Day giving thetime of the warranty period.
install date. Usuallydenotes the start date
for the warranty
periodVendorDescription

Optional

STRING[10]Machine builder's
description for what
the machine does

Free form string describing in
more detail the function of themachine.

Utilities

Required

Utilities[xx]Machine builder'srequired utilities formachine to function

Designates the utilities (air,electricity, gas, etc.) required
for the proper operation of theequipment.

2015 ODVA Industry Conference

10©2015 ODVA, Inc.

Table E – Machinery Configuration Data – End User Description StructureThis table defines all of the attributes required to describe identifying information of themachine as required in the end user’s facility and in the end user’s MES or ERP
systems.
Parameter Name
MachineLocation

Need in
Implementation
Required

Data TypeSTRING(10)Description of Parameter
This is a 10 dimension arraythat holds all the information
for the location of a machine,where each element in thearray is given a specificmeaning

Semantics of Value
See below.

Each dimension of the array is
32 characters long.
Required

String(0)Country

Name of country wheremachine is located.

Required

String(1)State/Province

Name of state/province wheremachine is located.

Required

String(2)City

Name of city where machine islocated.

Required

String(3)Facility

Name of facility wheremachine is located.

Required

String(4)Level

Name of level where machine
is located.

Required

String(5)Cell/Quadrant/Zone

Name of cell/quadrant/ zone
where machine is located.

Required

String(6)Machine ID

Machine identifier.

Required

String(7)User Defined

End user custom identifying
information.

Required

String(8)User Defined

End user custom identifying
information.

Required

String(9)User Defined

End user custom identifying
information.

2015 ODVA Industry Conference

11©2015 ODVA, Inc.

Table F – Machinery Configuration Data – Vendor Contact StructureThis table defines all of the attributes required to provide the machine vendor’s contact
information.
Parameter Name
VendorContactInformation

Need in
Implementation
Required

Data TypeSTRING(10)Description of Parameter
This is a 10 dimension arraythat holds all the information
for the location of a machine,where each element in thearray is given a specificmeaning

Semantics of Value
See below.

Each dimension of the array is
32 characters long.
Required

String(0)Street number

Street number where vendor is
located.

Required

String(1)Street Name

Name of Street where vendor
is located.

Required

String(2)City

Name of City where vendor is
located.

Required

String(3)State/Province

Name of State/Province
vendor is located.

Required

String(4)Country

Name of Country where
vendor is located.

Required

String(5)ZIP/postal CodeName of ZIP/postal code
where vendor is located.

Required

String(6)Contact Name

Name of person to contact at
vendor location.

Required

String(7)Phone number

Phone number for vendor
location.

Required

String(8)Phone extension

Phone extension at vendor
location.

Required

String(9)Email address

Email address of contact at
vendor location.

2015 ODVA Industry Conference

12©2015 ODVA, Inc.

Table G – Machinery Configuration Data – Utilities StructureThis table is meant to define the attributes associated with describing all of the energy
sources and associated utilities that are required for the machine to operate properly.
Parameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of ValueID

Required

INTEGERID value for type of utility

Designates the ID of the utility
as standardized by the end
user. (air, gas, electricity,
coolant, etc.).

Name

Required

STRING

Utility name

Actual name.

Value

Required

FLOAT

Utility set point

Design operating setpoint forthis utility in order to achieve
proper machine operation.

Units

Required

STRING

Utility units

Engineering units for the utility.

ScalerValue

Required

FLOAT

Utility scaling value

Any scaling value that should
be applied given there may be
a conversion or transformationof the utility with respect tosome normalized reference.

ScalerUnits

Required

STRING

Utility scaled value units

Engineering units of the utility
after a given transformation.

2015 ODVA Industry Conference

13©2015 ODVA, Inc.

Table H – Machinery Input Data
This table defines the attributes associated with any fundamental operating inputs to themachineParameter Name
State

Need in
Implementation
Required

Data Type
DINT

Description of Parameter

Semantics of Value

State change command: e.g.,
PackML Model

State of the machine as
defined in state model that isbeing used (see Fehler!

Kein gültiges
Resultat für Tabelle.

for examples).
CommandRate

Required

FLOAT

Production rate of the machine Target rate at which theprocess should run.

CommandRateUnit

Required

STRING

Units of production

Units to apply to the commandand production rate of themachine.

TrackingID

Required

STRING

Current process ID used for
tracking production

Identifier for the produced
parts (or material). In
combination with the serial
number and production time,
material can be traced back to
the raw material andproduction conditions.

ResetCounts

Required

BIT

Set all material total counts to
zero

Resets the count for the
produced material.

Material

RequiredMaterial_In[xx]Material setpoints

Array of material structure todescribe all material used in
the machine as input toproduction.

Table I – Machinery Input – Material Input Data StructureThis table defines the attributes associated with tracking the material that is fed into themachineParameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of ValueID

Required

STRINGID value for material

ID for the Input Material of the
production machine.

Name

Required

STRING

Material nameName of the input material.

TrackingID

Required

STRING

Current process ID used for
tracking material

Tracking ID of the material totrace back to the production ofthis material.

2015 ODVA Industry Conference

14©2015 ODVA, Inc.

Parameter Name
ScalerNeed in
Implementation
Required

Data Type
FLOAT

Description of Parameter
Ratio of command rate tomaterial rate

Semantics of Value
Scaling factor for material input
to calculate transformation ofmaterial to finished product.

Table J – Machine Output Data
This table defines the attributes associated with the fundamental outputs of themachine.
Parameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of Value

RemoteEnabled

Required

BIT

Remote state and process rate Reports whether or not thecommands are allowed
machine can be controlledfrom a remote location (i.e.,
not in the immediate vicinity ofthe machine such as from acentral control room).

Mode

Required

DINT

Current active mode

Operating mode of themachine as defined by themachine/equipment builder
and/or the machinery standard(e.g., PackML).

State

Required

DINT

Current active state: e.g.,
PackML Model

Operating state of the machineas defined by themachine/equipment builder
and/or the machinery standard(e.g., PackML).

StatusRequired

DINT

Current active status: ODVAModel (green, yellow, orange,red)

One of the four designatedstatuses (see Fehler!

Kein gültiges
Resultat für Tabelle.:
enumeration 1=Green,
2=Yellow, 3=Orange, 4=Red).

TrackingID

Required

STRING

Current process ID used for
tracking production

Consumed

Optional

Material_Out[xx]Material consumed as an input Characteristics of materials
to the process
consumed by the production
process; can be applied ornulled.

InProcessOptional

Material_Out[xx]Material currently being
processed

Characteristics of production
work in process; can beapplied or nulled.

Produced

Optional

Material_Out[xx]Material produced by theprocess

Characteristics of good
products produced; can beapplied or nulled.

2015 ODVA Industry Conference

15

Unique identifier assigned by
the end user business process
to track the product during
production.

©2015 ODVA, Inc.

Parameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of Value

Waste

Optional

Material_Out[xx]Material lost due to reject ordefects in the process

Characteristics of waste or
scrap products produced; canbe applied or nulled.

EventActive

Required

BIT

Event active indicator

Flags that a machine event isoccurring (used together with
Event Description and Event
ID).

EventDescription

Optional

STRING

Event description

Literal description of the eventin process when the Event
Active flag is set.

EventID

Optional

DINT

Numeric value used to lookup
description if one is notprovidedReferences a specific string ina lookup table to describe theevent in process when the
Event Active flag is set if Event
Description is not used.

ResetCountsDone

Required

BIT

Material totals have been set
to zeroAcknowledge that producttracking counts have been
reset after a ResetCounts
action has been initiated.

Table K – Material Output Data StructureThis table defines the attributes associated with tracking the material or product that is
output from the machine
Parameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of ValueID

Required

STRINGID value for material

Unique identifier for thematerial.

Name

Required

STRING

Material name

Text description of thematerial.

TrackingID

Required

STRING

Current process ID used for
tracking material

Tracking identifier for thematerial in the relevant stageof the production process.

Available

Required

BOOL

Material flow is available

Status indication of thematerial flow as defined by themachine/equipment builder
and/or the machinery standard(e.g., PackML).

IdealRate

Required

FLOAT

Ideal material usage rate
based on command rate andscaler

Ideal rate at which the material
will be consumed in theprocess.

RawTotal

Required

FLOAT

Material usage before scaling

Actual raw count of productthat has been produced in thecurrent production run.

2015 ODVA Industry Conference

16©2015 ODVA, Inc.

Parameter Name

Need in
Implementation

Data Type

Description of Parameter

Semantics of Value

ScalerRequired

FLOAT

Ratio of command rate tomaterial rate

Scaling factor for material
usage to calculatetransformation of material tofinished product.

Total

Required

FLOAT

Total material usage after
scaling

Scaled material usage total foruse by external systems.

2015 ODVA Industry Conference

17©2015 ODVA, Inc.

4. Extensible data structures
Extensible data structures are structures that can be added to the base data structurefrom a predefined data set to offer a very flexible way to fulfill varying and future
requirements. Some reasons to introduce extensible data types are to:Enable low cost or constrained devices and machines to offer full information
support. This works by limiting the information to be stored in the device or
machine to the mandatory data set. Other data may be stored outside thedevice and referenced by a link or similar construct.
Eliminate inconsistent copies of data. Common data can be stored in a single
location outside the device.
Add new data structures to the device, machinery or system at any time after
deployment to take advantage of new and emerging applications andtechnologies without changing the common data.

4.1. Static and dynamic data
Static data does not change over time and therefore can be stored outside the device.
The minimum data set would be the identification data set that enables any supervisorysystem to uniquely identify the device. All other information could be stored outside thedevice and represented by a link or lookup.
Dynamic data are subject to change over time. This makes it likely that this type of data
will be stored in the device. The minimum set of dynamic data needs to be stored
locally. Additional data can be store remotely. The mandatory set of dynamic data
(Common) should be stored locally.
4.2. Identification
Each object (structure) needs a unique identifier. In the case of a machine, theUniversally Unique Identifier (UUID) would be the combination of the Vendor Machine
Serial Number and the Asset ID (assigned by the end user).
4.3. Linked Information
Linked Information could reside on a server in, for example, an XML data file (e.g.,//Server/dir/machine/uuid/ODVA.desc.xml). Relative path names and permalinks are
permitted.
4.4. Optional features
Features of a machine are listed in the mandatory set of machine information. Only
supported features are listed. Predefined features can reference a publicly available
2015 ODVA Industry Conference

18©2015 ODVA, Inc.

description that could be available worldwide on a public server (e.g., B2MML or
JavaScript styles).
Special features reference a local description or a machine vendor/user specificdescription optionally residing outside the machine.
All optional feature descriptions need to have: a unique identifier description in an accessible data structure (e.g., XML file) either local or pointed
to by link or lookup
 data that can be static/dynamic and local/remote
4.5. XML description
XML files contain syntax and semantics, but also pure text readable by humans, not bymachines.
4.6. Machine Model
The machine model consists of a base machine object and additional (optional) objects.
The optional objects can be predefined (e.g., as Energy object and Condition Monitoring
Object as depicted in Figure 3) or independently defined. The base machine object
defines the unique machine identification, the set of features, and the basic status/statemodel. Optionally it contains an extended state model and more information about the
production process.

2015 ODVA Industry Conference

19©2015 ODVA, Inc.

Figure 3 – General Machine Information Structure
5. Conclusion
The attainment of a standard data structure as mapped through CIP, Sercos, and OPCUA will create many benefactors. The machine supplier is given a common “socket” forwhich standard “plugs” will interface. This allows the equipment designer to efficiently
design equipment that has high value to his customer, making his equipment more
attractive over competition. With a standard interface, there is no longer the need todesign each machine differently for each customer. All data is mapped to known
structures where pre-defined information can be readily collected.
The end-user benefits from a ubiquitous data model that easily traverses multiple
protocols and networks, allowing for fluid bridging of data across different interfaces andmediums. The pre-defined data structures act like multi-pinned connectors that can be
fitted into MES and ERP systems which are designed to accept the same standard.
This common data model enables the IoT promise of data enabled devices – where theend “device”, in this case, is a machine. In defining known structures and locations formachine information – all data is accessible for historization, asset management, supply
chain management, manufacturing execution, and many other types of analytics andmanagement tools.

2015 ODVA Industry Conference

20©2015 ODVA, Inc.

The ODVA Machinery Information SIG will continue to drive out this capability to allow
for true Optimization of Machine Integration.
References[1] ISA, „Machine and Unit States:An Implementation Example of ISA88,“ ISA, Research Triangle Park,NC, 2008.
[2] ANSI/ISA, „Batch Control Part 1: Models and Terminology,“ ISA, Research Triangle Park, NC, 2010.
[3] A. Kather, C. Haufe und T. Voigt, „WS Pack Specification of the Interface Content (Part 2),“ Lehrstuhl
für Lebemsmittelverpackungstechnik, TU München, München, 2014.
[4] J. Turner, „MTConnect Standard Part 3 - Streams, Events, Samples and Conditions V1.3.0,“
MTConnect Institute, 2014.

******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2015 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All other trademarks areproperty of their respective owners.

2015 ODVA Industry Conference

21©2015 ODVA, Inc.