Manufacturing: TranXML, Architecture, Engineering, and Construction XML (aecXML)

Manufacturing

Businesses of all shapes and sizes have been impacted by the constant need to delivery more products or services at lower costs and greater margins. Businesses face pressures of time, competition, lack of resources, and, of course, greater revenue.

Although these are the typical, everyday problems that businesses will deal with as long as there is a market, XML technologies and standards have attempted to solve some of these problems.

Once the general business issues are addressed, issues more specific to an industry or particular business remain. For example, how do utility companies communicate their billing needs to their customers? How do construction companies share planning and material requirements documents? There are also applications for XML in the manufac-turing industries to provide functionality for data interchange between ordering systems and shop-floor scheduling systems, enabling machine and equipment communication, providing standardized bills of material as well as pack-and-ship systems, and simplify-ing software configuration.

Because Chapter 20, “Implementing XML in E-Business,” deals with e-business stan-dards, how does this section overlap with what we have dedicated an entire chapter to? The answer is simple: Manufacturing involves more than just supply-chain operations. E-Business specifications just cover the business part of manufacturing; we have to deal with the actual manufacturing process itself. Even before there was a formal supply chain to speak of, there were processes that resulted in the fabrication of products from raw materials. As the factory became an automated workplace, the need for paper and processes surely followed. It’s these automation, assembly, factory, and associated processes that are moving from paper to electronic formats, and XML is empowering this revolution.

However, despite this focus on manufacturing, there aren’t many shop floor and factory XML standards that have garnered widespread attention and adoption, so we’ll focus on what it takes to get products from point A to point B (otherwise known as shipping and logistics).

Shipping and Logistics

As mentioned, many of the issues in producing product have to do with getting the man-ufactured product from one location to another. In many cases, we are talking about ship-ping, but more generally these activities are called logistics. Transporting goods in many ways is a horizontal industry, because it crosses so many industry boundaries. After all, products as diverse as running shoes, waterbeds, and automobiles all need to be trans-ported. However, transportation and logistics are usually considered vertical industries because they have very domain-specific vocabularies and business processes.

The goal of shipping and logistics standards is to provide a common base for communi-cating shipping instructions, bills of lading, packaging, routing, and related logistic infor-mation. It would be unreasonable to assume that every industry that touches logistics should create identical vocabularies, so many logistics-focused vendors have come together to create standards that can be shared with other industry and standards organi-zations—and XML is the language of choice for enabling these possibilities.

TranXML

Originally formed as part of the transportation giant Union Pacific, Transentric branched off on its own in mid-2000 as an organization focused on solving the technological prob-lems faced in the transportation, shipping, and logistics industries. Leveraging its 20 years of experience in developing semantic repositories for logistics and transportation needs, Transentric has developed an open, cross-vertical specification called TranXML for standardizing the way that transportation information is sent between customers and freight carriers.

In many ways, one can look at transportation as a “horizontal industry” that is applicable to multiple vertical industries. Industries as diverse as petroleum, automotive, computer manufacturing, textiles, and agriculture all rely on transportation as the means to get their products to market. Therefore, they have usually created vocabularies to express the vari-ous needs in describing transportation, shipping, and logistics information. Much of this information is the same, regardless of the industry being described. As such, transporta-tion companies such as Transentric have sought to bring some order to the chaos by pro-viding a single cross-industry definition of transportation needs. In standardizing this format, TranXML hopes to provide the benefit of cost savings and efficiency to the “small mom and pop” organizations. Also, TranXML serves an important role in enabling internal communication, interapplication integration, and communication with the systems of other trading partners.

Rather than creating a new semantic representation of this information, Transentric sought to leverage its years of experience in EDI and present a format that is easily exchanged with this format. EDI use is widespread in the transportation industry, and requiring a new format that uproots the existing technology would cause unnecessary difficulty in gaining acceptance and adoption. The TranXML specification therefore mirrors many of the existing X12 EDI specifications and uses an architecture that accepts EDI messages at one end, converts to an “XEDI” specification by means of an XML Solut-ions XML transformation tool, and results in a native XML format well suited to EDI integration. This EDI approach uses qualifiers as attributes, thus keeping compliance checking similar to X12. However, the EDI “conversion” only gets one halfway there, since it represents a simple transformation. The real added value of the TranXML group is that it uses its domain knowledge and expertise to transform these EDI-based elements into native XML code that differs based on interpretation of X12 standards. For example, equipment, name, and invoice structures are particular to individual industries and organizations.

