Techniques for decoupling access to infrastructure models

Abstract

In an example embodiment, technology is provided for decoupling user access to an infrastructure model from proprietary software that maintains and updates the infrastructure model. A back-end application may include an infrastructure modeling back-end module, which, among other functions, handles communications with an infrastructure modeling front-end module of a front-end application that provides user access to the infrastructure model, an infrastructure modeling hub service that maintains a repository of infrastructure models, and an infrastructure modeling native module that creates, performs operations on, and updates a local instance of a database that stores the infrastructure model. Although the infrastructure modeling back-end module can pass information obtained from the infrastructure modeling front-end module and the infrastructure modeling hub service to the infrastructure modeling native module, it can be functionally separated from the software of the infrastructure modeling native module that understands how to maintain and update the infrastructure model (including interacting with the local instance of the database).

Description

Background Art

[0001] Technical Field

[0002] The present disclosure relates generally to infrastructure modeling, and more particularly to a software architecture for granting distributed user access to an infrastructure model.

[0003] Background Information

[0004] Throughout the design, construction, and operation of infrastructure (e.g., buildings, factories, roads, railways, bridges, power and communication networks, etc.), it is often desirable to model the infrastructure using infrastructure modeling applications. Infrastructure modeling applications have traditionally used a variety of different technologies and data formats to maintain infrastructure descriptions at different stages of a project. In the past, infrastructure information maintained according to such formats was disjoint and included a large number of data redundancies, inconsistencies, and other sources of inefficiency. Models may have been optimized and adapted for specific use cases, often without considering other stages of an infrastructure project, resulting in distinct product / prescription / stage data silos and disconnected workflows.

[0005] Recently, systems have been developed that can break down such existing product / prescription / stage data silos and enable the generation of true "digital twins" of real-world infrastructure that describe various aspects of the infrastructure in a more unified manner. The generation of such "digital twins" addresses many of the limitations of traditional infrastructure modeling techniques. However, this also leads to new technical challenges. These challenges include the following questions: how to enable distributed user access to infrastructure models from multiple different sources while providing high performance (e.g., in terms of network bandwidth, processing load, etc.) and ensuring security. Therefore, improved techniques are needed to grant distributed user access to infrastructure models while addressing these issues. Summary of the invention

[0006] In an example embodiment, a technique for decoupling user access to an infrastructure model from proprietary software that maintains and updates the infrastructure model is provided. A back-end application may include an infrastructure modeling back-end module, which, among other functions, handles communications with an infrastructure modeling front-end module of a front-end application that provides user access to the infrastructure model, an infrastructure modeling hub service that maintains a repository of the infrastructure model, and an infrastructure modeling native module that creates, performs operations (e.g., inserts, deletes, and queries models, elements, attributes, etc.) on a local instance of a database storing the infrastructure model, and updates (e.g., applies a change set to) the local instance. Although the infrastructure modeling back-end module may pass information obtained from the infrastructure modeling front-end module and the infrastructure modeling hub service to the infrastructure modeling native module, it may be functionally separated from the software of the infrastructure modeling native module that understands how to maintain and update the infrastructure model (including interacting with the local instance of the database). Such an arrangement may allow the development of a variety of customized back-end applications, the deployment of which may reduce network bandwidth consumption, provide load (e.g., processing load) balancing and other benefits, while increasing security by functionally separating the software that maintains and updates the infrastructure model from the rest of the software of the back-end application.

[0007] It should be understood that various additional features and alternative embodiments may be implemented in addition to those discussed in this summary. This summary is intended to simply serve as a brief introduction to the reader and does not indicate or imply that the examples mentioned herein cover all aspects of the disclosure or are essential or necessary aspects of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following description refers to the accompanying drawings of example embodiments, in which:

[0009] Figure 1 is a high-level block diagram of an example infrastructure modeling software architecture that decouples user access to an infrastructure model from proprietary software that maintains and updates the infrastructure model;

[0010] Figure 2 is a flowchart of an example sequence of steps for opening an infrastructure model;

