Tizen RT Long-term Goals

From Tizen Wiki
Jump to: navigation, search

IoT JavaScript Framework

Tizen RT provides Application Framework based on JavaScript. JavaScript has strong point especially in IoT devices since it has huge amount of developer community support and fast development cycle. The Application Framework is built on top of ultra-light JavaScript engine (JerryScript) and asynchronous I/O event processing library (libtuv) which enables fast app development and prototyping for individual IoT developers. IoT JavaScript Framework (IoT.js) will support ARTIK in the first quarter of 2017 and continue to open source activities to increase popularity of IoT.js.

IoT Javascript Framework Block Diagram.JPG

Figure 1. IoT Javascript Framework block diagram

IoT app framework called IoT.js will be provided as well as described in Table 1.

IoT App Framework Ultra-light JavaScript Engine Small enough to fit in IoT devices

• ES5 support

Ultra-light JavaScript Runtime Small JavaScript runtime which support IoT application lifecycle and JavaScript APIs requires IoT Applications. Support asynchronous I/O event processing
Binding layer for IoT library

(e.g. OCF libaray)

Provides binding layer and enables native functionality with additional libraries.

In case of OCF, basic features based on TinyAra will be supported initially.

S/W Update

For home appliance products, Tizen RT supports the proprietary S/W update mechanism developed by Samsung. However, Tizen RT will be the open source project soon. This means that non-Samsung devices which run Tizen RT require the S/W update service as well. In order to support non-Samsung devices, Tizen RT will support OMA lightweight M2M (LWM2M)-based FOTA in 2017. ARTIK Cloud has already supported LWM2M.

Fault Tolerance

IoT platforms are facing a challenge about large-scale device management of deployed IoT devices. System reliability has become a key success factor of IoT platforms. If a critical bug in device drivers or other system components occurs, the whole system is inevitably crashed in the case of traditional monolithic kernel. We need a clear solution to overcome this challenge. However, typical target devices of Tizen RT have only MPU (memory protection unit). Without MMU (memory management unit), protecting the system from faults is much more difficult. In order to provide MPU-based fault isolation, Tizen RT pursues four stepwise approaches.

  • per-thread memory protection
  • microkernel architecture
  • self-healing
  • live update

Assuming the completion of all these features, Tizen RT can be safely protected from any kind of faults. For example, even though a network component encounters a critical error, this fault can be identified by memory protection and isolated by microkernel architecture. The network component can be restarted by self-healing without any effects to the entire system. If that component is not self-healed eventually, it can be updated by live update through the S/W update.

1. Memory Protection

Tizen RT supports not only flat build but also memory-protected build. The former can help to reduce the memory usage at the expense of memory vulnerability. The latter can be achieved at the cost of about 20~30% increase of memory usage. Which mode fits best for low-end IoT devices? It surely depends on the trade-off analysis while considering S/W requirements and H/W limitations. User/kernel space separation is already achieved. The entire memory map is divided into user and kernel spaces. Kernel space is exclusively accessed by only kernel. Any user tasks which illegally attempt to access this memory region will raise an exception. In this mode, kernel executes with privileged permissions while user threads execute with unprivileged restricted permissions as shown in the figure below. Per-thread memory protection will be provided in the first half of 2017. The user thread is executed in the user unprivileged mode with restricted permissions. When multiple threads are running, the scheduler shall preempt the current running task and bring the new ready-to-run thread for execution. The stack / data region of thread A is protected from being written by thread B even after thread A is preempted by thread B. This per-thread protection can be realized by MPU which stores and restores the MPU context of every thread at every context switch.


Figure 1.Concept of User and Kernel Separation

2. Microkernel Architecture

Microkernel aims at minimizing kernel functions only including scheduling, task, memory, and IPC. Other kernel modules like device drivers, network stacks, file system should be isolated from kernel as isolated components. This isolation has each system component execute as a separate user space thread/task. The kernel can be communicated with the isolated components in user space through IPC as shown in the figure below. The frequency of IPC usage inevitably becomes higher than that of monolithic architecture. This is why the IPC design to minimize its overhead is a key success factor of microkernel architecture. Microkernel architecture will be designed in the first half of 2017 and the per-thread memory protection will be followed by the microkernel implementation.

ConceptofMicrokernelArchitecture2.png ConceptofMicrokernelArchitecture.png

Figure 2. Concept of Microkernel Architecture

3. Self-Healing

Recovering from failures makes a system sustainable. To this end, Tizen RT can detect faults regardless of where the faults happen. A dedicated component called service manager can monitor all system components via IPC and control their execution. After detection, the crash event is notified to the components (orange balloon) which have dependency on the faulted component (pink crashed balloon) as depicted in the figure below. Then the orange component immediately halts its dependent tasks and waits for messages from the service manager. If the manager restarts the corrupted one and judges that the restarted component is normally operating, it inform the orange component of the success of restart of the corrupted component. Then, the orange component resumes the halted tasks and normally communicates with the restarted component via IPC. The whole procedure is preceded by the microkernel architecture.


Figure 3. Concept of Self-Healing


Build configuration allows developers to choose the features of Tizen RT at compilation time. Tizen RT can be configured from a full-featured platform to a small, connectivity-oriented platform. Two representative full-featured configurations can be wearable band configuration and low-end home appliance configuration as shown in the table below. Typical hardware requirements include Cortex-M4/R4, more than 256KB RAM, more than 1MB Flash, and Wi-Fi or NB-IoT/Cat-M. The representative configuration of connectivity-oriented platform is shown in the first column of the table below. Typical hardware requirements include Cortex-M3, less than 256KB RAM, less than 1MB Flash, and IEEE 802.15.4 or BLE. This build-time configuration is based on Kconfig which is the same as Kconfig in Linux. For GUI configuration, Tizen RT also adopts menuconfig which is also the same as menuconfig in Linux.

Table 1. Three Representative Configurations of Tizen RT


Support Standard IoT Protocols

While keeping the latest IoTivity version, Tizen RT will support other standardized IoT protocols like Thread and IPSP over BLE in 2017. These protocols can surely promote IoTivity across heterogeneous connectivity devices.

Support Low-end Wearable Bands

The PoC of lightweight UI framework has been developed in 2016 and will have evolved into commercial-level verified framework. This will help IoT manufacturers easily make their own low-end wearable bands with small LCD.