Abstract
IoT devices are diverse in their characteristics and made by many vendors, hence the inter-operation among them is difficult. Especially, end users can’t make their own programs by do-it-yourselves. IFTTT and Zapier platforms are designed to help end users to make them inter-operable easily and prevail in these days. Their approach is categorized into a Trigger-Action-Programming, in which trigger conditions and actions are already made by professional programmers of several IoT vendors and end users composite them into their own applications easily. But, their drawback is that the composition can be made at once in the first level, hence end users can’t make more complicated applications.
Our approach is based on a dataflow programming paradigm which resembles the TAP in that the internal actions are triggered when all the inputs of a node are prepared. In our approach, a composition of some atomic nodes becomes another atomic node, so the composition would continue iteratively. This feature is so generous that several visual programming languages like LabView are relied on the approach for various fields. We propose the overall architecture of our system and explain them. We also present Internet of Things examples of our approach, which shows that atomic dataflow objects can be associated to produce composite dataflow objects. And they are also composited to make more complex applications iteratively. We compare IFTTT, Zapier, and our approach qualitatively and show that end users can make more diverse and flexible applications in our approach.
Keywords
Introduction
A temperature and a light density sensors are equipped in a room and the curtain actuator is deployed in the room. When the temperature is higher than the appointed one, the curtain is winded down. What matters that it is difficult to make them interoperable since they are using different protocols and made from different vendors. 6LoWPAN [1] was devised to make IoT devices from different vendors interoperable via Internet protocol. OneM2M [2] is also for the inter-operation between IoT devices. But, end users who are not familiar with the programming are difficult to make them work through the protocols.
End users are less willing or interested in developing computer applications of their own usage while professional developers can’t pre-develop all the software that end users want. This is the reason why it is necessary for the end user to easily implement the desired function. From these demands, end user development (EUD) systems have been researched and developed in various forms over a decade [3].
Systems for EUD can be found more often for specific applications than for general purpose. Nguyen [4] proposed a NXT-G visual programming tool for robot applications using Lego blocks. RoboFlow [5] presented the Visual Programming tool for programming the control of the robot called PR2. In 2005, Nokia proposed Context Studio [6], an end user programming tool for developing applications that control devices in the home on their mobile phones. In this tool, an end user-defined method of triggering and performing a specified action when a certain condition is satisfied is proposed. For end users, this Trigger-Action-Programming (TAP) scheme [7, 8] is a typical EUD.
IFTTT [9, 10] and Zapier [11] are also the platforms that provide an interface for end-users to bridge different applications in a trigger-action model and easily create automated tasks across diverse platforms [12]. These platforms get more popularity than the platforms uttered above. Their platforms are successful, but they have the lack of user’s programming ability in that user can composite triggers and actions only in the first level.
Dataflow approach began with the exploitation of parallelism of conventional imperative programs like C or FORTRAN programs. Hardware architectures were devised and implemented in 70’s∼80’s. And finally, they were evolved to the field of dataflow visual programming languages (DFVPLs) [14]. LabView [15] is the commercial product based on DFVLPs for the signal processing applications. It means that dataflow approach can be utilized in the field that end users make their own IoT programs by do-it-yourself (DIY).
In this paper, we propose an End User Development (EUD) tool that supports end users to develop their own personal applications. We introduce the dataflow approach, which makes end users generate more complex programs with simple programs, and present the EUD system based on it. By presenting an application example, we illustrate that it is easier to describe a composite sentences than the recently activated IFTTT (IF This Then That) system.
Backgrounds
Related works of EUD systems
Since general-purpose EUD systems must have all the features required by professional software developers, systems for EUD can be found more often for specific applications than for general ones. For example, Nguyen [4] proposed a NXT-G visual programming tool for robot applications using Lego blocks. It is a development system similar to the flow chart and suggests a level of EUD that students can easily learn. RoboFlow [5] presented the visual programming tool for programming the control of the robot called PR2. It is also based on flow chart and it is available to the end users using the robot.
In 2005, Nokia proposed Context Studio [6], an end user programming tool for developing applications that control devices in the home on their mobile phones. In this tool, an end user-defined method of triggering and performing a specified action is proposed when a certain condition is satisfied. For end users, this Trigger-Action-Programming (TAP) scheme is a typical EUD system and also utilized in the iCAP [7] system. Lin [8] supported a tool called Vegimite, which helps end users to mash up their own new information from the search results of Internet information.
IFTTT and zapier
The IFTTT (If This Then That) site [9, 10] provides TAP-based automatic programming techniques for end users. After 2012, many companies are providing solutions for end users. They use simply enter the appropriate parameters into it. The IFTTT method is simple to use and is successfully used so that end users input only their own parameter values.
As shown in Fig. 1, IFTTT applications are the same as if-then structure. End users select a “if-condition” among a lot of “if-samples” which have already made by professional programmers, and also choose a “then-action” like the same procedure. In IFTTT, end user’s programs are done in the very coarse grain, which makes it easy to program. The application built is called a recipe.
Examples of IFTTT(a) the applications for WEMO (b) [9].
Zaiper [11, 12] is a web based automation application that can help end users build apps and automate part of their lives or businesses. Zaiper was started in 2011 in Columbia Missouri. After an initial rejection, they built their initial prototypes that consisted of 25 apps. The apps that are build using Zaiper are called Zaps. Zaps contain a blueprint of the task that needs to be done over and over. The Zap will contain a trigger and an action for the specific trigger. You can mix, match and trigger about any task with Zaps automated actions.
Dataflow Programming is a method of modeling a program as a directed graph. A program consists of nodes and edges. The data flows through the edges and the processing of the data is done in the node. For example, a typical arithmetic expression, A: = X + Y is represented by a graph of a node processing a ’+’, the input ‘X’ and ‘Y’ of the node, and the output ‘A’ of the node. When the inputs, ‘X’ and ‘Y’ are moved into the node, the ’+’ operator is triggered and the result, ‘A’ is sent to the next node. Dataflow programming is very useful when it supports parallel processing, and it has been widely studied in the 1980s [13]. Figure 2 shows that the left algebraic expressions are converted to the equivalent dataflow diagram.
A simple program (a) and its datafloww equivalent (b) [13].
Research into dataflow was originally the exploitation of parallelization of general programs. Dataflow hardware architectures were devised and implemented in 70’s∼80’s. And also, dataflow programming languages were developed and finally, they were evolved to the field of dataflow visual programming languages (DFVPLs) [14]. LabView [15] is the commercial product based on DFVLPs for the signal processing applications. As can be seen in the previous history of dataflow approach, it can be utilized in the field that end users make their own IoT programs by do-it-yourself (DIY).
Overall architecture
In this section, we present our EUD platform, which is composed of 3 major parts. Figure 3 depicts the overall architecture of our system that is composed of 3 major parts as follows.
Overall Architecture of Our System.
An end user visits our web site for choosing his own application for inter-operating IoT devices and his smartphone. If he does not find proprietary application, he would make his own by DIY. At that time, he use the service template authoring tool for editing the application. Through service template repository, he could find atomic templates or composite templates to make his application. After his application is completed, it is transferred to the web object repository in his smartphone.
It is a visual programming environment as shown in the figure. It is for end users to edit their own mobile applications which will be executed in their smartphones. End users can search proprietary service templates from Service Template Repository. The templates are moved to the authoring tool to make a new composite template. Composition is made according to the rule of dataflow programming paradigm, in which an output of a node may be connected into the input of other nodes. Authoring procedure is so easy for end users to program them since they have only to connect nodes to nodes through the tool.
Service template repository
That is a data base to manipulate a lot of service templates. This supports end users to store, retrieve, insert, delete, and find functions, especially inter-operated with Service Template Authoring Tool and end users’ smartphones.
End user’s smartphone application
This application has 3 sub-parts, Web Object Repository, Scheduler, and Peripheral Manager The repository helps end users to find adequate service templates co-operated with Web Object Repository. In the repository, an end user makes his own web object from the template. For Example, his own parameters, ‘AM11’, ‘Alarm Message’, and ‘Hong’ are inserted in the service template to become his own web object that send an alarm message to his friend ‘Hong’ in ‘AM11’. Another part is to make the web object work well. If user executes web objects, they are converted to web object entities (woe). A woe is inserted into the suspended queue until all input are delivered to it. After all input arrives, woe is moved to ready queue as shown in the figure. Since web object entities are web documents originally, the webview is the major part in the function. The final part is for device manager, time manager, and location manager. Device manager handles the input/output between IoT devices and the smartphone. Time manager is obtaining the current time exactly. Location manager gets the location through GPS, WIFI footprint, and so on.
Atomic templates
Atomic templates are originally web pages which will be presented by the webview in a smartphone. They are programmed by professional web programmers. Some of them are relevant to IoT devices. Some of them would be gathering information through web search. Others might be in the role of smartphone applications.
All templates have 3 attributes. They are the service name, the input/output, and user parameters. In the top of Fig. 4, ‘Sensor Control’ is the service name. ‘Temp Appointment’ and ‘Light Appointment’ are user parameters which will be inserted by a user when it is finally serviced. ‘Temperature’ and ‘Light’ are input from devices or other peripherals. ‘Up/Down Control’ is the output. Figure 4 shows 2 atomic templates.
Atomic templates.
Sensor Control service means that the temperature value and the light value reach over the threshold pre-defined by user parameters, ‘Temp Appointment’ and ‘Light Appointment’, then the ‘Up/Down Control’ is output.
Curtain service means that the curtain is actuated according to the input, ‘Up/Down Control’ to produce the output, ‘Up/Down Event’
Figure 5 shows the composition of atomic templates shown in Fig. 4. Two templates are linearly ordered to make ‘Curtain Control’ service. User parameters are inherited from the atomic templates and exposed outward the composite template, while the ‘Up/Down Control’ is hidden inside the composite template.
Composition of Atomic Templates.
Figure 6 shows 3 examples of service templates. They are Alarm Clock, Messenger, and Curtain Control. Alarm Clock stands for “At ‘Time Appointment’, an alarm is ringing and ‘Success Event’ is output after a user pushes the stop ‘Button”’. ‘S/F Event’ means that either ‘success event’ or ‘fail event’ is output. And, ‘S Event’ means that the action is completed successfully to produce a success event.
Three atomic templates.
Messenger stands for “After ‘S Event’ is arrived, the ‘Appointed Message’ is sent ‘To Whom”’. Curtain Control means that the ‘Up/Down Event’ is output if the temperature is less than ‘Temp Appointment’ or the light density is lower than ‘Light Appointment’. Each service can be used in the separate manner.
Three templates are either atomic templates or composite templates. Especially, Curtain Control is the composite template shown in section 3.3. But, it becomes the atomic on recursively.
In Figure 7, it is shown that 3 atomic templates are composited to make 2 composite templates. When they are composited, the parameters are maintained to be fulfilled by end users for their own purposes. Alarm Messenger stands for “In ‘Appointed Time’, alarm is ringing and when a user pushes the stop button, then ‘Appointed Message’ is sent to ‘To whom’, finally success or fail is output”. This composition is made in Service Template Authoring Tool by end users. Curtain messenger is the composition of 2 templates, ‘Curtain’ and ‘Messenger’, and the meaning is that a message is sent after the curtain works as similar to Alarm Messenger.
Composition of 2 atomic templates.
Figure 8 shows the overall architecture of IFTTT and our platform. In the figure, programmer level means that professional programmers make the level with conventional programming languages like C or HTML5. End user level is means that end users can make the application easily with some clicks and choices. In IFTTT platform, end users make their application only in the first level. In our system end users can composite services in the several levels. It is mainly caused by the dataflow paradigm which we adopt in our platform.
(a) The architecture of IFTTT (b) the architecture of ours.
Table 1 shows that the comparison between IFTTT, Zapier, and our platforms. This table is relying on the original analysis [16] and we add it with our features. As seen in the table, IFTTT and Zapier are oriented from both TAP approach while ours are based on dataflow paradigm. Our platform is now under construction, but we aim at more general applications than both IFTTT and Zapier since the spine of our platform is dataflow paradigm. Dataflow approach is so generative that it can be used as a general purpose programming language in the fine grain. In the coarse grain, a visual programming language was built and utilized in the several applications [14].
The Comparison among IFTTT, Zapier, and our platforms
In this paper, we propose an End User Development (EUD) tool that supports end users to develop their own personal applications in their mobile terminals. We introduce the dataflow approach, which is the core concept of our system. We suggest the overall architecture of our system and some examples. By presenting an application example, we illustrate that end users make their applications only in the first level in IFTTT and Zapier while end users can composite services in the several levels in our platform.
Our platform is now under construction, but we aim at more general EUD platforms than both IFTTT and Zapier since the spine of our platform is dataflow paradigm which is so generative that it can be used as a general purpose programming language in the fine grain. In the coarse grain, a visual programming language was built and utilized in the several applications [14].
Footnotes
Acknowledgments
This research was supported by Next-Generation Information Computing Development Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT (NRF-2017M3C4A7069073, No. NRF-2017M3C4A7069075)