[0011] Figure 3 is a flow chart of an example sequence of steps for shutting down an infrastructure model;

[0012] Figure 4 is a flow chart of an example sequence of steps for inserting an element into an infrastructure model;

[0013] Figure 5is a flow chart of an example sequence of steps for retrieving element properties from an infrastructure model; and

[0014] Figure 6 is a flowchart of an example sequence of steps for querying an infrastructure model. DETAILED DESCRIPTION

[0015] definition

[0016] As used herein, the term "infrastructure" refers to physical structures or objects that have been built or are planned to be built in the real world. Examples of infrastructure include buildings, factories, roads, railways, bridges, power and communication networks, etc.

[0017] As used herein, the term "built infrastructure schema" or "BIS" refers to a type of conceptual schema (ie, conceptual data model) that describes the semantics of data representing an infrastructure.

[0018] As used herein, the term "infrastructure model" refers to a digital representation of an infrastructure. An infrastructure model may be organized according to a pattern of constructed infrastructure. One specific type of infrastructure model may be an iModel® infrastructure model.

[0019] As used herein, the term "infrastructure modeling repository," or simply "repository," refers to a distributed database that stores one or more infrastructure models. Each materialized view of such a distributed database may be referred to as a "briefcase," as discussed below.

[0020] As used herein, the term "change set" refers to a persistent electronic record that captures the changes required to transform a particular instance of a database from one version to a new version. As explained below, in an example implementation, an ordered series of change sets can represent a timeline. The change sets of a timeline can capture the changes required to move a database instance from one version (version M) to another version (version Q). The change sets can be applied in a sequential order to move version M to version Q. The change sets can also be applied in a reverse sequential order to move version Q back to version M.

[0021] As used herein, the term "briefcase" refers to a specific instance of a database. In an example implementation, a briefcase can represent a materialized view of information of a specific version of a repository. One version of a briefcase (version M) can be considered to be the information resulting from sequentially applying all changesets (up to and including changeset M) to a "baseline" briefcase (e.g., an empty "baseline" briefcase). A briefcase of version M can be moved to another version (version Q) by applying to it a set of changesets from N to Q (inclusive).

[0022] As used herein, the term "element" refers to a record maintained in a briefcase. An element represents (ie, "models" in the colloquial sense of the term) an entity in the real world. In an example implementation, an entity in the real world may be a single unit of infrastructure.

[0023] As used herein, the term "model" refers to a container for a set of elements that collectively represent (i.e., "model" in the colloquial sense of the term) a real-world entity. In an example implementation, the real-world entity may be a single unit of infrastructure. In some cases, models may be nested. That is, a model is said to "break down" a particular element into more fine-grained descriptions (i.e., descriptions that describe the same real-world entity but at a finer granularity).

[0024] As used herein, the term "relationship" refers to a connection involving two or more elements or models. Examples of relationships include parent-child relationships, which may imply ownership, and peer relationships, which may define a group.

[0025] Example Embodiments

[0026] Figure 1 1 is a high-level block diagram of an example infrastructure modeling software architecture 100 that decouples user access to an infrastructure model (e.g., an iModel® infrastructure model) from proprietary software 140 that maintains and updates the infrastructure model. The architecture can be divided into client-side software 110 that executes on one or more computing devices provided locally to an end user (collectively, "client devices") and cloud-based software 112 that executes on one or more computing devices provided remotely from the end user (collectively, "cloud computing devices") and is accessible via a network (e.g., the Internet). The client-side software 110 may include a web front-end application 120 that operates within a virtual environment (e.g., a "browser sandbox") provided by a web browser 124 (e.g., a Chrome® web browser) and a desktop front-end application 122 that operates directly under an operating system and a back-end application 132 that interacts therewith. The cloud-based software 112 may include an infrastructure modeling hub service (e.g., an iModelHub™ service) 142 and a back-end application 130 that interacts with the web front-end application 120. At least the infrastructure modeling hub service 142 and portions of the backend applications 132 that operate to maintain and update infrastructure models may be considered proprietary software 140 .

