Every THING is Internet of Thing

AWS IoT: Device Management

 
  • Akhilesh Moghe
  • Feb 21, 2020

Device Management:

AWS IoT Device Management makes it easy to securely onboard, organize, monitor, and remotely manage IoT devices at scale. In this blog we will explore AWS IoT Device management in details.

On-Boarding & Provisioning of Devices:

  • Onboard connected devices in bulk.
  • Onboard new devices by using:
    • the IoT management console or
    • APIs to upload templates that you populate with information like:
      • device manufacturer
      • serial number
      • X.509 identity certificates
      • security policies
  • Devices may either connect directly to IoT Core or connect indirectly via an AWS Greengrass powered gateway.
  • AWS IoT provides four ways to provision devices:
    • Single-thing provisioning
    • Bulk provisioning
    • Just-In-Time Provisioning (JITP)
    • just-In-Time Registration (JITR)

Single device provisioning:

  • Ideal use-cases:
    • When your IoT solution requires you to provision either one device or a small number of devices at a time.
    • If your company only has a handful of devices and you expect this number to grow slowly.
  • Ways:
    • Using Management Console
    • Using AWS CLI Commandline interface AWS CLI: IoT Thing creation AWS CLI: IoT Thing Certs and Policy creation
    • Using register-thing API call

Bulk provisioning of devices:

  • Ideal use-cases:
    • In situations such as migration of IoT devices.
    • In situations where your IoT device provisioning needs may be sporadic or unpredictable.
      • An example of this operation might be a situation where your company has purchased or produced a large number of new devices that require immediate provisioning.
    • In a situation where the devices that sat on the shelf may have expired certificates, for instance.
  • Details:

Just-in-time-provisioning:

AWS IoT Device Provisioning JITP

  • Ideal use-cases:
    • When you have a reached a point where it makes sense to consider provisioning in advance!
      • Like in cases of Consumer Products, which are produced in bulk but for a long time are not purchased.
      • Such products need activation whenever they connect for the first time to cloud.
      • The manufacturer cannot predict when a device will be used first-time and act on provisioning process.
      • So, in such situations JITP is an ideal way.
  • Just-In-Time Provisioning (JITP) allows you to register devices dynamically.
  • In order to use JITP:
    • You register your own CA with AWS IoT,
    • Enable automatic registration within AWS IoT
    • Associate the provisioning template to your CA.
      • Provisioning Template
    • You will also generate your own public key infrastructure (PKI) keys and certificates
    • And then copy them to your devices.

    Register your CA certificate, to create your own client/device certificates:

  • When your device connects to AWS IoT for the first time, AWS IoT automatically calls the RegisterThing API, its certificate is registered, and a notification is published to an internal topic $aws/events/certificates/registered/certificateID.
  • By using the AWS IoT Rules engine, the registration event can trigger an AWS Lambda function that takes the appropriate steps you need to meet your workflow requirements—for example, merging content from other resources (such as an on-premises database).
  • Detail Steps for JITP:

Just-in-time registration (JITR)

AWS IoT Device Provisioning JITR

  • Ideal use-cases:
    • Just-in-time registrations makes the most sense when your IoT solution requires flexibility.
    • If your company produces several different types of IoT devices, it may make the most sense to use just-in-time registration to ensure that individual IoT devices are provisioned based on their specific type.
    • For instance, you may use different device templates for light bulbs and door locks using just-in-time registration.
  • With JITR, when you connect to AWS IoT with the device certificate for the first time, the service will detect an unknown certificate signed by a registered CA and will auto-register the device certificate.
  • On successful registration, AWS IoT will publish a registration message on a reserved MQTT topic and disconnect the client.
  • This MQTT registration event will trigger the attached AWS Lambda rules engine action, which will complete the provisioning of the certificate.
  • After these steps, your device certificate will be ready to connect and authenticate with AWS IoT.
  • One of the key benefits to JITR is flexibility. While JITP only offers static provisioning of IoT devices (with Provisioning Template), JITR allows you to dynamically determine how to register and associate your certificates, policies, and things.
  • Detail Steps for JITP:

Comparison of JITP vs JITR

JITP-JITR-Workflow

JITP-JITR-comparison

Organize Devices:

  • group your device fleet into a hierarchical structure based on function, security requirements, or any other category.
  • Use of Device Organization:
    • manage access policies
    • view operational metrics
    • perform actions on your devices across the entire group

A Thing == A Device:

  • In AWS IoT, things are identified by a unique name.
  • A thing is stored in the registry as JSON data.
    • :warning: IoT Devices with valid certificates can connect to AWS IoT without a thing name registered for them..

Thing Attributes:

  • Things can have Attributes, as name-value pairs that can be used to store information about the thing, such as its serial number or manufacturer.
  • Thing name can be used as the default MQTT client ID (~though this is not mandatory, using this way, simplifies use of Shadow, Certificates).
  • Attributes of a thing can be used to search all things with specific attribute value.
    • :heavy_check_mark: e.g. let’s say Attribute is Company Name = “Persistent”

Thing Types:

  • Things with a thing type can have up to 50 attributes.
  • Things without a thing type can have up to three attributes.
  • A thing can be associated with only one thing type.
  • Thing Types are Optional.
  • There is no limit on the number of thing types you can create in your account.
  • Thing types are immutable.
  • Deprecate/Delete Thing Type:
    • We cannot change a thing type name after it has been created.
    • But we can Deprecate a thing type at any time to prevent new things from being associated with it.
      • All existing things associated with the thing type are unchanged.
    • Deprecating a thing type is a reversible operation. You can undo a deprecation.
    • Delete thing types that have no things associated with them.
    • Only deprecated thin types can be deleted.

