# Direct data flows as alternative to file-based Exchanges in AEC: A comparative case study of two plugin developments

Ahmed Ismail, Philippe Marin

► To cite this version:

Ahmed Ismail, Philippe Marin. Direct data flows as alternative to file-based Exchanges in AEC: A comparative case study of two plugin developments. eCAADe 2023: Digital Design Reconsidered, Graz University of Technology, Sep 2023, Graz, Austria. pp.263-272, 10.52842/conf.ecaade.2023.1.263. hal-04214735

HAL Id: hal-04214735

https://hal.science/hal-04214735

Submitted on 31 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Direct data flows as alternative to file-based Exchanges in AEC: A comparative case study of two plugin developments

Ahmed Ismail, Philippe Marin

► To cite this version:

Ahmed Ismail, Philippe Marin. Direct data flows as alternative to file-based Exchanges in AEC: A comparative case study of two plugin developments. eCAADe 2023: Digital Design Reconsidered, Graz University of Technology, Sep 2023, Graz, Austria. pp.263-272, 10.52842/conf.ecaade.2023.1.263. hal-04214735

HAL Id: hal-04214735

https://hal.science/hal-04214735v1

Submitted on 31 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Direct data flows as alternative to file-based Exchanges in AEC

## A comparative case study of two plugin developments

Ahmed W. Ismail¹, Philippe Marin²

¹,²MHA Laboratory, Grenoble School of Architecture (ENSAG), Univ. Grenoble Alpes

(UGA) ¹Laboratory CNPA, École Polytechnique Fédérale de Lausanne

¹,²{ahmed.ismail|philippe.marin}@grenoble.archi.fr

In this article, we examine two ways of establishing direct links between different digital tools, based on two plugins developed as part of a larger research. The objective of the research is to explore alternative ways of exchanging data by the means of free and direct data flows.

The research methodology consists of linking theory and practice. Firstly, it consists of studying the current state of interoperability in AEC through literature review, to define the theoretical frame. It focuses on the particular use-case of interoperability between design actors (architects), and fabrication actors (suppliers). Secondly, as a practical application, it studies the development of two plugins. Both plugins establish design-to-fabrication workflows with the means of direct data flows, based on open-source solutions.

The aim of this paper is to compare the primary results of the two plugins, currently under development. The comparison addresses both practice-related and technical aspects. This assessment analyses different interoperability needs and the efficiency of the developed tools as a solution to the initial problem of interoperability. The results provide guidance for future developments and give suggestions for possible improvements.
By providing new protocols for data exchange, this research uses software development as a tool to target the initial research problem.

**Keywords:** Data Exchange, Interoperability, Industrial Engineering, AEC, Direct Dataflow, Software Development, Open Source.

## INTRODUCTION

In the context of the second digital turn (Carpo, 2017) and with the adoption of BIM methods, interoperability has become an important topic in the architectural design practice. Interoperability is needed to allow for data exchange between

different software tools used in AEC (Eastman et al., 2018).

While most data exchanges are file-based, this paper focuses on alternatives to traditional workflows. Two software tools are examined. A comparison is made on both technical and
# Direct data flows as alternative to file-based Exchanges in AEC

## A comparative case study of two plugin developments

Ahmed W. Ismail¹, Philippe Marin²

¹,²MHA Laboratory, Grenoble School of Architecture (ENSAG), Univ. Grenoble Alpes (UGA) ¹Laboratory CNPA, École Polytechnique Fédérale de Lausanne

¹,²{ahmed.ismail|philippe.marin}@grenoble.archi.fr

In this article, we examine two ways of establishing direct links between different digital tools, based on two plugins developed as part of a larger research. The objective of the research is to explore alternative ways of exchanging data by the means of free and direct data flows.

The research methodology consists of linking theory and practice. Firstly, it consists of studying the current state of interoperability in AEC through literature review, to define the theoretical frame. It focuses on the particular use-case of interoperability between design actors (architects), and fabrication actors (suppliers). Secondly, as a practical application, it studies the development of two plugins. Both plugins establish design-to-fabrication workflows with the means of direct data flows, based on open-source solutions.

The aim of this paper is to compare the primary results of the two plugins, currently under development. The comparison addresses both practice-related and technical aspects. This assessment analyses different interoperability needs and the efficiency of the developed tools as a solution to the initial problem of interoperability. The results provide guidance for future developments and give suggestions for possible improvements.
By providing new protocols for data exchange, this research uses software development as a tool to target the initial research problem.

**Keywords:** Data Exchange, Interoperability, Industrial Engineering, AEC, Direct Dataflow, Software Development, Open Source.

## INTRODUCTION

In the context of the second digital turn (Carpo, 2017) and with the adoption of BIM methods, interoperability has become an important topic in the architectural design practice. Interoperability is needed to allow for data exchange between

different software tools used in AEC (Eastman et al., 2018).

While most data exchanges are file-based, this paper focuses on alternatives to traditional workflows. Two software tools are examined. A comparison is made on both technical and
operational aspects. The aim is to define how their
response helps solving the interoperability issue.

In the first part, a state of the art of
interoperability is made, where the different existing
solutions are examined. Then, the two tools are
presented in a comparative method. Finally, the last
part is a discussion on the efficiency of the solutions
as a response to the issue of interoperability.

## INTEROPERABILITY: A STATE OF THE ART

The digital transition and the adoption of BIM
methods in the architectural practice, and more
generally in AEC, concerned all the disciplines
involved in the architectural project. It brought new
software tools to practice. The research hypothesis is
that two possible scenarios motivate data exchange:
the need to collaborate between different actors of
the project and the natural desire to mix and match.

In this part, various ways of exchanging data are
examined and analysed, in order to constitute a state
of the art of the current situation on interoperability
in AEC.

## Interoperability modes

Different literature resources on BIM and digital tools
evaluated the state of interoperability. According to
Eastman et. Al, there are four possibilities to
exchange data: (1) direct proprietary binary links (2)
Proprietary file formats (3) public product data
models (4) XML exchanges (Eastman et al., 2018).

Van Berlo distinguishes two perceptions of a
shared model for collaboration: one that uses a
single central data repository suited to a same
software environment, mostly proprietary; and that
of a shared data model, based on an open standard
like IFC (van Berlo et al., 2012). Poinet finds this vision
coherent with Baran's 3 network types: (1)
Centralized (2) Decentralized (3) Distributed. He
claims that the first perception of a shared model
falls within the first network type, whereas the
second perception corresponds to the second and
third network types (Poinet, 2020).

## File-based exchanges

Among the aforementioned types of data
exchanges, file-based exchanges are the most
common mode. Most file formats are physical text
files saved on computer memory. They can be
proprietary closed, proprietary open or public.

Hence, DWG is a proprietary closed file format.
Despite being the native format for Autodesk's
AutoCAD, it became a de-facto standard for CAD
data (Björk and Laakso, 2010). This is despite the
existence of proprietary open like DXF and public
open formats like IGS. When it comes to data-rich 3D
models, there are two approaches: OpenBIM and
ClosedBIM (Bucher and Hall, 2020), which resonates
with Van Berlo's shared model perceptions. In
ClosedBIM, a proprietary file format is privileged for
exchange between tools developed by the same
editor and for the use of a single shared model for
collaboration. It is the case of the Autodesk
environment. In OpenBIM practices, a neutral open
format is favoured for exchanges between
applications from different editors. In this case, what
is shared is data model with different
implementations (e.g. instances). It is typically the
case of IFC file format, based on the IFC standard.

