Device resources

Principle

LiveObjects offers a resource feature that allow customers to follow devices reported resources, manage new resource versions, and update device resource with fresh version.

The main goal is to provide resource update facility, where the update principle is :

  • The Device connects and exchanges with LiveObjects.

  • The Customers defines some resources for his tenant,

  • The Customers asks LiveObjects to update device resource versions for some devices.

  • The Device communicate with LiveObjects to process the update.

  • LiveObjects reports to the Customer the current state of updates and device resources.

Manage and follow resource update

LiveObjects provides to the Customer DM resource related API in order to:

Manage resource inventory for his tenant :

  • add, update, remove resource versions,

Manage device resources :

  • get device resources reported versions,

  • set, or reset device resources requested versions,

Follow and manage update operations :

  • create device resource update operation.

  • cancel an update.

  • get, or list device updates states,

Manage and follow resource update
@startuml
scale 0.8
skinparam BackgroundColor transparent
skinparam componentStyle rectangle

node Resource {
     component "Version management" {

       component "Device update"#lightblue {
         [updates operations]
       }

       component "Device resources"#lightblue {
         [reported versions]#lightgrey
         [requested versions]
       }

     }
     component "Resource inventory"#lightblue {

       [versions]
       [resources]

     }
}
@enduml

Here is an example of Customers in-sequence actions :

  • create a new resource version for his tenant,

  • async trigger an update by setting a requested versions for a given device,

  • get latest device update to track update operation state.

Resource versions management

A resource is a versioned binary content (for example a device firmware). You can manage a repository of resources in your tenant account.

For each resource you can manage multiple resource versions.

Live Objects can track the current versions of resources on a specific device.

Customers can plan an update by setting a requested version for a given device resource version, or can order immediately an update.

Device resource requested versions Device resource versions updated
@startuml
scale 0.6
skinparam {
  BackgroundColor #EEE
}
skinparam component {
  FontSize 14
  FontName Courier
  BorderColor lightblue
  BackgroundColor lightyellow
  ArrowFontName Impact
  ArrowColor blue
  ArrowFontColor black
}
skinparam frame {
  BackgroundColor white
}
skinparam folder {
  FontSize 12
}
skinparam rectangle {
  FontSize 12
  BorderColor brown
  BackgroundColor lightyellow
  ArrowFontName Impact
  ArrowColor grey
}
node "Device" {
    frame "Resources"#LightYellow{
        rectangle "R1:V1"#LightGrey
        rectangle "R0:V0"
    }
}
node "LiveObjects" {
    folder "ResourceInventory"{
        frame "LO Resources"#LightYellow{
            rectangle "R1"
            rectangle "R0"
        }
        frame "LO Resources Versions"#LightYellow{
            rectangle "R1V2"
            rectangle "R1V1"
            rectangle "R0V1"
            rectangle "R0V0"
        }
    }

    [R1] <|.. [R1V2]
    [R1] <|.. [R1V1]
    [R0] <|.. [R0V1]
    [R0] <|.. [R0V0]
    folder "DeviceResource"{
        frame "requested"#LightGrey{
            rectangle "requested R1V2" as requested_R1V2
        }
        frame "reported"{
            rectangle "reported R1V1" as reported_R1V1 #LightGrey
            rectangle "reported R0V0" as reported_R0V0
        }
        [R1V1] <.. reported_R1V1
        [R1V2] <.. requested_R1V2
        [R0V0] <.. reported_R0V0
    }

}

