StressFree | David Harrison

Open source development & digital architectural collaboration

BIMserver and the potential of server-side BIM

Submitted by David on 26 February 2009 - 10:20am
Printer-friendly version

We are now at a stage where a computer's speed and network connection are no longer significant process bottlenecks in digital architectural design. As a consequence the need for efficient digital collaboration tools within the architecture, engineering and construction (AEC) industry is a growing requirement. The BIMserver project from TNO and the University of Eindhoven is exploring how collaborative design can be improved through the combination of Building Information Model (BIM) and open source server technologies. Unlike conventional, workstation-based CAD software, BIMserver stores BIM data within a dedicated server where it can be accessed by all members of the design team simultaneously. Whilst conceptually not a new idea, the project is the first to move beyond the research lab and be promoted as software (almost) ready for production deployment within AEC organisations.

What is a BIM server?

BIM in its most general sense is a collection of 2D, 3D and textual data that when assembled within a computer’s memory creates an accurate and detailed representation of an architectural project. Like its predecessor CAD, BIM data is typically stored in a digital file (or files) where it is accessed directly by complex, workstation-based applications such as Revit and Microstation. In contrast a BIM server stores all design data internally and exposes its information to client applications through a series of well controlled and documented interfaces. This has a number of practical and technical advantages, the most significant being all client applications read from, and write to, the same digital model. In comparison when using a file-based BIM it is up to each participant to ensure they are working on the latest revision of the project’s files. Additionally by centralising the flow of data a BIM server enables near real-time collaboration as changes to the model are reflected on all clients each time their view of the data is refreshed from the server.

Another important characteristic of a BIM server is that the building model exists as a live entity, distinct from the client applications that interact with it. This means client applications are simpler to write because they do not need to know how to comprehend an entire digital model, they simply need to ask the BIM server for the subset of information that concerns them. For example using a traditional file-based BIM an application that counts the number of doors in a design needs to parse the file, construct an in-memory model, and then count the door instances. In comparison a BIM server handles the parsing of the digital model, all the client application needs to do is construct a query that asks how many doors the design has. Another benefit of a live BIM is that the server can automatically respond to outside events such as scheduled processes or changes to data hosted by external services. For example the BIM server could monitor the pricing and availability of materials used in the design and automatically update the model to reflect these variations. The end result is that instead of being viewed as a static, “dumb” file, the migration of the Building Information Model into a server would create a far more dynamic and accessible project resource.

Why BIM servers are not common place

The use of computers within the AEC industry stemmed from the increased affordability of single-user workstations during the 1980s and 90s. This emphasis on workstations was due to the visually intensive nature of the AEC workspace and the slow networks of the time which could not efficiently communicate such data. In comparison many other industries had already adopted centralised mainframes and mini-computers as core computing platforms well before this desktop revolution. This different pattern of computer adoption has had a significant effect on how AEC software has evolved relative to industries with a history of centralised computing. Rather than relying on a large, server-based infrastructures, tools such as CAD were optimised to run on independent workstations with few, if any ties to external digital services.

This small but significant characteristic has had a profound influence on the evolution of CAD, BIM and how AEC professionals digitally collaborate. As other industries have encouraged consolidation of data around servers and the Web, the AEC industry has instead sought faster workstations to enable the building of more detailed models. Whilst this high-powered, but isolationist strategy has enabled excellent static outcomes, it has come at the expense of a team's ability to efficiently collaborate digitally. This inefficiently stems from the interoperability issues which exist between different applications, and the inherit shortcomings of software designed primarily for use on standalone workstations. For example whilst the majority of CAD and BIM software enable collaborative workspaces, this usually involves partitioning off an area of a model so only a single person can make changes. But as CPU and network performance has begun to exceed demand, researchers and product managers are exploring how collaboration can be improved through the use of centralised BIM servers.

BIM as a Service