## Proprietary formats and vendor lock

Proprietary formats may offer some advantages.
They allow for seamless data exchanges, with no
need for conversions or use of intermediate formats,
allowing for time gain and preventing data loss.
Technically, they allow for direct binary links via APIs
and the use of homogeneous Common Data
Environments for collaboration. However, the use of
proprietary file formats results in a limited freedom
for the data exchange. Proprietary formats limit
interoperability by restricting a workflow to certain
tools, which results in Vendor Lock-in.

Consequences of lock-in is privileging
interoperability over performance. Also, when data
is written in proprietary files, it can only be accessed
by the means of certain software tools. This raises a
question of ownership and authorship of data,
especially with the proliferation of time-limited
operational aspects. The aim is to define how their
response helps solving the interoperability issue.

In the first part, a state of the art of
interoperability is made, where the different existing
solutions are examined. Then, the two tools are
presented in a comparative method. Finally, the last
part is a discussion on the efficiency of the solutions
as a response to the issue of interoperability.

## INTEROPERABILITY: A STATE OF THE ART

The digital transition and the adoption of BIM
methods in the architectural practice, and more
generally in AEC, concerned all the disciplines
involved in the architectural project. It brought new
software tools to practice. The research hypothesis is
that two possible scenarios motivate data exchange:
the need to collaborate between different actors of
the project and the natural desire to mix and match.

In this part, various ways of exchanging data are
examined and analysed, in order to constitute a state
of the art of the current situation on interoperability
in AEC.

## Interoperability modes

Different literature resources on BIM and digital tools
evaluated the state of interoperability. According to
Eastman et. Al, there are four possibilities to
exchange data: (1) direct proprietary binary links (2)
Proprietary file formats (3) public product data
models (4) XML exchanges (Eastman et al., 2018).

Van Berlo distinguishes two perceptions of a
shared model for collaboration: one that uses a
single central data repository suited to a same
software environment, mostly proprietary; and that
of a shared data model, based on an open standard
like IFC (van Berlo et al., 2012). Poinet finds this vision
coherent with Baran's 3 network types: (1)
Centralized (2) Decentralized (3) Distributed. He
claims that the first perception of a shared model
falls within the first network type, whereas the
second perception corresponds to the second and
third network types (Poinet, 2020).

## File-based exchanges

Among the aforementioned types of data
exchanges, file-based exchanges are the most
common mode. Most file formats are physical text
files saved on computer memory. They can be
proprietary closed, proprietary open or public.

Hence, DWG is a proprietary closed file format.
Despite being the native format for Autodesk's
AutoCAD, it became a de-facto standard for CAD
data (Björk and Laakso, 2010). This is despite the
existence of proprietary open like DXF and public
open formats like IGS. When it comes to data-rich 3D
models, there are two approaches: OpenBIM and
ClosedBIM (Bucher and Hall, 2020), which resonates
with Van Berlo's shared model perceptions. In
ClosedBIM, a proprietary file format is privileged for
exchange between tools developed by the same
editor and for the use of a single shared model for
collaboration. It is the case of the Autodesk
environment. In OpenBIM practices, a neutral open
format is favoured for exchanges between
applications from different editors. In this case, what
is shared is data model with different
implementations (e.g. instances). It is typically the
case of IFC file format, based on the IFC standard.

## Proprietary formats and vendor lock

Proprietary formats may offer some advantages.
They allow for seamless data exchanges, with no
need for conversions or use of intermediate formats,
allowing for time gain and preventing data loss.
Technically, they allow for direct binary links via APIs
and the use of homogeneous Common Data
Environments for collaboration. However, the use of
proprietary file formats results in a limited freedom
for the data exchange. Proprietary formats limit
interoperability by restricting a workflow to certain
tools, which results in Vendor Lock-in.

Consequences of lock-in is privileging
interoperability over performance. Also, when data
is written in proprietary files, it can only be accessed
by the means of certain software tools. This raises a
question of ownership and authorship of data,
especially with the proliferation of time-limited
subscription-based plans. This is where open standards and open file formats are more sustainable, more transparent and more interoperable.

## Open standards potential and limitations

Standardization is key for interoperability. In other industries, the wide adoption of recognized standards was key to efficient interoperability, as in the case of W3C. When it comes to AEC, the standardization process began with the ISO committee that formulated the STEP (Standard for the Exchange of Product data). This gave birth to the EXPRESS modelling language (Schenck and Wilson, 1994). The International Alliance for Interoperability, now BuildingSmart International, worked on a standard for Building data.

Hence, Industry Foundation Classes (IFC) were adopted, based on the same EXPRESS language. Beyond interoperability, it is an object-oriented product data model, aimed to suit the complex nature of an architectural project. It is the only standard made specifically for AEC. For some authors, all BIM models should be based on the IFC standard. In other words, a BIM model should be an instance of the IFC object data model.

However, in spite of all what IFC can support, it has been often limited in use to a file format. Most authoring tools have their own proprietary closed data model. To create an equivalent IFC model, data is translated from native format to IFC at export, and inversely when importing an IFC into an authoring tool. IFC has the advantage of being a public open standard, which guarantees the access to all data at any time, independently from software tools.

## Examining alternative ways

Alternative ways of data exchange are enabled by the recent advances in data communication. It is coupled with the growing tendency of implementing APIs accessible by the public users, which allow them to develop custom extensions on top of authoring tools. Examples of tools with

accessible APIs include Autodesk's package or McNeel's Rhinoceros, which are both .NET based.

These two environments are usually involved in workflows where design is made in Rhinoceros, for its freeform NURBS-based modelling; and BIM model made in Autodesk's Revit, for the data-rich model, necessary for the integration of technical aspects, execution and documentation. This led to the proliferation of tools designed to enable direct interoperability between the two. Examples include, but are not limited to, Grevit, Rhynamo, Mantis Shrimp (Deutsch, 2017) and recently Rhino.inside.Revit. The latter is based on the Rhino.inside technology by McNeel, which enables Rhino to run inside of a host application, sharing a same process and memory space (McNeel & Associates, 2022). These examples are limited to two specific software and the particular use case of a 'Design to BIM' Workflow. They correspond to the need of mix and match of the best of each of the two tools in a bilateral manner.

When it comes to collaboration between different actors coming from various disciplines, multiple tools are involved. Alternatives to file-based collaboration will rely on direct links to APIs and a communication protocol, like REST protocol through a shared server. Flux.io was a project that enabled direct interoperability between different applications via a server connection linking applications together. The project was proprietary and shut down abruptly in 2018 (Wintour, 2020).

Speckle is an open-source project, defined as a distributed Common Data Environment and a GIT for AEC. It started as a research project at UCL and is now a powerful tool for interoperability between different tools. Similar to Flux, it consists of connectors, acting as clients, and a server to host data, with a RESTful communication mechanism. It also involves a 3D Web viewer and a Git-like versioning mechanism. The growing success of Speckle, motivated by a large community and a performant set of connectors covering a large spectre of software tools.
subscription-based plans. This is where open standards and open file formats are more sustainable, more transparent and more interoperable.

