In this post we are going to define a Reference Architecture for an IoT Platform, this architecture needs to be neutral regarding industries and use cases and also neutral regarding concrete approaches to model entities, devices, metadata, …
A Reference Architecture should be guided by these principles:
• Heterogeneity: The proposed model must accommodate a wide variety of scenarios, environments, devices, standards.
• Security: in the IoT world and its connection between the digital and physical worlds it is essential to build secure systems. The reference model includes security and privacy between areas including device identity, authentication, authorization, data protection, …
• Deployment: the platform allows you to quickly launch pilots with few devices and also scale to support millions of connected devices
• Flexibility: the heterogeneous needs of the IoT market requires the composition of solutions with different components and services. The reference model is created under the principle of being able to compose solutions based on individual components.
The figure shows the Building Blocks of this IoT Platform Reference Architecture:
Being an abstract architecture this architecture must be able to serve as a “reference” to map the largest number of IoT platforms.
With that goal in future posts we´ll map several platforms on this Architecture as Amazon AWS IoT Platform, Azure IoT Suite, Watson IoT Platform, Thingworx and Sofia2 IoT Platform.
In this first post we´ll describe the Building Blocks that compose it:
• Client Connector: represents a device connecting to the IoT platform through the Device Gateway module. Typically this component should offer:
· A secure communication channel
· Direct connectivity
· Support of standard protocols of communication with the platform (REST, MQTT, …)
· Bidirectional communication with the platform (from platform can be sent information to the client without the need to make a request
• SDKs: set of components in different languages and platforms to simplify the connectivity with the Platform abstracting the details of the underlying protocols. These libraries can be used directly embedded in an application and as agents.
• Device Server Gateway: part of the platform that enables remote communication from and to devices. It can be accessed over the Internet, on a VPN, or on private connections. It manages all aspects of communication, including:
· Communication Pattern
· Communication Protocol
· Authentication and authorization of the connected device
Allows monitoring and diagnostics of device connections as well as quotas and data collection.
• Stream Processing: once the data flow and the system has passed the Device Server Gateway arrives at this component that facilitates the execution of online rules on this information. It typically allows:
· Creating flows and rules in a visual and simple way
· Routing data to different destinations
· Take action based on content
· Processing of complex event processing
• Storage: stores the operational data sent by the devices, this repository is separate from the Device Registry (where the Device status is stored). Usually stores 2 types of information / access patterns:
· A stream of events sent by the device and
· Historical information and may aggregate on this information.
Must support geographic queries about this information
• Device Registry: it is a repository that allows to define and register the devices, as well as the attributes, metadata and configuration that handle a device. This information must be able to have a scheme to define each device.
• Analytics This block allows analytical treatment of the information managed by the platform, in real time and also in batch. Typically allows:
· Running Machine Learning Algorithms
· Visualization of information in the form of KPIs on Dashboards
· Tools and interfaces for data scientists to work with this information in an integrated way.
• Management: the Platform allows to manage all the blocks in a unified form, from the definition and provision of devices, authentication, rules, deployment, … also offers dashboards and KPIs to visualize the state of the devices, and simplifies the development of applications Business or display. Typically this layer is offered with an HTML5 + REST API interface
• Security This component is responsible for all aspects of security:
· Authentication and authorization of the connected device (requested by Device Server Gateway)
· Channel level security
· Authorization to users according to their role: high devices, rules, creation of Apps, access to device data
• UX Support this block implements the access to the visualization, either of data of devices, results of analytical processes, alerts, notifications, geolocation, … It can also provide or integrate interactive dashboards and facilities for web and mobile application development.
• Backend Support: represents the support offered by the platform for the development of business logic of the solution. It offers abstractions of devices, groups, users, roles, business rules, actions, … also allows access to all platform information, usually through APIS REST.
• Business Connector: this component is responsible for integrating the IoT environment with business systems such as CRMs, ERPs, … for example to access external databases, user profiles, schedules, Legacy systems, … the platform offers connectors and facilities For the development of connectors with these systems.
• Extension Points: this block is optional, allows to extend the platform in different points, for example to include new communication protocols, new connectors, …