The idea of a centralised service that hosts core business data has been a central facet of software architecture since the introduction of mainframes and the client-server paradigm. In the workstation-dominated AEC industry, centralisation is limited to file servers that provide convenient locations for BIMs when it is not being worked on in isolation. However from a collaboration perspective it is far more economical to access and modify a centralised BIM because it is easier to ensure the currency and validity of its data. A centralised model also reduces interoperability concerns as the interactions between client and server are limited simple transactions, for example 'read this' or 'write that'. In contrast a standalone piece of software must correctly comprehend an entire data file, and if modifications are made, write its contents back in exactly the same way. This has proven to be a very demanding problem to solve for relatively simple office documents, but when taken to the level of complexity of a BIM, the task becomes almost impossible.

There have been many AEC research projects that have implemented a client-server architecture for collaborating on CAD or BIM models. Unfortunately for a variety of reasons none have made the transition into mainstream AEC use. Perhaps the most notable of these was the IFC Server from the VTT Technical Research Centre. The project was an Internet-based model server that built upon two significant standards, the Industry Foundation Classes (IFC) building data format and the SOAP web services protocol. Leveraging these existing industry standards made the task of creating software clients simpler because developers could reuse existing knowledge, documentation and tooling. Unfortunately the project never got beyond the research lab, but five years on many of its concepts are alive and well within BIMserver.

BIMserver - Industry meets Research

BIMserver is both an open source model server project and a collection of European organisations committed to developing the concept further. The project lead is Léon van Berlo of TNO, a non-profit organisation established in the Netherlands to encourage innovation within small and medium businesses. Working as a scientific partner is the University of Eindhoven, whilst both the CSIRO and VTT are investigating ways in which to take part. Alongside these research institutions, nine businesses have expressed an interest in making compatible client software and others are simply keen to explore the potential of the server in practice. In an effort to foster broad adoption and encourage developer involvement BIMserver is free and its code released under the GPLv3 open source license. This is relatively unique for the AEC software industry, where closed source licenses and high per-user licensing costs, especially for BIM software, is the norm.

An underlying theme of BIMserver is to establish a platform that can be used in a variety of situations and software developers can build upon. This philosophy extends to the code itself which is written in Java, a robust and popular language amongst businesses and casual programmers. The application itself can then be deployed to any modern Java web application server, or run as a standalone program using the light-weight Jetty library.

“The technology we are using is based on the latest stable technology. We are using the Eclipse Modeling Framework, BerkelyDB, Tomcat, Jetty, Java,  et cetera. This is done to get BIM from IFC (read: Step) into the ‘normal’ world of everyday programming. When that is done every ‘dorm-room programmer’ can work with BIM and IFC (instead of having to learn the Step language first). This could (we hope) be a enormous driver for the adaptation of IFC and BIM.”

Léon van Berlo, TNO

An important factor in these technology decisions is they are all vibrant, open source projects, allowing the BIMserver team to effectively ‘stand on the shoulders of giants’. This makes the tasks of development and support simpler because there exists an extensive knowledge base around the server’s fundamental components. Also from a business standpoint it is reassuring that if BIMserver or one of its dependent projects should cease to exist, the organisation can continue to operate and extend upon the existing open source code.

Deploying and using a BIMserver

The benefit of being written in Java is that BIMserver can be run on any platform that supports Java 6 such as Windows, Mac OSX and Linux.  In a production environment BIMserver should be deployed within a Java web application server, for example Tomcat, JBoss or GlassFish, as these provide optimised and scalable web engines. Once operational client applications interact with the BIMserver through a SOAP web service interface that implements the Building Information Exchange Protocol (BIEP). BIEP is a new protocol from the Open Source BIM Initiative which combines the best of the Sable and oBIX projects. Whilst slightly concerning that BIMserver is implementing a new protocol rather than reusing something that exists already, considering the immature nature of this market it is not uncommon or necessarily wrong.