[R1:V1] .. reported_R1V1
[R0:V0] .. reported_R0V0
@enduml
@startuml
scale 0.6
skinparam {
  BackgroundColor #EEE
}
skinparam component {
  FontSize 14
  FontName Courier
  BorderColor lightblue
  BackgroundColor lightyellow
  ArrowFontName Impact
  ArrowColor blue
  ArrowFontColor black
}
skinparam frame {
  BackgroundColor white
}
skinparam folder {
  FontSize 12
}
skinparam rectangle {
  FontSize 12
  BorderColor brown
  BackgroundColor lightyellow
  ArrowFontName Impact
  ArrowColor grey
}
node [Device] {
  frame "Resources"#LightYellow{
          rectangle "R1:V2"#LightGreen
          rectangle "R0:V0"
  }

}
node [LiveObjects] {
  folder "ResourceInventory"{

    frame "LO Resources"#LightYellow{
      rectangle "R1"
      rectangle "R0"
    }
    frame "LO Resources Versions"#LightYellow{
      rectangle "R1V2"
      rectangle "R1V1"
      rectangle "R0V1"
      rectangle "R0V0"
    }
      [R1] <|.. [R1V2]
      [R1] <|..[R1V1]
      [R0] <|.. [R0V1]
      [R0] <|.. [R0V0]
  }
  folder "DeviceResource"{
    frame "requested"{
        rectangle " "
    }
    frame "reported"{
        rectangle "reported R1V2"#LightGreen
        rectangle "reported R0V0"
    }
    [R1V2] <.. [reported R1V2]
    [R0V0] <.. [reported R0V0]
  }
}
[R1:V2] .. [reported R1V2]
[R0:V0] .. [reported R0V0]
@enduml

Optional compatibility restrictions can be configured between versions to avoid compatibility issues when switching from a version to another.

Live Objects will refuse a resource update request that don’t match the compatibility restrictions.

Different kind of updates

As today, Live Objects supports two kind of updates:

  • a resource update that rely on http-updater updater (with mqtt and Lwm2m devices):

LiveObjects provides the resource in the form of a secure (https) or insecure (http) URL. Then the Device will decide when to act as http client and query that URL to retrieve the content.

  • a resource update that rely on lwm2m-updater updater with Lwm2m devices (Beta):

LiveObjects rely on Twin to send LwM2M operations, and will send the resource to the Device via downlink operation (ex. Twin write).


Here is a summary of resource updates mode compatibility and feature matrix

Updater Connectivity Update trigger

http-updater

MQTT

set requested version

create update

http-updater

LwM2M

create update

lwm2m-updater

LwM2M

create update

Resources inventory

Resources and versions definitions

Customer defines for his tenant a set of resources.

A resource is:

  • a resourceId: a unique identifier (ex. X113DevFirmware, EPROM7300_V12).

  • a label (optional)

  • a description (optional)

  • a connector (optional): the default related updater

  • some meta-data

  • some aliases (optional)

For each resource, Customer then defines one or more resource versions.

A resource version is:

  • a given unique version identifier (ex. 1.0, 1.1a),

  • a file content,

  • a checksum of the file content,

  • an optional list of the compatible versions from which you can update to this firmware.

Resources aliases

You can configure zero, one or several aliases on a resource to help you manage your resource update operations.

An alias can be used to replace with a string of your choice a resource version when requesting a new target for a resource.

For example you could create an alias preprod to refer or target the 1.1a resource version.

You can use up to 5 aliases per resource.

A same version can be used in several aliases. An alias key must be unique.

Resources versions compatibility

When a resource version includes at least one or more compatible versions, LiveObjects must check that the current device resource reported version is compatible in order to target an update to this resource version.

When a resource version compatible versions is empty or missing, LiveObjects is able to target an update to this resource version without version check.

For example, if 1.1a compatible versions are [0.8, 1.0, 1.1], then

  • a device which reports 0.8 as current version is compatible

  • whereas a device which didn’t report current version, or which reports 0.9 (or 1.2) version is NOT compatible and cant be updated to 1.1a.

Resource definition API examples

Create a new resource

POST /api/v0/rm/X113DevFirmware
{
  "connector": "http-updater",
  "resourceId": "X113DevFirmware",
  "label": "X113 DEV",
  "description": "X113 firmware of box, in DEV mode.",
  "metadata": {
    "BoxSeriesSuffix": "FF1Fxx42"
  }
}

Response

{
    "tenantId": "5ae04ef29a92790fd7f2a5e4",
    "resourceId": "X113DevFirmware",
    "label": "X113 DEV",
    "description": "X113 firmware of box, in DEV mode.",
    "connector": "http-updater",
    "metadata": {
        "BoxSeriesSuffix": "FF1Fxx42"
    },
    "creationTs": 1677496010873,
    "updateTs": 1677496010873
}

Remove a given resource

DELETE /api/v0/rm/X113DevFirmware

Create a new resource version

