KR102246079B1 - SYSTEM OF SENSORY DATA ACQUISITION AND SYNCHRONIZATION FOR CLOUD CENTRIC IoT AND METHOD PERFORMING THEREOF - Google Patents

Abstract

The multi-modal sensor data acquisition and synchronization system for cloud-centric IoT according to the present invention includes a sensor device profile database in which a profile for each sensor device is stored, a data acquisition strategy unit in which an acquisition strategy for each sensor device is stored, and a sensor suitable for a specific smart environment. A data acquisition strategy generator that provides a plurality of models for the data acquisition strategy so that the data acquisition strategy can be used, based on the cloud instance, and extracts and loads the profile of the sensor device for data acquisition from the sensor device profile database before data acquisition. And a data acquisition unit for acquiring data from a corresponding sensor device based on any one of the plurality of models.

Description

Multi-modal sensor data acquisition and synchronization system for cloud-centric IoT and its execution method {SYSTEM OF SENSORY DATA ACQUISITION AND SYNCHRONIZATION FOR CLOUD CENTRIC IoT AND METHOD PERFORMING THEREOF}

The present invention relates to a method for collecting data of an IoT environment into a cloud and a system for executing the same, and more specifically, by separating data acquisition strategy and communication, cloud sensing uses a cloud platform in the IoT environment based on the situation and environment. The present invention relates to a method for collecting data of an IoT environment in a cloud, which enables data acquisition, and a system for executing the same.

The smart environment is the motive of realizing the IoT environment, where the sum of things works harmoniously to achieve a specific goal. It is highly dependent on data collected by various sensors, and the collected data is used for context awareness and decision making by intelligent processes.

The core technology of ubiquitous computing and ubiquitous computing is context awareness, which means that the system understands the situation using data collected from the surrounding environment, which can be classified into low-level and high-level contextual awareness. The key to the context-aware system is to collect data from multimodal sensors in the IoT environment through a cloud platform. In other words, the data consistency and reliability must be guaranteed so that the intelligent system can make decisions based on this.

The ubiquitous cloud platform with abundant resources has reduced the role of the sensor as much as possible by performing the computation that had to be performed by the existing sensors, thereby achieving device independence in which the sensor only performs the role of collecting data.

For frameworks based on time-based and lifelog maintenance, the cloud platform plays a key role for context curation and monitoring, and detects anomalies.

In addition, the cloud platform plays the role of a big data platform that can store vast amounts of data. Therefore, it is essential to use Cloud Sensing-as-a-Service for application models in the current advanced situation.

Making compliance with a single standard in an IoT environment composed of sensors produced by various manufacturers is a difficult task. Normalizing the data acquisition method by various kinds of large-scale events in a cloud environment as a centralized hub of data has many problems to be solved.

The method of acquiring data from the current IoT environment sensor to the cloud depends on the specifications of the device and the system. This means that only APIs specified by the manufacturer are complied with, so there are limitations that are not dynamic and cannot have extensibility.

On the other hand, events occurring in the IoT environment with various and vast groups of sensors are used for situational awareness with the cloud platform as a central hub. The current situation awareness systems assume a smart environment within the area based on the location and time information of the sensor and perform situation recognition.

However, in the distributed sensor environment in the IoT environment, sensor information generated in the area where the current event does not occur is also important, but current systems ignore it, reducing the accuracy of the situation. Therefore, there is a need to synchronize sensor events occurring in various areas in the data acquisition stage.

The present invention is a multi-modal sensor data acquisition and synchronization system for cloud-centric IoT that enables cloud sensing to acquire data using a cloud platform in an IoT environment based on the context and environment by separating data acquisition strategy and communication. It aims to provide an implementation method.

In addition, an object of the present invention is to provide a system for acquiring and synchronizing multi-modal sensor data for a cloud-centric IoT that enables synchronization of data acquired using a cloud platform in an IoT environment, and an execution method thereof.

In addition, an object of the present invention is to provide a system for acquiring and synchronizing multi-modal sensor data for a cloud-centric IoT that enables synchronization of independent time of each sensor device into one logical time, and a method of executing the same. .

The objects of the present invention are not limited to the above-mentioned objects, and other objects and advantages of the present invention that are not mentioned can be understood by the following description, and will be more clearly understood by examples of the present invention. In addition, it will be easily understood that the objects and advantages of the present invention can be realized by the means shown in the claims and combinations thereof.