In April 2001, Transentric released eight TranXML schemas in support of its standards effort. These support applications such as load tendering, delivery, freight billing, recon-ciliation, scheduling/forecasting, and equipment ordering. Specifically, the schemas cor-respond to rail bills of lading, car location messaging, motor carrier bills of lading and load tender, shipment status and weight, terminal operations and intermodal ramp activ-ity, and a dictionary for transportation terms and attributes. The next release of additional schemas will include rail waybills, car handling, shipper car orders, switch lists, advance shipping notices, and warehouse stock, shipping, and inventory.

One of the benefits of a single cross-industry transportation description such as TranXML is that it provides an easy and inexpensive way to implement new trading part-ner relationships, because it leverages EDI and provides a neutral format that enables both carrier and shipper legacy systems to exchange data. Because the format requires some of the capabilities of EDI, it has taken advantage of XML Schema, which provides more advanced grouping, data typing, attribute capabilities, and inheritance capabilities. Developed as an open standard, TranXML is designed to be vendor neutral, and licenses will be available free of charge.

Because the interest in transportation vocabularies, especially track and tracing function-ality, is widespread among many industries, Transentric sought to form a neutral, inde-pendent organization for the promotion and continued development of the TranXML format. The mission of TranXML.org is to provide a neutral, cross-industry forum for the development of collaborative logistics supply-chain XML vocabularies and functions.

The collaborative effort will encourage participation by carriers, shippers, and third par-ties. TranXML.org also meets its goals by forming relationships with other standards organizations, such as the Chemical Industry Data Exchange (CIDX), RosettaNet, and the Joint Core Components group of ASC X12 and UN/EDIFACT. The important consid-eration is that a critical mass of carrier adoption (rail, ocean, motor, and air) is needed.

The group is working with other industries that share synergies due to shared transporta-tion needs. For example, ChemXML is heavily drawn from X12 and EDIFACT directo-ries and would also benefit from a TranXML relationship. TranXML has adopted the ebXML framework for transport, routing, packing, and security. It would like to work closely with the JCC but have some concerns about interest and overlap. Despite these concerns, TranXML is working to get involved with the JCC repository and ensure proper expertise in this domain area. RosettaNet also provides an opportunity to gain from a TranXML relationship, because its schemas provide only the basics for trans-portation and logistics need.

TranXML is a focused, detailed effort that is sure to gain adoption and attention by the industry as soon as the various vertical industry specification efforts realize that trans-portation, logistics, and shipping are not their core competencies. It is hoped that the TranXML.org group can promote its efforts and continue development to the extent that other specification efforts leverage its work. After all, it makes no sense to reinvent the wheel in transportation—that’s where it was invented in the first place.

Architecture and Construction

The folks who are responsible for the creation of buildings, namely architects and the construction industry, are remarkably high tech for a seemingly low-tech industry. Building plans, layouts, and materials must be documented and stored. Daily operations, schedules, and dependencies must be tracked. The hundreds, if not thousands, of workers need to be coordinated and efficiently used. If anything, construction and architecture have just as much need for up-to-date information logistics as do traffic controllers and financial traders.

Architecture, Engineering, and Construction XML (aecXML)

Planning, engineering, and constructing buildings is a very labor- and paper-intensive process. The amount of paperwork needed to build anything, from a simple single-family residence to the most complicated of structures, is tremendous. Architecture, engineering, and construction (AEC) data sets are usually quite large and typically involve many types of unstructured, interrelated data that is created and used by many types of users and software applications. At any time in a project cycle, users such as the owner or operator of the subject facility, architects, designers, engineers, project managers, contractors, estimators, consultants, suppliers, product manufacturers, and government regulatory agencies may utilize the information for different reasons. Many of these participants are small to medium-sized companies and are only involved in small roles in the project for short periods of time, commonly working on multiple projects simultaneously. It is no surprise, then, that so many different systems of varying qualities are being used within the industry. It’s important to solve this problem, because the industry generates hun-dreds of thousands of transactions worldwide and has annual expenditures in the trillions of dollars.

However, in every aspect of the building creation and operation process, the Internet and XML are making significant inroads. This means that proposals, design, estimating, scheduling, construction, ordering, and purchasing are being automated and simplified by way of XML-based standards, such as those enabled by International Alliance for Interoperability’s (IAI) aecXML. The IAI-adopted aecXML provides a means for com-municating information between participants involved in designing, constructing, and operating buildings, plants, infrastructures, and facilities. Applications, organizations, and individuals using the aecXML schema can coordinate and synchronize related project information among suppliers and purchasers of equipment, materials, supplies, parts, and services based on that technical information.

