[INSTRM-309] Define STS datum structure. Created: 23/Mar/18 Updated: 23/Mar/18 Resolved: 23/Mar/18 |
|
| Status: | Open |
| Project: | Instrument control development |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | cloomis | Assignee: | Hiroshige Yoshida (DISABLED, Use LDAP account) (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
This ticket is to declare a provisional standard, and to open discussion for modifications. The most common STS data types are the obvious INT, FLOAT and TEXT. But there are also INT+TEXT and FLOAT+TEXT types, and STS alarms can be triggered based on either the numeric or the text values. The alertsActor will contain the PFS alarm logic and will generate the alarms (and not STS). I had intended to do that with STS TEXT fields (a.k.a. "datum"s), using "OK" as the non-alarm state. But with the numeric+TEXT types, I think we should make all numeric STS fields numeric+TEXT. The alertsActor will keep a table of active alarms, and the STS forwarding module would either send "OK" or some short informative text if an alarm for that keyword[index] is active. The STS alarm logic could then simply be text != "OK" for all. There will also be synthetic TEXT-only alarms from the alertsActor. The same alarm logic would apply on the STS side. One mildly annoying point I need to be careful about is that each MHS keyword can have multiple fields, but STS fields only contain one number. So the alertsActor needs to be careful about setting alarm state on individual keyword fields. Hiroshige Yoshida (DISABLED, Use LDAP account) knows the most about the STS. At first glance we believe this would simplify the transfer of alarm state to the STS. |