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

Telescope model (instrument configuration) service improvements

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

Details

    • Feature
    • Must have
    • PI14
    • COM SDP SW
    • None
    • Data Processing
    • Hide

      See description (who & why sections)

      Show
      See description (who & why sections)
    • Hide
      1. Review scope, use cases and solution architecture.
      2. Timeboxed activity to evolve or pivot current solution for serving data (working with MCCS on the server & client APIs).
      3. Collect data files to be served in one place (work with MCCS).
      4. Write clear documentation for how to add and access new data items through the library from the perspective of SKA developers (specifically cross-ART)
      5. BDD style test(s), exposed to Xray, for this service one from SDP and one from MCCS usage sides), eg.
        • Given an SDP visibility receive workflow is running
        • When the workflow requests a specified version of station/dish coordinates from the Telescope Model service
        • Then these are available to the workflow for subsequent processing
      Show
      Review scope, use cases and solution architecture. Timeboxed activity to evolve or pivot current solution for serving data (working with MCCS on the server & client APIs). Collect data files to be served in one place (work with MCCS). Write clear documentation for how to add and access new data items through the library from the perspective of SKA developers (specifically cross-ART) BDD style test(s), exposed to Xray, for this service one from SDP and one from MCCS usage sides), eg. Given an SDP visibility receive workflow is running When the workflow requests a specified version of station/dish coordinates from the Telescope Model service Then these are available to the workflow for subsequent processing
    • Inter Program, Intra Program
    • 4
    • 4
    • 8
    • 2
    • Team_YANDA
    • Sprint 5
    • Hide

      AC1: motivated by the arch sync discussion and ADR-30, MCCS was confirmed to provide antenna position data to serve as initial use case
      AC2: collaboration on configuration scheme with MCCS, SDR-624
      AC3: backing store git repo with MCCS data (*.geojson) and its description
      AC4: usage of storage backend
      AC5: BDD test (MR65) using the MCCS supplied antenna positons

      Show
      AC1 : motivated by the arch sync discussion and ADR-30 , MCCS was confirmed to provide antenna position data to serve as initial use case AC2 : collaboration on configuration scheme with MCCS, SDR-624 AC3 : backing store git repo with MCCS data (*.geojson) and its description AC4 : usage of storage backend AC5 : BDD test ( MR65 ) using the MCCS supplied antenna positons
    • 17.5
    • Stories Completed, Integrated, Outcomes Reviewed, NFRS met, Satisfies Acceptance Criteria, Accepted by FO

    • PI24 - UNCOVERED

    • SPO-1591

    Description

      Who? 

      For developers of systems needing a single source of truth for telescope model/instrument configuration data.
      Keep scope limited to start with to SDP and MCCS use cases - will evolve or pivot in future if successful 

      What?

      A solution that provides a single source of truth for telescope model/instrument configuration data, limited in scope to a few (TBD, see list below) data models needed for SDP and MCCS for AA0.5.

      Needs to consider use cases and data models with a limited scope starting with SDP and MCCS possibly including:

      • Static and limited dynamic data 
      • Data versioning (with timestamps on versions?)
      • Data models (and formats)
        • Station coordinates
        • Aperture array coordinates
        • Aperture array connection map/list (probably not the right term - check with
          m.waterson
          )
        • Haslam map (list of HEALPix pixels)
        • RFI Masks
        • (Embedded element beam pattern coefficients?)
      • ...?  (needs to be worked out in PI14 but not expected to be a complete list - just need to find out what we need in the short term based on needs of SDP and MCCS in the first instance)

      Review and evolution of current solution https://gitlab.com/ska-telescope/sdp/ska-sdp-tmlite-repository with consideration for data backend, service interface, and client library (can probably just persist current solution )

      A client library that provides a solution to make it easier for application developers to exercise this interface

      Simple data backend which supports the data models and data versioning 

      Simple service interface that abstracts how data is stored and hides it from the client

      Why?

      Single source of truth for configuration data that needs to be shared across the telescope, if we don't have this we'll have a massive headache trying to make sure data such as antenna coordinates are shared between sub-systems.

      Needs to be able to support versioning so we can reason about what configuration was used for any given observation/test.

       

      Other notes

      Attachments

        Issue Links

          Child Of

          Enabler - An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. SS-77 Software Deployment configuration in AA0.5 and ITF

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done

          Enabler - An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. SS-90 Reintegrate missing components into SKAMPI

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done
          is cloned by

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2148 Further development of the Telescope Model configuration data service (and client library)

          • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
          • Discarded
          is required by

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2466 CBF-SDP emulator sends correlator data dumps

          • Won't have (this time) - Items labelled as "Won't have", have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, "Won't have" items are not planned into the schedule for the next delivery timebox.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2363 Visibility Receive workflow enhancements

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done
          relates to

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-1720 Configuration Scheme (locations, setpoints, etc)

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-2487 CLONE - LOW Telescope Configuration Scheme (locations, setpoints, etc)

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done
          mentioned in

          Page Loading...

          Page Loading...

          Structure

            Activity

              People

                b.mort Mort, Ben
                b.mort Mort, Ben
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 4.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete710.0
                  Total710.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel