Docs › Release notes › Previous versions › Izuma Device Management: Previous versions › Pelion Device Management (May 2020)

Pelion Device Management (May 2020)

Pelion Device Management

Wi-SUN Field Area Network (FAN)

Wi-SUN FAN is a field-area network radio technology gaining popularity in outdoor infrastructure operations, such as automated metering infrastructure. This smart metering example is one of several use cases that need a proven, long-term technology option that avoids vendor lock-in; being standardized as IEEE 802.15.4g means that Wi-SUN is becoming increasingly popular.

Wi-SUN is a fundamental mesh connectivity technology; it operates in unlicensed frequency bands offering low bandwidth networks. Routing nodes forward messages from their neighboring nodes in addition to their own application traffic to border router(s), which then transfer the messages to the backend, using Ethernet or cellular backbone connections.

Pelion Device Management enables the deployment of end-to-end IoT solutions with Wi-SUN FAN technology using these components:

Wi-SUN FAN router node is preintegrated with Pelion Device Management Client, which allows developers to focus on application integration, as Pelion Device Management handles device management and monitoring services from the outset.
Mbed OS operated Wi-SUN FAN Border Router offers connectivity to the Pelion Device Management service. Both cloud and On-Premises deployments are supported.
Pelion Device Management offers unique services to Wi-SUN FAN router nodes, which communicate to the cloud using UDP, where packet acknowledgement can happen in higher layers (for example, CoAP level).

This feature is available now for preview by selected customers.

Device Sentry

When IoT devices are deployed into the field, it is important to be able to monitor their status and take corrective actions if there are problems. A powerful device management solution should not rely on the continuous vigilance of fleet operators to actively check the status of all devices. This is paramount in deployments with large numbers of devices, where the ability to manually track the status is more challenging.

Device Sentry is a system built into Pelion Device Management Client (supporting both RTOSes and Linux). It captures relevant data from the devices in a customer's fleet and transmits it to Pelion Device Management in the cloud, where the data can be processed.

You can flexibly configure Device Sentry to automatically collect metrics from devices, such as memory use, CPU behavior, network traffic and thread count. These metrics can indicate a wide range of unanticipated problems. For example:

High CPU usage may indicate unexpected firmware behavior.
Unexpected network traffic may indicate issues with network connectivity.
A combination of the two can be an indication of a security incident, such as an attempt to compromise device firmware through a remote attack.

You can organize the frequency of collection and the group of devices to be monitored through Insight Sessions. You can use an Insight Session to:

Define threshold values to compare values against expected norms.
Automatically raise alerts when devices behave incorrectly, for example when they exceed a defined threshold.

Device Sentry provides out-of-the-box monitoring with no additional development work. After configuring Device Sentry, you can leave it to guard the fleet of devices. This means that operational teams can reduce the time spent actively monitoring the fleet of devices; they can work in a more reactive way, when alerted to incidents occurring in real time. It can also mean that issues are detected earlier, reducing the affect and cost of restoring to an operational state should something unexpected occur.

This feature is available to selected customers.

Connection ID

When using Pelion Device Management Client to connect devices to the cloud, DTLS sessions are used by default to ensure device-to-server communications are secure. The device configurations, new device firmware image deployments and - most importantly - application data and control communication must be secure. To establish a DTLS session, a handshake operation is required between the device and the cloud.

The DTLS handshake is a heavy operation, consuming network bandwidth (2.2kB per handshake) and power (which may be at a premium on battery-based devices). In case of sleepy devices, a DTLS handshake forces the device to be awake for longer, forcing the sleeping periods to be longer to compensate.

The Connection ID (CID) feature removes the need for a new handshake on every connection. When the device and server complete a full handshake negotiation, they share a unique connection ID. For the upcoming connections, the device suggests the CID to the server, and if recognized within the timeout period of the session, the existing session can be reused. Using the CID, you can reduce the number of handshake operations to a few times each year

The Connection ID feature provides a number of benefits:

Devices (especially those using the UDP protocol) can go to sleep more often. The power consumption during the handshake is 100-1000 times bigger than when sleeping. You save power every time the device wakes up, for example to update a data resource value.
Reductions in bandwidth usage enable larger mesh network deployments.
When using the same CID session, you can use a different address each time, so this does not force a new handshake. This is useful, for example, in the case of Network Address Translation (NAT) in IPv4 networks, which can cause a change in the address.

See the IETF specification for more details.

This feature is coming soon for all customers.

Device Echo

More and more use cases see constrained devices establishing only limited or intermittent connectivity. This model could be the result of remote location, limited or expensive connectivity options or a conscious decision to minimize energy consumption and maximize battery life. However, transient connectivity can disrupt effective device management; the loss of device visibility and status can make the operator's life difficult.

Pelion Device Management resolves this challenge with the introduction of Device Echo, a service providing enhanced visibility to the state of devices that have previously connected. Device Echo provides access at any time to each device's resource values. It stores desired and last reported values, each with its own time stamp and status. This provides visibility to the most recent pending device commands for a given resource and enables operators to identify whether the last reported value is newer than the latest desired value.

The Device Echo service is accessible whether or not the devices are currently connected. This means fleet managers can make interactive monitoring applications or real-time operational decisions, according to the known current state of the device fleet. Pelion Device Management maintains the Device Echo service. Therefore, customers don't need to implement their own device status database.

This feature is available to select customers. The Device Echo will incur additional charges based on the amount of data stored and retrieved. Contact us for the details of the pricing model and availability.

Service availability verification service

Availability (sometimes referred to as "uptime") and responsiveness are important for a good user experience in any service. Especially in the case of an IoT service, it is important to know the exact status of the cloud service operation and the IoT devices. If you cannot connect to a device to retrieve its latest data, you must be able to troubleshoot the reason. You need to identify whether there is a problem:

With the cloud service.
Blocking network traffic getting between the devices and the cloud service.
Caused by an issue with the firmware or by the devices themselves.

Pelion Device Management provides a solution for global service availability measuring, with targeted coverage for each deployment region. To measure the service status, we connect to the service APIs using simulated devices from data center locations specified by the customer. We collect and aggregate the metrics to the Pelion Device Management deployment for the customer to consume in their own system monitoring solution.

These metrics are monitored by a 24/7 support team that keeps Pelion Device Management running, to ensure the Service Level Availability (SLA) targets are met. If there are unforeseen problems, the support team brings the service back into full operation in a timely manner.

This feature requires additional professional services engagement to provide a custom device test simulation. To meet your exact operational needs, you need to agree on the verification test lab locations and test cases and implement them together with Arm. Test lab operations will incur additional charges based on the resources consumed. Contact us for further details.

Developer experience - web application tutorial

Pelion Device Management provides powerful capabilities out of the box. For example, the Portal user interface enables you to perform and monitor device management operations.

However, many customers building their own IoT solutions have challenging use cases and complex environments and need to build web services using our APIs to achieve their goals. Every customer has different infrastructure and processes and may require additional skills and knowledge to prepare for development. Developers evaluating how to fit Pelion Device Management into their own solutions could benefit from a single example that pulls the details together in the context of an end-to-end web application.

We provide a web application example and tutorial that you can follow to learn more about the APIs and how to structure an application. The example doesn't illustrate all possible application environments and challenges, and it focuses on one language (javascript). However, you can apply the principles to any application architecture.

By following this tutorial, you can learn about:

Connecting your development board to the platform using the existing quick start guide and the steps needed to develop and integrate an application.
Subscribing to device resource changes through Device Management, storing the values in a time series database and retrieving the data values to provide a web service for a web application to consume.
An example web application front end, which pulls data from the web service API to create a visualization of the stored time series data.

A fully working open-source application with multiple deployment options accompanies the tutorial. See the tutorial, related other documentation and the web application example:

Pelion Device Management On Premises

Release 3.0

Pelion Device Management On Premises release 3.0 is a hybrid product that scales according to customer needs, use cases and location. This hybrid approach enables you to deploy Device Management On Premises on any type of cloud, bare-metal or datacenter environment to provide IoT device management capabilities to its users.

IoT projects can start out small, either as trials or where the service is highly localized. You may wish to optimize the investment in On Premises infrastructure and reduce risk for new initiatives.