Client-side BIM applications will access the server’s data natively or through third-party plug-ins which translate responses from the BIMserver into instructions the host application understands. The quantity and quality of the client application support will be the determining factor behind BIMserver’s success in the long-term. AEC professionals are primarily interested in efficiently achieving their allotted work using reliable tools they understand. If adoption of BIMserver requires a significant toolset change, or the use of software that is slow and unreliable, the initiative will ultimately be rejected. Unfortunately for BIMserver proponents this poses a chicken and egg dilemma; third-party support hinges on demand, but server deployments will not occur until applications support it. Given this situation perhaps the best long-term yardstick of BIMserver’s success is whether or not it can garner support from one of the major BIM vendors. If this commitment can be achieved then it will almost certainly mark a tipping point in both adoption and third-party client support.

Beyond the SOAP interface’s computer to computer communication there is a limited web interface for the manual management of the BIM models stored on the server. As the project matures this side of BIMserver will be developed, plus extra functionality can be added through the installation of licensed plug-ins. Compared to a file-based BIM the benefit of a web interface is that it enables ubiquitous access to the underlying project data. Whilst in its infancy, over time many tasks related to the consumption of BIM data will no doubt be possible via the Web, for example checking that onsite construction drawings are the latest version. From a collaboration standpoint this is very significant because currently access to file-based BIM data is restricted to those with access to the file itself and the desktop application needed to read it.

Alongside the complex SOAP interface is a limited collection of REST web services. Unlike its often unwieldy and over engineered cousin SOAP, REST web services are easier to understand and use within applications on the desktop or web. REST is a new web service standard, but it has been implemented using proven HTTP concepts and existing technologies. Due to this simplicity and ubiquity REST is fast becoming the dominant standard for web service-based information exchange on the Web. With this in mind it is important that BIMserver has strong support for REST, not only because it is easier for developers to use, but it is also a more appropriate choice for the data communicated by a BIM server.

The Technical Challenges Ahead

The initial release of BIMserver is promising from a conceptual and technological standpoint, but it has a long way to go before mainstream deployment within AEC organisations can be considered. Of highest priority is the growth of the BIMserver documentation and developer community so that third-party software vendors can seriously consider adapting their software to work with it. Beyond growing the ecosystem the server at its core also needs to go through several iterations to expand its feature-set and establish itself as a robust and scalable platform.

“I'm saying it's okay to ship crap - I'm not saying that it's okay to stay crappy. A company must improve version 1.0 and create version 1.1, 1.2, ... 2.0. This is a difficult lesson to learn because it's so hard to ship an innovation; therefore, the last thing employees want to deal with is complaints about their perfect baby. Innovation is not an event. It's a process.”

Guy Kawasaki
How to Change the World: The Art of Innovation

There are three technical areas the BIMserver team need to focus on during these forthcoming iterations; design versioning, scalability and robustness.

Design Versioning

Version control management is an important topic for architectural collaboration or any line of work which relies on comprehending changes to generated content over time. Strangely whilst the AEC industry has checks and balances to monitor design revisions, these are generally manual processes such as file naming standards and revision spreadsheets. In contrast within the field of software development the use of version control systems such as Subversion and Git are not just common place, they are a necessity given the complexity of computer program code. If implemented well the inclusion of a sophisticated design versioning system within BIMserver and its client interfaces may help spark a revolution in digital architectural version control. Unfortunately version control and conflict resolution is a complicated subject which may take years of testing to perfect, but the first product to do so will hold a compelling, and lucrative, competitive advantage.

Scalability

When deployed in production a BIM server will be the digital hub for an AEC organisation’s project information. In order to fulfill this role the service must be capable of scaling to simultaneously serve large numbers of client connections and store vast quantities of data. Appreciating that peak demand will always exceed the capacity of a single computer is the most important aspect of scalability. Hence the components of a BIM server (web interface, processing logic and storage) must be loosely coupled so that they can be easily distributed across multiple computers. Architecturally this is a straightforward task, but getting this to work reliably without severely impacting performance is a challenging, and at times complex process. Fortunately BIMserver’s ability to be deployed within a Java web application server is beneficial in this regard because there is a large knowledge base built around scaling such services. This being the case there are still many application design and coding decisions that can act as scalability bottlenecks.