[0027] The core of the cloud-based software 112 can be an infrastructure modeling hub service 142, which manages a repository 144-146 that includes briefcases that store infrastructure models. Briefcases 152 in the repository 144-146 can start as empty "baseline" briefcases that are programmatically generated and persisted by the infrastructure modeling hub service 142. The repository 144-146 can be modified by accepting new change sets into the collection of accepted change sets 147. As the number of change sets in the collection of accepted change sets 147 grows, the time required to obtain an empty "baseline" briefcase and apply all the change sets required to transform it into a briefcase under a specific version (e.g., the "most recent version") may grow larger. For this reason, the infrastructure modeling hub service 142 can create additional "snapshot" briefcases 152 under different versions. When a specific version of a briefcase is needed (eg, a "most recent version"), the briefcase 152 closest to such a version is accessed (which may be a "snapshot" briefcase), and changesets (or reverse changesets) from collection 147 are applied until the desired version of the briefcase is obtained.

[0028] The infrastructure model maintained in the briefcase 152 of the repository 144-146 can be defined using a conceptual schema (e.g., BIS) and stored using an underlying database schema (e.g., SQlite schema). The conceptual schema can describe the infrastructure using digital objects including elements, models, and relationships, which are used as building blocks of the infrastructure model. Elements represent (i.e., "models" in the colloquial sense of the term) entities in the real world. Based on the properties of the modeled entity, an element can be a "leader" element. Other elements are usually inversely related to the leader element. The model acts as a container for a collection of elements, where the collection of elements collectively represents (i.e., "models" in the colloquial sense of the term) entities in the real world. In some cases, models can be nested. That is, the model is said to "decompose" a specific element into a more refined granular description. Models can be arranged according to a model hierarchy to support modeling from multiple perspectives. A single repository model can be used as the root of a model hierarchy. A relationship involves two or more elements or models. Examples of relationships include parent-child relationships that can imply ownership and peer relationships that can define groups.

[0029] The underlying database schema may describe how objects are stored in individual rows of tables of the underlying database. The objects may be maintained using multiple rows of multiple different tables storing object attributes. For example, the attributes of an element may be spread across multiple rows of multiple tables. To create, remove, or modify an object, a primitive database operation, such as insert, delete, or update, is performed on the appropriate row of the appropriate table.

[0030] The infrastructure modeling hub service 142 can be called by multiple other services in the cloud that perform information management and other functions. For example, the information management service 152 can manage asset data, project data, reality data, Internet of Things (IoT) data, code, and other features. In addition, the bridge service 154 uses a source format specific bridge 156 that knows how to read and interpret source data in traditional formats to allow interoperability with traditional data sources (not shown), incrementally aligning data. A variety of additional services (not shown) can also be provided and call the infrastructure modeling hub service 142 or otherwise interact with it.

[0031] In order to grant access to the infrastructure models maintained in the briefcases 152 and changesets 147 of the repositories 144-146, backend applications 130, 132 may be provided. As mentioned above, some backend applications 130 may be located in the cloud as part of the cloud-based software 112, while other backend applications may be located on the client device as part of the client-side software 110. The backend applications 130, 132 may maintain local briefcases 138 and the changesets required to transform them into the desired versions. Each backend application 130, 132 may include functionality for interacting with and servicing requests from the frontend applications 120, 122, calling the infrastructure modeling hub service 142, and creating and performing operations on the local briefcase 138 (e.g., inserting, deleting, and querying models, elements, and attributes of the local briefcase 138, applying changesets to the local briefcase 138, etc.). Such functionality may be implemented by an infrastructure modeling backend module (e.g., iModel.js backend module) 134 (e.g., written in JavaScript or another language) and an infrastructure modeling native module (e.g., iModel.js native module) 136 (e.g., written in C++ or another language). The infrastructure modeling backend module 134 may handle functionality related to interacting with and servicing requests from the frontend applications 120, 122 and calling the infrastructure modeling hub service 142, but does not understand how to create and perform operations on the local briefcase 138 storing the infrastructure model (e.g., inserting, deleting, and querying models, elements, and attributes of the local briefcase 138, applying changesets to the local briefcase 138, etc.). The infrastructure modeling native module may be relied upon to handle this functionality.

