Requirements for the Visitor and Staff GUIs

[TerryJC]

Later today I will be posting the first draft of the Requirements Document for the Visitor and Staff GUIs. However, before I can do that, I need the answer to a question.

The purpose of the two GUIs is present the status of the River System elements in a graphical form. Regardless of how this is done, it will be necessary to convey the information from the Master Pi to the GUI Pi in a reliable manner (and vice-versa in the case of the Staff GUI).

This information will typically be:

• For the Visitor GUI:
  • Readings of Sensors.
  • State of Valves.
  • State of Pumps, etc
• and for the Staff GUI.
  • All of the above, plus;
  • Control signals to start and stop the system and pumps and valves, etc

The question is; how best should we do this?

My first thought is that the Master Pi should host a database (MySQL or similar) which contains a record for each of the above conditions. The Master Pi would maintain this and the GUI Pi would read each record in turn before displaying the relevant reading or state on the display. In the case of the controls, the software on the GUI Pi would have permission to write to the database and the Master Pi would then carry out the action required.

Does anyone have any thoughts on this? Whatever we do it will need to be fully defined in the requirements, so the students who take this on will be able to read from and write to a 'black box' and won't need to know any low-level stuff like sockets or remote direct memory access.

[Penri]

Terry

I think the architecture proposal is sound and hosting the parameters which dictate or show the status of the dynamic status of system as a database in the Master Pi is right. I'm not familiar with MySQL but using a SQL database to me makes sense.

For increased visitor interest and interaction I would like to see the GUI being able to play back the river status, graphically for the visitors, over a choosen period of time, in accelerated time, ie play back to show how the river system levels and flows changed over a week in a minute or so, perhaps with some actual or customised "interesting" scenarios (dealing with summer cloud burst when the system is almost empty). Would this need a second database, perhaps hosted in the GUI Pi, for longer term status logging?

If we wanted to integrate some other parameter later: rainfall, temperature of air / water, wind direction / strength, .... could that be accommodated by the architecture?

Hwyl

Penri

[TerryJC]

Penri,

Thanks for your feedback.

As far as the database is concerned, it shouldn't be a problem to store the necessary parameters because that would simply involve copying a complete set of records into a another 'mirror' part of the database, for later playback.

However, implementing the playback feature might be a little difficult in the timescales available to the students, so I propose to make it a stretch target.

[Penri]

Terry

No issues with making it a stretch target.


Penri

[TerryJC]

Attached to this posting is the first draft of the Statement of Requirements. Please review and comment so that we may get this out to the school before Christmas.

[Penri]

Good morning all

I've made a small number of amendments and added some comments and questions; some of these outside the scope of this particular project but occurred to me as I was reading the document. I was wondering if some of these could be bundled up as additional work packages, perhaps for QE pupils?

I have a Pi 3 with keyboard and mouse sitting on my desk that can be used as a development tool.


Penri

[TerryJC]

Penri,

Thanks for your comments. I'll work through the changes and come back V03 in due course.

To answer your questions:

[Penri question: should there be a section here on the GUI Pi and any interface hardware, e.g.
GUI Pi is a xxx
Main visitor screen is a xx” HD display
Main visitor keyboard 4 buttons, functionality defined by the GUI Pi
I know we may not know all of this now but I think the designer needs some steer to what the deployed interface will look like.]

I'll add a section on the GUI Pi and some tentative ideas about the interface. I must admit, my original thoughts were that this display would not be interactive as far as the Visitors are concerned and the Staff would simply have a mouse and keyboard (or a keyboard with a touch pad).

If we want to have an interactive system, then that is a bit more difficult. Maybe another stretch target? If we do, then I think we should perhaps think about the value of using a touch screen?

I'm very conscious that in just over six months time these guys will be moving on to the Upper 6th and may not have the time to do everything we would like. However, it could be a project that has the right hooks and is then passed on to subsequent students or picked up by ourselves eventually.

[ Penri question: would be want to see depth the probes represented or just the level of water in the sump and butts?]

I'm not sure that I understand the question. What is the difference between the two values.

[Penri question: should we have a help / more information facility to explain the why’s and how’s of the river system? I’m also probably thinking beyond the scope of this work package to a kiosk style slide show that would run continually giving WMT / river information until interrupted by a key press / touch on screen]

Again, this could be a stretch target.

[Penri comment: this would be best if it allowed the visitor to select the senario]

This would depend on whether we have the interactive system.

[Penri]

Terry

It was reading the document that set the thoughts running in my head and it seemed better to share them than not, but it doesn't make them right either! It is be something that I'd like an input from a broader audience, Greg and the trustees, but that has not been easy to elicit so far. I agree we do need to bound the work into manageable chunks but to do so without precluding extensibility in the future.

I've added a diagram to show what I meant by the second question you picked up. I was trying to explain in my words that every sensor did not need to be shown (i.e. the probe) if a symbol could readily convey the status (animated blue level in a container).

On the third question, I'm ok with it as a stretch target but we could leave it out and make it a future work package.

... and I agree with you comment on the final point I raised.


BTW I recall you saying, some time ago, that Greg had mentioned an externally mounted touch screen display to you, we should re-visit that with him.


Hwyl

Penri

[TerryJC]

Penri,

Thanks for the feedback and I agree that this should be discussed with Greg et al, before we submit it to the school.

Regarding your response about levels, I think that it's the level that matters not the probe and so we should probably use your right-hand approach. However, I think that the display should indicate which probe level is being displayed so that faults can be identified quickly.

Which makes me think that we should have some way of marking dubious values and flagging them up on the screen (on the Staff GUI at least).

[TerryJC]

BTW I recall you saying, some time ago, that Greg had mentioned an externally mounted touch screen display to you, we should re-visit that with him.

Penri,

I've been thinking about this overnight and also done a bit of research.

The topic came up one day when I asked Greg where he thought we should put the Monitor for the Visitor GUI and he said that he would quite like it to be outside near the entrance and just in front of the Bog Garden. At the time I said that a reasonably sized IP65/67 rated monitor would cost in the region of £1000 and we would then have to somehow protect the Pi and also get power to it. At the time, we also talked about using a rugged tablet because that wouldn't need the Pi to be local (but it would still need power to recharge it's battery).

Putting the tablet aside for the moment, I've looked again at rugged monitors and if anything they are a bit more expensive now (pesky Brexit affecting the pound I expect.) Even so, it would be doable if we brought the power in via PoE, because many IP rated monitors can be run off a wide DC voltage range. That would mean that we would need a fairly small IP65 equipment case to house the Pi and the DC-DC converter and a plinth to put the monitor on (the case could be hidden underneath the plinth).

Alternatively, if mains power was available somewhere near the entrance then we could utilise that and use WiFi to pick up the data. We'd still need an IP65 equipment case for the Pi though and I personally would be happier if mains was nowhere near anything that could be touched by the public.

Going back to the tablet idea; that would have its own power and WiFi built in, so we would simply have to make sure that it was adequately protected from someone slipping it into their bag. However, it would have to have a source of power nearby for recharging and although Android tablets are pretty cheap, they are also quite small, so we could end up running out of real-estate on the screen.

All this is definitely worth a revisit with the WMT staff.

Of course, once we have this resource it would become much more that a River System display and could be used for a variety if things.