PLM Interoperability: Can XML Circuitry Be the TCP/IP of PLM?
By Ken Verspille, Research Director, D.H. Brown Associates, Inc.

De facto standardization atop the TCP/IP networking protocol established a universal technology framework in the '80s. As a result, the Internet exploded as a viable, open-communication medium. Today, Product Lifecycle Management (PLM) initiatives seek an analogous communication framework to link the wide range of disparate applications that are necessary to conceive, plan, design, produce, market, sell, and service manufactured products. Although no comprehensive solution has yet to emerge, competing PLM vendors and consortiums all bank on Extensible Markup Language (XML) technology to form the communication "protocol" of PLM.

The strengths of XML derive from its ability to describe the language of PLM, and its data content, in an open, non-proprietary format. The effort with XML too often fails, however, to meet the key challenges necessary for PLM applications to truly communicate. The winning solution will be the one that establishes the correct level of data granularity and relational connections between data objects; that best fits what will come to be the actual usage model of PLM users.

That usage model is only partially understood today. It relates to exactly delineating all the applications users will need to manage the full product lifecycle. What are the critical data objects from any one application that must be shared with other applications? How are those shared objects from disparate applications related to each other? Today, industry technologists from the PLM solution vendors can make informed decisions on the correct level of data granularity and relationships based on their current experience. No one - not even the users of future PLM applications - can predict with any real confidence how their business and product development processes will evolve to take advantage of these new capabilities. New or varied processes will potentially require data and data relationships not currently envisioned. A solution that underestimates the correct level of data granularity will block users from accessing the data they need; a solution that overestimates the correct level of data granularity runs the risk of creating a cumbersome, sluggish implementation that users will reject.

The Compounding PLM Interoperability
The vision of PLM is to establish and automate cross-organizational business processes, product development process data exchange, and collaboration. That is a huge task.

Solution providers on the product development side have been challenged for decades to supply integrated, interoperable applications that span conceptual design, detailed computer-aided design (CAD), computer-aided engineering (CAE), and computer-aided manufacturing (CAM) systems. As each advance is made, the problem becomes more formidable because of rising product complexity, and the increased depth of the specialized applications and processes that must be addressed. The track records of solution providers to address these issues have improved dramatically over the years. But none has earned an A+ from users for interoperability. The challenge has been especially acute in dealing with the real-world requirement that disparate applications from different vendors must interoperate smoothly as users look to more closely integrate their in-house product development together with partners across their supply chains.

PLM expands the challenge by now including all the business process applications needed to plan, manage, sell, and service products. Today, the major commercial PLM vendors all race to provide solutions in business planning, requirements capture and analysis, procurement, supply chain management, asset management, and sales and distribution management. The list keeps growing. Each new application adds to the potential pool of PLM data objects that must be captured and shared across a future PLM communication framework. In addition, choices must be made on the relationships between these new business data objects. How are assets, for example, related to specific product plans? Moreover, the interaction between business objects and product development objects must be detailed. How are manufacturing assets related to specific design configurations during production?

Defining the Level of Granularity and Detailing the Relationships
The technical challenge is one of granularity and relationships. With enough software development, every application vendor can flood PLM circuitry with every bit and byte of their application's data wrapped in XML. The concern centers not on how data is wrapped, but rather how much data is wrapped into individual bundles to facilitate its access. For example, a component 3D solid model could be XML-encoded as a single, large object. That would facilitate a disparate application only when its need is to reference (or point to) the component solid as a whole. Such a case might occur when linking the procurement supply-chain purchase order to the outsourced component.

However, numerous scenarios can already be predicted where the disparate application needs reference only to a portion of the component model, for example, a particular form feature such as a countersunk hole or a flange. If the component model is encoded as a single, large object, that application can only reference the component as a whole and implement a likely non-standard method to locate the form feature of interest within the component model and unwrap the full solid model in order to access it. That defeats the goal of a consistent, sharable solution.

Any win-win solution will have to strike a balance on the correct data granularity to enable the widest possible set of expected references while minimizing the work needed to decode exceptional references.

