The Evolution of CAD
Chapter One:
The Evolution of CAD
Written By Martyn Day
In an article of near Biblical proportions, Martyn Day looks at future technology issues of CAD as we enter a new object oriented era. Certain software companies like Autodesk and Bentley will introduce solutions later this year, which will allow their respective architectural customers to build detailed 'intelligent' models. At face value this object-based technology promises users vast increases in productivity by moving away from 'dumb' lines, circles and arcs. What will be the impact of generating more complex models to drawing interoperability?
"In the beginning CAD created the heaven and the Earth and the Earth was without format and void; and there was nothing but darkness. And the software of CAD moved upon the faces and surfaces and CAD said let there be lines; and there were lines. And CAD saw the lines, that they were good."
Well, perhaps not, the Genesis of draughting harks back a long time before electricity. Before the arrival of all this wonderful technology, the human race had been drawing on inanimate objects for a long time. First we drew lines in the sand, then scratched on rocks, daubed on dried animal skins, clay, slate, paper and metal. Then recently, that's in the scale of things and perhaps rather ironically, we went back to the sand and devised a way to use silicon to replace the wasteful paper.
If you are to believe the marketing of the various software companies, we are currently on the cusp of the next revolution in the way we use computers to model the real world. Say goodbye to those ancient lines circles and arcs, and say hello to 'drawing' with 'walls', 'doors' and 'windows'. But before I charge on ahead through the trials and tribulations of the new technology, it's worth spending a little time going over the relevant CAD basics. This could be a good time to grab a coffee!
Moving to CAD Being limited to two dimensions, our best efforts of communicating our design intent has only been possible through schematic representation. Lines, circles and arcs marked physical boundaries of walls, columns and doors, providing an easy means of communication for all disciplines. Over many centuries, standards were agreed and a common 'language' of industry-specific symbols, which the initiated could interpret was established. We took 2D to its limit introducing axonometric and Isometric representation, projecting 3D views in a 2D plane and when the computer came along it was pretty much as a direct drawing board replacement.
CAD offered big benefits over paper. Once over the learning curve, your drawings could be re-used/edited, copied, printed, scaled, passed between computers and so on. The productivity benefit of not having to redraw through each amendment and the ability to insert 'ready drawn' industry symbols provided a compelling business advantage.
As software functionality mushroomed and computing power increased, it became possible to dispense with these parochial 'flat' conceptions and generate complete 3D models, though in the architectural market using lines, circles and arcs with the addition of 'faces'.
In computing terms, CAD software can be very basically described as a database. Using a graphical interface, the user 'draws' creating a list of vectors (lines, circles, arcs etc.), which are stored in a file. As CAD software progressed it was possible to group and organise these 'dumb' entities in many different ways - e.g. Blocks for quick insertion of repetitive groups of lines. When simple lines were not good enough, developers added the ability to extend the data related to these entities. This was usually called 'Extended Entity Data' (EED) and provided a chance to store more pertinent information in the database. For instance, a particular group of lines could be 'Blocked' and called 'a chair', a cost for the 'chair' could be placed as EED for later use. As with all database applications, it was possible to query and filter these lists, one application being the generation of Bills of Materials (BOMs) where you could, for instance, count the instances of the block 'chair', extract the cost from the EED and come up with a total.
Applications To further enhance customer's productivity, and of course to increase sales revenue, the CAD vendors added proprietary Application Programming Interfaces (APIs) to their products. Using these tools, developers could automate many of the repetitive draughting tasks and create solutions specific to particular vertical markets. These vertical markets are traditionally broken down into Architecture/Engineering/Construction (AEC), Mechanical CAD, Electrical CAD, GIS/Mapping and Facilities Management (FM). Combining vertical industry standards (e.g. the architectural layering standard BS1192), the CAD package's built-in geometry creation commands, EED and a lot of software know-how, it was possible turn a standard CAD solution into an expert system. The end results are still given in the universal language of lines, circles and arcs with the add-on application providing a limited amount of intelligence.
Towers of Babel One of the great things about CAD systems is that you can pass data from computer to computer. If the two computers are running software from the same vendor (say AutoCAD to AutoCAD) then compatibility is usually ensured, as both are really identical copies of the original code. The drawing file only contains a list of the entity information (e.g. line, start point/end point, layer, colour, linestyle and so on). Opening this file in any identical CAD application (like someone else's copy of AutoCAD) will reconstitute the file using its built-in commands. As the application contains the same geometry creation commands as your copy of AutoCAD, only the raw geometry data needs to be stored. This is an important element of what we have come to expect from a CAD solution, as will be revealed later.
Transferring drawings from one CAD system to competitive vendor's systems is another matter! There are two critical issues that cause problems. All CAD vendors have their own 'native' file formats; Autodesk has DWG, Bentley has DGN. These file formats are not 'open', in that they are not published to enable other vendors access. The proprietary nature of CAD files has caused many problems when sharing data and over time independent standards have been developed (STEP, IGES), though the process still is no where near 100%, often giving a lowest common denominator result.
DXF Due to its market dominance, Autodesk's DXF file has also won industry favour, though the format is written longhand, so the DXF file size can become unwieldy. In one project in Germany I've seen an individual DXF file span over 37 disks! DXF wasn't created as an industry standard. Autodesk had versions of AutoCAD which ran on incompatible operating systems, like the now ancient and extinct CP/M and UNIX, which stored data in totally disparate file formats. So Autodesk required a solution to get data from one AutoCAD to another when the versions were described as 'binary incompatible'. DXF is a text dump of what's inside the DWG file so it's not all that difficult to understand for other CAD vendors. However, it's not a true 'open' standard as Autodesk is in sole control and initiates changes with nearly every incremental release of AutoCAD. DXF also falls foul of the next issue...
Intrinsic problems The other problem facing drawing translation is that CAD engines are all built differently. Bentley's MicroStation only supports 64 layers, while AutoCAD supports unlimited layers - what happens to all the layers past 64? Whatever you do with that file it will not be correct because of these fundamental differences.
Over the last 10 years, many small software companies have set up to reverse engineer the most popular drawing formats to allow various subscribing CAD vendors to provide a degree of compatibility with competitor's CAD systems. The results of this are invariably less than perfect, mainly due to the reverse engineering of the file format in question and the multitude of software methodologies of what exactly constitutes a 'CAD engine'.
Data interoperability is a major problem facing the CAD industry today. Companies that employ a number of 'best-in-class' solutions will always end up with a hotchpotch of vendor software. By passing data around these systems, the various translation stages required acts like a 'filter', losing data accuracy and possibly introducing data errors. There are financial implications for this process and the more systems you have in-house, the greater the probability of errors.
Most CAD vendors would dearly love to provide all your software design tools and it would appear that the data translation problem that is rife in the industry 'bats for the side' of the CAD vendors. Interoperability isn't good enough and it is not unknown for firms to have to buy another CAD solution just to work on a specific client's project. Unfortunately there appears to be a general reticence within the leading vendors to develop a truly 'open' file system.
Exodus to objects Parting the waves at a dealer near you soon! There has been much said and written about 'Objects' in the CAD industry over the last five years and to date there has been little to show for it. So it's about time they delivered!
The term has been borrowed form the software industry, which has seen the adoption of object-oriented (OO) programming methodology and languages (like C++). Without getting into too much detail, the idea being here that programs are broken down into objects, which are collections of data and processes that interact with other objects. There are many definitions of what an object is but in essence they contain behaviour and identity.
Within the world of 'objects' there is another term, 'class definitions'. A class is a lowest common denominator definition. It would be equivalent to any grouping term, like 'vehicles'. Within each class there are parameters, for our example, for the class of vehicles, the parameters would include make, model, colour and so on. and the processes would be start, change gear and stop. So, 'vehicle' acts as a common description of this variable structure. A red Volvo is an object of the class 'vehicles'.
Now applying this to CAD, the idea is to move away from using the CAD software as an electronic draughting board and instead create intelligent real-world objects. So you no longer are limited to lines, circles and arcs but you can 'draw' with doors, walls and windows etc. Here doors, windows and walls are all object classes, each containing a number of variables and processes. For instance, when you invoke the 'wall' command in an object modeller you are calling up the class definition 'wall'. As you go through the process of entering in your parameters - single or double-insulation, height, width, length, you create an object in the CAD package's database. When another object, like a window, is introduced to the model, the built-in behavior (process) allows the wall and the window (objects) to interact in an architecturally meaningful way.
Each real-world object (or class) is controlled by a small sub-program, called a parent application, which holds this behavioral intelligence to each instance (occurrence) of that object (door, wall, window etc.) in the drawing. This is a major advance from the use of a drawing to merely represent, to the ability to model and analyse with intelligent feedback.
The graphical interface still relies on vectors as its primary representation, so no big change there. However, the benefits can be seen when performing editing and insertion commands, as these objects will, if programmed to, interoperate with each other. Inserting a window into a wall is point and click, with all the finishing details being handled by the respective parent applications, to your specification. If you want to move the window, simply grab it and move it, the wall will repair itself automatically.
The CAD software companies have possibly bitten off more than they can chew here, as there are many thousands of standard 'classes' that need to be defined. Each vendor will implement their own object definitions - that's to say an Autodesk 'wall' will be different to a Bentley interpretation of a wall and so on.
So how will different CAD software exchange this more complex data? With great difficulty is the answer. Now not only do we have a problem of file formats and disparate CAD engines but we now also have to somehow transfer the object intelligence.
One early issue will be overcoming the problem of working with files. CAD systems currently dump geometry data into a file (like DWG) so it can be 'replayed' and recreated in identical versions of that software. This system is reliant on the fact that all the same creation commands (line, circle etc.) are in that other 'identical' system. With object-based systems you need to have the object definition (object wall) at the receiving end.
When it comes to object modelling, the file doesn't contain the definition (object wall), just the properties. So if another user loads up the file without the corresponding object definition (object wall), the intelligence is lost. If we can't manage to keep the intelligence in this process, the industry might as well just stay at dumb 'lines'.
IAI Autodesk saw this problem a few years ago and helped set up an independent body, called the International Alliance for Interoperability (IAI), which has been working to define standard definitions of walls, doors etc. with architects and other CAD companies. The IAI is responsible for setting out a file format called IFC, which stands for Industry Foundation Classes and is based on an old interchange format called Standard for Exchange for Product Model Data (more commonly called STEP) . In many ways it gets around some of the existing data transfer problems.
As we have seen transferring geometry from one vendor's solution to another is a veritable can of worms. IFCs get around these by removing the need to transfer geometry, and instead just announcing the name of the object and a list of industry agreed dimensions. For example, to transfer a wall from AutoCAD to MicroStation the IFC file would say, create object wall at point XYZ, 3 metres high, 10 metres wide and 0.5 metres deep. In each case the CAD software would instigate its own object definition of 'wall' and would take the numerical values to drive its creation. On the face of things this is a big advance over proprietary file formats and geometry dumps.
Unfortunately progress has been slow to create object definition standards for the transfer of these AEC object models. It's commonly quoted that there are 6,000 components in a car and 40,000 in a house. It will take many years to define all the AEC components necessary for a full translation and the industry needs these yesterday! Objects that do not have agreed definitions can not be translated. If the IAI hasn't got a definition for what makes up a truss, how can it translate that object in the IFC? Also as the IFC specification is only a written document, each vendor will have its own interpretation of that standard. So while the promise of IFC translation sounds good in practice, this is currently very limited indeed.
Who are the players? There are a number of software vendors out there who are developing object modelling applications: Autodesk, Bentley, Graphisoft, Nemetchek and PTC. For the purpose of this article I'm going to concentrate on how the most vocal companies, Autodesk and Bentley, are attempting to overcome the technology issues involved.
Autodesk Autodesk was first to the market with the now infamous AutoCAD Release 13 but due to many problems really failed to maximise the benefit of the object-oriented rewrite of the program until the end of its lifecycle. The move to 'objectify' AutoCAD was painful for all concerned but Autodesk did also choose to make a number of other major changes all within one revision, the addition of the ACIS solid modelling engine for one.
The launch of Release 14 brought stability and a more robust developer's toolkit for its ObjectARX development library. ObjectARX is the most powerful development language that Autodesk has developed to date. AutoLISP and ADS (AutoCAD Development System) sat 'on top' of the AutoCAD executable, while ObjectARX is integrated within the program's very core. This makes applications written in ObjectARX fast and more powerful. The first major object-based application to be developed for AutoCAD was Mechanical Desktop (now in its third release) and later this year an architectural flavour, called Architectural Desktop, is due to ship in the UK. According to Autodesk, its army of 'third-party' developers are also hard at work developing ObjectARX applications for R14.
Bentley Bentley, developer of MicroStation, has talked much about its object-based solution over the years. The first industry reports were about a product supposedly called Objective MicroStation but Bentley later described this as being the company's internal project name for its object modelling test engine. Nearing completion, the product will be called MicroStation /J. The J stands for Java, as Bentley has married its own development language (called MDL it's nearest equivalent being Autodesk's ADS) with Sun Microsystem's Java, creating JMDL. Bentley is also making a large number of other changes to its CAD engine, including the move from ACIS solids to Parasolid and single precision to double precision co-ordinate system.
Almost two years ago Bentley announced a range of server products, one of these, called MicroStation Continuum, is designed to act as a central data server, holding, controlling and distributing project information to MicroStation/J seats over a network. The idea here is that the same model can be shared by multiple users simultaneously, providing data and specific object enablers via JMDL.
The next chapter Over the page I will continue looking at this move to building models with objects but concentrate on how Autodesk and Bentley are separately attempting to solve the problem of evolving their user base from traditional schematic CAD to object modelling. The major problem appearing to be the ability of these systems to produce 'data without supervision', where the geometry (e.g. of a wall) and the intelligence (the definition of what walls can do) get separated. These are more commonly called Proxy objects and it appears that they not only affect data transfer between different CAD systems, but even within the same vendor's solution.
Autodesk was first t
