Scintillating schemas sought
XML translator makes plant floor 'monolithic,' for better plant-to-business integration
By Kevin Parker, Editorial Director -- Manufacturing Business Technology, 11/1/2001 12:00:00 AM
Russ Fadel has a complaint and a mission. President of Exton, Pa.-based Lighthammer Software Development Corp., Fadel complains that while significant strides are being made in business-to-business (B2B) connectivity using eXtensible markup language (XML), the plant floor is being left out of the equation.
"The big enterprise system vendors, including SAP," says Fadel, "have stayed away from shop-floor connectivity. Enterprise applications integration vendors, such as webMethods, have put all of their efforts into connections between the large enterprise systems. Supervisory control vendors have been focused on having a certified connection to SAP for their systems only. They all ignore the fact that there is not a single plant-floor system, but that information related to inventory use, work-in-process movement, and other production performance parameters must be gleaned from many different systems." (See sidebar, "Why so much SAP?")
Examples of supervisory control vendors would include Intellution, Foxborough, Mass.; Wonderware, Irvine, Calif.; and USDATA, Richardson, Texas.
XML is a computing language well-suited for use in application-to-application transfer of structured data. It does so by describing such data in an open, text-based format and using the Hypertext Transfer Protocol (HTTP), or other transports. Besides delivering data to desktops, XML serves as a format for server-to-server data transfers.
Lighthammer's mission, Fadel says, is to leverage the power of XML in a solution that makes the plant appear "monolithic," by allowing an enterprise system to draw on the full range of plant floor data, as needed—i.e., plant-to-business (P2B) integration.
Heretofore, P2B integration has been accomplished a number of ways, including: 1) downloading of work orders and recipes in flat-file format to supervisory control systems, which in turn transmit material usage and other data back to the business system; 2) configuring a manufacturing execution system with a relational database as its nucleus, which includes functionality for such things as work instructions, recipe management, and materials management; or 3) manual data entry for inventory use and work-in-process (WIP) movement tracking. With any of these methods, further integration is required to other systems, such as for plant scheduling or quality management.
Even for point solutions, says Bradley Ward, Lighthammer director for real-time supply chain products, "plant-to-business integration has always been a custom project that could take four to 12 months to complete. In that time, many things can change."
More complexity on the way
With contract manufacturing becoming the norm, it's fair to say demand for plant-to-business integration is growing. But the task becomes even more complex in this changing environment because "the 'make' link of the supply chain must serve multiple masters—SAP for one customer, [supply chain planning vendor] i2 Technologies for another," says Ward. "To achieve the goal of a real-time supply chain, integrating information from the plant into business systems must be 'productized'."
What's needed, says Lighthammer, is a system that allows plant personnel, using a "point-and-click" metaphor, to create "meaningful" transactions that can then be mapped into an enterprise resources planning (ERP) system. In this way, once created, the transactions are automatically translated and delivered to the ERP system in the XML schema required. Transactions can be based either on a plant event—such as end of batch, WIP movement, or end of shift—or in response to an in-bound request from the ERP system.
Schema translation is important because while all major enterprise and other type application vendors support XML, there is as of yet not a single standard. Even if the base standard is agreed upon, XML only provides a framework, and how the standard actually is used can vary widely. And, of course, manufacturing plants are rife with legacy systems that are not XML-enabled at all. In these cases, it's not a matter of schema translation as much as generating XML based on other type output.
A great deal of work is being done in the B2B arena, says Fadel, to define things like a "purchase order," by groups such as the OAG, RosettaNet, Microsoft with BizTalk, and Sun Microsystems with ebXML. "But still, the schema for a purchase order in an SAP system is different than the schema for a purchase order in a J.D. Edwards system."
For example, a simple schema translation might map the element PO_NUMBER in one system to the element PO.NUMBER in another.
A more sophisticated kind of mapping involves different structures for handling purchase orders. For example, purchase order management in one system might consist of PO_NUMBER combined with PO_SEQUENCE_NO, to handle purchase order revisions. Another system might handle revisions by changing the PO_NUMBER each time there is a revision and take care of the necessary housekeeping behind the scenes. In this example, schema translation would concatenate PO_NUMBER & PO_SEQUENCE_NO and map the result into PO.NUMBER.
Transactions needed
Unfortunately, things get even more complicated in the P2B world because there are no predefined structures such as those for "purchase order" and the like, which, as indicated, are present in all ERP systems with only slightly different elements or structures.
In the plant, data is typically unstructured. For example, information such as "material usage by shift" could be found 1) in TAG LIC-330 in a data historian; 2) in an execution system query: Total MATERIAL_USAGE where start time = 8:00 and end time = 4:00 and WHERE area = Line 1; or 3) through a calculation taken from programmable controller or supervisory control system values: GET Count21 + Count22 + Count23 = material usage; or 4) some other expediency.
Thus, says Fadel, for the business system, there is not much value in raw data taken from the sensor or supervisory control level. "Enterprise systems need the data in context, and they need enough data to complete a transaction. Raw or low-level interfaces don't add value."
Ward says Illuminator, Lighthammer's enterprise manufacturing intelligence system, has the plant-system connectivity and XML foundation to solve the P2B connectivity problem. This is so because it acts as a universal translator—connecting to systems that speak different languages, sometimes XML-based but often not, getting the needed information, doing the in-line data preparation, and transforming it into the ERP system's XML schema.
Apart from any role it may play in P2B integration, an enterprise manufacturing intelligence system such as Illuminator is one that aggregates data taken from a wide range of computing sources—both on the plant floor and in business systems—to organize that data into meaningful, roles-based information for analysis and reporting. Use of Internet technology delivers information and production data to any authorized user via a standard Web browser or other Internet-ready device.
Other vendors in this space include Indx Software Corp., Aliso Viejo, Calif., and Executive Manufacturing Technologies, Ontario. Based on the technologies involved, but applied to a slightly different set of business problems, comparisons could also be made to supply chain event management vendors such as SeeCommerce, Palo Alto, Calif., and Efinity, Aliso Viejo, Calif.
Solution outlined
Lighthammer now says that using Illuminator's AdvancedXML module, plant system data can be mapped into ERP transactions by plant personnel, allowing integration to be implemented and tested in days. In this regard, Illuminator acts as the universal "plant connector."
Says Ward, "We made this happen by adding to Illuminator a visual transaction mapping tool and communication routing rules. These let engineers or IT personnel quickly link data items from plant systems into the elements in any XML schema. The resulting 'P2B transaction' contains everything that is required to query plant systems for appropriate data, perform data conditioning, transform it into any XML schema, and deliver it to the ERP system."
Data conditioning is the in-line process discussed above that achieves something as simple as converting formats for dating, e.g., MM/DD/YY to MM/DD/YYYY, or performs calculations such as summation or integration. "We leverage Illuminator's key performance indicator calculation engine for sophisticated calculations. Simpler transformations are handled in the XML transformation engine."
Use of a plant-floor solution for schema translation "will reduce the cost and risk associated with empowering enterprise systems with fresher, more accurate data," says Fadel. "This increases the effectiveness of capable-to-promise, available-to-promise, and supply chain planning applications— reducing inventory and improving order fulfillment accuracy."