Thing Groups

  • We cannot rename a group once created.
  • Groups can have Hierarchy, i.e. one group in another.
    • But thing group cannot be member of multiple thing groups.
  • Thing group can be mapped as child of another group only at creation time,
    • i.e., Parent of a thing group cannot be changed after child group creation.
  • A group can have max 100 direct child groups.
    • group all floors within a building
      • group all rooms on the same floor
        • group all sensors in a room
  • Each group can have up to 50 Attributes ().
  • Attach a policy to a parent group and it is inherited by its child groups, and by all of the things in the group and in its child groups.
  • Configure logging options for things in a group.
  • Create jobs that are sent to and executed on each thing in a group and its child groups.

    Key Advantages of Thing Groups

    • Updating IoT Policies gets easier with thing groups, as Policies are applied to all child groups and things registered in child and root thing group.
    • When a thing is moved from a thing group to another thing group, new policies are dynamically applied w.r.t. new thing group.

    Limitations with Thing Groups

    • If a thing group will be a child of another group, the parent must be specified at the time of creation
    • A thing can belong to one or more thing groups (up to 10 groups).
    • Cannot add a thing to more than one group in the same hierarchy.
    • Groups cannot be renamed
    • Group names cannot contain international characters

    Dynamic Thing Groups

    • Dynamic thing groups update group membership through search queries. Using dynamic thing groups, you can change the way you interact with things depending on their connectivity, registry, or shadow data.
    • Because dynamic thing groups are tied to your fleet index, you must enable the fleet indexing service to use them.
    • With dynamic thing groups, you can specify a dynamic thing group as a target for a job. Only things that meet the criteria that define the dynamic thing group perform the job.
    • You can attach a policy to a dynamic thing group. The policy applies only to those things that meet the criteria that defines the dynamic thing group.
    • dynamic thing groups will automatically add devices that meet your specified criteria and remove the devices that no longer match the criteria.
      • overrideDynamicGropus:
        • Override dynamic thing groups with static thing groups when 10-group limit is reached. If a thing belongs to 10 thing groups, and one or more of those groups are dynamic thing groups, adding a thing to a static group removes the thing from the last dynamic group.
        • You can use the overrideDynamicGroups flag to make static groups take priority over dynamic groups.
    • Dynamic Vs Static Thing Groups:
      • Membership in dynamic thing groups is not explicitly defined
      • Dynamic thing groups cannot be part of a hierarchy
      • Different commands are used to create, update, and delete dynamic thing groups
    • Dynamic thing group creation is not instantaneous.
      • The dynamic thing group backfill takes time to complete. When a dynamic thing group is created, the status of the group is set to BUILDING.
      • When the backfill is complete, the status changes to ACTIVE.
      • One more status is REBUILDING.
    • APIs/Action for Dynamic Thing Groups:
      • CreateDynamicThingGroup
      • DescribeThingGroup
      • UpdateDynamicThingGroup
      • DeleteDynamicThingGroup
  • Detail steps for Thing Groups:
  • Fleet Indexing is a managed service that enables you to index and search your registry data, shadow data, and device connectivity data (device life-cycle events) in the cloud.
  • After you set up your fleet index, the service manages the indexing of updates for your thing groups, thing registries and thing shadows.
  • You can use a simple query language to search across this data. You can also create a dynamic thing group with a search query.
  • AWS_Things is the index created for all of your things.
  • AWS_ThingGroups is the index that contains all of your thing groups.
  • AWS IoT keeps indexes continuously updated with your latest data.
  • Further References:
  • Fleet Indexing offers several options to index data from AWS IoT:
    • OFF: no indexing at all
    • REGISTRY: index registry data only
    • REGISTRY_AND_SHADOW: index registry data and shadow data
    • REGISTRY_AND_CONNECTIVITY_STATUS: index registry data and connectivity status
    • REGISTRY_AND_SHADOW_AND_CONNECTIVITY_STATUS: index registry data, shadow data and connectivity status
  • Detail steps for fleet indexing:
  • Use-cases:
    • You can use fleet indexing when you want to take an action on a specific subset of the IoT devices in your fleet.
    • You can also use fleet indexing to help you make informed decisions.
      • Suppose your company’s products newly released have features that only work on specific versions of the software. You can use fleet indexing to figure out which devices are running outdated versions of the software.
  • find device records for devices in the registry based on any combination of device attribute or state so that you can perform actions across the device group.
  • use device connectivity indexing to quickly discover which devices are currently connected or disconnected to AWS IoT.

Monitoring Devices:

events capabilities:

  • Whenever a thing, group or type resource is created, updated, or deleted, IoT Device Management will post an MQTT message to a topic. We can match these messages via rules to take whatever actions we would like to make.
  • Configure different log levels, such as, info, debug, warnings, and errors for different principles, such as thing groups.
  • These logs will be published into CloudWatch in JSON format, that can easily parse and search through your logs.

Remote Management of devices:

  • Push software and firmware updates to devices in the field to patch security vulnerabilities and improve device functionality.
  • Execute bulk updates, control deployment velocity, set failure thresholds, and define continuous jobs to update device software automatically so they are always running the latest version.
  • Send actions such as device reboots or factory resets remotely to fix software issues in the device or restore the device to its original settings.
  • Digitally Sign and __Verify__files that you send to your devices.

WORKSHOP AWS IOT DEVICE MANAGEMENT

Search