## Open standards potential and limitations

Standardization is key for interoperability. In other industries, the wide adoption of recognized standards was key to efficient interoperability, as in the case of W3C. When it comes to AEC, the standardization process began with the ISO committee that formulated the STEP (Standard for the Exchange of Product data). This gave birth to the EXPRESS modelling language (Schenck and Wilson, 1994). The International Alliance for Interoperability, now BuildingSmart International, worked on a standard for Building data.

Hence, Industry Foundation Classes (IFC) were adopted, based on the same EXPRESS language. Beyond interoperability, it is an object-oriented product data model, aimed to suit the complex nature of an architectural project. It is the only standard made specifically for AEC. For some authors, all BIM models should be based on the IFC standard. In other words, a BIM model should be an instance of the IFC object data model.

However, in spite of all what IFC can support, it has been often limited in use to a file format. Most authoring tools have their own proprietary closed data model. To create an equivalent IFC model, data is translated from native format to IFC at export, and inversely when importing an IFC into an authoring tool. IFC has the advantage of being a public open standard, which guarantees the access to all data at any time, independently from software tools.

## Examining alternative ways

Alternative ways of data exchange are enabled by the recent advances in data communication. It is coupled with the growing tendency of implementing APIs accessible by the public users, which allow them to develop custom extensions on top of authoring tools. Examples of tools with

accessible APIs include Autodesk's package or McNeel's Rhinoceros, which are both .NET based.

These two environments are usually involved in workflows where design is made in Rhinoceros, for its freeform NURBS-based modelling; and BIM model made in Autodesk's Revit, for the data-rich model, necessary for the integration of technical aspects, execution and documentation. This led to the proliferation of tools designed to enable direct interoperability between the two. Examples include, but are not limited to, Grevit, Rhynamo, Mantis Shrimp (Deutsch, 2017) and recently Rhino.inside.Revit. The latter is based on the Rhino.inside technology by McNeel, which enables Rhino to run inside of a host application, sharing a same process and memory space (McNeel & Associates, 2022). These examples are limited to two specific software and the particular use case of a 'Design to BIM' Workflow. They correspond to the need of mix and match of the best of each of the two tools in a bilateral manner.

When it comes to collaboration between different actors coming from various disciplines, multiple tools are involved. Alternatives to file-based collaboration will rely on direct links to APIs and a communication protocol, like REST protocol through a shared server. Flux.io was a project that enabled direct interoperability between different applications via a server connection linking applications together. The project was proprietary and shut down abruptly in 2018 (Wintour, 2020).

Speckle is an open-source project, defined as a distributed Common Data Environment and a GIT for AEC. It started as a research project at UCL and is now a powerful tool for interoperability between different tools. Similar to Flux, it consists of connectors, acting as clients, and a server to host data, with a RESTful communication mechanism. It also involves a 3D Web viewer and a Git-like versioning mechanism. The growing success of Speckle, motivated by a large community and a performant set of connectors covering a large spectre of software tools.
Although not a formal standard, Speckle's openness increased its popularity in AEC. The next part compares an implementation of a Rhino.inside project to the development of a Speckle connector, both on top of the same software, for the particular use case of design to fabrication.

## CASE STUDY OF TWO SOFTWARE DEVELOPMENT

In this part, two software developments are compared. They correspond to two use-cases and are based on two distinct technologies. The common trait of both implementations is being real-time, file-less data exchanges and open-source. The objective is to evaluate the efficiency of developing custom tools for interoperability.

### Context

These two developments are carried out as part of a larger research and a Doctoral Thesis. The main goal is to find efficient solutions to the interoperability issue, by experimenting Open Source and examining non-traditional ways of data exchange. The findings of the previous review constitute a theoretical framework for the development, testing and evaluation of the developed tools.

### Development methodology

The research methodology is aligned with the development of the two tools. The objective is to study a seamless interoperability adapted to the particular use-case of interoperability between AEC software and a fabrication-centred software, and to determine its efficiency.

It starts by defining the use-case in accordance with the theoretical findings. A software tool is chosen as an example to attempt to enhance its interoperability with other AEC tools. Two open-source solutions are picked to be tested. The technical aspects of the solutions used are then analysed. Finally, a simultaneous development process is made, while noting the different technical and functional aspects, as well as the primary results to be studied.

## The use cases

As mentioned in the first part, file-based exchanges are cumbersome and do not allow for a fluid flow of data in an associative way. In this study, TopSolid, a CAD-CAM software, has been chosen. It is a mechanical-industrial tool, known for its fabrication-centred approach. To establish direct interoperability with other AEC tools, two plugins target two use-cases, in a non-file manner. Table 1 summarizes the dual approach for interoperability.

<table><caption>Table 1
Comparison of 2 use cases and tools</caption><thead><tr><th></th><th>Use case 1</th><th>Use case 2</th></tr></thead><tbody><tr><th>User(s)</th><td>Single user</td><td>Multiple Users</td></tr><tr><th>Machines</th><td>Same Machine</td><td>Multiple machines</td></tr><tr><th>Interoperability need</th><td>Mix and match</td><td>Collaboration</td></tr><tr><th>Tool</th><td>Rhino.inside</td><td>Speckle</td></tr></tbody></table>

As Observed in Table 1, the first is that of the same user, wanting to use different tools on their own machine. It is the case of the aforementioned natural desire of 'mix and match' during the same phase of a project, or else for the transition between one phase and another. The tool developed here is Rhino.inside.TopSolid, based on the open-source Rhino.inside technology by McNeel, similarly to the well-known Rhino.inside.Revit.

The second use-case is that of full collaboration between a user and other users, each working on their own machine, using their own software tools adapted to their corresponding discipline. The tool developed for this case is the Speckle Connector for TopSolid. Speckle being an open-source project, it allows for direct interoperability between tools belonging to different software ecosystems.

## Technical Description of the tools involved and developed

Among the tools involved there is TopSolid, a CAD-CAM software, used in mechanical engineering and wood assembling. It is characterized by its exact solid modelling kernel Parasolid and the integrated
Although not a formal standard, Speckle's openness increased its popularity in AEC. The next part compares an implementation of a Rhino.inside project to the development of a Speckle connector, both on top of the same software, for the particular use case of design to fabrication.

## CASE STUDY OF TWO SOFTWARE DEVELOPMENT

In this part, two software developments are compared. They correspond to two use-cases and are based on two distinct technologies. The common trait of both implementations is being real-time, file-less data exchanges and open-source. The objective is to evaluate the efficiency of developing custom tools for interoperability.

### Context

These two developments are carried out as part of a larger research and a Doctoral Thesis. The main goal is to find efficient solutions to the interoperability issue, by experimenting Open Source and examining non-traditional ways of data exchange. The findings of the previous review constitute a theoretical framework for the development, testing and evaluation of the developed tools.

### Development methodology

