MCCIDistributionSchema
A "Distribution Schema" describes the data that will be shared over the MCCI network.
The single greatest reason for a distribution schema is to save bandwidth and processing time. Rather than using variable-length strings, fixed-length integer IDs are sent in messages and converted to their string equivalents when needed for logging or debugging.
Rather than compute variable names into integers on a per-host basis, we ensure the same name-to-ID mapping on all vehicles by specifying it in advance and placing that exact schema on all vehicles. (It is reasonable to assume that the set of data names understood by a system of vehicles can be agreed upon before deployment.)
The current trend in robotics development is increased collaboration -- separate components being designed by separate groups and later integrated to form a single system. An important part of this process is to ensure that all relevant interfaces are producing appropriately-named data, and in the proper units (recall the Mars Climate Orbiter crash).
MCCI cannot (necessarily) validate that the proper units are being sent in messages from the clients. However, reporting proper units in debugging tools provides developers with a "first line of defense" against false assumptions.
The data distribution is implemented as an SQLite database with the following tables:
| Variable (implemented as 'var' due to reserved words) | ||
|---|---|---|
| var_id | unsigned integer | |
| name | string | |
| enabled | boolean | |
| category_id | unsigned integer | category.category_id |
| protobuf | (identifier) | Pointer to protobuf definition |
| unit | (identifier) | OPTIONAL Pointer to UnitsML (or equivalent) definition of units |
The Variable table is the only part of the distribution schema that is used by the MCCI server. Only the first 3 fields are used in server operation ("enable" being used to allow elements of a master schema to be turned on and off as desired). Protobuf and unit need not be present in a MCCI schema, although they may be of inestimable value to other system components.
| Category | ||
|---|---|---|
| category_id | unsigned integer | |
| name | string | |
| parent_category_id | unsigned integer | category.category_id |
| unsigned integer | category.category_id | |
| (identifier) | Pointer to protobuf definition | |
| (identifier) | OPTIONAL Pointer to UnitsML (or equivalent) definition of units |
The Category table is used to provide a hierarchy of organization for a given variable (such as Sensors->External->Ocean->CTD->Salinity, Sensors->Internal->Navigation->Velocity->DVL->DVL_X). This would be used by various debugging tools to help visually organize the data.
| Tag | |
|---|---|
| tag_id | unsigned integer |
| name | string |
| Variable_Tag (implemented as var_tag for consistency) | ||
|---|---|---|
| var_id | unsigned_integer | var.var_id |
| tag_id | unsigned integer | tag.tag_id |
The Tag and Variable_Tag tables can also be used by debugging tools to name arbitrary collections of variables. For example, all inputs and outputs in a chain of navigation-related processes.