Director of Software Development Solutions Group
Avatech Solutions Inc.
Owings Mills, Md
Edited by Leslie Gordon
Design-engineering software that can’t communicate well with manufacturing is a recipe for trouble. When the two don’t talk to each other, engineers might find themselves manually retyping and synchronizing BOMs derived from CAD into other data-storage applications. This is a painful process and prone to error. Likewise, change management is difficult at best when information does not flow easily from manufacturing back to engineering.
Developers of manufacturing software typically have not devoted much effort to ensuring all systems work together. But the tide is turning. A software component of Windows called the .NET Framework is helping to boost productivity by reducing software communication problems. Basically, the .NET Framework is a collection of programming “building blocks” that provide unified access to a wide range of capabilities for Microsoft’s programming languages.
Details of .NET
Microsoft intended .NET to make software development simpler by bringing together the various fragmented programming languages and development environments used in the preceding decade. And, in fact, it has had a profound effect on the evolution of IT in all industries by marrying the worlds of Web, server, and desktop-application development. Thus, .NET gives languages such as VB.NET, C#, C++, and J# a great set of tools to work with, such as XML, Web Services, cryptography, and more.
Unfortunately, manufacturing hasn’t adopted .NET (or the industry-standard technologies that it supports) as rapidly or extensively as, for example, the ITdriven financial services industry. That said, .NET is making it easier for CAD software, PDM packages, and manufacturing or enterpriseresource- planning (MRP-ERP) systems to talk to each other. Manufacturers that exploit the technology no longer must manually reenter BOMs or other information from one storage system into another. Vendors such as Autodesk, Dassault, Oracle, and SAP have all built collaboration and datamanagement software based on Web Services, which opens them up to any software developer that learns .NET.
Before discussing .NET further, it is helpful to first examine a few of the underlying technologies mentioned above. Perhaps the most important of these is XML. While HTML has became the standard language for showing content on the World Wide Web, XML has become the accepted way of exchanging structured data between software applications. For example, many different manufacturing packages can import and export XML for exchanging information about everything from BOMs to results of interference-checking software. Thus, information systems for manufacturing are increasingly married by data and process descriptions using XML.
Also important is Web Services. The technology typically lets “server” software (like PDM or ERP systems ) publish an “officially supported” way of communicating between and among disparate programs. This lets other programs send and receive messages using industrystandard protocols (typically XML formatted). For example, a PDM system might offer “services” for interacting with Documents, Part Numb e r s , an d Change Orders. Web Services lets software exchange information over an intranet or the Internet, while the databases involved in the exchange are kept separate and safe. This contrasts with older approaches in which software communicated directly with the underlying database — a method prone to problems and costly to develop. PDM and PLM software such as Autodesk’s Productstream and PTC’s Windchill are built with strong Web Services capabilities. This simplifies the task of writing homegrown or commercial applications to work with them. Other software companies are also writing applications with new capabilities to move information back and forth from CAD to PLM to ERP.
Closely tied to Web Services and XML, Services Oriented Architecture (SOA) is currently a hot topic. SOA uses what’s called an information- architecture approach to taking a bunch of loosely coupled “services” — information residing in separate systems — and orchestrating the information in a larger business process. The full scope of a change order, for example, might involve three or four different systems. An SOA approach lets the process flow across the disparate systems to accomplish the whole process. These loosely coupled systems are generally held to be more flexible and adaptable to change over time.
Many manufacturers have employees whose job it is to develop software — whether from the engineering IT or the business IT side. Those using .NET will find it much easier to take advantage of XML, Web Services, and SOA. Companies are also garnering benefits from PDM systems supported by .NET. Autodesk’s Productstream, for example, uses a combination of client and server-based software components to manage product data. Productstream’s Web services architecture provides a flexible approach to connect with numerous enterprise programs, including work-order management, compliance management, and even a manufacturer’s homegrown software.
Enterprise mash-ups The increased use of Web Services has led to a whole new software category called the Enterprise Mash-up. Companies with information in different formats and different applications are now building new applications by “mashing” together data from disparate sources.
For example, suppose employees need the capacity to easily pull-up all information on a part (i.e., 3D model, drawing, revision history, and field maintenance notes) based on a part number. The problem: When it comes to large assemblies, it’s difficult for the average individual to know which part number to use. As an example of what is possible with .NET, consider software such as Product Browser. Our company worked with several manufacturers to build the application that “mashes up” Autodesk Productstream and Autodesk Design Review.
Product Browser uses Web Services to let users look up the top-level part number and then use a 3D model of the assembly to graphically find other parts in the assembly by clicking on them. This allows manufacturing, field maintenance, and purchasing to eyeball product designs and drawings and understand which revision they are viewing.
The .NET framework also helps automate CAD. For example, we built a custom system based on .NET that automates Stealth Concealment Solutions’ design process. The Charleston, S.C., company manufactures structures for concealing cell towers. The application lets Stealth engineers work from project details gathered in the quotation process to generate a starting assembly in Autodesk Inventor. A series of tools automates the design of concealment structures to fit particular sites. The tools use the company’s knowledge of materials and best engineering practices to help its engineers focus on high-level design choices, rather than on the mechanics of the CAD system. The .NET framework made it easy to connect to the company’s cost-estimating software, as well as to automate the repetitive aspects of their design process in Autodesk Inventor.
Coming soon to manufacturing
Versions 3.0 and 3.5 of .NET were released within the last year and are just starting to get widespread adoption. They have significant changes that will affect manufacturing, one of which is Windows Workflow (WF).
WF lets software developers add a “configurable workflow” to any application. The new workflow engine will theoretically let engineers as well as software developers who understand workflow requirements make changes to an application’s workflow using a graphical, drag-and-drop interface. This has traditionally been difficult in areas such as engineering release or purchasing authorization because work flows are often ‘fixed’ within the software.
Take the case of a simple purchase order in which an employee enters a dollar amount for approval and the request routes to his boss. When the amount exceeds a certain figure, the approval goes to someone with more authority. When that manager is currently unavailable, the process suspends until he returns and grants the approval. Such workflows often start out as simple, but become more complicated over time as requirements such as preferred vendor sourcing are added. Software often has a hard time keeping up with such changes in business processes. However, configurable workflows should help address the issue.
As more manufacturers exploit .NET, it should facilitate the generation of homegrown and commercial software that will let new business processes run among organizational departments and between trading partners along the supply chain. It will also allow automating purchasing for just-in-time delivery to reduce warehousing costs and parts obsolescence.