The research methodology is aligned with the development of the two tools. The objective is to study a seamless interoperability adapted to the particular use-case of interoperability between AEC software and a fabrication-centred software, and to determine its efficiency.

It starts by defining the use-case in accordance with the theoretical findings. A software tool is chosen as an example to attempt to enhance its interoperability with other AEC tools. Two open-source solutions are picked to be tested. The technical aspects of the solutions used are then analysed. Finally, a simultaneous development process is made, while noting the different technical and functional aspects, as well as the primary results to be studied.

## The use cases

As mentioned in the first part, file-based exchanges are cumbersome and do not allow for a fluid flow of data in an associative way. In this study, TopSolid, a CAD-CAM software, has been chosen. It is a mechanical-industrial tool, known for its fabrication-centred approach. To establish direct interoperability with other AEC tools, two plugins target two use-cases, in a non-file manner. Table 1 summarizes the dual approach for interoperability.

<table><caption>Table 1
Comparison of 2 use cases and tools</caption><thead><tr><th></th><th>Use case 1</th><th>Use case 2</th></tr></thead><tbody><tr><th>User(s)</th><td>Single user</td><td>Multiple Users</td></tr><tr><th>Machines</th><td>Same Machine</td><td>Multiple machines</td></tr><tr><th>Interoperability need</th><td>Mix and match</td><td>Collaboration</td></tr><tr><th>Tool</th><td>Rhino.inside</td><td>Speckle</td></tr></tbody></table>

As Observed in Table 1, the first is that of the same user, wanting to use different tools on their own machine. It is the case of the aforementioned natural desire of 'mix and match' during the same phase of a project, or else for the transition between one phase and another. The tool developed here is Rhino.inside.TopSolid, based on the open-source Rhino.inside technology by McNeel, similarly to the well-known Rhino.inside.Revit.

The second use-case is that of full collaboration between a user and other users, each working on their own machine, using their own software tools adapted to their corresponding discipline. The tool developed for this case is the Speckle Connector for TopSolid. Speckle being an open-source project, it allows for direct interoperability between tools belonging to different software ecosystems.

## Technical Description of the tools involved and developed

Among the tools involved there is TopSolid, a CAD-CAM software, used in mechanical engineering and wood assembling. It is characterized by its exact solid modelling kernel Parasolid and the integrated
<caption>Table 2
Comparison on
technical aspects</caption>

Product Data Management, with feature-based parametric design, in a part/assembly logic (Monedero, 2000). The API provided, Top'ADS, is .NET based and allows for AddIn developments. The two developments are built on top of this API and are coded in C#. The AddIns establish the link to Speckle and Rhino by calling their APIs. A comparative summary is provided in Table 2.

Speckle provides many Software development Kits (SDKs), of which the most popular is .NET based (Introduction | Speckle Docs, 2023). It provides tools to create a Speckle connector for a software of choice. The SDK is part of the SpeckleSharp repository where one also finds the Objects Kit. An object kit is composed by an object model, serving as a reference schema for geometries and built elements, and a set of converters that take care of converting from and to native formats of each software. When creating a connector, one deals with (1) Bindings, establishing a connection with host app (2) Conversion routines of the native elements from and to the schema. Speckle's software architecture is shown in figure 1.

In the case of the Rhino.inside project (mcneel/rhino.inside, 2023), the aim is to be able to launch Rhino in a host software, in this case TopSolid. Technically, this means to be able to load the Rhino Dynamic Link Libraries (DLL) from TopSolid and be able to launch Rhino's main window and Grasshopper window. The link between both environments is achieved through a Grasshopper plugin (a .gha file loaded when Rhino is launched inside TopSolid) that contains the different commands to interact with TopSolid's native objects through Grasshopper's visual programming interface. Similar to Speckle, Rhino's .NET SDK was used, with code written in C#. Figure 2 illustrates Rhino.inside's structure.

## Data conversion:

### A strongly-typed approach

Both plugin developments establish a link between two distinct object models. On a lower technical level, sharing the same framework and programming language offers a common ground for

data types. C# is a strongly-typed, object-oriented programming language. Hence, conversion routines consist of translating elementary built-in data types, such as integral numeric types, floating-point numeric types, Boolean value type and character-based types (Microsoft, 2022).

Native object types for each software data model are defined as a structured combination of the previously mentioned elementary data types. This is the case of classes or structs. A conversion of an object instances from one model to another consists of mapping the different values from one definition to the other, applying the necessary adjustments.

For example, the same NURBS curve in different environments based on its mathematical definition and its implementation in the software model. A parametric curve in a CAD software consists of an equation, an interval and the group of points (Ko and Steinfeld, 2018). A generalization of freeform curves is the NURBS representation. TopSolid uses its geometric kernel, Parasolid, to define a curve object. Rhino has its own geometric kernel where it is defined. For the case of Speckle, the Curve class is only a data model as it has no geometry kernel. The data needed to construct a NURBS curve are control points and Knot vector. Each control point is defined by three numeric values corresponding to its cartesian coordinates, and optionally a fourth value for the weight in case of rational BSplines. Knot vector is a set of numeric values. Some additional

<table><thead><tr><th></th><th>Rhino.inside</th><th>Speckle</th></tr></thead><tbody><tr><th>Framework</th><td>.NET</td><td>.NET</td></tr><tr><th>Exchange means</th><td>Binary Links</td><td>RESTful Streams via server</td></tr><tr><th>User Interface</th><td>Visual Programming (Grasshopper)</td><td>DesktopUI (WPF)</td></tr><tr><th>Object Model</th><td>Native Rhino (RhinoCommon)</td><td>Speckle Default Objects</td></tr></tbody></table>
<caption>Table 2
Comparison on
technical aspects</caption>

Product Data Management, with feature-based parametric design, in a part/assembly logic (Monedero, 2000). The API provided, Top'ADS, is .NET based and allows for AddIn developments. The two developments are built on top of this API and are coded in C#. The AddIns establish the link to Speckle and Rhino by calling their APIs. A comparative summary is provided in Table 2.

Speckle provides many Software development Kits (SDKs), of which the most popular is .NET based (Introduction | Speckle Docs, 2023). It provides tools to create a Speckle connector for a software of choice. The SDK is part of the SpeckleSharp repository where one also finds the Objects Kit. An object kit is composed by an object model, serving as a reference schema for geometries and built elements, and a set of converters that take care of converting from and to native formats of each software. When creating a connector, one deals with (1) Bindings, establishing a connection with host app (2) Conversion routines of the native elements from and to the schema. Speckle's software architecture is shown in figure 1.

In the case of the Rhino.inside project (mcneel/rhino.inside, 2023), the aim is to be able to launch Rhino in a host software, in this case TopSolid. Technically, this means to be able to load the Rhino Dynamic Link Libraries (DLL) from TopSolid and be able to launch Rhino's main window and Grasshopper window. The link between both environments is achieved through a Grasshopper plugin (a .gha file loaded when Rhino is launched inside TopSolid) that contains the different commands to interact with TopSolid's native objects through Grasshopper's visual programming interface. Similar to Speckle, Rhino's .NET SDK was used, with code written in C#. Figure 2 illustrates Rhino.inside's structure.

## Data conversion:

### A strongly-typed approach

