Matt Mason
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.
Underlying technologies
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.