The ODS system is modeled in Cameo based on the requirements and ConOps provided here. The model currently consists of a context diagram and a use case diagram.

Context Diagram

The system context models the OSS system as a 'black box' and depicts the information flows into and out of the system.


Use Case Diagram

Use Cases are a means of specifying the required usages of a system. The use case diagram (click to enlarge) below models the ODS usages.

Note: "include" means the use case is always executed and "extend" means the use case is only executed when the extension point criteria are met.


Requirements

The Requirements Diagram models the existing requirements (click to enlarge).

Architecturally Significant Requirements

  • The system must be able to support the Green Bank Radar Transmitter, ngVLA Core, ALMA, VLBA in the future.
  • Quasi-realtime performance: "Update latency should be of order seconds." and "Expected use cases will seek to update information on 15 second cadence."
    • Assume latency means: "the delay before a transfer of data begins following an instruction for its transfer."

High-level Design

Data Model

Satisfies Matrix

Questions

  1. From presentation: "If telescope is observing in a downlink band then satellites serving cells within XX km of the telescope enter a special mode." Are the telescope/antennae locations supposed to be part of the station information response or would the satellite network know the locations another way?

  2. Are queries station-specific or are they for all stations?
  3. We assume the Historical interface is already implemented by the "Data Collection for Foreign Observing on AUI-managed Instruments" Project (AD2). Is that correct?

  4. Regarding "The driver for the update is that NRAO and GBO are testing new methods to coordinate observations with potential interfering signals from satellite transmissions.", was the converse communication strategy considered? That is, the satellite network sends information to the NRAO system and the NRAO system determines what mode the satellite should be in and sends the associated simple response.

  • No labels

12 Comments

  1. Chris De Pree

    1. I think that the telescope locations should be part of the station information for completeness.
    2. I assumer here you mean (e.g.) elements of an interferometer? We should have some way to account for subarrays for completeness.
    3. This may be a question for Jeff Kern 
    4. I think that we need to proceed this way (eg. satellite networks operate in normal mode unless we are observing in their downlink bands). But happy to discuss.

  2. Mark Whitehead

    2. When a satellite network or satellite operator makes a query, does the system return reports for all the stations at once from a single query or is it required to make a query for each station?

    4. Under the current ConOps, the satellite network requests information from NRAO and then the satellite network decides what mode to put the satellite(s) in. I'm asking if it would be feasible to reverse that: an NRAO system requests information from the satellite network and the NRAO system decides what mode the satellite(s) should be in and transmits that result to the satellite network.

    1. Chris De Pree

      #4 Perhaps. I have a meeting with SpaceX this Wed and can ask then. Just want to make sure that is feasible from their end.

      1. Chris De Pree

        But my guess is that they would not want their network receiving ground commands for mode setting from a non-SpaceX transmitter.

  3. Chris De Pree

    #2 I think that a query for one element of a system (e.g. VLA) should return status of all elements of the system.

  4. Mark Whitehead

    It wouldn't be a command for mode setting, it would just be a request based on their frequency and location information to enter the special mode to avoid interfering with observations.
    Since you're talking to SpaceX this week, it would be nice to know how many simultaneous clients they envision being involved with the machine readable interface. Also, any protocol preferences would be helpful.

  5. Chris De Pree

    For sure - I can ask those questions this week and get back.

  6. Chris De Pree

    Mark Whitehead Sorry I did not get to this yesterday.

    Interaction with SpaceX has been highly focused on a test we are going to run in coordination with Sugar Grove Research Station next Tuesday, so I might not be able to get feedback about the reversal of the request (e.g. we request that they enter a special mode versus they see our status and enter that mode). I assume there are advantages to this approach from our end (e.g. simplicity?)

    My assumption has been that there will be only one client at any given time (from SpaceX), but I will also verify that. That is, their system is making the inquiry, not individual satellites. Their satellites will get marching orders from their network control system, as I understand it.

    Otherwise - these diagrams are very helpful, and please let me know what else you need. I am traveling this weekend, but the next team meeting can include Bang Nhan (RFI Scientist). Jeff Kern 


  7. Mark Whitehead

    Chris De Pree No worries.

    Reversing the request could simplify things on our end, especially with regard to VLBA. Additionally, the requirements currently suggest that the historical interface data would be used for the machine readable interface which doesn't seem right - it would be helpful to clarify what specific data are needed for either side to make a mode decision.

    Thanks for the clarification about the network control system.

    Look forward to the next team meeting.

    1. Chris De Pree

      Sent these requests on to Mike Nichols (their Lead system engineer). Do you think a kickoff meeting with Mike/his team would be helpful?

  8. Daniel Lyons

    I realize this feedback is quite late but I would recommend flipping the polarity on "Non-merit reviewed program" because "Non-merit reviewed program = False" is harder to comprehend than "Merit-reviewed program = True" or "Merit-reviewed program = False."

    1. Bang Nhan

      Hi Daniel Lyons, nothing is too late. The point of last week kickoff meeting is to start things in a way we think is the best for this round during the SWIFT-SAT phase of this project. Did you get the email I sent last week about the questionnaire? Please fill that out and add your comment about this in there so we can discuss next Fri on what we all need to change. A lot of things on this page may not be true anymore, so things will need to be updated by all teams. So your inputs from the SSA perspective in the early phase of the SWIFT-SAT project is important. Thanks.