Fact sheet : data and connection tables fact sheet
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!
The table offers a summarized and complete view of the needs in terms of connection for each use case and enables the comprehension of:
Why the access to the data of each system is important (open APIs, communication on a standard and accessible IP network)
Why data crossing is important (the use cases need the description data from the building crossed with the consumption and real use data for instance)
Why the homogenization of data is important (for the data crossing from different silos)
Which are the most critical data silos (the ones that serve the most often, the reference frame data will come back very often...)
Which are the most critical services or use cases in terms of data usage (number of different data sources for each use case)
Which is the number of logical connectors to make between all systems in case of spaghettiware architecture (number of boxes checked in the table)
The drastic reduction of the number of connectors and the capacity of sharing the reference frames within the scope of a rational architecture with a BOS.
The fact sheet
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!