Enterprise Integration

ARC Advisory Group's recently published ARC View, Emerson Brings DeltaV SIS into the Future with Version 11 Release, describes the continuing advancements of the DeltaV SIS safety instrumented system. DeltaV SIS launched over 5 years ago and this whitepaper provides an update of its original and continuing objectives:

Emerson designed DeltaV SIS to address the issues that face safety system end users today, from flexibility in design to increased reliability, increased visibility into the system, reduced complexity, and easier regulatory compliance.

The flexibility is described:

DeltaV SIS can support a simplex or redundant logic solver. Both are certified for SIL 3 applications. Each logic solver has 16 integrated I/O channels. These are software configurable, eliminating the need for separate I/O cards.

The SIS scales from an individual logic solver upwards:

Emerson has also considerably increased the potential size of DeltaV SIS systems to the point where they can handle very large applications. The architecture can expand from a single 16-channel logic solver to 30,000 I/O... SISNet Domains further increase design flexibility, provide improved support for large projects, easier expansion of existing systems, and easier isolation of separate SIS applications. Basically, this eliminates the capacity limits for DeltaV SIS.

The purpose of a safety instrumented system is of course to take the process to a safety state if it enters a hazardous operating condition. The flip side is that you don't want the SIS to shut down the process when it shouldn't, such as in the case of a failure of a transmitter or final element. The whitepaper notes where the reliability concerns in a safety instrumented function (SIF) typically occur:

When it comes to safety system reliability, most failures are the result of a faulty valve or sensor. Emerson's recent enhancements to its 3051 S intelligent pressure transmitter for SIS applications include plugged impulse line detection. Emerson's DVC6000 SIS intelligent valve positioner for SIS applications includes partial stroke testing capabilities.

Diagnostics from these intelligent sensors and digital valve controllers within each SIF are sent back to the DeltaV SIS logic solvers to help identify problems in advance, before a spurious trip occurs.

Increased visibility with the process automation system occurs because:

...integration of the control and safety system in the operations, maintenance, and engineering environments, but provides complete physical separation of control and safety hardware, software, and communication networks. This separation of the basic process control system (BPCS) and safety system hardware provides the independence necessary to eliminate the possibility of common mode failures.

Though physically separated, the advantages of this integration:

...are reduced costs due to common HMI and software tools, and, more importantly, increased visibility into the process. The integrated architecture allows the user to see everything that happens in their SIS, including device diagnostics and alerts. It allows the user to take a proactive maintenance approach by addressing problems before they become incidents, such as through partial stroke testing and plugged impulse line detection.

The final point, easier regulatory compliance involves not only the functions within the SIS, but the people and processes required in a process manufacturer's IEC 61511 safety compliance efforts. The Syncade smart operations management software can play a role in this work process management. Noted in the whitepaper:

Now the same level of integration between the DeltaV control system and Syncade is available between Syncade and DeltaV SIS. This greatly eases the process of safety system validation, competency management, document management, and workflow management. The document management capability of Syncade can help users be sure they are doing things properly from one phase of the safety lifecycle to the next.

Regulatory compliance is also assisted by the AMS Asset Portal, built on Meridium technology, which measures:

...key performance indicators such as overall equipment effectiveness (OEE).

You can follow news and connect with the DeltaV SIS team on Twitter (@DeltaVSIS), LinkedIn, or Mike Boudreaux's Safety Instrumented System room in FriendFeed.

MP3 | iTunes

A colleague pointed me to this provocatively titled article, Social media: Why engineers should be anti-social, on the Control Engineering website. It reports:

A recent survey says that IT departments are having arms twisted to relax cyber security rules and allow access to social media sites, such as Twitter or GoogleApps.

I hope some of my gentle prods, such as, "I know that some have written me to say that their IT department blocks these videos. I think the case must be made that there are significant business uses from training videos, to application videos, to even capabilities videos like these", aren't contributing to this undue pressure... OK, I confess. I do hope they are.

The title of this article seems to be the polar opposite of an article Deb Franke and I wrote for a sister publication, Control Engineering Asia. The article, The World of Web 2.0, describes our strong beliefs how these social media technologies can increase the effectiveness of engineers and other process manufacturing professionals.

