This was preceded by the vision of manufacturers, system providers, and users that a universal IoT connector was needed to standardize the connection between hardware and the cloud for the full deployment of Internet of Things applications. Previous standardizations often focused only on communication and security, and therefore on the upper layers of software or communication. Or, to put it simply: on the application itself, and thus on the useful part of IoT solutions.

However, data must first reach the layer where it can be collected, transported, and ultimately processed or stored. While it's possible to access and control hardware resources such as sensors, actuators, or embedded systems via the eAPI for embedded hardware through a defined interface, all hardware I/O communication has had to be performed manually for each edge and cloud connection until now. When replacing hardware, upgrading, or even switching manufacturers, many, if not all, customizations must be done from scratch, potentially for all affected layers, all the way to the final application. This is precisely where the UIC comes in: integrating components is made easier thanks to the three levels of abstraction, which allow for the partitioning of many aspects of IoT computing. The UIC interface standard distinguishes between device configuration (hardware identification, device assignment, value-to-information mapping), sensor and actuator communication (hardware controller), and device communication (data transfer and processing). With over 450 cloud service offerings and an even greater number of possible hardware configurations, it offers a very open, efficient, and practical approach to current and future Internet of Things solutions.

uic-abstraction-layers-wSpecifically, the Universal IoT Connector architecture consists of three interface descriptions: First, the Embedded Controller Module (EDM) interface, which controls connected hardware peripherals via controllers and provides sensors, actuators, or other local information. The second functional block is the Project Configuration Interface, which provides a configuration mechanism for embedded systems. It regulates which peripherals will be controlled, how raw data is added to information sets, and at what point the data will be transmitted to the server. Last but not least is the Communication Agent interface, responsible for transferring information to the communication unit, for example, a (cloud) server, including sending and receiving data sets or events. What makes UIC stand out in the field is its open approach to server connectivity (Cloud/Fog/M2M) and its associated infrastructure, as well as its underlying hardware and vendors, at least as long as EDM is supported, and last but not least, to the communication level. Depending on the configuration, this allows connection to Amazon Web Services (AWS) using a Qseven module and MQTT, as well as connection to Microsoft Azure Cloud via XRCE using a COM Express module. Due to its abstraction, the lean middleware paves the way for a particularly flexible approach. The open, cross-platform approach unifies access to multiple hardware components from different vendors, such as ADLINK, Congatec, Kontron, Portwell, or Seco, using a growing number of supported cloud platforms, including AWS, M2MGO's People System Things (PST), SAP HANA, or Microsoft Azure Cloud, and employing a wide range of protocols (MQTT, XRCE, OPC/UA, etc.). Furthermore, UIC runs on Windows Embedded and Embedded Linux.
SGeT's UIC standard offers a practical and open approach to IoT solutions and Industry 4.0 applications in one of the fastest-growing markets, estimated at €250 billion by 2020, leveraging existing structures and maximizing synergies. The multi-level structure supports continuous development, and the modular approach ensures a balanced combination of abstraction and ease of use.

More information