-
Notifications
You must be signed in to change notification settings - Fork 88
feat: Add ADR for device functions #644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
d35d610
2fc4be1
639fb93
c5266fd
0d6d03b
8f0ee4b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,140 @@ | ||
# Invoking Device Functions | ||
|
||
|
||
## Status | ||
|
||
**Draft** | ||
|
||
## Context | ||
This ADR presents a mechanism for invoking functions on a device. | ||
|
||
## Existing Behavior | ||
|
||
Device access in EdgeX is focussed on 'Readings' and 'Settings'. A device may | ||
present values which are readable, representing some measurement or status, | ||
such as a temperature or vibration reading. Also a setting such as a the | ||
required speed of a fan motor may be written to and read back. | ||
|
||
What is not supported directly is 'Functions', where a device may be commanded | ||
to do something. Examples could include perform a self-test, go into standby | ||
mode for an hour, invalidate an access key. | ||
|
||
While such operations may modelled using virtual resources in a device profile, | ||
this is unintuitive. | ||
|
||
## Decision | ||
|
||
**Add a new section to device profiles describing functions** | ||
|
||
``` | ||
{ | ||
"deviceFunctions": | ||
[ | ||
{ | ||
"name": "Name by which the function is accessed", | ||
"description": "Readable description of the function", | ||
"attributes": { device-service-specific attributes which select this function }, | ||
"parameters": | ||
[ | ||
{ | ||
"name": "Parameter name", | ||
"description": "(optional) description of what the parameter controls", | ||
"type": "Any of the existing EdgeX data types", | ||
"defaultValue": "(optional) value to use if param is not supplied", | ||
"maximum": "(optional) for numerics, maximum allowed value", | ||
"minimum": "(optional) for numerics, minimum allowed value" | ||
} | ||
], | ||
"returnValues": | ||
[ | ||
{ | ||
"name": "Name of returned value", | ||
"description": "(optional) description of what the value indicates", | ||
"type": "Any of the existing EdgeX data types" | ||
} | ||
] | ||
} | ||
] | ||
} | ||
``` | ||
|
||
Note: the `attributes` structure is analagous to `attributes` in a `deviceResource`. Each device service should document and implement a scheme of required attributes that will allow for selection of the relevant function. | ||
|
||
**Define MessageBus topics on which function call requests and replies are to be made** | ||
|
||
These follow the style of messagebus usage set out in the North-South messaging ADR. | ||
|
||
`edgex/request/function/[device-service-name]/[device-name]` | ||
|
||
The payload for messages on these topics should be of the form | ||
``` | ||
{ | ||
"correlation-id": "1dbbd344-c9f6-4714-8c89-91c1d5b11a90", | ||
"deviceName": "device1", | ||
"function": "functionname", | ||
"request": | ||
{ | ||
"requestId": "184b894f-a7b7-4d6c-b400-99961d462419", | ||
"parameter1": "37", | ||
"parameter2": "0" | ||
} | ||
} | ||
|
||
``` | ||
|
||
`edgex/response/function/[device-service-name]/[device-name]` | ||
|
||
The device service will provide responses to function calls on this topic. The payload will be | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are messages sent with guaranteed delivery, or can messages be thrown away if the device is not there to receive them? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. QoS is configurable in the main messagebus options |
||
|
||
``` | ||
{ | ||
"correlation-id": "1dbbd344-c9f6-4714-8c89-91c1d5b11a90", | ||
"response": | ||
{ | ||
"requestId": "184b894f-a7b7-4d6c-b400-99961d462419", | ||
"statusCode": 0, | ||
"returnVal1": "true" | ||
} | ||
} | ||
``` | ||
|
||
or if a call fails | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if a response is never sent or received? |
||
|
||
``` | ||
{ | ||
"correlation-id": "1dbbd344-c9f6-4714-8c89-91c1d5b11a90", | ||
"response": | ||
{ | ||
"requestId": "184b894f-a7b7-4d6c-b400-99961d462419", | ||
"statusCode": (nonzero), | ||
"message": "Message indicating the nature of the failure" | ||
} | ||
} | ||
``` | ||
|
||
*Returned status codes* | ||
|
||
| Status | Meaning | ||
|--------|-------- | ||
| 0 | The operation was successful | ||
| 1 | Request message format error | ||
| 2 | Parameters were missing, out of range or non-parsable | ||
| 3 | The Device is DOWN or DISABLED (OperatingState / AdminState) | ||
| 4 | No such device or function | ||
| 100+ | Implementation-specific errors, defined for each Device Service | ||
|
||
*Configuration* | ||
|
||
The topic prefixes `edgex/request/function` and `edgex/response/function` will be configurable in the device services. | ||
|
||
**Device SDK enhancement** | ||
|
||
The device SDKs will handle the messagebus communcations and parameter marshalling. The generic errors defined above may be detected in this SDK code. The SDKs will define APIs for the individual device services to implement the function invocations. | ||
|
||
**Command service enhancement** | ||
|
||
The core-command service to be extended to provide access to device functions as it does for device readings and settings. | ||
|
||
## References | ||
|
||
* [ADR 0023-North-South-Messaging](https://github.com/edgexfoundry/edgex-docs/blob/master/docs_src/design/adr/0023-North-South-Messaging.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems odd to describe functions in device profiles. Typically what we're trying to accomplish is allow use of some sort of functional protocol to communicate with devices, and the protocol itself doesn't change for different instances of the class of devices supported by the device service. For instance, the original device-camera service only supports ONVIF (which is a SOAP-based protocol), likewise our RFID device service only supports LLRP. I suppose if a service supported more than one function-based protocol, then defining the functions in profiles makes sense, but I think this is the exception, not the norm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes for protocols like ONVIF which define available operations at the protocol level. But for eg a Modbus device where you may have a function "Reset latching alarms" which is invoked by writing a zero into register 0x16, that ought to be defined in a device profile.