POST /api/v0/rm/X113DevFirmware/version
{
  "file": "iVBORw0KGgoAAAANSUh...UVORK5CYII=",
  "checksum": "9WeAuNlX/WaappCx4sSMYQ==",
  "resourceVersionId": "1.0",
  "compatibleVersions": ["0.5","0.8","0.9"]
}

This sample adds a new X113DevFirmware firmware resource version 1.0. This version is compatible with following versions: 0.5, 0.8, 0.9.

  • file attribute is base64 encoded file content (abbreviates in the example above).

  • checksum is md5 of the raw firmware content encoded in base64.

Example of generating md5 checksum :

  import com.google.common.hash.Hashing;
  import com.google.common.io.BaseEncoding;
  import java.io.File;
  import java.nio.file.Files;
  import org.apache.commons.io.FileUtils;
  import org.junit.Test;

  // ...

  File file = new File("C:/tmp/myFirmware.bin");

  byte[] fileBytes = FileUtils.readFileToByteArray(file);
  String fileB64 = BaseEncoding.base64().encode(fileBytes);

  byte[] fileMd5Sum = Hashing.md5().hashBytes(fileBytes).asBytes();
  String fileB64OfMd5Sum = BaseEncoding.base64().encode(fileMd5Sum);

  System.out.println("::fileB64> " + fileB64);
  System.out.println("::checksum> " + fileB64OfMd5Sum);

Remove a given resource version

DELETE /api/v0/rm/X113DevFirmware/version/1.0

This sample removes X113DevFirmware firmware resource version 1.0.

Version management

Device declaration

Depend of the protocol, the device could report the current version of his resources.

This device initiated declaration is mandatory when relying on resources with compatibility restrictions.

But LiveObjects is also able to execute update operation without device declaration when relying on resources with NO compatibility restrictions.

  • For MQTT, please refer to Current Resources publication section.

  • For LwM2M, as today there is no device declaration, and so update must rely on resources without compatibility restrictions.

Version operation

Set or Reset requested version

Customer can set requested versions on devices :

In order to plan an update, Customer can record some intention : set a requested versions on one or more device resources.

This way represent an asynchronous trigger of the update operation because the update operation is created at LiveObjects initiative: when we know that the device is compatible, and when the device is ready to accept a new update (cf. conditions bellow).

Customer can reset requested versions on devices :

To remove any update intention, the reset operation will clean the requested version.

In that case, there is a chance that the update were already created/started : in that case LiveObjects will cancel related update too.

Note that http-updater will be used if no updater has been declared as connector for the resource

Create an update

Customer can create an update operation on devices :

In order to immediately trigger an update, LiveObjects let you create a device update directly. This way represent a synchrone trigger of the update operation: the update operation is started at Customer initiative.

This operation may be immediately rejected in some case:

  • we already know that the device is not compatible,

  • an update is already in progress on that device.

When the device is not ready, or when we don’t know if he is compatible, then the update will stay in his initial state(PENDING), and will progress later.

Note that http-updater will be used if no updater has been declared as connector for the resource

Update trigger

Here is a summary of updates conditions

Connectivity Updater Update conditions

MQTT

http-updater

Mqtt connection is established, the device is listening resource update requests, and the compatibility restrictions (if any) are fulfilled.

LwM2M

lwm2m-updater

LwM2M device is connected, the device supports and instantiate the first Firmware Object (/5/0), the target resource has no compatibility restrictions, the device supports the delivery process :

- firmware update state (/5/0/3) shall be idle

- in-band delivery with lwm2m-updater : device must support push delivery method (/5/0/9)

- out-of-band delivery with http-updater : device must support pull delivery method (/5/0/9) and support http or https protocol (/5/0/8)

http-updater

Version management API examples

Set device resource requested version

Request

POST /api/v1/deviceMgt/devices/urn:lo:nsid:sensor:temp001/resources/MyResource001
{
    "version": "1.1",
    "metadata" : {
        "secured" : true
    }
}

Response

{
  "reported": {
    "version": "1.0",
    "timestamp": "2020-03-12T10:43:18.350Z"
  },
  "requested": {
    "version": "1.1",
    "timestamp": "2020-07-23T14:53:03.959Z"
  }
}
JSON Params Description

reported

current device resource status

requested

requested resource status

version

resource version

timestamp

date of resource version association

metadata

metadata associated with this device (if any)