To achieve this purpose, the multi-modal sensor data acquisition and synchronization system for cloud-centric IoT is a sensor device profile database that stores a profile for each sensor device, a data acquisition strategy unit that stores acquisition strategies for each sensor device, and a specific smart environment. A data acquisition strategy generation unit that provides a plurality of models to generate the data acquisition strategy so that the sensor can be used appropriately, and a profile of the sensor device for data acquisition in the sensor device profile database prior to data acquisition based on a cloud instance. And a data acquisition unit that extracts and loads, and then acquires data from a corresponding sensor device based on any one of the plurality of models.

In addition, the multi-modal sensor data acquisition and synchronization method for cloud-centric IoT to achieve this purpose is the step of creating a plurality of models to create a data acquisition strategy so that the sensor can be used for a specific smart environment, based on a cloud instance. And extracting and loading a profile of a sensor device for data acquisition from a sensor device profile database before data acquisition, and acquiring data from a corresponding sensor device based on any one of the plurality of models. .

According to the present invention as described above, there is an advantage that it is possible to acquire data using a cloud platform in an IoT environment in which cloud sensing is based on a situation and environment by separating data acquisition strategy and communication.

In addition, according to the present invention, there is an advantage of being able to synchronize data acquired using a cloud platform in an IoT environment.

In addition, according to the present invention, there is an advantage that the independent time of each sensor device can be synchronized to one logical time.

1 is a diagram illustrating a system for acquiring multi-modal sensor data for a cloud-centric IoT according to an embodiment of the present invention.
2 is a diagram illustrating a system for acquiring and synchronizing multi-modal sensor data for a cloud-centric IoT according to an embodiment of the present invention.
3 is a diagram illustrating a glass diagram of an object model for a data acquisition strategy according to an embodiment of the present invention.
4 is a diagram illustrating a process of generating a data acquisition strategy according to an embodiment of the present invention.

The above-described objects, features, and advantages will be described later in detail with reference to the accompanying drawings, and accordingly, a person of ordinary skill in the art to which the present invention pertains will be able to easily implement the technical idea of the present invention. In describing the present invention, if it is determined that a detailed description of a known technology related to the present invention may unnecessarily obscure the subject matter of the present invention, a detailed description will be omitted. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the drawings, the same reference numerals are used to indicate the same or similar elements.

1 is a diagram illustrating a system for acquiring multi-modal sensor data for a cloud-centric IoT according to an embodiment of the present invention.

Referring to FIG. 1, a system for collecting data of an IoT environment in a cloud includes a communication device 201, a data acquisition unit 203, a sensor device information database 213, a data acquisition strategy provision unit 223, and a data acquisition strategy. It includes a generation unit 233 and a model authoring interface providing unit 243.

The communication device 201 includes a direct communication device and an indirect communication device.

Direct communication devices have data communication protocols and asynchronously communicate with the cloud platform using HTTP/HTTPS.

Indirect communication devices require a bridge for communication. These include wearable devices through smartphones and sensor devices through edge computing. These indirect communication devices communicate with each other in a synchronous or asynchronous manner depending on their type and configuration, but the bridge that communicates with the cloud operates only in an asynchronous manner.

The data acquisition unit 203 acquires data from the communication device 201 based on the static model 233a or the dynamic model 233b selected by the data acquisition strategy providing unit 223 based on the cloud instance 253. .

To this end, the data acquisition unit 203 extracts and loads the profile of the sensor device for data acquisition from the sensor device information database 213 before data acquisition, and then the static model selected by the data acquisition strategy provider 223 Data is acquired from the sensor device based on either of the models 233a and 233b.

In one embodiment, in the case of the static model 233a selected by the data acquisition strategy providing unit 223, the data acquisition unit 203 corresponds to the profile of the sensor device among the configuration files for each sensor device stored in the static model 233a. Data can be acquired based on the data acquisition strategy corresponding to the sensor device.

In another embodiment, when the data acquisition unit 203 is the dynamic model 233b selected by the data acquisition strategy providing unit 223, the profile of the sensor device among the configuration files for each sensor device stored in the dynamic model 233b Data can be acquired based on the data acquisition strategy corresponding to the corresponding sensor device.

As described above, when the data acquisition unit 203 acquires data, it acquires data through the indirect communication gateway 204 and the direct communication gateway 205 as shown in FIG. 2.

