"Control plane" considerations

Discussions around potential new RFID/LLRP device service highlight that it can be inconvenient to control some device interactions via existing EdgeX mechanisms.

Example device profile extract:

deviceResources:
  - name: "Action"
    properties:
      value: { "type": "String", readWrite: "W" }

  - name: "ROSpecID"
    description: "Client-generated Reader Operation Specification Identifier"
    properties:
      value: { type: "uint32", readWrite: "W", defaultValue: "1" }

  - name: "AccessSpecID"
    description: "Client-generated Access Specification Identifier"
    properties:
      value: { type: "uint32", readWrite: "W", defaultValue: "1" }

deviceCommands:
  - name: enableROSpec
    set:
      - { deviceResource: "ROSpecID", parameter: 0 }
      - { deviceResource: "Action", parameter: "Enable" }

  - name: startROSpec
    set:
      - { deviceResource: "ROSpecID", parameter: 0 }
      - { deviceResource: "Action", parameter: "Start" }

Potential areas of improvement for EdgeX:

Allow for more dynamic device profiles
- We could provide ways of performing "safe" updates to a Device Profile, such as adding new Device Resources
Implement command chaining
- In the data plane, this provides for hierarchical structure. For control, it allows commands made up of subcommands
Add new modelling for control-type operations
- Rather than trying to fit such things onto the data model.
- This may help with the common request to be able to write to the device and get results back

EdgeX Wiki

"Control plane" considerations

Analytics

Related content