Both plugin developments establish a link between two distinct object models. On a lower technical level, sharing the same framework and programming language offers a common ground for

data types. C# is a strongly-typed, object-oriented programming language. Hence, conversion routines consist of translating elementary built-in data types, such as integral numeric types, floating-point numeric types, Boolean value type and character-based types (Microsoft, 2022).

Native object types for each software data model are defined as a structured combination of the previously mentioned elementary data types. This is the case of classes or structs. A conversion of an object instances from one model to another consists of mapping the different values from one definition to the other, applying the necessary adjustments.

For example, the same NURBS curve in different environments based on its mathematical definition and its implementation in the software model. A parametric curve in a CAD software consists of an equation, an interval and the group of points (Ko and Steinfeld, 2018). A generalization of freeform curves is the NURBS representation. TopSolid uses its geometric kernel, Parasolid, to define a curve object. Rhino has its own geometric kernel where it is defined. For the case of Speckle, the Curve class is only a data model as it has no geometry kernel. The data needed to construct a NURBS curve are control points and Knot vector. Each control point is defined by three numeric values corresponding to its cartesian coordinates, and optionally a fourth value for the weight in case of rational BSplines. Knot vector is a set of numeric values. Some additional

<table><thead><tr><th></th><th>Rhino.inside</th><th>Speckle</th></tr></thead><tbody><tr><td>Framework</td><td>.NET</td><td>.NET</td></tr><tr><td>Exchange means</td><td>Binary Links</td><td>RESTful Streams via server</td></tr><tr><td>User Interface</td><td>Visual Programming (Grasshopper)</td><td>DesktopUI (WPF)</td></tr><tr><td>Object Model</td><td>Native Rhino (RhinoCommon)</td><td>Speckle Default Objects</td></tr></tbody></table>
Boolean properties may be needed, as for whether the curve is rational, periodic, closed, etc. An example of adaptation is the need to fit Rhino's particularity of not storing superfluous knots. These are a repetition of first and last values. Superfluous values are stored in most models, such as for TopSolid and Speckle. The adaptation consists of removing the extra values when converting from TopSolid to Rhino, or inversely adding them.

Hence, the translation of data models consists of sending basic data types, such as numeric values. However, for a correct conversion, some adaptations may be needed. It is necessary to study each representation to establish equivalence between the two models. Also, the philosophy of the API can impact the way an object can be constructed, as it exposes a set of constructors (a mechanism to instantiate classes) and setters to set the different values. If a property is read-only, it cannot be set and is usually not essential to define an object.

## Challenges faced

Both developments faced challenges for the technical implementation, that are detailed in the following paragraphs.

The Speckle Connector implementation consisted of a first technical step, ensuring compatibility and basic functions. It included successfully loading the DLLs and all the dependencies, launching the DesktopUI and connecting to a Speckle Server. The project structure had to evolve to meet the SpeckleSharp structure, by doing a fork of the main repository and working on it, as it usually happens in Open Source. The most exhaustive task was that of coding all the conversion routines needed for the basic geometries and elements, which will have to be completed. Speckle's default object model (scheme) was chosen. Its geometry seems to be aligned with Rhino's geometric object's, such as NURBS (curves and surfaces) and BREPs (Boundary representations); whereas the built elements match Revit's building elements i.e. walls, slabs, beams, etc. Dealing with

the PDM structure in TopSolid consisting of parts/assemblies was crucial. Speckle objects all inherit from the Base class. This allowed for a dynamic way of structuring data and properties in nested Speckle objects. Speckle's philosophy is object-oriented, which means that every Speckle object is serialized and stored as a JSON object on the server, as opposed to file-based approaches.

On the other hand, Rhino.inside approach is all about binary direct links. The main challenge was to get to load the DLLs correctly without error. The second technical challenge was to define a structure for the plugin. Unlike Speckle, there is no provided template by the project maintainer, but rather different instances of Rhino.inside for other software that served as examples. The decision was to follow what has been done in Rhino.Inside.Revit and create the Grasshopper plugin. As explained in Figure 2, the different layers of the software tool developed are (1) TopSolid, as a host software (2) A TopSolid AddIn that, when called, launches Rhino (3) Rhinoceros (4) Grasshopper, as module on top of Rhino (5) a Grasshopper plugin for TopSolid with dedicated custom components. Note that only (2) and (5) are the effective contribution of this project, meanwhile (1), (3) and (4) are already existing. The functionalities present cover (1) Geometry conversion routines between Rhino's Geometry and TopSolid's Parasolid Geometry (2) PDM access to manage different native document types, including parametric families (3) Native TopSolid Operation, driven by Grasshopper. The first category is the most exhaustive and involved complex concepts like BSLine, NURBS and Solid/BRep.

## Main results

The main result is achieving non-file-based interoperability. The technical aspects described above were translated by the successful establishment of two different kinds of workflows, both non-file-based and thus independent of file-formats, by directly interacting with APIs.
Boolean properties may be needed, as for whether
the curve is rational, periodic, closed, etc. An
example of adaptation is the need to fit Rhino's
particularity of not storing superfluous knots. These
are a repetition of first and last values. Superfluous
values are stored in most models, such as for
TopSolid and Speckle. The adaptation consists of
removing the extra values when converting from
TopSolid to Rhino, or inversely adding them.

Hence, the translation of data models consists of
sending basic data types, such as numeric values.
However, for a correct conversion, some adaptations
may be needed. It is necessary to study each
representation to establish equivalence between the
two models. Also, the philosophy of the API can
impact the way an object can be constructed, as it
exposes a set of constructors (a mechanism to
instantiate classes) and setters to set the different
values. If a property is read-only, it cannot be set and
is usually not essential to define an object.

Challenges faced

Both developments faced challenges for the
technical implementation, that are detailed in the
following paragraphs.

The Speckle Connector implementation consisted of a first technical step, ensuring compatibility and basic functions. It included successfully loading the DLLs and all the dependencies, launching the DesktopUI and connecting to a Speckle Server. The project structure had to evolve to meet the SpeckleSharp structure, by doing a fork of the main repository and working on it, as it usually happens in Open Source. The most exhaustive task was that of coding all the conversion routines needed for the basic geometries and elements, which will have to be completed. Speckle's default object model (scheme) was chosen. Its geometry seems to be aligned with Rhino's geometric object's, such as NURBS (curves and surfaces) and BREPs (Boundary representations); whereas the built elements match Revit's building elements i.e. walls, slabs, beams, etc. Dealing with

the PDM structure in TopSolid consisting of
parts/assemblies was crucial. Speckle objects all
inherit from the Base class. This allowed for a
dynamic way of structuring data and properties in
nested Speckle objects. Speckle's philosophy is
object-oriented, which means that every Speckle
object is serialized and stored as a JSON object on
the server, as opposed to file-based approaches.

