# An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
## 2 Related Work  
To address the aforementioned SW-IoT heterogeneity problem, there are two possible approaches. The first one is the hub approach. The hub approach is achieved by implementing different connectors corresponding to different SW-IoT ecosystems. With the connectors, a hub can communicate with different systems. A hub can be in the application layer, service layer or gateway layer as long as the hub can support protocols of different systems. For example, If-This-Then-That (IFTTT), a service hub on the application layer, supporting many connectors connecting to many web applications and SW-IoT systems. The hub approach is effective and easy to develop. However, for as many SW-IoT systems, a hub needs to implement customized connectors, which results in significant development cost. The second approach is the standard approach. In principle, by following standards, SW-IoT systems from different manufacturers can collaborate with each other within each standard ecosystem. There are some organizations proposing their proprietary standards, such as Apple's \"Works with HomeKit ([[https://www.apple.com/tw/ios/home/accessories/](https://www.apple.com/tw/ios/home/accessories/)]([https://www.apple.com/tw/ios/home/accessories/](https://www.apple.com/tw/ios/home/accessories/)))\" and Google's \"Works with Nest ([[https://nest.com/works-with-nest/](https://nest.com/works-with-nest/)]([https://nest.com/works-with-nest/](https://nest.com/works-with-nest/)))\". Different from the hub approach, enterprises are trying to define proprietary standards to attract manufacturers to join their ecosystems. However, proprietary standards and ecosystems would cause more heterogeneity issues as no existing SW-IoT ecosystem is large enough to attract all manufactures. On the other hand, the real potential of the standard approach is to follow open and commonly agreed standards. For example, there are many existing open standards defined for unifying interfaces of the SW-IoT Service Layer. Among the standards, the OGC SOS is a web service interface standard for sensor resource sharing. Information shared by SOS services is described with other SWE standards such as the O&M and SensorML. However, the SOS is based on Simple Object Access Protocol (SOAP) and XML-based network protocol, which are considered as outdated and inefficient. Therefore, OGC recently defines another service interface standard, the SensorThings API. The first part of the SensorThings API standard is primarily designed for the SW-IoT sensing capability. Different from other OGC service interfaces, the SensorThings API applies RESTful style and JSON encoding to provide a more lightweight and efficient interface. The data model of the SensorThings API is mainly extended from the O&M data model by including classes of IoT to ensure the versatility of its data model. The interface of the SensorThings API service is inspired by the OASIS OData. SW-IoT resources are represented as entities or properties that can be identified by URIs (Uniform Resource Identifiers), and resources can be linked together using relationship links. The second part of the SensorThings API is under development and focuses on extending the data model and service interface to support tasking capabilities. In addition, there are some standards designed by different industrial alliances. HyperCat standard [21] is proposed by the HyperCat consortium, an organization which is composed of more than 40 UK-based companies including British Telecom, Rolls-Royce, and military supplies manufacturer BAE, etc. The HyperCat is an open, lightweight, JSON-based online catalog tagged with metadata. The HyperCat exposes SW-IoT devices' information and observation resources over the web with semantic annotations. Instead of requiring manufacturers to follow the same data format, the HyperCat can describe data from different providers and help users search for the data relevant to their needs.