Toolchains for Interoperable BIM Workflows in a Web-Based Integration Platform

Abstract

The construction industry is characterized by the diversity of its processes, whereby persons involved in changing project communities are confronted with a changing interplay of software applications. Therefore, planning workflows, and especially the exchange of information between stakeholders, need to be formalized. The automation and execution of these workflows go one step further to achieve added value in implementation and project management using building information modeling. For the configuration and execution of collaborative BIM workflows with compatible software products, a framework is conceived and developed that enables the modeling of project-specific workflows by linking individual software tools based on a standardized process notation. The resulting toolchains enable seamless information exchange between applications that integrate an openCDE-compliant web interface. The methodological approach in this paper is a concept implementation, including a proof of concept. For the concept development, a review of the state of the art is conducted, and requirements are analyzed. The concept development comprises data models and API descriptions and includes the concept of a central integration platform. The interaction between workflow management on the platform and the execution of tasks in the software product clients is explained. The implementation of the toolchains on the proposed platform is evaluated in a demonstrator scenario.

1. Introduction

The construction industry is distinguished by the strong diversity of its processes. The use of Building Information Modeling (BIM) offers a digital working method that significantly improves the collaboration of involved actors, and thus also requires a transformation of processes and systems. Established recurring and reusable process flows in the form of so-called BIM use cases are well described in various frameworks [1,2]. Nevertheless, the challenges become apparent during the technical implementation and application, especially regarding interoperability between software tools. Changing construction project participants and the associated different IT systems make a common vendor-neutral data exchange difficult [3]. The exchange of data in non-vendor-neutral formats requires the use of application software from the same vendor by different project partners. These formats reduce information losses due to differing data interpretation. However, this requirement leads to significant project-specific investments in the acquisition of suitable software.

To avoid this, the construction industry mainly uses open file formats, such as Industry Foundation Classes (IFC) or BIM Collaboration Format (BCF). This approach is called openBIM. Although openBIM is increasingly demanded by public clients [4], this open data exchange is not yet sufficiently supported by software products in the Architecture, Engineering, Construction, and Operation (AECO) industry. In addition, file-based data exchange for the collaboration required by the BIM methodology cannot be implemented in a meaningful way in some cases, especially if several participants work collaboratively on building models [5]. An alternative to the file-based exchange is the asynchronous exchange of information via web interfaces. The development and use of web interfaces support the tendency of construction IT products moving toward the cloud. In addition, software is increasingly being offered as a scalable service-on-demand, i.e., customers do not purchase software licenses but use the functionality [5,6,7].

Moreover, the exchange of information via web interfaces is gaining relevance in the construction industry due to their standardization. In this regard, the international standard ISO 19650-1 [8] defines terms and principles for information management with BIM. It contains recommendations for specifying the management, exchange, recording, versioning, and organization of information for involved stakeholders [8]. In addition, the specification DIN SPEC 91391-2 [9] recommends the use of web interfaces for Common Data Environments (CDE) data exchange of different vendors. To improve the data exchange and simplify the connection of software products for developers, the specification also provides a conceptual basis. It sets out the requirements for procedures and structures when exchanging data between two CDEs or between a CDE and another software product [9]. The usage of standardized openCDE-compliant web interfaces may increase the competitiveness of small and medium-sized construction IT product providers. Furthermore, it facilitates market entry, helps to simplify the initialization of construction projects, reduces investment costs, and promotes collaborative working with BIM.

The integration platform developed in the scope of the Software Reference Architecture for openBIM Services (BIMSWARM) project may serve as a central point of contact for information on IT products in the construction industry and corresponding certifications in Germany. An essential core function of the platform is the linking of applications, services and content in common workflows to build holistic digital value chains for BIM-based construction planning, execution and operation, which are subsequently termed toolchains. The user-friendly configuration of such toolchains is ensured by a web user interface called composer. Via an Application Programming Interface (API), client software products can be integrated into these toolchains and interact with the platform. The implementation and use of a Single Sign-On (SSO) guarantees a high security standard. These features are based on the consistent use of standardized and established web technologies, such as Representational State Transfer (REST), Hypertext Transfer Protocol (HTTP), Javascript Object Notation (JSON) and Open-Authorization (OAuth).

This paper provides a concept, implementation and evaluation of a platform-based IT system for the workflow-specific definition of toolchains and the client software integration API for the AECO industry. A methodological approach for the development of a platform infrastructure for modeling and executing product-integrated workflows is presented in the following. The methodology can be described as a concept implementation (proof of concept) as it is classified by Glass et al. [10] for software engineering research. The concept implementation is one of the most used research methods in the information technology and software engineering research domain [10].

The approach in this paper consists of a five-step process (see Figure 1). At the beginning, the process requires consideration of the current technical state of the art (Figure 1 step 1). Therefore, Section 2 provides explicit insight into the representability of BIM-based workflows through the use of industry standards Information Delivery Manual (IDM) and Business Process Modeling and Notation (BPMN). In addition, open standards related to data exchange and web-based collaboration in AECO domain are presented. An overview about the use of platform systems is given. Based on the recognized research gaps and potentials, requirements for interoperable model-based BIM workflows are analyzed in the next step (Figure 1 step 2) The requirements are identified and presented in a structured manner, as denoted in Section 3. Starting from the specified requirements, the concept for the design of the framework was developed (Figure 1 step 3) and is proposed in Section 4. As a requirement for the implementations of toolchains, a data model for AECO software products is specified. Next, a data model for representing product-integrated BIM workflows, the so-called toolchains, is presented. Furthermore, based on REST-based web services, the integration of client software applications and the integration of third party REST APIs is discussed. The SSO for seamless integration of user identities and data security is outlined as well. In Section 5, the concept and its implementation (Figure 1 step 4) is applied on a demo scenario as a proof of concept (Figure 1 step 5). The practical benefits for different stakeholders in construction projects are also discussed. A final summary and further outlook are given in Section 6.

