[Business] Parameter meta data

[Lauri Kimmel]

From javadoc https://github.com/Villemos/hbird-business/blob/master/exchange/core/src/main/java/org/hbird/exchange/core/Parameter.java

/**

 * A parameter. The parameter type is at the core of the information model. It 

 * is used to describe a name-value pair, attaching the meta-data for description 

 * and unit.

 * 

 * There is no predefined set of parameters in the form of a database. Creating

 * a new parameter is simply the creation of a Parameter with a new name.   

 *

 */

AFAIK the Parameter object should contain all related information needed in the system to avoid extra lookups from DB-s. This in mind I think current fields – name, timestamp, unit, value, issuedBy, datasetidentifier and description are not holding sufficient information for the system. Few examples:

• For organizing Parameters in UI elements some kind of grouping should be possible. For example in tree widget or similar. Current "issuedBy" filed gives some level of grouping but it’s very limited. From ESTCube project we have one WeatherStation component which is responsible for collecting data from different sources. Some of the parameters are available more than one source. So we have one parameters WeatherStation.meteo.temperature and other WeatherStation.ilm-ee.temperature. How to display them in tree widget? One solution would be to use naming convention - each dot (or slash etc.) in parameter name represents level in hierarchy like file paths or package names in java. Other one is to include extra meta data in Parameter object.
  
• Parameter names from above example are not user friendly. They are long, hard to read, understand and remember. So in my opinion short or display name is needed for parameter.
  
• Command arguments are defined as Parameters. To build dynamic form in UI for Command and its Parameters some additional information is need. For example 
  

• data type – numeric, string, boolean, date etc. to choose input widget
• some validation criterions – min/max value, regex, is null allowed etc. to validate user input 
• default value to initialize widget
• etc.

Maybe I’m looking this from wrong direction and there is simple answer for all this. Otherwise I’d like to extend Parameter object and possible others like Command as well. I’d like to know what you think about "extra meta data" and how to solve it.

[Lauri Kimmel]

One more issue. SCOS and also ESTCube have two values for the same parameter at same time - raw value & engineering value. Raw value is low level sensor readout. Engineering value is something system components & humans can interpret. Engineering value is calculated from raw value using calibration. It can be simple function for boolean parameters [1, 0] -> [true, false] or quite complex for more sophisticated data types. How does this concept fit into Humingbird?

[Villemos]

Hummingbird has a script engine for calculation of engineering values. Its still in Beta.

 

Hummingbird sees the two values as two different parameters. They are related, but destinct. This simplifies a lot of things.

 

Also, there may be multiple engineering values based on the same raw parameter. Each will be a separate parameter.

 

I hope this answers your question.