Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

The Device Configuration Service provides a set of functionality to enable users to read and write to the various characteristics that make up the service. 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 Configuration 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#5.-Device-Configuration-Service

Related Jira Issues

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-73

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-179

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-111

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-176

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-169

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-170

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-171

Jira Legacy
serverSystem JIRA
serverIde71e36b8-1c31-3d38-9c43-0d513e8b44c9
keyFNSDKEXT-172

Constraints

Performance

As the device configuration 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 Configuration Service will utilize classes 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 DeviceConfigurationService will inherit from the BaseService class, exposing public functions to read from and write 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 and write 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 without also verifying the current values on the VictoR device will cause any values currently set on the device to be overwritten.

Image Removed

Figure 1A: Device Configuration Service Class Diagram (Windows)

Image Removed

Image Added

Image Added

Figure 2A: General System Parameters Class Diagram (Windows)

Figure 3A: System Power Command Class Diagram (Windows)

Figure 4A: System Time Class Diagram (Windows)

Figure 5A: Trigger Detection Parameters Class Diagram (Windows) [DEPRECATED]

Figure 6A: Training Parameters Class Diagram (Windows)

Figure 7A: Video Parameters Class Diagram (Windows)

Figure 8A: Vision System Command Class Diagram (Windows)

Image Removed

Figure 8A: Target Recognition Parameters Class Diagram (Windows)

Image Removed

Image RemovedFigure 9A: Threshold Based Trigger Detection Parameters Diagram (Windows)Image Added

Image Added

Image Added
Image Added

System Interaction

The below sequence diagram illustrates the typical workflow when reading a characteristic from the VictoR device. The Device Configuration 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 system time on the device, the service’s “GetSystemTime” 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 Configuration service will then utilize the Read function, paired with the “TryGetServiceUUID” function from its parent BaseService class to use the appropriate Guid for the System Time characteristic. This in turn calls the DeviceManager’s Read function, using the device address passed by the end-user application’s request for the system time 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 SystemTime class, to be passed back to the end-user application.

Glossary

Term

Description

SDK

Software Development Kit

ICD

Interface Control Document