Mistake on this page? Email us

Requirements for Client production devices

Hardware and software requirements for Pelion Device Management Client/Lite production devices.

Tip: If you are still in development, you can see Pelion Device Management-compatible devices on our Boards page.

Client hardware requirements for Mbed OS

Capability Device Management Client Client Lite Comments
CPU Performance as in Cortex-M3 or better. *1 Performance as in Cortex-M3 or better. *1. No specific CPU architecture requirements. CPU performance impacts (D)TLS handshake duration.
RAM and Flash memory XiP*2: 128 KB to 256 RAM
Non-XiP: 512 KB RAM (or more)

1024 KB Flash (or more)

Device Management Client 1.4 example uses 83 KB RAM and 139 KB flash (including Mbed OS, MbedTLS but with external network stack).




XiP*2: 64 KB RAM with external IP stack

512 kB Flash (or more)

Client Lite 0.5.0 example uses 29-32 KB RAM and 85 KB flash (including Mbed OS, MbedTLS but with external network stack).



These requirements imply the typical whole hardware requirement - Device Management Client and Client Lite will use only a part of the RAM and flash listed. The numbers are for reference only and you must verify the figures for your combination. The network stack size, for example, can vary from a few kilobytes (external module with its own RAM/flash) upto 900 kilobytes. Mbed OS version used also impacts memory consumption.

For example:

- Device Management Client with Mbed OS on UBLOX_EVK_ODIN_W2 using its Wi-Fi needs 1.3 megabytes of flash.
- Device Management Client with Mbed OS on UBLOX_EVK_ODIN_W2 using its Ethernet with LWIP needs 404 KB of flash.
- Bootloader uses 32 KB of flash.
- Mbed TLS takes 30-71 KB of flash.
- CMSIS/RTOS takes 15 KB of flash.
- lwIP stack takes 40 KB of flash.

The selected network stack, application complexity and size will impact your total memory requirements. Verify your assumptions with your application and board combination.

Mbed OS linker report will help in understanding where your flash goes.

For development purposes, we recommend that you use a platform with larger RAM and flash to allow the use of debug images with traces, which are significantly larger.














Networking IP based networking. IP based networking. Ethernet, Wi-Fi or similar.

Note that the maturity and capability of different Wi-Fi modules varies a lot.

For non-IP based connectivity, see Device Management Edge and its protocol translator capability.



Root-of-Trust (RoT) Recommended. Recommended. Secure memory for hardware root of trust.
On-die flash as minimum. See note *3.
True Random Number Generator (TRNG) Recommended. Recommended. See note *4.
Clock Needed. Not needed. Either an
- Real Time Clock or
- some low-frequency crystal (for sleepy devices) or
- SW clock (non-sleeping devices) that provides the device proper time.

This is needed to handle any certificate validity time attacks.




Secure boot module Optional. Optional. The secure boot module checks the integrity and authenticity of the firmware at boot time to protect the device from reflash attacks.

Client hardware requirements for Linux

Capability Device Management Client Comments
CPU Single core. Any single-core capable of running Linux SW is enough. If your application is heavy, please consider those needs separately.
RAM 1 MB Device Management Client itself is extremely light, but your Linux distibution and other parts of your stack can impact this significantly. Typical Linux boards have 256 MB to 1 GB of RAM which is typically more than enough for the Device Management Client itself.

Verify your assumptions with your Linux distrubution and application stack combination.

Flash/Storage Minimum 128 MB Typical Linux distributions seem to require at least 30 megabytes for the root FS. However, if you add heavy stacks the size can easily grow up to 1 gigabyte. The storage must be partitioned in a particular fashion for firmware update to work.

Verify your assumptions with your Linux distrubution and application stack combination

Networking IP based networking. Ethernet, WiFi or similar. For non-IP based connectivity, see Edge and its protocol translator capability.
Root-of-Trust (RoT) Recommended. Secure memory for hardware root of trust.
On-die flash as minimum. See note *3.
True Random Number Generator (TRNG) Recommended. See note *4.
Clock Needed. Either an
- Real Time Clock or
- some low-frequency crystal (for sleepy devices) or
- SW clock (non-sleeping devices) that provides the device proper time.

This is needed to handle any certificate validity time attacks.




Secure boot module Recommended. The secure boot module checks the integrity and authenticity of the firmware at boot time to protect the device from reflash attacks.

Notes:

*1 Device Management Client (or Lite) does not require any specific Arm CPU, all of the code is C/C++ and as long as we have a working C and C++ toolchain - any CPU will do. Currently porting has been done to multiple Arm, Intel x86, Intel x64 and MIPS architectures.

*2 XiP is an abbreviation for eXecute-in-Place, which allows you to execute the static code directly from internal flash, without loading it all to RAM.

*3 Device identity and keys stored on the device need to be protected for their integrity and confidentiality. Some of these must be immutable. The recommended practice is using a local root of trust, stored on die, which protects information stored on an external flash. The local root of trust is stored on die in a one-time-programming bits or internal flash, with access control and optional write protection. This protects the device from physical access attacks (such as reflash attacks) and software vulnerability exploitations, which extract the keys and remotely take over the device.

*4For secure communication and secure device identity, a Random Number Generator needs to be seeded with cryptographically strong entropy. The recommended practice to provide such a seed is by TRNG hardware capability. Alternatively, if your platform has no TRNG, you can implement software-based DRBG and rely on entropy or key injection during device production. The NUCLEO-F411RE board is an example of this.

Software stack

You need to choose an OS for your IoT Device. Device Management Client is pre-integrated with Mbed OS, which provides the capabilities described below. However, you can choose a different RTOS and port Device Management Client by implementing a Platform Abstraction Layer for it. See the porting guide for information about porting. We provide a porting layer to Linux.

If you plan to use Device Management Client with an OS other than Mbed OS, you need to choose a platform and components that provide the following capabilities.

Capability Description Comments
OS * Mbed OS v5.10.0 or later.
* Linux: Ubuntu 16.04 LTS, Yocto v2.3.x
Porting to other OS / RTOS is possible - see porting guide.
Storage Flash and filesystem drivers.
Networking * Networking Drivers.
* TCP/IP.
* DNS resolver.
* Optional (recommended): DHCP.


* IP over the HW supported bearer.
* DNS and DHCP simplifies the device configuration during deployment.
Crypto/TLS Mbed TLS or equivalent Crypto and TLS/DTLS libraries. You should configure Mbed TLS to use only the latest TLS cipher suites, because older ones become vulnerable.
TRNG Driver Platform’s TRNG driver.
Crypto module programmed to use the TRNG.
System Tick System’s tick availability at a rate of at least one tick per millisecond (higher than 1Khz tick). The tick is the OS (platform) kernel system tick counter.
Software-reboot Ability to software-reboot the device. Required for tests and for Device Management Update.
Bootloader Bootloader with FW update capability. Required for Device Management Update.
Optional, if you do not use Device Management Update.
We provide a bootloader you can use with Mbed OS and reuse in other platforms.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.