The indirect communication gateway 204 acquires data received from the indirect communication device. For example, the indirect communication gateway 204 is a Node.js-based non-blocking web service and may receive data from an indirect communication device such as a smartphone or an edge node using HTTP/HTTPS.

The direct communication gateway 205 obtains data from the direct communication device 201b.

The data acquisition strategy providing unit 223 selects one of the static model 233a and the dynamic model 233b generated by the data acquisition strategy generation unit 233 and provides it to the data acquisition unit 203.

In one embodiment, when it is determined that the type of smart environment is a limited smart environment, the data acquisition strategy providing unit 223 selects the static model 233a from among the static model 233a and the dynamic model 233b, and then the data acquisition unit ( 203).

In another embodiment, when it is determined that the type of the smart environment is a large-scale smart environment, the data acquisition strategy providing unit 223 selects the dynamic model 233b from the static model 233a and the dynamic model 233b, and then the data acquisition unit Provided to (203).

The data acquisition strategy generation unit 233 generates a plurality of models to generate a data acquisition strategy so that the sensor can be used in accordance with a specific smart environment. In this case, the plurality of models includes a static model 233a and a dynamic model 233b.

In the static model 233a, a configuration file for each sensor device is stored. In this case, the configuration file for each communication device may include device registration information, a data acquisition strategy, a communication frequency, and a trust level of the communication device.

This static model 233a is suitable for use in a smart environment using limited sensor devices. The reason for this is that a sensor device can be set based on a configuration file for each sensor device stored in the static model 233a during execution time, but the scalability is insufficient.

In the dynamic model 233b, setting information for each sensor device is stored in an object-oriented manner. In this case, the setting information may include device registration information, a data acquisition strategy, a communication frequency, a reliability level of a communication device, and the like.

This dynamic model 233b can be set at runtime and has excellent scalability, so it is suitable for use in an evolved and reusable smart environment with a large-scale sensor.

In addition, the data acquisition strategy generation unit 233 generates a data acquisition strategy for each of the static model 233a and the dynamic model 233b so that the sensor can be used in accordance with a specific smart environment.

In one embodiment, the data acquisition strategy generation unit 233 executes setting of a communication target sensor, a communication protocol, an execution frequency, a data type, a redundant data management, and a trust level of each sensor.

For example, if there is a smart environment that checks air quality, the data acquisition strategy would be "communication target sensor: environmental sensor, execution frequency: once a minute, etc."

The model authoring interface providing unit 243 generates a data acquisition strategy according to various situations by using a model authoring tool and provides an interface that enables a sensor to be used in accordance with a specific smart environment.

First, the model authoring interface providing unit 243 provides an interface so that a designer can create a strategic situation and bind it to a sensor and an environment to create a model. The interface includes a sensor profile providing window and a data acquisition strategy window.

The sensor profile providing window is an interface that provides a list of all currently available sensors. Sensors are registered for each type, and sensors can be newly added or deleted by a user.

The strategy window is an interface that can create the context of a data acquisition strategy according to conditions and sensors. For example, the situation is as in [Equation 1] below, and the condition is as in [Equation 2] below.

[Equation 1]

S = f(U, C, D)

U: identification information of sensor a,

C: set of conditions

D: set of sensor devices

[Equation 2]

In [Equation 2], the left operator (Oleft) and the right operator (Oright) may have sub-conditions.

2 is a diagram illustrating a system for acquiring and synchronizing multi-modal sensor data for a cloud-centric IoT according to an embodiment of the present invention.

2, a system for synchronizing and storing data collected in the cloud of IoT environment data includes a communication device 201, a data acquisition unit 203, a data buffer 206, and a data synchronization unit 210 do.

The communication device 201 includes a direct communication device 201a and an indirect communication device 201b.

The direct communication device 201a has a data communication protocol and communicates with the cloud platform asynchronously using HTTP/HTTPS.

The indirect communication device 201b needs a bridge for communication. These include wearable devices through smartphones and sensor devices through edge computing. These indirect communication devices communicate with each other in a synchronous or asynchronous manner depending on their type and configuration, but the bridge that communicates with the cloud operates only in an asynchronous manner.

The data acquisition unit 203 is from the communication device 201 based on the static model 233a or the dynamic model 233b selected by the data acquisition strategy providing unit 223 based on the cloud instance 253 as shown in FIG. 1. Acquire data.

At this time, the data acquisition unit 203 acquires data through the indirect communication gateway 204 and the direct communication gateway 205.

