GRAPHISOFT has a plan. It has a plan about how different stakeholders in the AEC industry can work together that goes beyond the notion of sharing BIM models.
The problem with BIM model sharing and data exchange is that on many levels it isn’t quite working. There are two problems in particular that impact GRAPHISOFT along with most others in the AEC industry. The first problem is the battle over a common file format for a means to exchange data. The global AEC industry is largely wrestling with a battle between a proprietary file format by Autodesk—much like what happened in the 2D CAD era—and an open industry standard format that is less than perfect.
The second problem is that in many if not most cases, the need to exchange BIM models as a way for disparate teams to work together is total overkill. Take for example the exchange between an architect and her structural engineer. In a current workflow today the architect exports the architectural model and sends to the structural engineer who needs to interpret it and “translate” it into the language of her domain: into an “analytical stick model.” If the architect wants to suddenly lengthen the overhang on a roof, what the engineer needs to evaluate that change structurally is for that change to be reflected in the analytical model—a different thing than the structural elements in a BIM model. What if the architect could simply send the change to the structural engineer in the form of a direct update to the analytical model?
An analytical model for structural engineering is shown inside a future version of ARCHICAD, with new per-element parameterization data linkage to a RISA analytical model.
This is a vision about integrative working and data interoperability in AEC that is more efficient than BIM model exchange for subsequent coordination. Sure, AEC teams will still need to transfer BIM models, but not in every situation. What Huw Roberts, CEO of GRAPHISOFT calls “parameter-level” controlled access to BIM data is the next level of AEC interoperability and AEC project collaboration.
Of Digital Twins and APIs
In a talk at the GRAPHISOFT KKC in Las Vegas, Huw Roberts said he likes the term “digital twin” because it goes far beyond the digital geometry of something real in the world. “It has a lot more information than a BIM model,” says Roberts, “because it describes how you got there, about the voids, clearances” and other metadata surrounding the importance of a geometrically defined element that exists in the world.
GRAPHISOFT’s ARCHICAD 23 now supports voids as intelligent non-object elements in the BIM model. While perhaps not sexy features in the new version 23 release, voids (and in the near future ports) are vital additions to grids, clearances, and spaces—all elements of the BIM model that if it wasn’t a building but a living body we could describe as “tissue-less.” There is nothing in a void you touch—provisions for voids help coordinate numerous unsexy items in real buildings, like mechanical equipment and critical clearances around elements that both take up space and volume but beyond their own geometry.
It has a lot more information than a BIM model because it describes how you got there…
This is part of the metadata of buildings in the real world and the data found in a digital twin. Both the things you can touch and the things you cannot are elements in an ARCHICAD BIM model and GRAPHISOFT’s vision for “parameter-level” controlled access to BIM data is far-reaching and rich with potential. It is important to note that a “digital twin” isn’t just a replica of a physical thing in the real world, it can act as the “soul” of that physical thing. The body and soul metaphor adds massive depth potential to digital models—the digital twin is a way forward to visualizing both the physical shell of something in “digital space” but also gaining access to the “intelligence” behind that physical shell. In the context of buildings and cities, this intelligence can inform during design, construction, and operations.
In a series of presentations that looked at the future of GRAPHISOFT, KCC attendees got an interesting view into how their ARCHICAD models and their attendant data and metadata could communicate with other applications—and not just BIM applications or even 3D applications but any application.
The goal is to attack the ways data in AEC lives in silos—even in the BIM world. If GRAPHISOFT can liberate the data and information that tends to get bound up in specific applications with their specific file format types, a faster, more streamlined, and more integrative way of working can emerge. Viktor Varkonyi, new Division Head of Design and Planning at Nemetschek said on stage that “it could be fair to say that even the BIM manager is in a different silo than the architect.” To radically de-silo data, pushing beyond BIM file format exchanges—one of the core expertise of a BIM manager—is necessary and vital.
Python API integrations are shown in a future version of ARCHICAD shown above, live-linked with data in Excel.
To help push this element-level data integration GRAPHISOFT has previewed new support for API-based data exchange. The company has long had a C++ based API (application programming interface) so that part isn’t new. What is new is that the definition of the BIM model itself has been extended—the data that this API can now touch works deeper into the BIM model itself. A parameter-level transaction environment can move the AEC discipline from what the company labeled “detached design” to “integrative design”—in the same spirit of the master builder of the pre-renaissance era.
To make the point about just how detached the A, E, and C disciplines are, a RISA representative came on stage and noted that few architects, very few, know what tools their structural engineers use to do their structural analysis work. When working with a per-element basis various stakeholders can begin to be capable of developing more integrative workflows.
In addition to deeper C++ API technology, the company showed support for lighter-weight APIs like Python and JSON. These demonstrations were met with much approval from the KCC audience and the many partnership speakers on stage already working with early versions of this technology. A very impressive example that got attendees very excited was a Python API example that worked with linked data from Excel.
The API story is still evolving but the examples shown on stage at the KCC in Vegas were impressive. JSON and Python are lighter-weight languages that offer more accessibility and greater potential for synergy and custom development, both by end-users and by software companies. API integration is all the rage in the current SaaS world. Take a look at Asana, for example, and the sheer volume of API integrations possible is getting mindboggling.
MORE: Architosh Exclusive—Nemetschek Group Unveils Its CDE Strategy with Bluebeam Technology at its Core
The KCC showed one architect after another building out bespoke, firm-specific, custom workflows using various means but most often Rhino-Grasshopper-ARCHICAD integrations. The AEC industry can expect a lot more. What isn’t clear is how these new API-based technologies will work with web-based common data environments (CDEs) in the industry, including the future Nemetschek Group level solution that has already been discussed on Architosh at length. More clarity on that front remains a target for this publication, but in the meantime, GRAPHISOFT seems ready to push in a new direction that provides both a deeper and wider level of creating more integrative workflows that cut across data silos.