In concrete terms, in order to carry out your smart specification and your project, it is necessary to state the announced principles (Definition of the objectives and principles of the smart project) in practical tools. This page supplies 2 simple tools to understand the data needs linked to the use cases and the necessary interactions with the IS or applications in order to carry out these use cases:

• the system connections table

• the fact sheet

One of the first concrete steps of an IS bill of specifications is this list of use cases to which the system must have an answer to and therefore the digital services it will have to supply. In the case of a digital building, this list can be long and the project constrained in time. Hence, why it is so important to prioritize the use cases which will have to be viable at the delivery of the building, and those which will have to be progressively implemented as part of the current digital evolution (made possible thanks to the Building Operating System.)

This prioritization has to follow at the minimum two constraints:

• The service's "criticality": either for the building's good operation or for image reasons

• The cost of the service implementation: is it more costly if the service is installed before or after the construction project.

Following the R2S reference frame of the Smart Building Alliance (SBA), which advises a unified and secured IP network for the building's communication infrastructure and the choice of open IS with accessible and documented APIs, makes possible the development of future services by limiting the access costs to information. But there is still the action of building the "connectors" to be done, in order to ensure the exchange of information between the systems and data management tools to enable data governance. At this stage, several questions come to light:

• Which is the useful data for each use case?

• Which systems or applications supply this data? (redundancy is possible)

• Which are the connectors to create?

• How many connectors must be created according to the chosen architecture?

• Which is the useful reference frame data for the majority of the services?

• ...

The "fact sheet" data and "connections table" enable the formalization in a simple and readable manner of the answers to these question.

The connections table is built in the following manner:

• The use cases and their range are referred to in the lines (a line corresponds to a specific task)

• The IS, applications and data sources are reported in the columns (one column per system). The data producers are filed according to the nature:

  • reference frames: important data shared with a great number of digital services

  • OT : automated systems belonging the building's infrastructure that depend on the deployment of physical objects (sensors, actuators, automatons, IoT)...

  • IT : Management IS that can be completely virtualized (and often deployed in the cloud)

  • producer of personal data: IT specific system which supplies personal data

• An interaction or data need is materialized by a checkbox between a use case and a data producer. It is important to note that for each box checked, an "e-connector" must exist (a connector is a piece of software that uses APIs to recover and translate the data).

In the table supplied, the list of use cases and systems is indicative and not exhaustive. It serves as an example to illustrate the table and must be completed during the consulting phase beforehand. You can copy this table and train filling in the cells!

In addition to the previous table, which is a tool offering an overall view of the connections to foresee, the fact sheet enables to focus on a particular use case and specify more acutely the data needs and the use case details.

In the supplied fact sheet, the list of use cases and systems is indicative and not exhaustive. It serves as an example to illustrate the table and must be completed during the consulting phase beforehand. You can copy this table and train filling in the cells!