Pelion Device Management On Premises already meets the needs of large-scale deployments and now extends its configuration to support smaller deployments. The new configurations provide a solution for customers wanting to deploy smaller numbers of devices cost efficiently. We now support configurations of 50k, 100k, 250k and 500k devices.

The new configurations support options for alternative components such as load balancers, firewalls and Hardware Security Module (HSM). These options and the addition of Kubernetes cluster support give integrators more flexibility in selecting components for smaller deployments and save costs.

You can scale up the new configurations up to 1 million devices or more. These configurations are compatible with cloud-based Pelion Device Management solution. Therefore, you can always move to a cloud based Pelion deployment, should that be more suitable for your purposes.

A small On Premises deployment is quick to set up, and you can scale it up as your deployment grows.

Available for all On Premises customers.

Native load balancer

Previously, load balancing was provided using F5 in our cloud environments, and On Premises customers were mandated to acquire one. We have removed the dependency on F5. This enables faster deployments, scaled to match your needs.

You can replace the commercial F5 product with a native load balancer:

With any affordable physical load balancer.
With no load balancer, so load balancing is done in DNS.
Based on the public Kubernetes cloud.

You can now deploy Pelion Device Management as On Premises or on cloud without F5. Without the need for expensive integration components, the solution is suitable for use in a wide range of use cases and vertical applications.

Benefits:

Reduced initial investment costs.
Faster to deploy, less dependencies and easier to maintain.
Reduced recurring costs related to load balancing.
Scalability to a larger installation.

Pelion Device Management Edge

Edge container orchestration

IoT deployments are increasingly implemented with a cloud-based service element, complemented and enhanced with a computing capability at the edge. This could be to enable preprocessing of high-volume sensor or video data, to reduce the amount of data sent at cost over low bandwidth and high latency network or to create an autonomous processing environment in which edge devices can make autonomous decisions based on installed application software.

Edge gateways provide a solution to enable edge processing. This introduces the challenge of managing and maintaining application distribution. Pelion Device Management solves this by creating an edge-centric ecosystem that is dynamically programmed and managed from the cloud. New application software, new machine learning models, software updates, security patches and modular peripheral changes are seamlessly supported through integrated container orchestration based on Kubernetes.

This capability brings advantages to IoT deployments:

Bring compute capabilities closer to the Edge, reducing network latency and bandwidth.
Maintain continuous uptime even with intermittent cloud connectivity.
Enable efficient use of hardware assets, helping to streamline digital transformation projects.
Manage software applications, machine learning models and more across the edge device deployment.

This feature will be available for preview to selected customers by June 2020.

Native tunneling solution

Deploying applications to your Edge gateway requires remote access to applications running inside containers. Previously, this required the use of costly third-party remote access capabilities, even if only a subset of the functionality provided for that cost was providing a benefit.

Pelion Device Management Edge now provides a native tunneling service. It provides access through the Pelion Device Management service, exposing a websocket API to enable connections to any application. To take advantage of this capability, you need to implement a microservice, which uses this tunneling capability to provide remote access.

There are strict operational limits on the provided connection. The service incurs additional charges, priced according to usage. The solution is available for selected customers. Contact us for details.

Secure device access and remote workflow management

Local access management to IoT devices, in particular controlling and managing deployed IoT devices, including Edge gateways, in the field, is a serious security challenge. This includes the management and enforcement of access permissions to specific users, such as service technicians, who can use the app to connect to devices out of network coverage, or where those devices don't have their own network connectivity.

Pelion Device Management App for mobile phones now enables secure device access and remote workflow management, which ties local access management to the enterprise user’s management system, so only authorized users can access and manage devices locally. This can be enforced even when the user’s mobile phone and the device are not connected to the network. This is achieved through the use of secure trust anchors on the device and synchronization of access tokens and event logs when the mobile application connects to the cloud.

The Pelion Device Management application provides benefits for remote devices:

Authorized control for access to IoT devices.
Different levels of access for different user groups, enabling strong enforcement of operational procedures.
Reduced operative time for each commissioning event.
Reduced number of configuration errors.
Workflow logs provide automated recording of maintenance events in the field.

