Wonderware Production Events Module v. 1.0 (PEM)

Transcription

1 Wonderware Production Events Module v. 1.0 (PEM) Deployment Guide Revision A Last Revision: 7/11/2005 Invensys Systems, Inc.

2 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, addresses, logos, people, places and events depicted herein are fictitious and no association with any real company, organization, product, domain name, 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 or by sending an to support@wonderware.com. Portions of this document have been based upon or excerpted from ANSI/ISA , Enterprise-Control System Integration Part 1: Models and Terminology, and ANSI/ISA , Enterprise-Control System Integration Part 2: Object Model Attributes. Copyright ISA 2000 and 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 Rancho Parkway South Lake Forest, CA

3 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 Basic Production Questions Intended Users References Common Object Attributes (Summary) Production Attributes (PAs) Extended Production Attributes (EPAs) Triggers Common PEM Object Configuration Recommendations PEM Object Security Uploading Runtime Attributes 'Unit' Objects with UDAs for Basic Shared Information Capturing Start and End Times with the ProductionData Object Common PEM System Configuration Recommendations Microsoft Message Queuing (MSMQ) Microsoft SQL Server CHAPTER 2: PEM Object Architecture...23 PEM Object Architecture General Notes PEM Production Services Event Message Handling Without Response (Default) With Response PEM Object and Trigger Status Without Response With Response Monitoring Without Response Messages Monitoring With Response Messages... 30

4 4 Contents CHAPTER 3: PEM Data Relationships...31 About ISA Collaborative Manufacturing Environment...32 Exchanged Information Categories...33 PEM Data Relationships...33 Relationship to ISA 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

5 Contents 5 CHAPTER 6: Visualizing PEM Data in the SuiteVoyager Portal...59 About Production Events and Historization About Genealogy Genealogy, PEM Objects, and SuiteVoyager PEM Genealogy Summary PEM Object Genealogy Configuration PEM Views Production Events Module Content Units for SuiteVoyager (Summary) Production Events Runtime Serial Number Data Configuration/Collection Visualization CHAPTER 7: PEM Diagnostics and Troubleshooting...73 PEM Object Diagnostics Using the Log Flag Editor Troubleshooting PEM Event Messages PEM Events Without Response PEM Messages With Response PEM Event Processing Errors Monitoring PEM Objects PEM System Diagnostics Microsoft Performance Monitor Performance Monitoring Summary Monitoring Database Transactions ISA-95 Glossary...93 Index...97

6 6 Contents

7 Before You Begin 7 Before You Begin About This Document The 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 Bold Monospace Italic Used for Menus, commands, buttons, icons, dialog boxes and dialog box options. Start menu selections, text you must type, and programming code. Options in text or programming code you must type.

8 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: 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 Receive technical support by sending an to your local distributor or to support@wonderware.com. Web: You can access Wonderware Technical Support online at Telephone: You can call Wonderware Technical Support at the following numbers: U.S. and Canada (toll-free): 800-WONDER1 ( ) 7 a.m. to 5 p.m. (Pacific Time) Outside the U.S. and Canada: (949) 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. Any relevant output listing from the Log Viewer or any other diagnostic applications. Details of the attempts you made to solve the problem(s) and your results. Details of how to recreate the problem.

9 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 address where you can be reached.

10 10 Before You Begin

11 Production Events Module (PEM) Introduction 11 CHAPTER 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 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 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? What basic resources (water, energy, etc.) were consumed during the processing of my product?

13 Production Events Module (PEM) Introduction 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 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 Production Events Module (PEM) Introduction 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 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 Production Events Module (PEM) Introduction 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 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 Production Events Module (PEM) Introduction 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 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 Production Events Module (PEM) Introduction 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 22 Chapter 1

