Skip to main content

production-deployment

The v1.0 integration flagship — a field-deployable IoT product that exercises factory provisioning → secure boot → OTA → remote attestation in one app. Every other example covers one library surface; this one covers the production lifecycle that ties them all together.

Source: examples/production-deployment/.

Lifecycle stages​

  1. Factory provisioning read-back. On boot, <alp/hw_info.h> reads the EEPROM manifest programmed at factory test. Production firmware treats this as the authoritative per-unit identity (SKU, serial, HW revision, factory date).
  2. Secure-boot attestation. MCUboot chain is verified by the bootloader; the application reports back the slot it's running from and the signature key ID.
  3. Application work. Runs whatever the device actually does — for the example, a small connected sensor reporting over MQTT with TLS.
  4. OTA receive + verify. Updates are pulled via Mender (Yocto) or signed MCUboot images (Zephyr); both paths go through <alp/security.h> for signature verification before slot swap.
  5. Remote attestation. Periodically signs a freshness nonce with the on-module OPTIGA Trust M and publishes the signature alongside the EEPROM manifest data so a back-end can prove the running firmware matches the provisioned identity.

board.yaml​

The v0.6 declarative-stack flagship — every block applied at production stance on AEN701 + OPTIGA-rooted TF-M:

som:
  sku: E1M-AEN701

preset: e1m-evk

cores:
  m55_hp:
    app: ./src
    peripherals: [i2c, gpio]
    libraries: [mbedtls]                # required by iot.tls: true (validator R3)
    iot: { wifi: true, mqtt: true, tls: true }
    memory:
      stack_kib:     8
      heap_kib:      64
      isr_stack_kib: 2
    power:
      sleep_mode:     standby           # disabled | idle | standby | deep
      wakeup_sources: [uart, gpio]

boot:
  method: mcuboot
  signing:
    algorithm: ecdsa_p256               # AEN family allow-list (validator R2)
    key_file:  keys/release-mcuboot.pub.pem
  slots:
    primary:   { size_kib: 480 }
    secondary: { size_kib: 480 }
  swap_algorithm:   scratch
  scratch_size_kib: 32
  anti_rollback:    false
  build_type:       Release             # propagates to MCUboot + TF-M sysbuild

ota:
  provider:      mender                 # provider-driven dispatch (ADR 0009)
  artifact_name: alp-prod-1.0.0
  signing_key:   keys/ota.pub.pem
  server:
    url:    https://hosted.mender.io
    tenant: ${MENDER_TENANT_TOKEN}
  poll_interval_s: 1800

storage:
  - name: app_data
    size_kib: 256
    fs: littlefs
    mount: /lfs/app
    flash_device: mram_main             # references the SoM preset's memory_map: region

security:
  psa:
    persistent_slots: 16
    its_storage:      mram_secure       # SoM memory_map: region
    ps_storage:       app_data          # OR a storage[].name from above
    tfm:              true
    attestation_root: optiga_trust_m    # rejected if the SoM doesn't ship OPTIGA

chips:
  - optiga_trust_m
  - eeprom_24c128

diagnostics:
  log_level: info
  modules:
    alp_iot:      warn
    alp_security: debug

For V2N targets, switch som.sku to E1M-V2N101, the board preset: to e1m-x-evk, and add an a55_cluster: core with image: alp-image-edge; the application surfaces are identical. Mender stays the same — provider: mender now accepts either a Yocto or a Zephyr core per ADR 0009.

Build​

west alp-build -b alp_e1m_evk_aen alp-sdk/examples/production-deployment
west flash

What it ties together​

SDK surfaceStage
<alp/hw_info.h>Stage 1 — factory manifest read
MCUboot + <alp/security.h>Stage 2 — boot attestation
<alp/iot.h> + <alp/security.h>Stage 3 — application traffic
MCUboot signed slot swap / MenderStage 4 — OTA
<alp/chips/optiga_trust_m.h>Stage 5 — attestation signing

See also​

Questions about this page? Discuss in Community Forum