This feature is available for all customers.

Gateway management - additional features

We have extended the current Device Management features to support new gateway use cases:

Device reset and reboot support container orchestration on Dell 3002 Gateways.
Remote gateway configuration management capability for network and logging.
Pelion-managed updates on Ubuntu Core on Dell 3002.

These features provide a number of benefits:

Pelion Edge helps to orchestrate and report the snap update process. The snap store update method lacks the controls to provide feedback of device software inventory to customers.
Remote Network Configuration replaces the Ubuntu command-line tools such as nmcli and mmcli through a remote terminal to configure the network interfaces.

These features are available for selected customers.

Pelion Device Management Client

Support for FreeRTOS

Given its layered architecture and porting abstraction layer, Pelion Device Management Client can support any OS, and many customers have a preference or a requirement to combine Pelion with an RTOS other than the native Mbed. One such example is the FreeRTOS product that's popular with embedded systems.

Therefore, in association with two of our key IoT ecosystem partners, NXP and Renesas, Pelion Device Management Client now offers support for FreeRTOS, beginning with the Client 4.4.0 release, removing the need for any additional development work beyond integration with the Client APIs.

Examples using NXP's popular LPC5400 series and Renesas RA6M3 boards are now available. You can use either of these targets or any other FreeRTOS target, with minimal porting effort:

This feature is available for all customers.

Support for Microchip ATECC508/608A secure elements

Pelion Device Management Client supports Microchip ATECC508/608A secure elements.

Preprovisioned secure elements enhance the security of your IoT solution. They solve challenges in a number of different security use cases, for example:

Third-party manufacturing security: no need to handle private keys in the factory; only assemble the preprovisioned secure element to the board.
Security threats: secrets generated within the secure element are never at risk during transmission and provide considerable resistance to attack because they are difficult to extract.

Device Management Client supports two Microchip secure elements out of the box, ATECC508 and ATECC608A. These chips offer a sensible secure element solution for you because they are available for €0.5 for a piece even in small volumes. There are also multiple packaging options to match the printed wiring board (PWB) size requirements. With some professional services work, we can also support other secure elements, as the abstraction model allows adding additional secure element drivers.

By default, we support using the Microchip Certificate Authority (CA) for development purposes, but for production use, you can set up your own CA.

This feature is available for all customers.

Yocto Zeus support

Open embedded Yocto is the most prominent embedded Linux build system used by nearly all chipset vendors. Pelion Device Management Client now supports Yocto release Zeus 3.0, released in October 2019. This demonstrates our ongoing commitment to Linux-based IoT devices using the secure Pelion Device Management solution.

The Zeus release brings you new kernel version supports (5.2/4.19), updated toolchains (gcc 9.2, glibc 2.30), critical security fixes and other improvements.

See the Raspberry Pi3 meta layer documentation for an illustration of how to use this solution.

This feature is available for all customers.

Client Lite Alpha 1.1

As IoT gets pushed further, broader and deeper, leveraging smaller and more constrained devices, the limitations of the conventional device management client stack become more pronounced.

In response to the needs of this new generation of ultraconstrained device designs, Arm has developed Pelion Device Management Client Lite. This lightweight version of the client enables customers to use smaller and more cost-effective IoT chipsets while maintaining a responsible level of security with full X.509 certificate-based authentication and encryption.

We offer a solution that works for the most minimal footprint:

No OS required, bare-metal event loop only (however, we also support threads, if you wish to use them).
Special version of Mbed TLS to take the dynamic RAM consumption and flash size requirements to a minimal range.
Full update capability with a new, size-optimized firmware update client.

The memory figures for the full solution allow us to have a board with full update capability with:

512kB flash and 64kB RAM (internal flash only solution) or
256kB flash, 64kB RAM and additional SPI-flash for the firmware image management area.

SPI-flash is a cost-effective way to handle the storage, if the application also needs to store data before uploading the data to the cloud.

Client Lite is available as an Alpha-level solution, suitable for proof-of-concept trials.

Documentation

Pelion Device Management (May 2020)