[0032] The front-end applications 120, 122 may be primarily concerned with providing a user interface and enabling user interaction with the infrastructure model. As mentioned above, some front-end applications may be web front-end applications 120 operating within a virtual environment (e.g., a "browser sandbox") provided by a web browser (e.g., a Chrome® web browser) 124 on a client device, while other front-end applications may be desktop front-end applications 122 executed as standalone applications that interact directly with the operating system of the client device. The desktop front-end applications 122 may include embedded web browser code (e.g., Chromium® embedded web browser code) 126 to allow them to interact with back-end applications 132 in a manner similar to the web front-end applications 120. The front-end applications 120, 122 may utilize an infrastructure modeling front-end module (e.g., an iModel.js front-end module) 128 (e.g., written in JavaScript or another language) to send requests to and process responses from an infrastructure modeling back-end module (e.g., an iModel.js back-end module) 134. Depending on whether the front-end application 120, 122 is a web front-end application 120 or a desktop front-end application 122, the requests and responses may be sent differently. In the case of a web front-end application 120, communication may be via a network protocol (e.g., Hypertext Transfer Protocol (HTTP)) to an infrastructure modeling back-end module (e.g., iModel.js back-end module) 134 of a back-end application 130 located in the cloud as part of the cloud-based software 112. In the case of a desktop front-end application 122, communication may be via inter-process communication (IPC) to an infrastructure modeling back-end module (e.g., iModel.js back-end module) 134 of a back-end application 132 located on a client device as part of the client-side software 110.

[0033] In operation, the infrastructure modeling software architecture 100 functions to decouple user access to the infrastructure model from the proprietary software 140 structure that maintains and updates the infrastructure model. In particular, while the infrastructure modeling backend module (e.g., iModel.js backend module) 134 can pass information obtained from the infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 and the infrastructure modeling hub service 142 to the infrastructure modeling native module, which is used to create and perform primitive operations on the briefcase (e.g., insert, delete, and query models, elements, and attributes of the briefcase, apply changesets to the briefcase, etc.), the infrastructure modeling backend module itself may not understand how to maintain the briefcase and how to interact with the briefcase, and it is functionally isolated from the briefcase. Such an arrangement can allow the development of a variety of customized backend applications 130, 132, the deployment of which can reduce network bandwidth consumption, provide load balancing and other benefits, while increasing security by functionally separating the software that understands how to interact with the briefcase from the rest of the backend application.

[0034] Figure 22 is a flow chart of an example sequence of steps 200 for opening an infrastructure model. Such operations may be used to obtain a materialized view of an infrastructure model from a repository 144-146 for storage in a briefcase 138. At step 205, the infrastructure modeling backend module (e.g., iModel.js backend module) 134 of the backend application 130, 132 receives a request to open an infrastructure model via the infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 of the frontend application 120, 122. In response, at step 210, the infrastructure modeling backend module 134 pulls down any relevant changesets 147 from the infrastructure modeling hub service 142 and provides them to the infrastructure modeling native module 136. At step 215, the infrastructure modeling native module 136 applies the changesets to a baseline briefcase (e.g., an empty briefcase or a snapshot briefcase) database to produce a local briefcase 138. At step 220, it returns a status to the infrastructure modeling backend module 134. At step 225, the infrastructure modeling backend module 134 may abort in an error state or continue in a success state. At step 230, the infrastructure modeling backend module 134 calls the infrastructure modeling native module 136 to open the local briefcase 138. At step 235, the infrastructure modeling native module 136 opens the local briefcase 138 and, at step 240, returns a status to the infrastructure modeling backend module 134. At step 245, the infrastructure modeling backend module 134 may abort in an error state or continue in a success state. At step 250, the infrastructure modeling backend module 134 calls the infrastructure modeling native module 136 to obtain properties. At step 255, the infrastructure modeling native module 136 performs a query on the local briefcase 138 to populate an object (e.g., a JavaScript Object Notation (JSON) object or another type of object) with the proper values ​​and, at step 260, returns the object to the infrastructure modeling backend module 134. Thereafter, at step 265, the infrastructure modeling backend module 134 returns information from the object to the front-end application 120, 122.