2. State of the Art

The consistent use of the BIM methodology implies the model-based collaboration of all stakeholders involved in the life cycle of a building. However, the current predominance of a file-based information exchange in the AECO domain disrupts the asynchronous model-based collaboration. Meanwhile, the asynchronous exchange of information via web interfaces is gaining importance, as standardization within the AECO domain is advancing in this direction [11]. These web interfaces, also referred to as APIs, are based on the REST paradigm and can be connected to new applications easily. The provision of APIs is a significant advantage for digital platforms, making a platform extensible by providing functionalities to the applications that can consume the programming interface of the platform [12,13]. Digital platforms have a central role in the digitization of traditional value chains. Open platforms offer a high degree of interoperability, flexibility, and portability, having special significance for the value creation [14,15].

After introducing workflow-driven BIM-based collaboration, this chapter gives an overview of web-based exchange, considering the REST paradigm and current standards in the construction industry. In particular, relevant developments from buildingSMART and the open exchange between CDEs using DIN SPEC 91391-2 [9] are discussed.

2.1. Workflow-Driven BIM-Based Collaboration

Use cases and recurring workflows in BIM context are modeled with the industry standards IDM and BPMN [3,16,17,18]. The IDM is an international standardized framework to model the information delivery in BIM-based projects [16]. The BPMN is a standardized non-construction-specific comprehensive framework for modeling business processes of all kinds [19,20]. The IDM framework is well researched for the application of the information delivery [17,18,21] and the specification of information requirements in the construction industry [22]. The relevance of IDM and BPMN in the renovation phase of buildings was also investigated by Armijo et al. [23]. The authors presented these two frameworks as an essential method for openBIM workflows during the reuse of a building. This study revealed that both the interoperability of software solutions and the systematization and structuring of interactions between participants and the information exchange process lead to a higher level of collaboration. Hence, all phases of the building life cycle can benefit from the application of IDM and BPMN, which have a key role for successfully establishing openBIM in construction projects.

Fundamental research on increasing interoperability between software applications, such as design and structural analysis, through the use of BPMN was conducted by Ren and Zhang [24]. The information delivery using BIM is defined in ISO 19650 [8], providing workflows for requesting and delivering information at certain points during the project delivery and asset operation. Applied to CDEs, workflows are proposed providing access rights to the data in certain status types [25]. The status types are Work in Progress, Shared, Published and Archived and the respective workflows, which transfer data from one status to another, require an approval procedure in each case [8]. These workflows are implemented in several CDEs and are also considered in the specification for openCDE DIN SPEC 91391 [9].

2.2. Web Interfaces and Representational State Transfer

The term web interface refers to an API which is available on the internet. Such a programming interface for web applications is usually based on the HTTP and defines a set of documented commands that allows external systems (clients) to interact with the providing system (server). One possibility to map such a command set is the REST [26]. The REST programming paradigm describes a stateless client–server communication that allows machine-readable communication to be established in a defined scheme with encapsulated components [27]. The advantage of using a REST interface is the targeted access to required resources, i.e., a web-based construct that can be addressed by means of a Uniform Resource Identifier (URI) [28]. For access, a request is sent, to which a response is made in a previously defined scheme.

By addressing certain predefined endpoints from any client, the various functions on the resources are invoked to give a specific response, such as retrieving a container in a CDE using HTTP GET [9]. Commonly, HTTP methods are used to specifically request resources without causing changes on the target system (GET), to change an existing resource or to create a new one (PUT), to create a new one under an addressed resource for which no URI exists yet, to receive the URI of the new resource as a response (POST), and to delete a specified resource (DELETE)  [26].

While the relevance of REST interfaces in research, especially in specification, lies in an improvement of discoverability, accessibility, interoperability and reusability [29], in practice, the term RESTful API is coined above all. This means that such an API implements all the requirements of the REST paradigm in the best possible way. One further advantage for both fields of interest is the easy scalability of applications based on the REST paradigm [29]. In addition, REST is also suitable for providing publicly available APIs that give developers web-based access to interact with a web service (e.g., the Twitter API).

2.3. Usage of Web Interfaces and BIM Data Exchange in AECO Industry

The two most important criteria related to the openBIM approach are, as described in Borrmann et al. [1], are the openness and neutrality of data standards. In the AECO industry, buildingSMART acts as a neutral body for the standardization of interfaces and data exchange standards in the field of BIM [30]. Relevant standards, such as the openCDE specification, are further developed, and new ones are being launched by buildingSMART.

For the improvement of interoperability within the AECO software ecosystem, buildingSMART has developed several APIs. A major innovation is the openCDE-API family consisting of the already established BCF-API [31], a new Documents-API [32], and a basic Foundations-API [33]. The basis for the buildingSMART openCDE family is the German national DIN SPEC 91391-2 [9] (also known as the openCDE specification). It is an industry specification for the exchange of data in the context of shared data environments, specified by leading software companies in the field of CDEs. It describes the data exchange needed to synchronize CDEs with other applications, using RESTful API to exchange, store, and manage data with project partners. CDE fulfilling the requirements and API specification by DIN SPEC 91391-2 are denoted as openCDE [9]. The specification standardizes both technical functionalities through the use of data structures and protocols, as well as logical aspects through the use of workflows for data management.

Furthermore, the openCDE specification [9] defines metadata for managing information containers and the inherent information contents in CDEs. It specifies a set of RESTful routes for obtaining the current version of the API, logging in and out, accessing projects, accessing different container types in projects and managing the respective information containers with GET and POST requests. Each time a container is posted, it either creates a new container or a new version of the container. There is no overriding or changing of containers possible according to the specification, which is defined in the versioning concept in DIN SPEC 91391-2 [9]. Furthermore, the specification defines use cases for the usage of the API.

Basic functions of the openCDE-APIs are user management, the authorization and authentication process, as well as filtering, sorting and managing resources. The Foundations-API [33] also includes these basic functions and acts as a foundation for the BCF-API [31] and Documents-API [32]. The uploading and providing of documents can also be used in combination with the functions of the BCF-API. This API specializes the BCF and is used to document project-specific problems that occur during the modeling process of a structure so that they can be solved by project participants in the further course. For this purpose, the BCF-API provides functionalities to create these topics. Further functions are the management of comments, viewpoints and related documents.

Building data, such as objects and processes, are modeled in the IFC schema to provide an open and vendor-neutral format for interoperability between BIM tools [3]. Currently, IFC files are manly exchanged using three data formats, including .ifc in step format, .ifcxml in XML format, and .ifcZIP with the PKzip 2.04 g compression algorithm [34]. The chosen serialization of an IFC file significantly affects the data transfer rate and performance of a system [35]. The study by Afsari et al. [5] on cloud BIM data integration and data exchange has shown that the model-based data exchange is a major challenge and that current methods do not fully exploit the potential of the cloud.

In common web applications, individual services communicate via data serialized either in XML or JSON. The result of previous research studies was that JSON serialized data are processed much faster, and the parsing efficiency is much higher compared to XML [35,36]. In response to these results, Afsari et al. [34] developed an initial approach for serializing IFC files in JSON format. The authors presented a methodology for generating an ifcJSON schema that is validated against both the IFC schema and the JSON schema. Furthermore, a use case was applied to describe how ifcJSON documents can be generated. However, the results were only related to the use case discussed in the paper and the data needed for the study [34].

2.4. Standardization of Information Containers

The specification of the openCDE interface is based on information containers according to DIN EN ISO 19650 [8] (generally) and DIN SPEC 91391-2 [9] (specifically). These information containers achieve an efficient exchange of heterogeneous and interlinked construction data, e.g., for data drops or long-term archiving. In general, information containers are referred to as the interrelated addressable set of data or information in the storage hierarchy of a system [8]. In the context of data transfers, information containers are usually transferred as compressed, structured file archives. An information container can provide a set of metadata and a set of information content according to DIN SPEC 91391-2 [9]. The general openCDE-compliant interface does not specify a specific container format, but also allows for unstructured storage of documents in an information container. More specific and structured information containers can be, for example, the Dutch standardized COINS container [37], the multimodel or BIM-LV container [38], or the Information Container for linked Document Delivery (ICDD) [39]. Extensions of the openCDE interface for specific container types, for instance, using the ICDD container, were analyzed, conceptualized and implemented by Höltgen et al. [39].

With the employment of information containers and, in particular, the ICDD and the Semantic Web technologies utilized in it, decentralized applications and data storage are made feasible for the building life cycle. The stakeholders of projects in the AECO domain are used to operate in a decentralized manner in terms of their location and organization [40]. Therefore, more and more approaches focus on the development of decentralized CDEs [41], considering information containers to comprise heterogeneous information from distributed locations to be accessible for stakeholders [40]. This kind of decentralization is also facilitated by the use of Federated Linked Building Data as a novel approach for the BIM collaboration [42].

3. Requirements Analysis

The research gap is identified from the literature review as the lack of vendor-neutral interoperability [4,23,24] and the need for structured and systematically formalized workflows [18,23]. Moreover, the collaboration between stakeholders focuses on centralized document-based data [5,40], while there is a gap in exchanging information that is decentralized and asynchronous in federated resources [40,42]. Altogether, the construction industry is approaching web applications and web technologies for information exchange [5,6,7] as well as platform ecosystems for BIM collaboration [15,43].

Considering the research gaps and research directions, an analysis of the current user requirements regarding information exchange workflows was conducted. For this purpose, the involved user groups of the toolchain framework were identified. Prior to the identification of technical requirements, challenges in project collaboration and user-centered requirements for interoperable model-based BIM workflows were identified in workshops with experts from the construction industry.