The indirect communication gateway 204 acquires data received from the indirect communication device 201a. For example, the indirect communication gateway 204 is a Node.js-based non-blocking web service and may receive data from an indirect communication device 201a such as a smartphone or an edge node using HTTP/HTTPS.

The direct communication gateway 205 obtains data from the direct communication device 201b.

Data acquired through the data acquisition unit 203 is temporarily stored in the data buffer 206. In this case, data refers to data before synchronization is performed. This data buffer 206 includes a first buffer 207, a second buffer 208 and a buffer control module 209.

Data received from the indirect communication device 201b through the indirect communication gateway 204 is stored in the first buffer 207. The first buffer 207 displays a synchronization ready state by using the last bit information after data storage is completed. For example, after data storage is completed, the first buffer 207 may set the last bit information to “0” to indicate a synchronization ready state.

In addition, when data stored in the first buffer 207 is synchronized by the data synchronization unit 210 and then inserted into the data queue 216, the synchronization completion status is displayed using the last bit information. For example, when the first buffer 207 is synchronized by the data synchronization unit 210 and then inserted into the data queue 216, the last bit information is set to “1” to indicate the synchronization completion status.

Data received from the communication device 201b directly through the second buffer 208 is stored. The second buffer 208 displays a synchronization ready state by using the last bit information after data storage is completed. For example, after data storage is completed, the first buffer 207 may set the last bit information to “0” to indicate a synchronization ready state.

In addition, when data stored in the first buffer 207 is synchronized by the data synchronization unit 210 and then inserted into the data queue 216, the synchronization completion status is displayed using the last bit information. For example, when the first buffer 207 is synchronized by the data synchronization unit 210 and then inserted into the data queue 216, the last bit information is set to “1” to indicate the synchronization completion status.

The buffer control module 209 interlocks with the data buffer synchronization module 211 to delete synchronized data from each of the first buffer 207 and the second buffer 208 at specific time intervals. At this time, the buffer control module 209 determines whether or not synchronization is terminated using the last bit information of each of the first buffer 207 and the second buffer 208, and deletes synchronized data from the corresponding buffer according to the determination result. .

In one embodiment, the buffer control module 209 interlocks with the data buffer synchronization module 211 to delete synchronized data from the first buffer 207 when the last bit information of the first buffer 207 is in a synchronization end state. do. For example, if the last bit information of the first buffer 207 is “1”, the buffer control module 209 determines that the synchronization has ended and deletes the synchronized data from the first buffer 207.

In another embodiment, the buffer control module 209 interlocks with the data buffer synchronization module 211 and when the last bit information of the second buffer 208 is in the synchronization end state, the data synchronized in the second buffer 208 is Delete it. For example, if the last bit information of the second buffer 208 is "1", the buffer control module 209 determines that the synchronization has ended and deletes the synchronized data from the second buffer 208.

The data synchronization unit 210 synchronizes each data based on the generation time of each data. At this time, since each data generation time is allocated based on an independent clock possessed by the entity generating the data (for example, a direct communication device or an indirect communication device), a different generation time is allocated even if it is generated at the same time. There may be.

In general, a communication device (eg, a direct communication device or an indirect communication device) allocates a generation time of the corresponding data to each data whenever data is generated. However, since each communication device has its own independent clock, the generation time is allocated based on each independent clock.

Accordingly, even if data is generated at the same time in different communication devices, the generation time allocated to the data will be different because the generation time is allocated to the data based on its own clock.

In order to solve this problem, the present invention synchronizes independent times of different communication devices into one logical time. To this end, the data synchronization unit 210 synchronizes the data stored in the first buffer 207 and the second buffer 208 at a specific time period or at a time other than the specific time period and then stores the data in a queue. The data synchronization unit 210 includes a data buffer synchronization module 211, a complete synchronization module 212, an incomplete synchronization module 213, and a data queue 216.

When the data of the first buffer 207 and the second buffer 208 is stored in the data queue 216, the data buffer synchronization module 211 is The bit information is changed to notify the buffer control module 209 that synchronization of data stored in the first buffer 207 and the second buffer 208 is completed.

The complete synchronization module 212 is a first buffer after each data received from the direct communication device 201b and the indirect communication device 201b is received in each of the first buffer 207 and the second buffer 208 at a specific time period. Data queued by grouping data stored in each of the first buffer 207 and the second buffer 208 into one message according to the state of each of the 207 and the second buffer 208 and allocating a generation time to the data queue 216 Each is provided in.

