Imagine if you could simply open up an architectural design, do your analysis and then print out the resulting engineering drawings using one file. Just click File->Open, add your input and then File->Print. Think how much time could be saved compared to all the different programs and inputs that you have to do today. Working with others would be so much easier and you could test far more options for the best solution.
Unfortunately this isn’t the current reality, although is there any reason that the software can’t do this? In this post I look at some current approaches to sharing engineering information and how useful they are. Examples include the IFC file format, Rhino.Inside.Revit and Speckle.
Why So Hard?
The basic problem is that each piece of software uses a different format than every other piece of software. It’s an interoperability problem and unfortunately it’s been around ever since software was developed for Engineers and Architects.
So why don’t we use a standard format for all engineering information? For one thing, there isn’t much incentive because there is no money to be made. In fact there is an opposite intensive from a software companies perspective. If they allow anyone to transfer their information then anyone can switch to using other programs. It’s far better if Engineers and Architects have to pay every year to keep working in a format that is only compatible with their software.
Another reason is that it is hard to do. It should be pointed out that there have been many attempts at creating an open standard over the years. For much of that time, the solution was seen as a file type but today there are also new techniques available.
Standard File Types
For many, the answer to sharing Engineering information means a file type that can be opened by many programs.
The most basic use of this technique is the DWG format. It can carry primitive geometry (such as beam centre lines) but can’t really carry other engineering information (like member sizes or loads). It gets used if there is no better alternative and it still takes a lot of time getting the other information into each program.
The file type approach has a long history however. An early attempt at a universal format is IGES which has been around since 1976. It was developed by the US air force as a vendor-neutral file format to allow the digital exchange of information among computer-aided design (CAD) systems. This file type was originally based on punch cards and due to a number of disadvantages it was eventually mostly replaced with the development of the more modern STEP format.
STEP took a more advanced text based description approach and is defined by the ISO 10303 standard. While this proved more useful than IGES, it is still rather complex, can’t support textures or other information and isn’t an open free standard.
The most current attempt at a universal file type using ideas from STEP is IFC (or Industry Foundation Classes) which is probably the most popular and useful file format for Engineering information today. Unlike other formats it is open for use by anyone and supports many different types of engineering objects. A majority of software programs also support it in some way, although some are better at this than others.
Despite these many advantages, the IFC format can be a bit controversial. If you read other peoples opinions, it seems to be something that is either loved or hated. It does have a reputation for losing parts of models in the transfer process and is considered to be quite complex. An excellent article on the pros and cons of IFC is here.
It should be remembered that all of these standard file types, including IFC, act more as a transfer file rather than a working file. The imported items are typically static second class citizens to ones created in the programs native format. It’s not normally possible to open an IFC file and edit the members directly in Revit for example.
So are there any other options other than files available?
Streaming Data
A file isn’t the only way to transfer information these days as data can be streamed locally on your computer or to the internet.
This is the approach used by project such as Speckle. The data from one program is streamed to a database on the internet and then can be written to another program from that stream. For this to work, both programs require a plugin allowing the transfer.
This seems like a promising approach if all of the various programs and plugins are maintained and work well. Many of these solutions are currently a work in progress but may be a good option for some workflows.
Programs Within Programs
Another new way being used to transfer information is by writing it to a program directly by accessing an API (or Application Program Interface). Not all programs have this feature but the larger ones such as Revit and Rhino do.
This technique allows software such as Rhino.Inside.Revit for example to directly control elements inside a host program (in this case Revit) so that no file or transfer stream is even required. Whenever you draw an item in one program, it will appear directly in the other program.
There is currently a lot of excitement about Rhino.Inside.Revit in particular. However it shouldn’t be forgotten that this solution only helps with those two specific programs. It is not currently any use for any of the many other programs an engineer or Architect might need.
The Practical Approach
Currently there doesn’t seem to be a unified way to store or manipulate engineering information that works across the industry. Because of the lack of incentives, a universal solution to this problem may be far in the future or even never developed at all.
It seems that the best way to deal with the situation therefore, is to take a practical approach. We can use the technologies and techniques available (discussed above) where we can but can only go so far as the current software allows us.
One thing we do without software companies or other developers inventing a solution is to use existing native formats where possible. There are online conversion services (such as one that Structured Parametrics provides) which will convert most structural engineering data to these formats. This offers a quick way to get working on a project without all the complexity discussed here.
Summary
It’s up to the designer to decide which techniques will provide the fastest, most reliable and easiest workflow for their project.
The tables below summarise engineering information transfer options.
References
Wikipedia
Structured Parametrics 