Glen and I have been working to design the interface between the Sensing Management and the Data Transfer domains in the remote sensor.
The Data Transfer has to map requirements delegated to it by the Sensing Management domain onto the Bluetooth LE transport. Domains such as this (and User Interface domains are another example) always pose special problems. The physical nature of communications interfaces means that everything has to be serialized going over the interface and, also important, everything the system needs to expose to the outside world must somehow make its way across the interface.
The particular problem for which we were designing a solution, was how to transport Group Sample instances corresponding to a particular Sensor Group across the Bluetooth LE interface. In Bluetooth LE, client nodes present a set of services which contain a set of characteristics which correspond to typed data values. Characteristics may be read or written, but also may asynchronously notify a client of a value change. The design of the characteristics for transferring Group Sample instances is to have service corresponding to each Sensor Group and that service consists of a pair of characteristics. A Group Sample Count characteristic gives the number of Group Sample Values that are available for transfer for the service's corresponding Sensor Group and a Group Sample Value characteristic which, when read, yields a single Group Sample timestamp along with its related Sensor Sample values. A client would then be expected to repeatedly read the Group Sample Value characteristic for Group Sample Count number of times to retrieve the environmental data. A client is also expected to repeat this process for all the services that correspond to Sensor Groups.
The complications arise when considering whether or not notifications should be supported for the Group Sample Count characteristics and, if notifications are supported, what type of interface should be used for notification of the value change. Since the Data Transfer domain will also have to handle transporting other data values from the system to a Data Aggregator component, we need to find a design that will work well with other domains. So the solution should not be strictly tailored to the particulars of the Sensing Management domain. For example, if we wish to expose an Input Point from the Signal I/O domain (e.g. the internal CPU temperature), then the interfaces presented by the Data Transfer domain should support that use case also.
The following is the proposed set of interfaces to accomplish these requirements:
- The Data Transfer domain defines an external entity named ACCESS. This entity is delegated the requirements to gather and / or distribute data values from the Data Transfer domain to other parts of the system. The bridge code underlying the entity is responsible for mapping from characteristics identifiers from the Data Transfer domain to other operations in the system to read or write data values. Often, data values are obtained from attributes of other domains and, in that case, the bridge would use the micca portal to access the attributes.
- The Data Transfer domain provides a domain operation named Notify value change which takes a characteristic identifier and value and issues notifications to any interested clients currently connected on the Bluetooth link.
For the case of the Sensing Management domain, the following is proposed as the means by which Sensor Group data is made available to the Data Transfer domain.
- The Sensor Group class has an attribute named, for example, Sample count. This attribute would be a mathematically dependent attribute. When read, the attribute formula would return the cardinality of the relationship between Sensor Group and Group Sample (R4). The ACCESS entity bridge code would then read this attribute in response to a read request from a connected Bluetooth client accessing the Group Sample Count characteristic.
- If notification of value changes in Sensor count are supported, then the Sensing Management external entity, XFER, must have an operation to report changes in the value of Sensor Group.Sample count. The bridge code for the XFER operation would then use the Data Transfer domain operation to report the value change by mapping the Sensor Group ID to a characteristic identifier and include the new value of the count. This operation would have to be invoked each time a Group Sample instance is created. The Data Transfer domain is responsible for determining if any physical notification is transmitted depending upon the state of the Bluetooth connection and whether the client has enabled such notifications.
To see how the Signal I/O example might also use these interfaces, consider the internal CPU temperature. This is available for reading from a domain operation provided by Signal I/O. Also, Signal I/O has notification capability for Input Points and each time a new Input Point value is converted, the new value is reported via the NOTIFY external entity of Signal I/O. To expose this value on the Bluetooth connection implies that ACCESS bridge code of Data Transfer must map a characteristic identifier to reading an I/O Point value from Signal I/O. To expose notifications of this value, implies that the NOTIFY bridge code of Signal I/O must map an I/O Point identifier to a Data Transfer characteristic identifier. Both operations are common bridge functions.