Note: some points mentioned do not reflect the current implementation; things would need to change to accomodate for this proposal.
Device
Sensor Data
All devices are assumed to have the same fixed set of four sensors.
Sensor data is always assumed to be floats (or ints which have to be converted to floats).
Unlike everything else, sensor data is never stored in PostgreSQL; it's retrieved on-demand from DynamoDB.
Schema
A Device stores a name and a description.
It is associated with one and only one user.
It is associated with zero or more Tests.
Parameter
Each sensor is associated with a Parameter. There can also be manual ones that allow arbitrary user input.
It stores a name, description, and unit name.
It is associated with one and only one Test.
UNSURE: We could change this to a many-to-many relationship which would allow a sensor to be scheduled at multiple different times.
It is specific to a Device; even if two devices have identical sensors, each device would need its own corresponding Parameter.
An automaticParameter is associated with a sensor, and the test will automatically receive data from the sensor.
There can only be one Parameter per sensor of a device. For example, a temperature sensor cannot be associated with two or more different Parameters simultaneously.
It is associated with a sensor using a unique identifier consistent across all devices. All devices are hard-coded to understand these identifiers as mapping to their corresponding sensors. We can do this because we assume the same 4 sensors types are present on all devices. Most likely going to be some integer identifier that is abstracted by an enum.
A semi-automaticParameter is similar to an automatic one, except that it requires user intervention before the sensor can be used (e.g. submerging a sensor).
A manualParameter expects data to be input by the user.
For simplicity, the user input must also be a float/int, especially if we store manual data in DynamoDB too.
For the user's convenience, when a Device is registered, a Parameter should automatically be created for each of the four sensors. It should use a predefined name, description, and unit name. The user should be able to change all of these later if they wish.
Test
A Test is a regularly scheduled event from collecting data from one or more sensors on a device.
A Test is associated with one and only one Device.
UNSURE: It is associated with one or more Parameters.
Supporting this means the DynamoDB schema needs a composite primary key. Not sure if that's a hassle to change now that some code has already been written for writing data to DynamoDB. We could just do one Parameter per Test for simplicity.
A Parameter cannot be simultaneously be associated with different Tests.
See previous comment on a many-to-many relationship.
It stores a name and description.
It stores an initial timestamp and a frequency, which is how often the Test should run relative to the previous run.
For example, a Test starting at 2022-02-24 20:30 with a frequency of 30 minutes would first run at 20:30, then 21:00, and so on.
The initial timestamp may be any time in the future; it doesn't have to be the current time.
TestHistory
A TestHistory is a specific instance of a Test. For example, there would be one TestHistory for the test ran at 20:30 and a separate one for the test ran at 21:00.
It is associated with one and only one Test.
It stores a start time, and end time, and a status.
The status is one of the following:
SCHEDULED: this test is waiting to start running.
CANCELLED: this test was manually cancelled by the user.
RUNNING: data is currently being gathered and uploaded for this test.
SUCCEEDED: the data for the parameters was successfully gathered and saved.
FAILED: the data couldn't be gathered or saved for any reason.
The test runs when the start time reaches the current time. Tests can not run in parallel. If two tests are scheduled at the same time, or close enough that one needs to start before the other has finished, then the later test will run late and wait until the previous test is done. This should be implemented using a queue for tests.
If the associated Test has automatic Parameters, the device is sent the TestHistory ID and the IDs of sensors in the Parameters. If it has manual Parameters, the user is prompted to enter values for them. I think it is better to store these in DynamoDB too for consistency, but these could be stored in PostgreSQL instead. It'd probably require more work though.
If it has semi-automatic Parameters, the user will be sent a notification when the device is ready for them to intervene and do any necessary set up. The test will wait until the user confirms that the device is ready to continue. The test will then be perform just like an atomic Parameter.
A TestHistory is not created until it is time to run the test. If the frontend needs to display tests scheduled in the future, it should dynamically calculate this based on the Tests start time and frequency. This is better since the future is indefinite, and we obviously cannot store an indefinite number of TestHistory objects in the database.
Note: some points mentioned do not reflect the current implementation; things would need to change to accomodate for this proposal.
Device
Sensor Data
floats (orints which have to be converted tofloats).Schema
Devicestores a name and a description.Tests.Parameter
Each sensor is associated with a
Parameter. There can also be manual ones that allow arbitrary user input.Test.Device; even if two devices have identical sensors, each device would need its own correspondingParameter.Parameteris associated with a sensor, and the test will automatically receive data from the sensor.Parameterper sensor of a device. For example, a temperature sensor cannot be associated with two or more differentParameters simultaneously.Parameteris similar to an automatic one, except that it requires user intervention before the sensor can be used (e.g. submerging a sensor).Parameterexpects data to be input by the user.float/int, especially if we store manual data in DynamoDB too.For the user's convenience, when a
Deviceis registered, aParametershould automatically be created for each of the four sensors. It should use a predefined name, description, and unit name. The user should be able to change all of these later if they wish.Test
A
Testis a regularly scheduled event from collecting data from one or more sensors on a device.Testis associated with one and only oneDevice.Parameters.ParameterperTestfor simplicity.Parametercannot be simultaneously be associated with differentTests.Testshould run relative to the previous run.Teststarting at 2022-02-24 20:30 with a frequency of 30 minutes would first run at 20:30, then 21:00, and so on.TestHistory
A
TestHistoryis a specific instance of aTest. For example, there would be oneTestHistoryfor the test ran at 20:30 and a separate one for the test ran at 21:00.Test.SCHEDULED: this test is waiting to start running.CANCELLED: this test was manually cancelled by the user.RUNNING: data is currently being gathered and uploaded for this test.SUCCEEDED: the data for the parameters was successfully gathered and saved.FAILED: the data couldn't be gathered or saved for any reason.The test runs when the start time reaches the current time. Tests can not run in parallel. If two tests are scheduled at the same time, or close enough that one needs to start before the other has finished, then the later test will run late and wait until the previous test is done. This should be implemented using a queue for tests.
If the associated
Testhas automaticParameters, the device is sent theTestHistoryID and the IDs of sensors in theParameters. If it has manualParameters, the user is prompted to enter values for them. I think it is better to store these in DynamoDB too for consistency, but these could be stored in PostgreSQL instead. It'd probably require more work though.If it has semi-automatic
Parameters, the user will be sent a notification when the device is ready for them to intervene and do any necessary set up. The test will wait until the user confirms that the device is ready to continue. The test will then be perform just like an atomicParameter.A
TestHistoryis not created until it is time to run the test. If the frontend needs to display tests scheduled in the future, it should dynamically calculate this based on theTests start time and frequency. This is better since the future is indefinite, and we obviously cannot store an indefinite number ofTestHistoryobjects in the database.