The initiative began in August 1999 as an independent effort by Bentley Systems and was soon moved to the administrative domain of the industry consortium International Alliance for Interoperability. As of October 2001, there are seven working groups, and over 600 interested participants are involved in the development of aecXML. The main principle behind the creation of the format is that project information can be entered once and reused where necessary, across organizational, geographical, and technological boundaries. In today’s project-management processes, information is commonly reen-tered many times by many people, due to differences in the way that data is stored and represented, especially as projects pass from phase to phase and as new participants become involved in the project. As paper-based reports, specifications, and product cata-logs are replaced by their electronic equivalents, searches for product information, speci-fications, and pricing and availability will be conducted, taking advantage of the Internet. This means that regulatory rules, requirements and guidelines, project submissions, and the review and approval processes will be automated similar to how other processes have been enabled using XML.

aecXML is an XML-based vocabulary used to represent and communicate information across the AEC industries. This information covers resources such as projects, docu-ments, materials, parts, organizations, professionals, and activities such as proposals, design, estimating, scheduling, and construction. Some examples of this information include the following:

   Documents such as Request for Proposal (RFP), Request for Quotation (RFQ), Request for Information (RFI), drawings, specifications, addenda, bulletins, change orders, contracts, building codes, and purchase orders

   Building components such as catalog items, custom manufactured items, assem-blies, and materials

   Projects such as design, construction, decommissioning, operations and mainte-nance, and facilities management

   Professional services and resources such as engineers, architects, contractors, sup-pliers, and specialties

   Organizations such as standards bodies and government agencies

   Software such as computer-aided design (CAD), estimating, project management, scheduling, and document management

However, aecXML is not intended to be a native file format because many of the applications used to support these needs have their own valuable file formats. Rather, aecXML will simply be a file-exchange mechanism using XML as its strength.

The aecXML group envisions a utility within a software program that provides the option “Save as aecXML.” This utility would export necessary information in the aecXML schema.

One of the key aspects of the format is the aecXML Framework, which includes a set of XML schemas to describe information specific to the information exchanges between par-ticipants involved in designing, constructing, and operating buildings, plants, infrastruc-tures, and facilities. The aecXML Framework provides the AEC industry with common business interfaces and defines both the data to be exchanged among AEC participants and the processes ruling the exchange of that data. The Framework is composed of several components, including Common Object Schemas (COS), Domain Specific Schemas (DSS), Business Process Schemas (BPS), and the Implementation Framework (IF).

The COS serves as a component library that’s composed of many reusable schema objects that are common to multiple AEC business domains. These objects, such as global elements, global attributes, complex types, and simple types are reused in different places of AEC business information exchange. There are two types of common objects:

non-AEC-specific and AEC-specific objects. AEC-specific objects are objects that have content specific to the AEC industry, whereas non-AEC-specific objects are objects can apply to any industry. Examples of AEC-specific objects are Project, Contractor, and BuildingComponent, whereas examples of non-AEC-specific objects are Name, Email, Address, and Person. The aecXML format defines some of these non-AEC-specific objects but plans to leverage objects from other formats, such as xCBL, as they become available. AEC-specific objects are derived from many sources, including IAI’s Industry Foundation Classes (IFC), which are object models that allow for the exchange of dynamic information among platforms and applications serving the AEC community.

The aecXML Domain Specific Schemas (DSS) are sets of schemas built on the aecXML COS to describe static AEC information, whereas dynamic information such as business processes are defined in the BPS. These can be either an individual piece of business information or a natural grouping of AEC business components. Examples of DSS include objects such as ChangeOrder, which can be used to define the document flow of change order information within the BPS as RequestForChangeOrder,

ApprovedChangeOrder, and CompletedChangeOrder. The DSS are operated through domains such as Project Management, Design, Schedule, and Plant. Each of these domains owns one or more schema namespaces that contain multiple schemas.

As stated in the aecXML specification, “the COS define the letters of the alphabet, the DSS define nouns, and the BPS define verbs.” The BPS encapsulate the exchange of business data between AEC participants during the project life cycle. The aecXML BPS are sets of schemas that describe AEC industry-specific business processes, including the query of information, the business transaction, and the communication messages. The BPS describe detailed interactions and their respective activities between AEC partici-pants, identify which data needs to be present to ensure requirements of both parties are being met, and choreograph AEC business documents with process interfaces. Examples of BPS include Send an Invoice, Submit a Purchase Order, Request for Information, and Request for Change Order.

The Implementation Framework provides a messaging framework for the exchange of aecXML messages. The IF supports the use of multiple different messaging framework standards such as ebXML, RosettaNet, and BizTalk. As a specification, aecXML is trans-port neutral and is not developing its own IF, rather relying on the preceding methods for transporting aecXML documents.

The aecXML initiative comprises constituents from industry, government, and research communities as well as end users. Since its inception, more than 600 organizations have expressed interest in this initiative on six continents. These organizations include architects, engineers, contractors, owner/operators, estimators, consultants, materials suppliers, and building product manufacturers.