Production Events Module (PEM)

Transcription

Wonderware Production Events
Module v. 1.0 (PEM)
Deployment Guide
Revision A
Last Revision: 7/11/2005
Invensys Systems, Inc.
INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE
WITHOUT NOTICE
© 2005 by Invensys Systems, Inc. All rights reserved. No part of this
document may be reproduced, stored in or introduced into a retrieval system,
or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording or otherwise), or for any purpose, without the express
written permission of Invensys Systems, Inc. Except where noted, the
companies, organizations, products, domain names, e-mail addresses, logos,
people, places and events depicted herein are fictitious and no association with
any real company, organization, product, domain name, e-mail address, logo,
person, place or event is intended or should be inferred.
Invensys and the author(s) assume no responsibility for errors or omissions and
no liability is assumed for damages resulting from the use of the information
contained herein. Use of the Invensys software described in this document is
subject to the terms of the applicable Wonderware Corporation or Invensys
Systems, Inc., license. These terms include provisions that limit your rights
such as use restrictions, disclaimers of warranties and limitations of
Wonderware and Invensys liability. A copy of the applicable license will be
displayed upon initial installation of the software. If a copy of the license
terms is not displayed or you require an additional copy of the license terms,
you may obtain one from Invensys' Wonderware business unit by calling
1.949.727.3200 or by sending an email to support@wonderware.com.
Portions of this document have been based upon or excerpted from ANSI/ISA95.00.01-2000, Enterprise-Control System Integration Part 1: Models and
Terminology, and ANSI/ISA-95.00.02-2001, Enterprise-Control System
Integration Part 2: Object Model Attributes. Copyright ISA 2000 and 2001.
Reprinted by permission. All rights reserved.
Invensys; Wonderware; ActiveFactory; ArchestrA; DT Analyst; FactorySuite;
FactorySuite A2; InBatch; InControl; IndustrialSQL Server; InTouch; InTrack;
QI Analyst; SCADAlarm; SuiteLink; SuiteVoyager; WindowMaker;
WindowViewer; WonderWorld; Every system in your plant, working in
concert; the Visualize, Analyze, Optimize symbols; SPCPro and Visualize,
Analyze, Optimize are trademarks or service marks of Invensys plc, its
subsidiaries and affiliated companies. All other brands and product or service
names may be the trademarks or service marks of their respective owners.
Invensys Systems, Inc.
26561 Rancho Parkway South
Lake Forest, CA 92630
1.949.727.3200
http://www.wonderware.com
Contents
3
Contents
Before You Begin ...............................................7
About This Document ............................................................................ 7
Assumptions ........................................................................................... 7
Document Conventions .......................................................................... 7
Where to Find Additional Information................................................... 8
ArchestrA Community Website.......................................................... 8
Technical Support ............................................................................... 8
CHAPTER 1: Production Events Module
(PEM) Introduction ............................................ 11
About the PEM Objects........................................................................ 12
Basic Production Questions.............................................................. 12
Intended Users .................................................................................. 13
References ........................................................................................ 13
Common Object Attributes (Summary) ............................................... 14
Production Attributes (PAs).............................................................. 14
Extended Production Attributes (EPAs) ........................................... 14
Triggers............................................................................................. 15
Common PEM Object Configuration Recommendations.................... 16
PEM Object Security ........................................................................ 16
Uploading Runtime Attributes.......................................................... 17
'Unit' Objects with UDAs for Basic Shared Information ................. 17
Capturing Start and End Times with the ProductionData Object ..... 20
Common PEM System Configuration Recommendations................... 20
Microsoft Message Queuing (MSMQ)............................................. 20
Microsoft SQL Server ...................................................................... 21
CHAPTER 2: PEM Object Architecture...........23
PEM Object Architecture General Notes ............................................. 24
PEM Production Services..................................................................... 24
Event Message Handling...................................................................... 25
Without Response (Default) ............................................................. 25
With Response .................................................................................. 26
PEM Object and Trigger Status............................................................ 27
Without Response ............................................................................. 28
With Response .................................................................................. 29
Monitoring Without Response Messages ......................................... 30
Monitoring With Response Messages .............................................. 30
Production Events Module (PEM) Deployment Guide
4
Contents
CHAPTER 3: PEM Data Relationships............31
About ISA-95........................................................................................32
Collaborative Manufacturing Environment.......................................32
Exchanged Information Categories ...................................................33
PEM Data Relationships .......................................................................33
Relationship to ISA-95 ......................................................................33
ProdDB ..............................................................................................35
PEM Views ...........................................................................................35
CHAPTER 4: PEM Validation ...........................37
PEM Validation Summary ....................................................................38
Object and Server Validation Tasks...................................................38
Validation Behaviors .........................................................................38
Common Validation Configuration ..................................................39
Validation Examples..........................................................................40
Validating Against External Tables.......................................................40
CHAPTER 5: Creating a Basic
PEM Production System...................................43
PEM System Topology .........................................................................44
PEM Component Installation Notes..................................................44
Deploying PEM Components ...............................................................45
About Manufacturing Types .................................................................46
Discrete Manufacturing .....................................................................47
Batch Manufacturing .........................................................................51
Continuous Manufacturing................................................................52
Collecting and Delivering Accurate Data .............................................52
Data Collection Considerations.........................................................52
Event Triggers ...................................................................................53
PLC Queue Characteristics................................................................53
Interrupted Data Collection ...............................................................54
Scaling the PEM System.......................................................................56
Production Server Node Specifications.............................................56
Scaling Out ........................................................................................57
Scaling Up .........................................................................................58
Contents
5
CHAPTER 6: Visualizing PEM Data in the
SuiteVoyager™ Portal .......................................59
About Production Events and Historization......................................... 60
About Genealogy.................................................................................. 60
Genealogy, PEM Objects, and SuiteVoyager ................................... 60
PEM Genealogy Summary ............................................................... 62
PEM Object Genealogy Configuration............................................. 62
PEM Views........................................................................................... 63
Production Events Module Content Units
for SuiteVoyager (Summary) ............................................................... 64
Production Events Runtime .............................................................. 65
Serial Number Data.............................................................................. 70
Configuration/Collection .................................................................. 70
Visualization ..................................................................................... 71
CHAPTER 7: PEM Diagnostics and
Troubleshooting ................................................73
PEM Object Diagnostics ...................................................................... 74
Using the Log Flag Editor ................................................................ 74
Troubleshooting PEM Event Messages............................................ 79
PEM Events Without Response........................................................ 79
PEM Messages With Response ........................................................ 83
PEM Event Processing Errors .......................................................... 84
Monitoring PEM Objects.................................................................. 85
PEM System Diagnostics ..................................................................... 88
Microsoft Performance Monitor ....................................................... 89
Performance Monitoring Summary .................................................. 91
Monitoring Database Transactions ................................................... 92
ISA-95 Glossary.................................................93
Index ..................................................................97
6
Contents
Before You Begin
7
Before You Begin
About This Document
The Production Events Module (PEM) Deployment Guide provides
recommendations and "best practice" information so that you can effectively
define architectures and design and implement projects in a Wonderware®
FactorySuite A2™ environment.
Recommendations included in this guide are based on experience gained from
the development of multiple projects using the ArchestrA™ infrastructure and
the PEM objects. Recommendations are not intended to limit you in
discovering other methods and procedures that work effectively.
Assumptions
This deployment guide is intended for:
•
Engineers and other technical personnel who will be developing and
implementing Production Event Tracking System solutions.
•
Sales personnel who need to define specific PEM-related object and
system details in order to submit project proposals.
It is assumed that you are familiar with the working environment of the
Microsoft® Windows® 2000 and 2003 Server, and Windows XP Professional
operating systems, as well as with a scripting, or programming language. Also,
an understanding of manufacturing concepts such as production events, and
manufacturing types (as well as script statements, functions, and methods) will
help you to understand the PEM objects.
It is also assumed that you are familiar with the individual components that
constitute the FactorySuite A2 environment (where applicable). For additional
information about a component, see the associated user documentation.
Document Conventions
This documentation uses the following conventions:
Convention
Used for
Bold
Menus, commands, buttons, icons, dialog boxes and
dialog box options.
Monospace
Start menu selections, text you must type, and
programming code.
Italic
Options in text or programming code you must type.
8
Before You Begin
Where to Find Additional Information
Wonderware offers a variety of support options to answer questions on
Wonderware products and their implementation.
ArchestrA Community Website
For timely information about products and real-world scenarios, refer to the
ArchestrA Community website: http://www.archestra.biz/ The ArchestrA
Community website is a centralized information center where users, systems
integrators (SIs) and OEMs can share information and application stories,
obtain products and learn about training opportunities.
A key component of this website is the Application Object Warehouse, a
constantly growing resource that provides downloadable ArchestrA objects,
including a range of shareware products.
In the future, objects from the Invensys-driven object library will be available
for purchase. Third parties are also encouraged to submit their own ArchestrA
objects for inclusion.
Technical Support
Before contacting Technical Support, please refer to the appropriate chapter(s)
in this manual and to the User's Guide, Installation Guide and Online Help for
the relevant FactorySuite A2 component(s).
For local support in your language, please contact a Wonderware-certified
support provider in your area or country. For a list of certified support
providers, refer to http://www.wonderware.com/about_us/contact_sales/
E-mail: Receive technical support by sending an E-mail to your local
distributor or to support@wonderware.com.
Web: You can access Wonderware Technical Support online at
http://www.wonderware.com/support/mmi.
Telephone: You can call Wonderware Technical Support at the following
numbers:
•
U.S. and Canada (toll-free): 800-WONDER1 (800-966-3371) 7 a.m. to 5
p.m. (Pacific Time)
•
Outside the U.S. and Canada: (949) 639-8500
If you need to contact technical support for assistance, please have the
following information available:
•
The type and version of the operating system you are using. For example,
Microsoft Windows XP Professional.
•
•
The exact wording of the error messages encountered.
•
•
Details of the attempts you made to solve the problem(s) and your results.
Any relevant output listing from the Log Viewer or any other diagnostic
applications.
Details of how to recreate the problem.
Before You Begin
•
9
If known, the Wonderware Technical Support case number assigned to
your problem (if this is an ongoing problem).
When requesting technical support, please include your first, last and company
names, as well as the telephone number or e-mail address where you can be
reached.
10
Before You Begin
Production Events Module (PEM) Introduction
C H A P T E R
11
1
Production Events Module
(PEM) Introduction
This chapter provides a high-level introduction to the PEM Application object
templates and PEM System components. It includes a PEM object overview,
common object characteristics and behavior, and recommended object and
system configurations common to all PEM system environments.
Note For information on specific PEM object attributes and their uses, see the
Production Events Module User’s Guide.
Contents
•
•
•
•
About the PEM Objects
Common Object Attributes (Summary)
Common PEM Object Configuration Recommendations
Common PEM System Configuration Recommendations
12
Chapter 1
About the PEM Objects
The Production Events Module (PEM) is the first of a set of Wonderware
components built on the ArchestrA framework to address Manufacturing and
Production Information needs.
PEM objects provide traceability of production events. The module consists of
ArchestrA application objects and associated services required to capture these
events and store the data. The stored data is organized in a (SQL Server™)
database that is designed following the ISA-95 (S95) standards for naming,
format, data and transactions that occur between Production Systems and
Business Systems.
Note See Chapter 3, "PEM Data Relationships." for more information on
ISA-95.
PEM objects generate messages triggered by production events. The messages
contain data about the event. The event data is configured at the object level
within the ArchestrA IDE. Event messages are written to a SQL Server
database for retrieval and analysis.
Note For specific information on PEM Object installation, see "PEM
Component Installation Notes" on page 44.
Basic Production Questions
The PEM objects provide the means to store the data and event context
necessary to answer the following questions:
•
•
•
•
•
•
How much product did I make?
•
What basic resources (water, energy, etc.) were consumed during the
processing of my product?
What component materials went into my final product?
What other products used the same component materials?
When was my product produced?
What equipment was used to process my product?
Which operator was responsible for the equipment during processing of
my product?
13
More Complex Production Questions
• How much input material did I use vs. how much output material was
produced (mass balance)?
•
What were the values of some key product attributes at a particular
inspection point in the process of making my product?
•
•
Which specific tooling was in the equipment that processed my product?
Which runs of this product:
•
•
•
Went through the same equipment?
Were run by the same operator?
Used the same input materials?
Intended Users
The PEM objects are intended for users who need to collect production event
information, but who may not have the need or resources to initially implement
a full-featured Manufacturing Execution System.
Many modern production environments can improve their manufacturing
operations tremendously by gathering (tracking) just a few key production
parameters - material consumption, production, or equipment information.
Note It is assumed that the PEM user has a complete understanding of the
ArchestrA framework and the Industrial Application Server in order to
effectively utilize the PEM components.
The modular nature of PEM enables pilot or limited solutions development
that target specific production issues, yet provide an easy mechanism for
growth as it becomes required or possible.
The ArchestrA framework provides the flexibility to grow from very small to
very large, vertically or horizontally. PEM takes full advantage of this
flexibility.
Note For more information on PEM Scalability, see Chapter 5, "Creating a
Basic PEM Production System."
References
The following documents contain detailed information that compliments the
information found in this Deployment Guide:
•
•
•
•
•
Wonderware Production Events Module (PEM) User's Guide
Wonderware Industrial Application Server User's Guide
Wonderware FactorySuite A2 Deployment Guide
Microsoft SQL Server User's Guide and Books Online
ISA-95 Parts 1, 2, 3
14
Chapter 1
Common Object Attributes (Summary)
Production Attributes (PAs)
The Production Attributes (PAs) are the key data options selected to trace
(record to the database) when the object’s trigger executes. The specific PAs
associated with each PEM object template differ slightly due to the function of
the object (i.e. a particular function may require several more key parameters
in order to sufficiently capture the information to describe the event).
The following figure shows the Production Attributes tab field of an object
derived from $MaterialConsumedActual:
Extended Production Attributes (EPAs)
Extended Production Attributes (EPAs) provide extensibility for the solution
developer to capture custom attributes when an object executes. For example,
when executing a function to record a material production, it may be desirable
to also capture a set of process or quality parameters at the same time.
Items such as maximum or minimum temperature, visual inspection results or
final weight can be stored with the material production record through the use
of Extended Production Attributes.
15
Triggers
A trigger is a special PEM object attribute. A trigger initiates production data
collection and storage to the ProdDB database. Data collection occurs when
the trigger is set to True by the native trigger attribute
(MyPEMObject.trigger), or by specifying an Input Source, which in turn sets
the Trigger attribute to True.
The data that is collected is defined within the PEM Production Attributes
tab field. For example, the Input Source attribute might be directed to look at a
machine start signal from an I/O device. The trigger might also be pointed to
an attribute that is set within an IAS script. This allows the solution designer to
evaluate any conditions that must be met before executing the transaction.
When a PEM trigger is set to True (executes), it collects the values of all of its
configured attributes and assembles a message. Care must be exercised to
ensure that all of the attributes referenced have been appropriately updated
and/or not overwritten. For example, a changing quantity value needs to be
captured immediately so that value is not lost by the time the message from the
PEM event is formatted and sent.
The timing of the attribute updates and the trigger execution is critical and may
require attention to the execution order of the related objects. The following
figure shows a trigger setting in a derived object instance. Note the use of
MyContainer relative reference, and the fact that it is grayed out, indicating
that this has been configured in a template and locked:
Note For more information on PEM object triggers, see "PEM Object and
Trigger Status" on page 27, "Event Triggers" on page 53, and "Monitoring
PEM Objects" on page 85.
16
Chapter 1
Common PEM Object Configuration
Recommendations
The following guidelines and recommendations facilitate the use of the PEM
objects within the Industrial Application Server environment.
PEM Object Security
PEM object security is configured using the Industrial Application Server
security model. Detailed security information is included in the Wonderware
FactorySuite A2 Deployment Guide.
Deploying PEM Objects in a Workgroup
Security Environment
In some environments, it may be necessary to deploy the PEM objects and the
Production Server within a Workgroup security environment. In these
situations it is important to keep the following considerations in mind when
configuring security settings for the PEM nodes that will participate in the
application.
In a Workgroup security environment machines use only Local user settings
and are not "aware" of users on other machines within the workgroup. This
implementation differs from a Domain environment which provides the ability
to create and specify Domain-level users.
There is no equivalent model in the Workgroup environment. This
consideration is important when two or more machines wish to grant access to
certain resources to users on other machines within the same Workgroup. In
most instances, as long as the same user and password are configured on both
machines in a workgroup, the operating systems match the two usernames and
make the assumption that they are both the same.
There are some exceptions to this; most notably Microsoft’s Message Queue.
In the case of MSMQ, even if the same username is configured on both the
sending and receiving nodes (as will be the case after a standard PEM
installation), the messages bound for the Production Server appear to be
coming from an unknown user when they arrive.
To enable the Historian/Production Server to successfully receive
messages in a Workgroup security environment
•
Grant "Send/Receive" permissions to both the Anonymous Logon and the
Everyone users for the wwprodmsgqueue1.0 incoming queue on the
Historian/Production Server node.
Note If this permission is not granted, the messages from the Sending node
are returned unprocessed and placed into the Transactional Dead-Letter
message Queue on the client.
For specific details about IAS and Historian nodes, see "PEM Component
Installation Notes" on page 44.
17
Deploying PEM Objects in a Domain Security,
"Mixed Platform" Environment
The default PEM installation within a Domain Security environment should
ensure correct message handling between Windows operating systems. This
includes PEM objects on the XP platform that send production messages to the
Windows 2000 or 2003 Server node.
A specific Production Environment may include different server platforms
(operating systems). For example, the "sending" and "receiving" machines
may be a combination of Windows2000 Server and Windows Server 2003
platforms.
Message handling problems will result between Windows 2000 and 2003
servers without changes to the (default installation) security settings on the
Historian/Production node.
To ensure correct message handling between mixed platforms
Add an Anonymous login account to the queue on the Historian (message
processing) node with Full Access permissions. This user/permission
combination ensures correct message handling between mixed platforms.
For specific details about IAS and Historian nodes, see "PEM Component
Installation Notes" on page 44.
Uploading Runtime Attributes
PEM attributes are intended to contain real-time values or constant values. The
InitialValue attribute enables 'constants' to be locked into the containment
model at configuration time and automatically propagated during deployment
from within the IDE.
Therefore, when an "Upload Runtime Changes" operation is performed on any
PEM attribute, the value stored in the Value attribute will not overwrite the
InitialValue attribute.
'Unit' Objects with UDAs for Basic Shared
Information
Unit Container
It is highly recommended that a higher level 'unit' container application object
be created as a repository for common attributes that will be accessed by the
contained PEM objects.
Items such as Lot Number, current Operator, Process Segment, Segment
Response or Production Request can all be stored at the container level by
adding UDAs. This container can be an existing equipment object within the
model or it can be an object specifically created to contain PEM objects.
18
Chapter 1
Justification: This structure allows the PEM objects to be configured with
'Input Source' references using the 'MyContainer' relative addressing terms.
This makes the use of instances from the deployed template objects much
easier. The subsequent instances of these objects can then immediately identify
their Input Source when they are attached to any 'unit' container.
Further, the designer may find it advantageous to create a template (i.e.
Manufacturing Unit) that already has all the necessary UDAs added. This can
be used to create derived templates for more specific purposes and the derived
templates will already have, at least, the standard UDAs.
Pre/Post Event Conditions
The PEM objects are triggered by a digital flag and do not allow for
conditional statements to drive execution. However, it is possible to evaluate
pre-conditions through the use of a simple script at the parent object level that
examines the required conditions and sets the trigger.
Single Object Instance for Multiple Events vs.
Multiple Object Instances with Single Event
One of the guiding principles of the Production Events Module is that it be
implemented in a manner consistent with the ArchestrA modeling approach.
In the PEM object context, the production objects represent transactions, and
the transactions are generated by events that occur in the production
environment. The events should be logically associated with modeled
equipment or areas, and the model should reflect reality from the production
environment. This structured model is key to easily interpreting and exercising
an Industrial Application Server solution.
The following guidelines illustrate these principles and potential exceptions:
Use object instance to save the model, do not model to save instances.
The goal of the ArchestrA model built for a production environment is to
mirror the real world as closely as possible: If a machine has three pumps, it is
modeled with three pumps. Likewise, if a machine executes three production
transactions, it should have three PEM object instances to reflect those three
transactions.
This practice provides clear benefits beyond appearance: For instance, if three
separate consumptions occur at a machine at the same time, three separate
objects will be executed by the same single trigger and all three will then
execute on the same scan. The threading will be handled by underlying
subsystems.
The one clear exception is when a large volume of transactions need to occur at
once or at high speed/volume. For example, 50 materials are combined and
dumped into a blending process, once every hour. When an operation
consumes 50 different materials all at once, it would probably be confusing to
try to attach 50 consume events to a model.
If there is no urgency to process each consumption at high-speed, it may be
acceptable to use fewer PEM consume objects. The object can be re-populated
with a new set of attributes for material, lot, etc., and re-triggered until all
consumptions are complete.
19
From an execution standpoint, this scenario requires the developer to provide
the controlling logic to process through each of the materials and re-trigger the
PEM consume event. From a processing perspective, the total consumption of
all materials must execute over several scans.
If all of the transactions must have the same time-stamp, the time-stamp can be
configured as an input-sourced attribute for the object. Each event then uses
the value of the event input source for time.
Capturing Start and End Times with the
ProductionData Object
To track Start/End dates (instead of a specific production event), you need to
provide "boundary" events. Boundary events are generated by triggering a
ProductionData object that has no EPAs, but has the correct Production
Request ID, Process Segment ID and Segment Response ID set.
The first time you trigger that ProductionData object it will mark the Start
time. Any subsequent triggers of the same event with the same production
attributes (Production Request ID, Process Segment ID and Segment Response
ID) simply update the End time.
This strategy is useful in the context of a Continuous manufacturing
environment. For more information, see "Continuous Manufacturing" on page
52.
Common PEM System Configuration
Recommendations
Microsoft Message Queuing (MSMQ)
The following information is based on the assumption that the PEM
environment includes objects configured Without Response.
Note MSMQ must be installed with a minimum of the Common subcomponent on the AppEngine node (hosting the objects), and the Historian
node (PEM Production Services) before the PEM objects and services are
installed.
In an AppEngine failover (Redundancy) configuration, the user must install
MSMQ with its minimum components on both Primary and Backup nodes
prior to PEM object deployment.
For more information on Message Queuing, see "PEM Events Without
Response" on page 79.
Microsoft Message Queuing service is used to handle PEM event messages
when PEM objects are configured Without Response.
20
Chapter 1
If MSMQ exists on the machine, the Production Service installation configures
and enables the Message Queuing services. If MSMQ does not exist on the
PEM Object node, the PEM objects will function using "With Response" mode
only.
If the user attempts to trigger an object configured in Without Response mode
and without MSMQ, the object will return an Error and error messages will be
logged to the WWLogger indicating the cause of the error and the potential
solution.
Note For more information on PEM Event Message Handling, see Chapter 2,
"PEM Object Architecture."
The following information describes MSMQ installation scenarios on different
operating systems:
•
On Windows 2003 and XP Operating Systems: Message Queue
Common files are included in the operating system installation and are
enabled and/or configured when the PEM Production Services are
installed.
If you must re-install Message Queuing on these operating systems, only
the Common sub-component is necessary for proper interaction with the
PEM system. When only this sub-component is selected for installation,
the installation CD is not necessary because the Common files already
exist on the operating system.
•
On Windows 2000 Operating Systems: It is necessary to install the
MSMQ service manually from a CD before installing the PEM Services
on Windows2000.
Note For information about security settings specific to the Microsoft
Message Queue, see "Using Message Queuing" on page 80. Security
configuration for MSMQ and other PEM Services is handled automatically at
installation.
21
Microsoft SQL Server
A primary concern when administering Microsoft SQL Server is the actual
database size-on-disk.
The default settings for database file growth are Automatically grow file and
Unrestricted file growth. These settings have obvious implications for
resource availability and consumption. As the PEM data is written to disk,
SQL Server consumes more and more system resources until all disk space is
exhausted.
MS SQL Server includes a variety of sizing and management options. The
following recommendation for data file growth should be considered in the
context of an effective database backup and restore strategy:
To Configure Database File Growth:
1.
Launch SQL Server Enterprise Manager.
2.
On the local SQL Server, expand the Databases icon.
3.
Right-click the ProdDB icon and select Properties.
The General tab contains summary information about the database, such
as Date created, Size, Space available, etc.
4.
Select the Data Files tab.
5.
Select the File growth and Restrict file growth options and enter specific
values in each field.
6.
Configure a SQL Agent Job to notify the user when a specific threshold
value has been reached.
Other SQL Server Recommendations
• Configure the Transaction log on a separate logical or physical disk.
• Implement a separate (similar) growth configuration for the transaction
log file.
•
•
Implement a separate backup/restore strategy for the transaction log.
Implement a viable data archival strategy (export the data to a separate
physical disk).
Note See SQL Server Books Online for detailed information about database
and transaction log growth and growth implications.
22
Chapter 1
PEM Object Architecture
C H A P T E R
23
2
PEM objects send messages sent when their Trigger attribute (from an external
source or script) is set to True.
The message contains a snapshot of all configured attribute values collected at
the time of the event. Each message is handled differently, according to its
settings.
The following information describes PEM object architecture in the context of
PEM events configured as Without Response and as With Response, and
includes detailed explanations of message handling, and object behaviors.
Contents
•
•
•
•
PEM Object Architecture General Notes
PEM Production Services
Event Message Handling
PEM Object and Trigger Status
24
Chapter 2
PEM Object Architecture General Notes
•
Configuration: Objects' attributes are configured. Objects must be
configured as either With Response or Without Response.
•
Runtime: Events are triggered from an external source (Input Source) or
from a script. Messages are handled in two different ways depending on
the response attribute setting (see below).
•
PEM Production Services, the ProdDB (with SQL Views), and the
PEMErrorViewer component are installed on the GR/Historian machine.
•
A separate node is recommended for the SuiteVoyager installation.
Note The SuiteVoyager Production Events Module Content Unit
component is a separate installation and is available for SuiteVoyager
version 2.5 and later. For more information on the Production Events
Module, see Chapter 6, "Visualizing PEM Data in the SuiteVoyager™
Portal."
•
The average size of a PEM message is 15kb, but its ultimate size in the
database will likely be smaller and will vary considerably from message to
message, depending on its configuration.
PEM Production Services
PEM Production Services is a .NET Services Component whose methods are
invoked by the aaProductionMessageDispatcher and the web services. It is the
middle-tier between the PEM objects and the ProdDB.
The Production Service sub-components are:
•
ArchestrA Production Message Dispatcher
(aaprodmsgdispatcher.exe): Accessible through Administrative
Tools/Services. This service acts on production messages. The service
interacts with the Microsoft Message Queuing service.
•
PEM Web Service 1.0: Accessible through Microsoft Internet
Information Services (IIS), handles all messages from an object
configured With Response. IIS is not a part of the PEM Production
services, but it hosts the Web Service which handles With Response
messages.
•
ProdMsgHandler: A .NET component accessed as a COM+ application.
Receives messages from both the Production Message Dispatcher and IIS,
and dispatches all Production Event messages to the ProdDB.
Note For details on Production Service installation, see "PEM Component
Installation Notes" on page 44
Specific service interactions are detailed in the figures on the following pages.
25
Event Message Handling
PEM Event messages are handled in one of two ways:
Without Response (Default)
The message is processed by the Message Queue Service on both the "sending"
node (AppEngine Node) and the "receiving" node (Production Service Node).
The message is then passed to the ProductionMessageDispatcher, then the
ProdMessageHandler component, which writes the content to the ProdDB.
Note Microsoft Message Queuing is a Microsoft Operating System
component leveraged by the PEM objects. For more information, see Chapter
7, "PEM Diagnostics and Troubleshooting."
Config
Runtime
Services
ProdDB
External Event Trigger
(InTouch, PLC, DB,
etc.)
EquipmentActual
MaterialConsumableActual
MaterialConsumedActual
MaterialMovedActual
MaterialProducedActual
PersonnelActual
ProductionData
SuiteVoyager
MSMQ
Internal Event
Trigger (Scripted)
MSMQ
Presents Error Messages and detailed
information from the
ProductionEventMessageError table.
ProdMsgDispatcher
Data
ProdMsgHandler
PEMObject
Deploy
PEMErrorViewer
Production Services
Message
Without Response
Event
PEMObject
Contains Content Unit samples that organize/
display message data from PEM in a number of
different contexts, including Genealogy. Content
Units query from SQL Views in ProdDB.
MessageDispatch
Resubmitting the error sends the message back
to IIS for validation.
The data contained in messages triggered in
Without Response mode are validated within
the ProdMessageHandler component.
If validation succeeds, the message is written to
the appropriate data tables within the Production
Database. If validation fails, an error message
(along with the original message) is written to the
ProductionEvenMessageError table in the
Production Database. These errors can be
viewed using the PEMErrorViewer web client.
26
Chapter 2
With Response
Use the With Response configuration option when a response (to an operator
interface/InTouch™ HMI application, internal client, etc.) is required.
The object validates the message and sends it directly to the PEM Web Service
(IIS). PEM Web Service then sends it to the ProdMessageHandler Service.
Important! The first time a message With Response is triggered after system
startup (i.e. each time the system is rebooted), a delay will occur because the
IIS Services are starting the PEM Web Service components. Subsequent
messages are handled without delay.
Note The term "Validation" in this context is defined as the mechanism to
ensure that the values of defined Production Attributes and Extended
Production Attributes comply either with predefined patterns or that the values
passed in the attribute are unique in a specified database table.
For more details on Validation, see Chapter 4, "PEM Validation."
If the message cannot be validated, an error is returned to the object.
Config
Runtime
Services
ProdDB
External Event Trigger
(InTouch, PLC, DB,
etc.)
EquipmentActual
MaterialConsumableActual
MaterialConsumedActual
MaterialMovedActual
PersonnelActual
ProductionData
SuiteVoyager
Contains Content Unit samples that organize/
display message data from PEM in a number of
different contexts, including Genealogy. Content
Units query from SQL Views in ProdDB.
Production Services
Internal Event
Trigger (Scripted)
Message
With Response
Event
Data
PEM Web
Service
ProdMsgHandler
PEMObject
PEMObject
Deploy
MessageDispatch
If IIS services are not running, object
generates error message "Production Event
Message Retry Error."
The data contained in messages triggered in
With Response mode are validated within the
ProdMessageHandler component.
If validation succeeds, the message is written to
the appropriate data tables within the Production
Database. If validation fails the an error
message is returned to the object, which is
accessible via the Status and Error Message
attributes of the object.
IMPORTANT: In the case of validation failure for
With Response messages, no error is written to
the ProductionEventMessageError table.
Therefore, it is important to monitor the Status
attribute to catch errors that occur during
runtime.
Note For more information on these behaviors, see Chapter 7, "PEM
Diagnostics and Troubleshooting."
27
PEM Object and Trigger Status
PEM Objects have the following states: Ready, Busy, Done, and Error. The
state is expressed via the Status attribute. The status attribute can be viewed in
the Object Viewer or other application.
The value of the Trigger attribute is checked at every scan. If it changes when
the object is in the Ready, Done, or Error state, the object takes appropriate
action, based on the following behavior description:
Note Never modify the Trigger attribute's value when the object is in the Busy
state.
1.
The object begins in the Ready state and the Trigger attribute is 0 (False).
2.
The trigger attribute is set to 1 (True).
3.
At the next scan, the object recognizes the Trigger is True and transitions
to the Busy state.
4.
While Busy, the object is creating and sending, or queuing the production
message.
5.
When message processing completes successfully, the object transitions to
the Done state, and the trigger remains True.
Note If processing fails, the object transitions to the Error state, and the
Trigger attribute remains True. Communication or validation problems cause
the object to transition to the Error state.
6.
When the Trigger attribute returns to False, the object transitions to the
Ready state.
Objects in the Without Response mode write an appropriate error message to
the ProductionEventMessageError table in the case of error. Use the PEM
Error Viewer web-based utility to view and re-submit these messages.
Objects in the With Response mode will populate the Error and ErrorMessage
attributes with the appropriate error message information.
Important! When functioning without errors, the AutoReset functionality
automatically resets the Trigger attribute to False when the Done state is
reached (and the Trigger attribute is True). It is important to remember that the
AutoReset functionality will not reset the Trigger of an object that is in the
Error state. If it did the user would never see the error. When an error occurs,
the object must always be reset manually by the user or via a script.
Object triggering behavior is described on the following pages in the context of
Without Response and With Response.
28
Chapter 2
Without Response
The following figure shows the trigger behaviors when the object is set
Without Response:
Ready
Trigger set to
value of 0
Trigger set to
value of 0
Trigger set to
value of 1
Error
Message is in the
process of being created
and placed onto the
message queue
Done *
Message not placed onto the
message queue . Trigger
attribute remains 1 (True).
Busy
Message successfully queued for
delivery to the Production Server
1.
The object begins with Ready status.
2.
The trigger status of the Ready object is 0 (False).
3.
When the trigger is "fired", the trigger status is set to 1 (True), and object
status = Busy.
4.
While Busy, the object is creating and queuing the production message.
The message is successfully queued, or not queued.
5.
When message processing completes successfully, the object transitions to
the Done state, and the trigger remains True.
Trigger attribute remains True.
6.
Ready state.
Note (*) AutoReset does not take effect if the Status attribute's value is
anything other than Done. If the AutoReset attribute is set to 1 (TRUE), the
Status attribute's value is Done and the Trigger attribute's value is 1, the object
sets the Trigger attribute’s value to 0 (zero), causing the object to transition
from the Done state to the Ready state on the next scan of the Application
Engine. Otherwise, the application logic is responsible for resetting the Trigger
attribute's value to 0 (zero). For example, a PEM object will never "AutoReset"
out of Error Status, and requires a manual or scripted reset of the Trigger
attribute before the object will return to Ready Status.
29
With Response
The following figure shows the trigger behaviors when the object is set With
Response:
Ready
Trigger set to
value of 0
Trigger set to
value of 0
Trigger set to
value of 1
Error
Message is sent and
awaits response from
Production Server
Done *
Message not delivered
successfully, or a
validation error occurred .
Trigger attribute remains
1 (True).
Busy
Message successfully sent and
received a positive response
from Production Server
1.
The object begins with Ready status.
2.
The trigger status of the Ready object is 0 (False).
3.
When the trigger is "fired", the trigger status is set to 1 (True), and object
status = Busy.
4.
While Busy, the message is successfully delivered, or a validation error
occurs.
5.
The object status is then set to either Done, or Error.
Trigger attribute remains True.
6.
Ready state.
Note (*) AutoReset does not take effect if the Status attribute's value is
anything other than Done. If the AutoReset attribute is set to 1 (TRUE), the
Status attribute's value is Done and the Trigger attribute's value is 1, the object
automatically sets the Trigger attribute's value to 0 (zero), causing the object to
transition from the Done state to the Ready state on the next scan of the
application engine. Otherwise, the application logic is responsible for resetting
the Trigger attribute's value to 0 (zero). For example, a PEM object will never
"AutoReset" out of the Error Status, and requires a manual or scripted reset of
the Trigger attribute before the object will return to the Ready Status.
30
Chapter 2
Object Monitoring is recommended for both With Response and Without
Response object configurations.
Monitoring Without Response Messages
Monitoring Without Response messages is necessary in the case where the
Auto Reset option is set and the object generates an error. The trigger state will
not reset to False when an error occurs.
In this case, the Error condition should be monitored to raise an Alarm (not
the trigger status), and at least one InTouch operator station should be
configured to subscribe to such an alarm. Otherwise, data is not logged
correctly and the object appears to be operating normally.
Error messages in this configuration are written to the
ProductionEventMessageError table.
Monitoring With Response Messages
When using messages With Response, it is necessary to monitor the object
message using scripts. This is because all error information is returned directly
to the object rather than being stored in the database. If an error occurs,
regardless of the state of the Auto Reset attribute, the object will remain in the
Error state and will not process a new message until the error has been cleared
by setting the Trigger attribute to False.
As an application designer, one must take this eventuality into account by
creating screen/HMI elements that will monitor for a Status of Error, and that
will clearly display the string value contained in the ErrorMessage attribute,
which is the error returned to the object from the Production Message Service
in the case of error.
No error information or history will be maintained for objects configured as
With Response. The trigger status is True until the object state is either Done,
or Error. The object status changes to Ready when the message is sent
without error.
For more information on Object Monitoring and a script example, see
"Monitoring PEM Objects" on page 85.
PEM Data Relationships
C H A P T E R
31
3
This chapter explains the PEM Automation Object data relationships.
The term "data relationships" in this context refers to the way production data
is linked:
•
Externally: To ISA-95 Definitions: Objects and their attributes are
manifestations of the ISA-95 Part 1 / Part 2 Object model, specifically the
Production Information and a small part of Scheduling Meta-objects.
•
Internally: To the ProdDB relational database. The data is exposed as
views closely following the underlying physical model of ISA-95, and in
more complex views that are pre-joined to natural relationships like
parent-child. The data is viewed in context using the SuiteVoyager
Production Events Module content units.
Note Using 3rd party reporting tools for queries to the views is supported
while direct access to the tables is not, since the raw schema may change over
time. Instead, all query and analysis tools should use the PEM Views to obtain
the data they need from the Production Database.
PEM object data relationships are designed around ISA-95 standards, and are
implemented to provide production data in the relationships defined by the
standards. These relationships are explained in the following chapter.
The following information provides a high-level overview of ISA-95, and a
detailed description of PEM data relationships. Note that while most attribute
values are optional - differing from the ISA-95 standard - the resulting
business value could be reduced when all of the ISA-95 schema relationships
are not leveraged.
Note PEM objects are not intended to be ISA-95-compliant, but to facilitate
rapid enterprise integration. For more detailed information on ISA-95
definitions and standards, see ISA documentation.
Contents
•
•
•
About ISA-95
PEM Views
32
Chapter 3
About ISA-95
ISA-95 is a multi-part set of standards that defines the interfaces between
enterprise activities (Business Systems) and Production Management. Thus its
focus is on Production Management and its interfaces to Enterprise ERP
systems and the Control layer (where required) and control activities
(Manufacturing Systems). The standards provide formalized models for
exchanged data between business systems and manufacturing systems.
The models provide definitions of Manufacturing Operations Management.
The definitions allow systems of the plant floor to integrate with other systems,
say a LIMS system recording results integrated to the Production Information
store.
It models plant capacity, definition of resources, definitions of processing and
requirements, the scheduling details, and production performance, which is the
target of the PEM objects.
The ISA-95 Standard includes the following parts:
•
•
•
Part 1: Models and Terminology
Part 2: Object Attributes
Part 3: Activity Models of Manufacturing Operations Management
Note The following materials focus on Part 1: Models and Terminology and
Part 2: Object Attributes.
The standard is implemented in the context of a collaborative manufacturing
environment.
Collaborative Manufacturing Environment
Collaborative Manufacturing takes place when information is exchanged
between Business Systems and Manufacturing Systems. However, the two
systems have different goals and different success criteria.
The following table provides an overview of the two systems:
Business Systems
Manufacturing Systems
Time Horizons:
Time Horizons:
•
•
Long Term View.
Real-time View.
Model Detail:
Model Detail:
•
•
Linear route structures.
Complex routes with rework
paths.
Control Emphasis:
Control Emphasis:
•
•
Product cost and overall
profitability.
Physical movement &
accountability.
Modeling Criteria:
Modeling Criteria
•
•
Accounting reference points.
•
Has inventory value changed
significantly? If not, don’t model
separately.
Material Movement reference
points.
•
Does product stop moving? If
not, don’t model separately.
View from the Boardroom.
33
View from the Workcenter.
Collaboration takes place when information is exchanged in a structured way,
on a regular basis, between the systems.
Exchanged Information Categories
The PEM objects address the Production Response definition within the
Production Performance ISA-95 category of exchanged information between
these systems.
Relationship to ISA-95
PEM objects represent information defined in the ISA-95 Production
Performance category. This category includes the following production cells:
•
•
Production Request
Segment Response
•
•
•
•
•
•
Material Produced Actual
Material Consumed Actual
Personnel Actual
Equipment Actual
Production Data
Production Response
34
Chapter 3
The following figure represents a portion of an ISA-95 Production
Performance model, and illustrates the Segment Response cell with its
associated elements. Note that the Segment Response cell may contain the
other elements (they are not required). Each element cell below Segment
Response corresponds to a PEM object:
Production
Performance
is made up of
Production
Response
is made up of
Segment
Response
May contain
Production Data
Personnel Actual
Equipment Actual
MaterialProduced
Actual
MaterialConsumed
Actual
ConsumableActual
Note The MaterialMoveActual object is not represented in the previous
figure, since it is implemented as a combination of MaterialConsume and
MaterialProduce.
The following figure describes the relationship between the attributes of the
MaterialConsumableActual object defined in the ISA-95 standard and the
PEM MaterialConsumableActual object attributes and data tables:
ANSI/ISA-95.00.02
PEM Object
Base Template
$MaterialConsumableActual
SQL Server View
ISA-95 Definition:
Consumables Actual
SQL Server ProdDB
Data Table
ConsumableActual
ProdPerf_ConsumableActual
Attributes:
Columns:
ActualDateTimeUTC
UTCOffset
EventMessageGlobID
Material Definition
Descripition
Material Definition
Descripition
Location
Location
Quantity
Quantity Unit of Measure
Quantity
The ANSI/ISA standards
define basic production
objects and their attributes.
The PEM object sends
configured attribute
information to the
Production Services.
The SQL Server Views provide
information in a Genealogy context from
the corresponding ProdDB Data Table,
or a combination of related tables.
Production Services parses
and writes the information
to the correct data tables.
The View is accessed by one or more
Table Weaver objects within
SuiteVoyager for reporting purposes.
Quantity Unit of
Measure
The ProdDB Data
Tables are constructed
around the ISA-95
standards.
Note The object definition information is derived from ANSI/ISA-95.00.022001.
35
ProdDB
The ProdDB database consists of data tables which contain data captured by
configured PEM object attributes. The columns contain PEM object attribute
data and map back to the ISA-95 definition for that attribute.
The data is recorded with two ID values:
•
Each data point is assigned a GlobalID number. This number is used by
the system to join and assigns the data to logical groups. This number is
also referenced by .xml style sheets. The GlobalID number may also be
relied on for parsing XML documents with style sheets.
•
Each data point is assigned an ID string. This string is configured by the
user from within the Object Editor as a user-defined identifier in the ID
field to further enhance the user experience in lookup and context filtering.
Serial Numbers
Serial numbers are handled differently within the ProdDB than in a strict ISA95 definition. In the ISA-95 definition, a serial number is a property of an
object, similar to a name or value.
The PEM data schema defines the serial number in a separate table
(SerialNumberData) as its own entity, with links to the
MaterialProducedActual and MaterialConsumedActual tables.
Note For detailed information on Serial Number implementation, see "Serial
Number Data" on page 70.
PEM Views
Views are virtual tables whose structure and contents are defined by a SQL
Query. A view returns a set of named columns and data rows that are defined
within the query. They are produced dynamically when the view is referenced
by another SQL query or script.
The data from the ProdDB tables are organized and made available to the enduser (client application) using SQL Server views. The views are installed with
the ProdDB.
Views provide the client with logical data groups, and do not require extra
storage nor extra processing. PEM Views are a "shorthand" means of
predefining queries and result sets.
Note Views are designed to be used by external reporting analysis tools.
Reporting from and/or modification of the data tables is NOT supported and
could result in serious damage to the data tables.
36
Chapter 3
Common Characteristics
The PEM views directly support the ISA-95 schema. They will be sufficient
for the vast majority of production management information retrieval
requirements. A number of views support application development functions
that are related to the events themselves; these views will normally include
'event' somewhere in their name.
All table views that include ISA-95 date-time information include the ISA-95
attribute name (i.e. ActualDatetime) with the UTC time zone offset (i.e. UTC
Offset) as well as the same time attribute expressed as UTC Zulu time (i.e.
ActualDatetimeUTC), time zone zero(0).
The physical database schema relies on the use of Global Unique identifiers as
surrogate keys to ensure uniqueness across events and across
databases/servers. These columns are then exposed in views for establishing
relationships between entities.
Note The database schema are not intended for end-user display.
Views may not include all ISA-95 columns, or the columns available may not
all be available for manipulation.
No attempt should be made to leverage or override these 'unused' columns
since additional content and feature sets in the future will likely use most, if not
all, of them to provide enhanced capabilities.
Note For detailed information on Views in the context of reporting, see
Chapter 6, "Visualizing PEM Data in the SuiteVoyager™ Portal."
PEM Validation
C H A P T E R
37
4
PEM Validation
Each PEM object contains built-in validation behaviors for both Production
Attributes (PAs) and Extended Production Attributes (EPAs).
The attributes and validation behaviors are configured according to the
validation type required by the process. For example, a process order number
could be validated against an Excel spreadsheet containing valid order
numbers. A user may require comparing LotID against table of valid Lots, or
validating Material ID against table of Materials.
This chapter contains a summary of PEM validation types, and detailed PEM
object behaviors in the context of validation.
Contents
•
•
PEM Validation Summary
Validating Against External Tables
38
Chapter 4
PEM Validation Summary
Each PEM object editor (IDE) pane includes a Validation tab. The Validation
behaviors (appearing on the User Interface) are listed below:
•
•
•
•
Pattern Matching
Unique or Exists
Table Name/Column Name
Value Optional
All aspects of the validation information for any PEM object attribute is
configured from within the Validation tab field.
Object and Server Validation Tasks
Some validation occurs at both the object and the server level.
Object-Level Validation
The object verifies that the quality of the "trigger" attribute is "Good." If not,
the event message is not sent to the server. This is done because if the quality is
not Good, we cannot be sure if the trigger attribute was real or not.
Server-Level Validation
The remainder of the validation tasks are performed at the Server-Level:
•
•
•
Pattern Matching.
•
•
•
Context error: At least one of the required values wasn’t provided.
Exists/Unique.
Missing one or more values (i.e.: user indicated they wanted to log it, but
no value was provided).
String lengths: Verify all the strings attributes have appropriate lengths.
Attribute Value Quality: Verify all data attributes have "Good" quality.
Validation Behaviors
When Enable Validation at Runtime is selected (from the General tab), the
triggered PEM object informs the Production Service to perform validation for
its attributes with Validate Attribute selected.
For example, if 'Pattern Matching' is enabled, the PEM Production Service
compares the corresponding object attribute(s) with the pattern string.
Validation Errors Without Response
Validation errors are written to the ProductionEventMessageError table in
the ProdDB and viewed using PEMErrorViewer. No validation errors are
returned to the object in this configuration.
PEM Validation
39
Validation Errors With Response
Validation errors appear in the corresponding object's .ErrorMessage and
.ErrorCode attributes. Error messages are viewed using Object Viewer or the
HMI application.
Note No validation errors are stored in the database in this configuration. Be
certain to configure the application to closely monitor the Status and
ErrorMessage attributes so the user can react accordingly.
Validation Source Updates
The PEM object must be updated during configuration time to change which
table it uses for validation. This allows the designer to designate the target
table, based on events or context.
Common Validation Configuration
PEM object validation requires a value for at least one Required (asteriskmarked) Production Attributes configuration setting to pass the validation for
the event. If one or more object attribute settings have Value Optional
selected, there must be another Required object attribute value logged in order
to pass the validation for the object.
Pattern Matching
The following wildcards are provided for positional pattern matching:
•
•
•
'#' position must contain a digit.
'&' position must contain a letter.
'@' position must contain a alpha-numeric character.
DB Table Validation
• Unique option: Used for database validations. Indicates the attribute value
must not already exist in the database table and column name specified in
Table Name and Column Name.
•
Exists option: Used for database validations. Indicates that the attribute
value must exist in the database table and column name specified in Table
Name and Column Name.
The Table Name field entry must match the target table name exactly. The
target table name cannot contain any spaces.
The Column Name entry field must match the table’s column name
exactly. The column name cannot contain any spaces.
•
Value Optional option: Allows an empty value for the selected object
attribute. Value Optional is only valid on String object attribute types.
40
Chapter 4
Validation Examples
The following examples describe pattern string validation and a SQL database
table validation.
Pattern String Validation
The object attribute value must match the pattern string specified in the
Validation tab.
For example, you want to validate the Production Request ID matches a certain
pattern for a MaterialConsumedActual. For example, PR### as shown in the
following figure:
When validation occurs, you can use Object Viewer to view the attribute status
and any possible validation errors.
Database Validation Example
The object attribute option must be Unique or Exists in the designated
database table. For example, you want to validate the MIDTable database
table for a MaterialConsumedActual. The information in the table storing the
Material ID must match or exist in the validation field.
The following figure shows an example of a database table MIDTable and a
column name called MIDNumber located on the local node:
Validating Against External Tables
PEM validation requires that the validation table must exist within the PEM
database (ProdDB). Any number of SQL tables may be created.
However, it is often necessary to use external tables for validating attribute
values supplied to the transaction. External tables exist either in a different
database on the same machine, or on a remote machine.
If a validation table exists in a separate local or remote database, a SQL Server
Linked Server relationship must be created to point to the existing table. The
Linked Server is a link to the other database that is transparent to the client. In
other words, the external database appears to the client as a part of the ProdDB.
PEM Validation
41
About the Linked Server Relationship
Each external data source used for Exists/Unique Validation (database table,
Excel spreadsheet, Access database, .csv files, text file, etc.) must be
configured as a "Linked Server" within Microsoft SQL Server Enterprise
Manager. The data source will then appear as another table in the Production
Database. While it isn’t actually located in the database, its data is accessible
using a simple SELECT statement.
For example, if you configure an Excel Spreadsheet that contains today’s list of
Orders on Sheet1 as a Linked Server, and call the linked server TodaysOrders,
you can then query the contents of Sheet1 as follows:
SELECT * FROM TodaysOrders…Sheet1$
That query retrieves all the rows from Sheet1 on in the Excel spreadsheet
TodaysOrders.
From the PEM user's perspective, when you configure Validation to check for
the existence or non-existence of an item in that Excel spreadsheet, you
provide the linked table reference and the column name.
In this case, those would be:
•
Table Name: TodaysOrders…Sheet1$. The three dots ( … ) are not
arbitrary, but required to reference the linked table.
•
Column: OrderID (as an example).
Configuring a Linked Server Relationship
The following example describes a scenario in which the user needs to link an
Excel Spreadsheet into their existing SQL Server so it can be accessed as a
table during PEM object validation.
Note For this example, it is assumed that an Excel spreadsheet has been
created and contains the necessary information on Sheet1.
To configure a linked server relationship
1.
Launch SQL Server Enterprise Manager.
2.
Expand the server icon of the target server.
3.
Expand the Security folder.
4.
Right-click Linked Servers and select New Linked Server.
The Linked Server Properties dialog box appears:
5.
Enter a name for the linked server.
6.
Select SQL Server or Other data source. For this example, select Other
data source (Excel Spreadsheet).
7.
Select the Provider name from the drop-down list.
8.
The correct provider for Excel (.csv, .txt, and others) is Microsoft Jet 4.0
OLE DB Provider.
9.
Enter the Product Name. For Excel, it is Jet 4.0.
42
Chapter 4
10. Enter the Data source name. The data source could be on the local drive
or a network location. The data source location is similar to the following:
C:\NAMES.xls.
11. Enter the Provider string. For Excel it is Excel 5.0.
Note See SQL Server Books On Line for information about other data
Provider types and data sources.
12. Click OK.
The Linked Server appears as an icon under the Linked Server root. Expand it
to reveal the target table.
The Linked Server relationship can also be verified using SQL Query Analyzer
to execute the following query:
SELECT * from SysServers
The query results confirm that the new server is recognized by the SQL Server
query engine.
The External Data Source can now be accessed using a SELECT statement:
SELECT * from <LINKEDSERVERNAME>...Sheet1$
Optional: Configuring Security
Data sources may require login or access credentials. For example, CFR
regulations contain guidelines about access from properly-certified
individuals. The Security tab of the Linked Server properties dialog box
contains security configuration settings.
•
Local logins can be associated with remote users and their passwords,
allowing multiple users and their credentials to be configured.
•
The default authentication that is sent to the Linked Server for users who
try to access this Linked Server but are not defined in the list above.
Creating a Basic PEM Production System
C H A P T E R
43
5
Creating a Basic PEM
Production System
This chapter provides a high-level recommendations for creating a Production
Tracking System using the PEM objects.
It includes a suggested system topology, explanations of manufacturing types,
data collection considerations, and general information on system scalability.
Contents
•
•
•
•
•
PEM System Topology
Deploying PEM Components
About Manufacturing Types
Collecting and Delivering Accurate Data
Scaling the PEM System
44
Chapter 5
PEM System Topology
The following figure describes a simplified topology for a typical PEM
Production System. It includes the following:
•
•
•
•
SFC and Production Scheduling Node
IAS Redundancy (GR Node and IAS-Backup with InTouch View)
Historian Node: Includes ProdDB and PEM Production Services
SuiteVoyager Portal node (Table Weaver Production Events Module
Content Unit)
SuiteVoyager WWW
Reports
OS Group-Based
Security
ERP / Enterprise
IAS – GR Node
InTouch Master NAD
Historian Node:
SQL Server/ProdDB
Production Services
AlarmDB Logger &
Database
Domain
Controller
Engineering
IAS – Primary InTouch
View/NAD Client
Operator Station –
InTouch View (NAD Client)
IAS – Backup
InTouch View (NAD Client)
Control Room
PLCs
SFC and
Production Scheduling
Production/Plant Floor
PEM Component Installation Notes
The following information describes PEM component installation
recommendations. In general, 3 separate server-level machines are
recommended on a distributed network:
•
PEM Objects: Install into the Galaxy using a standard Import operation
using the IDE.*
•
PEM Services: Must be installed on the Historian (IndustrialSQL Server)
Node.*
•
Production Events Module Content Units component: Install on the
SuiteVoyager node.*
* For specific hardware requirements, see that product's documentation.
Note For PEM system security recommendations, see "PEM Object Security"
on page 16.
45
Deploying PEM Components
The PEM objects can be deployed to any AutomationObject node. The
following information describes recommended deployment scenarios:
Single Platform/Single Engine
Client Node:
Multiple PEM objects
Single Platform
Single Engine
Historian Node:
SQL Server/ProdDB
Production Services
Engine
Platform
Multiple PEM objects are deployed on a single Engine, on a single Platform.
The data is written to the ProdDB on the Historian Node.
Single Platform/Multiple Engines
Client Node:
Single Platform
Multiple Engines
Historian Node:
SQL Server/ProdDB
Production Services
Engine
Engine
Platform
Multiple PEM objects are deployed on multiple Engines, on a single Platform.
The data is written to the ProdDB on the Historian Node.
Multiple Platforms/Multiple Engines
Client Node:
Single Platform
Multiple Engines
Engine
Engine
Platform
Historian Node:
SQL Server/ProdDB
Production Services
Client Node:
Single Platform
Multiple Engines
Engine
Engine
Platform
Multiple PEM objects are deployed on multiple Engines, on multiple
Platforms. The data is written to the ProdDB on the Historian Node.
46
Chapter 5
Multiple Historian Nodes
Client Node:
Single Platform
Multiple Engines
Historian Node:
SQL Server/ProdDB
Production Services
Engine
Engine
Platform
Client Node:
Single Platform
Multiple Engines
Historian Node:
SQL Server/ProdDB
Production Services
Engine
Engine
Platform
This scenario is possible in a widely-distributed environment. The following
conditions apply to this scenario:
•
•
•
Use multiple Historians for related and separate production lines.
•
Cross-Historian data visualization is possible using multiple SuiteVoyager
Content Units but the data is not related across Historians.
Use multiple Historians in a case where network optimization is necessary.
Data related by genealogy must be written to a single Historian node.
Storing related data to multiple Historians is not supported.
About Manufacturing Types
Manufacturing types can be grouped into three basic categories that either
individually or in combination, describe every manufacturing environment.
•
Discrete: Lot-based, identifiable component materials are assembled or
combined into a unique, identifiable produced material.
•
Batch: Various identifiable component materials (usually a combination
of bulk and lot-based) are combined into a unique, identifiable produced
material.
•
Continuous: Various component materials (usually bulk, flowable
materials) are combined into a bulk, flowable output material.
Each of these manufacturing types has unique characteristics that must be
considered when applying the Production Events Module to create a
Production Tracking System.
The basic problem is that, in any manufacturing type other than discrete, there
may not be a clear correlation between when input materials are being used
and when the finished material is being produced. In order to address this
situation, both the process designer and the Production Tracking System
developer must take steps to make the process as 'discrete' as possible.
47
Discrete Manufacturing
The PEM objects are easily configured to record and relate production events
in a Discrete Manufacturing environment. The basic processes of "Assembly"
or "Build" have clearly designated input materials (often measured as single
items) and clear output materials (often single final product). This normally
also implies a structured Bill of Materials. As a general rule, input materials in
a Discrete environment can be physically picked up. They are often
individually identified with serial numbers.
(1) Part A
+ (1) Part B
+ (1) Part C
-----------Final Product 001
This is the simplest application of the PEM objects because events are
naturally related to an individual product. Genealogy is straight-forward.
Note The following example contains input materials such as glue or paint,
which are also valid material types even though they cannot be "picked up."
Other discrete environments will include similar input materials.
Discrete Manufacturing Example
This Discrete Manufacturing Process example produces packaged chairs.
The PEM objects are configured to observe and record genealogy.
The process has three steps:
•
•
•
Assembly
Finishing
Packaging
Each step consumes and produces materials.
48
Chapter 5
The following figure describes the process steps and a suggested Genealogy
structure.
Note For detailed information on the Production Request ID, Process
Segment ID, and Segment Response ID attributes, see "PEM Object
Genealogy Configuration" on page 62.
Production Request ID WIPLOT#
Process Segment ID
Operation Name (Hardcoded)
Segment Response ID PRID + PSID
SN + PSID
Production Request ID
ABC-001
Process Segment ID
Process Segment ID
Process Segment ID
A
F
P
Segment Response ID
Segment Response ID
Segment Response ID
ABC-001-A
ABC-001-F
Assembly
Chair Kit
Unfinished
Chair
Glue
Finishing
ABC-001-P
Finished
Chair
Packaging
Chair
Package
Paint
The following information describes the process.
Assembly Step Attributes
• Consumes a Chair Kit and Glue.
• Produces an Unfinished Chair.
• The MaterialConsumedActual object is used to record material Lot
consumptions.
•
For Lot-based genealogy to work, the Lot from which materials are
consumed must be logged, and the Lot to which materials are being
produced must also be recorded.
•
•
•
49
Assembly has two MaterialConsumedActual objects:
•
MCA_ChairKit: Logs the lot from which we are consuming Chair
Kit.
•
MCA_Glue: Logs the lot from which we are consuming Glue.
Assembly has one MaterialProducedActual object:
MPA_UnfinishedChair
•
•
Records what was produced in Assembly.
Logs the lot to which we produced Unfinished Chair.
There is one pair of Consumed and Produced objects. In this example, ALL
events contributing to the production of a lot of Unfinished Chairs will be
associated with the same Segment Response ID (ABC-001-A).
The two material consumption objects and the one material production object
in the Assembly step each log the Lot attribute.
In order to know which Lots were consumed by a specific Unfinished Chair
Lot, connect the events using the Segment Response ID (SRID). This
provides the context necessary to connect the Consumption and Production
events for reporting.
Because we produce an Unfinished Chair Lot each time through the Assembly
step, the SRID must change each time through the Assembly step.
For example: The first time through Assembly the SRID is logged as ABC001-A for both consumption objects and the production object:
MCA_ChairKit, MCA_Glue, and MPA_UnfinishedChair.
The next time through the Assembly the SRID will be logged as ABC-002-A.
Finishing Step Attributes
The Finishing Step is set up the same way as the Assembly Step:
•
•
Consumes: Unfinished Chair and Paint.
Produces: Finished Chair.
PEM Objects:
•
•
•
MCA_Unfinished Chair
MCA_Paint
MPA_FinishedChair
The Segment Response ID (ABC-001-F) for the Finishing Step must be
different than the Segment Response ID for Assembly.
For example: The first time through the model the SRID for MCA_ChairKit,
MCA_Glue, and MPA_UnfinishedChair is ABC-001-A, while the SRID for
MCA_UnfinishedChair, MCA_Paint, and MPA_FinishedChair is ABC-001-F.
In order to have Lot-based genealogy work between Assembly and Finishing
the consumption of Unfinished Chair in Finishing must be from the same Lot
to which Unfinished Chair was produced in Assembly.
50
Chapter 5
Packaging Step Attributes
The Packaging step is set up the same way as the first two steps.
•
•
Consumes: Finished Chair.
Produces: Packaged Chair.
PEM Objects:
•
•
MCA_FinishedChair
MPA_PackagedChair
The SRID used for Packaging must be different from the one used in Assembly
and Finishing (ABC-001-P).
For Example: The first time through the model the steps had the following
SRIDs: ABC-001-A, ABC-001-F and ABC-001-P.
In order to have Lot-based genealogy work between Finishing and Packaging,
the consumption of Finished Chair in Packaging must be from the same Lot to
which Finished Chair was produced in Finishing.
51
Batch Manufacturing
A Batching manufacturing environment has some specific issues when trying
to record production events.
Input materials for Batch operations are usually pulled from bulk storage
(tanks, containers or directly from a prior continuous production step) and
some discrete materials (additives, catalysts, etc.). Since the bulk sources are
constantly receiving new input materials, it may be virtually impossible to
determine exactly which material is currently being delivered to the process.
Further, these materials usually arrive at the process via some flow mechanism.
This makes it difficult to identify precisely when a material that left the storage
vessel actually arrives at the process.
In many Batch environments, there is a legal and regulatory requirement to
identify sources and characteristics of all input materials. It will be necessary
to work closely with the process designers to provide distinct measurement
points.
For example, the physical process operating procedure may impose constraints
such as a requirement to empty a storage tank completely before adding new
material. Additionally, there is often a purge and clean process that ensures
there will be no contamination between batches. Delivery systems may require
some flow measurement to determine the time lag between material leaving a
tank and arriving at a process.
These triggering mechanisms will allow for the design of a Production
Tracking System that generates genealogy for a Batch process.
The following figure shows a simplified batch process that includes produceconsume event pairs and other PEM object applications in a Batch
environment:
Consume from Trucks
Produce to Storage Tank A
Consume from Additive
Produce to Processing Units
Consume from Multiple
Processing Units
Produce to Storage Tank A
Consume from Processing Unit
Produce to Waste
Storage
Tank
A
(Produced)
Produce to Waste
Produce to Waste
Consume from Storage Tank A
Produce to Bottles
Consume from Storage Tank A
Produce to (Multiple) Processing Units
Produce to Waste
52
Chapter 5
Continuous Manufacturing
The Continuous Process Manufacturing environment has always presented
special challenges for Production Recording. The nature of the continuous
process implies that there are few clear start-stop points by which to group and
report production. The usual approach to this issue is to create some kind of
'virtual' grouping. This is often a time-based unit such as day, shift or hour.
This approach can be applied when using the PEM objects to capture events in
a Continuous Process. The Process Segment would still be defined as the static
process (i.e. Refining). The Segment Response ID, which always serves as the
unique identifier, would be defined as a unique time-period virtual bucket (i.e.
Day240Shift01Hour16). The Production Request ID is then left to define the
Production Order which may run for hours, days or months.
As with Batch systems, it may be possible to impose some procedural steps to
help establish some correlation. Delivery systems may use some flow
measurement to determine the time lag between material entering the process
and product leaving a process.
Ultimately, there is no true genealogy in a continuous environment. A report
can be produced that captures the history of material, equipment, personnel
and data events that occur during a defined segment of a continuous process
run.
Collecting and Delivering Accurate Data
PEM provides a context to an individual collection of production data and
stores it in a database whenever a production event occurs. The production
event is triggered whenever a condition is met.
It is critical to give significant consideration to synchronizing the trigger for a
production event and ensuring the production data collection contains the
correct (targeted) values. When the trigger is not synchronized with the
expected (actual) production collection values, the wrong values will be stored
and result in false analysis/reporting.
Data Collection Considerations
•
•
Do I trigger a production event in the PLC or in IAS?
•
Is losing production events (During IAS failover or other communication
interruption) critical to your process?
How do I make sure all the production data collection that needs to be
stored arrived to IAS before trigger the production event? (implement a
handshake and/or use block read).
These considerations can be addressed by the following implementations:
A. Implement a robust, redundant hardware architecture.
B. Implement a watchdog between the PLC and IAS so the PLC pauses
its process and resumes it when IAS is back up and running after a
failover.
53
C. Implement a buffer (queue) in the PLC to hold all the production data
collection and create handshake between the PLC and IAS that will
trigger production events to process this queue (this queue should be
able to hold a certain amount of production events and their relevant
production data collection). This option is discussed in the following
section.
Note The timing of the attribute updates and the trigger execution is critical
and may require attention to the execution order of the related objects.
Event Triggers
PEM objects can be triggered either by using the native trigger
(MyPEMObject.trigger) or by specifying an Input Source (external).
For example, the Input Source might be directed to look at a machine start
signal from an I/O device. The trigger might also be pointed to an attribute that
is set within an IAS script. This enables the solution designer to evaluate any
conditions that must be met before executing the transaction.
When a PEM object executes, it collects the values of all of the attributes it is
configured for and assembles the transaction. Care must be exercised to ensure
that all of the attributes referenced have been appropriately updated and/or not
overwritten.
PLC Queue Characteristics
The following information describes creating a Queue or "buffer" at the PLC
level. The buffer is created to ensure that all relevant data is collected for the
event and that it represents the event accurately.
Note The following information is intended to be "generic" and does not
apply to all PLC models.
PLC Data Collection Events
In this example, the following data collection events occur:
A. A bag is weighed and the value stored to the PLC register.
B. The moisture content is measured, and the value stored in the PLC.
C. A temperature is measured and stored in the PLC.
D. A Barcode is scanned, and recorded with the "Queue Length" value.
The barcode scan event triggers the data (weight, moisture, temperature,
barcode) to be transferred to the PLC queue.
PLC Queue Operation Events
A. If the barcode register contains a value, all data is stored in the next
available queue location.
B. Clear the barcode register contents.
54
Chapter 5
C. Increment the register containing "Queue Length."
Production Event Script Logic
Note UDA_Trigger is connected to the Stage Set bit within the PLC.
A. When UDA_Trigger is set to 1 by the PLC, the following occurs in a state
aware, while true AppObject script, attached to the PEM Event object:
B. Verify that the Read Complete bit from the previous transaction has
returned to zero (hand-shaking mechanism).
C. The Reading Stage bit in the PLC is set to 1 so the PLC knows we are
reading the staged values and can no longer touch them until we are done.
D. A block read is initiated via the DIO (Device Integration Object) to
retrieve the staged values.
E. When the block read is complete, the real trigger attribute on the PEM
object is set to 1, causing the object to store the values to the ProdDB.
F.
When the PEM object returns to the Ready state, the Read Complete
register is set within the PLC to indicate that the PLC is free to pass in the
next staged values.
Interrupted Data Collection
The following information describes data collection interruptions between:
•
The data source (PLC, other computer, etc. that provides the conditions for
the production event and sends them), and;
•
The ApplicationServer, where all the data processing occurs.
Data collection can be interrupted for various reasons:
•
•
•
Communication failure.
•
•
•
Machine shutdown.
Hardware malfunction.
Failover time period and/or failover scenarios (Active-Active engine
states).
Catastrophic failure.
Other failure.
The PEM objects and the underlying Production Messaging Service have been
designed to be robust in the face of communication and hardware failure and
misconfiguration. In almost all cases, production even data will be preserved
and eventually delivered to the Production Database without error.
In some rare instances, where the IAS system is configured for Redundancy,
and there are multiple network and communication issues between the Primary
and Standby nodes, a condition may arise where there are two active
Application Engines, both hosting the same PEM object. In this case, multiple
data entries may occur for a single event.
55
Duplicated data will significantly impact system performance and
visualization/reporting.
Note This information assumes data is transmitted from a PLC and that a
redundant engine pair is configured on the AppServer node.
Best Practice
If both PLC registers are determined to be inactive (communication failure,
etc.), the data is stored in a PLC buffer until one register becomes active.
To avoid redundant data generation, configure a "watchdog" script at the PLC
that monitors the active status of the PLC registers.
In this scenario, the AppEngine communicates with "Registry1" (primary
engine) and "Registry2" (backup engine).
When both Registries are determined to be active, the script sends the PLC a
message to Pause production and generate an alarm (or similar action). The
data is stored in the buffer until only one register remains active.
56
Chapter 5
Scaling the PEM System
The following section describes two PEM System scalability scenarios. These
scenarios were tested as part of a series of internal tests:
•
Scaling Out: Adding separate Platforms (nodes) to an existing system for example, adding machines at separate production facilities. Each
remote node sends production event data to a central Historian node.
•
Scaling Up: Adding separate Engines (production lines) to an existing
node - for example, routing all PLC data to a single Platform.
Production Server Node Specifications
The following specifications are provided for reporting purposes (to provide an
example of "typical" Server node) and are not intended to be used as a formal
recommendation:
CPU
2.0 GHz Pentium P4
Network Card
Integrated Fast Ethernet Controller
Speed
100 Mb/s
RAM
1024MB
OS
Windows 2003 w/applicable Service Packs
The PEM objects host nodes (clients) include a similar configuration.
The following information is derived from Integration testing data and is
intended to serve as a loose framework from which to plan scaling of a PEM
system. The data was collected using Windows Performance Monitor, then
combined in a readable format using Microsoft Excel.
The figures represent averaged data across approximately 20 minutes (between
points).
Note The following data is not intended as a predictor or guarantee of system
performance in either scenario.
57
Scaling Out
The following graph represents the use of the
aaProductionMessageDispatcher. Service counter values as each platform
(node) is added to the system:
% Processor Time
aaProductionMessageDispatcher
0.5
0.45
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
1
2
3
4
5
6
7
8
9
10
Platforms/Nodes Added
The following graph represents the total messages in the queue and the
weighted average value of the bytes in the queue over the time span. A value of
> 1 means that messages are processed quickly over the time period.
0.3
4000
3500
3000
2500
2000
1500
1000
500
0
0.25
0.2
0.15
0.1
0.05
Bytes in Queue
Messages in
Queue
MSMQ Incoming Messages
0
1
2
3
4
5
6
7
8
9
10
Platforms Added
Messages in Queue
Bytes in Queue
58
Chapter 5
Scaling Up
The following graph represents the use of the
aaProductionMessageDispatcher. Service counter values as each engine
(representing a different production line on the same node) is added to the
system:
aaProductionMessageDispatcher
0.45
% Processor Time
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
1
2
3
4
5
6
7
8
9
10
Engines Added
The following graph represents the total messages in the queue and the
weighted average value of the bytes in the queue over the time span. A value of
> 1 means that messages are processed quickly over the time period.
5000
0.3
4000
0.25
0.2
3000
0.15
2000
0.1
1000
0.05
0
0
1
2
3
4
5
6
7
8
9
Engines Added
Messages in Queue
Bytes in Queue
10
Bytes in Queue
Messages in Queue
MSMQ Messages in Queue
Visualizing PEM Data in the SuiteVoyager™ Portal
C H A P T E R
59
6
Visualizing PEM Data in the
SuiteVoyager™ Portal
PEM objects use a Lot-Based Genealogy strategy for viewing PEM
information inside the SuiteVoyager portal. LotID is a required field for all
applicable PEM objects.
This chapter focuses on using the SuiteVoyager portal for data visualization. It
provides a hi-level summary of the various PEM components, and how they
provide Lot-Based Genealogy (production data) within the SuiteVoyager portal
environment.
Contents
•
•
•
•
•
About Production Events and Historization
About Genealogy
PEM Views
Production Events Module Content Units for SuiteVoyager
(Summary)
Serial Number Data
60
Chapter 6
About Production Events and Historization
PEM objects are designed to enable maximum flexibility when configuring the
object to record event data.
Selecting individual objects' Production Attributes such as Serial Number List
or Quantity provide basic historization, which ensures that specific data
(necessary to understand the context) is written into the ProdDB database
when a production event occurs. The data is then preserved and viewable using
views as part of SuiteVoyager content units.
PEM objects are also designed to store data in a specific, related context based
on ISA-95 definitions. PEM provides the means to link production events
using Production Attributes configured in specific combinations to provide the
ability to link production data from raw material to finished product,
throughout the course of production. This linking of different events delivers a
genealogy and reverse genealogy when displayed in the PEM content units for
SuiteVoyager.
About Genealogy
PEM defines Genealogy as a method of relating production data
(consumptions and productions) by linking the data with common production
attribute. The common attribute may span a simple Consume/Produce event
pair (consume from a truck, produce to a holding tank), a Process Segment
(Store, Mix, Package, etc.), or the entire production process.
Genealogy, PEM Objects, and SuiteVoyager
When specific PEM object Production Attributes are configured, the generated
event data is available for viewing using the SuiteVoyager Production Events
Module Content Unit component.
When preparing the data for Lot-Based Genealogy, the following 3 production
attributes (PAs) must also be configured in some combination:
•
•
•
SegmentResponse ID
ProcessSegment ID
ProductionRequest ID
The combinations depend on the physical production characteristics and how
the process is defined.
A Segment Response (for tying consume to produce) is recommended. The
user's lookup and filtering experience is enhanced by using all three.
Note The Production Events Module Content Unit utilizes the Table Weaver
Unit of SuiteVoyager.
The Production Events Module Content Units provide pre-configured SQL
queries that present production data in a related context within the
SuiteVoyager portal interface. The queries call the SQL Views that are
provided with the ProdDB.
61
Some of the content units provide the user with the ability to "drill down" into
a specific production event and see all its related data.
Note The Production Events Module Content Units component also
provides other filtered views of configured production attributes.
The content units delivered with PEM 1.0 include one for genealogy within the
PEM context. Genealogy is provided by linking Segment Response ID to Lot
ID. The Lot ID value is assigned at object configuration-time to provide a
common value used to provide common context for the Segment Response,
Process Segment, and Production Request attributes.
The following figure shows how the PEM Production Attributes can be
configured for Genealogy:
Segment
Response ID
Process
Segment ID
Consume
Event
Produce
Event
C1
P1
Production
Request ID
C2
SR ID = 1
P2
C3
C4
P3
SR ID = 4
SR ID = 3
SR ID = 2
PS ID = 1
PS ID = 2
PR ID = 1
P4
Segment
Response ID
Process
Segment ID
Production
Request ID
Note An example of Genealogy configuration within a Discrete
manufacturing environment is provided in "Discrete Manufacturing Example"
on page 47.
1.
SegmentResponse ID: Each Segment Response ID consists of one or
more Consume Event and Produce Events. The segment Response ID
links the events at that level and must contain at least one pair of
Consume and Produce.
For instance, the Consume would normally identify the LOT that was
being consumed (from another location/difference segment entirely - it
can be from anywhere in the plant).
Likewise the outbound Produce MAY label the lot as it is put into storage
or the storage location may can be Lot-labeled during a post consumption.
Recall that a consume-produce pair can be 'virtual' in that nothing actually
occurs other than a relabeling of goods.
62
Chapter 6
2.
ProcessSegment ID: Each ProcessSegment ID may consist of
SegmentResponse IDs. There is no limit to the number of
SegmentResponse IDs within the Process Segment.
3.
ProductionRequestID: Each ProductionRequest ID consists of
ProcessSegment IDs and SegmentResponse IDs. There is no limit to the
number of Process Segments within a Production Request.
PEM Genealogy Summary
•
To begin linking data, each SegmentResponse must include at least a
Consume event and a Produce event in a 1:1 relationship. It is then
possible to configure one-to-many or many-to-many relationships,
depending on your production environment.
It would be normal to consume many different materials (lots) to make a
single output. Likewise, a produced lot (say a premix batch) may be
consumed in may different segments.
It should be noted that the 'end-points' or boundary conditions may contain
very different looking consume / produce where the manufacturer labels
the Lot as their style lot.
•
SegmentResponse ID, Process Segment ID and ProductionRequest ID
attributes are necessary settings for genealogy linking. However, they are
not all required.
•
The level of Genealogy depends on your process environment, required
level of genealogy and reporting needs. For example, it is possible that
SegmentResponse IDs are linked to an entire production line by
configuring multiple Consume and Produce Events.
Genealogy is best supported by understanding what information flow is needed
so that appropriate consumption and production tracking events can be
configured.
PEM Object Genealogy Configuration
The following (common) object attributes are required in some combination to
view genealogy from production data in the SuiteVoyager environment:
Production Request ID
A production request defines a request for production for a single product
identified by a production rule.
A production request contains the information required by manufacturing to
fulfill scheduled production. The Production Request may be bound to things
like maintenance activities. It may also be linked to asynchronous processes
like premix batches.
This may be a subset of the business production order information, or it may
contain additional information not normally used by the business system.
A production request must contain at least one segment requirement, even if it
spans all production of the product.
63
A production request may be reported on by one or more production responses.
In some situations, the material identification and material quantity may be all
that is needed for the manufacturing. Other situations may require additional
information. The additional information may be described in the production
parameters, personnel requirements, equipment requirements, and material
requirements.
Segment Response ID
The production response for a specific segment of production is defined as a
segment response. A segment response may be made up of sets of information
on production data, personnel actual, equipment actual, materials consumed
actual, materials produced actual, and consumables actual.
Process Segment ID
Given the previous definitions, a process segment is a segment of production,
independent of any particular product.
PEM Views
The PEM Views are installed on the ProdDB node to make production data
available to the SuiteVoyager Production Events Module Content Units. The
content units are installed on the SuiteVoyager node and contain SQL queries
and pre-configured links that provide data to the SuiteVoyager portal.
Note Detailed information on the Production Events content unit is provided
in the following section.
PEM Views are always prefixed with a Production Database area identifier,
and correspond to an ISA-95- based object model.
The prefixes are:
Prefix
Content
ProdPerf_ *
Production Performance
ProdSched_ *
Production Schedule
ProcSeg_ *
Process Segment
ProdEvents
Production Events
The views may be further elaborated in the following ways:
•
For each Resource Object (Material Consumed, Material Produced,
Consumable, Equipment, and Personnel) there is a view, i.e.
ProdPerf_EquipmentActual.
•
For each Resource Object there is a respective Property view, i.e.
ProdPerf_EquipmentActualProperty
64
Chapter 6
•
For each Resource Object, there is a Detail view which comprises the
columns of the Resource Object and the columns of its respective Property
view, i.e. ProdPerf_EquipmentActualDetail. The view joins the resource
with it’s properties, returning a row for each property returned.
•
If the view contains 'Event Detail', i.e. Material Consumed Actual Event
Detail, the view combines the resource object properties and the event
detail properties.
The Property tables include a column for Value, which is defined as a
SQLVariant data type, allowing character, integer, float, or datetime for
instance. It is up the user to manipulate this field for its intended purpose. If the
property value is of numeric type, a supplemental column is included for easy
aggregation in a complex query without requiring content specific
manipulation.
Note For a detailed description of each View, see the Production Events
Module (PEM) User’s Guide.
Production Events Module Content Units for
SuiteVoyager (Summary)
The Production Events Module content units provide views within
SuiteVoyager (version 2.5 and later). These content units enable navigational
access to any PEM-provided production data.
The following information assumes that the Production Events Module is
installed on the SuiteVoyager node and that the user has appropriate
administrative privileges to view both the data and specific content unit
components described in this chapter.
Note The Production Events Module content units are provided as a sample
to provide PEM Data in context within a SuiteVoyager portal. They are not
intended to represent data visibility for every production environment.
65
Production Events Runtime
The Production Events Module panel is accessible from the System panel of
the SuiteVoyager Launch Pad area: Table Weaver/Production Events.
Two links are available: Lists and Searches.
Lists
The following List links are available:
•
List EPA Names: Returns a list of the Extended Production Attribute
Names in the ProdDB.
•
•
•
•
•
List Event Names: Returns a list of the Event Names in the ProdDB.
•
List Production Request IDs: Returns a list of the Production Request
IDs in the ProdDB.
•
List Segment Response IDs: Returns a list of the Segment Response IDs
in the ProdDB.
•
List Serial Numbers: Returns a list of the Serial Numbers in the ProdDB.
List Locations: Returns a list of the Locations in the ProdDB.
List Lot IDs: Returns a list of the Lot IDs in the ProdDB.
List Materials IDs: Returns a list of the Materials IDs in the ProdDB.
List Process Segment IDs: Returns a list of the Process Segment IDs in
the ProdDB.
Note Details about serial numbers are included in "Serial Number Data" on
page 70.
66
Chapter 6
Click a specific link to provide a list for the particular item. For example, the
Lot IDs link provides the List Lot IDs view (LotIDs are configured at the PEM
object-level):
Searches
The Searches links provide the following filtered searches:
•
Search EPA Names: Search for a specific or partial Extended Production
Attribute (EPA) in the system.
•
Search Event Names: Search for a specific or partial Event Name in the
system.
•
•
•
Search Locations: Search for a specific or partial Location in the system.
•
Production Attribute Value Search: Search for a specific or partial
Production Attribute (PA) in the system.
•
Search Process Segment IDs *: Search for a specific or partial Process
Segment ID in the system.
•
Search Process Segment ID Time Range: Search for a specific or partial
Process Segment Time Range ID in the system.
•
Search Production Request IDs *: Search for a specific or partial
Production Request ID in the system.
•
Search Segment Response IDs *: Search for a specific or partial Segment
Response ID in the system.
•
Search Serial Numbers: Search for a specific or partial Serial Number in
the system.
Search Lot IDs: Search for a specific or partial Lot ID in the system.
Search Material IDs: Search for a specific or partial Material ID in the
system.
•
67
Search Time Range: Search for a specific or partial Time Range in the
system.
Note The searches designated by an asterisk ( * ) represent the PEM object
attributes that establish genealogy context. The attributes are set at the object
level.
For example, the Search Production Request IDs link provides the ability to
apply filtering to a search for specific Production Requests:
68
Chapter 6
Production Events Module Content Units
Configuration
Configuration of Production Events Module components is accessible from the
System pane of the SuiteVoyager Launch Pad area: Administration/Table
Weaver Manager:
Clicking the Content Unit Component links (right-hand icons) provides access
to the Production Events configuration for that particular content unit.
Note The Content Unit configuration steps are common to all components.
For detailed information on SuiteVoyager Content Unit configuration, see the
SuiteVoyager 2.5 User's Guide.
69
The following example describes the Datasource Content Unit component.
Production Events links are contained in all the component links except KPI’s.
To access a Content Unit Component
1.
Click the Datasource icon.
The Data Source List pane includes a link to ProductionEvents:
2.
Click ProductionEvents.
70
Chapter 6
The Data Source () pane displays the connection string to the ProdDB:
3.
Click the Table Weaver Manager link in the System Launch Pad pane to
return to the Content Unit Component pane.
Serial Number Data
Serial Numbers are collected as strings, with a 1024-byte limit. This
implementation is necessary for full integration into the ArchestrA framework.
The data is collected when serial numbers are configured as an object attribute.
The values are concatenated as string, then inserted into the
SerialNumberData table.
PEM Serial Numbers are considered in the following context:
•
•
Configuration/Collection
Visualization
Configuration/Collection
When a PEM event is configured to collect serial number information, careful
consideration must given to collecting serial number data within the ArchestrA
framework. It is necessary to configure the event (or multiple events) so that
the serial number string limit is not exceeded for that event.
71
For example, assume that a serial number for a particular produced item is 8
characters long, including dashes, spaces, commas, etc. This means that the
event must be configured to capture up to 128 serial numbers at a time. If the
1024-byte limit is exceeded, the event will fail and generate an error.
The events can be triggered at any point in the production process, but would
likely occur at some final production phase like Bottling or Packaging.
Event configuration becomes more complex when considering other serial
number formats included in differing products or from different vendors.
Note To capture the correct serial numbers, it may also be necessary to
configure a delay in an SFC loop until the serial number collection events are
complete.
Visualization
SuiteVoyager returns serial number data as a part of reverse genealogy. When
reverse genealogy data is returned by the pre-configured SQL query
LotIDReverseGenealogy. The query is reproduced below for illustration:
SELECT TOP #Count#
ActualDatetime,
Location,
MaterialLotId,
MaterialDefinitionId,
MaterialSubLotId,
Quantity,
QuantityUnitOfMeasure
FROM dbo.ProdPerf_LotIdReverseGenealogy
WHERE ReverseGenealogyLotId=’#LotID#’
ORDER BY ActualDatetime DESC
This query returns the desired information from the
ProdPerf_LotIdReverseGenealogy view, which performs inner joins on the
MaterialProducedActual and MaterialConsumedActual tables (through other
views). The data in those tables is related to the serial number data stored in the
SerialNumberData table.
This query returns ALL of the data, which appears as duplicated record sets.
For example, each serial number included in both the MaterialProducedActual
and MaterialConsumedActual data sets will be returned.
72
Chapter 6
The following workaround prevents duplicate data from appearing in the
SuiteVoyager ProductionEvents Genealogy pane:
To configure the LotIDReverseGenealogy SQL query
1.
Use the SuiteVoyager TableWeaver to access the Production Events
Module Content Unit.
2.
Select Query/ProductionEvents.
3.
Modify the first line (SELECT) of the LotIDReverseGenealogy query to
read as follows:
SELECT Distinct TOP #Count#
4.
Save and exit the query.
This modification filters the data by its uniqueness and returns only unique
data rows.
PEM Diagnostics and Troubleshooting
C H A P T E R
73
7
PEM Diagnostics and
Troubleshooting
In the simplest sense, Production Events Module (PEM) object diagnosis and
troubleshooting determines the following:
•
•
•
Whether a PEM object is triggered.
Content of the sent message.
Whether the message was successfully delivered to the database.
However, PEM Objects use different system components and services to
handle messages. When performing diagnostics and troubleshooting, it is
necessary to assess the problem in the context of the individual object. For
example, when diagnosing a message failure, you must know whether the
object was configured With- or Without response. This will enable correct
diagnosis at the object level.
The PEM objects and services also interact with Microsoft SQL Server, and
diagnostics and troubleshooting must include the related components.
Detailed explanations of object- and system-level diagnostics are also included
in this chapter.
Contents
•
•
PEM Object Diagnostics
PEM System Diagnostics
74
Chapter 7
PEM Object Diagnostics
The following section describes diagnosing and troubleshooting at the object
level.
Using the Log Flag Editor
Use the SMC (System Management Console) Log Viewer to troubleshoot
PEM objects. The Log Flag Editor displays a list of all ArchestrA components
installed on the GR Node. Log Flags can be set locally (for a particular object)
or Globally (for all objects).
Note Use caution when setting Global log flags, since they can affect node
performance.
After applying the settings, error and status messages appear in the logger.
To configure Log Flags
1.
Launch the SMC on the GR node or on a Remote node.
2.
Expand the Log Viewer icon.
3.
Right-click Default Group and select Connect.
4.
Select the Local or Remote sub-menu command.
When connecting to a remote node, enter the network node name in the
Computer Name field and click OK.
The Node appears in the SMC under Default Group:
5.
75
Right-click the target node and select Log Flags.
The object list for that node appears in the left pane. The default selection
is Global: Log Flags available for all objects:
6.
Highlight the target PEM object or service. The PEM objects and system
components appear as the following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
EquipmentActualRuntime1
MaterialConsumableActualRuntime1
MaterialConsumedActualRuntime1
MaterialMovedActualRuntime1
MaterialProducedActualRuntime1
PersonnelActualRuntime1
ProductionDataRuntime1
TraceEventAttrManagerRuntime1
TraceEventCDARuntime1
TraceEventPDAPackage1
TraceEventPDARuntime1
TraceEventStringValueRuntime1
TraceEventValidationRuntime1
TraceProdServ
76
Chapter 7
The PEM Services appear as the following:
•
•
ProdMsgDispatcher1.0
ProdMsgHandler
Note ProdMsgDispatcher1.0 and ProdMsgHandler service traces are
available from the Log Flag Editor pane.
The Log Flags list for the selected object appears in the right pane:
7.
Select the Trace flag, or any available flag.
The recommended Log Flags for the PEM objects are:
•
•
•
•
Error
8.
Close the Log Flag Editor and click Yes when prompted to apply the
changes to the Log Flag editor.
Warning
Trace
Entry-Exit
The selected Log Flag items appear in the Log Viewer (following figure).
77
Logged Items
The following figure shows an object with the Trace Log Flag selected. Listed
Events/Trace outputs include:
•
•
•
•
Data values configured at the object and contained in the message.
Object and system status values.
Calls made by the Production Services.
System Events.
Double-click an item to view its contents:
78
Chapter 7
Filtering PEM Traces
Use the filter to reduce and focus the number of log messages written to the
file.
Filter conditions can come from Logger column names. (Process ID,
Component), or key words like Error, etc.
The filter pane includes Messages, Time Range, and Terminal Sessions tabs:
Select the Show option to display the filtered messages.
79
Troubleshooting PEM Event Messages
The PEM objects use Microsoft Message Queuing or IIS web services to
handle event messages. Message Queuing is used when the objects are
configured Without Response, and the IIS Web Service is used when the object
is configured With Response.
Each PEM object’s messages have unique characteristics and must be
evaluated accordingly. For example, messages configured With Response
must be evaluated at runtime using the available object attributes.
Error messages generated by objects configured Without Response are
different in nature and viewed by the PEMErrorViewer.
PEM objects generate two error types:
•
•
Production Event messages.
Validation messages.
Production Event messages are generated after a production event occurs and
are viewed from the SMC.
Validation messages occur when either pattern or other validation error occurs
and are returned to the triggered object when configured With Response, or
written to a specific data table when configured Without Response.
PEM Events Without Response
PEM objects configured Without Response use the Microsoft Message
Queuing (MSMQ) Service.
About Message Queuing
The Message Queuing and routing system for Windows operating systems
enables distributed applications running at different times to communicate
across heterogeneous networks and with computers that may be temporarily
offline.
Message Queuing servers can be used to:
•
Provide message routing and session concentration for independent
clients.
•
•
Provide message routing between sites over routing links.
Create queues and store messages for dependent clients.
80
Chapter 7
Common Message Queuing Characteristics
• Message Queuing provides guaranteed message delivery, efficient routing,
security, and priority-based messaging.
•
Access the service from the Computer Management Control Panel icon.
Select Services and Applications/Message Queuing. Message queues are
found in various sub-folders.
•
Following a new installation of Message Queuing, or after an upgrade
from Windows2000 to Windows2003, the default limit for storage size is 8
GB.
This is the size for all the messages in all the queues on the machine.
•
The storage size limit on a Windows2000 machine is 1.6 GB because it
runs MSMQ 2.0.
When a computer quota is reached, no messages are delivered to any
queue or journal on the computer.
No negative acknowledgement message is generated, and an error is
returned for messages sent locally. A remote node tries to resend until the
cumulative size of the messages in the queues drops below the specified
limit.
Note ArchestrA Admin permission is required to view the outgoing Message
Queue on the AppEngine (sending) node.
Using Message Queuing
The MSMQ service is viewed from Control Panel/Administrative
Tools/Computer Management/Message Queuing.
The following table contains information about the MQ behaviors when
viewed from the Message Queuing window:
Problem
Behavior
Event messages sent by
objects do not appear in
the Production Database
(ProdDB).
Messages are queued up Server node is not
on Object node (node on operational.
which the objects are
deployed.
Cause
Problem
Behavior
(ProdDB).
ProductionMessage
Messages are not
Dispatcher service is
queued up on Object
node, but are delivered not started.
to the ProdDB Node and
queued there.
(ProdDB).
Messages do not appear
queued on either node.
Messages sent
successfully from client,
but rejected by
target/server due to
permission mismatch.
81
Cause
Client machine does not
have correct (Peek, Get,
Write) permissions on
server. The security
settings on the inbound
message queue,
WWProdMsgQueue1.
0, must include Peek,
Get, and Write
permissions for the user
specified as the
ArchestrA Admin User
on both nodes.
If this situation exists,
messages are rejected by
the server and are
instead sent to the
Transactional DeadLetter Queue on
client/sending machine.
Ensure Common Service Login Permissions
Ensure the ProductionMessageDispatcher service has the same login
permissions as the other ArchestrA Services (Administrator-level). This
ensures the service interacts correctly with Message Queuing and specifies the
Galaxy Admin account at installation.
If it is configured with permissions other than the Galaxy login permissions
(same as at installation), the MSMQ Service might consume 100% CPU and
freeze the system.
82
Chapter 7
PEMErrorViewer
The PEMErrorViewer utility is used to automatically access the
ProductionEventMessageError table in the ProdDB on the Historian node. It is
installed with the Production Services installation.
It is launched from the Internet Explorer browser by entering the following in
the URL field: http://machinename/pemerrorviewer.
The PEMErrorViewer includes standard filtering, navigation and display
options.
83
Using PEMErrorViewer
The PEMErrorViewer views error messages written to the PEM error tables.
These messages are only written for objects that are configured Without
Response.
When the object sends data, it uses the Message Queue. When the service
receives the object data, it confirms that the validation conditions are met.
For example, an operator enters a production order and triggers it. The
message is sent to the service. If a supervisor has entered the order as a
production schedule, the order message is validated and sent to the ProdDB.
If the supervisor has not yet entered the production schedule, the message
cannot be validated and it is sent to the ProductionEventMessageError table.
The information is viewed by the PEMErrorViewer and can be re-submitted
for validation.
Note The Resubmit operation will not work if the message quality is bad or
there is any other message issue. The only issue that can be corrected is a
pattern match that has changed or a table validation that has been updated to
include or exclude values necessary for exists or unique.
PEM Messages With Response
PEM Messages With Response are handled by the IIS Services. If a message
with response found to be not valid, an error is returned to the object.
For messages configured With Response, the following object attributes should
be monitored:
•
•
•
.ErrorCode
.ErrorMessage
.Status
Other object attributes such as
SegmentResponseID.ErrorCode,...ErrorCount, or ...ErrorMessage may
also be monitored to understand the validation problem.
When the Auto Reset attribute is not selected, the object status must be reset
manually.
Note A sample monitoring script is included in Monitoring PEM Objects
"Best Practice" on page 86.
84
Chapter 7
PEM Event Processing Errors
When the PEM object trigger is processed correctly, the object status is set to
Busy, then Done/Ready at the completion of the triggered event. The status
also depends on the Auto Reset attribute setting.
If any processing errors occur, the object status will be set to Error and the
ErrorCode and ErrorMessage attributes will be set according to the
following table:
Code
Message
0
Description
Blank <default>, no error(s)
1
Unknown Exception Occurred
An unknown exception was
occurred that could not be
handled.
2
Busy Status on Startup Error
PEM AppObject was found to
be in a "Busy" state on
initialization.
3
DateTime Quality Error
Occurs if the DateTime quality
is NOT good.
4
Machine Name Error
Occurs if the PEM AppObject
finds the
Engine.Historian.Connection
attribute is either blank or has a
quality that's not good.
100
COM [Create] Production
Event Message Error
Occurs if a COM error is thrown
when creating the Production
Event Message object.
101
COM [Initialize] Production
Event Message Error
Occurs if a COM error is thrown
during the process of initializing
the Production Event Message
object.
102
COM [Send] Production Event Occurs if a COM error is thrown
Message Error
during the process of sending
the Production Event Message
object.
200
Send [Undefined Mode]
Production Event Message
Error
Occurs if mode is not defined as
"Without Response" or "With
Response" (should not happen).
201
Send [Without Response]
Error
Indicates that some error
occurred when sending an
"Without Response" Production
Event Message.
202
Send [With Response]
Error
Indicates that some error
occurred when sending a "With
Response" Production Event
Message.
85
Code
Message
Description
203
Retry Error
Occurs only for "With
Messages. Indicates that some
error occurred and that the
original message should be
retried because it is unclear if
the Traceability Service was
able to process it successfully.
Retries are not supported at this
time.
204
Validation Error
Messages. Indicates that there
was validation error(s) found
while processing the Production
Event Message.
205
Response Error
Messages. Indicates some error
occurred that was not a Retry or
Validation Error.
Monitoring PEM Objects
PEM objects behave in specific ways. Object monitoring is recommended to
confirm the expected object behavior and to provide diagnostic or preventative
strategies when the objects do not behave as expected.
PEM Objects have the following states: Ready, Busy, Done, and Error. The
state is expressed via the Status attribute. The status attribute can be viewed in
the Object Viewer or other application.
Note Details about Object Trigger behavior are included in "PEM Object and
Trigger Status" on page 27.
The default state of the object is Ready. The object stays in this state until
something effects it, like a trigger. The object then changes to either
Busy/Done (successful), or Busy/Error (unsuccessful).
The object stays in Done or Error state until something acts on it to change the
state to Ready.
86
Chapter 7
Auto Reset Behavior
The Auto Reset attribute is provided as a way for the integrator to easily
change the object state back to Ready when the object completes its task. Auto
Reset checks for the object state of Done and changes it to Ready.
Auto Reset will not reset an object status when the object is in the Error state,
because if it did the user would never see the error. When an error occurs, the
object must be reset manually. This is true for both With and Without
Response modes.
Object Monitoring is recommended for both With Response and Without
Response objects.
Best Practice
Implement PEM object monitoring for the following reasons:
•
If the PEM objects are configured to trigger quickly, the status of the
object must be monitored and validated to Ready state before retriggering. You should never attempt to trigger an object when it has a
status that is anything other than Ready.
•
When the object generates attribute quality or system-related errors, and is
configured Without Response, the object remains in the error state and
must be reset manually. Monitor the Status attribute to reset the object
state.
•
In some situations it may be desirable to record errors (validation, qualityor IIS errors) when a PEM object is triggered in With Response mode. To
do this, the application designer should monitor the Status attribute and
write the appropriate information to a database or log file when the Status
attribute goes to the Error state.
•
Capture operator input and other information when the object is
configured With Response. Then write the information to a database or
log file. To implement this, monitor for the Done Status.
Note For other information on PEM object behaviors, see Chapter 2, "PEM
Object Architecture."
A sample object monitoring script is included for reference and includes the
necessary conditions to reset the trigger if an error is present:
•
•
•
•
Script Name = TriggerReset
Execution Type = Execute
Expression = me.Status
Trigger Type = DataChange
IF me.Status == "Error" THEN
logMessage(me.ErrorMessage);
me.Trigger = false;
ENDIF;
87
Note An error code status of 0 means "no error." For more information on
specific object error messages, see "PEM Event Processing Errors" on page 84.
Generating Error State Alarms
The object state data is of CustomEnum type. Alarms are triggered by Boolean
conditions. Therefore, a separate UDA must be scripted to evaluate the object
state and generate an alarm if the state = Error.
The following configuration is included for an example. It can be used for a
production event such as Consume or Produce:
1.
Configure a UDA called InAlarmState.
Data type: Boolean
Category: Calculated
2.
Create an alarm extension called InAlarmState.
3.
Create a script with the following:
Execution type: Execute
Expression: me.Status
Trigger type: Data Change
IF me.status == "Error" THEN
me.InAlarmState = true;
ELSE
me.InAlarmState = false;
ENDIF;
The alarm can then be generated to a pager, or an action based on the alarm can
pause production.
Monitoring Transactions Before and After
Message Transmission
The PEM system utilizes SQL transactions to ensure data integrity throughout
the system, even in the face of transient network connections or
machine/network failures.
In some PEM applications it is necessary to perform tasks before a PEM
transaction and some tasks after the transaction. Success or failure of the PEM
transaction is important as there would be a need to either not do, or possibly
undo the other actions in the case of failure.
For example, a record of a sample delivery is made to a LIMS system, then a
PEM object is triggered to record the specifics of that delivery, then the LIMS
system is instructed to assign the sample to a lab tech for analysis.
In this case, if the PEM object trigger fails to store the data in the PEM
database because of validation errors due to user input errors, the LIMS entry
needs to be rolled back so the two systems are kept in sync, and the assignment
task shouldn't be done.
88
Chapter 7
To accomplish this type of integration, the application designer will need to
configure the PEM object for With Response mode, then monitor the Status
attribute. If the Status goes from Ready to Busy, then to Done, the transaction
is considered successful.
If on the other hand the Status attribute goes from Ready to Busy, then to
Error, the transaction is considered unsuccessful, and no data is stored to the
PEM database.
In the case of failure, a compensating transaction is performed to undo
whatever was done before the PEM object was triggered. The content of this
transaction is dictated by the particulars of whatever was performed in the
action taken before the PEM object was triggered. For example, in the case of
the LIMS system above, the compensating transaction that would be to inform
the LIMS system that the sample delivery notice should be removed from the
LIMS database.
In addition, in the case where the Status of the PEM object goes to Error, the
steps normally taken after a successful triggering of the PEM object are
aborted or not taken at all. In the LIMS example, the step of instructing the
LIMS system to assign the sample for analysis would simply not be done.
Note For Version 1.0 of PEM, it is not possible to directly participate in the
internal transactions utilized by the PEM system.
PEM System Diagnostics
Performance management at the system level is both an iterative and
continuous process that is imperative for Service Level Agreements and
capacity planning.
A performance management process will generally follow the 80/20 rule,
focusing on managing primary performance metrics. Basic resource counters
should be tracked and monitored, as well as many other details with complex
interdependencies that may have a significant bearing on system performance.
System performance management in the PEM environment is a function of
both specific software resource requirements and the available hardware
resources and configurations.
The basic hardware resources are processor, memory, network, and storage.
Each resource has gross capacity measures as well as details that may have
multiple dependencies.
Note that many performance issues can be hidden in 'tandem queues' where a
bottleneck at one area hides a bottleneck at another. Here is where the need for
an iterative discovery and resolution process has to be in place to be effective.
89
Microsoft Performance Monitor
Microsoft Performance Monitor can be used to monitor relevant PEM system
counters to assess system performance. The following performance manager
objects and counters can be used to manage the PEM application:
Note Detailed explanations for each item are available from the Performance
Monitor interface by highlighting the counter and clicking the Explain button.
Processor
• %Processor Time
• DPC Rate
• Interrupts/sec
The CPU is perhaps the most visible (and hyped) system resource. A general
heuristic is that a system is considered saturated when average CPU
consumption is above 60%.
Excessive interrupts or DPC time is a sign that detailed analysis may be
warranted. CPU metrics are relative to the hardware provided: 32/64-bit,
amount of level 1 and level 2 cache, etc.
Memory
• Pages/Sec
• Page Faults/Sec
• Page Reads/Sec
Memory capacity will generally improve performance up until some point of
rapidly diminishing return. Paging is a primary concern, yet low paging rates
are expected rather than a target of zero. It is very important to differentiate
hard faults (page reads) rather than soft faults resolved by cached pages.
Network Interface
Bytes Total per Sec should be compared with known bandwidth
Network bottlenecks may be common for server applications, especially where
off-node bulk operations like printing, backup, or Extract- Transform- Load
processes are present. Measurement is relative to capacity, and capacity is
interpreted differently for switch vs. hub network topologies.
90
Chapter 7
Messaging Queue
• Messages in Queue: Instance for private$wwprodmsgqueue1.0.
A queue can be found on both the AppServer node and the Production
Services node.
•
MSMQ Service: MSMQ Incoming Messages/sec.
Processor -memory - network are all basic resources that need to be
addressed on any server application. Their capacity is usually a
specification found on the machine.
Although disk capacity for database is an explicit sizing metric, a key disk
resource issue is the I/O capacity of the disk subsystem. Of course a system
needs the sizing capacity of the application, the I/O rate is the primary
performance criteria.
RAID Monitoring Recommendations
RAID is a standard feature of any server application, best known for providing
fault resilience. For databases or other processes that make heavy use of disks
for persistence, RAID enables the I/O capacity to be scaled.
For example, an ultra-wide SCSI disk may have an I/O capacity value of 125
and an application requirement of 520 I/Os.
Divide the requirement by the capacity of a single disk, then round up to find
out how many disks are required in the RAID storage partition (five [5] disks).
Physical Disk (For Each RAID Disk Instance)
• %Disk Time
• Avg. Disk Queue length
• Avg. Disk Sec/Read
• Avg. Disk Sec/Write
• Current Disk Queue Length
• Disk reads per second
• Disk writes per second
The byte counts for the last 2 items (above) may be of interest if the channel
becomes saturated.
PEM is a Disk-write-intensive application (it logs production events). Due to
large memory and little read activity, dirty pages accumulate in memory at
high transaction system; SQL checkpoints may cause some I/O counters to
record very high rates.
91
ArchestrA Production Message Dispatcher
(aaprodmsgdispatcher.exe)
• Thread count: The configured number of threads. Registry tuning may be
used to optimize best performance; more is not necessarily better.
•
Thread DurationAvg: Average of transaction duration for the given
interval.
•
Threads per second: A close approximation to transactions per second
counter provided in the SQL server database object counter.
SQL Server: Buffer Manager
• Buffer cache hit ratio: PEM will normally produce very high numbers.
Contention with other software may result in less-than optimal numbers
based on memory pressure.
•
Checkpoint pages/sec periodically, since dirty memory pages will be
flushed to disk. Note that I/Os will be highest as this occurs while the
database transactions continue.
SQL Server: Databases Select ProdDB Instance
• Active Transactions
• Transactions /sec
The amount of resources consumed by each service running on a host is
essential information. Scalable architectures allow applications to be relocated
within the overall system for best system operation.
Performance Monitoring Summary
The PEM server node combines Web Services, Production Database, MSMQ,
and IndustrialSQL Server - Historian™ software. Each of these applications
has the capability to consume large quantities of resources depending on the
application design, so overall performance is highly interdependent.
CPU, memory, and network resources can be scaled on the node in a general
fashion. In the PEM environment, disk configuration will best be managed by
addressing the needs of the specific applications. Both the SQL Server and
MSMQ have a main file as well as a log file based on their transaction focus.
The logs and the main files must always be separated for performance and
recovery purposes. The IndustrialSQL Server - Historian component is
inconsequential from a disk standpoint, but the queue files it maintains are
similar to the log files in that the write activity is sequential in nature and
should not be mixed with other application data.
The interdependence of applications warrants using the Process Performance
object to detail the extent of resource consumption per process: CPU, IO,
paging, etc.
92
Chapter 7
Monitoring Database Transactions
SQL Profiler is installed with Microsoft SQL Server. SQL Profiler is an
excellent tool to see individual database transactions and what data is being
passed from the service layer. SQL Profiler shows exactly what the database
access layer does for a PEM object.
To use SQL Profiler
1.
Select Start/Programs/Microsoft SQL Server/Profiler.
2.
Select File/New Trace.
3.
Select the SQL Server Node and connection authentication.
4.
Name the trace, and begin with the Standard Profile. The Standard Profile
is a good place to start. Other options available with the Profiler can be
leveraged.
5.
Select the Filters Tab and enter the Application Name 'Like' with the value
Traceability Production Service 1.0.
6.
Click Run.
You will see messages like:
RPC:Completed | exec GetSegmentResponseWithDateUpdate.
Reads, Writes, Duration and other information is displayed in columns.
This information will be important to assess transaction performance.
The lower field contains the Transact-SQL script.
Note that the PEMErrorViewer can be similarly analyzed by using the value
PEM Error Viewer 1.0 as the Application Name filter.
SQL Profiler precludes the need for content reports to 'prove' the data is
reaching the database.
ISA-95 Glossary
93
ISA-95 Glossary
The following glossary is compiled from World Batch Forum (WBF) B2MML
V2 document sources, and is intended as a resource for this Deployment
Guide.
C
ConsumableActual
ConsumableActuals include resources that are not normally included in bills of
materials or are not individually accounted for in specific production requests.
Depending on the industry these may include water, catalysts, common
chemicals, and utilities, such as electricity and steam. These items will often
result in direct charges that will usually be considered in costing the product
segment. Consumables are often materials that do have an inventory balance.
A Consumables Actual in a production response identifies a consumable
material consumed during the specified segment of production.
E
EquipmentActual
Equipment actual in a production response identifies a equipment resource
used during the specified segment of production.
M
A material produced actual in a production response identifies a material
resource by class ID, definition ID, Lot ID, and/or Sublot ID produced during
the specified segment of production.
MaterialsConsumedActual
A material consumed actual in a production response identifies a material
resource by class ID, definition ID, Lot ID, and/or Sublot ID consumed during
the specified segment of production.
P
PersonnelActual
A personnel actual in a production response identifies a personnel resource
used during the specified segment of production.
94
Glossary
ProductionPerformance
A production performance report is made up of a set of 1 or more production
responses. The production performance also contains the information that
defines the context of the report, such as start time, end time, location, and
published date.
ProductionRequest
A production request defines a request for production for a single product.
ProductionResponse
Production responses are the responses from manufacturing that is associated
with a production Request. There may be one or more production responses for
a single production request if the production facility needs to split the
production request into smaller elements of work. For example a single
production request for the production of "200 gears" may be reported on by 10
production response objects of "20 gears" each because of manufacturing
restrictions.
S
SegmentRequirement
A production request is made up of one or more segment requirements. Each
segment requirement may correspond to, or reference, an identified process or
product segment. The segment requirement references the segment capability
to which the associated personnel, equipment, materials, and production
parameters correspond.
A SegmentRequirement reflects the ISA-95 standard by saying that a segment
requirement corresponds to either a product segment or a process segment. In
many cases it may not matter. A segment request should define resources and
parameters already defined in process segments or product segments.
However, in order to match the spirit of the ANSI/ISA-95 standard, this should
always be a product segment ID in the SegmentRequirement, and the product
segment should refer to a process segment through the ProductDefinition.
The production parameter in a SegmentRequirement can be a Process Segment
parameter, or a Product Segment parameter. This means the production
parameter could have been defined in the process segment, because it is
product independent (like the color in a "PAINT" segment), or defined in a
product segment when it is product dependent (such as a component’s color to
be applied to only specific products). So, the SegmentRequirement could point
to the product segment, but parameters for the product segment and the process
segment may be duplicated, and this practice ensures differentiation.
SegmentResponse
The defined production response for a specific segment of production. A
segment response may be made up of zero or more sets of information on
production data, personnel actual, equipment actual, materials consumed
actual, materials produced actual, and consumables actual. A segment response
may include an identification of the associated process segment. the actual
starting and stopping time of the segment. and the duration of the segment.
ISA-95 Glossary
95
A SegmentResponse is also included as an optional element in a
ProductionRequest. In those cases the SegmentResponse defines elements that
are to be returned with a ProductionResponse. In this use it basically defines a
template of information to be filled in and returned. A segment response
contains an element (RequiredByRequestedSegmentResponse) that is used in a
ProductionSchedule to indicate if the including element is required or optional
in a response from a request. The value of the
RequiredByRequestedSegmentResponse element may be extended on an
application-specific basis.
96
Glossary
Index
97
Index
A
E
aaProductionMessageDispatcher 24
scaling out 57
scaling up 58
alarms, generating object error state alarms 87
attributes, common PEM object 14
auto reset, error state behavior 29
EquipmentActual, ISA-95 definition 93
errors
event processing error list 84
logging 74
viewing 77
G
B
batch manufacturing environments, PEM object use
examples 51
best practice
configuring PEM attributes for lot-based
genealogy 61
configuring SQL database growth 21
monitoring "with response" messages 55, 86
PLC queues for capturing accurate data 53
PLC register activity 55
validation and linked servers 41
visualizing serial numbers in SuiteVoyager 70
C
collaborative manufacturing 32
configuring PEM objects
common configuration recommendations 16
for genealogy 60
SMC log flags 76
configuring SQL Server
database file growth 21
linked servers 41
ConsumableActual, ISA-95 definition 93
continuous manufacturing environments
capturing start-end times 19
PEM object use examples 52
D
data collection
accurate collection and delivery 52
interrupted 54
delivering accurate PEM data
event triggers 53
PLC queues 53
diagnostics and troubleshooting
errors 84
IIS Web Services 83
Message Queuing 80
PEM object log flags 75
PEMErrorViewer 82
Performance Monitor 89
SQL Profiler 92
trace filters 78
discrete manufacturing environments, PEM object
use examples 47
document references 13
genealogy
about 60
correct PEM object attributes 60
lot-based 59
I
IIS Web Services
diagnostics and troubleshooting 83
messages with response 83
installation notes for PEM components 44
intended deployment guide users 13
ISA-95
about 32
relationship to PEM objects 31, 33
relationship to ProdDB tables 34
relationship to SQL Views 36
M
manufacturing types
about 46
batch 51
continuous 52
discrete 47
MaterialProducedActual, ISA-95 definition 93
MaterialsConsumedActual, ISA-95 definition 93
message handling
about 19
installation notes 20
Message Queue diagnostics and
troubleshooting 80
messages without response 19
mixed platform security considerations 17
PEM message size 24
Windows 2000 20
Windows 2003 and XP 20
mixed platform environment
example 17
message handling 17
monitoring
database transactions 92
PEM objects 30
98
Index
P
S
PEM content builder unit
visualizing PEM data 60
PEM object architecture, general notes 24
PEM objects
about 12
architecture 24
common characteristics 11
common configuration recommendations 16
common object attributes (summary) 14
configuration recommendations 16
message without response 20
messages with response 26
messages without response 19, 25
monitoring object status 85
object status 27
security considerations 16
triggering messages 15
triggers 12, 15
troubleshooting 73, 74
uploading runtime changes 17
PEM production services 24
and IIS 26
PEM installation notes 44
PEM Web Service 1.0 24
ProdMsgHandler 24
PEM production services list 24
PEM systems
monitoring 88
scaling out 57
scaling up 58
PEM validation
against external tables 40
PEM validation types 38
PEM Web Service 24
PersonnelActual, ISA-95 definition 93
ProcessSegment ID, configuring lot-based
genealogy 60
ProdDB
about 35
error tables 82
error viewing 83
serial numbers 35
supporting ISA-95 31
ProdMsgHandler 24
production attributes
for genealogy 60, 61
production server node specifications 56
production services,
aaProductionMessageDispatcher 24
ProductionPerformance, ISA-95 definition 94
ProductionRequest ID, configuring lot-based
genealogy 60
ProductionRequest, ISA-95 definition 94
ProductionResponse, ISA-95 definition 94
S95 See ISA-95
scalability 56
script
alarm from object errors 87
monitor and reset object in error state 86
security
configuring workgroup permissions 16
linked server 42
mixed platform environment 17
MSMQ configuration 81
PEM object and IAS 16
troubleshooting messages 80
workgroup environment 16
SegmentRequirement, ISA-95 definition 94
SegmentResponse ID, configuring lot-based
genealogy 60
SegmentResponse, ISA-95 definition 94
serial numbers
presented in the SuiteVoyager portal 71
SerialNumberData data table 35
SMC log flags 74
recommended for PEM objects 76
SQL Server 21
linked servers 41
PEM views 35
ProdDB 35, 70
Profiler 92
recommendations 21
views 60
SQL views
common characteristics 36
supporting the ISA-95 schema 31
SuiteVoyager
installing PEM content builder unit 44
ProductionEvents add-on 60
viewing PEM data 59
T
triggers
about 15
auto reset and error state 28, 29
behavior with response 29
behavior without response 28
event 53
status 27
U
uploading runtime changes 17
Index
V
validation 38
against a database table 40
against external tables 40
configuring a linked server 41
object-level 38
server-level 38
visualizing PEM data
accessing SuiteVoyager content units 69
configuring PEM object attributes for
genealogy 62
99
PEM content builder units 60, 68
SQL views 35, 63
SuiteVoyager lists 65
SuiteVoyager searches 66
W
workgroup security environment
configuring permissions 16
deploying PEM objects 16
100
Index

Production Events Module (PEM)

Transcription

Similar documents

Configuring Windows® SharePoint Services™ for PEM v1.0 to Work

David Nicholas Bio 2014 - Rhinoceros - Music

2007 - 3 rd Volume, No. 1

TTCSI Services Talk final proposal

Manifesto, But Why?

instructions

April 2013 Newsletter - Terrebonne Genealogical Society

7 Segment Display Driver

our Alpha API Brochure

Take Part In The largest beer Festivals In Maryland