[0035] Figure 3300 is a flow chart of an example sequence of steps for closing an infrastructure model. Such operations may be used to close a local briefcase 138. At step 305, the infrastructure modeling backend module (e.g., iModel.js backend module) 134 of the backend application 130, 132 receives a request to close the infrastructure model via the infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 of the frontend application 120, 122. In response, at step 310, the infrastructure modeling backend module 134 calls the infrastructure modeling native module (e.g., iModel.js native module) 136 to close the local briefcase 138. At step 315, the infrastructure modeling native module 136 closes the local briefcase 138 and, at step 320, returns a confirmation to the infrastructure modeling backend module 134. At step 325, the infrastructure modeling backend module 134 optionally clears any relevant information of the briefcase from its local storage. Thereafter, at step 330, the infrastructure modeling backend module 134 returns a confirmation response to the frontend application 120, 122 via the infrastructure modeling frontend module 128.

[0036] Figure 44 is a flow chart of an example sequence of steps 400 for inserting an element into an infrastructure model. At step 405, the infrastructure modeling backend module (e.g., iModel.js backend module) 134 of the backend application 130, 132 receives a request to insert a new element having one or more attributes via the infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 of the frontend application 120, 122. At step 410, the infrastructure modeling backend module 134 serializes the attributes into an attribute string (e.g., a JSON string). In response, at step 415, the infrastructure modeling backend module 134 calls the infrastructure modeling native module (e.g., iModel.js native module) 136 to insert the element, providing the attribute string. In response to the call, at step 420, the infrastructure modeling native module 136 parses the attribute value from the attribute string, and at step 425, initializes the element structure from the attribute value. At step 430, the infrastructure modeling native module 136 binds the value from the element structure to a database statement (e.g., an SQL INSERT statement), and at step 435, executes the database statement on the local briefcase 138. The statement may create a new row in the database for the inserted element, and such a new row may be stored in the changeset. At step 440, the infrastructure modeling native module 136 retrieves an identifier (e.g., ElementId) for the newly inserted row, and at step 445, serializes the identifier in an identifier string (e.g., a JSON string). At step 450, it returns the identifier string to the infrastructure modeling backend module 134. At step 455, the infrastructure modeling backend module 134 deserializes the identifier string, and at step 460, returns an object (e.g., a JavaScript object or another type of object) to the frontend application 120, 122 via the infrastructure modeling frontend module 128.

[0037] Figure 51 is a flow chart of an example sequence of steps 500 for retrieving element properties from an infrastructure model. At step 505, an infrastructure modeling backend module (e.g., iModel.js backend module) 134 of a backend application 130, 132 receives a request for obtaining element properties of an infrastructure model element via an infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 of a frontend application 120, 122. The request includes an identifier of the element. In response, at step 510, the infrastructure modeling backend module 134 serializes the identifier into an identifier string (e.g., a JSON string), and at step 515, calls an infrastructure modeling native module (e.g., iModel.js native module) 136 to provide the identifier string. In response to the call, at step 520, the infrastructure modeling native module 136 resolves an identifier (e.g., ElementId) from the identifier string, and at step 525, performs a query on the briefcase 138 for an element including the identifier (e.g., ElementId). At step 530, it loads the element structure from the query result, and at step 535, serializes at least a portion of it in a result string (e.g., a JSON string). At step 540, the infrastructure modeling native module 136 returns the result string to the infrastructure modeling backend module 134. At step 545, the infrastructure modeling backend module 134 deserializes the result string into an object (e.g., a JavaScript class or other type of class defined in time). At step 550, the infrastructure modeling backend module 134 returns the object to the front-end application 120, 122 via the infrastructure modeling front-end module 128.

