Home
The Internet of Things (IoT) has recently moved closer to being a reality, thanks to the increased abundance of smart objects such as temperature sensors, smoke detectors, smart phones, air pollution controllers, car, parking space controllers, etc. These smart objects sense the physical world by obtaining information from sensors, affect the physical world by triggering actions using actuators, engage users by interacting with them whenever necessary, and process captured data and communicate it to outside world. We expect to see increased adoption of IoT concepts in the fields of personal health, inventory management, and domestic energy usage monitoring, among others.
The aim is to make IoT application development easy for stakeholders. In particular, the aim is to achieve the following objectives:
- To separate IoT application development into different concerns. So, stakeholders can deal with them individually, both in time (evolution) and in space (reuse across applications).
- To provide high-level modeling languages addressing characteristics for IoT applications. This helps stakeholders to reduce both complexity and development effort associated with IoT applications.
- To automate IoT application development where possible. This helps to reduce development effort of stakeholders.
In the next section, we briefly illustrate each step of IoT application development. For Hello world application, we consider a building automation domain. A building cluster might consist of several buildings, with each building in turn consisting of one or more floors, each with several rooms. It may consist of a large number of heterogeneous devices equipped with sensors to sense environment, actuators to influence the environment. An application running on such system aims to regulate appropriate temperature for worker productivity and personal happiness. The temperature in each room of the building is regulated by a sense-computer-control pattern, illustrated as a layered architecture in Figure 1, executing among the temperature sensors and heaters of the room, using the average temperature of room. Based on this, the threshold used by the room’s heater is updated.
To provide the reader necessary background, this section summarizes our IoT application development process (complete tour is available in our publications), illustrated in Figure 2. It separates IoT application development into different concerns and integrates a set of high-level languages to specify them. It is supported by compiler, mapper, and linker modules at various phases of IoT application development process to provide automation. Stakeholders carry out the following steps in order to develop an IoT application using our approach.
The domain expert specifies a domain vocabulary using Srijan Vocabulary Language (SVL) (Step 1). The vocabulary specification includes concepts specific to a target application domain (e.g., building automation, transport, etc.). For example, the building automation domain is reasoned in terms of rooms and floors, while the transport domain is expressed in terms of highway sectors. Furthermore, the vocabulary includes specification of resources, which are responsible for interacting with entities of interest (EoI). This includes sensors (sense EoI), actuators (control EoI), and storages (store information about EoI).
Leveraging the vocabulary, the toolsuite generates (Step 2): (1) a vocabulary framework to aid the device developer, (2) a customized architecture grammar according to the vocabulary to aid the software designer, and (3) a customized deployment grammar according to the vocabulary to aid the network manager. The key advantage of this customization is that domain-specific concepts defined in the vocabulary are made available to other stakeholders and can be reused across applications of the same application domain.
Using a customized architecture grammar, the software designer specifies an application architecture using Srijan Architecture Language (SAL) (Step 3). He specifies computational services and interactions with other components. Computational services are fueled by sensors and storages (defined in the vocabulary). They process inputs data and take appropriate decisions by triggering actuators (defined in the vocabulary specification).
The development framework leverages an architecture specification to support the application developer (Step 4). To describe the application logic of each computational service, the application developer is provided an architecture framework, pre-configured according to the architecture specification of an application.
To describe the application logic of each computational service, the application developer leverages a generated architecture framework (Step 5). It contains abstract classes (we assume that the application developer uses an object-oriented language), corresponding to each computational service, that hide interaction details with other software components and allow the application developer to focus only on application logic. The application developer implements only the abstract methods of generated abstract classes.
Using a customized deployment grammar, the network manager describes a deployment specification using Srijan Deployment Language (SDL) (Step 6). The deployment specification includes the details of each device, including its regions (in terms of values of the regions defined in the vocabulary), resources hosted by devices (a subset of those defined in the vocabulary), and the type of the device. Ideally, the same IoT application could be deployed on different target deployments (e.g., the same inventory tracking application can be deployed in different warehouses). This requirement is dictated by separating a deployment specification from other specifications.
The mapper produces a mapping from a set of computational services to a set of devices (Step 7). It takes as input a set of placement rules of computational services from an architecture specification and a set of devices defined in a deployment specification. The mapper decides where each computational service will be deployed. The current version of this algorithm selects devices randomly and allocates computational services to the selected devices. A mapping algorithm aware of heterogeneity, associated with devices of a target deployment, is a part of our future work.
Leveraging the vocabulary, IoTSuite generate a vocabulary framework to aid the device developer (Step 8). The vocabulary framework contains interfaces and concrete classes corresponding to resources defined in the vocabulary. The concrete classes contain concrete methods for interacting with other software components and platform-specific device drivers. The interfaces are implemented by the device developer to write platform-specific device drivers.
The linker combines and packs code generated by various stages into packages that can be deployed on devices (Step 9). This stage supports the application deployment phase by producing device-specific code to result in a distributed software system collaboratively hosted by individual devices, thus providing automation at the deployment phase. We assume that a middleware is already installed on the deployed devices. The installed middleware enables inter-device communication among devices.
To support stakeholders, IoTSuite integrates three modeling languages: (1) Srijan Vocabulary Language (SVL) to describe domain-specific features of an IoT application, (2) Srijan Architecture Language (SAL) to describe application-specific functionality of a IoT application, (3) Srijan Deployment Language (SDL) to describe deployment-specific features consisting information about a physical environment where devices are deployed. In the following, we describe these three modeling languages in detail.
SVL is designed to enable the domain expert to describe a domain vocabulary domain. It offers constructs to specify concepts that interact with entities of interest. We describe these concepts in detail as follows: Regions: It represents the set of regions that are used to specify locations of devices. A region definition includes a region label and region type. For example, the building automation is reasoned in terms of rooms and floors (considered as region labels), while the transport domain is expressed in terms of highway sectors. Each room or floor in a building may be annotated with an integer value (e.g. room: 1 interprets as room number 1) considered as region type. This construct is declared using the regions keyword. Listing 1 (lines 1-4) shows regions definitions for the building automation domain.
Structs: Each resource is characterized by types of information it generates or consumes. A set of information is defined using the structs keyword (Listing 1, line 5). For instance, a temperature sensor may generate a temperature value and unit of measurement (e.g., Celsius or Fahrenheit). This information is defined as TempStruct and its two fields (Listing 1, lines 6-8).
Resources: It defines resources that might be attached with devices, including sensors, actuators, or storages. We describe them in detail as follows:
-
Sensors: It defines a set of various types of sensors (e.g., temperature sensor, smoke detector). A set of sensors is declared using the sensors keyword. Each sensor produces one or more sensor measurements along with the data-types specified in the data structure. A sensor measurement of each sensor is declared using the generate keyword (Listing 1, line 12). For instance, a temperature sensor generates a temperature measurement of Tempstruct type (lines 12) defined in data structures (lines 6-8).
-
Actuators: It defines a set of various types of actuator (e.g., heater, alarm). A set of actuators is declared using the actuators keyword (Listing 1, line 13). Each actuator has one or more actions that are declared using the action keyword. An action of an actuator may take inputs specified as parameters of an action. For instance, a heater may has two actions. One is to switch off the heater and second is to set the heater according to a user's temperature preference illustrated in Listing 1, lines 14-16. The SetTemp action takes a user's temperature preference shown in line 15.