Lantern: A domain specific language for energy awareness in smart-homes

The notion of energy-awareness is represented through the use of control zones and language constructs to manage and adapt resources with those zones depending on individual’s energy needs. The central concepts and notions of energy consumption, awareness and usage are modelled in both aspects of the Lantern ecosystem (i.e. language and middleware) while the compositional and adaptive nature provided by Lantern is implemented as part of the middleware. Only those concepts that are exposed within Lantern are usable by developers. An overview of the hierarchical nature of the constructs and how they fit together with other concepts are illustrated in Fig. 2(a).

The central design criteria for the language was to take a low-energy/energy-aware approach to programming language design. In this case, environments allow direct mapping to physical buildings while areas located within these buildings can be linked to locations. Once these physical mappings have been defined within the language, the power use of devices and smart devices can be monitored, maintained and adapted based on what instructions the end-user provides. The language can adapt and react based on environmental state information and user generated complex events within the system. The decision to take this direction was because of the nature of the exploratory work of the Lantern system. Limiting the domain to statically located devices rather than mobile physical devices was to ensure that a core language could be developed. This is being built upon in another iterative development cycle which includes support for mobile systems and provides a more expressive language.

A similar approach has been taken to other languages where a compiler has been developed which will compile and then link each generated service or user-generated control program into the middleware [19]. Figure 2(b) shows how the language relates to other system components.

User generated services and programs are translated into Java and compiled and then linked into the middleware as service agents. These can be either control agents (i.e. the user generated programs for controlling the power utilisation of an area) or system agents which control devices and allow them to interface with the middleware.

OPEN IN VIEWER

Fig. 2.

An overview of Lantern.

The main components that have been developed in this phase are the compiler, middleware and device services. The middleware layer is to provide support to test the ideas behind the language rather than providing a fully rich middleware. By evaluating the language, and determining what works well will inform the next language iteration.

The environment construct is to provide a top-level container definition for a set of defined sub-locations within an area. Multiple environments can be defined which provide configuration, adaptation, control and accessibility to the devices which are on offer within the sub-locations defined within them. These locations could cover a wide variety of different types and smartness levels. As each location can provide access to a number of devices which exposes telemetry and capabilities to the middleware, the linkage of what is available would be defined within the location construct. This would allow the association between an area and a number of sub-locations where the end-user would be exposed to the conditional and adaptive nature of the system for controlling their power consumption. The syntax of the environment construct is shown as follows.

The environment construct will, when used in context of the rest of the Lantern description, provide the constraints on the environment by determining how to manage the effective use of energy within the enclosed area. The location construct is used to define one or more sub-areas within an environment. The purpose of the location is to allow the linkage and association of controllable smart devices within that sub-area to be identified and linked into the middleware. Once linked in, telemetry and the control of the devices can then be maintained. The syntax of the location construct is as follows.

Devices allow the connectivity of smart objects to the environment. Devices defined here are place holder references that can be used within condition constructs and allows the linkage of device variables to receive input (i.e. telemetry) or as a means to control by associating them to corresponding aliases. This provides an interface for not only receiving telemetry data that can be generated from the device but also act as a conduit in the control and use of the device. The input keyword is used to allow the capture of a type of telemetry on offer by the device while the device connector construct -> or <- provides the direction of flow of information. In the case of receiving information, the device connector specifies the direction coupled with the type of data which is to be associated within the middleware. The device keyword allows a device to be created and maintained and any data or control requirements will be accessible under the device variable name that has been specified. Therefore, any environmental readings generated by this device will be internally represented, accessed and available through the associated variable name. Information can flow from a device to the middleware but control can also be maintained on the device by using the -> and output constructs. This provides the middleware with the ability to regulate whether the device is turned on or off.

Figure 3 illustrates locations in the scenario where the kitchen, front room and bedroom have been defined along with a set of devices and aliases linking to existing sensors and devices.

OPEN IN VIEWER

Fig. 3.

The environment of the home.

The consumption construct allows the developer to define the consumption rules for a given location based on how much energy is being consumed. Rules can be provided that allow the customisation and adaptation of areas based on environmental factors and stimuli. The consumption construct acts as a container unit which binds together all actions that need to be taken in an area. For instance, the consumption of energy within an area (i.e. the environment) can be controlled so that if it exceeds an energy threshold, the language and middleware will re-configure devices appropriately to reduce their total energy usage so that it falls below this threshold. The syntax of the consumption construct is as follows.

Introducing a consumption concept into the language allows for the monitoring and maintenance of the total energy use within the given environment. When defining the use of energy, a set of overrides are specified which allow fine grained energy usage monitoring and control of the locations within the environment. For example, a building could have a number of locations defined within it. When coupled with the override construct, the consumption levels of each of these locations can be monitored and adapted depending on environmental stimuli and user generated rules governing the forcible reduction of energy usage of devices.

When defining how to respond to the changing power usage within a location, the override construct is used to provide the fine tuning of how to handle the devices within the location which can impact environmental changes in state. Overrides allow the middleware and language to react to a stimuli or condition occurring which results in some form of intervening reaction. Each override definition identifies the location and how much the energy consumption threshold is for the area. Lantern will automatically calculate the total power usage for the location by using the associated devices specified by the user in the corresponding location construct. As each of these associated devices will be able to provide power usage telemetry as well as environmental state data, the associated location variable will be able to provide a snapshot on the current energy usage for its domain. This energy level is consumed by the corresponding override statement which executes a number of conditional checks to allow the adaptive reduction in energy consumption. These overrides only come into play once the threshold has been exceed, in most cases, these will not be performed and normal reconfiguration and use of the environment outlined in the identity construct would take precedent. Only when there is an exceptional spike in energy consumption would the consumption overrides start altering the power usage and availability of associated devices within the location, thereby overriding and ignoring any user specific conditions for normal use. The syntax of the override construct is as follows.

When used in conjunction with the consumption construct, a set of overrides can be configured which allows a variety of scenarios where different energy thresholds can be encountered. The effect or resulting action to take place on the firing of an override clause is specified using a set of condition constructs which can allow the dynamic reconfiguration of devices based on the current environmental state.

OPEN IN VIEWER

Fig. 4.

The consumption of the home.

The consumption section defines what needs to be done for the house environment when power usage exceeds a pre-defined amount. For example, the kitchen override specifies how many Watt’s need to be consumed before which the associated override kicks in and adapts the power utilisation within that area. In this case, a condition for checking if the microwave and cooker are on then to reduce the power provided to the cooker by 30%. Another condition is to check to see if the microwave, cooker and kettle are on at the same time and to perform multiple actions as a result (i.e. reduce the cooker power by 20% and set the buzzer) as shown in Fig. 4. It is through these overrides that the location will adapt itself so that power is reduced until a later time when additional conditions can re-configure the power usage of devices. In this iteration of the language, a weak notion of power has been adopted (where everything is in Watt’s). By introducing % of power to control devices, allows reducing power needs using a simple representation. However, in practice, this was found to be not powerful enough (see Section 4.4) and the next version of the language includes more strongly typed energy, temperature and time representations.

User identity is represented within the language using the identity construct. The notion of identity is weakly represented within the middleware itself as users are equipped with RFID and NFC badges/tags as well as smartcard swipe access. This loose notion of identity does lead to a number of challenges which still need to be addressed within the middleware. For instance, the issues relating to identity conflict and identity resolution where more than one person is contained within a sub-location such as a shared office. However, from a language point of view, it takes an agnostic approach where users can specify how they want devices and the environment to react based on a set of conditions describing what to do in specific cases. By allowing the language to have an opaque notion of identity, the issues revolving around how to coordinate and determine the precedence of conditions for multiple users in the same area can be left to the middleware.

The language definition of identity allows users to specify how they wish the environment (i.e. the sub-location) to respond to both system-based stimuli as well as more complex aggregate conditionals which can occur over time. The following shows the syntax for specifying an identity.

Identities are associated to an end-user which is maintained and monitored by the middleware when they move between locations. Each user can specify any number of details regarding how they want a specific location to react. This is specified by linking the identity to a specific location and then defining the state changes that need to be monitored and reacted to. For example, in Fig. 6, an identity for the user bill has been defined and linked to each location in the home. Within each room, there are a number of smart devices as well as devices controlling the ambient temperature and light levels. In this particular scenario, the user has specified that the heating is required to be turned on at 7.30 am in the morning and then specifies two additional conditional statements which dictate when to turn the heating on or off thereafter to ensure that the ambient temperature of the room is maintained.

3.5. Conditions

Conditional statements provide a degree of flexibility in the minute-to-minute monitoring and adaption of an environment. They are associated to two constructs (override and identity) which allows the fine grained control of smart devices within a particular location or environment.

Conditions follow a simple cause and effect relationship whereby any condition that evaluates to true will perform the associated effect, or action. As events are generated and propagated throughout the middleware, a snapshot of the state is maintained for each location. This allows state information to form over time rather than waiting for the off chance that multiple events and compound events are received at the same instant in time. Conditions access this location specific state information provided by the middleware to determine the validity of the statement. In its simplest form the condition construct syntax is in Fig. 5.

OPEN IN VIEWER

Fig. 5.

Conditions.

Conditions can be used as a single instance or part of a more complex aggregate of conditions. The conditional predicate of the statement either evaluates to true or false but can be formed out of more complex combinations of conditionals using standard and, or and not operators. It is only once all conditionals evaluate to true will the associated action be performed. Additional keywords and concepts are available to be used within the formation of conditions to expand on their expressiveness. For example, the definition of user types which are of a given type and associated to a form of telemetry from a device can allow a degree of flexibility in the terms used in their construction.

Events are used to transmit information around the middleware and are used as a basis to populate state information regarding the devices within a given location. The middleware maintains this state and provides the ability to form unbounded time-based event states. This means that multiple events can be received in a short time whereby they are deemed to have a causal relationship with one another. Building upon this is the notion that user generated events can be triggered based on a set of expected events and can be used in the composition of more complex states. In order to create a user generated event, the new-event keyword is used which will relay it to the middleware layer and is based on a key-data tuple pair. For example, in the following, a new user generated event is created once the condition has been received.

In this case, the action is triggered which allows the new-event keyword to be used to generate a message with data that needs to be sent. By adding the ability to create new user generated events allows the language to be extendible and react to other non-system related events generated by devices.

Direct manipulation of devices can also be achieved through the action construct by specifying directly the state that device needs to be in. For instance, by explicitly setting a device to on will direct the middleware to interact with the device and change its state. This is accomplished within the middleware through the use of services residing on individual devices which provide a way of manipulating and controlling the underlying device, as illustrated in Fig. 6. In this example, the device associated to one of the heating variables can allow the direct manipulation of its state. However, the comparison of the state/value contained within this variable is checked against a user-generated typed variable linked to a specific device and sets a specific threshold. The language also allows for comparison against a statically defined numeric value as well. In this example, the at keyword is used which allows the condition to trigger based on a temporal event, in this case as soon as the system time becomes 7.30, the condition will be triggered.

Conditions can use the standard set of comparison operators as found in other languages, namely, equality (==), greater (>), less than (<) and not (!). Conditions can be formed by any combination of and, or, not conjunctions and allows the precedence ordering of combinations. Power handling can also be accomplished by using the reduce keyword in the action statement. The purpose of this is to allow any suitably equipped smart device which can interact with a physical device (for example a cooker or heater unit) to reduce its power consumption by a given amount – as illustrated in the kitchen location of Fig. 6

OPEN IN VIEWER

Fig. 6.

Example identity and conditions for a location.

The final key component of the language is providing the semantics for linking telemetry streams and power control functionality to variables which can be manipulated within the user defined program. Aliases are used to allow variables to be bound to real-world objects and sensor streams using a proxy pattern. Figure 7 highlights the syntax of the different styles of aliases that can be defined.

OPEN IN VIEWER

Fig. 7.

Aliases.

A binding-alias allows the connection of a user defined binding variable to be associated to a real-world device. The declared binding variable is then used as a conduit through which information and control can flow depending on the type of connectivity (i.e. -> implies that information can flow from system to device, while <- implies information flowing from device to system). Each binding variable provides state (either in the form of telemetry that has been provided) and timing information for use when handling events or combinations of complex events. As binding-alias’s provide contextual information from a device they are considered bounded variables whereby an association is defined and maintained between construct and device. Information flow is dictated by the connectivity operator which defines which direction information flows. For binding aliases which require telemetry to be received, the input-connector is used. However, if control of the device is required, an additional binding-variable has to be created to handle control messages and is used in conjunction with the output-connector when associating the binding variable with a device.

The second type of alias is a declaration-alias which allows users to define their own variables with a specific integer value or threshold. These types of aliases can be bound or un-bound to a device depending on the context that the variable is to be used. For instance, an alias could be defined thusly, alias(low : integer) = define (20). In this case, the variable simply is assigned a static value which can be accessed throughout the programs lifetime. However, as it is un-bounded, i.e. it is not linked to a particular device, no contextual information is required or used to determine if the variable is being used in the correct context with regard to a device. If it were a bounded variable, an explicit link to a device would be given. For example, alias(low : integer) = define (20) <- heating, in which heating is an alias connected to a device can be used (of type heating). Here, as context is provided by the linkage between this static variable declaration and a device (through another alias definition / proxy to a device) checks can be made to ensure that the type of telemetry data matches with the type definition of the variable.

OPEN IN VIEWER

Fig. 8.

Corresponding capabilities list in device system agent.

When binding a device to a variable or interfacing any hardware, contextual information regarding the capabilities and offerings of a system-based service representing the physical device (hardware) is needed to be specified. As system agents act as proxies to real-world devices, they are programmed to offer a set of capabilities. It is through these capabilities that the resolution and binding process takes place between a binding variable and associated device (hardware). For example, when defining a system device, the capabilities would follow on from previous work [19] in which each device can specify what their capabilities are when defining the service. Figure 8 illustrates an example of this.

Here, the device-type acts as type identifier for the classification of the device. If telemetry is generated by the device, the service will have a telemetry-type definition which defines the type of information which is generated. If a device is controllable, i.e. it can be manipulated by turning on or off, or in some cases reducing the power consumed to a lower amount, the controllable identifier will either be yes or no. Associated to whether it can be controlled, the controllable-state identifier is used to indicate what type of actions can be performed. In this example, boolean is specified to indicate that it can be either on or off. More sophisticated devices which can offer a variable control over the device, i.e. reduce its power consumption by offering more states, would link to the reduce construct. The location identifier allows the device to indicate where it is located as searching for “heaters” could potentially return a set containing all heaters rather than one specific one. To help in the resolution process, key-data pairs can be used to help resolve to a single device.

Beyond the key constructs introduced in the preceding sub-sections, Lantern incorporates a rudimentary recommender system. The recommender allows processing of tariff information which is provided by utilising information from energy suppliers websites. At present this is done by hand and is stored locally within the system. The purpose of the recommender is to allow the system to offer suggestions to the end-user and inform them if performing the action at an alternative time could provide some cost savings. The time-window parameter specifies how much time to consider before and after the current time. If a better alternative has been found within this window, then a recommendation will be made. This language feature has been added to complement other work that the authors are undertaking in looking into ways of reducing the energy footprint of an individual within their home.

The recommend construct is triggered when a condition statement or composite set of conditional statements evaluates to true. If this is the case, the associated action is performed which can allow either a direct notification to be passed to the user or by generating another event. The basic syntax of the recommend key word is as follows.

An example use of the recommender and how it can influence the system is as follows.

3.8. Energy-aware software compositions

To demonstrate the usefulness and applicability of the language a supporting middleware has been developed based on previous work [19] to support energy-aware software compositions. The middleware provides control, communication and monitoring capabilities of connected devices and user defined programs for controlling and adapting the power usage of the language. Figure 2(b) provides an overview of the hierarchical nature of the Lantern Stack. The Lantern compiler was developed under C++ and compiles Lantern code into Java which is subsequently compiled to a set of Java files and linked into the Lantern Middleware. The middleware was developed using Java to enable portability and availability of the middleware on different platforms.

Constructs within the language provide exposure to hardware devices that control what functionality is on offer to the middleware. This is through a set of proxy devices which act as an interface between the middleware and hardware. In addition, the middleware handles the control, coordination, adaptation, discovery/resolution, monitoring and environmental state of all devices and services running within the distributed middleware.

Devices (hardware) represent the physical smart assets which have been subsumed within physical locations. To interface with these devices, two types of software agents are used which act as proxies between the physical and middleware representations of devices. The control agent provides a conduit for controlling the given device by offering a set of capabilities which describe the type, location and controllable aspects of the device. In addition they allow any user generated contextual information to help in the discovery and resolution process as well as allow the middleware to control the operation of the device. There are three modes that are supported, on, off and reduce which align with system concepts present within the language. Conversely, System agents provide telemetry from the device. Each service representation only allows information to flow in a single direction: control information flows to the device while telemetry flows from a device. Keeping these separate allows a simpler model for representing the devices so that they align with their corresponding Lantern constructs (in this case the uses and input or output connectors). One or more environments can be defined which act as zones of control and map to real-world notions of a physical environment such as a building. Inside each environment, one or more locations can be defined which represent physical locations within a building. Inside of these locations, devices will be found which can allow for the transmission or manipulation of state.

When writing system or control agents, contextual information is used to define their type along with their capabilities. This information is used in the lookup / discovery process by which variables are created within the language and then dynamically bound to an associated service at run-time.

Lantern allows the developer to write systems which uses some of the principles from Design by Contract. For example, the use of a similar notion to those of assertions through condition and alias variables. These are used to specify condition matching through the use of late dynamic binding variables for the matching of devices to services. Verification is handled in a number of ways by providing syntax and type verification. For example with user variables or conditions, if the variable is not linked to the correct type of device, an error will occur at run-time. This allows for a stronger type association to the condition or alias to ensure that the correct context is used, or identify an ambiguity if more than one variable is defined but linked to another device. In addition, Lantern also supports the developer with contextual associations between the main constructs so that services can be written which verify the presence of devices within the context of their use. This ensures that a logical set of abstractions of devices used within strongly defined areas. Verification of systems is an extremely important issue in the development of robust, adaptive software. In future versions of the language this issue will be addressed more deeply.

The middleware also provides the coordination and control functionality to maintain all devices located within environments. State information which is transmitted as telemetry event messages are passed throughout the middleware layer. These event messages are exposed to Lantern and forms the basis of triggering corresponding conditional statements. As events are bound to time, location and device, the middleware layer provides a comprehensive way of providing state information which can be accessed and used within the language. State information can represent one or more device states / telemetry as well as offering the ability to form complex user generated conditional statements where events can occur over a given time rather than at the same instant.

Lantern allows users to generate programs based on their requirements for an environment and how to control and adapt to changing demands of power utilisation. These programs are compiled by a compiler which has been implemented to generate agents which work on behalf of users. At present, this is controlled by a single instance whereby all environments are maintained by a single top-level management agent which controls all requirements specified within each of the abstractions. However, this is to be expanded upon to fit in with the rest of the model of the middleware whereby each will be represented by a variety of agents.

4.1. Language comparison

The purpose of the Lantern language is to address whether energy-awareness can be expressed within a language rather than as an addon to an existing language. Because of this, Lantern is feature rich when considering how it can adapt to changing needs within an environment and facilitate the binding, and reconfiguration of connections to other agents and devices. Table 1 shows a high-level comparison between Lantern and C++. Other languages could have been used for this comparison but C++ has good constructs like object-oriented, exceptions and templates suitable for system development, and thus, a reasonable choice for comparison.

