/
"Control plane" considerations

"Control plane" considerations

Owned by Iain Anderson
Sept 21, 2020

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


Related content