Robustness

If a firm with a large number of employees is to depend on BIMserver the software needs to demonstrate it can perform reliably under a range of situations and over long periods of time. Most importantly each transaction that occurs between a client and server must be guaranteed because in the context of the architectural project the information exchanged is potentially very valuable. If a single transaction were not to be processed correctly, for example the realignment of a wall, this could have significant and potentially costly ramifications if it was not detected and corrected. During the course of BIMserver’s life such errors will undoubtedly occur, so it is important that a support infrastructure is in place to rectify problems and alert other BIMserver users of their existence. To facilitate such robustness many open source projects have two or more branches of code; a stable, professionally supported release, and a development package in which new features are added and tested. Establishing this infrastructure is vitally important for business adoption, but whether those currently driving BIMserver are capable of undertaking all these responsibilities is yet to be seen.

Is the AEC industry ready?

BIMserver, like any innovation, is concept now in search of its actual audience and problem space. In such a situation the use of open source is wise because it allows potential users to test the software in a variety of situations without having to commit significant resources. This exploration process will highlight aspects of the architectural design process that will benefit from BIMserver and scenarios where its application is unsuitable. Whilst it is difficult to say what these will be, there are broader issues around the BIM server concept in practice which need to be overcome before mainstream adoption can take place.

The most challenging of these issues is whether architectural practice can be sold on the idea of a BIM server and whether the cost of its demonstrated benefits can be justified. A paradigm shift to server-side BIM is a difficult proposition given it must overcome decades of momentum and investment in file-centric workflows. It is harder still when most AEC organisations are still grappling with the transition to BIM and how this will actually benefit their practice. BIMserver’s open source strategy mitigates this somewhat because it allows experimentation without commitment, but at some point actual marketing will need to be used to influence opinion. Here again this will probably rely on a major BIM vendor adopting the concept (once proven) and pushing it through their various marketing and distribution channels.

Beyond actually selling the concept is the hurdle of getting AEC organisations to make room for its implementation within their limited I.T. budgets. Unfortunately this is problematic because most architectural professionals consider the majority of their income is from digital content created on their desktops. This workstation-centric culture means managers will not hesitate to spend $5,000 or more workstations or BIM licenses, but to compensate investments in server infrastructure are comparatively small. Getting companies to appreciate that implementation and support of a business critical BIM server is not a low cost exercise will also pose its own set of issues. Much to the ire of hard-pressed I.T. staff, production BIM servers will behave quite unlike file servers, and given their complexity will undoubtedly require more support.

Conclusion

The successful introduction of BIM servers could revolutionize digital collaboration and the use of BIM within the AEC industry. The BIMserver project is a very good step in the right direction, but it faces a daunting mountain to climb if it is to move from a niche research test-bed into a mainstream piece of AEC infrastructure. The first step in this process is identifying what industry sectors are best suited for BIM server deployment and the benefits it will actually generate. BIMserver is ideally suited for this role because it is open source and can be tested without commitment. Whether the BIMserver ecosystem can achieve critical mass and gain the support of at least one major BIM vendor will be interesting to watch. It is certainly a very promising concept, but whether the big fish bite will be the difference between a nice idea and revolutionary product.

 

Asite cBIM

