Libertas Thing-App and Task
Like the smartphone App, Thing-Apps are applications for the Internet of Things.
Thing-App vs. Smartphone App
-
End-users “use” Thing-Apps on smartphones, just like smartphone Apps.
-
But Thing-Apps are not running on the smartphones. Thing-Apps run inside trillions of connected things.
Thing-App Naming and Identification
A Thing-App shall have a unique name. The Thing-App name follows the same validation rule as developer account name.
If a Thing-App is published to the public in our Thing-App store, it must be published by a registered developer account.
A combination of the developer account name and Thing-App name uniquely identifies a Thing-App globally.
Write Once, Run Everywhere
Libertas Thing-App is designed to be “write once, run everywhere.” The same Thing-App code is automatically compiled for different targets, including:
- Clouds
- Edge device (Libertas Hub)
- IoT Devices, different Microcontrollers (MCUs)
Libertas system automatically chooses the best node to run a Thing-App task based on capability, bandwidth, reliability, and security requirements.
Libertas-OS empowers trillions of things and turns everything into a platform that interconnects and interacts with other things directly, securely, and privately.
Native Code vs. Byte Code
A Thing-App can be based on either byte code or native code.
- Native code
Rust based Thing-App (under development). - Virtual machine byte-code
Lua Virtual Machine + TypeScript frontend, using TypeScriotToLua
Performance and Safety Guarantees
There are guarantees a Thing-App must offer.
- Performance Guarantee
- The Rust-based Thing-App offers performance comparable to C language with similar guaranteed hard real-time latency.
- The Virtual-Machine-based Thing-App also offers a certain performance guarantee, although the performance is many times worse than that of the native code.
- Safety Guarantee
- CPU Safety - Thing-App’s CPU is protected to ensure Thing-App is always manageable and the Thing-App execution will not breach the protection.
- Memory Safety - Thing-App’s memory, including stack memory, is protected. A Thing-App can not access memory out of its designated bounds.
Microcontrollers lack the hardware protections found in bigger CPUs. We can still provide these guarantees on microcontrollers with our design.
Manufacturer Thing-App
A Manufacturer Thing-App can be the default Thing-App shipping with the device as part of the default firmware.
A Manufacturer Thing-App has slightly relaxed safety rules while enjoying the benefits of features, manageability, and sustainability provided by Libertas OS open-source code.
Thing-App Package
A Thing-App package is a single file that can be published to the Thing-App store. The package is an archive of multiple files like the Java jar file.
Note a Thing-App package may have multiple functions. Each function can be used to create a Thing-App task.
The Thing-App package contains a collection of compiled binaries for different platforms and CPU architectures. Once a user creates a Thing-App task, the central controller chooses the best node to run it and then deploys executable binary, and the user inputs data to the node. The executable binary’s architecture shall match the node’s platform and CPU.
Thing-App Functions
A Thing-App is a collection of functions. A function usually has arguments.
A Thing-App can have more than one function.
Public and Private Functions
Only public functions of a Thing-App are exposed.
A public function is declared with the “export” keyword.
A Thing-App code shall export at least one function.
Thing-App Task
Each function can create a process as the process entry point.
In other words, every public function is equivalent to the “main()” function in programming languages such as C and Java.
Like in any other Operating System, end-users can start a new process by passing a list of arguments to an entry function.
In Libertas, a Thing-App process is called a “Thing-App task”.
Using a smartphone or Libertas Studio, a user creates a task by:
- Choose a function from a Thing-App.
- Specify the “task config data” as the input arguments of that function (if there is any)
Tasks may run everywhere, on Clouds, Edges (Libertas Hub), or devices/sensors. Tasks can be managed with Libertas smartphone tool or web tool.
Using our tools, users can easily create, modify, start, stop, and delete a task.
Thing-App Task Configuration UI
Throughout this document, the Thing-App task configuration UI is also called “Thing-App UI.”
End-users use Thing-App on smartphones. The user interface (UI) of Thing-Apps looks no different than that of smartphone Apps.
A smartphone App creates its UI by running the App on the smartphone. A Thing-App, however, does not run on the smartphone.
Thing-App Schemas
The Thing-App UI is automatically generated by analyzing the Thing-App source code. Libertas IDE extracts the data structures of functions’ arguments and definitions of data structures (enums, classes) referred to by these arguments. The extracted data structures are called schema (metadata.)
The schema contains definitions of function arguments and related enums and classes. Libertas Signature Editor is a GUI tool to further enrich the schema with attributes.
Thing-App UI is a tree-data editor following the schema.
Thing-App Task Configuration Data
Throughout this document, the Thing-App task configuration data is also called “task config data.”
An end-user uses the Thing-App UI to edit the “task config data”
The “task config data” directly serves as the task function’s arguments to start the Thing-App task.
The animation below demonstrates how the developer’s code is used to generate Thing-App UI and how an end-user uses the Thing-App UI to create task config data. Click to play the animation.