In one embodiment, the complete synchronization module 212 determines that the state of the first buffer 207 is ready for synchronization using the last bit information of the first buffer 207, the data stored in the first buffer 207 Is grouped into a single message, and a generation time is allocated to provide the data to the data queue 216.

In another embodiment, when it is determined that the state of the second buffer 208 is ready for synchronization using the last bit information of the second buffer 208, the complete synchronization module 212 is stored in the second buffer 208. After data is grouped into one message, a generation time is allocated and provided to the data queue 216.

In yet another embodiment, the complete synchronization module 212 is determined to be in the synchronization ready state using the last bit information of each of the first buffer 207 and the second buffer 208, the first buffer 207 and the first buffer 207 2 After the data stored in each of the buffers 208 are grouped into one message, a generation time is allocated and provided to the data queue 216.

In the above embodiment, the complete synchronization module 212 is determined to be in a synchronization ready state by using the last bit information of the first buffer 207, but it is determined to be in a synchronization ready state by using the last bit information of the second buffer 208. If not, or if it is determined that the synchronization is ready using the last bit information of the second buffer 208, but is not determined that the synchronization is ready using the last bit information of the first buffer 207, another buffer for a specific time It waits until the state of is changed to the ready-to-sync state. However, the complete synchronization module 212 only synchronizes the buffer in the synchronization-ready state if the state of the other buffer is not changed to the synchronization-ready state even after a specific time.

As described above, the complete synchronization module 212 has the first buffer 207 and the second buffer 207 and the second buffer 207 at a specific time period because the generation times allocated to the data stored in each of the first buffer 207 and the second buffer 208 are different from each other. By grouping data stored in each of the buffers 208 into messages and allocating a generation time, data grouped into messages can be synchronized.

The incomplete synchronization module 213 generates a message using data stored in each of different buffers at times other than a specific time zone and provides the message to the data queue 216.

The incomplete synchronization module 213 interlocks with the first synchronization module 214 or the second synchronization module 215 to use the entire data or the last data stored in each of the first buffer 207 and the second buffer 208 After generating the message, it is stored in the data queue 216.

In one embodiment, when prioritizing the performance of IoT context awareness using data, the incomplete synchronization module 213 interlocks with the first synchronization module 214 to provide the first buffer 207 and the second buffer 208. A message is generated using all data stored in each and then stored in the data queue 216.

In another embodiment, when the incomplete synchronization module 213 prioritizes the accuracy of context recognition of IoT using data, the first buffer 207 and the second buffer ( 208) A message is generated by using the last data among the data stored in each, and then stored in the data queue 216.

The data queue 216 stores messages in the first buffer 207 and the second buffer 208 for synchronization of messages in the first buffer 207 and the second buffer 208. This data queue 216 is used to recognize the context of the stored message.

The low-level context recognition unit 217 extracts messages one by one from the data queue 216 to determine whether the message is a low-level context. The low level context recognition unit 217 provides a message to the high level context recognition unit 218 if the message is not a low level context recognition.

The high level context recognition unit 218 stores the message received from the low level context recognition unit 217 in the database 219 if it is a high level status.

3 shows a class diagram of an object model for a data acquisition strategy according to an embodiment of the present invention.

3, the strategy design pattern for the data acquisition strategy 301 generated by the data acquisition strategy generation unit 233 includes selection of an agile strategy, a data acquisition situation 305, and a defined and reusable data acquisition strategy ( 302, 303, 304).

The data acquisition controller 306 provides implicit memory management in a singleton pattern for utilization of a single instance running over a lifetime.

The composite pattern 309 is used to merge data sources. The data source 307 provides an interface for device addition and registration of the sensor 308 required in the data acquisition strategy 302, 303, 304.

4 is a diagram illustrating a process of generating a data acquisition strategy according to an embodiment of the present invention.

Referring to FIG. 4, the model authoring interface providing unit 243 provides an interface 401 so that a designer can create a strategic situation and bind it to a sensor and an environment to create a model. The interface 401 includes a sensor profile providing window 402, a data acquisition strategy window 405 and a sensor environment window 406.

The sensor profile providing window 402 is an interface that provides a list of all currently available sensors. Sensors are registered for each type, and sensors may be newly added (403) or deleted (404) by a user.

The data acquisition strategy window 405 is an interface capable of generating a situation of a data acquisition strategy according to a condition and a sensor of a smart environment.

The sensor environment window 406 is an interface that displays a smart environment in an image form (eg, a two-dimensional image, a three-dimensional image, etc.).

As described above, although the present invention has been described by the limited embodiments and drawings, the present invention is not limited to the above embodiments, which is, if one of ordinary skill in the field to which the present invention belongs, various modifications and Transformation is possible. Therefore, the idea of the present invention should be grasped only by the claims set forth below, and all equivalent or equivalent modifications thereof will be said to belong to the scope of the idea of the present invention.

201: communication device
201a: direct communication device
201b: Indirect communication device
203: data acquisition unit
213: sensor device information database
223: Data Acquisition Strategy Provision Department
233: data acquisition strategy generation unit
233a: static model
233b: dynamic model
243: model authoring interface providing unit
204: indirect communication gateway
205: direct communication gateway
206: data buffer
207: first buffer
208: second buffer
209: buffer control module
210: data synchronization unit
211: data buffer synchronization module
212: full synchronization module
213: Incomplete synchronization module
216: data queue

Claims (10)

A data acquisition strategy generator for generating a data acquisition strategy for each of the static model and the dynamic model according to the conditions and sensors of the smart environment;
A data acquisition strategy providing unit for selecting the dynamic model when it is determined that the type of the smart environment is a large-scale smart environment, and selecting the static model when it is determined that the type of the smart environment is a limited smart environment;
Before data acquisition, the profile of the sensor device for data acquisition is extracted and loaded from the sensor device information database, and the sensor device data corresponding to the profile among the configuration files for each sensor device stored in the model selected by the data acquisition strategy provider A data acquisition unit that acquires data based on acquisition strategies;
A plurality of buffers for storing data acquired through the data acquisition unit and displaying a synchronization ready state or a synchronization completion state using last bit information;
When the last bit information of each of the plurality of buffers indicates a synchronization ready state, a complete synchronization module that groups data stored in each of the first buffer and the second buffer into one message, allocates a generation time, and provides it to the data queue. ;
When the performance of IoT situation awareness is important by using data outside a specific time zone, a message is generated using all the data stored in each of the plurality of buffers, and then provided to the data queue, and the IoT situation using the data. In a case where recognition accuracy is important, an incomplete synchronization module that generates a message by using the last data among the data stored in each of the plurality of buffers and stores it in a data queue.
Multi-modal sensor data acquisition and synchronization system for cloud-centric IoT.
delete The method of claim 1,
The above data acquisition strategy is
It comprises at least one of communication target sensor, communication protocol, execution frequency, data type, and redundant data management.
Multi-modal sensor data acquisition and synchronization system for cloud-centric IoT.
delete delete In the multi-modal sensor data acquisition and synchronization method for cloud-centric IoT executed in a multi-modal sensor data acquisition and synchronization system for cloud-centric IoT,
Generating a data acquisition strategy for each of the static model and the dynamic model according to the conditions and sensors of the smart environment;
Selecting the dynamic model when it is determined that the type of the smart environment is a large-scale smart environment, and selecting the static model when it is determined that the type of the smart environment is a limited smart environment;
Before data acquisition, the profile of the sensor device for data acquisition is extracted and loaded from the sensor device information database, and data is acquired based on the data acquisition strategy of the sensor device corresponding to the profile among the configuration files for each sensor device stored in the selected model. Acquiring;
Receiving the acquired data, storing them in different buffers, respectively, and displaying a synchronization ready state or a synchronization completion state using last bit information;
Grouping data stored in each of the first and second buffers into one message when the last bit information of each of the plurality of buffers indicates a synchronization ready state, allocating a generation time and providing the data to a data queue;
When the performance of IoT situation awareness is important by using data outside a specific time zone, a message is generated using all the data stored in each of the plurality of buffers, and then provided to the data queue, and the IoT situation using the data. In case that recognition accuracy is important, generating a message using the last data among the data stored in each of the plurality of buffers and storing the message in a data queue.
Multi-modal sensor data acquisition and synchronization method for cloud-centric IoT.
delete The method of claim 6,
The above data acquisition strategy is
It comprises at least one of communication target sensor, communication protocol, execution frequency, data type, and redundant data management.
Multi-modal sensor data acquisition and synchronization method for cloud-centric IoT. delete delete

Images