ScaleUp: middleware for intelligent environments

Step one: declaring constants

Firstly, several constants need to be declared to allow communication and different control systems to operate correctly. Figure 5 provide examples of these, where each attribute is explained further in the implementation process.

Step two: creating device instances

The EDK API contains several different classes that can be used to create new representations of individual master devices. The selection of the class for a given situation depends upon several factors, specifically, the number of state variables supported by the device along with its identification as an actuator or a sensor. For common device types, the EDK API contains several dedicated classes, many of which contain bespoke convenience methods that provide better control of specific state variables. For example, Figs. 6 and 7 show the creation of an instance of two different types of light emitting devices. Both types have a state variable “Power” declared, which controls whether the device is on or off. To support these actions, both the “BooleanLight” and “DimmableLight” classes contain two convenience methods “turnOn” and “turnoff” which allow the “Power” state variable to be set without the need to declare or process any new values directly. The “DimmableLight” class used in Fig. 7 additionally contains “getBrightness” and “setBrightness” methods, as compared to the declared “Brightness” state variable, used to control the emitted light level.

Without these convenience methods, the state variable name would need to be declared along with any new state value (if applicable), in a formatted String in order to perform the same function. If the device being used is uncommon or unknown for some reason, the EDK API generic series classes can be created. This creates representations based purely on the number of declared state variables. For actuators, these would be “SingleVariableActuator” and “MultiVariableActuator”, whereas for sensors the appropriate generic classes would be “SingleVariableSensor” and “MultiVariableSensor”. Each class contains several different constructors based on the available information of the created device. For instance, in Figs. 6 and 7, the constructor is provided with a name for the device instance, the supported state variables (provided in a string array for multi-variable devices, as seen in Fig. 7), and a description of the device itself. In this instance, all other required variables, such as a unique UUID, are allocated to the new device by the EDK API. Figures 6 and 7 also show how a “StateChangeListener” can be attached to individual master device instances, which flag whenever the value of any supported state variable is changed either by some attached hardware or due to a user request.¹

Step three: adding communications

An instance of the “Communications” class must be created in order for master devices to be able to connect to an EDK network. Figure 8 shows how to do this using two of the variables from Fig. 5 mentioned earlier to supply values for the network address and communications port variables. The EDK uses multicast communication to allow master devices to send updates to any running control points that have joined the same group. As a consequence, it is important to ensure that the value used for the “NETWORK_ADDRESS” variable is a valid multicast address. It may also be necessary to open the value used for “COMMUNICATIONS_PORT” on firewalls, which may be blocking the sending or receiving of multicast communications packets on the network.

Step four: loading device controllers

Control system programs for individual smart devices are created independently of the EDK. Once implemented, a device control system can be uploaded into a master device via the EDK API. Figure 9 shows how to do this. “DeviceController.jar” is the filename of the controller being uploaded, from the designated “CONTROLLER_DIRECTORY”. To integrate the controller program with the master device, the EDK needs to know the package (“CONTROLLER_PACKAGE”) and the name of the main class (“CONTROLLER_CLASS”).

As before, examples of these values are provided in Fig. 5.

Step five: creating a device processing hub

The next step is to create a hub to process devices. The “communications” variable of the “DeviceHub” constructor should be the same instance of the “Communications” class created back in Step Three. Once the hub is initialised, each of the smart device instances created in Step Two needs to be individually added. As these are master devices, they also need to be associated with their respective controller programs, loaded during Step Four. Figure 10 provides an example of how to implement this for light devices.

The purpose of the “DeviceHub” class differs slightly depending upon whether it is used within an implementation for master devices or an EDK control point. For master devices, the hub liaises with the communication system created in Step Three, to have each of its stored devices access their associated controllers and perform a live update of their recorded state variables. Typically, this would involve each device accessing the real-world hardware to which its control system connects it. Once acquired, the up-to-date state variable information is then passed back to the communications system, where it is transmitted to the EDK network and used synchronizing any listening clone device representations.

Step six: adding web services (optional)

Using the Web Services interface method with an EDK middleware implementation is optional, so this step can be ignored if desired. However, enabling the Web Services system only requires the code shown in Fig. 11 to be added after the creation of the device hub. The variable “WEBSERVICES_PORT” is the last of the declared constants create back in Step One, which in the case of this example (Fig. 5).

Once added to an instance of the “DeviceHub” class, the EDK mechanism will auto-generate a Web Services control interface for each of the declared smart devices and add them to the internal HTTP Server. Currently, two different acceptable commands are implemented for sensors (i.e., about and get), while three for actuators (i.e., about, get and set). The Web Services interface can be loaded using any standard Web Browser, including on most mobile devices, such as smartphones and tablet computers. The syntax for an EDK Web Service is naturally bespoke to each situation where it is used, but the basic URL structure is as follows:

$$\mathbf{h}\mathbf{t}\mathbf{t}\mathbf{p}://<\mathbf{ComputerIPAddress}>:<\mathbf{WebServerPort}>/<\mathbf{DeviceName}>/<\mathbf{Command}>$$

So, based upon the “BooleanLight” and “DimmableLight” smart device examples used throughout this tutorial, some acceptable URLs would be:

• http://127.0.0.1:8000/Light1/about

• http://127.0.0.1:8000/Light1/get

• http://127.0.0.1:8000/Light1/set?Power:1

• http://127.0.0.1:8000/Dimmer1/get?Brightness

• http://127.0.0.1:8000/Dimmer1/set?Brightness:75

Creating a control point

An instance of the “ControlPoint” class allows external client programs to access devices via an EDK network. Figure 12 shows the API code required to perform this task. The String variable used in the “ControlPoint” constructor is a bespoke name for the specific instance being created. If more than one control point is being used within a client program, (i.e., to access different EDK networks), this variable can be used to identify specific instances.

A control point effectively acts as a portal into the EDK middleware system, allowing users to search for groups or specific master devices on the associated network. Its associated communications system provides details of the network which is accessed by a control point. In addition to providing details of an EDK network, the communication system supplied to a control point is also responsible for processing state update messages for the master devices. The control point itself automatically generates an internal “DeviceHub” instance, which is used to create and store clone device instances based on information received by the communications system from the EDK network. The control point accesses the stored clone devices and uses their information to provide returnable results for user searches.

Searching for devices

To search for known master devices, present on an EDK network, a “ControlPoint” instance can use its “searchForDevices” method (Fig. 13). Instances of “ControlPoint” will only become aware of master devices upon receiving an update packet from them. Therefore, upon initially starting, the delay might occur before all master devices present on a network are discovered, concerning their update cycles when the control point joins the EDK multicast group. It is typically a good idea to enclose the search command in a “for”, “do-while” or “while” loop to keep the control point scanning the network until a non-empty array is returned or the desired device is found. Alternatively, this command could also be repeatedly called from within an isolated thread, which runs continuously in the background, allowing devices that start broadcasting after the control point’s initial search also to be detected.

Searching for specific devices

If details of the target device or devices are known ahead of time, a client program can alternatively use one of the more specific search methods of the “ControlPoint” class. Figure 14 shows three such methods, each targeting different attributes of master devices. Firstly, the “SearchForDevicesByType” method can be used to filter the known list of master devices by their type, returning an array of any matching instances stored in the control point “DeviceHub”. The topmost example in Fig. 14 uses this method to search for all instances of a “BooleanLight” The “Actuator” and “Sensor” classes in the API both contain numerous other declared variables that can be used with this method each representing one of the pre-formed smart device types included in the EDK. Alternatively, to search for a device type not included within the standard API, programs can use the “SINGLE_VARIABLE_DEVICE” and “MULTI_VARIABLE_DEVICE” variables, (also found in the “Actuator” and “Sensor” classes), or a bespoke device name entered as a String.

The two remaining search methods, shown in Fig. 14, are each designed only to return a single device, matching either a specified name or uuid criterion. If no matching device is found, then a “null” value is returned. If, for some reason, two different master devices existed on an EDK network and both were called “Light1”, the “searchForDeviceByName” method will only return the first instance it encounters upon contents scanning of control point device hub. This also applies to the “searchForDeviceByUUID” method if both devices share the same aid value.²

Processing EDK smart devices

The instance of “Device Hub” created by a control point is used to store clones created to represent networked master devices locally. The device hub creates the clones, which is the automatic response when information is received from the communication system that does not match any previously known representation. Clone devices are generally stored locally on the same computer as the control point used to create them. Aside from not possessing controllers for hardware, they are identical to the master devices that spawned them in every way. Even the unique attributes of the original master device are copied, including its name and quid value. As such, by using the associated classes within the EDK API, the details and states of each clone can be read, and in the case of actuators manipulated, in the same manner as if connecting directly to any master device instance.

The EDK API contains several different methods of reading the state of smart devices. A selection of the possible options is listed in Fig. 15. The determination of best method largely depends upon what information is required about the state of a device and how it is subsequently used.

From Fig. 15 examples, the topmost method is a general “getState” command, which is common to every EDK device. When called, the “getState” command will return a single string representation of the entire device, or more specifically, its state variable values. Responses are always sent in pairs, with the name of the state variable and its current value. For instance, in the case of the “Light1” “BooleanLight” device used in the implementation examples earlier, an “etState” request could result in either of the following String responses;

$$\mathbf{P}\mathbf{o}\mathbf{w}\mathbf{e}\mathbf{r}\mathbf{:}\mathbf{0}$$

$$\mathbf{P}\mathbf{o}\mathbf{w}\mathbf{e}\mathbf{r}\mathbf{:}\mathbf{1}$$

where, “Power” is the name of the only state variable included in a “BooleanLight” object, while zero (off) and one (on) are the current values of that state. The colon separating the two values acts as a key in a split command to allow easy separation of variable name and its value. In the case of multi-variable devices, which contain more than one state variable, an additional tilde key (“~”) is added to separate the individual attributes. So, for the “Dimmer1” “DimmableLight” used in earlier examples, a “getState” request could return;

$$\mathbf{P}\mathbf{o}\mathbf{w}\mathbf{e}\mathbf{r}\mathbf{:}\mathbf{0}\sim \mathbf{B}\mathbf{r}\mathbf{i}\mathbf{g}\mathbf{h}\mathbf{t}\mathbf{n}\mathbf{e}\mathbf{s}\mathbf{s}\mathbf{:}\mathbf{100}$$

where, “Power” is the first state variable and “Brightness” is the second, with current recorded values of zero (off) and one hundred (percentage of maximum illumination), respectively³ .

Figure 15 shows three methods that API can be used to return only the current value of a specific state variable, rather than the name/value pairs shown above. Generally, this is achieved by specifying the name of the state variable whose value is required as a variable in the method. The second and third down examples in Fig. 12 demonstrate this process for a “BooleanLight” and “DimmableLight” respectively. Typically, the returned state values are in a String format, but can easily be converted as shown with the “Brightness” variable example, where the value is converted into an integer once returned.

In many cases, the string can be avoided to integer conversion, as performed in the third example of Fig. 15. This is based on EDK API device’s inclusion of convenience methods, which return state variable values in their most appropriate format automatically. This is demonstrated by the bottommost method in Fig. 15, which uses a “getBrightness” method found in the “DimmableLight” class, which automatically returns the state value as an integer. All that is required to use these bespoke convenience methods is to cast the generic “Device” object returned by a control point search into the appropriate device type class, as is shown in the example.

Writing to smart devices

In the example provided by Fig. 16, an array returned by a control point search (as described in “Techniques/Protocols/Paradigms used in the Development of Proposed Work”), is scanned for a specific device called “Dimmer1”, which is also a “DimmableLight”. If found, the value of the state variable “Power” is requested from the device. If the value returned for “Power” is zero (off) then a command is sent to turn the light on. For any other circumstance, the command is to turn the light off.⁴

In the example, the generic “device” variable taken from the “Device” array is cast into a “DimmableLight” object. This allows the programmer to access the two convenience methods “turnoff” and “turnOn,” which are contained within the Actuator class. The EDK API contains several models for intelligent devices that can be used in place of the more generic actuator and sensor classes. Some of these classes also contain further convenience methods specific to that device type. For example, the “DimmableLight” class also contains a “setBrightness” method to allow a specific value to be entered for a “Brightness” state variable, controlling the amount of light emitted by the device.

Implementing EDK compatible device controllers

Recalling back to “Step One: Declaring Constants”, two of the constants that needed to be declared when implementing a master device (as shown in Fig. 5) were “CONTROLLER_CLASS” and “CONTROLLER_PACKAGE”. The origins of the values used in the Fig. 5 example, can be seen in Fig. 17. The value that should be used for the “CONTROLLER_CLASS” constant is the name of the main class of the control system program, which in the example is simply “Controller”. Additionally, the value for the “CONTROLLER_PACKAGE” is the name of the package containing the declared main class, in this case “devicecontroller”.

When implementing a control program for smart devices to be used with an EDK middleware system, Fig. 17 shows the minimum classes required for integration. More specifically, the “getState” and “setState” methods are both essential and should be used to directly return or update the current state of the associated hardware, respectively. If additional code is required to create a link with the associated hardware, such as using a third-party software package (e.g., RXTX or a manufacturer API), then all this code should be placed into a constructor within the main class, as shown by the “Controller” constructor in Fig. 17.⁵ If necessary, the constructor code should establish a connection with the smart device hardware and then maintain it as a global variable that can be accessed directly by the “getState” and “setState” methods. Alternatively, the constructor could be used to start an isolated thread, which uses locally declared variables, also accessible by the “getState” and “setState” methods, to handle state action requests. It is essential that no code necessary to directly establish a connection with hardware is included in either the “getState” or “setState” method as doing so could lead to overall instability in the EDK middleware system.

Controllers for multi-variable devices

Figure 18 highlights how the controller code in Fig. 17 can be extended to handle smart devices with multiple state variables. The code presented (in Fig. 17), could function with a multi-variable smart device, but it is often desirable to separate certain state variables to better structure program code, or for efficiency, etc. Figure 18 shows a template for the controller used with the “DimmableLight” device “Dimmer1” example mentioned throughout this guide. Notice how the “getState” and “setState” methods have been retained (for handling the “Power” state variable), although the “Brightness” state variable has been separated and given its handling methods, namely “getBrightness” and “setBrightness.” To add additional “get” and “set” methods, it is necessary to ensure that their suffix is named the same as the state variable they are expected to handle, (e.g. “getPower”, “getBrightness”, “setPower”, “setBrightness”, etc.).⁶

When accessing a loaded device controller, an EDK implementation will first search through the methods of the declared controller class (i.e. “CONTROLLER_CLASS”) to see if it contains a bespoke match for the current state variable it needs to process. If no appropriate method matching the state variable can be found, the system will then automatically default to either the “getState” or “setState” method, depending upon which action is being performed.

Additionally, in Fig. 15, the package name has changed, reflecting that it is a different device controller program from Fig. 14 example. To be loaded correctly into the EDK and used with a master device, Fig. 15 example would need to specify “devicecontrollermultiple” as the value for “CONTROLLER_PACKAGE” during the first implementation step.

System validation: sensors

The first experiment in the project evaluation focused specifically on comparing middleware used to access sensors. In other words, devices whose functionality consisted only of sending information about their current state back to a requesting program. The Jetty-based Web Services system in the iClassroom linked directly into individual device control programs, which automatically requested a current reading from the relevant sensor hardware when called. However, the iSpace UPnP mechanism functioned in a very similar style to the EDK middleware design. Specifically, whenever called, the ‘getState’ command would access the control system for a specific device and return the last recorded value obtained from the actual sensor itself. A ‘getState’ method call never actually resulted in the hardware being accessed directly in order to take a reading. Updates to the recorded light level value were handled by an independent thread located within the program code for the sensor, which automatically took a new reading from the hardware intermittently. In the case of the iSpace UPnP system, a new reading was recorded approximately once every ten seconds. For EDK, this interval was reduced to approximately three seconds, in order to reduce the margin of error between the recorded and actual sensor values.

The experiment involved measuring the time required for each middleware system to return a lux value for a specific light sensor Phidget. As can be seen from the results displayed in Table 1, on average for each session run, both device interface methods offered by the EDK middleware required significantly less time to process individual action requests than both the Jetty-based Web Services or Youpi UPnP implementations. In the case of the Direct API interface method, the processing time was reduced to nanoseconds as the sensor value being returned in response to each action request was taken from a locally stored variable within the clone of the real sensor generated by the EDK. As mentioned above, the Youpi UPnP middleware used a similar method, but the recorded values for the light sensor were stored on a remote server, hence required additional processing time for the system to access and get the data values from. Unlike the API interface method, action requests made using the EDK Web Services were directed at the real light sensor, yet they still required a fraction of the processing time of the Jetty-based system, consistently throughout the evaluation.

System validation: actuators

The second experiment performed for the evaluation focused on actuators. More specifically, this involved devices that contained one or more variables that could have their state modified, via the middleware accessing an attached control system. When setting the state of a variable, the success of the corresponding hardware being updated was not always guaranteed. This is because many devices do not provide any feedback to the controller code, concerning whether a transmitted command has been received or acted. Both, Jetty-based Web Services and Youpi UPnP middleware sent acknowledgments back to the control programs where action requests originated but always assumed a positive outcome. In contrast, the EDK did not send any acknowledgments in direct response to individual state change requests. The success or failure of an update could be determined by observing the next set of variable settings transmitted by a real device to its clones.

This experiment involved each middleware system accessing a single DMX-controlled dimmable spotlight and alternating its brightness level between fifty and one hundred percent. Table 2 lists the average processing times required by each batch of one hundred action requests made during the experiment. As with the sensor experimentation, both EDK interface mechanisms were found on average to require significantly less processing times than the Jetty-based Web Services and Youpi UPnP systems. It is worth noting that the difference between the EDK and Jetty-based Web Services was not as profound as for the sensors. This was due to the controller code for the DMX lights adding a delay of approximately one hundred milliseconds to the processing of each action request via a compulsory sleep command. As the EDK Web Services were directed at the representation of the actual light rather than a local clone, the delay was unavoidable.

Unlike for the sensor ‘getState’ action requests, when setting a device’s state, the EDK’s Direct API interface method also targeted the original ‘master’ representation rather than a clone. Effectively, a state change action request was forwarded to the original device by sending out a state change request using the inbuilt multicast communication system. As the system did not require any acknowledgment, the process could be ended at that point, unlike UPnP and the Web Services mechanisms, which required some kind of response, even if based upon an assumption.