23 PEM Object Architecture 23 CHAPTER 2 PEM Object Architecture 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 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 PEM Object Architecture 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 EquipmentActual MaterialConsumableActual MaterialConsumedActual MaterialMovedActual MaterialProducedActual PersonnelActual ProductionData Runtime External Event Trigger (InTouch, PLC, DB, etc.) Internal Event Trigger (Scripted) MSMQ Message Without Response Services ProdDB MSMQ Production Services ProdMsgDispatcher Data 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. PEMErrorViewer Presents Error Messages and detailed information from the ProductionEventMessageError table. Resubmitting the error sends the message back to IIS for validation. PEMObject Event PEMObject ProdMsgHandler The data contained in messages triggered in Without Response mode are validated within the ProdMessageHandler component. Deploy MessageDispatch 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 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 EquipmentActual MaterialConsumableActual MaterialConsumedActual MaterialMovedActual MaterialProducedActual PersonnelActual ProductionData Runtime External Event Trigger (InTouch, PLC, DB, etc.) Internal Event Trigger (Scripted) Message With Response Services Production Services PEM Web Service ProdDB Data 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. PEMObject Event PEMObject ProdMsgHandler 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. Deploy MessageDispatch If IIS services are not running, object generates error message "Production Event Message Retry Error." Note For more information on these behaviors, see Chapter 7, "PEM Diagnostics and Troubleshooting."

27 PEM Object Architecture 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 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 Done * Error Message not placed onto the message queue. Trigger attribute remains 1 (True). Busy Message is in the process of being created and placed onto the message queue 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. Note If processing fails, the object transitions to the Error state, and the Trigger attribute remains True. 6. When the Trigger attribute returns to False, the object transitions to the 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 PEM Object Architecture 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 Done * Message not delivered successfully, or a validation error occurred. Trigger attribute remains 1 (True). Busy Message is sent and awaits response from Production Server 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. Note If processing fails, the object transitions to the Error state, and the Trigger attribute remains True. 6. When the Trigger attribute returns to False, the object transitions to the 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 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.

31 PEM Data Relationships 31 CHAPTER 3 PEM Data Relationships 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 Data Relationships PEM Views

32 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:

33 PEM Data Relationships 33 Business Systems Time Horizons: Long Term View. Model Detail: Linear route structures. Control Emphasis: Product cost and overall profitability. Modeling Criteria: Accounting reference points. Has inventory value changed significantly? If not, don t model separately. View from the Boardroom. Manufacturing Systems Time Horizons: Real-time View. Model Detail: Complex routes with rework paths. Control Emphasis: Physical movement & accountability. Modeling Criteria Material Movement reference points. Does product stop moving? If not, don t model separately. 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. PEM Data Relationships 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 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: is made up of Production Performance is made up of Production Response 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 PEM Object Base Template $MaterialConsumableActual SQL Server View SQL Server ProdDB Data Table ISA-95 Definition: Consumables Actual Attributes: Material Definition Descripition Location Quantity Quantity Unit of Measure The ANSI/ISA standards define basic production objects and their attributes. The PEM object sends configured attribute information to the Production Services. Production Services parses and writes the information to the correct data tables. ProdPerf_ConsumableActual The SQL Server Views provide information in a Genealogy context from the corresponding ProdDB Data Table, or a combination of related tables. The View is accessed by one or more Table Weaver objects within SuiteVoyager for reporting purposes. ConsumableActual Columns: ActualDateTimeUTC UTCOffset EventMessageGlobID Material Definition Descripition Location Quantity 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

35 PEM Data Relationships 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 ISA- 95 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 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."

37 PEM Validation 37 CHAPTER 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 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. Exists/Unique. Missing one or more values (i.e.: user indicated they wanted to log it, but no value was provided). Context error: At least one of the required values wasn t 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.

39 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 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.

41 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 42 Chapter 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.

43 Creating a Basic PEM Production System 43 CHAPTER 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 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 ERP / Enterprise OS Group-Based Security Engineering Historian Node: SQL Server/ProdDB Production Services AlarmDB Logger & Database IAS GR Node InTouch Master NAD Domain Controller IAS Primary InTouch View/NAD Client Operator Station InTouch View (NAD Client) Control Room IAS Backup InTouch View (NAD Client) SFC and Production Scheduling PLCs 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 Creating a Basic PEM Production System 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 Engine Platform Historian Node: SQL Server/ProdDB Production Services 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: Multiple PEM objects Single Platform Multiple Engines Engine Engine Platform Historian Node: SQL Server/ProdDB Production Services 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: Multiple PEM objects Single Platform Multiple Engines Client Node: Multiple PEM objects Single Platform Multiple Engines Engine Engine Platform Engine Engine Platform Historian Node: SQL Server/ProdDB Production Services Multiple PEM objects are deployed on multiple Engines, on multiple Platforms. The data is written to the ProdDB on the Historian Node.