This is through the nested constructs dealing with the environment and location and how different rules can be attributed to areas. These constructs allow for the initial bind and subsequent re-binding and discovery of agents within the middleware. Primarily, adapting to changing energy demands requires interpreting and reacting to telemetry generated through service agents interfacing with physical devices. Constructs that deal with initial discovery (or devices for example) are the alias, device , input and output constructs. When interpreting and responding to changes, the constructs dealing with override, condition and action enable altering and adapting the environment based on environmental state information. Higher-level constructs, such as environment and location enable higher-order configuration and adaption details regarding the physical smart space being controlled.

When determining the expressivness of a language, it can be subjective when coming up with metrics which can be used. The approach that has been taken is to use a scenario-based method whereby three scenarios have been created and compiled to show the expressivness of the language when modelling these situations. The first scenario models a smart house (as introduced in the example used in this paper). The second models a smart office environment, while the third scenario is more specialised and is used to control the energy needs for an older person to help them make reduce their energy footprint.

For each of these scenarios, a comparison is made between the constructs and key language notions used. Table 2 compares each scenario.

From this it is possible to observe the following. Although the scenarios were programmed using Lantern, it can be seen that the amount of keywords and lines of code to produce each scenario highlights how little code is needed. No C++ equivalent was produced to directly compare against but it can be assumed that more code would need to be produced to provide for a similar level of functionality.

The lantern language provides specialised constructs for the linkage to physical devices, discovery, and subsequent binding to devices located within a defined area. By providing structures to represent an environment and sub-locations within it provides a clean way of grouping requirements and power adaptability together.

As Lantern is a domain specific language for expressing energy-aware concepts within a language, an important area to evaluate is the energy-aware expressiveness and how this impacts on the generation of code to adapt to changing energy needs. Table 3 shows the use of energy-aware constructs for each of the scenarios.

When evaluating the language, the constructs that facilitate adapting the environmental energy use (overrides and conditions which lead to a change in the environment) vary depending on the complexity of the scenario. For instance, scenario 1 was for a smart house with several devices in a few rooms when compared with scenario 2 (a smart office) show that the complexity and number of constructs used depend on the number of devices available in the environment. The more complex the environment and higher number of devices, translates into a greater number of conditions and overrides used overall within the system.

Scenario 3 models a house which has a couple of rooms to notify older users of when to do things. Specifically, this is recommending when a better time to perform the user action should take place to help improve the energy use within the home. This pulls in the recommender component of the system which uses tariff information relating to how much it costs to use energy from a supplier at different times of the day. Used in conjunction with conditions allows the scenario system to offer suggestions. Data to see if this changed the end user habits were not monitored.

Overall, introducing energy-aware constructs within the language allows producing fairly straight forward systems to adapt to energy needs.

In this section, a comparison of the Lantern language has been provided using several scenarios to highlight the expressivness of the language. However, the intention behind the Lantern system was to investigate ways in which energy-awareness and control can be integrated into a language for coordinating cyber-physical systems with an emphasis on statically located devices and environments. This was a multi-step process where an initial language (Lantern) was first developed to explore what issues lay in providing a domain specific language for controlling the energy use of devices and services within an environment. Based on what was learnt from this initial phases, a more in-depth language (PLECO) is under development which learns from the ewillxperiences gained from Lantern. From these experiences the areas which need expanding from this first phase can be summarised as:

Another area of focus in the next iteration of Lantern is to look at scalability and optimisation. Comprehensive benchmarking will be performed to determine the effectiveness of Lantern against other approaches. This will consider language-based metrics (lines, man hours, keywords, etc.) along with middleware metrics (adaptation, connectivity, discovery, etc.). These as well as other enhancements and considerations are being considered in the next iteration phase of the system called PLECO [18].