​
Cloud-Based

Unlike config schemas, configuration data is not stored in a git repository. Instead, configuration data is stored in the cloud and is accessible via the Miru dashboard or programmatically via the Miru REST API.

Miru uses the concepts of clients, tags, and metadata to structure how configuration data is stored and used.

Think of tags and metadata as a datastore for configuration data. This data is then referenced by policies to distribute concrete configs in the format of a particular config schema.

​
Clients

A client is the machine to which concrete configs are deployed. This could be an NVIDIA Jetson, Raspberry Pi, industrial PC, or any other machine running your application.

​
Tags

Groups of clients share configurations based on criteria like hardware, customers, location, etc. Miru uses the concepts of tag types and tags to group clients in a logical way.

A tag type is a group of related tags, while a tag is an instantiation of a tag type. Examples illustrate this best.

A hardware tag type could be used to group clients based on the hardware they run on: Raspberry Pi 4 Model B, NVIDIA Jetson Orin Nano, and NVIDIA Jetson Orin AGX.

An environment tag type could group clients based on the stage of development they are in: Dev, QA, Beta, and Stable.

An accelerometer tag type could define a tag for each accelerometer: Accelerometer 1, Accelerometer 2, Accelerometer 3, Accelerometer 4, etc. A client’s accelerometer tag would reflect the specific accelerometer in use by the client, which may change as accelerometers are replaced or upgraded.

As the name suggests, clients can be “tagged” with a particular tag.

​
Metadata

Metadata is data stored about a particular client or tag.

Maybe robots support certain features based on their hardware. This information can be stored as metadata for each tag in the hardware tag type.

For example, let’s say robots running the NVIDIA Jetson Orin Nano can support the jump and spin features but not the backflip feature. This information can be stored as metadata for the NVIDIA Jetson Orin Nano tag.

Similarly, clients may have unique data of their own, such as an ID. Miru allows the storage of arbitrary metadata for each client as well. Here we’re storing robot_id as metadata for a client.

A metadata schema defines the constraints on the metadata.

Metadata schemas are written in a configuration language like JSON Schema. The following JSON Schema is a plausible metadata schema for the robot_id metadata we showed above.

Miru requires every tag type to have a metadata schema describing what constitutes valid metadata for any tag of that tag type. For instance, the hardware tag type may have the following metadata schema to specify the features (jump, spin, backflip) supported by a given hardware.

Any tags of the hardware tag type can only store metadata that adheres to the hardware metadata schema.

Metadata schemas look eerily similar to config schemas but serve a different purpose. A metadata schema does not describe or enforce any constraints on the concrete configs that are deployed to clients. Metadata schemas only describe what constitutes valid metadata, effectively structuring the metadata stored for clients and tags.

​
Customization

Tags are completely defined by you. We gave examples with the hardware, accelerometer, and environment tag types. However, you can define any tag type you want and create any amount of tags for each tag type.

This flexibility allows you to tailor tags to the needs of your application. Maybe your customers don’t have unique configurations. A customer tag type would be unnecessary then. You may have many different sensor types. Defining a tag type for each sensor type would then prove useful.

The metadata stored for clients and tags are also completely defined by you. We showed simple examples of metadata and their schemas: a client storing a robot_id and hardware tags storing supported features like jump, spin, and backflip. However, you can define the metadata custom to your application.