Therefore, several use cases were defined systematically in templates based on the methodology proposed in [44]. These use cases are comprised of three characteristic application scenarios along the building life cycle: (1) model checking regarding the employers information requirements (EIR); (2) model-based cost-estimation; and (3) the legally compliant commissioning of a building. These application scenarios are then decomposed into individual workflows and specified for use in the toolchain framework according to the use case templates and accompanying BPMN diagrams. The developed use cases were presented and evaluated by the project partners as well as by other experts from the AECO industry and were used for the concept development of the toolchain framework. For any further workflows, expert knowledge is supposed to be used for generating further toolchains or for refining the granularity of existing toolchains.

In order to face the identified challenges of the non-formalized process implementation, the consideration of various standards and the combination of software from several vendors, subsequent ideation was started to examine the current state of collaboration more intensively. Considering the standardized method of IDM for formalizing BIM workflows and information exchange (c.f. Section 2), stakeholders in construction projects establish collaboration utilizing BPMN. To directly integrate software products into these workflows, structures are needed that map the interaction of corresponding applications from BPMN and control the underlying processes via a central platform. These structures are called toolchains.

A toolchain is defined as a linkage of software products to common workflows (c.f. Section 1). The term software product subsumes applications, services and content within the presented service infrastructure, with which holistic digital value chains for BIM-based planning, construction, execution and operation can be created.

To ensure the error-free linking of software products, a data model for software products is required that maps all relevant information for such a product. In addition to the versioning of the product, this also includes detailed descriptions of all functions that are offered and the supported import and export formats. A uniform description format is required, especially for the recording of software product functions to enable clear comparability of different software products. Depending on the level of detail of the collected data, an automatic compatibility check can also be performed when creating a toolchain. The workflow mapped in a toolchain should be available within the platform as an executable process. For this purpose, a concept must be developed which represents the communication of the individual components in relation to the process flow. Therefore, a status model is needed to map the process flow. It ensures that in every toolchain iteration state, the status of all software products, which are integrated into the toolchains, is clearly represented in each process step.

In addition to the actual process flow of a toolchain, it is also necessary to define exactly how the data flow between individual software products is to be handled. Based on the technologies examined in Section 2, a container-based structure is suitable for exchanging input and output data between software products. In particular, an openCDE-compliant web interface is to be developed. The usage of such an interface is that the data transfer within a toolchain can be at least semi-automated during the toolchain execution, in particular when services without user interaction are in use. To ensure the security of the data exchanged via this interface and to make the data exchange as seamless as possible, the integration of cross-application authentication is required. For the use of the openCDE and the authentication, the development of a web API is essential with which software products can be embedded in toolchains. To make the connection to this interface as simple as possible, the provision of detailed documentation and the creation of training materials have to be provided. The aggregation of all the above-mentioned functions are integrated within a platform that manages software product data, allows creating and executing toolchains, and handles authentication, all represented in an API.

4. Concept Development

This paper focuses on the conception and technical implementation of reusable BIM workflows. These workflows are supplemented by an open data exchange using the openCDE-compliant web interface. Based on the requirements included in the previous section, in the next step, various aspects of the proposed toolchain concept are established and explained. The basic prerequisite for the modeling toolchains employing different software products is a data model for the software–technical representation of software products and their versions, functions, and interfaces. Subsequently, the data model for the toolchains is presented. The execution of toolchains is described in detail, taking into account the integration of client applications. Finally, the developed concept for the use of third-party APIs and cross-application authentication is explained.

4.1. Data Model for Software Products

Figure 2 shows the developed data model for the products on the platform, which consists of the classes for products in a specific variant and version, product categories, properties, and product-type groups (PTG) in a specific version. The class Product represents software applications as well as web services or content, referenced by the enumeration Category. A relevant aspect of the modeling of software products is the specification of properties using the class roperty. This allows for grouping and filtering of products into entities of the ProductTypeGroup. The PTGs can later be used in workflows as placeholders for any products with comparable functionality, e.g., to replace a product in a toolchain for a specific task with a product with equivalent functions and properties.

A Product is classified by different types of properties: general properties, technical properties, category-specific properties, and PTG-specific properties. General properties must be specified equally for all products on the platform, regardless of their respective product-type groups. Examples for general properties are the product name, and the product or API endpoint route. Technical properties must be specified for all products with regard to be available for the certification of import and export functionalities. This essentially includes the compatibility with interfaces and file formats to further perform a compatibility check for workflows. Category-specific properties must be differentiated for the app, service, and content categories. Required PTG-specific properties must be mandatory captured by the respective product in order to be classified in a specific PTG. Additional optional features can also be specified on a PTG-specific basis.

Compatibility is the ability of two systems or components to exchange information without loss and to use this information in the same context [45]. Using different IT products from various vendors, the collaborative BIM method requires that information can be created and exchanged compatibly. The platform provides information on the supported formats for input and output data of IT products to enable a uniform, transparent source of information for software procurement in AECO industry. The BIMSWARM Composer is used for this purpose, wherein compatibility properties are considered. The basis for the compatibility checks in the Composer are the detailed software product information, provided in the form of compatibility properties, which represent the possible exchange formats. The data structure of the compatibility properties bases on the metadata for documents defined in DIN SPEC 91391-2 [9], in which an internationally standardized media type, a file schema, as well as the version and a subset of a file schema are defined.

The integration of specific IT products within BIM use cases requires a data structure that can map the interaction of the corresponding applications, as well as the decentralized data store, and allows for monitoring the underlying process execution via a central platform. Toolchains represent a process in which applications, services, and content are modeled based on the process steps of, e.g., a BIM use case (see Figure 2).

