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.