The Evolution of CAD
Chapter Three:
Deploying Model Servers
Written By Martyn Day
Last issue we looked at the proposed benefits of moving from lines circles and arcs to modelling with intelligent 'objects'. Chapter two mainly concentrated on the specific problem that CAD users might come across while attempting to maintain their 'object' model's integrity. Martyn Day investigates how the CAD industry is looking to move to server-based intelligent design systems in an attempt to fulfil the promise of 'object' modelling.
From talking to the main CAD software developers it's clear that they have big plans for their fledgling object modelling systems. The move towards intelligent 'object' models (made from walls, windows and doors instead of dumb lines circles and arcs) really only makes sense if the engineering files of their customers are held in a central database, an engineering project database if you will. As we saw in the last chapter, current workflow practices will not make implementing a move to object modelling easy: drawing files will not only need to have the right base application running (R14, Architectural Desktop, MicroStaion/J etc) but they will also require the correct object creation plug-in to be present. If editing of an intelligent model takes place without the presence of the rules for all components (a wall, door, window etc) then the model will be compromised and can't be relied on to supply correct information. So once you implement an 'intelligent' object-based CAD design system the need to manage drawing data sub-file level (walls, doors, windows) becomes essential.
By deploying something termed a model server (sometimes called a project server), engineering departments should have a way to 'enclose' all this data and the object intelligence and provide a means of delivering both in a highly controlled manner. By taking this 'centralised repository' route, companies will also be able to merge the other essential non-CAD project data (like schedules, costings etc.) that usually gets stored and maintained separately in unsynchronised workflows. The benefits of an approach like this are obvious and an easy idea to sell to large companies. For many years now, CAD files have nearly always been maintained by the drawing office as opposed to a company's centralised IT systems managers, this is because the format of the engineering workflow and file formats are so different and specialised. By deploying a model server implementation, the drawing office will be able to finally pass the task of data management and maintenance to a centralised IT department.
There is no doubt in my mind that this vision of the dispersed model server/ object modeller implementation is the ultimate goal of all the CAD developers, it's just some are taking different routes. This is a problem for early adopters of this technology. While the CAD companies are now trying to sell these object enabled modelling engines, the model server side of things, from what I can deduce an essential piece of the jigsaw, is very much still in the R&D labs of the various software houses. Until these solutions are available it's like buying a car in a country that has no roads! At the moment some of the CAD fraternity is akin to building cars with only a notional concept or blueprint of what a road should be. Much of the following information is therefore conceptual in nature but should give you an insight as to the current trend in model server thinking.
The return of distributed architecture
While Autodesk gets the accolade of being first to market deliver an object-based CAD engine (AutoCAD R13), Bentley was first to 'go public' on the concept of model servers and demonstrate concurrent use of a singular object model by a number of MicroStation seats. In essence, Bentley is currently promoting a 'three-tier' network that it calls its engineering back office strategy. Here the first tier master server holds all the raw project data centrally, stored in both traditional relational databases and the emerging spatial databases - depending on the type of data. This information is then handed on, when required, to the second tier which comprises a number model servers (one for architecture, mechanical, geographical and raster data) which serve the data with any necessary associated intelligence as an 'applet' to a company's workstations running, in our example, MicroStation, for editing. This second tier also maintains the synchronisation and integrity of a particular model while a number of engineers may be working on the same part of a particular model.
Another advantage of this implementation is that these servers could be anywhere in the world and due to the sophisticated model filtering and deliver system, you could work anywhere - so long as it had a phone line. As the data was stored at a remote site, the owner of that information could keep tight control on how, when and if it is edited, potentially putting an end to the drawing revision confusion that I'm sure you have all experienced. Unfortunately I think the early versions of this will not be as 'pure' as the theory would have us believe. To work live on a centrally stored model over the Internet or even a simple LAN would require considerable bandwidth and that is something, which is currently a scarce world-wide resource. This was one of the many reasons Bentley chose to integrate Java into the recently released MicroStation/J. Java is especially designed to deliver 'packaged applications' (e.g. a wall creation program) down a thin client (i.e. low bandwidth) or 'fat' high-speed network.
For now though, bandwidth shortage and network bottlenecks are serious problems that limit just how much of this philosophy can be realised. Within the next decade it's conceivable that there will be enough bandwidth to dispense with powerful local workstations and run an editing session on a simple Network Computer (NC) that only has RAM, graphics and a low power processor. However, for today's technology and its limitations that's pretty much a pipe-dream. For now I'm sure that the portion of the drawing being worked on will still have to be downloaded and stored locally while the editing session is live. This may be done in the background as smart systems will delete the file as the session shuts and the data changes are logged back into the system.
Towards Concurrent Design
By running an engineering drawing in a centralised database the possibility for a concurrent workflow is a chance that no one is going to let pass by. In theory it should be possible to have a whole architectural firm working on a single model, providing viewing, editing and mark-up for all the engineers working on a project. This is one of the long-time 'holy grails' of the CAD industry.
However, today's CAD systems are used as direct replacements of the drawing board. The majority of engineers work on a number of drawings from a project, one drawing at a time. Each drawing is involved in its own workflow and sign off loop. By moving to CAD, the drawer might still work on a number of drawings, one at a time but the benefit was that when a change was made, editing meant that the drawing didn't have to be redrawn from scratch and time was saved. However, in nearly every other respect the workflow mirrors that of the old fashioned paper trail.
The next minor advancement in CAD tools allowed a number of CAD sessions to externally reference the same drawing. It is quite often the case that many drawings will share the same information, so to save it all having to be redrawn, one could reference the file and use it in the background of a drawing session as a drawing aid. The disadvantages being that users could view the referenced file but not alter it and there was also the danger that a key drawing, which just happened to be referenced in many other drawing files, could be altered, causing problems down-line. This is pretty much where traditional CAD finds itself today.
Looking forward, CAD companies are currently developing 'single built model' solutions, where all the drawing time is put into create one singular model which holds all the engineering data on one project. Firms would need to have concurrent (simultaneous) access to a singular file or project database where all this information is stored. If this is done with an object-based solution it will also need to be managed at the wall, door window level, not at the file level. Files will have to be broken down into their base components (walls, doors, windows) and stored/delivered in a way that allows data to be shared freely, preferably without locking users out of editing all the components.
The big hurdle to overcome with concurrent methodologies is what happens when separate engineers on the same data perform a number of edits? Somehow the system has to warn the users involved that there has been a conflict and a resolution is required. Whoever gets this bit right will look very slick in the demos.
Another problem in need of a solution is, if you chose to work on a particular room in a building, you can filter out all the geometry around it to lessen the burden on the PC. The problem here is the wall may extend beyond the boundary you selected, yet the changes you might make could effect the wall and another part of the drawing adversely.
Autodesk's on Model Servers
When first researching and writing this chapter, Autodesk certainly claimed to be working in the same direction as Bentley on the model server front, the main difference being that Autodesk didn't really let on exactly how it plans to face the challenges of developing such a system. Carl Bass, Autodesk's Chief Technical Officer (CTO), was extremely guarded in his replies on this topic but he did confirm certain aspirations. Carl commented, "If you asked me to draw a picture of where we are 5 years from now. I suspect our view is not very different from Bentley's. So you will actually see, when we roll out the next version of AutoCAD, moving to more project based and over time moving to a more centralised server. There is nothing that we've done today that precludes that happening."
Despite making very little of Autodesk's actual model server strategy public, Carl added, "I would actually say from everything I can tell, we are probably further ahead than Bentley in our Model Server effort. We have a different opinion on how best to communicate this to our customers."
However, in a more recent conversation with another Autodesk development manager, I got a slightly different picture where he stated, "We are experimenting with one and I am not convinced that it's a great thing to do right now. We have got 4 people working on a prototype project and we have a prototype working of the Design Server but we are not sure that we want to take it to market."
Autodesk's reluctance to discuss its future plans and the vague answers given when pressed on the issue are really starting to make me wonder just how far ahead Autodesk plans its core development. The issue with ObjectARX and Zombies was realised before R13 shipped and yet, two releases on, the company is still in the process of trying to patch-up the basic limitation of its object implementation. Autodesk isn't sure that Model Servers are the way to go but can only offer a vague indication of its research. My Autodsk contact concluded, "We have to start to design a system that always assumes that there's 10 people, 15 people, 20 people working on the drawings at the same time. Whether we make AutoCAD multi-user aware or we build a little server in the centre..I don't know yet. "
I infer from my conversations with Autodesk personnel that long-term strategy either isn't discussed in public or more worryingly isn't a major consideration for Autodesk past the next Release. When adopting object-based technology I feel it is essential to know just where your vendor is leading you, what problems there may be and what solutions are being planned.
Enter Bentley's vision, ProjectBank.
ProjectBank
The philosophy behind ProjectBank is straightforward, file-based systems are too limiting and there is a great demand out there for concurrent access to project data. ProjectBank solves both these issues by splicing up DGN and DWG files down to their bare constituents (lines, circles, arcs, attributes, hatches etc.) and holding this data as a store in a central location. Then, as users come on line and require access to that data, the ProjectBank serves up identical copies of that data in a file to each user. You could have any number of users accessing the same project and as each one submits the changes to the ProjectBank, the software checks to see if any conflicting edits have been made. If a conflict is identified the user is warned. It's also useful here that ProjectBank stores a complete project history so it's possible to go back and not only see what the changes to the model were but why the change was made in the first place.
ProjectBank is really a database but without the query tools. This database is combined with two important concepts the Schema and the briefcase. Schemas are written by Bentley and provide ProjectBank with the ability to strip-down files into 'components' and rebuild components into existing file formats for use in traditional CAD systems- there are two that will ship next year, the first one to be released will be for DGN, the other for AutoCAD's DWG. Schemas also define the relationship of how components interact with one another, so there's some intelligence there as well. The briefcase is a small program that sits on the hard disk of the MicroStation/J or AutoCAD workstation and acts as the intermediary between the CAD system and ProjectBank. As a user places a request for data, the briefcase calls the relevant components from the ProjectBank and creates a schema (file) locally for the CAD system to edit. The briefcase holds this file locally until the user wants to submit his or her changes to the central ProjectBank. If no changes to the components within that schema have been made then no changes will be made to the master component listing when checked back in.
ProjectBank can handle many schemas simultaneously - DWG or DGN, tracking changes to the project data in both formats. ProjectBank doesn't solve data translations between the two (DGN to DWG etc) as a translation is required which will always mean some loss of data due to the fundamental differences in the solutions. However, according to Bentley, its DGN and DWG schemas have common interfaces, so that component-based programs can recognise the work out common factors between them. This ability to link between ProjectBank components was partially demonstrated at PES Philadelphia last year, even if one was held in a DWG Schema and the other were in a DGN schema. Expect to see delivery of this technology around May/June this year.
Object Revision Issues
Imagine you were sending a model to a college, traditionally one of the main considerations would be to make sure he was running the same version of the CAD application to minimise incompatibilities. Now imagine you're delivering an object-based model to a customer, which contains a variety of walls doors and windows in it. The issue here is that it's not just about matching the version of the base application (AutoCAD/ MicroStation), each object creation routine and component created will be associated to a revision number (Wall Rev1.1 Door Rev2 etc) and will need to be managed as each of these get incremented and updated. As the years advance and software matures a wall object created with revision 1 will need to be read by subsequent versions of that wall applet and the same for every architectural object. Also, what would happen if your chosen HVAC developer went bankrupt and so didn't port to the next release of your CAD system?
Both Carl and Keith admit that object versioning is a difficult thing. In the instance of AutoCAD, Carl Bass admitted that ARX applications written now will not run on future releases of AutoCAD. However, the components (intelligent objects) created with these 'old' applications will always be backward compatible and readable by the latest version of the ARX application, even if it is in AutoCAD R25.
Keith Bentley elaborated a little more on how Bentley Systems was going to tackle this thorny issue, "The issue of "schema evolution" is a very real concern that should be addressed openly up-front, regardless of the project server used. Provisions must be made to "stamp" schemas, and the components created by them, with a version number and conversion routines must be supplied where necessary. Certain kinds of revisions can be handled automatically (adding a new field to a component, for example), but other types of changes are more difficult. Just like in the relational database world, schema migration has to be handled off-line (that is when no changes are being made to the database) and can potentially be a substantial undertaking. However, proper up-front planning and programming techniques can isolate change and smooth the process substantially. Our schema architecture holds the line against uncontrolled change. As a first line of defence, we prevent the entire model from becoming a 'zombie' by keeping the schema with the data. Also, the dynamic way in which JMDL components are loaded prevents the "domino effect" of changes in supporting libraries requiring recompile/relink of dependent modules, and so on."
Data Transfer
Moving to an all-encompassing model server, should mean that those that are allowed access to your database can draw and edit without fear of creating proxies. Unfortunately, this doesn't make it any easier when it comes to passing intelligent models from one CAD vendor's software to another. On this point Keith Bentley put forward the philosophy behind his company's development of ProjectBank.
"As engineering models begin to hold more information than geometric and physical properties, it will become increasingly important for us to jettison our parochial notion of "data transfer" in favour of a more practical approach to "information interchange". That is, sending "data" from one system to another as a list of raw name-type-value triplets isn't all that valuable unless you know how those values are related, constrained, derived, etc. (think of a spreadsheet vs. a table in a word processing document). True "information exchange" should be the goal, which generally means some form of interactive dialog between systems rather than one simply reading a dump from the other.
"When peer systems are each creating and modifying related information, the long transaction checkin/checkout (sometimes called "forward changes") method rather than today's round-trip translation should be employed. The difference can perhaps be better understood using the common "book" analogy. Instead of translating an entire book from German to English, making changes in English, and then translating the entire book back to German, imagine that the book's author was a multilingual speaker and was always available (you authors are such amiable people after all!).
"English speakers could ask for a complete translation, just an overview, or ask specific questions or clarifications about the book. They could then "suggest" changes and/or additions to the author, who would make those changes, provided they were in concert with the rest of the work. Of course if there were multiple people each suggesting changes at the same time, the author would be responsible for co-ordinating those efforts and resolving (most likely with help) conflicts and notifying others when changes are made. In this scenario there is definitely a "master" bookkeeper and everyone "forwards their changes" to him. Of course their must be a "native" language for the bookkeeper (lets call that the project server for now) and conversations will be more natural in that language. However, standards like the IFC's are necessary to converse with "foreign" systems and the more semantic content they convey the more complete the information transfer can be. The key is that the IFC's (for example) define the vocabulary rather than necessarily the format of the conversation."
Conclusion
The more I look at this move to object modelling, the more I see the massive effort required in both short and long term planning for those software companies trying to develop it and the high levels of investment for the potential technology adopters i.e. you and me. The general concept of object modelling is easy to grasp and the benefits look good on paper but as with all things the devil is in the details.
Running a traditional networked drawing office, producing engineering files, managing and distributing them is an art form in itself. From what I can see, moving to a model server/ object modelling strategy really doesn't suit the small non-networked companies that use CAD today. The network infrastructure investment levels required and benefits of concurrent working methodology, really best suits large companies working on enterprise-scale projects. That said, even those companies will have to be very committed and convinced by the productivity benefits, especially when one considers the data management problems that could arise from the mushrooming control and delivery demands of a typical model server configuration. It's not simply a case of making sure everyone's running the same release of AutoCAD or MicroStation, every object 'applet' (creation routines for wall, door, window etc) and component (instance of wall, door, window) will need to be managed. Call me a cynic but I'm sure the CAD vendors will be happy to provide object adopters with the necessary management tools, at a cost of course.