Upon closer inspection of the article, it was not a call for engineers to be anti-social all the time, just when they happen to be on computers sharing bandwidth with the control system network connected to social media applications out on the web. The article cites applications such as Twitter, Facebook, MySpace, GoogleApps, etc.

At least, that was my takeaway from ISA SP99 co-chairman Brian Singer's quote:

Taking 300-500 ms extra to receive e-mail or a Webpage is largely unnoticeable; 300-500 ms for control messages or safety messages could be disastrous. Often, what is an acceptable level of saturation or utilization from an IT perspective can spell disaster for controls.

In the article, Emerson's cyber-security expert Bob Huba added:

"Using the control system for non-control communications, says Bob Huba, DeltaV product manager for Emerson Process Management, "regardless of how much 'extra' bandwidth appears to be available, can only lead to problems getting the mission-critical control information distributed as quickly as possible."

On these points, I can't disagree. I believe engineers, on their plant intranet networks, outside the firewalls and DMZ, which separates this network from the plant's control network, should have access to these social media applications--for the reasons we cite in the Web 2.0 article.

I also believe there is benefit in experience sharing with some of these social media applications like wikis, blogs, and microblogs hosted internally, inside the firewall, but also not connected to the control network.

Where once the operator and maintenance workstations were the only way to view information, we now live in a world with phones, hardened portable devices, and other handheld devices that can connect people to the information they need without piping this information through the control network.

My thoughts in summary... keep that pressure on the IT folks to open up the plant networks to social media applications, but not the plant control networks.

MP3 | iTunes

Update: Welcome Feed Forward readers! Paraphrasing the words of Get Smart's Maxwell Smart, "I hope I wasn't out of line with that crack about engineers." As an engineer, I mean it only in the most endearing way!

In the news a while back was Emerson and Flow-Cal, maker of the leading natural gas accounting software. They introduced Coriolis-specific data integration to the FLOWCAL software. The purpose is:

...to enable direct interface of API Ch. 21.1-compliant Micro Motion Coriolis data with Flow-Cal accounting software for natural gas production and transmission data management.

The API Ch. 21.1 standard refers to the electronic gas measurement portion of Chapter 21, Flow Measurement Using Electronic Metering Systems. It encompasses the flow computer as well as the gauge/impulse lines; cabling/wiring; peripheral devices including counters, pulse generators, on-line analyzers, densitometers and gravitometers; calibration equipment; and measurement software.

I turned to Emerson's Marc Buttler, a manager in the Micro Motion division to get the story for how this integration was made possible. He described the typical natural gas accounting path. It starts with the flow meter measurement on the gas production line. The flow meter feeds a transmitter or flow computer, also known as electronic flow measurement (EFM). A SCADA system typically polls this information, and sends it to the enterprise management accounting software.

The American Petroleum Institute (API) and American Gas Association (AGA) have very strict requirements for this data required by the natural gas accounting software. The data must include the measurement, associated configuration, and the event logs around the measurement.

Marc shared with me that the Remote Automation Solutions business within Emerson has had a longstanding relationship with the Flow-Cal organization. The Micro Motion team also has had a longstanding relationship with their parent company, Coastal Flow. The engineers at Micro Motion and Remote Automation Solutions teamed with the Flow-Cal engineers to complete the path from the Micro Motion flow meters, with a FloBoss 107 or a ROC809 as the flow controller, and ROCLink software used in place of SCADA polling software.

Technically what happens is that the ROCLink software delivers the flow meter data in the Flow-Cal specified .CFX file format for Coriolis natural gas flow measurement required for AGA 11 (Measurement of Natural Gas by Coriolis Meter) and API Ch 21.1 compliance.

By automating this flow of information through this collaborative R&D effort, energy producers can increase the reliability of their natural gas measurements and production accounting, while reducing the maintenance and capital costs. Much of these improvements come from the accuracy and reliability of Coriolis measurement. It measures gas volume without additional temperature or pressure measurements, which reduces the components to purchase and maintain.

As Coriolis measurement continues to move into the mainstream of natural gas flow metering, Marc sees more SCADA polling suppliers developing and providing the connection from the electronic flow measurement device to the Flow-Cal software to provide the end-to-end natural gas production and transmission management.

