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

Development of minimal telescope configuration data interface for visibility receive

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

Details

    • Enabler
    • Should have
    • PI11
    • COM SDP SW
    • None
    • Data Processing
    • Hide

      Being able to capture visibility data is one of the core functions expected to be provided by SDP for AA0.5. While previous developments have resulted in a workflow that is approaching what is needed for AA0.5 use, in order to derisk this function further we need to:

      1. Advancing the design, so that data not provided by the data stream from CSP is accessible for writing a valid MS file. (this ticket)
      2. Testing the current visibility receive code against data rates for AA0.5 and common failure modes anticipated to be encountered (SP-1654)
      Show
      Being able to capture visibility data is one of the core functions expected to be provided by SDP for AA0.5. While previous developments have resulted in a workflow that is approaching what is needed for AA0.5 use, in order to derisk this function further we need to: Advancing the design, so that data not provided by the data stream from CSP is accessible for writing a valid MS file. (this ticket) Testing the current visibility receive code against data rates for AA0.5 and common failure modes anticipated to be encountered ( SP-1654 )
    • Hide
      1. Review completeness of the MS written by the current SDP visibility receive workflow and record a list of any missing data.
      2. Develop a minimal interface emulator that provides the visibility receive workflow with data (not already part of the SPEAD CBF stream) needed to write a complete MS. This could be based on the current FakeTM class (https://gitlab.com/ska-telescope/cbf-sdp-emulator/-/blob/master/cbf_sdp/utils.py#L66) but needs to provide a route where data, particularly that which may change for each observation, can eventually be provided by an external interface that is not tightly coupled with receive.
      3. Coordinated with SP-1654, move CBF-SDP Emulator (visibility receive) code into SDP subgroup in GitLab and refactor/rename to meet SKA code naming policy 
      Show
      Review completeness of the MS written by the current SDP visibility receive workflow and record a list of any missing data. Develop a minimal interface emulator that provides the visibility receive workflow with data (not already part of the SPEAD CBF stream) needed to write a complete MS. This could be based on the current FakeTM class  (https://gitlab.com/ska-telescope/cbf-sdp-emulator/-/blob/master/cbf_sdp/utils.py#L66)  but needs to provide a route where data, particularly that which may change for each observation, can eventually be provided by an external interface that is not tightly coupled with receive. Coordinated with SP-1654 , move CBF-SDP Emulator (visibility receive) code into SDP subgroup in GitLab and refactor/rename to meet SKA code naming policy 
    • 2
    • 2
    • 26.5
    • Team_YANDA
    • Sprint 4
    • Hide

      Useful progress on what is needed next has been made but a solution is blocked by further design work as described in the comments.

      Show
      Useful progress on what is needed next has been made but a solution is blocked by further design work as described in the comments.
    • 11.6
    • Stories Completed, Outcomes Reviewed, Accepted by FO

    • PI24 - UNCOVERED

    Attachments

      Issue Links

        relates to

        Architectural Decision - Software Architectural Decision ADR-30 Telescope configuration / model / test data repositories AA0.5

        • decided

        Enabler - An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. SP-1546 Design and implement telescope model for visibility receive

        • 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-1654 Testing of the visibility receive workflow for AA0.5 use

        • 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-1706 Correlator Output Packets

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

        Structure

          Activity

            People

              b.mort Mort, Ben
              f.graser Graser, Ferdl
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Feature Progress

                Story Point Burn-up: (100.00%)

                Feature Estimate: 2.0

                IssuesStory Points
                To Do00.0
                In Progress   00.0
                Complete36.0
                Total36.0

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Structure Helper Panel