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.