Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-3414

Develop MCCS dashboards

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • LOW ART
    • Hide

      We need a monitoring UI for the MCCS:

      • for public demos (to other teams, to managers, to external people)
      • to better support the needs of MCCS developers and engineers when they are debugging it
      • to support AIV engineers when testing the MCCS.

      We will end up with a system of Taranta dashboards that can be used as a means to obtain additional feedback as we go on with development, testing, and using our software and hardware.

      Show
      We need a monitoring UI for the MCCS: for public demos (to other teams, to managers, to external people) to better support the needs of MCCS developers and engineers when they are debugging it to support AIV engineers when testing the MCCS. We will end up with a system of Taranta dashboards that can be used as a means to obtain additional feedback as we go on with development, testing, and using our software and hardware.
    • Hide

      The scope should be fairly limited to ensure success of this initiative.  Therefore:

      • the dashboards should cover health-status related items
      • and/or temperatures 
      • and/or voltages.

      Only failures and drill-down/wrap-ups related with the above data will be supported.

      A persistent Taranta instance will be made available at the LOW ITF such that:

      • it contains dashboards and user accounts that can run these dashboards; data about users and dashboards persist across updates of Taranta code;
      • the dashboards will present  the above-mentioned information;
      • a user can navigate through these dashboards to drill-down and wrap-up as needed by the task at hand.
      • control of the MCCS is out of scope, and expected to be performed through other means (like CLI tools).
        • However control also through Taranta dashboards is allowed and welcome.

      NOTE "Persistent Taranta instance" is something that CREAM and SYSTEM teams are expected to provide. (I spoke already with U.Yilmaz on this)

      Show
      The scope should be fairly limited to ensure success of this initiative.  Therefore: the dashboards should cover health-status related items and/or temperatures  and/or voltages. Only failures and drill-down/wrap-ups related with the above data will be supported. A persistent Taranta instance will be made available at the LOW ITF such that: it contains dashboards and user accounts that can run these dashboards; data about users and dashboards persist across updates of Taranta code; the dashboards will present  the above-mentioned information; a user can navigate through these dashboards to drill-down and wrap-up as needed by the task at hand. control of the MCCS is out of scope, and expected to be performed through other means (like CLI tools). However control also through Taranta dashboards is allowed and welcome. NOTE "Persistent Taranta instance" is something that CREAM and SYSTEM teams are expected to provide. (I spoke already with  U.Yilmaz  on this)
    • 2
    • 0
    • 23.5
    • PI24 - UNCOVERED

    • Taranta Team_MCCS mccs_ui

    Description

      Following work from PI17 on the MCCS "thin control slice" (SP-3028, MCCS-1232, MCCS-1224), develop a set of inter-related dashboards for the MCCS (in the context of Solution Goal 2  | https://confluence.skatelescope.org/display/SE/Test+AAVS3+release+of+MCCS+at+the+LOW+ITF ]) on LOW ITF.

      In particular, those dashboards should be used:

      • by developers of the MCCS to monitor its behaviour and expose its relevant internal state (including value of relevant attributes), and to support identification of failures and to support diagnosis;
      • by AIV engineers to carry out testing of the MCCS;
      • by managers and others when doing public demos;
      • by operators who provide feedback about usefulness and effectiveness of such dashboards.

      A necessary outcome of this work should be that after PI19 people actually use these dashboards, and evolve them as the needs change.

      NOTE: one possible approach to follow is what n.rees calls "maximum severity". Another is to adopt an approach similar to what you do in FMECA (Failure Mode, Effects, and Criticality Analysis: https://www.weibull.com/basics/fmea.htm): we are not aiming at estimating likelihood of failures, but just understand how failures of parts contribute to failures of super-parts (m.miccolis  to be credited for this suggestion).

       

      NOTE: this is a modified version of a feature SP-3213 that was not worked on in the past that assumed that a Lean UX process was established. For this feature we are not requiring a lean UX process (though it will welcome).

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                g.brajnik Brajnik, Giorgio
                g.brajnik Brajnik, Giorgio
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (0%)

                  Feature Estimate: 2.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete00.0
                  Total00.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel