EDA Homepage - Electronic Design Automation and SEO

AMAR Hospin

Dear Editor:

First and foremost, we would like to thank you for efforts to educate customers on the benefits and challenges of utilizing object technology in design applications. As you noted, object technology can and will have immediate impact on customer productivity as it provides a foundation for more intelligent, discipline-specific applications. Since both form and function are understood by the design application, tedious "re-drawing" steps can be eliminated, relationships between design elements can be maintained, and design intent can be recorded.

However, design productivity is only half the story driving object technology in design software. Design automation applications, such as AutoCAD, are now broadening beyond automating just the concept, development and documentation of the design. As information technology becomes better understood in design companies, customers want to drive entire lifecycles electronically. You have heard this expressed as "art-to-part" in mechanical engineering or "design-build-maintain" in the building design industry. Design-clients want the designs they commission to be useful beyond the narrow documentation/drafting phase of design and be fully utilized for stress analyses, facilities and asset management, and so on. Object technology is perfect for encapsulating the information necessary to widen the usefulness of design for all these diverse needs. We therefore see the use of object technology as being inevitable.

As with any new innovation, the adoption of object technology poses fresh challenges and you are quite correct in recognizing the interoperability challenge. We should place this challenge in context - it is hardly a permanent or insurmountable issue.

Let us remember that many of the things that we take for granted today were seen as huge challenges only a few years ago. For example, in making the shift from paper-based drafting to computer-aided design, designers feared losing their designs due to a computer or media (disk) failure. Today, we do not think twice when relying on computers for safe storage of designs and documents. Less than 12 months ago, security was a real concern on the Internet with regard to credit card transactions today electronic commerce over the world wide web is a booming, multi-billion dollar industry. Likewise, while object technology poses unique interoperability challenges, we are confident that these will be dealt with during successive evolutions of the technology.

Object interoperability is not a CAD-specific issue. Indeed, the "document-centric" paradigm that the industry is evolving two provides many parallels - OLE in Windows being the best known one. When you embed a Microsoft Excel (tm) spreadsheet in a Microsoft Word (tm) document, you encounter exactly the same issue (and behavior) as you would in the CAD space. When the Word document is sent to another user, who does not have Excel, merely the bitmap of the spreadsheet is displayed. If Excel is present, then the spreadsheet behaves intelligently and can provide spreadsheet-specific menus and toolbars. In the world of the Internet, HTML pages may contain tags that require supporting code (known as "plug-ins") to fully display the page. In the absence of the supporting plug-in, nothing is displayed. Even in CAD, in the days before objects, if a drawing file was unable to find a font file associated with a text entity, it substituted a lowest-common-denominator font (in the case of AutoCAD, txt) to display the string.

These experiences are roughly analogous to the R13 behavior of displaying zombies (vector image equivalents) and attempting to automatically load applications associated with custom objects.

Since customer expectations of design applications appear to be higher than those utilizing office applications, we improved the default behavior of custom objects in Release 14 enabling them to participate in more editing operations even in the absence of the supporting application. This is why we changed the name of objects-without-supporting-applications from zombies to "proxy objects". However, work remains to be done to continue to improve interoperability. Autodesk's continuing plans are:

1) Proliferating object enablers

For our customers, we intend to drive the creation of free, widely available object enablers so they will not encounter "mute" designs. Similar to the Internet practice of providing free plug-ins for viewing and interaction (but charging for authoring applications), we envisage a home page on our web site for hosting hundreds of design object enablers. Client applications, such as AutoCAD, will automatically query a specified home page (just as browsers do) when encountering an object with a missing supporting application on the desktop. We are starting this practice with our own object enabler for our object-based application, AutoCAD Architectural Desktop. We intend to make the creation of object enablers (and registering a corresponding URL) a logo requirement for future "Built with ObjectARX" logo compliant applications.

For our developer partners, we intend to make it easier to create object enablers by providing a simpler framework layer at which to enable the object - the database. In the R13 and R14 days, object enablers had to be developed at the ObjectARX interface level - making it hard to separate out the enabling and creation parts of the application. Since the next release of AutoCAD successfully encapsulates the AutoCAD database in a separate component (ObjectDBX), object-based applications will be able to easily partition their logic into enabling and creation/interaction parts. We see this as the next critical step to proliferating a class of .dbx "viewlets" that are the free, widely available and downloadable object enablers referred to above. Such .dbx enablers will be designed to work across the spectrum of Autodesk products, from View to LT to AutoCAD to Mechanical Desktop, and so on.

2) Improving the transportability of designs

Designs are can no longer be considered fully contained in a single file such as .DWG. Indeed, as industry practice evolves towards information modeling, designs will be more linked than ever - needing resources such as reference files, fonts, and hatch patterns, or URLs for Web information, or database links to enterprise information, and now supporting object enablers. When a design is shared with a colleague in the future, we will be making efforts to "package up" these resources along with the core design file itself. You see some of this in the form of the pack-and-go application today, in the future you will see us working more along the project/source/resource metaphor of the Visual C++ and VBA programming environments. Or even distributed network applications using portable, transparent middle-ware frameworks to access distributed design-project databases.

3) Improving inter-application interoperability

Steps one and two mainly relate to interoperability within the Autodesk product domain. Interoperability between two design applications such as Microstation and AutoCAD is never going to be easy with or without objects. In the past, standards such as IGES and STEP have attempted to develop a protocol for defining geometry and product information. IFC now strives to do this at the object level. We continue to support this effort because IFC is more than an effort to bridge two design applications - it is an effort to integrate all applications that need to participate in the art-to-part/design-build-maintain cycle, which is what object technology is ultimately attempting to solve.

The main reason interoperability between two CAD applications remains imperfect has less to do with the issue of "file formats" or "standards" and more to do with the fact that any two applications may implement the same idea - differently. For example, one application may implement lineweights on a per-object basis, the other on a per-layer basis and even if formats and protocols are well understood, the mapping between the two will never be perfect. To achieve perfect interoperability, you almost have to guarantee that all design applications utilize the same source logic.

On a final note, we almost always discuss (and are distressed by) interoperability in a desktop-centric world. When company walls and distance separate customers and computers, solving interoperability issues is particularly challenging. Now, imagine a world where all these customers and computers are connected to one another, and have the ability to "fetch" the appropriate information on a just-in-time basis, and interoperability becomes more solvable. Technologists today are already excited by the advent of distributed environments such as Jini/Millennium/Inferno where intelligent devices broadcast services and needs over a global, inter-connected network. Eventually, Palm Pilots we own can print to a printer that it never met before. Now, imagine this in the context of design - intelligent objects (and applications) broadcasting their needs and services over an inter-connected network and you can see why we are confident that object interoperability while being a real issue today, is an eminently solvable one in the near future.

Very truly yours,

Amar Hanspal

Director, AutoCAD Product Management

Links

Downloads

AMAR Hospin

Media Partners