Set device resource version using alias

Configure an alias

Request

PUT /api/v0/rm/MyResource001
{
  "connector": "http-updater",
  "metadata": {
    "secured": true
  },
  "versionAliases" : {
      "prod" : "1.1",
      "preprod" : "1.2"
  }
}

Response

{
  "resourceId" : "MyResource001",
  "connector" : "http-updater",
  "metadata" : {
    "secured" : "true"
  },
    "versionAliases" : {
      "prod" : "1.1",
      "preprod" : "1.2"
  },
  "creationTs" : 1563191282476,
  "updateTs" : 1595594676082
}

Set requested version alias

Request

POST /api/v1/deviceMgt/devices/urn:lo:nsid:sensor:temp001/resources/MyResource001
{
    "version": "prod",
    "metadata" : {
        "secured" : true
    }
}

Response

{
  "reported": {
    "version": "1.0",
    "timestamp": "2020-03-12T10:43:18.350Z"
  },
  "requested": {
    "version": "1.1",
    "timestamp": "2020-07-23T14:53:03.959Z"
  }
}

The requested alias must exist and meet the compatibility restrictions

Reset device resource version

Request

DELETE /api/v1/deviceMgt/devices/urn:lo:nsid:sensor:temp001/resources/MyResource001/requested

This DELETE call will remove the requested version of the device resource MyResource001 if related update has not been triggered.

If an update already exists for this device resource, then requested version is untouched. If the update is active, internally, a soft cancel is done.

Create resource update

Request

POST /api/v1/deviceMgt/devices/urn:lo:nsid:sensor:temp001/resources/MyResource001/updates
{
  "requestedVersion": "1.0",
  "connector": "http-updater",
  "metadata": {
    "secured": true
  }
}

Response

{
    "id": "5f3bf1ecb23f3277805478a7",
    "resourceId": "MyResource001",
    "created": "2023-03-02T15:21:16.128Z",
    "updated": "2023-03-02T15:21:16.128Z",
    "initialVersion": "0.8",
    "requestedVersion": "1.0",
    "connector": "http-updater",
    "status": "PENDING",
    "metadata": {
      "secured": true
    }
 }
JSON Params Description

resourceId

device resource to update

created

resource update creation date

updated

resource update update date

initialVersion

device resource initial version

requestedVersion

device resource requested version

connector

updaterConnector to use. Can be http-updater OR lwm2m-updater.

If not provided, the connector associated to the resource is used.

If the resource has no associated connector, http-updater is used.

metadata

metadata associated to this update

Update Operation

Update states

Customer can get, or list resource updates.

This is different states values for a resource update :

State Description

PENDING

This is update operation initial state. The device is not yet ready or didn’t report his current version.

PREPARING_CONNECTOR

The update operation is now in progress and related update connector is initializing (internal).

PREPARING_ASSET

verify the device state or ask to the device to accept update.

WAITING_TRANSFER_INFO

waiting the device to accept the update

TRANSFER_PENDING

resource transfer is ready to start

TRANSFER_IN_PROGRESS

resource transfer is in progress

TRANSFER_SUCCESS

resource transfer is just done with success

CANCELED

The update operation has been canceled. This is a final state.

ERROR

The update operation has failed. This is a final state.

DONE

The update operation is done successfully. This is a final state.

Update timeouts

An active update has 2 timeout windows:

  • after the resource update request (LiveObjects → Device request with http-updater update).

  • for the overall update (for http-updater, and lwm2m-updater updates).

After the resource update request:

  • the device does not confirm the resource update request and does not download or report the version. After 5 minutes, the update returns to the PENDING state.

  • the device accepts the resource update request but does not download or report the version. After 5 minutes, the update will end with a timeout error (ERROR state).

For the overall update

  • an active update (update with a state not in DONE,CANCELED,ERROR) MUST NOT be older than 24 hours. After 24 hours, the update will end with a timeout error (ERROR state).

Cancel an update

There is multiple ways to cancel an update :

  • reset device resource requested version to cancel a set requested version,

  • soft cancel a resource update.

  • hard (aka. force) cancel a resource update.

The "reset" method will clean an expected requested version. If the update has already been triggered and is always active, a soft cancel is internally done.

