diff --git a/TS-0041-oneM2M-SensorThings_interworking.md b/TS-0041-oneM2M-SensorThings_interworking.md index 90a448a3dc50bd637c9bcb5f1ba4488b8f12162c..a75992c5decc49d624e1e388a0493080e3c0f177 100644 --- a/TS-0041-oneM2M-SensorThings_interworking.md +++ b/TS-0041-oneM2M-SensorThings_interworking.md @@ -76,7 +76,7 @@ The following referenced documents are necessary, partially or totally, for the - Use the **EX** style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example). `EXAMPLE:` -- <a name="_ref_1">[1]</a> ETSI TR 102 473: "<Title>". +- <a name="_ref_1">[1]</a> OGC SensorThings API "Part 1: Sensing Version 1.1" (http://www.opengis.net/doc/is/sensorthings/1.1) ## 2.2 Informative references @@ -87,7 +87,8 @@ The following referenced documents are not necessary for the application of the - Use the **EX** style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references). -- <a href="#_ref_i.1">[i.1]</a> oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf) +- <a href="#_ref_i.1">[i.1]</a> oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf) +- <a href="#_ref_i.2">[i.2]</a> OGC SensorThings API "Part 2 – Tasking Core" ( http://www.opengis.net/doc/IS/sensorthings-part2-TaskingCore/1.0) # 3 Definition of terms, symbols and abbreviations @@ -154,6 +155,28 @@ The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in # 5 Introduction to OGC SensorThings API <Text> +The SensorThings API (STA) is a standard of the Open Geospatial Consortium (OGC). It provides a framework for communication and exchanging data between sensors and applications. The standard is devided in two parts. SensorThings API Part 1 is dedicated to sensing and was published in 2016 and updated in 2021 <a href="#_ref_1">[1]</a>. Part 2 deals with tasking and was published in 2019 <a href="#_ref_i.2">[i.2]</a>. +A STA-based architecture works in client/server mode. A sensor device pushes data to the SensorThings Server via HTTP. A SensorThings Server may also support MQTT protocol to support publish and subscribe capabilities. An interested application can subscribe to the MQTT-Broker, in order to get notified about new sensor events. + +<figure> + <img src="media/sta_flow.png" alt="STA_message_flow"> + <figcaption>Figure 5-1 STA message flow</figcaption> +</figure> + +The data in the SensorThings server are organized as according to “Sensing Entities” (see Figure 5.0-1: “Sensing Entities” data model). + +<figure> + <img src="media/data_model.jpg" alt="data_model"> + <figcaption>Figure 5-1 STA Sensing Entities Data Model</figcaption> +</figure> + +In the Sensing Entities Data Model events or sensor data are called "observations". Before a sensor is able to push an observation to the server it needs at least a 'Thing' and a 'Datastream' entity. This has to be created beforehand. One 'Thing' might have different 'Sensors', one 'Location' or many 'HistoricalLocations'. + +The Sensing Entities data model and the purpose of data within the data model discloses mainly two data characteristics, associated with a 'thing': +- Data observations originated by sensors or commands sent to interact with actuators may be seen as IoT data from oneM2M point of view. + While: +- Data embedded in the Sensing Entities Data Model, like "historic locations" should be seen as data for documentation purposes. + ## 5.1 User defined subdivisions of clause(s) from here onwards <Text>