Introduction

The Device Information Service class provides a set of functionality to enable users to read and write to the various characteristics that make up the service, as well as subscribe to changes to characteristics that allow for notifications. These functions will provide a layer of abstraction from the byte arrays that are passed back and forth between applications using the SDK and the physical device. The Device Information Service will derive from the Base Service class to provide a set of lower level functionality to read and write byte arrays that will be leveraged when calls to read and write to specific characteristics are made.

Requirements

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#4.-Device-Information-Service

Related Jira Issues

Constraints

Performance

As the device information service deals with interacting with the physical device, asynchronous Read/Write calls will be made available to provide non-blocking calls to the device.

Ease of Use

Rather than require byte arrays to read/write to/from the device, the Device Information Service will utilize classes and primitives to represent the various characteristics.

Supported Characteristics

Certain characteristics, and elements of characteristics, are currently not supported through read/writes to the characteristic. If a particular characteristic is not listed in the Detailed Design section, it can be assumed that the characteristic will not be supported. Similarly, if a characteristic value is marked in red, this signifies that the latest ICD shows a lack of support for that particular value. While the characteristic data struct may contain a correlating field relating to the item, it is not expected to cause any changes to the device itself.

Detailed Design

The Device Information Service will inherit from the Base Service class, exposing public functions to read from, write to, and subscribe to specific characteristics in the service without the need to deal with the byte arrays passed between the device and the lower level function calls. Each of these read, write, and subscribe calls will make use of data classes and structs built to represent the various characteristics that make up the device configuration service on the VictoR device. These data classes and structs will provide two constructors for ease of use: one which can take a byte array and process the data to construct the desired characteristic and one default constructor. It will be especially important that the byte array characteristic is able to account for byte arrays that do not properly represent the desired characteristic. In these cases, some (or all) of the fields that make up the characteristic will be initialized to their default values or null where appropriate. It is important to note that the expected use case will be to first pull data from the device, modify the data where needed, and send back the modified object to the device. Using the default constructor Assigning values without also verifying the current values on the VictoR device will cause any values currently set on the device to be overwritten.

System Interaction

The below sequence diagram illustrates the typical workflow when reading a characteristic from the VictoR device. The Device Information Service provides public functions for getting and setting specific characteristics, with each characteristic having a corresponding class that represents the characteristic within the SDK. When requesting the current cpu load the device, the service’s “GetCPULoad” function is called asynchronously, with the expectation of providing a Task result containing the appropriate characteristic class, returning a null object if the read is not successful. The Device Information service will then utilize the Read function, paired with the appropriate Guid for the CPU Load characteristic. This in turn calls the DeviceManager’s Read function, using the device address passed by the end-user application’s request for the cpu load to get the data from the appropriate device. Should the device interface successfully get the data from the physical device, the byte array representing the data will be passed back through the device interface, to the device manager, and finally to the device configuration service. It is here that the byte array will be deserialized and converted into the CPULoad class, to be passed back to the end-user application.

Image Added

Glossary