4.2. Data Model for Toolchains

Toolchains are divided into process steps, referred to as activities (see Figure 3). An activity is characterized by the fact that one (or more) outputs (documents, models, events, etc.) result from this activity. A basic distinction is made between product-neutral and product-specific toolchains. Product-neutral toolchains describe a process for handling a task without particular products being assigned to the respective process steps.

In the case of product-specific toolchains, particular products (as described in Section 4.1) are assigned to the individual process steps. Only product-specific toolchains can be executed, whereby product-neutral toolchains serve as templates. The latter describes the processes and can be used as a starting point for configuring product-specific toolchains by assigning products to each activity.

The graphical notation and the data model of a toolchain (see Figure 2) are based on the BPMN notation. Input data and output data of the activities are defined as data objects. Based on the business process modeling according to BPMN, a toolchain also starts at a start node and ends at an end node. Other toolchains can be referenced at the start and end nodes. Furthermore, activities can run in parallel (Branch–Merge) or certain paths of the toolchain can only be executed under certain conditions (Fork–Join). Criteria for the executability of a toolchain are as follows: (1) Every activity in the toolchain has a product assigned to it. (2) The process flow is complete (consistent start to end, referring to BPMN modeling guidelines) and does not include endless loops. (3) The toolchain is completely configured, i.e., the CDE location is specified and necessary API information (e.g., BCF) is available. However, non-executable toolchains can be used to model abstract BIM use cases.

The data model of the toolchain is defined according to the schematic diagram in Figure 2 and depicted in Figure 4. It provides the classes Toolchain, ToolchainMetadata, and ToolchainItem for toolchain modeling, and its subclasses ActivityItem, StartItem, EndItem, ForkItem, and JoinItem for the specific items (Figure 4, blue boxes). Moreover, the class ProductVersion is referenced from the product data model (see Figure 2) for the relation from an ActivityItem to a ProductVersion (Figure 4, green boxes). For the integration of the Toolchain and ActivityItem to the openCDE-compliant information container, the model contains the classes Container, Content, and FormatType (Figure 4, yellow boxes). To check the compatibility in the toolchain, the import or export FormatType are retrieved from the product and are attached to the respective Contents. This compatibility check then verifies the data flow (incompatible, compatible with restrictions or conversions, or fully compatible) and highlights the individual sections of the toolchain according to a color coding.

The process for creating an ActivityItem in Composer must procedurally specify the following information: (1) name (free text); (2) activity (a characteristic referenced by input and output); (3) PTG via the productTypeReference attribute; (4) product reference to specific product version referring to the productReference attribute. Abstract use cases thus indicate work states on the way to an executable toolchain, where some information is still missing and needs to be added so that finally an execution becomes possible. However, abstract use cases can still be shared with other users of the platform. They are still suitable for describing the processes for a use case without defining certain software applications. The user can then adopt these use cases as the basis for personal toolchains and then fill them with particular products.

When toolchains are executed on the BIMSWARM platform, data are exchanged in information containers. During the initialization, a container, filled with empty content elements according to the configured data flow, is automatically assigned to each toolchain (see Figure 5). These content elements serve as input or output for the data of an activity element and can be filled with files by the corresponding applications in the toolchain.

Subsequent activity elements can load the data from the corresponding content elements, process them, and put them back into the container. After the toolchain has expired, the corresponding container can be completely downloaded so that all editing steps and versioning are also available during the execution of the toolchain.

Thanks to the standardized interface, not only the provided BIMSWARM openCDE-compliant data store, but also all other CDEs implementing this interface, can be used for a toolchain. This means that the information can also be persisted. The data store is also connected to the central authentication of the BIMSWARM platform. In order for toolchains to run seamlessly across different applications, an overarching authentication concept is also provided (see Section 4.7).

Creating, managing, and executing toolchains as well as checking the compatibility of IT products in the platform context requires a user interface that enables users on the platform to configure compatible toolchains without in-depth prior knowledge. The Composer contains a graphical editor for creating toolchains. For ensuring fluent information exchange between IT products in a toolchain, a compatibility check in the Composer is carried out. The precondition for this check is the provision of detailed product information in the form of compatibility properties for the exchange formats or interfaces.

During modeling, it is constantly checked whether the toolchain has a valid configuration. Toolchains can only be executed if the configuration is valid and all activities within the toolchain are related to a particular IT product on the platform. A toolchain can then be executed as often as desired, and the authorized users on the platform can see the status of each activity or the entire execution of the toolchain. For the interaction in the context of a toolchain, a construction IT product must implement the platform API and the openCDE-compliant web interface for data exchange (see Figure 5).

4.3. Transitions of the Toolchain Items Status

Process control in toolchains is performed by the platform. For this purpose, the platform provides a web interface for software applications for docking and querying the information of the toolchains. This interface enables the query of all toolchain templates released for the authenticated user and respective instances.

To be able to control the process, each element in the toolchain is given a status, which is initialized with PENDING. Based on this status, elements are moved to WORKING status and then to either SUCCESS or FAILURE after execution. Elements that are not activity elements, such as branches and unions, are automatically controlled by the platform and advanced based on the status of their predecessors according to the defined status transitions.