MP3 | iTunes

I caught up the other day with Emerson's Shenling Yang, who is a senior project execution engineer in the Life Sciences and Food & Beverage (LSFB) industry group. You may recall Shenling from earlier posts.

She shared two pieces of news with me. The first is that the Critical Data Backup application developed by the LSFB team, and used for protection of DeltaV automation system configuration and critical process data, has been extended to the Syncade operations management software. Shenling has been working on a project with a pharmaceutical manufacturer implementing this application.

In one of the earlier posts with Shenling, Backing Up and Recovering Critical Control System Data, the goal of a biotech manufacturer was total recovery from a system failure in hours instead of weeks. For highly regulated industries, the scenario described was:

...the dreaded 3 am phone call from the plant with the news that production has stopped, people standing around and it's up to you to do something. Choice one is to go to the plant, to rebuild the automation system configuration, to revalidate the process, to lose a bioreactor batch that may have been running for up to 100 days, and then to hopefully resume production within a few weeks.

The Critical Data Backup application was the solution:

...to meet the 21CFR Part 11 compliance for backup, recovery and preservation of electronic records. It's a part of the overall disaster recovery plan, which includes files, spare on-site server hardware, physical separation of equipment and networks, and always-available support personnel on-site.

With the ISA95 Enterprise-Control System Integration standard, this critical backup need extends to level 3. The Critical Data Backup covers some of the Syncade Suite modules including: Document Control & Archiving, Security & Audit, Equipment Tracking, Batch Production Record, Recipe Authoring, Training and Development, and Manufacturing Information Portal. The backup extends beyond the operational and configuration data to include backup reports, style sheets, and behaviors.

I did mention there were two pieces of news. The second is that Shenling is moving to Shanghai to work with the Emerson Asia Pacific marketing team. She's promised to help me discover and tell stories of all the great work being done by our experts in China. I look forward to being able to broaden out the view of these Emerson experts around the world.

Safe travels and best of success in your new assignment, Shenling! And, make sure to show this post around to everyone that we've promised our readers some good stories.

MP3 | iTunes

One of the things I'd like to do more in future posts, is to "hand over the keys" to this blog to one of our experts and "let them drive." Today's post is from Joanne Salazar, a member of the Data Management Services team. For those of you who use Twitter, Joanne is @perspective21. Joanne's subject is that area historically defined as manufacturing execution systems (MES). I'll not indent in a quote box for space considerations, but I hope you enjoy Joanne's words below:

The promise of MES has been difficult to achieve over the years, partly due to limited product functionality. MES is broadly defined as an information technology (IT) solution that supports the primary production processes in a production plant. These applications close the gap between ERP systems and production equipment control, distributed control systems (DCS), programmable logic controllers (PLC), and/or supervisory control and data acquisition (SCADA) applications.

MES applications have become essential to support real-time production control, as well as data collection and reporting that is required in order to improve production performance; however, the practical implementation of these systems can be overwhelming and expensive. The challenge of MES solutions lies in the fact that it is broadly defined and impacts virtually every manufacturing function.

Product functionality that enables a batch recipe to span manual workflow and automated processes, provides a consistent operator interface, and generates a comprehensive batch record without custom coding has not been available until now. In this post, I would like to address the benefits of having a SINGLE batch recipe, developed in a SINGLE engineering environment, using ISA S88 and S95 STANDARDS.

SINGLE RECIPE. In all manufacturing facilities, manual and automated processes need to be coordinated. Manual operations may include filter changes, equipment cleaning, and material weigh dispense. Automated processes involve reading instruments and sequencing values, including steps such as heating, agitation, and material transfers.

Manual operations have historically been addressed via SOP's and paper-based procedures. Automation is commonly addressed using a control system. Therefore, a recipe needs to span across both manual and automated systems to be comprehensive. If the manual and automation systems are not addressed by the recipe, coordination and synchronization of activities needs to be forced, requiring additional resources and reducing efficiency.

One comprehensive recipe that spans manual and automated processes can provide:

• links to reference documents (SOPs, MSDS, P&IDs, etc)
• easy, intuitive interface that walks the operator through work instructions
• transparent access to automated activities with easy views of current process status
• ability to capture data from both manual and automated processes
• synchronization of manual and automated steps to ensure right-first-time manufacturing

SINGLE ENGINEERING ENVIRONMENT. To support a single recipe, it is important to have a single engineering environment to create, modify, and maintain the recipes. A single recipe definition reduces development time, minimizes custom interface software, and enables the process experts to define the recipe. This engineering environment can provide:

• ability to write a "library" of modular operations and steps that can be used multiple times within multiple recipes
• ability to initiate sequencing from one system to the other
• authorization and security functions that are defined once and used throughout the manufacturing facility
• easy, intuitive interface that graphically shows the recipe sequence including both manual and automated processes
• seamless, transparent passing of information between the recipe and the automation systems ensuring synchronization of process steps without the need to write custom code
• comprehensive capture of both manual and automated information, including seamless, transparent capture of automation system data to the recipe electronic batch record

ISA S88 and S95 STANDARDS The use of standards to define and implement recipes improves implementation efficiency and reduces the cost to maintain the solution over its life cycle. ISA-95 (S95) Standard, Enterprise-Control System Integration, is the industry standard for information exchange between enterprise and manufacturing control activities and their supporting IT systems. S95 is oriented toward the definition of data models, work activity, and information exchange.

ISA-88 (S88) Standard, Batch Control, provides guidelines for the design and specifications of batch control systems. S88 is oriented toward physical work execution. S88 is based on a well-defined equipment-oriented conceptual structure and a hierarchy of control functions that acknowledge manufacturing management functions and extend all the way to the manufacturing equipment itself.

Products that adhere to these standards provide easier implementation of recipes by using common terminology, providing a structure that allows process experts to define the recipe, enabling software module libraries for common functions, and predefined integration to other software applications. The use of standards also makes it easier to maintain the solution over its life cycle, ensuring that new product software versions will continue to function and communicate properly with other software applications.

I had the opportunity to visit with Emerson's Tom Wallace who was here in Austin recently. I like to joke with Tom that a post I had done with him comparing and contrasting HART and Foundation fieldbus caused such a stir, that it produced one of this blog's highest monthly visitor totals to date.

So let's see what we can do this month! Tom takes a comparative look at some of the swirl that surrounds EDDL and FDT/DTM in a new paper, FDT/DTM, and Enhanced EDDL, what's best for the user. These are both technology enablers for field devices, automation systems and asset management applications.

If this is all acronym soup to you, here's Tom's brief description of these technology enablers:

Device functionality is invoked using Electronic Device Description Language, EDDL or DTM's [Device Type Manager]. The DD or DTM tells the host what functionality the device has, and how the functionality is invoked. It also tells the host how to do common maintenance functions such as calibration, trims, tests, and other device activities.

I'll start with Tom's conclusion and then highlight some of his supporting points. He concludes:

In my opinion, there is a better technical implementation based primarily on ease of implementation and support. That solution is to use EDDL for all devices where EDDL is technically capable of delivering complete device functionality, and to use a DTM or a snap-on application to handle only the exceptions. I make this recommendation because it is simpler to implement a single solution than a combined solution. EDDL is a single solution that will work for the vast majority (95%) of HART, Foundation fieldbus, and Profibus PA devices.

Tom's point for commissioning Foundation fieldbus devices contrasts installable programs versus data files:

Commissioning Foundation fieldbus devices on most control hosts require DD's [device descriptions]. Most control hosts have a set list of applications that are considered safe to install on the host engineering or operator station. Each DTM is an application, and the testing required to ensure hundreds, or potentially thousands of DTM's are compatible with a control host user interface is not practical. EDD's are files, not application programs. Therefore there is no program installation risk loading EDD's on a control host.

On data availability, Tom writes:

...EDDL is the path for data availability that originates from a device, or is going to a device. The OPC Foundation support for the enhanced EDDL will broaden the use of EDDL for applications such as ERP, maintenance management, and other applications.

For the display of data in field devices, Tom notes:

EDDL is supported in the host by DD services. DTM is supported in the host by a frame or FDT. For many applications and hosts either EDDL or DTM can be used for data display. For hosts that are not based on a windows operating system, EDDL will be used as DTM requires a windows operating system. EDDL has defined display objects such as charts, graphs, etc. DTM is more of a free form environment using a variety of programming languages.

