Details

    • Story Points:
      2
    • Sprint:
      SM1-2019 K, SM1-2019 L, SM1-2019 M

      Description

      As discussed in last ICS/DRP+SpS telecon 2019-07-10, instead of the full alertsActor implementation of INSTRM-451, implement a simplified solution where the actor reads a YAML file with threshold and apply those thresholds to generate STS keywords.

        Attachments

          Issue Links

            Activity

            Hide
            cloomis cloomis added a comment -

            Specifically, there is a template config file for alerts in config/keywordAlerts.py, and I suggest that we implement only the limitsAlert part. E.g.

              meb:                          # MCS E-Box
                flow:
                  <<: *LIMITS_ALERT
                  limits: [0.0, null]
                  alertFmt: 'coolant flow has stopped'
                temps[0]:
                  <<: *LIMITS_ALERT
                  limits: [10.0, 25.0]
                  alertFmt: 'temperature out of range'
            
              xcu_{cam}:                    # All XCUs
                pcmPower[bus1]:
                  <<: *LIMITS_ALERT
                  limits: [23.5, null]
                  alertFmt: 'Input power is failing!!: {value}V'
                pcmPower[bus2]:
                  <<: *LIMITS_ALERT
                  limits: [23.5, null]
                  alertFmt: 'Input power is failing!!: {value}V'
            
            Show
            cloomis cloomis added a comment - Specifically, there is a template config file for alerts in config/keywordAlerts.py , and I suggest that we implement only the limitsAlert part. E.g. meb: # MCS E-Box flow: <<: *LIMITS_ALERT limits: [0.0, null] alertFmt: 'coolant flow has stopped' temps[0]: <<: *LIMITS_ALERT limits: [10.0, 25.0] alertFmt: 'temperature out of range' xcu_{cam}: # All XCUs pcmPower[bus1]: <<: *LIMITS_ALERT limits: [23.5, null] alertFmt: 'Input power is failing!!: {value}V' pcmPower[bus2]: <<: *LIMITS_ALERT limits: [23.5, null] alertFmt: 'Input power is failing!!: {value}V'
            Hide
            cloomis cloomis added a comment -

            And I'll point out INSTRM-311. I believe that this is the sane thing to do:

            • make all STS types STRING+INTEGER or STRING+FLOAT.
            • make that STRING "OK" or something useful to a human
            • STS logic only looks at the OK/other (and a couple of timeouts)
            Show
            cloomis cloomis added a comment - And I'll point out INSTRM-311 . I believe that this is the sane thing to do: make all STS types STRING+INTEGER or STRING+FLOAT. make that STRING "OK" or something useful to a human STS logic only looks at the OK/other (and a couple of timeouts)
            Hide
            hassan hassan added a comment -

            cloomis: Is your proposal above for the alertFmt in config/keywordAlerts.yaml ? And then regarding the STS logic, would that be a configuration for the 'real' STS server?

            Show
            hassan hassan added a comment - cloomis : Is your proposal above for the alertFmt in config/keywordAlerts.yaml ? And then regarding the STS logic, would that be a configuration for the 'real' STS server?
            Hide
            cloomis cloomis added a comment - - edited

            Yes. Exactly the same logic for both the fake and the real STS server. I don't think the alertsActor can tell the difference.

            Note that the actor is currently using the simpler STS.yaml, where the magic integers are the assigned STS IDs. I think we should merge STS.yaml and the more expressive keywordAlerts.yaml Obviously for "STRING+FLOAT" above I should have written "FLOAT+TEXT".

            The existing Controllers/actorRules.py wires the STS.yaml keywords to automatically forward to the STS server when they get updated. It actually already checks whether there is an entry in .actor.activeAlerts and forwards that instead of "OK". We need to also wire in any limit, etc. checks, which just need to set the entry in actor.activeAlerts.

            Note also that we probably do not need to debounce or latch errors, since the STS server does that for us. That is a pretty significant simplification. I.e. if a key field goes back within its limits, we can simply set it back to "OK" – the STS server will deal with the latching and give the human a way to clean and rearm. Very nice.

            Show
            cloomis cloomis added a comment - - edited Yes. Exactly the same logic for both the fake and the real STS server. I don't think the alertsActor can tell the difference. Note that the actor is currently using the simpler STS.yaml , where the magic integers are the assigned STS IDs. I think we should merge STS.yaml and the more expressive keywordAlerts.yaml Obviously for "STRING+FLOAT" above I should have written "FLOAT+TEXT". The existing Controllers/actorRules.py wires the STS.yaml keywords to automatically forward to the STS server when they get updated. It actually already checks whether there is an entry in .actor.activeAlerts and forwards that instead of "OK". We need to also wire in any limit, etc. checks, which just need to set the entry in actor.activeAlerts . Note also that we probably do not need to debounce or latch errors, since the STS server does that for us. That is a pretty significant simplification. I.e. if a key field goes back within its limits, we can simply set it back to "OK" – the STS server will deal with the latching and give the human a way to clean and rearm. Very nice.
            Hide
            hassan hassan added a comment -

            Alerts should be generated on the main pressures, temperatures and voltages.

            Show
            hassan hassan added a comment - Alerts should be generated on the main pressures, temperatures and voltages.

              People

              • Assignee:
                arnaud.lefur arnaud.lefur
                Reporter:
                hassan hassan
                Reviewers:
                cloomis
              • Votes:
                0 Vote for this issue
                Watchers:
                Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: