Skip to main content

IoT Alert Message

Versie: Process description SALES005 1-3-2021

1 Introduction​

This manual contains the general playing rules for companies from the construction and installation sector who wish to exchange standardised and electronic messages. It is a sector-specific basic document for each area of processing and contains general information on electronic communication and the operating rules. Within the construction and installation sector, DICO XML-messages are employed.

1.1 The IoT Alert Message within the DICO Standard​

The DICO Standaard contains various areas of processing which allow for the employment of the messages. All areas of processing can be found in Semantic Treehouse. Within the DICO Standaard the IoT Alert Message SALES005 can be identified by the logo displayed below:

Logo IoT Storingbericht within the DICO Standaard
Figure 1 – Logo IoT Alert Message within the DICO Standard

1.2 What is the purpose of this document?​

In this document, you will find the overarching agreements that have been made within the industry on the usage of the DICO XML messages. This processing model is meant for the quotations request for services and/or messages and provides an overview of the playing rules that are in force within the DICO Standaard.

1.3 Which documents are part of the user’s documentation?​

The user’s documentation for data messages consists of two documents: a process description (this document) for maintenance messages and for a technical document. Other (technical) information is published on Semantic Treehouse. Here, one can find, among others, sample messages, as well as tools, such as a validation tools used for the validation of messages. The documentation has been composed with great care; if there happen to be any inconsistencies or ambiguities, please contact Ketenstandaard for clarification. Please do not come up with an interpretation on your own, to avoid the coming into being various dialects of the standard.

The documentation describes the scope, process and technical assumptions of the DICO Standaard. Its structure, contents and operating rules are further elaborated upon in Semantic Treehouse. Finalised DICO XML messages should adhere to the delineated demands. For the factual exchange of DICO messages, a license is required. For more information and the general terms and conditions for use, please refer to www.ketenstandaard.nl.

1.4 Contributors​

This document is maintained by Ketenstandaard Bouw en Techniek. Ketenstandaard Bouw en Techniek magages the DICO Standard and facilitates DICO Committees for the Contrusction and Installation sector. Companies from the sector are represented within these committees, which ascertains the connection with the need for information from the sector. For any further questions or comments on this document, please contact dico@ketenstandaard.nl. 

2 IoT Alert Message​

This message enables the exchange of information regarding devices that have been linked / connected with an IoT Sensor. Enormous amounts of data are generated by the sensors, specific information can be derived from the analysis of this data. It is this information specifically that can be standardised. Via the IoT Alert Message, the information can be provided in a structured manner. It is information which, in practice, directly provides added value to the process.

2.1 The process overview​

The process is illustrated schematically in the figure below. An IoT device is situated at a specific location, in this example a house. Rough data is transmitted from the IoT device. This rough data is usually collected in a database, either for direct building analysis or device analysis by, for example, a producer. The analyses of this database result in information. The trigger for information is then exchanged between parties. Depending on the specific process, the trigger kan be forwarded directly to the executing party, or via an in-between station.

Schematic overview IoT Alert Message within the process
Figuur 2 – Schematic overview IoT Alert Message within the process

The IoT Alert Message can, if necessary, be exchanged even when there is no IoT device. If there is no IoT device present, there can still be relevant (alert) information. And this information can be exchanged via the Alert Message. However, when developing the message, the above-described process model was the starting point.

The implementation of the trigger is a logical consequence of the trigger. Recording the information on the implementation is the next step. The information might provide, for example, added value for the owner of the building’s management system or a producer. Standardising this feedback could be a next step in the process.

2.2 Headings IoT Alert Message​

In the headings, the message is displayed in a simple and lean manner. It should determine who the sender and receiver of the message are. The GLN identifier is used for this. Via a list of codes, it can then be made clear which <Type> of Alert Message is of relevance here.

2.3 Lines IoT Alert Message​

In the lines, the factual alert information is provided. The information has been further divided into various structures. Some of these are explained in the following sub-paragraphs.

2.3.1 DDiscipline​

To provide even more details on what in particular the alert pertains to, information regarding the discipline can be included. Whether, for example, the alert is to be resolved by an electrician or plumber. If the registered data provides such information, it can be of added value to include it in the message.

2.3.2 Notification​

For further information, a notification can be included in the lines. Advice for the producer might be included as well. It could happen dat the producer can and is willing to provide additional information regarding a specific alert.

2.3.3 System​

The hart of the message is the XML structure <System>. The information on the system is important, as this further identificies the alert. The type of system, as well as the relevant component, can be useful information for the eventual reperation.

The alert code is part of the structure as well. Once it is known which malfunction or error code is of relevance, it is easier to, together with ID, Type and/or component, determine what is wrong with the system. Just as with the notification, advice on the alert from the producer can be included. Via the structure, it is furthermore possible to indicate which spare part is required for the reparation.

2.3.4 Analysis​

The analysis of the rough data provides information which can be communicated via the DICO IoT Alert Message. It might be useful to include the data-batch from which the information was derived in the message. This possility is provided for in the structure.

2.3.5 Location​

A location where the IoT device is located is to be determined. The location data can be included in the message. This varies from the address, to the specific location within the building. Construction-related element scan be included as well. This happened via the NLSFB-coding.

2.3.6 Status​

The final structure pertains to the status information. The status information is relevant for the status of the report.

3 DICO “Executed” message​

As mentioned, the process is iterative. After an IoT Alert Message has been sent, it would be most ideal if there can be feedback on the exact execution. Which reparation, action, or maintenance has taken place? This message is not yet available, but could be developed.