Skip to content

12.31 Advanced Semantic Discovery - Facility management of a supermarket chain

12.31.1 Description

Building and facility managers need a helicopter view of the facilities management processes, regardless of existing building installations in order to make better-informed decisions and to enforce cross building policies. Building managers are faced with heterogeneous and vendor-specific installations. Centralized management of buildings oftentimes forces the owners to go through costly replacements to adopt mono-vendor solutions. Installation of new equipment requires costly system integration because devices are often designed to communicate with specific applications only.

This use case assumes a facility manager working for a supermarket chain and responsible of dozens of buildings. It is supposed that there is an interoperability platform (oneM2M) that offers a standard interface to monitor and control all the buildings regardless of vendor. The facility manager could apply energy efficiency strategies to all buildings on large scale. He could for example, compare buildings to detect leaks, adjust the heat and the lighting according to forecast or predictive models, and compliant with applicable regulations.

The exposure of the huge amounts of data through modern APIs allows proliferation of new building services such as situational awareness, energy efficiency, intrusion detection, preventive maintenance and smart data.

Through further APIs, wider integration of the buildings with the outside world is achieved to give rise to fully integrated cities. The buildings start to interwork with energy grids (smart and micro grids), smart parking, Electrical Vehicle charging, waste management, etc., the ultimate goal for buildings to be considered really smart.

Assuring interoperability between all the data producing, data storing, and data processing components, semantic discovery and query mechanisms across and between sensors, devices, APIs and even IoT platforms are essential.

This use case is similar to the use case "Semantics query for device discovery across M2M Service Providers" in clause 12.9 of the present documents. However, it extends the requirements with a focus on the discovery and query capabilities, introducing a direct relation with the semantic aspects and enabling more sophisticated semantic queries.

12.31.2 Source

RDM-2020-0031R04-Facility management of a supermarket chain

Note

informative sources refer to the following documents: ETSI SR 003 680 SmartM2M; Guidelines for Security, Privacy and Interoperability in IoT System Definition; A Concrete Approach [i.31]. ETSI TR 103 714 SmartM2M; Study for oneM2M Discovery and Query use cases and requirements [i.23].

12.31.3 Actors

  • M2M devices as e.g. energy meters, temperature sensors, fire detectors, leak detectors, lightning controls, heat and air condition controls, surveillance cameras , cash boxes, inventory controls
  • Facility manager
  • M2M Service providers
  • M2M Applications e.g. data analytics, fault detection, energy efficiency, hypervision

12.31.4 Pre-conditions

M2M devices in the super markets have been installed and registered to their corresponding MN-CSE (Middle Node - Common Services Entity). The MN-CSEs have been registered to the corresponding IN-CSE (Infrastructure Node - Common Services Entity).

The M2M Application Provider 1 has contractual relationships with the M2M Service Providers 2, 3 and 4.
The M2M Service Providers 1 and 2 have databases that contain information on the devices located in the supermarkets of the supermarket chain.

The facility manager wants to make use of the devices within his supermarkets and of the API "Facility management" in order to apply energy efficiency strategies to all buildings on large scale and to compare buildings to detect leaks, adjust the heat and the lighting according to forecast or predictive models, and compliant with applicable regulations. Assessing the warehouses stocks enables to refill it in time and a centralized fault detection ensures to take countermeasures.

The M2M Service Provider 3 wants to access data from energy consuming/measuring devices and/or respective databases of the M2M Service Providers 1 and 2 in order to optimize his energy providing balance.

The M2M Service Provider 4 wants to access data from parking lot sensors, from charging stations for electrical vehicles, data about the product range and warehouse stocks of the M2M Service Providers 1 and 2 in order to provide relevant services to the city inhabitants.

12.31.5 Triggers

The facility manager, the API "Facility management", the M2M Service Provider 3 or 4 (further on called "REQUESTER") sends a semantic discovery service request to the M2M Service Provider 1 or 2 (further on called "REQUEST RECEIVER"). The request contains information about the device to be discovered, e.g., a device type, a localization and other filters criteria.

12.31.6 Normal Flow

Following, one example of a typical scenario is described:

  1. Via a device (e.g. user terminal), which is connected to the API "Facility management", the facility manager initiates a semantic discovery request within the domain of the M2M Service Provider 1 to the smart meters of a specific area of a special supermarket, which enquires information about its energy consumption.
  2. The API "Facility management" verifies the integrity of the semantic discovery request and sends a semantic discovery request to the MN-CSE of the supermarket.
  3. The database of the MN-CSE is searched for the specific requested type of devices whether they are connected to it or not.
  4. If the requested type of devices is connected to the MN-CSE, it returns the requested information of the devices to the M2M Application.
  5. If the requested devices are not connected to the MN-CSE, a negative acknowledge is sent back to the M2M Application.
  6. The API "Facility management" processes, if necessary, the received information and forwards it to the requesting device of the facility manager.

12.31.7 Alternative Flow

Following, one example of an alternative scenario is described:

  1. An M2M Application of the Service provider 4 (Smart Cities domain) launches a query to the domain of M2M Service Providers 1 and 2 to find and identify the sensors of their parking lots, which enquires information about free parking spaces.
  2. The IN-CSE of the Service Provider 1 verifies the integrity of the semantic discovery request and distributes it to the MN-CSEs of the supermarkets.
  3. The databases of the MN-CSEs are searched for the specific requested type of devices whether they are connected to it or not.
  4. If the requested type of devices is connected to a MN-CSE, it returns the requested information of the devices to the IN-CSE, which forwards it to the requesting Service Provider 4.
  5. +f the requested devices are not connected to the MN-CSE, a negative acknowledge is sent back to the IN-CSE, which forwards it to the requesting Service Provider 4.
  6. The requesting M2M Application of Service Provider 4 processes the data and provides them in an appropriate way to the users of the M2M Application (e.g. city inhabitants).

12.31.8 Post-conditions

The facility manager, the API "Facility management", the M2M Service Provider 3 or 4 can start to employ the devices based on the semantic discovery service request sent to the M2M Service Provider 1 or 2.

12.31.9 High Level Illustration

Figure 12.30.9-1 - Facility management of a supermarket chain

Figure 12.30.9-1 - Facility management of a supermarket chain

12.31.10 Potential requirements

The following potential requirements are additional to the ones already identified in clauses 12.29.10 and 12.30.10.

  1. Advanced Semantic Discovery shall support queries written with specific domain ontologies, e.g. SAREF.
  2. Advanced Semantic Discovery shall support semantic reasoning between the baseline oneM2M ontology and the identified domain specific ontologies, e.g. SAREF. As example, if a query is looking for a oneM2M device observing Celsius temperature, then the Advanced Semantic Discovery would potentially return a SAREF temperature sensor.
  3. Advanced Semantic Discovery shall provide capabilities to identify multiple set of targets, and a multiplicity of searches (e.g. by setting parameters or filters).
  4. The oneM2M Access Control Policy shall include discovery permissions to support Advanced Semantic Discovery. When an Advanced Semantic Discovery is performed by the oneM2M System, it shall operate according to the indications associated with the desired information.

It is also expected that:

  • The solution would be based an evolution of the current oneM2M architecture and functionality and would reuse existing standard ontology mechanisms e.g. considering the SAREF standard developed in ETSI TC SmartM2M (which is also aligned with the W3C ontology approach). This intends to assure also a smooth interworking with relevant non-oneM2M solutions.
  • The solution would be complete and will be a part of the oneM2M core functions, to avoid the need of ad hoc applications designed to expand the oneM2M functionality with the risk of being implemented with different flavours.