SWiG parameter management proposal demonstration

Schema

parameters_schema.json Defines the structure of the parameter standard
parameters.json demonstrates a cut-down example of a few parameters used in the demonstration code or with particular features of interest
parameters.proto is the proposed protobuf definition to send parameter messages using the standard. It is generated by running the simple script python\json_to_proto.py from this level
python\ folder contains demonstration code to show a very simple implementation of the standard (see notes in demonstration section below)

Demo

The demonstration code simulates a simple configuration of a vessel(vessel.py) with a cabled connection to a wireless modem mounted on an ROV(rov.py). The modem on the ROV communicates wirelessly to/from a remote device (remote.py)

To simplify the code, common functionality shared between all simulated nodes has been extracted to common.py, which is imported to each of the node's Python files.

Communication on each simulated link is simulated by a UDP port or serial connection. For UDP, each simulated device port (vessel, ROV (wet and dry sides) and remote device wet side) each listen on one UDP port on the IP address defined in common.py. Vessel only communicates with ROV dry side, and remote only communicates with ROV wet side, no messages are sent directly between the vessel and the remote unit.

The protobuf definition includes source and target identifiers, then any or all of the following

A list of parameter id's which are requested from the target
A set of responses which are parameter values reported by the target (typically as a response to the above request)
A set of parameters and values which are sent to the target to update its configuration

The demo scripts read the json file directly to get detail which can be used to process and present the data (data types, meanings etc). "Magic numbers" read manually from the JSON and added to the code are kept to a minimum. It should be possible to reference each parameter by id (number) or name (machine-readable name field), but that isn't fully used in the demo.

Usage

Use Python to run the rov.py and remote.py scripts, starting the simulated subsea devices. Then use Python to run vessel.py . In the demo, it will interrogate each modem (the ROV one and the remote one) for some parameters and print the results on the console.

Serial support

To use serial ports for communications, install python serial pip install pyserial installs python serial port support And change the definitions for each end of the required connection (ports, speeds) in common.py Example implementation of serial and UDP alternatives are commented out in the supplied common.py

Protobuf

pip install protobuf installs protobuf support for python pip install cobs installs COBS support, to guarantee buffers only have nulls as terminating bytes for transmission pip show protobuf confirms version of python protobuf installed

On initial test, output of pip show protobuf was

Name: protobuf
Version: 4.21.6

Install a matching version of protoc (e.g. from protobuf release page ).

For example, to match the python version installed above, V21.6-win64 was used.

Command line to create python\parameters_pb2.py (assuming protoc is extracted to a folder called protoc-21.6 'beside' the one containing this README file) :

..\protoc-21.6\bin\protoc.exe --python_out=python .\parameters.proto

Resources

Use The JSON Faker to generate fake JSON for the given schema to check schema constraints- paste the proposed schema in to the left window, and each time you press 'Generate' on the top right a fake file will be produced in the right window which complies with the schema
Use The JSON Validator to validate the standard specification data against the given schema. Note that only the outer array of the specification file is required, remove the preceding {"all": and trailing } text (some validators need them, some don't accept them... there's probably a reason for that which can be fixed, somehow)
Tutorialspoint provide a useful protobuf tutorial

Misc Notes

Index by parameter ID, easy to make it unique
default for all access is 'no', only list free/authenticated. If manufacturer optional, add separate field for this?
auth authenticated how, and per connection assumed (i.e. make and authenticate connection, not per message?)
if auth is specified in standard, is it a)allowed or b)required? maybe better to leave out auth for now
Minimum for Standard compliance major and minor should always be set as the current version of the standard as of this document
Wet type 0=acoustic, 1=optical, 2=inductive, 3=radio, minimum and maximum set accordingly. Does it need to be a list of types supported in this standard instead?
Background light level and noise are set as read-only (writable with auth on spreadsheet V3_20Jul22 presumed typo)

manuignatius / subsea-wireless