Feedback-ID: i76984098:Fastmail
Message-ID: <ea77fa23-6361-42f0-a511-8e0997dada26@aklaver.com>
Date: Thu, 30 Jan 2025 08:45:52 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Ideas about presenting data coming from sensors
To: Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>,
 "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
References: <8d2dd92a-da16-435b-a38e-fe72191fc9d1@cloud.gatewaynet.com>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <8d2dd92a-da16-435b-a38e-fe72191fc9d1@cloud.gatewaynet.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/ea77fa23-6361-42f0-a511-8e0997dada26%40aklaver.com>
Precedence: bulk

On 1/30/25 06:18, Achilleas Mantzios - cloud wrote:
> Dear PostgreSQL people
> 
> We have a project having to do with capturing sensor data and alarms 
> from various machinery using various protocols/standards (e.g. NMEA , 
> MODBUS). We have about 150 sites (vessels of various types) and each 
> site will generate about 500 rows per minute. We have solved most of the 
> design + issues regarding DB, data transfer to the central DB, etc and 
> now we have started to think about presenting them.
> 
> Ideally and eventually each one of those will be connected to some 
> machinery item defined in our inventory / live system, so the final goal 
> is to have smth like "mimics" and interactive UI that will let the user 
> have an overall view of  the fleet (all vessels), spot the red/orange 
> ones, then click on a vessel, spot the red/orange areas, then keep on 
> zooming in until he/she finds the exact item that is in trouble.
> 
> This is the rough idea.
> 
> But for now we are more interested in just viewing the incoming data 
> that will be basically tag/value pairs.
> 
> The types of those data will be divided in normal tag with a normal 
> float value, or alarm data which have about 2 discrete boolean variables 
> (valid and acknowledged). So we want to cover those two cases as far as 
> viewing is concerned.
> 
> The data will have minutely resolution. So if a vessel e.g. has 700 
> discrete tags then the system will generate and transfer to the central 
> DB 700 rows for every minute.
> 
> Any ideas? Graphs time series? We have graphs (Java) that show time 
> series with daily resolution. What would you guys recommend for showing 
> such data, coming from data acquisition systems ?

It seems there are two uses in play here:

1) Minute by minute data acquisition to track sensor and alarm output in 
general.

2) Troubleshooting emerging problems.

For 2) you seem to already have the idea of drilling down on values that 
have moved into the orange --> red area. That does not require 
displaying all the data, just the data that enters the zone of interest.


For 1) the question is do you think folks are going to look at 700 
values recorded on a minute by minute basis on 150 ships? Where that 
information could help is supplying context for the problems arising in 
2), especially  intermittent issues. I could see picking a problem 
defined in 2) and allowing for the user to select both a time period and 
related values over that period to help determine how the problem
developed.


> 
> Thank you!
> 
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com