Tizen developers contemplate the Internet of Things

At the Tizen Developer Summit in Shanghai, several presentations dealt with hardware makers' desire to develop "smart appliance"-style devices in the vein of the Internet of Things (IoT), but there was not a single vision from the project on how exactly Tizen would best fit into an IoT product. One team advocated developing an IoT-specific protocol stack that could be attached to existing Tizen device profiles, while another proposed stripping additional layers off of the usual Tizen profiles, leaving a minimalist system behind. Reconciling the two approaches may not be a simple task.

OIC

On the first day of the event, Intel's Martin Xu presented an IoT strategy that was centered around the Open Interconnect Consortium (OIC), a newly announced industry group founded to develop networking protocols for IoT products. Xu began by outlining the challenges to making IoT's oft-cited promise of "connected everything" a reality. "Everything," naturally, encompasses a wide range of devices that vary in computing power and in networking capabilities.

But therein, evidently, lies the difficulty. The tiniest IoT devices tend to be equipped with Bluetooth Low Energy (BLE) radios, while even slightly more powerful devices step up to different network technologies altogether, such as WiFi, and only the fullest-featured, most-PC-like devices end up with the hardware and software to speak both BLE and WiFi. Similarly, the small, simple devices typically run embedded Linux distributions that are stripped down to the bare minimum, sometimes essentially booting to a single application. Thus, the more feature-rich devices designed to talk to these simple devices (for example, a smartphone that needs to connect to a house thermostat or lighting controller) end up with a separate application stack dedicated to each IoT device it interacts with. All too often, the protocols used by the IoT devices are either not supported in smartphone hardware (like ZigBee), or the manufacturer uses an open standard like BLE to wrap around binary, proprietary data packets.

The OIC, Xu said, was started to address these problems by providing an open-source software stack that is transport- and OS-independent. The group's founding members include Intel, Samsung, MediaTek, Broadcom, and Wind River. The OIC reference stack would be available for Tizen, he said, but would also be usable in other Linux distributions and other operating systems.

OIC's architecture (which was shown in a slide) requires multiple layers. At the top level is a resource-oriented API; applications would interact with IoT devices by requesting resources and sending resource-modification commands. The layers beneath provide an abstraction of what networking protocols are actually used as the transport between any given pair of devices. Xu also showed a two-by-two grid depicting various combinations of "client" and "server" packages that any one OIC-capable device would need to implement. A smartphone would be client-only, since it does not offer any IoT resources, but merely connects to the various "things." A traditional embedded device, though, would be server-only, since it does not offer a direct user interface, while other devices might both offer a service and a user-facing interface.

Unfortunately, what the OIC presentation lacked was any specific detail about what the resource-oriented API would actually be—a fact that several audience members seemed to pick up on and subsequently raised questions about during the Q&A period at the end of the session. One audience member commented that what was described in the diagrams amounted to a good approach to API design, but was not an API itself. Two others asked how what OIC intended to do differed from existing IoT efforts like AllSeen (from Qualcomm and others) or Google's Android APIs (which, while not IoT-specific, are nevertheless used by quite a few smart-device products already on the market).

Answers to these questions were not forthcoming. Xu declined to comment on how OIC compared to AllSeen and Android on the grounds that he did not wish to criticize the competition, but said only that OIC's stack, when released, would be more complete than the alternatives. Another audience member asked when OIC's reference implementation would be available, and was told in reply that development was very active, hopefully with something to be released by the end of the year.

Based on the questions asked, more than a few people in the audience found the lack of detail frustrating, especially given that Intel and Samsung, the two main driving forces behind Tizen, were also said to be key players in OIC. After all, the challenges to turning IoT from a hodgepodge of individual devices that do not speak a common protocol into a set of well-connected nodes that interoperate smoothly are well-known; the existence of other solutions like AllSeen is evidence of that.

Tizen Micro

A far more concrete approach to building software for IoT devices was presented in a pair of talks about Tizen Micro, a stripped-down profile designed for "headless" products. Intel's Bingwei Liu presented an overview of Tizen Micro in a session on the second day of the event, and was followed by a joint talk from Biao Lu and Austin Zhang on how Tizen Micro is built and deployed using Yocto.

Liu's session also started with a description of the challenges of making a reusable IoT software platform, although he emphasized that, even within a given product class, the specifics of a device can make for drastically different system specifications. An "IP camera," for example, could describe anything from a simple room monitor that streams video back to a single source all the way up to a truly smart system that did object- and facial-recognition and responded to gesture input.