The "soft" cancel update method will interrupt an active update in the following state : PENDING, PREPARING_CONNECTOR.

The "hard" cancel update method will interrupt an active update in the following state : PENDING, PREPARING_CONNECTOR, PREPARING_ASSET,WAITING_TRANSFER_INFO, TRANSFER_PENDING, TRANSFER_IN_PROGRESS, TRANSFER_SUCCESS.

Update API examples

Cancel resource update

Request

POST /api/v1/deviceMgt/devices/urn:lo:nsid:sensor:temp001/resources/updates/MyResource001/status?force=true
CANCELED

Response

HTTP Code:

200 OK

Updaters

In order to send the binary content to a device, Live Objects is built to provide different type of transfert protocols.

Those protocols are handled by updaters.

Updaters can support configuration parameters called metadata.

  • Http-updater

Live Objects provides a http-updater updater that allows the device to download the resource using HTTP protocol. http-updater is available with devices that have MQTT or Lwm2m (through "out-of-band" mode)

http-updater supports the following metadata:

Meta-data Description

secured

To enable https link for resources update, the default value is set to false (i.e. http link). It’s possible to set this "secured" metadata from device resource metadata, resource metadata, or update operation metadata.

  • Lwm2m-updater

Live Objects provides a lwm2m-updater updater that relies on LWM2M Specifications to process an update.

As today lwm2m-updater supports the push mode and rely on "Firmware(5)" object to read device firmware status, write, then execute firmware package and read firmware update result.

lwm2m-updater has no specific metadata.

Resource update process

Resource update with MQTT connector and HTTP updater

Live Objects will prepare the resource on public available endpoint and send update information to the device.

The device is responsible to download the resource, and then report his state to LiveObjects .

Trigger

How to trigger a resource update:

  • You can set the requested version of resources for a specific device in Live Objects that will then try to update the resources on the device as soon as the device is available for resource update.

  • You can trigger by creating an update directly.

step 1 - Resource update context

If your device is connected in "Device mode", please refer to the MQTT device mode part for messages that your device can send or receive. There is some practical examples in Resources update section like Current Resources publication.

step 1) Device resource update context
@startuml "Resource Update context"
scale 0.8

participant "Customer" as customer

box "LiveObjects" #LightBlue
  participant "Resource manager" as rm
end box

participant "Device" as device

activate customer

== Resource management API ==

customer -> rm: define resources versions
rm --> rm: update versions

== Current resource version declaration ==

device -> rm: current resources
activate device
deactivate device


== Device resource management API ==

customer -> rm: set device resource requested version
rm --> rm: update requested version

customer -> rm: reset device resource requested version
rm --> rm: remove requested version

customer -> rm: list device resource versions

@enduml

step 2 - New update

  • customer creates an update directly via API. cf. create resource update example.

  • or Live Objects automatically triggers an update for not honored requested resource versions set.

Pre-requisites: a new update is activated when

  • the device is ready to receive resource update (resource capability is available),

  • there is no update in progress.

When there is compatibility restrictions, then the device resource current version MUST be known.

Device resource update steps
@startuml
scale 0.6

  participant "Customer" as customer

  box "LiveObjects" #LightBlue
    participant "Resource manager" as rm
  end box

  participant "Device" as device

== 2 - New update ==

activate rm

alt #Lightgrey Customer initiative

  customer -> rm: create update
  rm --> rm: trigger an update

else #Lightyellow LiveObjects initiative

  device -> rm: connect & subscribe
  activate device
  rm --> rm: trigger an update
  note left
    eligible requested version
  end note
  hnote over rm #yellow : PENDING
  activate rm #FFBBBB
end

==3 - Prepare connector ==

  hnote over rm #yellow : PREPARING_CONNECTOR
  rm -> rm: prepare connector (file, link)

== 4 - Prepare asset ==

  hnote over rm #yellow : PREPARING_ASSET
rm -> device: update request [link,version]

  opt Device ack request
  device --> rm : accept
  end

== 5 - Transfer ==

alt Device download

  device -> rm: download
  note left
      whole or chunk
  end note
  rm -> rm: download progress
  hnote over rm #yellow : TRANSFER_IN_PROGRESS
  rm --> device: content
   hnote over rm #yellow : TRANSFER_SUCCESS

