Overview

Soracom Orbit is an inline data processing service that gives you the ability to write custom programs that transform device data as it passes to and from the cloud. With Orbit, your devices and cloud services can speak in their own separate languages, while Orbit provides translation in between.

In many IoT applications, differences between hardware requirements and cloud architecture considerations often lead to situations where devices and backend services speak different languages. For example, your hardware engineers may be trying to reduce power consumption by transmitting data only in raw binary without any additional processing, while your backend developers are building systems that handle data in a more universal format like JSON to ensure cloud services can be easily maintained. Usually, some amount of compromise is required, such as formatting the data on the device before sending it, or implementing additional server functions to parse device data.

Orbit lets you build a translation layer so that data is seamlessly transformed between different formats, which allows you to keep device and cloud concerns separate and maintain a highly scalable architecture.

With Orbit, you can:

Apply new data formatting to devices in production without rolling out new device firmware or software updates.
Minimize power consumption and data usage by formatting data in the cloud rather than on the device.
Use third party devices that send data using proprietary formats, without changing any backend code.
Mix and match devices types that each use different protocols, while ensuring that all data is conformed by the time it reaches your servers.
Reduce reliance on external tools or services that may be required to convert device data from one format to another.

Orbit is a bidirectional service, meaning that data transformation can happen both from device-to-cloud as well as cloud-to-device. In addition, Orbit gives you the power to customize the transformation applied in each direction.

Architecture

Orbit consists of the following components:

Soralet - A containerized WebAssembly (WASM) runtime environment on the Soracom platform that proccesses data.
Module - A WASM module containing your code for processing data.

With Orbit, you first develop a module on your local machine, implementing the actual code that transforms device data into a format understood by your servers, or vice versa. Then you create a Soralet and deploy your module into this environment.

Orbit overview

You can then activate the Soralet for a Soracom device group, and once the devices begin sending data to your servers, the Soralet runs the code on the device data, as well as any responses sent from your server back to the device.

Compared to Binary Parser

Binary Parser provides some similar capabilities by receiving binary data sent from your device and decoding it into JSON data based on a pre-defined format.

While Binary Parser does not involve any code development, it has several significant limitations:

Data is processed in one direction only, from device to server.
Only binary data can be decoded. Other data formats are not supported.
Because binary data is decoded according to a pre-defined format, variable-length data is not supported.

Compared to Funk

In terms of functionality, you can also use Soracom Funk to send device data to a cloud function service (such as AWS Lambda, Azure Functions, or Google Cloud Functions) in order to process the data before sending the data to your servers. However, as this process involves an external function provider, there are several limitations:

Funk sends your data to an external service for processing, while Orbit processes your data on-platform, which may result in improved latency.
Orbit can be combined with other Soracom services, such as Harvest and Lagoon, in order to handle the processed data directly inside the Soracom platform. When using Funk to send data to a cloud function, the data cannot be returned to Soracom for further data handling.

Orbit SDKs and Tools

Soracom provides SDKs for developing WASM modules in the following programming languages:

AssemblyScript - A subset of TypeScript, dedicated to writing WASM modules, for developers who are familiar with JavaScript development. In some cases, you can use existing NPM packages to speed up module development.
Rust - One of the most popular languages that has grown rapidly recently, and which is highly compatible with WASM module development.
C/C++ (using Emscripten) - A toolchain that allows you to compile C/C++ source code into WASM modules, for engineers that specialize in embedded development.
TinyGo - A subset of Go programming language for microcontrollers and WASM.

In addition, Soracom provides tools for Visual Studio Code that allow developers to test and deploy to a Soralet directly within VS Code, to provide a robust development experience.

Limitations

Each Soracom account is limited to 20 Soralets.
Each Soralet is limited to 10 WASM modules.
At this time, Orbit only supports Air for Cellular devices. Sigfox and LoRaWAN devices are not supported.
Devices must send data to Unified Endpoint in order for the data to be processed by Orbit.
WebAssembly System Interface (WASI) is not supported. System calls, such as file system operations or network access cannot be implemented in a Soralet module.
A WASM module cannot be used to programmatically change where data is sent.
If multiple users in your account attempt to list, test, update, or delete a Soralet at the same time, you will receive an error message stating another ongoing activity (SLM1017). When completing these actions for a Soralet or browsing the Soralet management page of the SORACOM User Console, please do so with one user account at a time. If you see the described error message, please wait a few minutes and try again.

When developing and testing a module, the following resource limitation apply:

Each compiled WASM module must be 4 MB (4,194,304 bytes) or less.
When a module's uplink() or downlink() function is called, it is subject to the following restrictions:
- Maximum execution time: 1 second
- Maximum memory usage: 16 MB
- Maximum log message size: 65,536 bytes total
The name of a Soralet can only consist of numbers, letters, underscores, and hyphens, and must be 100 characters or less.
Testing deployed modules (such as using the soralets exec Soracom CLI command, the testSoralet API, or the Orbit VS Code extension) is limited to 5 tests per minute.

In addition, the following limitations may apply due to Orbit runtime restrictions:

AssemblyScript
- Date - Not available
- Math - Not available
- The JSON encoder/decoder included in the AssemblyScript SDK is not compatible with multi-byte characters.
TinyGo
- You cannot use WASM modules that depend on the TinyGo JS runtime syscall/js.*. Doing so will result in an error, such as unknown import function: env.syscall/js.valueGet (SLM1011) when using the fmt package. You can check your WASM module's dependencies by using the wasm2wat command. For example:
```
wasm2wat build/soralet.wasm | grep 'import "env" "syscall/js.'
```
  Please refer to Using WebAssembly for details.
- The json package is not available since TinyGo does not support it. As a workaround, the Orbit SDK uses following libraries:
  - moznion/go-json-ice
  - moznion/jsonparser (without_js_runtime_tinygo branch)
  You can find available packages here: Packages supported by TinyGo

Implementation

Developing WASM modules for use with Orbit involves the following steps:

Set up a WASM module development environment on your machine using the SDKs provided by Soracom
Develop a WASM module and test it locally
Create a Soralet and deploy a WASM module, then test it remotely on the Soracom platform
Configure a group to use your Soralet
Begin sending and receiving data with an Air device attached to the group

Free Tier

Soracom provides a free tier for Orbit with each Soracom account. Refer to the Pricing & Fee Schedule for more information.