David, Just to make you aware that at Asite we have a fully web-based BIMServer (we call it a Model Server) within the Asite cBIM SaaS service - which we released in 2005. This is a web-based system (Software as a Service) implemented fully in Java which uses the open-standard IFC schema in the underlying model server. We have inbound and outbound connectors to all the major CAD/BIM platforms - and the model server functionality is available within a fully collaborative workflow environment, with full support for versioning and audit trails, advanced querying capability, data extraction, graphical reporting, and the ability to link objects in the model server to contracts, commercial workflows, supplier catalogues, etc. (which all exist as components within our platform) - with an open API for external access. This system is being rolled out within large-scale AEC organisations (private-sector) in the UK to manage BIM deployments across project portfolios. The system is used to define and enforce BIM protocols and then used as a central repository for model and commercial information which originates in external CAD platforms and ERP packages. This is a different model to the guys in Eindhoven are doing (we do know the team there) - as ours is a commercial offering and is based on a SaaS model - wherein global support and scalability is wrapped up into the service from the get-go. Kind Regards, Nathan http://www.freecollaboration.net/

We have inbound and outbound

We have inbound and outbound connectors to all the major CAD/BIM platforms
I couldn't find any mention of a connector for Vectorworks Nathan. I couldn't find much of anything on the Asite website to be honest.

Feedback

Hi Christiaan - unfortunately I've only returned to this blog a few months on to see your reply! We integrate with Vectorworks via the IFC connector - but fair enough we don't talk about Nemetschek on the website. I appreciate the feedback about you not being able to find much of anything on the website - but I do struggle to know how to apply it constructively. If you are interested in discussing further my contact details can be found following the link on my name above. Kind Regards, Nathan

contact details

sorry - link on my name above!

adoptation and IFC

Hi guys, The open source bimserver makes use of open standards. One of them is IFC. Every major cad vendor has an IFC import and export function. The data of every CAD-user can be put into (and out of) the bimserver using IFC. Besides that it is relatively simple to make a (for example) revit plugin (using their API) to directly connect Revit to the open source bimserver. I agree that adoptation is a big issue, but that is also why we thought it trough.... Kind regards, Léon bimserver.org

Other BIM Server efforts

Thank you for an informative post (and replies). It may be worth mentioning other IFC-based BIM Server solutions under development by industry and research groups similar to Active Facility and EDM (Jotne EPM Model Server). There are also other possibilities to achieve 'integrated' or 'federated' project delivery using open-proprietary schema and XML rather than ISO/STEP.

Thanks for the pointers

For future reference here are the links to these BIM server products:

Microstation and the BIM Server model?

An interesting review. I wonder whether the "Why BIM Servers are not common place" section should have a more extensive review of those 'collaborative work spaces' offered by CAD vendors today? As I recall, the Microstation 'paradigm' is of a CAD file which is a database to which the CAD modellers write every time they make a change to the building model? It has always seemed to me that this 'paradigm' is situated well to exploit internet-facilitated collaboration on a single file.

Of course, without a lot of extra services or additions, this is still just a CAD model, not a genuine BIM. However, this does seem to me to be a broader potential than your brief reference to collaborative work spaces?

See my "CAD Collaboration" post

Checkout this post where I cover the difference between the various CAD/BIM data methodologies and their collaboration characteristics:

CAD Collaboration (26th February 2007)

In the case of Microstation they use a file-based database architecture rather than a server-based one. This is a half-step towards the collaborative environments promised by BIM servers. Whilst data can be centralised, concurrent access is limited to the quality of the file system and reliable reads and writes is dependent on the BIM client.

Below is a table rough table which illustrates the relative qualities of each approach.

Type File-based, client-side BIM (Revit) Database-centric, clide-side BIM (Microstation) Shared BIM service (BIMserver)
Write performance One client only. Degrades as more clients are introduced. Bounded only by server resources.
Real-time collaboration Very limited: One person makes changes whilst others watch. Limited: Restricted to ability of file-system to process multiple writes. High: Internet compatible, bounded by server capacity.
BIM modification File written each time to disk by client. In-memory transaction committed to disk by client. Client transaction committed to disk by server.
Maximum connections 1 write and 10+ reads. File-locked to all but owner. 10+ read/writes. Writes limited by file-system to one at a time. 100+ read/writes. A high number of concurrent reads and writes, limited by server capacity.
Location of BIM logic Stored within the client. Stored within the client. Distributed between client and server.
Access & write permissions Restricted by filesystem and client. Restricted by filesystem and client. Restricted by BIM server.