else #LightPink Update cancel

  customer -> rm: cancel update
  rm -> rm: cancel request, delete download link
  hnote over rm #yellow : CANCELED

else #LightPink Transfer timeout

  rm --> rm: update set as ERROR
  note left
    device never download.
  end note
    hnote over rm #yellow : ERROR

end

== 6 - Final ==

alt Device update

  device --> device: update
  note left
    device checks file integrity, updates internal resource and may reboot.
  end note
  device -> rm: current resources
  rm --> rm: check resource version
  alt #Lightgreen version match
    rm --> rm: update set as DONE
    hnote over rm #yellow : DONE
  else #Lightpink version mismatch
    rm --> rm: update set as ERROR
    hnote over rm #yellow : ERROR
  end

else #Lightpink Device side failure case

  device --> device: update failed
  note left
     device refused update request or was unable to perform update.
  end note
  device -> rm: update error
  rm --> rm: update set as ERROR
  hnote over rm #yellow : ERROR


else #LightPink Update timeout
rm --> rm: update set as ERROR
note left
  update takes too much time
end note
    hnote over rm #yellow : ERROR


end

@enduml

step 3 - Prepare connector

  • Live Objects prepares the resource version binary and generates a download link.

step 4 - Prepare asset

  • Live Objects sends the download link and resource version id to the device

  • optional the device can respond to indicate whether it accepts the new resource version or not.

  • optional the device can send a customized error. The operation will be stated as failed

step 5 - Transfer

  • the device can download the binary.

  • optional at anytime, the operation can be cancelled. In this case Live Objects will remove the download link. cf. the section dedicated to cancellation.

  • when the device does not start the download, then timeout can occur cf. section dedicated to timeout.

  • when the device has not responded to the request and does not start the download, the update returns to the PENDING state.

step 6 - Final

  • download is done

  • the device can check the file integrity using the provided md5, and perform internal updates.

  • to acknowledge the binary reception and the update, the device sends a new current resources message.

  • Live Objects compares the current and expected resource version and updates the operation status accordingly.

http-updater resource update states

Device resource update states
@startuml
scale 0.6

hide empty description

(*) --> [ START: update trigger] PENDING