Each time the status of an activity element is changed via the web interface, the process control triggers the subsequent elements. Via a query on the web interface, each product can query its own status and notify it to the user accordingly. The process control also ensures that the defined status transition is guaranteed in the toolchain by checking all predecessors for each status change. A reset to the previous status is only possible for the FAILURE status in order to repeat an action. The toolchains facilitate the differentiation of errors during the execution and communication with the process control platform to indicate a FAILURE. Therefore, four types of errors are considered:

• Error type A (technical error): Technically caused error that occurs during processing within a product (e.g., unsupported file format in a converter).
• Error type B (business decision): Technical decision that the process step was not successful and may have to be repeated, or further previous process may have to be repeated (e.g., release of a BIM model is refused by supervisor due to technical errors, i.e., model has to be revised)
• Error type C (connection error): Connection errors that occur during the connection with BIMSWARM (e.g., connection aborts).
• Error type D (internal error): Internal errors that occur within the BIMSWARM platform (e.g., database errors).

The error types A and B are set by the respective product of the ActivityItem via the API call after completion of the activity, i.e., the ItemStatus of the ActivityItem is set to FAILURE, an error message is optionally transmitted via the API so that the failed execution of the activity is comprehensible. Error type C occurs during the request of a client product to the platform, i.e., BIMSWARM does not notice if there is a problem and no change of status is performed. The product usually receives no response at all for its request and has to handle this. In some cases, the response 408 Bad Gateway also refers to issues with the network connection during a request. Error type D occurs internally at BIMSWARM. The requesting application receives an error message in response (e.g., 500 Internal Server Error), and the status remains unchanged. The administrators of BIMSWARM receive a notification that an internal error has occurred.

4.4. Failure of Processes during Toolchain Execution

In case a FAILURE occurs and is reported to the platform, the user has the possibility to restart the toolchain at certain re-entry points via the platform user interface. To restart a toolchain, the user selects the re-entry point into the toolchain in the Composer. It may be necessary to repeat several toolchain items that have already been executed, depending on the origin of the error that ultimately led to the termination. A restart can only be performed when no ToolchainItems are in the WORKING status (see Figure 6, top toolchain), i.e., there are no more running activities in products. This also applies to parallel processes. A re-entry is only possible at toolchain items that are in the SUCCESS or FAILURE states (see Figure 6, bottom toolchain), which are called re-entry points. Re-entry points can be all subtypes of ToolchainItems, e.g., ActivityItems or ForkItems.

In Figure 7, a toolchain with five ToolchainItems is shown with the respective contents in the openCDE-compliant data store. The toolchain failed in the ToolchainItem 4. All contents up to this item are processed to the data store successfully. To retry the failed process, the toolchain is restarted in ToolchainItem 2. When a failed toolchain with already successfully created contents in the openCDE-compliant data store is restarted, the restart point and all subsequent items are given the status PENDING after the reset. Accordingly, ToolchainItem 2, is PENDING (see Figure 7, bottom toolchain). Furthermore, the BIMSWARM platform creates a new version of the container in the openCDE-compliant data store and copies all contents in the container up to the outputs of the restart item (e.g., here, Content 1) into the new version of the container. The versions of the information container are linked to each other in the data model, so that the user can access either version in the data store. Subsequently, processing continues, and the next pending item status can be set to WORKING via the web service and the client application.

4.5. Integration of Client Applications Using REST-Based Web Services

The interaction of IT products with the platform and the openCDE-compliant interface is as shown in Figure 8. The given are an application A, the BIMSWARM platform and the openCDE-compliant data store. In the assumed initial situation, the associated toolchain is already executed all the way to application A. Sending an HTTP GET request from the application A the inquiring party can retrieve all executed toolchains for which application A is ready to start as step ➀. An activity element is ready to start if it is itself in the status PENDING and all predecessor nodes are in the status SUCCESS. Since all requests to the platform are executed attaching the SSO token (see Section 4.7) within the authentication header, the requesting person is already identified. The list of toolchains is filtered according to the running toolchains to which the requesting person was granted access himself or via an organizational affiliation. In application A, depending on the respective implementation, either a toolchain can be selected by the user or a toolchain can be automatically determined for further procedures, for instance, if the list is to be processed in its order.

In the following step ➁, an HTTP PUT request is sent to the platform to change the status of the activity item to WORKING. The status of activity items can be tracked on the platform in the Composer. In step ➂, an HTTP GET query is used to retrieve all metadata for the input data and their resources. Similarly, the query also provides information about the content locations of the output data. With these content locations, the results can be returned into the workflow after the operation is successfully performed in application A. The metadata also contain information about which schema, schema version and schema subset the files to be retrieved are in, and are supplemented with the corresponding media type, so that the data can be optimally processed further.

In step ➃, the openCDE-compliant interface of the data store is used for the first time by retrieving all incoming content elements using HTTP GET on the route {project-root}/ containers/{containerId}/content/{contentId} with the respective ID of the information element. The partial route {project-root} is provided by the platform. The openCDE-compliant data store must therefore be registered as a product on the platform. In the current state of development, only a single data store can be used within a toolchain. In the future, however, different decentralized data stores can also be used within a toolchain for each storage element and networking with each other via the toolchain.

Similarly, in step ➄ the corresponding files are transmitted by means of an HTTP POST request to the routes of the respective outgoing content elements. Based on the metadata in the toolchain and in the information container, it can be clearly identified which outgoing data are necessary and where they must be stored. Thus, the next application can retrieve the information as input data. During these operations, the status of the activity element in the toolchain remains at WORKING.