On the other hand, Rhino.inside approach is all about binary direct links. The main challenge was to get to load the DLLs correctly without error. The second technical challenge was to define a structure for the plugin. Unlike Speckle, there is no provided template by the project maintainer, but rather different instances of Rhino.inside for other software that served as examples. The decision was to follow what has been done in Rhino.Inside.Revit and create the Grasshopper plugin. As explained in Figure 2, the different layers of the software tool developed are (1) TopSolid, as a host software (2) A TopSolid AddIn that, when called, launches Rhino (3) Rhinoceros (4) Grasshopper, as module on top of Rhino (5) a Grasshopper plugin for TopSolid with dedicated custom components. Note that only (2) and (5) are the effective contribution of this project, meanwhile (1), (3) and (4) are already existing. The functionalities present cover (1) Geometry conversion routines between Rhino's Geometry and TopSolid's Parasolid Geometry (2) PDM access to manage different native document types, including parametric families (3) Native TopSolid Operation, driven by Grasshopper. The first category is the most exhaustive and involved complex concepts like BSLine, NURBS and Solid/BRep.

Main results

The main result is achieving non-file-based
interoperability. The technical aspects described
above were translated by the successful
establishment of two different kinds of workflows,
both non-file-based and thus independent of file-
formats, by directly interacting with APIs.
<figure><img src="image_2.png" /><figcaption>Figure 1: Software Architecture of the Speckle Connector</figcaption></figure>

In the case of Speckle, there are many uses enabled by the developed tool (1) Communicating with other AEC software tools thanks to the existing connectors (2) Sending data and visualizing it on the web 3D viewer, independently of the software or even the Operating System (OS), only using a simple web browser (3) Use Git-like versioning techniques, including branching and role attribution. First tests featured sending different geometries to Rhino and Revit via Speckle, as well as receiving the other way around native objects.

Meanwhile, the Rhino.inside enabled distinct workflows (1) Sending Solid Geometries to Rhino, in order to use advanced NURBS techniques to modify them, and eventually sending them back to native TopSolid (2) Pre-visualize Rhino Geometries in TopSolid, which allows for rapid flexible modelling (3) Execute native TopSolid operations from Grasshopper (4) Instantiate parametric families in assemblies from Grasshopper. For (3) and (4), no geometry conversion is done, however, the use of Grasshopper's Data Structures and their potential to automate these operations. Although TopSolid has built-in functionalities for serialization (automation following patterns), Grasshopper brought larger spectre of possibilities.

## DISCUSSION AND PERSPECTIVE

In the first part, a non-exhaustive overview of existing practices was elaborated. In the second part, a practical approach to enhance interoperability,

based on two software developments, was studied. The presented tools are alternatives to the traditional file-based approach. It is worth noting that the development was conditioned by two factors: the accessibility of the APIs with appropriate documentation; as well as the open-source character of the projects used.

In this part, practical implications of the comparison are discussed. The enabled workflows will benefit some users, which is first analysed. Then, a generalization of the methodology of research is elaborated. Finally, perspective and limitations are examined.

## Enabled workflows

The two tools developed are based on open-source projects and are similar to other projects we observed in AEC. The particularity of these two is their transdisciplinary aspect. The choice of a CAD-CAM software as an example was motivated by its strong fabrication-orientated suited to industrial actors collaborating in building projects, a use-case has been rarely addressed in research. Also, another type of users is that of those who design and fabricate non-standard architectural elements, and who target a design-to-fabrication process (Cache and Speaks, 1995; Carpo, 2011). Speckle seamless collaboration serves the first scenario, while Rhino.inside's direct binary link serve the second use-case.
<figure><img src="image_2.png" /><figcaption>Figure 1: Software Architecture of the Speckle Connector</figcaption></figure>

In the case of Speckle, there are many uses enabled by the developed tool (1) Communicating with other AEC software tools thanks to the existing connectors (2) Sending data and visualizing it on the web 3D viewer, independently of the software or even the Operating System (OS), only using a simple web browser (3) Use Git-like versioning techniques, including branching and role attribution. First tests featured sending different geometries to Rhino and Revit via Speckle, as well as receiving the other way around native objects.

Meanwhile, the Rhino.inside enabled distinct workflows (1) Sending Solid Geometries to Rhino, in order to use advanced NURBS techniques to modify them, and eventually sending them back to native TopSolid (2) Pre-visualize Rhino Geometries in TopSolid, which allows for rapid flexible modelling (3) Execute native TopSolid operations from Grasshopper (4) Instantiate parametric families in assemblies from Grasshopper. For (3) and (4), no geometry conversion is done, however, the use of Grasshopper's Data Structures and their potential to automate these operations. Although TopSolid has built-in functionalities for serialization (automation following patterns), Grasshopper brought larger spectre of possibilities.

## DISCUSSION AND PERSPECTIVE

In the first part, a non-exhaustive overview of existing practices was elaborated. In the second part, a practical approach to enhance interoperability,

based on two software developments, was studied. The presented tools are alternatives to the traditional file-based approach. It is worth noting that the development was conditioned by two factors: the accessibility of the APIs with appropriate documentation; as well as the open-source character of the projects used.

In this part, practical implications of the comparison are discussed. The enabled workflows will benefit some users, which is first analysed. Then, a generalization of the methodology of research is elaborated. Finally, perspective and limitations are examined.

## Enabled workflows

The two tools developed are based on open-source projects and are similar to other projects we observed in AEC. The particularity of these two is their transdisciplinary aspect. The choice of a CAD-CAM software as an example was motivated by its strong fabrication-orientated suited to industrial actors collaborating in building projects, a use-case has been rarely addressed in research. Also, another type of users is that of those who design and fabricate non-standard architectural elements, and who target a design-to-fabrication process (Cache and Speaks, 1995; Carpo, 2011). Speckle seamless collaboration serves the first scenario, while Rhino.inside's direct binary link serve the second use-case.
<figure><img src="image_3.png" /><figcaption>Figure 2: Software Architecture of Rhino.inside</figcaption></figure>

Concretely, The Speckle connector allows sending and receiving of building elements modelled in a BIM Software, like Autodesk's Revit or Graphisoft's ArchiCad. The advantage of using Speckle instead of an IFC-based file exchange can be resumed in the following points: (1) The possibility to easily send a selection of elements via Speckle Streams (2) Sending and receiving happens in Real-Time (3) Speckle streams and branching allow to keep track of the different versions and even have different design alternatives (4) Interactive 3D comments and data visualization on the web browser. However, this workflow could not replace IFC, a robust and complete public standard for AEC. For some tasks, other open and free alternatives should be considered for collaboration.

Accordingly, the Rhino.inside works well with a full design-to-fabrication process. The mix and match of the different features can include complex freeform geometries manipulated in Rhino and instantiated in TopSolid for documentation drawings; generation of bill of materials and/or quantities and, most importantly, fabrication code adapted to CNC machines and their post-processors. The other use would be boosting native parametric features and automation in TopSolid, by integrating Grasshopper's visual programming and Data trees. The advantage of this workflow in comparison to file-based uses are: (1) faster and more performant, as links are binary (2) lower risk of data loss on import or export (3) Real-time exchange allow for an

associative parametric workflow (4) Support for metadata (5) direct combination of commands from the two software environments simultaneously.

## Perspective and limitations

Following these first results, formal evaluation of the two tools is needed to assess their performance in applied projects. A full formal evaluation is beyond the scope of this paper. The experiments carried out give answers to some questions and offer a framework to be extended or reproduced. Selected open-source projects are not the only existing solutions, but rather those that correspond to the interoperability needs defined.