46 46 Chapter 5 Multiple Historian Nodes Client Node: Multiple PEM objects Single Platform Multiple Engines Engine Engine Platform Historian Node: SQL Server/ProdDB Production Services Client Node: Multiple PEM objects Single Platform Multiple Engines Engine Engine Platform Historian Node: SQL Server/ProdDB Production Services 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. 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. Cross-Historian data visualization is possible using multiple SuiteVoyager Content Units but the data is not related across Historians. 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 Creating a Basic PEM Production System 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 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 Process Segment ID Segment Response ID WIPLOT# Operation Name (Hardcoded) 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 ABC-001-P Assembly Unfinished Chair Finishing Finished Chair Packaging Chair Package Chair Kit Glue 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 Creating a Basic PEM Production System 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 ABC- 001-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 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 Creating a Basic PEM Production System 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 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) Consume from Additive Produce to Processing Units Consume from Processing Unit Produce to Waste Consume from Additive Produce to Processing Units Consume from Processing Unit Produce to Waste Consume from Storage Tank A Produce to Bottles Consume from Storage Tank A Produce to (Multiple) Processing Units Consume from Processing Unit Produce to Waste

52 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? 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). Is losing production events (During IAS failover or other communication interruption) critical to your process? 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 Creating a Basic PEM Production System 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 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. Hardware malfunction. Failover time period and/or failover scenarios (Active-Active engine states). Machine shutdown. 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 Creating a Basic PEM Production System 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 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 Network Card Speed RAM OS 2.0 GHz Pentium P4 Integrated Fast Ethernet Controller 100 Mb/s 1024MB 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 Creating a Basic PEM Production System 57 Scaling Out The following graph represents the use of the aaproductionmessagedispatcher. Service counter values as each platform (node) is added to the system: aaproductionmessagedispatcher % Processor Time 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. MSMQ Incoming Messages Messages in Queue Platforms Added Bytes in Queue Messages in Queue Bytes in Queue

58 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 % Processor Time 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. MSMQ Messages in Queue Messages in Queue Engines Added Bytes in Queue Messages in Queue Bytes in Queue

59 Visualizing PEM Data in the SuiteVoyager Portal 59 CHAPTER 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 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 Visualizing PEM Data in the SuiteVoyager Portal 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 Production Request ID Consume Event Produce Event C1 P1 C2 P2 C3 P3 C4 P4 SR ID = 1 SR ID = 2 SR ID = 3 SR ID = 4 Segment Response ID PS ID = 1 PS ID = 2 Process Segment ID PR ID = 1 Production Request ID Note An example of Genealogy configuration within a Discrete manufacturing environment is provided in "Discrete Manufacturing Example" on page 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 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 Visualizing PEM Data in the SuiteVoyager Portal 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 ProdPerf_ * ProdSched_ * ProcSeg_ * ProdEvents Content Production Performance Production Schedule Process Segment 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 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 Visualizing PEM Data in the SuiteVoyager Portal 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 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. 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. Note Details about serial numbers are included in "Serial Number Data" on page 70.

66 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. 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. 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.

67 Visualizing PEM Data in the SuiteVoyager Portal 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 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 Visualizing PEM Data in the SuiteVoyager Portal 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 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 Visualizing PEM Data in the SuiteVoyager Portal 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 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.

73 PEM Diagnostics and Troubleshooting 73 CHAPTER 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 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:

75 PEM Diagnostics and Troubleshooting 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 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 Warning Trace Entry-Exit 8. Close the Log Flag Editor and click Yes when prompted to apply the changes to the Log Flag editor. The selected Log Flag items appear in the Log Viewer (following figure).

77 PEM Diagnostics and Troubleshooting 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 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 PEM Diagnostics and Troubleshooting 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 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 Cause Event messages sent by objects do not appear in the Production Database (ProdDB). Messages are queued up on Object node (node on which the objects are deployed. Server node is not operational.

81 PEM Diagnostics and Troubleshooting 81 Problem Behavior Cause Event messages sent by objects do not appear in the Production Database (ProdDB). Event messages sent by objects do not appear in the Production Database (ProdDB). Messages are not queued up on Object node, but are delivered to the ProdDB Node and queued there. Messages do not appear queued on either node. Messages sent successfully from client, but rejected by target/server due to permission mismatch. ProductionMessage Dispatcher service is not started. 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 Dead- Letter 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 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: The PEMErrorViewer includes standard filtering, navigation and display options.