Engineering View Usecase - DEPRECATED

DEPRECATED, instead see the engineering-view-plans page

----

Engineering View Usecase - McLaughlin Nutnet

This is a rough first draft of a usecase that fulfills the deliverables described in slide 6 of Matt's REAP overview Keynote presentation. 

D1 - Web-service API ...
---
?

D2 Inspection and D3 Monitoring
---

Check for, and use a relevant Ptolemy domain within Kepler so that a user may graphically view and edit their site (e.g. a group of deployed sensors). Such "workflows" could show sensors, dataloggers, computers, and telemetry using components and relations. Additionally we might allow for basic geographic features. "Running the workflow" could mean displaying in real-time useful data associated with a component or relation. For example a sensor-actor might change color by health, and display its most recent data-value near the actor. Health could be stored in a DataTurbine channel associated with each sensor, which contains the result of analyses, potentially specific to the type of sensor. These analyses might execute and populate health channels in separate workflows. Links denoting telemetry could visually change in a similar way. It should be easy to create and watch a more complex plot for (a) component(s) -- output ports of sensor actors could be available, outputting their datapoints, thus adding plots could be easy for the user. Right clicking on a component could allow a user to navigate to more detailed information for that component.

Relevant OGC xml file(s) could be used for the description of site components, and a site could have an associated Kepler workflow (graphical representation of site). These files could be stored in (a) Dataturbine channel(s). If one physically adds or alters a sensor at the site, new updated OGC doc(s) and moml would need to be inserted into the Dataturbine channel(s). This could be automated to some extent by checking for the appearance of new data channels in a DataTurbine Source and then generating and inserting the updated OGC doc(s) and Kepler workflow file into the appropriate channel(s). A user would likely have to flesh out whatever is generated, i.e. additional metadata in the OGC doc, and better layout generated graphical items in the workflow.


D4 - Control API
---
Given the Kepler interface described above, a user would like to alter their site. We'll likely want to add safeguards for these more dangerous activities.

Change physical layout of their site, e.g. move a sensor.
    - edit OGC docs, and manipulate the graph
Stop sampling a sensor.
    * in Kepler - use a context menu ON/OFF. Graphically, a red X on icon when it's off.
    - requires editing CRBasic program, uploading new program to deployed datalogger, and ensuring it compiles and begins.
Change sampling rate of a sensor.
    * in Kepler - change this from within a context menu on the sensor, or from within context menu of datalogger.
    - requires editing CRBasic program, uploading new program to deployed datalogger, and ensuring it compiles and begins.
Remove a sensor.
    * in Kepler - delete the sensor-actor.
    - requires editing CRBasic program, uploading new program to deployed datalogger, and ensuring it compiles and begins
Add a sensor
    * in Kepler, create a new sensor-actor and connect it in graph
    - requires editing CRBasic program, uploading new program to deployed datalogger, and ensuring it compiles and begins.

Note:
- We could store commands issued and possibly programs used, in a Dataturbine channel for later reference, but Dataturbine group does not recommend using Dataturbine as actual carrier for commands.

- Loggernet's CRBasic editor is very handy. The language and perhaps-common nature of people infrequently writing CRBasic programs, and of limited scope for their particular hardware, are such that I don't think many people will be able/willing to write CRBasic without this Editor. We could have a menu for selecting common high level function like "increase sampling rate" and then auto-change the CRBasic for the user, but this would be hardcoding to a specific version of CRBasic, and of limited scope.


D5 - implement for terr eco usecase in Kepler utilizing Dataturbine