Documentation

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 XiP*2: 80 KiB to 256 RAM (in HW)

Non-XiP: 512 (or more) KB RAM (in HW)

XiP*2: 64-128 KiB RAM (in HW) RAM is needed for:
- Client Example (or your application)
- Pelion Device Management Client
- Mbed OS, drivers
- Network stack
- MbedTLS.

Client takes only part of the resources - see Client RAM and flash consumption for more details.

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

Verify your assumptions with your application and board combination.










Flash/Storage 1024 - 2048 KiB Flash in HW 512 - 1024 KiB Flash in HW Flash is needed for:
- Bootloader (typical size 32-64 KiB).
- Application (including Mbed OS).
- KVStore for credential storage (minimum 2 flash erase sectors, typically 8-16 KiB).
- Firmware download area.

See Client RAM and flash consumption for more details.

Verify your assumptions with your application and board combination.







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 RAM and flash consumption

Client RAM and flash consumption is greatly impacted by:

  • Board itself - board target code and network driver sizes vary dramatically.
    • Bootloader sizes for the board vary (with exactly same functionality) from 26 KiB to 58 KiB.
    • Network stacks vary in size from tens of kilobytes to megabytes (some Wi-Fi and cellular stacks).
  • Compiler - GCC_ARM, ARMC and IAR all behave differently and produce binaries with different sizes.
  • Compiler settings - optimizations for speed or size have an impact on the generated code.
  • C/C++ language features and libraries used in an application - Client has recently dropped using C++ Standard Library (STL) completely, as it adds 15 KiB of overhead.
  • Feature selections.
    • Adding a filesystem, for example for SD card or external flash adds tens of kilobytes of code and kilobytes of RAM.
    • Enabling traces can almost double the flash consumption.
    • Additional drivers or application logic required. A complex sensor driver can take several tens of kilobytes of flash.
Example configurations
  • GCC ARM version 6 (6-2017-q1-update) compiler.
    • IAR and ARM C will produce smaller binaries and smaller RAM usage profile.
    • GCC ARM was chosen as the reference compiler as it is free and everyone has access to it.
  • Release profile used when compiling.
  • Memory figures in the table include all memory usage (Mbed OS, Client example application, Mbed TLS, networking stack).
  • Firmware update capability is included.
  • We have the following references:
Item  Client min config  Client max config Client Lite
Board  NXP K64F  NXP K66F NXP K64F
Connectivity  ESP8266 *5  Ethernet (lwIP) ESP8266 *5
Client version  3.1.0  3.1.0 0.8.0
Mbed OS version  5.12.1  5.12.1 5.12.1
Storage  KVstore(TDBStore (Internal)) KVstore(TDBStore (internal)) NVStore
Features All optional disabled All enabled All enabled *6
Config file esp8266_minimal.json  eth_v4.json ram-minification.json
Example memory figures

Below are the memory consumption figures measured using the Client (Lite) example application.

Memory consumption Client min config  Client max config Client Lite
Bootloader size (flash, KiB) 20 20 20
 Application and Mbed OS size (flash, KiB) 296 392 230
RAM, static (KiB) 25 56 29
RAM, dynamic (KiB) 31 51 18
RAM, total (static + dynamic, KiB) ~57 ~107 ~47

Mbed OS linker report helps in understanding where your flash goes.

Note: The allocations in internal flash must always be aligned to flash erase sector size. So, even if the bootloader size may be 20 KiB only, the erase sector size forces you to allocate 32 KiB for it. Sector sizes are very board dependent, so check your board specification carefully.

We provide multiple bootloaders and the configurations that use SPI flash or SD card as firmware download storage are ~10 KiB larger as they have to include block device and SD driver.

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 MB for the root FS. However, if you add heavy stacks the size can easily grow up to 1 GB. 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, Wi-Fi 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 a
- 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.

*4 For 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.

*5 ESP8266 Wi-Fi has flow control (CTS, RTS) and reset connected with updated firmware (v1.7).

*6 Client Lite feature set differs greatly from the Client feature set, thus it is not comparable to Client.

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.