Here follows the definition of IoT Edge Platform given by G2.com
IoT edge platforms help facilitate localized computer processing on IoT devices. These devices constantly analyze streams of data including information about networks, actions, and anything else the device is connected to or interacting with. IoT edge platforms provide containerized modules to deploy on IoT devices, a runtime to execute actions locally, and a cloud-based interface for monitoring and management.
Companies use these technologies to reduce bandwidth usage for IoT devices, respond quicker to malfunction, and reduce overall network traffic. Shifting IoT analytics to the edge can also increase security by reducing the amount of data being transferred over networks.
There is some overlap between IoT edge platforms and IoT analytics software, but most IoT analytics solutions do not shift workloads to the edge so processing can be completed locally on the device. Many non-edge IoT analytics solutions simply gather large amounts of data and centralize the information and analytics processes.
To qualify for inclusion in the IoT Edge Platforms category, a product must:
- Provide edge modules to deploy on IoT devices
- Provide a containerized runtime to manage devices and execute actions
- Provide a cloud-based monitoring console for real-time edge analytics
IoT Catalyst is a Low Code/No Code IoT Edge Platform that offers IoT DevOps and IoT Device Management tools to make the IoT simpler, faster and cheaper than it has ever been.
As an IoT Edge Platform, all the business logic is pushed at the edge and it is managed by a single control-plane that works in any web browser: the IoT Catalyst Studio.
IoT Catalyst makes it possible to design IoT Edge Applications, securely store them in a central repository, and then select and dispatch on-demand to computation devices installed at the network's edges.
IoT Catalyst adds value to any IoT architecture helping to standardize communication between things and any IoT platform, and thus creating a fast-growing ecosystem of supported devices.
Future-proof IoT and Industrial IoT (IIoT) architectures are possible because, with IoT Catalyst, users can easily create, populate, and manage their IoT domain independently of any IoT platform. IoT Catalyst manages IoT while avoiding the risk of over-reliance on IoT technology vendors, as it makes a distinction between the IoT domain and the IoT platform concepts (which should not be considered identical...). In fact, IoT Catalyst has been designed to manage IoT domains in a totally independent way irrespective of the IoT Platform chosen (if any).
Thanks to IoT Catalyst it is possible to decouple the IoT domain from any specific IoT platform technology: provisioning of any device happens in one click to any of the supported IoT platforms (PTC, GCloud IoT, AWS IoT, Thingsboard, eSight, Azure, and many more) without changing the IoT application source code.
This means that:
1) No IoT platform-specific competencies are needed to create IoT end to end applications;
2) If initial requirements change, it is even possible to change the IoT platform itself while preserving the other investments (such as system integration and IoT driver creation).
Moreover, being an IoT Edge Computing technology completely separated from the higher layers, makes IoT Catalyst not only suitable to simplify IoT integration but capable of providing asset-intensive companies with additional revenues stream.
IoT Catalyst enables IoT Hosting: an innovative business model allowing a company to sell IoT-based services to customers sharing part of the IoT investments carried out for internal needs.
One of the distinctive values of IoT Catalyst is that it improves management for the integration of additional devices and sensors, allowing them to be reconfigured remotely without any field intervention and making them capable to talk with any external application with no need of changing the original IoT code written.
The following video gives an idea of how Iot Catalyst manages the digitization of an asset.
Here follows the list of the concepts and topics covered in this section:
-
1
IoT Domain
-
2
Digital Twin
-
3
IoT Catalyst Architecture
-
4
IoT Catalyst Managed Entities
Digital Things, Containers, Hypervisor and Adapters -
5
IoT Catalyst Edge Manager
-
5
IoT Catalyst Security
1. IoT Domain
The IoT Domain is the collection of software and hardware capabilities used to make the interaction possible between the IT and OT departments of an organization. A typical IoT Domain includes: IoT drivers, Digital Twins, IoT platforms, servers, edge computers, etc.
In our vision, the IoT Domain is the virtual space where Digital Twins live.
2. Digital Twin
A Digital Twin is the dynamic virtual representation of a physical object or system across its lifecycle, using real-time data and other sources to understand, predict, and optimize its performance
In IoT Catalyst, the first step in creating an IoT Domain is the creation of the models (i.e., blueprints) that give birth to the Digital Twins. A model is a collections of features including settings, data, events, functions, and actions that define the cyber-model as a whole.
The cyber-model is used to describe the capabilities of a Digital Twin, which notifies every IoT Domain entity of all the features and capabilities of each Digital Twin.
In order to feed the cyber-model of a Digital Twin with actual data gathered from its physical counterpart (the physical asset associated with the Digital Twin) and enable the issuing of commands (functions and actions), software logic is required.
The foundational elements of a Digital Twin are:
- Cyber-Model: describes the entity as a collection of settings, data, events, functions, and actions.
- "IoT Driver": Software containing the business logic to bi-directionally link the digital entity to the corresponding physical thing, process, etc. This business logic can be very complex in some evolved cases; adding AI capabilities to the digital entity, for instance.
A Digital Twin is born when a new digital entity is instantiated using a cyber-model and the associated business logic.
The key factor of success in creating future-proof, flexible, scalable, and powerful IoT solutions is the adoption, by IoT Catalyst, of a model-driven methodology to design an IoT domain.
3. Architecture
IoT Catalyst consists of two distinct execution environments. The centralized environment, where the control panel and all the microservices necessary for the management of the whole IoT domain reside, and the peripheral environment that manages the execution of IoT applications.
For clarity sake, we will use IoT Catalyst Studio to refer to the centralized execution environment and to all its components, and
IoT Catalyst Edge to refer to the peripheral execution environment.
IoT Catalyst Studio is distributed as a collection of docker containers — having a microservices-based architecture — and executed in the cloud or on-premises. IoT Catalyst Edge is available in different versions specific for Windows and Linux — it even runs on a Raspberry Pi Zero — and requires very limited execution resources. IoT Catalyst Edge can be installed on-premises — usually on IoT Gateways or industrial PCs — or installed and run in the cloud, too.
From the image above, the separation of the two different execution environments is evident.
The IoT Catalyst Studio is the set of technologies used to create, configure, store, manage, monitor, and update the entire IoT Domain. IoT Catalyst Studio is accessed to create new IoT driver models, to provision new driver instances, to access edge computers installed in some remote site, and to update the various system components. The IoT Catalyst Studio represents the command and control center.
The IoT Catalyst Edge is instead the set of technologies necessary to execute the instances of the IoT driver models.
The IoT Catalyst Edge It activates when physically connecting a new device to an IoT Gateway to collect data and control it remotely, as an example.
For this to be possible, a copy of the specific IoT driver for the connected device must be downloaded and installed on the IoT Gateway. This IoT driver must be downloaded from the central driver repository managed by IoT Catalyst Studio and installed locally on the IoT Gateway. Once this IoT driver has been installed, it must run, always be available to check its operation, and access the appropriate management functions: start, pause, update, remove, etc.
Here, the IoT Catalyst Edge is the set of technologies that make this possible in a fully-managed way.
The various components of the Catalyst Studio and the IoT Catalyst Edge are able to talk through a secure management channel thanks to the use of security certificates assigned to each component individually.
Communication is also always possible without the need for an APN or VPN, even if the IoT Catalyst Edge is hidden behind a deep network.
The following details the simplified schema of the communication channels used.
4. IoT Catalyst Managed Entities
The IoT Domain managed by IoT Catalyst contains several entities. Focus your attention — for the purposes of this document — on the key players in the digitization process: Digital Thing, Container, Hypervisor, and Adapter.
4.1 Agent
IoT Catalyst Agent is deployed on an edge computer to make it compatible with the IoT Catalyst technology. Once installed, the IoT Catalyst Agent is responsible for the following:
- the update and management (start/stop) of IoT Catalyst Hypervisors, if installed;
- the execution of automation campaigns managed by the Automation Service
IoT Catalyst Agent agents are incredibly efficient and designed to run on different types of hardware architectures as well on various operating systems ( Windows and Linux ).
4.1 Digital Thing
The IoT Catalyst Digital Thing technology enables users to design universal IoT drivers: once a driver is created for a specific type of device, that device communicate not only with the IoT Catalyst domain, but also with third-party IoT platforms and legacy applications in a native way.
The idea behind the IoT Catalyst Digital Thing is quite simple : IoT Catalyst Studio helps users write IoT drivers for interfacing their device in an IoT solution, in a totally decoupled way with respect for any other elements of the IoT stack. In the generated drivers, there is no trace of third-party APIs, even if the resulting Digital Twins are capable of native communication with the third-party IoT platforms or other legacy applications.
IoT Catalyst Digital Thing's main goal is to be focussed entirely on devices, in order to: describe a device via a bill of features (BOF), define and code the inner logic (i.e., the driver), communicate with a specific family of devices, and define the main settings injected via runtime in the driver.
The BOF is the collection of data, events, and actions that a device is capable of managing. It represents the manifest used by the connected device to inform the whole IoT Domain about itself and about its capabilities
4.1 Container
After designing your IoT Digital Thing, in order to interface a physical device, you need to create a new instance of the Digital Thing — which acts as the baseline model. This creates a specific environment to make it executable on an IoT Gateway. IoT Catalyst Container is the entity that manages the entirety of this process on your behalf.
The IoT Catalyst Container's main task is to allow the actual execution of the driver contained in an IoT Catalyst Digital Thing, which provides the capability to remotely manage the following tasks from a browser: mount/unmount operations (i.e., the choice of the target IoT Catalyst Hypervisor), start-up settings injection, start/stop/restart operations, visualization of logs and real-time data, and access to the real-time command console.
The IoT Catalyst Container technology makes it possible to decouple the interfacing activity of your devices and assets from the higher elements of the IoT solution stack. In fact, each IoT Studio Container encapsulates an IoT Catalyst Digital Thing (the IoT driver), providing a standard communication interface with the IoT platforms or other legacy applications.
IoT Catalyst Container gives actual instantiation and execution of the IoT Catalyst Digital Things created.
IoT Catalyst Digital Things — encapsulated by IoT Catalyst Containers — is how your Digital Twins take birth!
4.1 Hypervisor
The Catalyst IoT Hypervisor is the core component of the edge computing technology of IoT Catalyst. Entirely written in Python 3.4, it runs on any Windows, Linux, or MacOS device. IoT Catalyst Hypervisor transforms any device with computational capability in a polymorphic IoT Edge Gateway to which devices, senso\rs and actuators can be attached . Any Digital Thing designed with IoT Catalyst Studio can be sent in the form of a IoT Catalyst Container to any active IoT Catalyst Hypervisor.
Each individual IoT Catalyst Container is managed by the IoT Catalyst Hypervisor independently, allowing customization of the settings, start and stop, and all the IoT DevOps operations.
For each container, you can view its status, the messages exchanged with the control plane, and access to the two-way, real-time command console. You can use the console to issue Windows/Linux/MacOS commands to the box running the IoT Catalyst Hypervisor, thus gaining full control of your remote computation box.
4.1 Adapter
IoT Catalyst is the only solution on the market that allows connecting the same IoT edge driver with multiple target platforms at the same time , without requiring intermediaries and the need to modify the source code.
This very important function is performed by the IoT Catalyst Adapter component.
The Adapter is conceptually similar to a Digital Thing. Digital Thing deals with physical devices, while the Adapter is a double-faced component that deals on one side with external IT systems and, on the other side, with Containers (instances of Digital Thing). Similarly to a Digital Thing, it represents the model and the base code that must be cloned and instantiated every time you want to put an IoT driver in communication with customized platforms or third-party platforms such as AWS, GCloud, Azure, PTC Thingworx, etc.
What happens when a user chooses to put a remote IoT driver in communication with one or more platforms? The IoT Catalyst takes care of enriching the single IoT driver on demand with one or more specialized components created just in time; these components are instances of IoT Catalyst Adapters. Each adapter instance runs in the same execution environment of the Containers and the IoT Catalyst Edge, and communicates bi-directionally with the IoT driver on the one hand (to collect live data and submit commands), and with the external platform for which it was designed (to send data and receive commands).
The communication always applies the same security policy defined in the initial design phase without any risk of being accidentally disrespected or violated. This is why — thanks to the Adapter technology — IoT Catalyst acts as the security policy enforcement point for the whole IoT Domain.
6 Security
Another element that deserves attention is the description of how security is managed in IoT Catalyst.
All communications happen via encrypted and secured protocols (HTTPS, TLS), and each IoT Catalyst entity is authenticated using a TLS certificate. This means that IoT Catalyst adds an extra layer of security to the network access (VPN/APN) by profiling not only users but also every non-human component.
This is possible through an atomic profiling system and the implementation of an ad hoc security module in the MQTT message broker, which is used as a management channel.
For example, each IoT Catalyst entity has its own digital identity that corresponds to a read/write access to a specific subset of the broker's MQTT topics.
If the trust of a single system component at the edge level is compromised, such as a single Digital Twin, it is possible to revoke its authorization exclusively. Regarding the certificates, users can decide to employ certificates signed by a third-party certificate authority (CA) or self-signed certificates (with a self-managed CA authority).
It is also possible to gain user visibility to a subset of managed entities (IoT Catalyst Containers, IoT Hypervisors, IoT Dashboards) or even to a subset of API calls
The same level of security is applied when IoT Catalyst entities interacts with external applications. Client certificates never leave the edge gateway because IoT Catalyst supports secure storage for certificates (see FWD Edge XT datasheet for details).
