Cependant, les données doivent d'abord atteindre la couche où elles peuvent être collectées, transportées, puis traitées ou stockées. Bien qu'il soit possible d'accéder aux ressources matérielles (capteurs, actionneurs, systèmes embarqués) et de les contrôler via l'eAPI (interface de programmation d'application) pour le matériel embarqué grâce à une interface définie, jusqu'à présent, toutes les communications d'entrée/sortie matérielles devaient être effectuées manuellement pour chaque connexion périphérique et cloud. Lors du remplacement de matériel, d'une mise à niveau ou même d'un changement de fournisseur, de nombreuses personnalisations, voire toutes, doivent être réalisées à partir de zéro, potentiellement pour toutes les couches concernées, jusqu'à l'application finale. C'est précisément là qu'intervient l'UIC (interface d'interface utilisateur) : l'intégration des composants est simplifiée grâce à ses trois niveaux d'abstraction, qui permettent de partitionner de nombreux aspects de l'informatique IoT (Internet des objets). La norme d'interface UIC distingue la configuration des appareils (identification matérielle, affectation des appareils, correspondance valeur-information), la communication avec les capteurs et les actionneurs (contrôleur matériel) et la communication entre appareils (transfert et traitement des données). Avec plus de 450 offres de services cloud et un nombre encore plus important de configurations matérielles possibles, elle offre une approche très ouverte, efficace et pratique pour les solutions actuelles et futures de l'Internet des objets.
Plus précisément, l'architecture du connecteur IoT universel (UIC) se compose de trois interfaces : premièrement, l'interface du module de contrôleur embarqué (EDM), qui pilote les périphériques matériels connectés via des contrôleurs et fournit des informations provenant de capteurs, d'actionneurs ou d'autres sources locales. Deuxièmement, l'interface de configuration de projet (PCI) offre un mécanisme de configuration pour les systèmes embarqués. Elle détermine les périphériques à contrôler, la manière dont les données brutes sont ajoutées aux ensembles d'informations et le moment où ces données sont transmises au serveur. Enfin, l'interface de l'agent de communication assure le transfert des informations vers l'unité de communication, par exemple un serveur (cloud), notamment l'envoi et la réception d'ensembles de données ou d'événements. Ce qui distingue l'UIC, c'est son approche ouverte de la connectivité serveur (cloud/fog/M2M) et de son infrastructure associée, ainsi que de son matériel et de ses fournisseurs sous-jacents, du moins tant que l'EDM est pris en charge, et enfin, au niveau de la communication. Selon la configuration, cela permet la connexion à Amazon Web Services (AWS) via un module Qseven et MQTT, ainsi que la connexion à Microsoft Azure Cloud via XRCE à l'aide d'un module COM Express. Grâce à son abstraction, le middleware allégé ouvre la voie à une approche particulièrement flexible. Son approche ouverte et multiplateforme unifie l'accès à de multiples composants matériels de différents fournisseurs, tels qu'ADLINK, Congatec, Kontron, Portwell ou Seco, en utilisant un nombre croissant de plateformes cloud prises en charge, notamment AWS, People System Things (PST) de M2MGO, SAP HANA ou Microsoft Azure Cloud, et en employant une large gamme de protocoles (MQTT, XRCE, OPC/UA, etc.). De plus, UIC fonctionne sous Windows Embedded et Linux embarqué.
La norme UIC de SGeT offre une approche pratique et ouverte des solutions IoT et des applications Industrie 4.0 sur l'un des marchés à la croissance la plus rapide, estimé à 250 milliards d'euros d'ici 2020, en tirant parti des infrastructures existantes et en maximisant les synergies. Sa structure multiniveau favorise le développement continu, et son approche modulaire garantit un équilibre optimal entre abstraction et facilité d'utilisation.