if "//Waiting for device //"
	-[#yellow]-> [ Cancel resource update] CANCELED
else
	--> [ Device is connected and ready \n to receive firmware update] PREPARING_CONNECTOR

if "//UpdaterConnector response//"
	--> [download link is ready] PREPARING_ASSET
else
	-[#yellow]-> [Cancel resource update] CANCELED

PREPARING_ASSET -[#A9A9A9]-> [update request sent to the device] WAITING_TRANSFER_INFO

if "no request ack and no transfer timeout ?"
  -[#grey]-> [yes] PENDING
else
  if "ack received but transfer timeout ?"
    -[#orange]-> [yes] ERROR
  else
	--> [Updater connection open] TRANSFER_PENDING
  endif
endif

TRANSFER_PENDING --> [Download begins] TRANSFER_IN_PROGRESS

if "//Download in progress//"
	-[#yellow]-> [Force cancel]  CANCELED
else
	--> [100% transfered]  TRANSFER_SUCCESS
	if "//current resource version// \n //matches target version ?//"
		--> [yes] DONE
	else
		-[#orange]-> [no] ERROR
	ERROR#orange --> (*)
	DONE#lightgreen --> (*)
	CANCELED#yellow --> (*)

@enduml

Resource update with Lwm2m connector - (Beta)

APIs allow to manage lwm2m-updater resource update only for LWM2M connector.

Live Objects will prepare te resource and send it to the device with a downlink operation.

The device MUST be compliant with related standard to accept the resource, and report his state to LiveObjects.

Trigger

How to trigger a resource update with lwM2M connector :

  • You can trigger by creating an update directly.

step 1 - Resource update context

  • the customer defines some resources, and some resource versions.

As today, you must use resource without compatibility restrictions.

step 2 - New update

  • customer creates an update directly via API. cf. create resource update example.

  • customer selects the connector : "lwm2m-updater" for push update or "http-updater" for pull update.

Pre-requisites: a new update is activated when

  • the device is ready to receive resource update (resource capability is available) : Lw device is connected and instantiate object /5/0,

  • there is no update in progress.

  • the device supports selected delivery method and http(s) protocol if "out-of-band" update is selected.

Device resource update steps
@startuml
scale 0.6

  participant "Customer" as customer

  box "LiveObjects" #LightBlue
    participant "Resource manager" as rm
  end box

  participant "LW Device" as device

== 2 - New update ==

activate rm

  customer -> rm: create update
  note left
    Customer initiative
  end note
  rm --> rm: trigger an update
  hnote over rm #yellow : PENDING
  activate rm #FFBBBB

==3 - Prepare resource ==

  device --> rm : device online with /5/0 instance
  note left
    Conditions are ok
  end note
  activate device
  hnote over rm #yellow : PREPARING_CONNECTOR
  rm -> rm: prepare file [version]

== 4 - Prepare device ==

  hnote over rm #yellow : PREPARING_ASSET
       loop #lightyellow
        rm -> device: READ Firmware /5/0
          hnote over device
            FW state (3), protocol support(8), delivery method(9)
          end note

        alt #lightgreen read OK, state=IDLE, protocol supported, delivery method supported
          hnote over device #lightgreen : 0:IDLE
          device --> rm: state value
          hnote over rm #yellow : TRANSFER_PENDING
        else #LightPink http-updater: protocol or delivery method not supported
          rm --> rm: report error, update set as ERROR
          note left
            Device is not compatible
          end note
          hnote over rm #yellow : ERROR
        else #LightPink read not OK or state != idle and loop max retries reached
          rm --> rm: report error, update set as ERROR
          note left
            Device is not in state to update
          end note
          hnote over rm #yellow : ERROR
        else #lightyellow loop: read not OK or state != idle and loop max retries not reached
          rm --> rm: await X ms (X: exp. backoff from 30sec to 8h)
        end
      end

== option: interruption ==

opt #LightYellow Update cancel

  customer -> rm: cancel request
  rm --> rm: update set as CANCELED
  hnote over rm #yellow : CANCELED

else #LightPink Transfer timeout

  rm --> rm: update set as ERROR
  hnote over rm #yellow : ERROR

end

== 5 - Transfer ==
  rm -> rm: get resource version
  hnote over rm #yellow : TRANSFER_IN_PROGRESS

alt #lavenderblush lwm2m-updater (push)
  rm -> device: WRITE /5/0/0 Firmware package content
else #lavender http-updater (pull)
  rm -> device: WRITE /5/0/1 Firmware package URI
end
  hnote over device #lightgreen : 1:DOWNLOADING
  device --> rm: write result

alt #lavender http-updater (pull)
  rm <- device: read package content
end

== 6 - Transfer verify result ==

  loop while (download is not finished)
    rm -> device: READ /5/0/3, 5/0/5
    device --> rm: state, update result value
  end

  alt #lightgreen downloaded
    hnote over device #lightgreen : 2:DOWNLOADED
    note over device : state = 2:DOWNLOADED \nresult = 0:INITIAL
    rm --> rm: transfer success
    hnote over rm #yellow : TRANSFER_SUCCESS
  else #LightPink failed or max retries reached
    rm --> rm: report error, update set as ERROR
    hnote over rm #yellow : ERROR
  end

== 7 - Execute update ==

    rm -> device: EXECUTE /5/0/2
    device --> rm: execute result
  alt #LightPink execute failed
    rm --> rm: report error, update set as ERROR
    hnote over rm #yellow : ERROR
  end

== 8 - Await update result ==

  loop while (update not finished)
    rm -> device: READ /5/0/5
    device --> rm: update result value
  end

  alt #lightgreen success
    hnote over device #lightgreen : 1:UPDATED_SUCCESSFULLY
    rm --> rm: update success
    hnote over rm #yellow : DONE
  else #LightPink update failed or max retries reached
    rm --> rm: report error, update set as ERROR
    hnote over rm #yellow : ERROR
  end


@enduml

step 3 - Prepare resource

  • LiveObjects internally prepares the requested resource version content to send.

step 4 - Prepare device: await device initial state

  • LiveObjects will use Twin operations to ask to the device the first Firmware instance (/5/0).

This provides some relevant informations : state (/5/0/3), protocol support(/5/0/8), delivery method(/5/0/9).

In order to start a firmware update sequence, following conditions apply :

  • the device state MUST be 0:IDLE.

  • (when using http-updater) protocol support and delivery method MUST be compatible with underlying update.

  • On unexpected read/state issue, the read operation is retried with a retry backoff mechanism. Note that on unexpected compatibility there is no retry, the update is directly moved to ERROR.

  • On unexpected read/state issue and max retry attempts reached, the update is moved to ERROR.

  • On satisfying conditions, device update will go to the next step : transfer.

option - Interruption

During an update in progress, some interruptions can occur:

NOTE: once the update request (step 4 - prepare device) has been sent, the cancel or timeout interruption impacts only on the update state. Customer can order a new update that will overwrite current residual update operation and restart a fresh update from scratch.

step 5 - Transfer operation

In case of push update (in-band write)

  • Live Objects sends the firmware package to the device with Lwm2m write operation.

  • Live Objects will rely on Twin WRITE operation to push the content of the resource to the device.

In case of pull update (out-of-band)

  • Live Objects has created a HTTP(s) download link and provides this URI to the device.

  • Device downloads the package content from this URI.

step 6 - Transfer verify result

  • resource is moving on device side

  • the device is responsible to update his internal state (ex. from 1:DOWNLOADING to 2:DOWNLOADED)

  • Live Objects will rely on Twin READ operation to get back Firmware state (/5/0/3) and Firmware update result state (/5/0/5).

  • Live Objects expects state to be 2:DOWNLOADED and result state to be 0:INITIAL.

  • Live Objects reads state retries in the limit of max retries : cf. DM Resource limitations

  • on success, the transfer is considered as a success and the update moves to the next step,

  • on read issue or unexpected states after max retries, the update moves to ERROR state.

step 7 - Execute firmware update

  • Live Objects will rely on Twin EXECUTE operation Firmware update execute (/5/0/2).

  • resource is already on device side

  • the device can perform internal operations, updates, reboot, etc.

  • to acknowledge the binary reception and the update operation, the device is responsible to update his internal Firmware update result state.

step 7 - Await device update result state

  • update is in progress, then done on device side

  • the device is responsible to update his internal Firmware update result state (/5/0/5) to 1:UPDATED_SUCCESSFULLY

  • Live Objects will rely on Twin READ operation to get back Firmware update result state (/5/0/5).

  • Live Objects expects state to be 1:UPDATED_SUCCESSFULLY.

  • Live Objects reads update result retries in the limit of max retries : cf. DM Resource limitations

  • on success, the overall update is considered as a success and the update is DONE.

  • on read issue or unexpected states after max retries, the update moves to ERROR state.

lwm2m-updater resource update states

Device resource update states
@startuml
scale 0.6
hide empty description

(*) --> [ START: update created] PENDING

if "//Waiting for device //"
	-[#yellow]-> [ Cancel resource update] CANCELED
else
	--> [ Device is connected  \n and support lw firmware object] PREPARING_CONNECTOR

if "//UpdaterConnector response//"
	--> [resource version is ready] PREPARING_ASSET
else
	-[#yellow]-> [Cancel resource update] CANCELED


PREPARING_ASSET --> [update request sent to the device, and read state] WAITING_TRANSFER_INFO
if "//READ state value//"
	-[#grey]-> [state is NOT 0:IDLE]  PENDING
else
    --> [device is 0:IDLE] TRANSFER_PENDING
else
    -[#orange]-> [read error or max read retries] ERROR
else

TRANSFER_PENDING --> [get resource version and transfer started*] TRANSFER_IN_PROGRESS
note on link
   transfer started:
    - push transfer : start writing package on Lwm2m device
    - pull transfer : provide package URI to Lwm2m device
end note

if "//READ firmware state//"
	-[#yellow]-> [Force cancel]  CANCELED
else
	-[#orange]-> [read error or max read retries] ERROR
else
	--> [state=2:DOWNLOADED and result=0:INITIAL]  TRANSFER_SUCCESS


if "//EXECUTE Firmware update//"
	--> [result=1:UPDATED_SUCCESSFULLY] DONE
else
	-[#orange]-> [read error or result >1 or max read retries] ERROR


	ERROR#orange --> (*)
	DONE#lightgreen --> (*)
	CANCELED#yellow --> (*)

@enduml