After all outgoing content elements have been filled, the status can finally be changed to SUCCESS in step ➅. If errors occur during editing in the IT product or during transfer to the openCDE-compliant data store, it is also possible to send the status FAILURE via the REST API, which then signals to the Composer that the toolchain cannot be executed further at a certain point. Resetting to any previous step can be done via the Composer.

4.6. Integration of Third-Party REST-APIs

In addition to the transfer of data via the openCDE-compliant interface, the toolchain also enables the integration of other web-based interfaces, so that data exchange can occur, for example, via the BCF-API [31]. The generic concept of an API registry for each toolchain allows for to provide further standardized web interfaces within a toolchain to optimize collaboration. The toolchain modeler can register APIs and corresponding web services during the modeling step. For instance, the BCF-API can be attached to provide a service for model-based communication, model annotation and reporting. Thus, asynchronous communication between users can take place within a toolchain. To provide insights into IFC model data, an interface for visualizing models parallel to the toolchain execution is specified to attach an instance of a model viewer to the toolchain. This API supports multiple IFC models to be visualized at the same time and a comprehensive manipulation API for setting colors, highlighting, and selecting IFC objects, retrieving metadata and annotations. The visualization API is evaluated in a prototypical implementation in the webVis/instant3DHub [47].

4.7. Seamless Integration of User Identities and Data Security

Executing toolchains with several users in different applications and services requires a comprehensive authentication that can be used in the client applications as well as for platform services. This authentication is conceived through generating a reusable signed access key (token) that can be used for secure authentication in different clients, which is why this method is also referred to as SSO [48]. The BIMSWARM SSO is mainly based on the established OAuth2 workflow [49] according to industry standard RFC 6749 [50] and is provided as an authentication service for all products registered on the platform. Because the token is compliant with JSON Web Tokens and RFC8725 [51], applications can decode the specified data record from the token payload. Identification and access management in toolchains and the data store are done using the encoded user ID. In client applications, the encoded user ID can either be mapped to existing users in the application or a new user can be created. The authenticity of the token can be validated using a public key infrastructure provided by the platform, thus creating a trusted environment between applications. In addition, all platform services accept the signed token and can thus provide API access to toolchains, openCDE-compliant data stores and visualization.

5. Proof of Concept

The presented concept of toolchains and its implementation in the BIMSWARM platform with the integration of the openCDE-compliant web interface is demonstrated in the following proof of concept. A use case is defined for the planning, tendering, and execution of a maintenance task by a building operator. The schematic representation in Figure 9 shows the basic structure of the use case performing seven activities in four different IT products. The data exchange between the IT products is identified and modeled with particular format types.

