Introduction
The VictoR Core Library will provide a standardized, user-friendly set of interfaces and base classes for interacting with the various services within an FN VictoR device without needing to reference an ICD to figure out the low-level details required for those interactions. To facilitate the development of those interfaces, a common Base Service class will be created with the intent of providing a common set of methods and fields that utilize the device communication interfaces as well as any common data to be shared among any services that inherit from this base service.
Requirements
Related Jira Issues
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Constraints
Performance
Read/Write calls to a VictoR device are time intensive I/O operations. The Services should not block and force the end-user to wait for the operations to complete.
OS Abstraction
End-users should not have to directly interact with OS-specific APIs to communicate with a VictoR device. The Base Service, and by extension all Derived Services, should abstract away the OS-specific implementation details and only provide the end-user with the data that they are interested in.
Ease of Use
End-users should not have to operate on data in binary form. The Derived Services should provide ordered, human-readable data structures that will be serialized into binary data when sending to a device, and deserialized from binary data from when receiving from a device.
Detailed Design
The Base Service will provide the common data inherited by derived Services, including the common portion of service and attribute UUIDs. It will also provide common functions that every derived service will need, such as the ability to read and write binary data to a particular device attribute using the device manager, and subscribing and unsubscribing from notifications of changes for a particular device attribute using the device manager. Derived services will maintain a mapping of all attributes relevant to that service to its underlying UUID, which will be used in conjunction with the provided read/write/subscribe/unsubscribe functions. All I/O operations to/from a VictoR device are performed in a non-blocking, asynchronous manner. In addition, the Base Service provides end-users with the ability to set (and get) a Current Device, which is the device that will be used for communication if no device is specified in a read/write operation. This allows the end-user to just set the device once and perform any number of read/write operations on that device, without having to manually specify the same device for each call.
.png?version=1&modificationDate=1648230710399&cacheVersion=1&api=v2&width=366)
System Interaction
The sequence diagram below in figure 2 illustrates the typical sequence of events when an end-user’s application uses the SDK to retrieve data from a VictoR device. In this example, the end-user makes a call to the Device Information Service to retrieve the Firmware Revision. This function has knowledge of which particular attribute ID this data corresponds to, and uses that information along with the provided device ID (if provided - otherwise it uses the Current Device ID) to call into the Base Service. The Base Service uses the Device Manager to request a read of the specified attribute from the specified device ID. The Device Manager takes that request, looks up the matching Device Interface from its internal map of devices, and forwards the request to that device. The Device Interface in turn requests a read of the specified attribute from a VictoR Device over the underlying communications protocol (which is determined by the particular Device Interface that was constructed). This sequence of function calls is non-blocking, so that the end-user is not left blocked waiting for the device to respond with the data. Once the device has finished processing the request and the data has been successfully transmitted back to the Device Interface, it is propagated back down to the Device Information Service in its serialized binary form. The original function used to retrieve the Firmware Revision contains logic to deserialize the the Firmware Revision from its binary form into an ordered Firmware Revision data structure that is then finally returned to the end-user.
Glossary
Term | Description |
|---|---|
API | Application Programming Interface |
ID | Identifier |
ICD | Interface Control Document |
I/O | Input/Output |
OS | Operating System |