[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.


Generated at Sat Feb 10 16:23:40 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.