[0038] Figure 66 is a flow chart of an example sequence of steps 600 for querying an infrastructure model. In step 605, the infrastructure modeling backend module (e.g., iModel.js backend module) 134 of the backend application 130, 132 receives a request for querying an infrastructure model via the infrastructure modeling frontend module (e.g., iModel.js frontend module) 128 of the frontend application 120, 122. The request includes a query statement and a binding. In response, in step 610, the infrastructure modeling backend module 134 calls the infrastructure modeling native module (e.g., iModel.js native module) 136, providing the query statement. In response to the call, in step 615, the infrastructure modeling native module 136 prepares a database statement (e.g., SQL SELECT statement) for the local briefcase 138, and in step 620, returns a status to the infrastructure modeling backend module 134. In step 625, the infrastructure modeling backend module 134 can abort in an error state, or continue in a successful state. In step 630, the infrastructure modeling backend module 134 calls the infrastructure modeling native module 136 that provides the binding. At step 635, the infrastructure modeling native module 136 binds the values ​​from the binding into a database statement (e.g., a SQL SELECT statement), and at step 640, returns a status to the infrastructure modeling backend module 134. At step 645, the infrastructure modeling backend module 134 may abort in an error state, or continue in a success state. At step 650, the infrastructure modeling backend module 134 calls the infrastructure modeling native module 136 to get the result of the query. At step 655, the infrastructure modeling native module 136 executes the database statement on the local briefcase 138, and at step 660, constructs an object (e.g., a JSON object) from the result, which is returned to the infrastructure modeling backend module 134 at step 665. At step 670, the infrastructure modeling backend module 134 returns the object to the front-end application 120, 122 via the infrastructure modeling front-end module 128.

[0039] In summary, user access to the infrastructure model is decoupled from proprietary software that maintains and updates the infrastructure model. It should be understood that a variety of adaptations and modifications can be made to the technology. In addition, in general, the functions can be implemented in software, hardware, or various combinations thereof. The software implementation may include electronic device executable instructions (e.g., computer executable instructions) stored in a non-transitory electronic device readable medium (e.g., a non-transitory computer readable medium), such as a volatile memory, a persistent storage device, or other tangible medium. The hardware implementation may include logic circuits, application specific integrated circuits, and / or other types of hardware components. In addition, the combined software / hardware implementation may include both electronic device executable instructions stored in a non-transitory electronic device readable medium, and one or more hardware components. Most importantly, it should be understood that the above description is meant to be considered only as an example.

Claims

1. A method for decoupling user access to an infrastructure model from software that maintains and updates the infrastructure model, comprising: obtaining, by an infrastructure modeling backend module of a backend application executed on a client device or one or more cloud computing devices, information related to the infrastructure model; Determining, by the infrastructure modeling backend module, a need to perform an operation on the infrastructure model based on the obtained information; The infrastructure modeling backend module calls the infrastructure modeling native module of the backend application describing the operation; and The operation is performed by the infrastructure modeling native module on a local instance of a database storing the infrastructure model, the operation comprising at least one of: inserting into the local instance of the database storing the infrastructure model, deleting from the local instance of the database storing the infrastructure model, or querying the local instance of the database storing the infrastructure model for its model, element or attribute, or applying one or more change sets to the local instance of the database storing the infrastructure model, wherein the infrastructure modeling backend module lacks the ability to interact with the local instance of the database storing the infrastructure model and the infrastructure modeling native module has the ability to interact with the local instance of the database storing the infrastructure model, and the infrastructure modeling backend module is functionally separated from the infrastructure modeling native module.

2. The method according to claim 1, further comprising: Based on the operations performed, a response is returned from the infrastructure modeling native module to the infrastructure modeling backend module, which response can be used to update the display of the infrastructure model.

3. The method according to claim 1, further comprising: Invoking, by the infrastructure modeling backend module, an infrastructure modeling hub service executing on one or more cloud computing devices to obtain one or more change sets from a repository applicable to a local instance of a database; providing, by the infrastructure modeling backend module, the one or more changesets to the infrastructure modeling native module; and The one or more change sets are applied by the infrastructure modeling native module to the local instance of the database to update the local instance.