On the other hand, there are limitations to the development of open-source means for data exchanges. For example, interoperability via Speckle require connectors for both sending and receiving software, so it also limits the list of interoperable tools, a priori. However, one can develop their own connector if needed, as shown in this study. For the Rhino.inside solutions, it is a rare exception of direct binary links between software tools from different environments and developed by different entities. Open Source projects and standards encourage wider adoption of a standard or technology (Meeker, 2020). Another previously mentioned condition is API accessibility in a popular programming language.
<figure><img src="image_3.png" /><figcaption>Figure 2: Software Architecture of Rhino.inside</figcaption></figure>

Concretely, The Speckle connector allows sending and receiving of building elements modelled in a BIM Software, like Autodesk's Revit or Graphisoft's ArchiCad. The advantage of using Speckle instead of an IFC-based file exchange can be resumed in the following points: (1) The possibility to easily send a selection of elements via Speckle Streams (2) Sending and receiving happens in Real-Time (3) Speckle streams and branching allow to keep track of the different versions and even have different design alternatives (4) Interactive 3D comments and data visualization on the web browser. However, this workflow could not replace IFC, a robust and complete public standard for AEC. For some tasks, other open and free alternatives should be considered for collaboration.

Accordingly, the Rhino.inside works well with a full design-to-fabrication process. The mix and match of the different features can include complex freeform geometries manipulated in Rhino and instantiated in TopSolid for documentation drawings; generation of bill of materials and/or quantities and, most importantly, fabrication code adapted to CNC machines and their post-processors. The other use would be boosting native parametric features and automation in TopSolid, by integrating Grasshopper's visual programming and Data trees. The advantage of this workflow in comparison to file-based uses are: (1) faster and more performant, as links are binary (2) lower risk of data loss on import or export (3) Real-time exchange allow for an

associative parametric workflow (4) Support for metadata (5) direct combination of commands from the two software environments simultaneously.

## Perspective and limitations

Following these first results, formal evaluation of the two tools is needed to assess their performance in applied projects. A full formal evaluation is beyond the scope of this paper. The experiments carried out give answers to some questions and offer a framework to be extended or reproduced. Selected open-source projects are not the only existing solutions, but rather those that correspond to the interoperability needs defined.

On the other hand, there are limitations to the development of open-source means for data exchanges. For example, interoperability via Speckle require connectors for both sending and receiving software, so it also limits the list of interoperable tools, a priori. However, one can develop their own connector if needed, as shown in this study. For the Rhino.inside solutions, it is a rare exception of direct binary links between software tools from different environments and developed by different entities. Open Source projects and standards encourage wider adoption of a standard or technology (Meeker, 2020). Another previously mentioned condition is API accessibility in a popular programming language.
<figure><img src="image_4.png" /><figcaption>Figure 3: Summary of the methodology</figcaption></figure>

## Generalization of the methodology

The findings of this experimentation can be generalized to other operational topics in the architectural practice after the second digital turn. Figure 3 summarizes the findings of the study.

Firstly, the general methodology consists of matching theory and practice by defining a theoretical framework to analyse a particular issue or research problem. The problem is then identified and formulated, before searching for existing solutions and then starting to develop adapted solutions.

Accordingly, another important aspect is the parallel approach, consisting of developing both tools simultaneously. This is the consequence of breaking down the interoperability problem into distinct needs to exchange data, to which adapted solution were envisioned. This top-down methodology can be generalised to most of technology-related research topics in AEC.

Similarly, open-source solutions should be favoured. It seems to be the only approach for software development in AEC that is compatible with the academic engagement for Open Science and Open Standards. In this study, all the authoring tools are proprietary, but exchange solutions were

open-source. Thus, the freedom of data was sought and achieved. If full freedom of the user is sought, as the freedom to run, study, modify and distribute a software requiring access to its source code (GNU, 2022), one should seek open-source authoring tools.

Finally, Open Source rely on community engagement and contribution. The two tools presented are contributions to existing projects: for the Speckle connector, it is an additional connector to the existing set of connectors; for the Rhino.inside developed for TopSolid, it is another instance of the Rhino.inside project. The source code of both solutions will be available on an online freely accessible code repository.

## CONCLUSION

In this study, the interoperability issue in AEC was studied at two times: on the theory level and on practical level. The focus was made on unconventional means to exchange data. The two tools were described in a comparative manner, in relation with the state of the art of interoperability elaborated. The development of two software tools brought answers to existing problems, for the specific case of the link between AEC and industrial engineering, applied to a particular fabrication-oriented software. In both cases direct interoperability was accomplished with no use of physical file exchanges. The larger research project will build on these findings to continue developing these tools.

Actually, in today's practice, it is the new role of design technology specialists in AEC, as superusers, to use code to empower their colleagues in the architectural project (Deutsch, 2019) by exploring new ways of data exchange. This research highlights the importance of software development as a research tool for the architectural practice. Relying on and contributing to Open Source can help AEC escape vendor lock-in and follow the lead of other industries, who succeeded in securing interoperable ecosystems by adopting open standards.
<figure><img src="image_4.png" /><figcaption>Figure 3: Summary of the methodology</figcaption></figure>

## Generalization of the methodology

The findings of this experimentation can be generalized to other operational topics in the architectural practice after the second digital turn. Figure 3 summarizes the findings of the study.

Firstly, the general methodology consists of matching theory and practice by defining a theoretical framework to analyse a particular issue or research problem. The problem is then identified and formulated, before searching for existing solutions and then starting to develop adapted solutions.

Accordingly, another important aspect is the parallel approach, consisting of developing both tools simultaneously. This is the consequence of breaking down the interoperability problem into distinct needs to exchange data, to which adapted solution were envisioned. This top-down methodology can be generalised to most of technology-related research topics in AEC.

Similarly, open-source solutions should be favoured. It seems to be the only approach for software development in AEC that is compatible with the academic engagement for Open Science and Open Standards. In this study, all the authoring tools are proprietary, but exchange solutions were

open-source. Thus, the freedom of data was sought and achieved. If full freedom of the user is sought, as the freedom to run, study, modify and distribute a software requiring access to its source code (GNU, 2022), one should seek open-source authoring tools.

Finally, Open Source rely on community engagement and contribution. The two tools presented are contributions to existing projects: for the Speckle connector, it is an additional connector to the existing set of connectors; for the Rhino.inside developed for TopSolid, it is another instance of the Rhino.inside project. The source code of both solutions will be available on an online freely accessible code repository.

## CONCLUSION

In this study, the interoperability issue in AEC was studied at two times: on the theory level and on practical level. The focus was made on unconventional means to exchange data. The two tools were described in a comparative manner, in relation with the state of the art of interoperability elaborated. The development of two software tools brought answers to existing problems, for the specific case of the link between AEC and industrial engineering, applied to a particular fabrication-oriented software. In both cases direct interoperability was accomplished with no use of physical file exchanges. The larger research project will build on these findings to continue developing these tools.

