Issue 8908: inability to describe sets of limits (alarms) and conversions (polynomials) (xtce-rtf)
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity: 
Summary: inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase  (JWST)
 
JWST hold conversion and limits in a seperate file that are grouped.  Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate.  XTCE allows one to specify at MOST one of each of these per parameterType

Resolution: 
Revised Text: 
Actions taken:
June 21, 2005: received issue
Discussion: 
Resolution:
There are really two separate issues here: 1) the need different alarms and calibrations in different phases and 2) the desire to use alarm or calibrator sets and refer to these sets in each parameter - to reduce redundancy.  Each of these sub-issues is addressed below:

1.	Alarms and Phases.  This is simply a nomenclature issue; what is called a mission phase here (and in many Boeing missions) is in XTCE called a '.Context'.  XTCE has a very robust capability to describe different alarms or calibrations in different Contexts.  Close, no change.
2.	Calibration and Alarm Sets.  Calibration and Alarm Sets are used in many ground systems that employ a relational data model.  In actual space systems, calibrations and alarm sets are shared by Parameters when the Parameters of the same 'type'.  For example, all voltage Parameters on a Space System will all have the same calibrations when the same voltage transducer is used throughout the space system - as is usually the case.  Because XTCE parameters are all declared from ParameterTypes, it is very easy to define a single 'VoltageType' with the calibration in the VoltageType and instantiate many Voltage Parameters from the Voltage 'Type'.  Using this declaration technique XTCE offers a very natural means to declare Calibration and Alarm sets once.  

This seems to be a recurring issue and will be addressed in a future ESA Schema change submission.

Ultimate this is an issue of compactness and modularity.  If typical parameter types can be set to one of several calibrations during the lifetime of a mission for example, one would be forced to create a new parameter-type for each one - that is if that calibrator is likely to change a fairly regular basis ( meaning that simply deleting the old information and updating isn't a good solution).  This has the tendency then to explode the type area.  In addition, the sets are a convenient place to group all the Alarms and Calibrators in use by the system.   

End of Annotations:=====
s is issue # 8908

inability to describe sets of limits (alarms) and conversions (polynomials)

inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase  (JWST)
 
JWST hold conversion and limits in a seperate file that are grouped.  Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate.  XTCE allows one to specify at MOST one of each of these per parameterType