# Digital Twin and Internet of Things--Current Standards Landscape
## 3 Standards for Digital Twins and the Internet of Things
### SensorThings API  
The SensorThings API (STA) standard [51] developed by the OGC SensorThings Standards Working Group (SWG) [52] provides a framework for interconnecting IoT devices, data, and applications over the Web. It is divided into multiple parts. Part 1 [53] was published in 2016 and covers the domain of sensing. Part 2 [54] addresses tasking, i.e., sending commands to devices, and was published in 2019. An updated version (v1.1) of Part 1 is finished and formal publication is underway.  
Since 2001, the OGC is working on a suite of standards for managing sensors and actuators called OGC Sensor Web Enablement (SWE). It is designed to enable the connecting sensor and actuator to the Web and make them discoverable and query-able. As sensors and actuators are usually physical devices, geo-location is a key element of OGS standards. The older SWE standards, e.g., Sensor Observation Service (SOS) and Sensor Planning Service (SPS), use rather old technologies like XML and SOAP but more importantly, they are also missing some basic features like publish/subscribe (pub/sub) support or capabilities to update/delete data. STA addresses those issues and at the same time redesigns the APIs to fit modern web-based principles like REST-based services and JSON as payload format.  
STA is strongly inspired by OData and re-uses some essential aspects, e.g., most parts of the URL conventions and query language, but is not fully compliant to OData. Besides leaving out some complexity of OData, STA also adds functionality where needed, e.g., pub/sub via MQTT and additional geo-spatial query capabilities. As OData itself is model-agnostic, STA provides a cross-domain model that can be further refined for any use case by providing an application model according to the metamodel hierarchy shown in Figure 2. The STA data model is shown in Figure 7. In STA, resources are called Things and are identified using URLs. The type system used is custom-built but re-using multiple existing type definitions, e.g., from previous SWE standards. Services are realized by modeling (virtual or physical) actuators with their capabilities and linking them to a thing. Events are only supported in the form of a subscription of changes of properties via MQTT. Resource interlinking and semantic annotation is hardy explicitly supported (only the class ObservedProperty has a property definition for semantic annotation) but can potentially be added by custom extension. Historical data is also only partially supported, as observations are stored over time, i.e., discovering past observations are possible but reading the value of properties at any time in the past is not possible.  
Resource discovery works almost identically as in OData although STA provides enhanced geo-spatial query capabilities.  
Figure 6: Components of URLs according to the Open Data Protocol specification.  
Resource access works also very similar to OData as both do not support direct communication between resource and consumer. In addition to OData, STA allows subscribing to the creation and update of resource collections, resources and properties. Having no direct communication between a consumer and a resource drastically improves usability in real-world applications, e.g., an actuator can subscribe to newly created tasks and immediately start processing them.