From a practical perspective the best comparison is the difference between a file-based spreadsheet (Excel), a file-based database (Access), and a relational database server (Oracle or MySQL). Each of these systems support specific collaboration needs, and in terms of business use they form a pyramid with the most important data at the top.

i.e. Thousands of Excel files, hundreds of Access databases and a handful of Oracle or MySQL databases.

Thanks David, this is the

Thanks David, this is the first compelling description I've seen of how BIM could revolutionise architectural practice.

My only reservation is the idea that the management of a BIM server need necessarily be complicated. Such servers may well be a different kettle of fish but as demonstrated by Apple with Leopard Server (Standard Installation) the management of complex things such as servers need not in itself be a complex matter.

Why start off on this assumption? Why not start off on the assumption that the greatest good will be gained by making it a priority that such servers are both powerful and easy to use? These two concepts need not be mutually exclusive. Only in an environment where programming is put ahead of interface design will this be the case (which is unfortunately often the case in the world of open source, where projects are mostly run by programmers).



Because beneath shiny GUIs server infrastructure is complicated

You are right, in small, non-business critical environments server infrastructure does not necessarily need to be complicated or expensive. However in these cases the BIM server concept is arguably of lest benefit. When there is only a handful of people actively working on a BIM, or the model is simply a peripheral reference tool, file-based BIM is probably going to be the easiest and most practical choice. However in organisations where twenty or more people need reliable, immediate access to the same BIM repository in order to do any meaningful work, service availability and performance are of utmost importance.

The biggest difference between a BIM server and a file server is that there is literally a lot more happening. At its core a file server performs a very basic function and the underlying technologies are very mature. But even here once beyond small workgroups its cost and complexity increases once you introduce directory servers, permissions, distributed access and backup processes. Mission critical BIM servers must meet all of these needs whilst reliably parsing, validating and modifying building models. This is not an impossible task, but it is not one that should be taken lightly or on the cheap.

In order to meet these demands in a moderately sized, business critical environment you need at least two physical servers for redundancy (because a second server is cheaper than having 100 staff not work for an afternoon). As soon as an infrastructure spans more than one computer its complexity increases by an order of magnitude. For example the data must be replicated across both servers, or in many cases stored on a third server. Once configured the BIM server then needs to be integrated into the existing network infrastructure such as directory servers for identity management, HTTP front-ends for external web access and backup agents. After all of this configuration and integration the once “simple” server has taken on a level of complexity that no single GUI can successfully manage.

This being the case I do believe you will see a market for “hosted” BIM servers, but it will not be economical until the concept enters the mainstream and is adopted by at least one major BIM vendor. These hosted offerings will be provided by the major BIM vendors and smaller third-parties (to fulfill specific market niches). For example if Autodesk adopted the concept it would be in their interests to provide a low-cost, entry-level BIM service which integrated directly into Revit and AutoCAD. This would have limited functionality, but it would be provided in an effort to spur interest in a more complex business product. This “enterprise” offering would have far more complete feature-set and be deployable inside an organisation, but it would have a price comparable to other enterprise software, i.e. $10,000+.

Whether or not an Autodesk BIM server will be compatible with BIMserver is also a matter for debate. Personally I feel a major vendor has more to gain by making their server incompatible with the competition. Not only does this let them add new functionality, but it shields them from direct competition whilst they concentrate on building market share. The net result of this will be the BIM server market will begin to resemble that of email. i.e. There will be a few major vendor implementations (Exchange, Groupwise), some generic open source alternatives (Dovecot, Courier) and mainstream, hosted offerings (GMail, Live).