Actually, in today's practice, it is the new role of design technology specialists in AEC, as superusers, to use code to empower their colleagues in the architectural project (Deutsch, 2019) by exploring new ways of data exchange. This research highlights the importance of software development as a research tool for the architectural practice. Relying on and contributing to Open Source can help AEC escape vendor lock-in and follow the lead of other industries, who succeeded in securing interoperable ecosystems by adopting open standards.
## REFERENCES

van Berlo, L.A.H.M. et al. (2012) 'Collaborative engineering with IFC: new insights and technology', in G. Gudnason and R. Scherer (eds) *9th European Conference on Product and Process Modelling, July 25-27, 2012. Reykjavik, Iceland*. United Kingdom: Routledge Taylor & Francis Group, pp. 811–818.

Björk, B.-C. and Laakso, M. (2010) 'CAD standardisation in the construction industry — A process view', *Automation in Construction, 19*(4), pp. 398–406. Available at: https://doi.org/10.1016/j.autcon.2009.11.010.

Bucher, D. and Hall, D. (2020) 'Common Data Environment within the AEC Ecosystem: moving collaborative platforms beyond the open versus closed dichotomy'. Available at: https://doi.org/10.3929/ETHZ-B-000447240.

Cache, B. and Speaks, M. (1995) *Earth moves: the furnishing of territories*. Cambridge, Mass: MIT Press (Writing architecture).

Carpo, M. (2011) *The alphabet and the algorithm*. Cambridge, Mass: MIT Press (Writing architecture).

Carpo, M. (2017) *The second digital turn: design beyond intelligence*. Cambridge, Massachusetts: The MIT Press (Writing architecture).

Deutsch, R. (2017) 'Understanding Architectural Workflows in Global Practice', *Architectural Design*, 87(3), pp. 56–67. Available at: https://doi.org/10.1002/ad.2174.

Deutsch, R. (2019) *Superusers: design technology specialists and the future of practice*. London; New York: Routledge, Taylor & Francis Group.

Eastman, C.M. et al. (2018) *BIM handbook: a guide to building information modeling for owners, managers, designers, engineers and contractors*. Third edition. Hoboken, New Jersey: Wiley.

GNU (2022) *What is Free Software? - GNU Project - Free Software Foundation*. Available at: https://www.gnu.org/philosophy/free-sw.en.html (Accessed: 29 March 2023).

*Introduction | Speckle Docs* (2023). Available at: https://speckle.guide/dev/ (Accessed: 28 March 2023).

Ko, J. and Steinfeld, K. (2018) *Geometric computation: foundations for design*. London; New York: Routledge.

McNeel & Associates, R. (2022) *Rhino.Inside, www.rhino3d.com*. Available at: https://www.rhino3d.com/features/rhino-inside/ (Accessed: 31 March 2023).

mcneel/rhino.inside (2023) *GitHub*. Available at: https://github.com/mcneel/rhino.inside (Accessed: 28 March 2023).

Meeker, H. (2020) *Open source for business: a practical guide to open source software licensing*. Third edition. North Charleston, SC: CreateSpace Independent Publishing Platform.

Microsoft (2022) *Value types - C# reference*. Available at: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtintypes/value-types (Accessed: 18 June 2023).

Monedero, J. (2000) 'Parametric design: a review and some experiences'.

Poinet, P. (2020) *Enhancing Collaborative Practices in Architecture, Engineering and Construction through Multi-Scalar Modelling Methodologies*. Available at: https://doi.org/10.13140/RG.2.2.25478.73280.

Schenck, D. and Wilson, P.R. (1994) *Information modeling: the EXPRESS way*. New York: Oxford University Press.

Wintour, P. (2020) 'Rediscovering Flux: Lessons for generative design software', *Parametric Monkey*, 3 June. Available at: https://parametricmonkey.com/2020/06/03/rediscovering-flux/ (Accessed: 31 March 2023).
REFERENCES

van Berlo, L.A.H.M. et al. (2012) ‘Collaborative engineering with IFC: new insights and technology’, in G. Gudnason and R. Scherer (eds) *9th European Conference on Product and Process Modelling, July 25-27, 2012. Reykjavik, Iceland*. United Kingdom: Routledge Taylor & Francis Group, pp. 811–818.

Björk, B.-C. and Laakso, M. (2010) ‘CAD standardisation in the construction industry — A process view’, *Automation in Construction, 19*(4), pp. 398–406. Available at: https://doi.org/10.1016/j.autcon.2009.11.010.

Bucher, D. and Hall, D. (2020) ‘Common Data Environment within the AEC Ecosystem: moving collaborative platforms beyond the open versus closed dichotomy’. Available at: https://doi.org/10.3929/ETHZ-B-000447240.

Cache, B. and Speaks, M. (1995) *Earth moves: the furnishing of territories*. Cambridge, Mass: MIT Press (Writing architecture).

Carpo, M. (2011) *The alphabet and the algorithm*. Cambridge, Mass: MIT Press (Writing architecture).

Carpo, M. (2017) *The second digital turn: design beyond intelligence*. Cambridge, Massachusetts: The MIT Press (Writing architecture).

Deutsch, R. (2017) ‘Understanding Architectural Workflows in Global Practice’, *Architectural Design*, 87(3), pp. 56–67. Available at: https://doi.org/10.1002/ad.2174.

Deutsch, R. (2019) *Superusers: design technology specialists and the future of practice*. London; New York: Routledge, Taylor & Francis Group.

Eastman, C.M. et al. (2018) *BIM handbook: a guide to building information modeling for owners, managers, designers, engineers and contractors*. Third edition. Hoboken, New Jersey: Wiley.

GNU (2022) *What is Free Software? - GNU Project - Free Software Foundation*. Available at: https://www.gnu.org/philosophy/free-sw.en.html (Accessed: 29 March 2023).

Introduction | Speckle Docs (2023). Available at: https://speckle.guide/dev/ (Accessed: 28 March 2023).

Ko, J. and Steinfeld, K. (2018) *Geometric computation: foundations for design*. London; New York: Routledge.

McNeel & Associates, R. (2022) *Rhino.Inside, www.rhino3d.com*. Available at: https://www.rhino3d.com/features/rhino-inside/ (Accessed: 31 March 2023).

mcneel/rhino.inside (2023) *GitHub*. Available at: https://github.com/mcneel/rhino.inside (Accessed: 28 March 2023).

Meeker, H. (2020) *Open source for business: a practical guide to open source software licensing*. Third edition. North Charleston, SC: CreateSpace Independent Publishing Platform.

Microsoft (2022) *Value types - C# reference*. Available at: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtintypes/value-types (Accessed: 18 June 2023).

Monedero, J. (2000) ‘Parametric design: a review and some experiences’.

Poinet, P. (2020) *Enhancing Collaborative Practices in Architecture, Engineering and Construction through Multi-Scalar Modelling Methodologies*. Available at: https://doi.org/10.13140/RG.2.2.25478.73280.

Schenck, D. and Wilson, P.R. (1994) *Information modeling: the EXPRESS way*. New York: Oxford University Press.

Wintour, P. (2020) ‘Rediscovering Flux: Lessons for generative design software’, *Parametric Monkey*, 3 June. Available at: https://parametricmonkey.com/2020/06/03/red iscovering-flux/ (Accessed: 31 March 2023).