Project Summary -- October 2020

It is a good time to summarize what we have achieved on Farfalle, some of the work that remains, and the areas where the contributors are working.

Remote Sensor Component

The code for the Remote Sensor is essentially complete for Phase 1. There has not been much work in this area recently. Two open issues will need to be resolved:

• [Time keeping] inaccuracies with the Silicon Labs sleep timer driver are still unresolved.
• [Rainfall] values are not scaled properly to match the specified units and resolution.

Data Aggregator Component

Of the three domains defined for the Data Aggregator, two have been modeled, translated, populated, bridged and have test suites (with varying amounts of coverage). Here we have two translations, a micca translation and a rosea translation. The intent is to use the rosea translation as a simulated replacement for Data Aggregator hardware.

There is still quite a bit to do on this component.

• Complete the model of the Data Accessor Upload domain.
• Translate the Data Accessor Upload domain. We will need both micca and rosea translations.
• Build the single domain integration test for upload.
• Build the bridge between Aggregation Management and Data Accessor Upload in both "C" and Tcl.
• Build the bridge between Data Accessor Upload and the cellular modem. Again, we need both "C" and Tcl bridges, although the Tcl bridge will be quite thin.
• Build a target integration application with only the Data Access Upload domain to test the cellular communications between the target and a remote host.
• Build a complete desktop integration application with the micca translation and its corresponding test suite.
• Build a complete integration of the rosea translations as an executable. We should consider adding a minimal Tk interface to this to allow monitoring and controlling aspects of what amounts to a Data Aggregator simulator.
• Build the complete target application and test the entire communications path across Bluetooth and the Internet (as provided by the cellular modem).

Data Accessor Component

We have a model for the Monarch Environment domain. It has been translated using rosea and has a test suite.

Here also we have a considerable amount of work to do. Since the execution environment is a Linux box, there is substantial uncertainty as to how to achieve a translation for this component. To that end a number of experiments are underway to examine various software technologies that might be useful for the implementation.

Paul is both modeling a User Interface and investigating the use of the Elm language to program a web based interface to the system. This effort will yield the understanding as to how to proceed to achieve an implementation.

Glen is building a server to receive the uploaded sample data and place it into a database. Currently, PostgreSQL is considered our best option to handle all the concurrency issues that are likely to arise in a Linux process-oriented execution environment. This test server will be helpful to support the communications testing with the Data Aggregator and by proxy to the Remote Sensor.

Some additional items will also need consideration.

• Revisit and complete, if necessary, the domain chart for the component. Much here will depend upon the requirements we choose to implement in Phase 1, which also needs to be pinned down.
• What role if any will a conventional web server, such as Apache, play in the delivered implementation. At least initially, we need to restrict access to the implementation during development since we will be public facing to the Internet. I don't think we will be able to ignore initially any security concerns.
• We must spin up a node on the "real" Internet and begin the migration of the project to that node. This should include not only the running implementation of the Data Accessor, but also the fossil repository and any other Farfalle specific materials. We own the "farfalle-project.org" domain name and will need to centralize access to that domain.