Digital Twin development requires harmonious communication between two groups of stakeholders: 1) AECO professionals and other non-software engineers, and 2) software engineers. The former knows what problems they want to solve, the latter knows how to solve them.

The substance of a software project is usually considered in terms of requirements. In such a setting, non-software stakeholders and software engineers have to achieve agreement on the kind of digital twin they wish to develop, the AECO-related problems they wish to address, and any aspects that are technically infeasible. Although such requirements are commonly incomplete (because completeness is either infeasible or too costly), and often change over time, they will still serve as a basis for system development.

Thus, both sets of stakeholders have to be able to read, review and approve the documented requirements. Scenarios are proposed with the aim of capturing the activities that take place between the digital twin and its users (both humans and other systems). Instead of free-form scenarios, we propose a well-defined scenario space that situates the scenarios in their respective contexts.

The following two sections illustrate firstly the perspective that a scenario should take (a system rather than a user perspective) and, secondly, the formal language that is best suited to the AECO sector in situations where the scenarios require formalization.

System scenarios

Digital twins interact directly with the physical world. This idea is fundamentally different to many of the typical information systems employed in the AECO sector. For example, data governance systems are used to manage collaboration between BIM models, but have no immediate impact on the physical world. The interactions of a cyber-physical system differ significantly from those of a data governance system because they are interconnected to other machines (devices, computers, vehicles, etc.), and human-computer interaction represents only a fraction of its requirements.

In a digital twin, the focus of the requirements analysis is shifted from the user to the system. Instead of describing user interactions in a user scenario, activities at module and system level are described in terms of system scenarios.

This shift of focus is crucial to a successful requirements analysis in the context of digital twin application in the AECO sector. Previous focus on the user has caused us to overlook a number of key system-related details. While many problems appear to be consistent and feasibly resolved from a user perspective, the same problems suddenly become practically infeasible and underspecified from a system perspective.

For example, from a user perspective, there is no need to know where our data comes from, or how, when, and how often they need to be processed. It is usually sufficient to note which data the user needs to see. However, a system perspective will reveal deeper issues, such as the reliability of the source of the data necessary to solve a given problem. A system perspective addresses such questions as: do domain experts agree about data validity (sensor accuracy)?, or does resolution of the problem in hand require a large or a small amount of data? Such questions have an enormous influence on downstream development and should be clarified as soon as possible. So, while user scenarios are certainly important, and should not be ignored, system scenarios are indispensable.

A universal language

A system scenario has to capture domain knowledge that enables software engineers to understand the problem in hand and evaluate its resolution. While free-form human language may suffice to describe a scenario in theory, the invention of relational terminology for every new problem or project is a tedious process, which can be avoided by re-using an existing language with well-defined terms. Such an approach can save a lot of work and avoid many misunderstandings.

Finding such a language is not a trivial task. It has to be understood by both domain experts and software engineers. The latter are familiar with general graphical languages, such as Unified Modelling Language (UML), but these are obscure to domain experts. Process languages, such as Business Process Model and Notation (BPMN) and Information Delivery Manual (IDM), are often too detailed, specific and elaborate for describing typical system scenarios.

While languages such as UML, BPMN and IDM can be used in situations where there is an explicit need for highly formal problem descriptions, there also exists an easier option – the Building Information Model (BIM), which is currently widely used in the AECO sector. Since BIM is increasingly universally mandated in the sector, including by public authorities, a growing number of domain experts are familiar with its entities and relationships.

Since BIM is widely recognised in the industry and already used as a modelling language, we see no reason why it cannot also be used as a universal language in relevant system scenarios. BIM offers a natural language for the description of system entities and their relationships within AECO-related processes.

BIM circumvents the communication barrier resulting from the formalisms so enamored by software engineers, but from which domain experts shy away. BIM thus offers an attractive compromise that is formal enough to prevent ambiguity and familiar enough to enable domain experts to participate in the discussion.

Do you want to know more? Download our whitepaper from here and share your opinion with us through our LinkedIn or our Twitter communities!