The choice for the enabler technology to use is EDDL or a combination of EDDL and DTM. Tom lists some considerations for your discussion based on operating systems, operating system version management, functionality and complexity of the device and if a custom display needs to be created.

Tom sums all this up with the following recommendation:

The final recommendation is to use EDDL as the required standard since each device must have a DD. Allow the use of DTM's on an exception basis where the functionality is required, and EDDL cannot provide it. Make sure that all the functionality to replace a failed device, or place a new device in service is available in EDDL. This will simplify implementation and maintenance, mitigate operating system migration issues, and provide a lower risk more error free working environment.

Update: Welcome readers of Gary Mintchell's Feed Forward blog! Join the conversation and add your comments below or on Gary's post.

While in Asia last week, I had the opportunity to catch a presentation by Bob Lenich, Director of Emerson's Data Management Services. With the announcement last year of Emerson's acquisition of Decision Management International and the Compliance Suite manufacturing execution system software, Bob has been busy integrating the organizations.

The Compliance Suite software is being used by many process manufacturers, especially in highly regulated industries such as Life Sciences--Pharmaceutical and Biotech manufacturers. The starting point for applying manufacturing execution system software is the data model defined by the ISA-95 (S95) standard. The S95 standard describes the architecture of information flow between the plant floor, the automation system, the manufacturing execution level and the enterprise resource planning levels. Getting these workflow activities and the flow of information between them right is what defines highly efficient, customer-responsive manufacturers.

Bob described the place to start as understand the challenges of improving quality, improving throughput and/or increasing process availability/uptime as a few examples of what can drive process manufacturers to look at improving the flow of information around the organization. You have to understand the problems and needs in order to improve things.

As an example, in the area of quality, typical issues are to reduce deviations. These can be caused by ensuring the right material is available to add at the right time or eliminating manual error in calculations. Also, much time and effort currently spent just doing all the paperwork and paper work tracking required to meet today's regulatory needs. Converting from paper to paperless systems can eliminate all of these problems

In addition to eliminating problems, reducing these deviations also improves throughput by reducing batch variability, reducing batch cycle time and reducing the overall batch release time as there aren't as many problems to address.

Solving these problems requires addressing a mixture of automated and manual processes. Bob noted that the best way to address these issues should begin with a look at the current workflow, to understand where efficiencies can be gained.

The workflow should look at equipment, people, materials, documents and existing information to develop the business justifications and information architecture to address the areas of inefficiencies. Once a good benchmark is established, improvements can be made and the results quantified.

There many opportunities to do this and Compliance Suite is a great tool to use for enforcing these changes. Bob stressed that these changes are typically strategic in nature for the process manufacturer and require the upfront planning and design work to focus the efforts to the areas of greatest efficiency gains and continuing to prioritize the areas of improved data management and flow over time.

I'm returning back to the U.S. from a week of meetings in Thailand. I'm struck by the sheer number of large greenfield projects being implemented and being planned across the Asia-Pacific region.

Over the past several years, Emerson project teams from this region have executed and are executing many of the mega-sized projects. Some examples from prior press releases include: Shanghai SECCO Petrochemical ethylene complex, Fujian LNG-import terminal, and Reliance Life Sciences therapeutic proteins manufacturing.

These projects are executed on a global scale with participation from project engineers from many countries in many world areas. Advances in communications and what can be done across the internet make global project collaboration and management possible.

While in other world areas we see a lot of experienced automation professionals retiring, in this world area a new generation of automation professionals is coming on the scene. They are learning the automation craft as these projects are executed and the new plants are operated.

Working on greenfield projects mean these new automation professionals get to use the lastest technologies like digital busses, controller-based advanced control, and enterprise connectivity to build plants that are more efficient than what is possible with prior technologies.

With my visit and new connections made, I hope to bring more stories of Emerson experts from this bustling region of the world.

I caught up the other day with Michael Barrett who manages some of Emerson's relationships with providers of production management software like OSIsoft.

Michael strongly believes that production management is a key success factors for process manufacturers competing in a global market. He defines production management as the area of management information systems that work with the planning and scheduling applications that drive the manufacturing operations in a Continuous Improvement Loop. This supports a company's Supply Chain Management by insuring the availability of right product at right time at the lowest cost.