Competing PLM Interoperability Alternatives
The landscape of PLM solutions today is composed of commercial vendors from every corner of the problem set. CAD vendors are moving toward full PLM. Enterprise resource planning (ERP) vendors are expanding outward from manufacturing. Data management and document management vendors look to grow their application footprint in PLM. Standards organizations, such as ISO STEP, UN/CEFACT and OASIS, and consortiums of vendors, such as OpenHSF, are active participants as well. Each brings their own perspective to the PLM challenge in developing a communication framework, but all agree that XML will be the vehicle.

The EDS PLM Solutions' technical strategy leverages the existing Direct Model JT visualization data format from their TeamCenter Visualization suite and the XT geometry data format from the Parasolid geometric modeling kernel. The solution, named PLM XML, is based on standard W3C XML schemas and is positioned as "representing a variety of product data both explicitly and via references, that provides a lightweight, extensible and flexible mechanism for transporting high-content product data over the Internet, and aims to form the basis of a rich interoperability pipeline connecting EDS PLM Solutions products and third-party adopter applications." EDS employs the analogy of data "pipelines" to represent the circuitry within their PLM framework. The strategy calls for additional "pipes" of data, all XML-based, as applications are added to their PLM suit of integrated products.

Tech Soft America and Spatial have amassed an impressive list of vendors and programming end user companies who assert they will support the OpenHSF implementation for visualization data. The consortium positions its brand of PLM connectivity as "an open format, freely available to anyone, so all content creators can export the HSF format and any downstream applications can import this data." They further indicate that "through this effort, intelligent digital models in the HSF format will be able to move smoothly through concept, design, analysis, manufacturing, marketing, e-commerce, maintenance and end-of-life segments that make up the product lifecycle." Supporters of the initiative include PTC, ANSYS, CADKEY, IronCAD, MSC Software, Alias/Wavefront, Actify, and Framework Technologies, as well as important end user companies such as Boeing and DaimlerChrysler.

With STEP XM, STEP counters EDS' Parasolid and OpenHSF's expected use of ACIS (from Spatial) for the XML wrapping of information on geometry and product structure. The XML wrapper for STEP allows the encapsulation of STEP's EXPRESS language to capture a product model's data and structural aspects. STEP, however, must rely on commercial vendors to implement the specification for their proprietary data. That is a difficult sell considering those vendors' past lukewarm support for STEP, now buttressed by their own technology solutions for PLM circuitry.

The industry will also need to deal with technology upstart, Proficiency, Inc., and its brand of intelligent data interoperability. Proficiency's Collaboration Gateway provides interoperability through sharing of CAD design intelligence, including features, dimensions, history, assemblies, meta data, and other information through a Universal Product Representation(UPR) data structure. The product currently supports I-DEAS, Pro/ENGINEER, CATIA V4, CATIA V5, and Unigraphics.

On the business process side of the PLM equation one of the more robust initiatives to capture business data for business-to-business integration using XML is ebXML. The ebXML framework represents a global electronic business standard sponsored by UN/CEFACT and OASIS that will allow businesses to find each other and conduct business based on well-defined XML messages within the context of standard business processes. It promises a standard methodology to describe company e-business capabilities, interoperability with trading partners' data and applications, and a standard transaction and collaboration architecture.

In addition to ebXML, new XML-based interoperability and integration standards are being defined by leading vendors known as "web services". Web services allow application capability to be published as a service using standard interfaces that lowers barriers to application integration across a business process. PLM vendors are going beyond basic XML support and are developing strategies to incorporate web services into their products to enable standards-based PLM integration.

While the energy level is evident across these numerous participants, the promise of a de facto standard for full PLM circuitry will only be realized once working versions of these implementations are in place and garner the acceptance of actual PLM users. Pragmatic estimates envision that this process will take three-to-five years with many missteps and rewrites along the way. The answer to the question of whether XML can be the circuitry of PLM is yes, but a qualified yes. The hurdles of data granularity and data relationships must still be addressed.

Our research programs in both Design Creation and Validation, and PLM Integration make this Technology Trends available to all our subscribers. DHBA has also initiated a major review of PLM Integration with Web Services, New Industry Standards for PLM Business Process Automation. A second major study will shortly be launched on Integration Platforms, Tradeoffs between EAI and Application Server Vendors in Manufacturing Environments. Those interested in participating in these collaborative research efforts should contact marketing@dhbrown.com.