Despite the common perception that IoT devices were machines of modest resources, Liu argued that they still required many of the same system components found in more feature-rich consumer electronics devices. For instance, although IoT devices are generally "headless" in the sense that they do not have an attached display, many of them still require a multimedia processing stack—either because they come with cameras (as in the IP camera examples), or provide microphones and speakers for voice interaction. As a result, while they can dispense with a compositor, they may still need the majority of the GStreamer components used by a device with a graphical user interface.

Similarly, while IoT products are often associated with small storage, memory, and CPU requirements, those measurements can be misleading. The small storage and memory footprints often stem from a desire to reserve as much space as possible for user-installed files and applications, so the total amount of memory and filesystem space to be managed by the OS may not be all that small. And while each running process may be modest, consumers expect most IoT devices to support multi-tasking: no one wants the video stream from their smart-home server to slow to a crawl whenever someone else in the house adjusts the climate controls running on the same device.

Liu and the others on the Tizen Micro team set out to adapt the base Tizen system for such headless, yet still full-featured, systems. The effort is currently in the proposal stage; if it is accepted by the Tizen Steering Group, it is not yet clear whether Tizen Micro would be seen as yet another device profile (along with smart TVs, smartphones, in-vehicle infotainment systems, and wearables) or something different.

The Tizen Micro "bill of materials" (BOM), as Liu described it, is essentially Tizen Common (Tizen's base layer) with certain packages removed. It includes the kernel, BusyBox, the dropbear SSH server, SQLite, nginx, node.js, Python, and various networking modules (including BLE). Interestingly enough, Liu commented that it may also include OIC as soon as there is an OIC release to include.

Lu and Zhang's presentation focused on how the team actually builds Tizen Micro test images. Lu, who led most of the session, started off by saying that developing software for small embedded systems like IoT products is notoriously difficult, but it is difficult for known reasons that can be worked around. Setting up the development environment is complicated (and small errors on the development system can cause large problems on the final device), developers need to possess an understanding of the entire software stack (from kernel drivers right up through middleware and applications), and the stability demanded of embedded systems means rigorous verification and testing are required.

Tizen Micro can alleviate some of these problems by building on the results of other Tizen profiles, he said: the middleware and development environment are well-tested and reliable, which is often not the case when building an embedded Linux stack from scratch. To handle the other challenges, the Tizen Micro team has focused on using Yocto as the build system, rather than git-build-system (GBS), which is used by the existing Tizen profiles.

The team has developed a Yocto meta-layer (called "meta-micro-common") that it tests on two Intel platforms: the Galileo and MinnowBoard MAX single-board computers. He explained the build process, which is more or less a standard Yocto build. That said, the team has so far only worked with one hypothetical IoT device in mind: a "smart hub" that serves as a router, file server, and a connection point to home-automation devices. Users interested in building Tizen Micro for other classes of device would need to modify the bitbake configuration files—but that, too, is a standard Yocto development chore.

Zhang responded to most of the audience's questions. Attendees wanted to know what the roadmap was for Tizen Micro, to which Zhang replied that so far, all of the work has taken place within Intel—the next step will be to reach out to interested parties at other Tizen partners (most notably Samsung) and test the tools on ARM systems. Only after that would Tizen Micro be a candidate to become an official Tizen project.

Zhang told another audience member that the team has not yet received permission to release its work to the public, but that he hopes to imminently. The team would also like to add support for GBS and the rest of the standard Tizen build tools, but that Yocto made it easier to build a minimal system image, which was the goal. He also chuckled when asked if the team had tested Tizen Micro on Intel's diminutive Edison boards: apparently they are in such high demand that not even everyone at Intel has gotten the opportunity to use one yet.

Less is more

Competing approaches to IoT within one project or company may not sound like an encouraging sign, but in reality it is probably par for the course. IoT is a popular buzzword but, like most tech industry buzzwords (think "cloud computing"), a lot of the buzzing stems from the fact that few people agree on precisely what the term means. Liu highlighted the wide range of embedded platforms that could qualify as an IoT product, and that sentiment was echoed by many of the speakers and audience members. No one is quite sure where the cut-off between IoT and traditional embedded Linux systems lies, so there are naturally a lot of different ideas about what the ideal IoT operating system should contain.

When it comes to Tizen specifically, the Tizen Micro idea certainly seems more fully realized than OIC. But it also may be too far removed from the standard Tizen use case to fit neatly into the overall project. If there are too many levels of "base Tizen" to choose from, eventually some of them may not really be Tizen anymore. Tizen Micro strips out a lot; it remains to be seen whether having the system developed within the auspices of Tizen is a sufficient selling point over a run-of-the-mill Yocto build.

[The author would like to thank the Tizen Association for travel assistance to attend TDS 2014.]