Author: Deelip Menezes
The following article is authored by PLM industry analyst and CAD expert Deelip Menezes. His complete bio can be found here.
For some time now, Computer-Aided Design (CAD) systems have been storing project data in individual files. But recent developments in product lifecycle management platforms, such as Dassault Systemes CATIA V6, have changed the game for storing your CAD data. Dassault Systemes CATIA V6 stores all project data in database, and no longer uses a native file format for their MCAD system storage. So, to be clear we’re not talking about dumping data into a single field as a BLOB (binary large object); we’re talking about a true database implementation for improved management, performance, and scalability. This means that CATIA V6 stores geometric and product data in individual records within database, and that’s a good thing.
All this takes me back to 1997 when I was working as a computer programmer for a company specializing in commuter bus bodies, where we had tried something very similar. Basically, as a result of multiple iterations of a design process we found we had eventually built an extensive design system, using AutoCAD Release 12 and FoxPro 2.6 for DOS, that could automatically create the geometry for practically all of our bus parts and assembly units. The process began with a Designer entering numerical data into a FoxPro form (Think: basic parameters of the bus such as wheelbase, number and types of seats, etc…), so the data was stored in a grouping of FoxPro DBF files. Then, the Designer using AutoCAD would run a set of AutoLISP programs created by our Developers. These programs would query the data in the DBF files and eventually produce actual drawings (DWG files) of the parts and system assemblies to be fabricated—resulting in output of the basic business logic that we had intended. From the Designer’s perspective, the creation of DWG files was of nearly transparent because they could be created at any time using a combination of data in the DBF files and our in-house AutoLISP programs. These programs eventually evolved to a point where we were able to place geometric data back into the database. And, over time the Designers could revise of drawings in FoxPro and never touch AutoCAD. This framework also allowed them to extensively reuse data. They could take pieces of data from various projects and mix them together to come up with a new project thereby saving time. Many times the design of an entire bus was done entirely in FoxPro. AutoCAD was used like a printer to simply churn out DWG files.
But here is the best part: anyone who was not working in the design department, and had absolutely no CAD experience, could query and even edit the geometric and product data stored in the database. This would ultimately result in actual changes in the geometry of the parts and assemblies. These “non-Designers” were absolutely amazed at the way they could affect the design of the various parts and assemblies of a bus with little-to-no knowledge of AutoCAD. As you can imagine, we had to put in place various checks and balances in place so that they didn’t mess things up, but overall our results were positive. I suppose my point is this: the actual geometric data could be entered and modified independently simply because it was stored in a database. Had we stayed with the system of single DWG files as system of data entry, data independence would not have been possible. Using a database was the key.
This was more than a decade ago using software and technologies that are long gone, and nearly forgotten. Imagine what we could have done using the power packed and highly scalable database technologies of today. Held to the latest standards, our system seems crude, and furthermore limited our collaboration to within the company Intranet. So, let’s take it a step further, and imagine what could be done with cloud based databases like Microsoft SQL Azure. Imagine the CAD and product-specific data of a company’s products stored in a database in the Cloud and managed by a Cloud-based PLM system. Imagine this data accessible all over the world instantly by anyone with the appropriate access. This is true collaboration—data utilization generating real results.
When you think about it, this completely overhauls the concept of search geometry. There is no longer a need to load each individual CAD file into memory, parse, and then look for parameters and features that match the search criteria. And, consider the impact to computationally expensive feature recognition. All the geometric data to be searched is already available and indexed in the database. For example, if I wanted to find every part within in my company that has four or more holes of a specific diameter (…let’s say 15mm), I wouldn’t have to open the thousands of part files and run a query on each and every one of them. No, I would simply run a SQL query and receive instantaneous results.
There’s one other thing, and this comes as no surprise, but the simple management of CAD data is better when it resides in a database. Just like you can lock certain records in a database, or set up rules determining which records can be changed and by whom, you can also lock parts of your model. Instead of checking files in and out, you can check the features of a model in and out. In other words, revisions need not be tied to an single file. You can have revisions for different features of your model. This level of granularity opens up possibilities that simply do not exist today.
This also opens up CAD data to non-CAD users. Like I mentioned in my FoxPro example above, geometry could be edited without ever touching the CAD system that created it. Now, this kind of automation can be done quite simply and the permutations are limitless. Back in 1997, records in a FoxPro DBF file determined what the geometry in a DWG file would look like. I remember writing a nesting program to optimally cut the floor plates that were to be riveted to the floor structure of the bus. The program would place and orient the plates on blank sheets so that the scrap was minimized. I wrote that program in FoxPro, not AutoLISP, because after the floor plates were cut the remnant sheets were to be recorded back into the database for future use. The user of that program was actually creating geometry without even knowing it. The records that he was adding to the DBF files represented rectangles and polylines and he had never seen AutoCAD in his life. Oftentimes, the user was a data entry operator sitting on a computer far away from the design department. Quite frankly, I don’t think he or she knew what they was doing—no offense intended—and it really didn’t matter because my program prevented them from doing something stupid.
Okay, so CAD data stored in a database is fundamental step in the right direction, but what if the database was located on the cloud? Earlier I had mentioned SQL Azure and how it could be used to drive a cloud based PLM system. Let’s take a deep look. Microsoft SQL Azure Database is a cloud-based database built on SQL Server technologies. It is offered as a Platform as a Service (PaaS ). This means that it does not require any physical administration: the software is installed, updated, and managed by Microsoft. However, if you want to manage the database yourself, Microsoft has something that it has codenamed “Project Houston” which is basically a lightweight and simple database management tool for SQL Azure databases.
One of the benefits of cloud computing is that it gives the sense of infinite computing resources because of its ability to provision the resources when needed and to scale. The same holds true for SQL Azure, databases can be scaled up or down according to your demand. Back in 1997, we continuously found ourselves battling the limitations of FoxPro and DOS, and this was frustrating and eventually hindered our ability to innovate at the rate we needed. But recent database implementations, like Microsoft SQL Azure, are far more scalable and flexible, and this bodes well for the future of innovation. Imagine all geometric and product data of an Airbus A380 stored in a database like SQL Azure on the Cloud. This reminds me, the A380 was significantly delayed due to problems linked to the 330 miles of electrical wiring in each aircraft (for those counting, that turns out to be about 100,000 wires and 40,300 connectors). In the end, the German and Spanish Airbus facilities continued to use the older CATIA V4, while the British and French sites had moved to CATIA V5. In actuality, the mix of CATIA versions resulted in poor data exchange between regional sites.
Fast-forward to today and imagine if there were no regional data exchange limitations and all data was stored in a database in the Cloud. The result? Everyone working on the same data located in the same source. Of course, there would be the usual revision control, but my point it there would be no need for data migration and all the potential million (perhaps billion) dollar mistakes that could come with it. The Airbus situation led to large scale cancellations of orders and a 26% drop in the share price of Airbus’ parent EADS. That led to the departure of the CEO’s of EADS and Airbus as well as the A380 program manager. Of course there were other factors that contributed to these happenings. But Airbus did point to the problem data exchange between CATIA V4 and V5 as one of the reasons for their delays.
It’s clear that data stored in a file has limitations. We are at a time where most agree that “If it’s data, then it belongs in a database”. And soon it will be said that “if data resides on the cloud, then it should in a database in the Cloud.”