The open source AEC technology cloud platform, Speckle, first came to my attention in December 2021 in an Agile BIM webinar I attended (see the article, “Speckle and IFC.js: Open Source Tools for BIM”), and it has gained so much momentum since then that there is now an entire conference devoted to it. The 2023 SpeckleCon conference was a two-day online event held last month, and it showcased the latest technology developments of the Speckle platform, including a brand-new Automate tool for automating repetitive tasks in AEC. A detailed overview of these developments is captured in this article, starting with a refresher on what Speckle is and how it is different from other AEC applications.
SpeckleCon 2023 also featured a large number of presentations by leading AEC firms like Arup, Aurecon, Atkins, Bollinger+Grohmann, and John Sisk & Son Ltd., showing how they were implementing Speckle in their organizations (Figure 1). There were also demonstrations by several third-party developers showing the tools that they were building on the Speckle platform, extending its cutting-edge technology and open-source philosophy in multiple ways to dramatically improve AEC workflows. These presentations will be captured in a separate article next month.
The main idea behind Speckle is to create an open central repository for AEC project data that can be used to exchange data in real time between multiple applications, but rather than using a file format, all the building object data is stored in a database. From a technical perspective, this is a critical difference – there is, in fact, a lot of information explaining this for those who are interested. (See, for example: File System vs. Database - DZone; Database vs File system storage - Stack Overflow; and Difference between DBMS and File System - W3schools, which I found was the easiest for a non-technical person to understand.)
To put it simply, storing object data in a database is a lot more flexible compared to storing it in a specific file format, which requires the data to be structured in a specific way. It is much easier to extend a database to add more types of information (for example, a new property type for a wall element) than to extend a file format to include this, whether it is an open file format like the IFC or a closed, proprietary one like RVT. Additionally, adding more data, whether it is more building elements or more metadata, will cause a physical file to continue to bloat in size which can become unmanageable at some point. In contrast, adding more data to a database is not problematic as there are no physical constraints, especially when it is located in the cloud as Speckle is.
In addition to data storage, there is also the matter of retrieving the data for all the different tasks and workflows that need to use it. Accessing the data from a file requires the whole file to be parsed by the receiving application, even if a lot of the data might not even be needed by it. For example, a visualization application does not need to have detailed metadata about BIM objects except for the surface texture of the objects that are visible. So why should it be forced to read through an entire file to parse what it needs? On the other hand, if the data is in a database, it can quickly traverse the data structure to extract what it needs and not bother with data that is not relevant to what it does. This makes the date retrieval a lot more efficient and therefore much faster.
This, then, is the main idea behind Speckle. It has built an object-based data layer for 3D data and BIM models, decomposing them into their sub-constituent atoms and storing them in a database that is available to users, to clients, and to scripts. The database becomes the central hub of the project, and Speckle provides “connectors” for different AEC applications to send data to it as well as receive data from it. This data exchange can be done in real time, enabling synchronous collaboration between the team members working on a project (as explained in Difference between DBMS and File System - W3schools, concurrent access to the same data is possible in a database but not in a file), along with broader interoperability among all connected applications (Figure 2).
The list of connectors that Speckle has developed is very comprehensive, covering the most popular AEC applications including Revit, Dynamo, Rhino, Grasshopper, Unity, Blender, ArcGIS, MicroStation, and 15 other applications. Additional connectors are in development and will soon be available for applications including SketchUp, Archicad (Figure 3), Tekla Structures, and Navisworks. Also, since Speckle is open-source, connectors can, in theory, be created by anyone with a sufficient amount of technical expertise.
Let’s now move to look at what was shared at SpeckleCon last month.
At the conference keynote, the Speckle team provided an overview of the latest technology developments of the Speckle platform. These include Speckle Mapper, which allows native BIM objects to be created from simple CAD geometry; Parameter Updater, which allows schedules from Revit to be sent to Excel where they can be updated and sent back to Revit, enabling more granular data exchanges to be accomplished in a few clicks without resorting to file exports or Dynamo scripts; and significant enhancements to the Speckle PowerBI connector, which allows custom data insights to be quickly generated from live project data in the form of interactive dashboards that can help to understand project status and drive decision making (Figure 4).
Other updates include a change in terminology to make Speckle more accessible and understandable, and less geeky. Thus, elements selected in an application to send to Speckle in what was known earlier as a “stream” will now simply be referred to as a “project.” A project can be segmented into multiple “models” — these were earlier known as “branches” — and Speckle automatically creates “versions” of the data each time it is sent to Speckle — these were previously referred to as “commits.” Viewing Speckle models in the browser has been enhanced with a new live following mode enabling real-time collaboration between the extended design team, which can also include the client (Figure 5). There is also a new change tracking feature that leverages Speckle’s versioning capability to quickly provide an insight into real-time project changes visually in the browser (Figure 6).
Additionally, model federation has been improved to make it easier to create model overlays on the fly as well as swap versions to visually check and evaluate the design in real time. The Speckle Viewer has been significantly overhauled to make it more modular, extensible, and faster, with powerful filtering capabilities by any element metadata property (Figure 7). There is also a new batch uploader capability that allows multiple files to be sent to Speckle, as well as the ability to leverage the data in the project to enable AI-powered conversations (Figure 8).
While AI is, of course, a key technology going forward, the biggest Speckle update announced at SpeckleCon was a tool called Automate. As the Speckle CEO put it, we need to “automate the boring things away before reaching AI nirvana” – which I thought was a fantastic line, in addition to being spot on!
As the name suggests, Automate is a functionality within Speckle that enable functions to be written that work on the project data in Speckle to automate various AEC processes and workflows (Figure 9). However, what makes Speckle Automate different from other kinds of automation functions and scripts that are written for other AEC applications — as well as the custom apps for Speckle itself — is that once a Speckle automation is set up for a specific use case, it will be automatically executed every time the model is changed — no button needs to be pressed to activate it. The technical term for this kind of software technology is CI/CD (see: What Is CI/CD, Continuous Integration and Continuous Delivery?), and Automate is a CI/CD solution for Speckle. Not only does this automation minimize manual labor, it also provides the assurance that the selected workflow has been executed on the most up-to-date data.
While Automate is still a very new addition to Speckle, there were several demos of it shown at SpeckleCon to illustrate what can be done with it for specific use cases. Examples include an Automate function that generates the 3D context for a Revit model (Figure 10); a “headless” Blender demo that automatically runs renders in the cloud of each of the cameras and 3D views in a Speckle model; simple quality control checks such as whether the model has an specific element type or data type, for example, an IFC Wall; a Model Health function that checks the mesh density of all the elements and highlights those that exceed specified limits (Figure 11); and a Data Sanitizer function that automatically removes or encrypts private data (which is to be kept confidential) every time a new version of the model is published (Figure 12). Other examples demonstrated were a data check for code compliance and clash detection between different disciplinary elements such as structure and ductwork.
In addition to the end users of Automate functions, Speckle is also making it easy for developers to create functions by providing them with templates to get started. Functions can be written in any language, and they can use Speckle’s APIs and Software Development Kits (SDKs) to work with the project data in Speckle. Once a function is created, it will be displayed in the Functions library, from where it can be used in to create an Automation. All functions are public, open-source, and freely accessible, encouraging the development of a broad collaborative community for AEC technology.
Speckle is a radically different approach to AEC technology — it stores project data in a database rather than a traditional file. It is also open-source, thus providing not only an alternative to proprietary file formats from vendors but also the open IFC file format that has, until now, been the cornerstone of interoperability in the AEC industry. Given that the IFC has been around for decades but has yet not solved the interoperability problem, perhaps a fresh new approach like Speckle might do the trick?
While this is, of course, impossible to predict, there is no doubt that it can only help to explore more than one approach to a problem. From that perspective, it is terrific to see Speckle growing and gaining so much momentum! I am looking forward to continuing to follow its progress.
Stay tuned for an in-depth overview, to be published next month, of the Speckle implementations and third-party tools that were presented at SpeckleCon 2023.
Lachmi Khemlani is founder and editor of AECbytes. She has a Ph.D. in Architecture from UC Berkeley, specializing in intelligent building modeling, and consults and writes on AEC technology. She can be reached at email@example.com.
Have comments or feedback on this article? Visit its AECbytes blog posting to share them with other readers or see what others have to say.
AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
This article provides an overview of Speckle and IFC.js, two open source software tools for the AEC industry that are available for free and can used by anyone developing BIM applications to jumpstart their development.
This article provides a broad overview of the IFC model without delving too deeply into its technicalities, intended to provide a better understanding of it to the AEC practitioner interested in interoperability.
This article capture the highlights of the 2021 Summit of the Open Design Alliance, including updates on its technologies such as CAD and 3D modeling, visualization, Revit and Navisworks toolkits, IFC and OpenBIM interoperability, point cloud support, cloud-based project management, and others.
In this Viewpoint article, Mario Gutman, Vice-president and Firmwide CAD Director of HOK, discusses the rebranding of the International Alliance for Interoperability (IAI) to buildingSMART, an organization he sees as the best forum for developing rigor in how the AEC industry exchanges information.