Skip to content

openOBD function hosting

Function hosting is the service that a partner implements which registers the custom partner openOBD functions with the function broker service.

It is possible to host openOBD functions on the network of Jifeline Networks (JNW). Hosting a function means that you as a partner stay in control over your function code (Intellectual Property) and run this code at your own infrastructure. You will stay in control whether your function can only be called from your own partner dashboard, or other partners of the network may call your functions directly. Parts of these hosting features are still in development, currently you can host your functions such they become easily accessible within the ticket workspace of your operators. The bottom line will always be that you are in control of your own IP.

To make your own openOBD functions available in your partner portal you will need to create an application that communicates with the so-called Function Broker (broker). This Function Broker acts as an intermediary for all openOBD function calls and routes the call to the right host is able to execute this specific call. Setting up your application can be done by using the openOBD library. The openOBD library contains the endpoints that are needed to set up the communication between your functions and the function broker via gRPC.

Example design

We will use the openOBD functions setup that is used by Jifeline Networks (JNW) as an example. The basic overview of the JNW openOBD function setup is shown in the following schematics:

Jifeline openOBD Design

In the image above it can be seen that there are two application JNW uses to host their openOBD functions: the Function Launcher (launcher) and Function Executor (executor).

In this example the launcher is the application that directly communicates with the broker. The launcher registers the openOBD functions JNW offers with the broker and executes openOBD function requests from the broker by passing them through to the corresponding executor. There can possibly be more than one executor.

The executor is responsible for the actual runtime of the openOBD functions. It contains the code for specific functions and executes this every time the launcher requests a certain function. There can be multiple executors written in different programming languages (although currently there is only a Python one) that can execute different openOBD functions, the launcher knows which function is handled by which executor. Each executed openOBD function will result in log output that will be captured and saved to a remote location (an AWS S3 bucket in JNW's case).

The launcher executes openOBD functions on the executor by calling the corresponding API endpoint, with the necessary information (like the openOBD Session)

Example code (Java )

There is a Java example openOBD setup available on this GitHub{target="blank"} page. This consists of the setup JNW uses to host their functions (so a _launcher and an executor), and a way to run this setup locally.

To be able to run these applications you need to have registered at least one openOBD function. After which you can configure the launcher to register this function with the broker. Refer to the code example for more information on configuring the launcher. Information on how to generate a function ID, which is required for registering a function, can be found here.

Create your own openOBD function

The example above will set you up to host your own openOBD functions, but does not contain any real function implementations. Feel free to use the example given above as a base to create your own openOBD setup, or create your own custom environment!