As an example, Michael cites a refiner who imports heavy crudes. They may have several locations to decide where to process it. The refinery ultimately receiving this heavy crude must ensure that they have available tankage to receive the crude, processing capacity to run it and logistics capability to handle the products. They must also make sure they are receiving precisely the quantity for which they are being invoiced. One of the challenges is accurate measurement of water in the crude receipt. If a refinery needs to wait on a 2MM Barrel parcel to let it settle in a tank to accurately measure water--that takes time and at the current price of crude is huge investment tied up ($50/Bbl times 2MM = $100,000,000).

They also may have to consider the hydrogen and fuel requirements to keep the refinery in hydrogen and fuel balance. Doing monthly or even weekly mass balance on the refinery and the internal units does not generate enough visibility to maximize the operational efficiency for the refiner in a global market. To accomplish these objectives many sites are facing a measurement shortfall. An obvious example is the water in crude measurement. Typical errors here can translate into millions of dollars paid for water. Many refineries also have issues with high levels of unaccounted losses in the loss control reports. Top tier refineries maintain unaccounted losses to less than 0.5% on crude. That kind of performance is not possible if you only measure the loss once per month.

Companies are engineering new refineries today coming on-line in 5-7 years in parts of the world where the owners will own the crude feed. They are being designed with digital communications technologies in the processing equipment and systems to interact more tightly with the scheduling and planning systems to maximize and optimize these assets and the added value products coming from the crude.

Michael believes the challenge for existing refineries is to improve and integrate the production management systems to account accurately on a daily basis actual verses planned production. This allows the planning and scheduling departments to improve asset utilization and squeeze more efficiency from existing equipment. Production Management systems should provide key metrics for operations management to make decisions that maximize response to market demands, spot opportunities and operating flexibility to better differentiate themselves from their competitors. This agility coupled with improved asset utilization will help existing refiners better compete as the modern, high-tech refineries begin to come on-line.

Michael recommends beginning with a thorough analysis of the production management system as a first step. This can be the basis of building a business case for change to more agile production. Developing and providing decision alternatives with their business impact is an important part of this improvement plan. There is no one thing, but rather a combination of tools, work flow changes and operational discipline which can reveal the scale of performance improvements possible.

As reported in my DeltaV News RSS feed, Emerson's Michalle Adkins and Dawn Marruchella have written a great piece in the AIChE's Chemical Engineering Progress Magazine entitled, Ask the Experts - Avoiding the Pains of Systems Integration.

In it, they recognize some of the issues process manufacturers have faced with manufacturing execution system (MES) integration projects and they share their expertise about how to reduce concerns about integrating existing batch process and achievable business benefits.

Their initial guidance is to analyze the integration needs and current business processes and develop a solution weighing the costs and risks against the sought benefits.

Functionality can overlap in both the MES and control system. If your control system has well integrated batch capabilities, Michalle and Dawn recommend using it to manage recipe execution and historical data collection around the batch. This reduces the complexity of the integration between the MES and control system and helps simplify the requirements for the MES. Then ease of MES and DCS integration and specifically capturing the information required for the electronic batch record would be the focus of the integration efforts.

Also, as mentioned in prior posts, they recommend that the solution have:

Support for web services, a service-oriented architecture, and the use of XML schemas, such as ISA-S95's business-to-manufacturing markup language (B2MML)...

Their final recommendation is to review successful implementations to understand not only the software and integration, but also the experience of the project team who implemented the solution.

The benefits for these efforts must accomplish the highly sought after business objectives. If these objectives are to reduce the cycle time for product release, you can incorporate much of the current after-the-fact documentation into the running batch process. Examples cited include:

• Manual setup, cleaning, and maintenance activities
• Review and approval processes for master and batch documents
• On-line data validity checks, electronic signatures, and completed calculations
• Exception-based reporting tailored for intended audience

By executing these tasks during the production of the batch, process manufacturers can increase their right-first-time metrics and shorten the post-batch approval cycle time. The article cites other achievable benefits based on the identified business objectives such as reducing deviations, significantly decreasing manual data entries, and eliminating paper log books.

