Report on Problem Solving Experiment for Realization of Web-API-based IoT

Outline of Web API and COMMA House COMMA House, the smart-house, was built at the Komaba Research Campus of UOT in 2011, with the intention of conducting research into energy, including HEMS and heat insulation performance. The smart-house is intended for demonstrations, equipped with solar power generation equipment and household lithium ion batteries. The research team arranged the system under discussion with multiple businesses so that the concurrent development of value-added applications can be materialized for the acceleration of the dispersion of smart-houses because energy-related applications alone are not sufficient for their consistent dissemination. It is presupposed that the value-added apps will be developed by third parties that are not directly related to the Things in smart-houses and installed in smartphones/tablets. As part of the joint research with private companies, UOT implemented Web API as a prototype, to enable flexible manipulation of the appliances within the smart-house from the devices. Value-added apps allow you to manipulate the appliances within the smart-house. In addition, such apps were implemented in other demonstrative smart-houses around Japan so that installed appliances could be operated based on the same mechanism. The results confirmed that the Web API was capable of absorbing differences in communications media and protocols for operating Things installed in different smart-houses. Many issues with the realization of IoT have already been reported. Web API may be a solution to some of those issues.

shows the structure of a prototype Web API implemented by UOT. The structure has two things of note, which are expected to greatly benefit the realization of IoT. (1) Application to Web API It is often said that a special communications protocol should be prepared for the operation of the Things. However, the cost for learning or additional resources can be avoided if an existing standard protocol is available. This will be a favorable situation for application developers. Accordingly, the structure of prototype Web API permits access from applications with standard protocols, such as HTTP and JSON, which are usually used. (2) Web API to Things The Internet of Things, IoT, is a system that connects everything via the Internet. Needless to say, the Things are limitlessly varied in their prices, with differences of up to five or six digits. One might naturally think that the manufacturing cost would increase if the existing Things that are not networked were connected to the Internet. It would be unreasonable to try to unite the communications protocols for operating the Things. In other words, the acceptable additional cost is naturally different between the Thing worth one dollar and one worth a thousand dollars. Namely, a single communications protocol will not suffice to address the difference.

Firm A| | | | +-+ | +------+ | | | +-+ | +------+ | | +-----+ | |B+-------------------->Firm B| | +-------->alpha+-------> +-+ | +------+ | | | +-----+ | +-+ +-------------+ | +------+ | | | | |C+-->Private Cloud+--->Firm C| | | | | +-+ +-------------+ | +------+ | | | | | | | | | | +-+ +--------+ | +------+ | | | | |Z+-->InfraRed+-------->Firm Z| | +----+ | | | +-+ +--------+ | +------+ | |apps+---+ +------------+----------| +----------+ +----+ | | | +-+ | | | |a+---------+ +----------+ | | | +-+ | | +------+ | | | +-----+ | +-+ +---------->Firm a| | +-------->beta +------> |b+------+ | +------+ | | +-----+ | +-+ | | +------+ | | | +-+ +------------->Frim b| | | | |d+---+ | +------+ | | | +-+ | | +------+ | +------------+----------+ +---------------->Firm d| | | +-----+ | | | +------+ | | |gamma| | | +----------+ | +-----+ | | Things beta +------------+----------+ ]]> A prototype Web API is based on the idea that various communications protocols can be used. It does not matter to users whether the communications protocols are united or not. They are satisfied as long as the Things operate properly. This is similar to the case where users do not find it to be an inconvenience if printer manufacturers have different types of driver software for operating a printer and for printing data from the computer. For this reason, the authors tentatively call the structure of Web API on the Things side the printer driver model. It is assumed that manufacturers of the Things would provide the driver software when the time of IoT arrives.

The following Things were used. They have different communications protocols for their operations. For some, signals of infrared ray remote controllers were emulated for operation. Electric windows Electric blinds Lighting (ECHONET Lite/Hue) Air conditioners (ECHONET Lite and infrared ray) Fans Applications developed for the appliances above by third parties are as follows: Control of windows/air conditioners according to the weather Control of the indoor environment according to the sleeping status of users Control of lighting to respond to early earthquake warnings, such as lights turning on These applications were easily applied to other smart-houses by making changes to the driver portion, after they were implemented at COMMA House, regardless of the different types of appliances.

The previously mentioned basic advantages of Web API can help solve issues in for the achievement of IoT as follows:

IoT services are assumed to involve combined appliances and systems in many different industries. Under such circumstances, it is important to set responsibility demarcation points to maintain security. Being called the printer driver model, Web API is expected to effectively clarify who should update and what should be updated to maintain security. Web API would enable the control of privacy for the obtained data, because it is a mechanism to access all appliances.

Significant labor is required to link applications to the Things. The use of a considerable amount of labor can be avoided by making the Web API intermediary a series of tasks comprised of installation, linking, and calibration, and by performing the tasks like software operations.

The ICT technology used for mobile phones is subject to alteration every few years, while the entrance doors are usually used for twenty to thirty years. If Web API is the intermediary, it will absorb the mismatch between the ICT and the life of Things.

There are still a high number of specifications to be introduced into IoT appliances/devices. Additional specifications are under consideration. Such a wide variety of options should not be overlooked. However, the companies that produce and provide services are not necessarily familiar with the specifications, just being users of the specifications. The Web API that is compared to a printer driver model would support the activities of the companies that produce and provide services while they are not bothered by the specifications for operating the Things similar to the users of printers for computers.

IoT services are expected to become multifarious through collaboration based on open innovation in the future. In this case, interconnectivity will be secured, and open innovation will be accelerated if Web API is used as an intermediary and a point of responsibility demarcation.

In the time of IoT, it is anticipated that Things will change from those packed with many functions to those with simplified functions that are allowed to exhibit their versatility through applications. Again, in this case, if interconnectivity is accelerated and responsibility demarcation points are clarified as stated above, then the collaboration will be accelerated between the providers of the Things and the application producers because of the easy-to-understand structure of Web API.

Same as above.

In some cases, companies hesitate to enter the IoT appliances market because of the increased cost for conversion into IoT, the effectiveness of which can be hard to see. More providers will be able to develop services/applications based on IoT appliances, appliances will do away with more complicated incorporation/implementation than necessary and providers will be able to reduce costs while adding more advantages if connection via Web API is materialized.

A socially acceptable system is required in order to transmit and store varied data collected from IoT appliances and appropriately provide consent. However, it is difficult to solve the issues if data is gathered unsystematically. Web API may help to manage such data and solve problems as a system for accessing all appliances.

The world is moving towards the widespread use of Web API. In todays world, having a strong API strategy is not just good software practice; it is a powerful business practice and the key to apps that connect the Internet of Things (IoT). Some examples of business strategies based around an API: - Amazon has built a multibillion-dollar revenue business in Amazon Web Services (AWS), leveraging powerful API-based elements such as EC2. - Google Maps would be a much smaller business if the only access were directly through its website. - Twitter has opened up an entire class of businesses and analytical modules by sharing its data API and platform. - Even Salesforce.com, with over 800,000 developers and more than 2.5 million applications on the Force.com platform, proudly states that API calls drive more than 60 percent of total traffic to the site.

Those who are interested in Web API with the aforementioned structure are now collaborating in preparation for the creation of Web API with open specifications. For this, UOT is working to provide the opportunity for a discussion that allows private companies to be involved.

Security issues are described in and .

This document has no actions for IANA.