Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: minor edits

...

Alternatively we can focus on the serialization aspect.  This is to define the exact payload in a generic communication protocol - e.g. MQTT which describes the transport and topic structure, but does not in itself define the payload format.  A definition of what is actually transferred on topics is required:

The page Value measurement Data serialization / value formats gives a high-level proposal for message types that are needed in a typical generic data transfer protocol. 

...

Code Block
TimestampedRecord:

message TimestampedRecord_uint32 {
   string ts = 1;   # Zulu time, ISO std with microseconds
   uint32 value = 2;  # (with specific uint32 type -- only valid for signals of that type)
}

# Or alternative that can encode multiple value types:
message TimestampedRecord {
   string ts = 1;   # Zulu time, ISO std with microseconds
   google.protobuf.any value; # There is a default "any" type defined by protobuf named google.protobuf.any but it might not be the only choice
}

message GeospatialRecord {
  GeoPosition pos;  
  stringTimeStampType ts = 1;      # Some efficient time stamp type?  # Zulu time, ISO std with microseconds
  google.protobuf.any value; # ValueType needs to be a union/any/variant type. 
}

# Just a proposal for a GNSS position type:
message GeoPosition {
  float latitude = 1;
  float longitude = 2;
  float accuracy = 3;
}

...

Code Block
message VISS_data_message {
   string path = 1;
   dp_type dp = 2;
   # Other optional parts?  Description, properties ...
}

message dp_type {
   google.protobuf.any value = 1;
   string ts = 2;  # Also here, a more efficient time stamp type??
}