4. The method according to claim 1, wherein: The need to perform the operation is based on receipt of a request from an infrastructure modeling front-end application executing on a client device that provides a user interface for user interaction with the infrastructure model.

5. The method according to claim 4, wherein: The infrastructure modeling front-end module is part of a web front-end application executed within a web browser on the client device, and the infrastructure modeling back-end module is part of a back-end application on the one or more cloud computing devices.

6. The method according to claim 4, wherein: The infrastructure modeling front-end module is part of a desktop front-end application on a client device including an embedded web browser, and the infrastructure modeling back-end module is part of a back-end application on the client device.

7. The method according to claim 1, wherein: The operation is to open an infrastructure model.

8. The method according to claim 1, wherein: The operation is to insert an element into the infrastructure model.

9. The method according to claim 1, wherein: The operation is to retrieve properties of elements of an infrastructure model.

10. The method according to claim 1, wherein: The operation is to generate a database query for an instance of a database storing an infrastructure model.

11. A non-transitory electronic device readable medium having stored thereon instructions, the instructions being configured when executed by one or more processors of a client device or one or more cloud computing devices to: The infrastructure modeling backend module of the backend application obtains information related to the infrastructure model; Determining, by the infrastructure modeling backend module, a need to perform operations on the infrastructure model based on the obtained information; The infrastructure modeling native module describing the operation is called by the infrastructure modeling backend module; and The operation is performed by the infrastructure modeling native module on a local instance of a database storing the infrastructure model, the operation comprising at least one of the following: inserting into the local instance of the database, deleting from the local instance of the database, or querying the local instance of the database for its model, element or attribute, or applying one or more change sets to the local instance of the database, in, The infrastructure modeling backend module lacks the ability to interact with the local instance of the database storing the infrastructure model and the infrastructure modeling native module has the ability to interact with the local instance of the database storing the infrastructure model, and the infrastructure modeling backend module is functionally separated from the infrastructure modeling native module.

12. The non-transitory electronic device readable medium of claim 11, further comprising instructions, which when executed are configured to: Based on the operations performed, a response is returned from the infrastructure modeling native module to the infrastructure modeling backend module, which response can be used to update the display of the infrastructure model.

13. The non-transitory electronic device readable medium of claim 11 , further comprising instructions that when executed are configured to: Invoking, by the infrastructure modeling backend module, an infrastructure modeling hub service executing on one or more cloud computing devices to obtain one or more changesets from a repository applicable to a local instance of a database; providing, by the infrastructure modeling backend module, the one or more changesets to the infrastructure modeling native module; and The one or more change sets are applied by the infrastructure modeling native module to the local instance of the database to update the local instance.

14. The non-transitory electronic device readable medium according to claim 11, wherein: The need to perform the operation is based on receipt of a request from an infrastructure modeling front-end application on a client device that provides a user interface for user interaction with the infrastructure model.

15. The non-transitory electronic device readable medium according to claim 14, wherein: The infrastructure modeling front-end module is part of a web front-end application executed within a web browser on the client device, and the infrastructure modeling back-end module is part of a back-end application on the one or more cloud computing devices.

16. The non-transitory electronic device readable medium according to claim 14, wherein: The infrastructure modeling front-end module is part of a desktop front-end application on the client device including an embedded web browser, and the infrastructure modeling back-end module is part of a back-end application executing on the client device.

17. The non-transitory electronic device readable medium according to claim 11, wherein: The operation is to open the infrastructure model.

18. The non-transitory electronic device readable medium according to claim 11, wherein: The operation is to insert an element into the infrastructure model.

19. The non-transitory electronic device readable medium according to claim 11, wherein: The operation is to retrieve properties of elements of an infrastructure model.

20. The non-transitory electronic device readable medium of claim 11, wherein: The operation is to generate a database query against an instance of the database storing the infrastructure model.

Images