This module provides an overview of the edge compute capabilities embedded within the Cisco Industrial Router portfolio and the Cisco IOx microservice framework for developing containerized applications. These containerized applications can be deployed at the edge of the IoT fabric to help extract IoT data from devices connected behind the gateway and transform that data for upstream consumption.
This module also covers how the cloud-hosted IoT Operations Dashboard (IoT-OD) can be used to centrally deploy and manage the entire deployment life-cycle of an IOx application to edge gateways in a scalable fashion. This involves the entire process from deploying the applications, starting, stopping and restarting the application, upgrading to a later version of the application, and finally deleting the application if no longer needed.
Disclaimer: While this document describes best practices and details on deploying and utilizing IOx for customized microservices, custom microservices are neither created nor supported by Cisco. The customer assumes all responsibility and risk associated with the development and use of such custom microservices.
Transformation of IoT edge generated data into business outcomes
Rapid system integration and edge application management
Availability of an Application Development Framework
Ability to centrally deploy and manage the entire application life-cycle
Support for Native Docker Tooling
Distributed edge compute
Availability of development and test sandboxes
Figure 1: Distributed Edge Compute and IOx Microserive Application Architecture
The key design guidelines for creating edge compute solutions include:
Devising methods of managing the information or sensor data received by the gateway via local processing and preparing it for transmission over the network backhaul.
Enabling effective bandwidth utilization, as desired, through local processing at the edge to transform, compress, or reformat data for upstream consumption.
Supporting real-time data processing for low-latency applications.
Converting or adapting legacy protocols to provide the information northbound via IP-based protocols or APIs.
Determining the location of decision making based upon data received—on the gateway device, on the local network, or at the head end.
Key Components of a Solution Using Edge Computing
Key Components enabling Edge Computing include the IoT edge gateway, the IOx framework for creating edge software, and IoT-OD for managing the edge applications. Each is described in more detail below.
IoT Edge Gateway Routers
IoT edge gateways are a critical component to the success of your IoT operations because they provide the ability for your IoT network to connect to local devices, applications, and ultimately to your cloud services. Cisco provides IoT gateways that also provide a layer of security to protect your IoT devices and to help prevent your IoT devices from being hacked. Cisco's IoT gateways can also function as a standalone device, processing data directly from sensors via Wi-Fi, wired, or serial input connections providing a battle-hardened device for the data you want to process at the edge.
There are two Cisco Industrial router models that provide Edge Compute capabilities with an ability to run IOx applications at the edge of the IoT fabric:
The IR1800 is a fleet-targeted mobile gateway that addresses most use cases for fleets. The goal is to provide an off-the-shelf solution for the widest possible number of fleet applications with the fewest number of SKUs and least amount of custom developments possible. This Fleet Gateway is a ruggedized and modular router integrating Wi-Fi and Cellular radios.
The IR1101 is like the IR829 and is a general-purpose industrial router but lacks Wi-Fi capability. Additionally, there are essential IOx differences in the IR1101 that are important to note. This information is provided below.
These routers ship with one Cisco provided IOxVM (virtual machine which enables IOx on the platform). All IOx applications run within this virtual environment. In certain cases, a customer may decide to install a custom operating system on the platform. In this situation, IOx support ceases to exist on the platform (and for the customer).
Figure 2: IOx Framework
The Cisco IOx framework provides a powerful platform for your Ops and App Developers to easily deploy applications to your IoT gateways. Cisco IOx utilizes Docker tooling to allow your development teams to build applications in a standard format that is familiar to cloud-native application developers. The Cisco IOx application environment combines the power of the Cisco IOS-XE and the Linux OS to provide highly secure networking. This enables you to execute IoT applications in the fog or at the edge with secure connectivity to the Cisco IOS software and get powerful services for rapid, reliable integration with IoT sensors and the cloud. Cisco IOx enables development and deployment of IoT business and control applications at the edge.
By bringing application execution capability to the source of the IoT data, customers can overcome challenges with high volumes of data and the need for automated, near-real time system responsiveness. Cisco IOx offers consistent management and hosting across network infrastructure products, including Cisco routers, switches, and compute modules. Cisco IOx allows application developers to work in the familiar Linux application environment with their choice of languages and programming models with familiar open-source development tools.
Figure 3: Cisco IOx Application Framework
IoT Operations Dashboard for IOx Life-Cycle Management
Building on Cisco IOx is IoT-OD. IoT-OD takes the best of Cisco IOx application management, adds IoT gateway management and automates/manages it for you as a cloud service allowing you to scale your operations. This provides ease of use for your Ops teams by allowing for both:
Auto-provisioning of Cisco IoT gateway devices
Easily connecting your gateways to your Kinetic account
Fog apps (for edge computing) are Cisco IOx applications that run on a Cisco gateway and transmit data from devices to the Cisco Edge Intelligence or other data destinations. Applications can be deployed and managed with the Cisco IoT-OD. Figure 4 depicts the high-level steps involved as part of the IOx development and deployment steps for an edge/fog application.
Figure 4: Cisco IOx Development Life-cycle
The Edge/fog application download process is embedded in the overall management of the gateway. When a gateway is powered on, it communicates with IoT-OD to download provisioning information and update/download Edge/Fog applications and ensure that the connected sensors are detected by the gateway. This way, a field technician can easily deploy a gateway that with minimal hands-on effort.
Beyond just the deployment of IOx applications, Cisco IoT-OD can be used to manage the entire life-cycle of an IOx application, including:
Centrally deploy an IOx application to a set of edge gateways.
Change the state of an IOx application (start/stop/restart).
Monitor the status of IOx applications.
Upgrade IOx application to the latest version.
View container and application logs.
Monitor events related to IOx application deployment.
The advantage of using Cisco IoT-OD is that you can now centrally deploy and manage the application on hundreds of gateways from a centralized management tool without having to log in or connect to each of the gateways individually. IOx applications can be deployed to a set of gateways, helping save deployment time and cost.
IOx Framework Details
The IR1101 and IR1800 gateway routers ship with one Cisco provided IOxVM (virtual machine which enables IOx on the platform. All IOx applications run within this virtual environment. In certain cases, a customer may decide to install a custom operating system on the platform. In this situation, IOx support ceases to exist on the platform (and for the customer).
These routers ship with one Cisco-provided IOxVM that enables IOx on the platform. All IOx applications run within this IOxVM.
In certain cases, a customer can decide to install a custom operating system on the platform. In this situation, IOx support ceases to exist on the platform (and for the customer).
The IR1101 features a 1200 MHz CPU, 4 GB memory, and 8 GB (4 GB usable) eMMC storage. Depending on the specific PID the IR1800 has either a 600 MHz or 1200 MHz CPU, 4 GB or 8 GB memory, and 8 GB (4 GB usable) eMMC storage.
Table 1: IR1101 and IR1800 Platforms - Key Resource Requirements
Key Resource Requirement
The Minimum IOS-XE version required for IOx support is 15.6(1)T1.
Application Types Supported
IR1100 and IR1800 platforms support LXC, and Docker type applications.
Application Resources Limit
IR1101 platforms have a total of 1255 units of CPU and 862 MB of memory for applications. IR1800 platforms have a total of 1617 units of CPU and 862 MB of memory for applications. Docker type applications can have maximum of 42 layers per application. At any time, IOx supports hosting 100 layers in total for all Docker applications installed on the device.
IR1101 and IR1800 platforms support NAT and bridge mode for application networking.
There are two serial ports (async0 and async1) available for applications. USB storage and USB serial capabilities for application are supported on this platform.
IR1100 and IR1800 platforms support application signature verification, which is enabled by default.
IOx services is enabled for IR800 platforms. IOx services like GPS, CANBUS, Serial port access, and more are supported out-of-the-box.
IOx nodes may have different CPU architectures, so it becomes very complex to characterize an application’s performance or requirements on each of them. IOx attempts to bring consistency and uniformity by using the notion of resource profiles. A resource profile encapsulates a set of resources (CPU, memory, etc.) under a unique name in a consistent fashion across all Cisco IOx platforms.
The intent of resource profiles is to allow developers to obtain some level of consistency when they test their applications on one platform and want to deploy the same applications on other platforms. Currently, only CPU and memory are characterized under a resource profile.
Resource Profile Definitions
Currently, the pre-defined resource profiles named "c1.tiny", "c1.small", "c1.medium", "c1.large", and "x1.xlarge" are provided. Each profile specifies a pre-set amount of memory and CPU resources to allocate for an application. However, the exact set of profiles and their values supported on a specific platform is a function of the available resources on that platform. Also, if one of the pre-defined resource profiles do not meet your requirements, you can always define your own custom profile based on the resources required for your application.
Memory assignment is platform agnostic and can be directly assigned based on the application requirements irrespective of the platform. However CPU resources are highly platform dependent and performance may vary based on the underlying CPU architecture.
To abstract these disparate characteristics to application developers and provide a uniform and consistent view, CPU resources are expressed in the form of “units”. This means an app with “x” CPU units would have similar performance on all Cisco supported heterogeneous platforms.
The CPU unit values for a platform are obtained by executing standard benchmarking tools on that platform and assigning a unit value based on their relative score when compared against a standard base platform.
To get a relative idea of what those units could mean in comparison to a standard CPU, here is a sample comparison with a generic x86 Intel platform:
Based on the benchmarking results, an x86-based 64 bit Intel Xeon processor with one core of CPU @ 2GHz will have 10000 CPU units. Based on this value developers can extrapolate and test an application in their devnet sandbox environment based on the same CPU characteristics and check the CPU units required for an app.
A note about resource bounds:
The CPU units allocated to an app are the minimum guaranteed. This means that at any given point in time depending upon the number of applications running, an app under consideration will get the guaranteed CPU units and may even get more than that if there is no other contention for CPU units.
Memory, however, is a hard limit. That is, at no point in time will the application get more memory than what is defined. Going beyond this limit typically results in a KILL signal to the application.
Table 2: Resources Available on Devices
Supported Application Types
ARM 64-bit (aarch64)
ARM 64-bit (aarch64)
Cisco's DevNet provides in-depth resources for learning about how IOx works, and provides many hands on examples for building and maintaining edge applications using LXC and Docker containers.
Additionally, if you want to learn how to leverage Cisco IOT-OD to deploy and manage applications (including Edge Intelligence), refer to the IoT OD documentation.