In an earlier post I discussed common transactions between enterprise, manufacturing execution, and control systems. At the heart of this exchange of information is Extensible Markup Language (XML) to pass types of data between systems in a standard, text-based way.

For instance, if you subscribe to this blog's RSS feed, it means you have an RSS reader which translates the XML data in the RSS feed and displays it in a readable format.

Another example is our Google search appliance that crawls the Emerson Process Management website to help you find things faster. The search results are in XML with eXtensible Stylesheet Language (XSL) to make the returned search results readable. Also, the latest version of Microsoft's Office (Office 2007) switched from saving data in a binary format to an XML format.

The uses for XML extend far beyond these examples and include the work being done with OPC Unified Architecture standard and many more.

I caught up with Dave Marschall who is an integration consultant in our Life Sciences industry center. He shared with me how he and his team were using the XSL/XSLT stylesheets in the process of creating custom electronic batch reports which contain information from the enterprise planning systems, manufacturing execution systems and control systems. XML is commonly used to store this batch report data from these various systems.

The XSL/XSLT stylesheets allowed the team to create different renditions or views of the same XML data. A production view might include process operations events and alarms, operator comments, equipment usage statistics etc. A quality assurance/quality control view might contain material usage, lot history, expirations, environmental data, laboratory data requests/results, etc.

Dave described a recent project where the addition of Quality Specifications data allowed the customer to add intelligence to these views of information. Instead of just displaying the data in a tabular format, the XSL/XLST stylesheets could perform comparisons between actual results versus the specifications, and change the color or highlighting of any discrepancies.

This change of colors was used to help the process manufacturer quickly scan dozens of pages of report data and identify areas of concern like out-of-spec conditions. The logic also triggered additional batch details where these abnormal conditions occurred to assist in the review process. The net effect of embedding this intelligence into the batch end report was quicker reviews of the batch which meant quicker release of the final product.

By using a text-based standard XML and XSL/XSLT approach, the solution can be well documented and more easily changed over time to meet the changing needs of the process manufacturer.

Update: Welcome readers of Gary Mintchell's Feed forward blog! Also, it was interesting timing to get a ControlGlobal.com email this morning discussing The ABCs of XML, Parts 1, 2 & 3.

Manufacturers increasingly look to optimize their businesses by integrating their business processes with their manufacturing processes. ANSI/ISA-95 (S95) is an international standard for developing an automated interface between enterprise and control systems.

Over the last several years our Life Sciences Industry Center has been working with pharmaceutical and biotech manufacturers on this optimization process in pursuit of operational excellence. I caught up with integration consultant, Dick Seemann, who discussed some commonalities he sees in integration transactions between enterprise planning systems like SAP business software, manufacturing execution system (MES) software and control systems like the DeltaV system.

A key transaction is the process order download which comes from the planning and scheduling software to the manufacturing system in the form of a request for a campaign of process orders or a single process order. The transaction contains a process order number, material components, equipment requirements, and specific parameters that are exchanged through standard web services. The team typically uses Compliance Suite as the MES software between the SAP software and the DeltaV system.

The MES software combines this information from the production, material management, and quality management software and then manages the order execution, performs weigh and dispense, and executes the manual work instructions in conjunction with the automated control system tasks. A complete electronic batch record is maintained at MES level, since it combines recorded manual processes and procedures with electronic information at the control system and enterprise planning system levels. Alarms, events, operation actions, and batch history are passed as transactions from the control system to the MES.

The process orders as the campaigns are being executed provide status transactions back to the planning systems on status changes during execution and upon completion of the process order. Materials consumed during the production and recorded by the manufacturing execution system are passed back as transactions to the material management module to accurately reflect what is available for planning future production.

Start and end times for each of the steps in the batch are also passed back as transactions to the planning systems to provide and accurate picture of equipment utilization and how long production steps take compared to standard times.

Dick notes that all process manufacturers have different business processes and that there are many more transactions that can occur between the three levels. As these paper-based processes are moved into an integrated, transactional world, end-to-end cycle times are reduced resulting in greater manufacturing efficiency.

Transcription errors are also reduced when all communications is electronic-based versus the paper batch sheets. Also, troubleshooting problems becomes easier when a history of electronic batch records is available to review to analyze where inefficiencies have begun to occur.