This maintenance task is defined in the Facility Management (FM)-system (Figure 9a). The order for the maintenance task is generated and transferred using the GAEB DA XML file format to a software application for model-based tendering (Figure 9c. In parallel, the respective IFC file is transferred from the CDE (Figure 9b) into the model-based tendering software. The order is filled with the description and pricing of the maintenance works to create a bill of quantity within the tendering software. Meanwhile, the tendering process takes place, and a craftsman awards the contract for the order. The work items from the bill of quantity are linked to the entities of the IFC model end exchanged in an ICDD container back into the FM-system (Figure 9d) and the CDE for long-term storage. The maintenance tasks are generated as BCF issues in the FM-system based on the linked IFC entities from the ICDD and transferred to the contractor in a facility service app (Figure 9e). After maintenance works are finished, the contractor returns the BCF issues back to the FM-system (Figure 9f) and the CDE (Figure 9g). The status of the maintenance works in the FM-system is updated, and the BCF issues are stored in the CDE to archive the changes related to the building model.

For modeling the toolchain based on the provided use case, the product-type groups FM-operator system, CDE, tendering, awarding, accounting (TAA), and facility service app are used. Having the use case, in the next step, the user can model the toolchain in the Composer (see Figure 10) on an empty canvas. Activities and contents can be modeled using drag-and-drop on the elements from the toolbox in the top-left corner of the canvas. The process flow and data flow can directly be created after placing the activities. Metadata of the toolchain or the toolchain items can be edited. The graphical user interface of the Composer enables to specify the activities from the schematic flow as activities or product type groups and, in the next step, to select particular construction IT products from the BIMSWARM marketplace for the activities. The particular software products chosen for the activities are displayed by their logos and names. Forks and joins are modeled as well per drag and drop. The Composer checks during modeling whether the process flow and the data flow are modeled correctly. The compatibility check based on the data formats to be transferred between the toolchain items is implemented only prototypically so far, but will be implemented into the Composer in the further development.

Based on the defined toolchain, multiple instances of the toolchain can now be created as required, so that the use case can also be executed multiple times in parallel. The products used within the toolchain can interact with the BIMSWARM platform and execute the workflow as shown in the Section 4.2 and Section 4.5. For each data object modeled in the toolchain, a content object in the respective information container in the openCDE-compliant data storage is automatically created.

After creating and executing the toolchain in the Composer (see Figure 10), the JSON Object presented in Listing A1 is produced using the query ➀ from Figure 8. The JSON Object is built regarding the UML diagram in Figure 4 and comprises general information about the toolchain, such as the creator or descriptive metadata. All entities within this object are identified over an id. Moreover, this toolchain object contains the list of toolchain items and their respective configuration, including the successor relation (successors), and the data input (inputContentId) and data output (outputContentIds) associations. Each output content defines additionally a predefined format, referred to via the formatTypeId. The toolchain items have their status and type as well as the reference to a software product (productId) attached.

Furthermore, the JSON object in Listing A1 contains all necessary information to connect to an openCDE compliant data store. Thus, an openCDE container is configured for each toolchain containing the required number of contents. After the container and contents are created according to the toolchain requirements, the unique identifiers of these entities are referred back to the toolchain using the externalId attributes. The base URL to the openCDE compliant data store is provided. According to this information, client applications can receive HTTP GET or send HTTP POST the respective data to the openCDE contents. In the Listing A1 in the Appendix A, only 2 out of a total of 13 toolchain items are depicted, while the rest are left out for brevity.

The evaluation of the toolchain framework is done with multiple users in multiple software applications. Regarding this demonstration use case, RUB Toolchain client is developed for interacting within the toolchain (see Figure 11). The client application is used as one of the IT products executing activities in the toolchain shown in Figure 9e.

The prototypical app retrieves BCF issues from its predecessor, allows changing the status of its corresponding toolchain item to WORKING and SUCCESS, and provides the upload of the BCF issues into the openCDE container for the subsequent applications. In between, the prototype allows changing the content of the BCF issues. This client implementation shows by means of the use case example that powerful apps based on toolchains and the API can be built easily and with less effort.

In this demo scenario, a toolchain with parallel processes and multiple users is proposed. Toolchains can be shared on the platform with a registered user from the same organization, so that the toolchain can also be used as a value chain across organizations. This allows for process-driven BIM collaboration to be established with the use of openCDE-compliant web interfaces within an organization or project. The concept of toolchains and its implementation was demonstrated in application scenarios within the framework of the BIMSWARM research project by project partners from the construction software industry. A client implementation for using the BIMSWARM API as presented in Section 4.5 is available via GitHub [52]. A long-term evaluation of toolchains with real stakeholders on the BIMSWARM platform is in progress and will help to assess the concept and implementation of toolchains quantitatively and qualitatively in the future.

6. Conclusions

This paper proposes a concept for configuring workflows employing construction-specific applications, services, and content within a platform in a compatible and process-oriented manner as so-called toolchains. These resulting toolchains can be reused for several projects across organizations to leverage the BIM value chain. The paper provides a short introduction to technical platform solutions and reviews the usage of open standards and web interfaces in the construction industry. The proposed concept comprises a data structure and an API for reusable toolchains that enable a seamless exchange of information between applications by using the presented openCDE-compliant web interface. The concept is implemented in the context of the BIMSWARM project, and the implementation is demonstrated in this paper as a proof of concept with a use case.

The concept relies on the idea of a centralized platform, that needs to be maintained by a national or vendor-neutral organization. This organization must not only host the platform, but also be able to moderate the core data (products and format types) on the platform. There are still open questions as to whether this organization can be a governmental organization that will expand this platform as data exchange in the construction industry continues to evolve, or how to ensure the operation of the platform for the implementation of toolchains. These questions are addressed in an organizational concept developed in the same research project.

Regarding the concept and implementation of the toolchain framework, there are minor limitations that can be resolved through further research and development. The toolchain concept currently handles a range of gateways from the BPMN framework, except for the parallel gateways. For efficient use, the decision gateway must be implemented in the next step. This would enable software applications to influence the toolchain process not only on the basis of the status reported back, but also on the basis of decision criteria. In addition, this would make it possible to implement iterative workflows, including termination conditions. To simplify the creation of toolchains for users from the construction industry, it would be significant to integrate existing BPMN diagrams via the Composer and to convert them into toolchains. This important improvement requires further development. Moreover, a deeper integration of REST web services for the transfer of IFC models as ifcJSON would further strengthen the integration of model-based workflows on federated (partial) models. For this, the finalization of the development of the ifcJSON format through buildingSMART is necessary.

The presented toolchain framework was successfully demonstrated in this proof of concept. However, a quantitative evaluation of the proposed framework with externally generated stakeholder-specific toolchains will be carried out in future work to retrieve reliable data about the feasibility of the framework. Significant added value is generated by integrating web services and enabling software vendors to easily network their products on the platform. According to the current methodology of formalizing information exchanges using the IDM framework and BPMN diagrams, this approach combines the current status quo and the technical integration of toolchains with software products for establishing vendor-neutral executable BIM workflows. Moreover, it enables the software tools of small and medium-sized enterprises in the AEC Software Market to be interconnected and compatible with other software products and, therefore, gain more visibility in the software market. The usage of cross-software workflows within the presented toolchains makes it easy to add further functionalities to existing workflows.

It would advance the collaboration between industry and academia concerning the definition and refinement of BIM use cases (e.g., described by buildingSMART in their Use Case Management Service), and the identification of the development needs relating to software products, interfaces, formats, and standards in the BIM domain. The paper presents the growing relevance of web interfaces and cloud solutions for digital collaboration in the construction industry. Overall, the implemented exchange of information via the openCDE-compliant web interface promotes the dissemination and implementation of the openBIM idea. The proposed platform can support the discovery of openBIM solutions and their linking to executable toolchains, facilitating a continuous, openBIM-capable workflow.