compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (26)

View Page History

_Everything in Assumptions and Dependencies is consistent with John G's understanding except as noted._

# Sensing and Acquisition is responsible for:
## Interfaces to Sensors (instruments)
### State-of-health monitoring
# Primary Programming Language is Java (2130-00002 pg. 1)
{note:title=JBG}Michael M has told me verbally that these language decisions are not yet made. Not sure whether that or document holds. JBG
# Specific purpose applications for user interfaces will be in Python (2130-00002 pg. 1)
# In the case of instrument direct access, the other service networks (i.e. not S&A) will establish the communication channel and the VPN so that direct access can occur (i.e. the IO's will provide VPN management). The same is true for the serial access case and the user will simply connect the virtual serial port software to an IP address.
# During the VPN (direct access case). Other than some form of authentication, all other CI functionality will not be available due to this being an out-of-band mechanism.
# There is a one-to-one relationship between IP address and an instrument agent.
# -There is a one-to-one relationship between IP address and an instrument agent-. \[There is no relation between instrument agent and IP address\]
# If the *DN Information Information Container Overview* on 2130-00002 pg. 12 is correct, the Instrument agent will be responsible for:
## Constructing the message
# The COI provides consistent policy enforcement (2130-00002 pg. 2)
# The COI provides uniform life-cycle management and access for resources (instruments are a resource) (2130-00002 pg. 2)
# The Data Management (DM) Service Network (SN) will provide data distribution (2130-00002 pg. 2)
{note:title=JBG}This and the following line are uncertain in my mind, I haven't seen these tasks in DM yet (but they may be there).
# The DM SN will provide data persistence (buffering, caching, and archiving) (2130-00002 pg. 2 & pg. 7)
# There will exist (outside of the S&A SN) a *Resource Catalog* where information related to physical resources (such as manuals) will be stored. (2130-00002 pg. 14)
# The infrastructure for the network will be provided (satellite, LAN, etc.) by the CI already. The S&A will build on top of an existing network.
# Coding any prototypes that succeed in acquiring real data will REQUIRE exact, real-world instruments (type, manufacturer, model numbers) to be specified and perhaps samples provided.
# We need the list of instruments to support, rumored to exist and to have been sorted in order of complexity by Frank Vernon, for us to start bridging the gap between suggested ontologies / messaging systems and actual real-world data sources.

h4. Outstanding Issues

# Is the assumption that we are making about the instrument agents running inside a capability container always true so that we can depend the existence of the CC for all instrument agents?
# 2130-00002 pg. 2 states Mule will be the ESB, I thought we were not using an ESB?
# Does the instrument agent ever interact direcly with CEI or is it all through messaging?
{note:title=JBG}All through messaging.
# Is the assumption that the instrument agent only interacts with the COI true (i.e. does it just exchange messages with the COI and the COI handles interactions with other resources (like other instruments))?
{note:title=JBG}Yes, true (except possibly for direct access.
# (2130-00002 pg. 6) What is meant by "other" observatory infrastructure?{note:title=JBG}
{note:title=JBG}Controllable resources like lights, docking systems, maybe network controls ...(?)
# (2130-00002 pg. 6) states "performs observatory management and oversight", I would assume that is referring to the external observatory management system and not to sensing and acquisition (as it sounds), correct?
# Is the *DN Information Container Overview*(2910-00010 OV7 shown on 2130-00002 pg. 12) the form that all messages on the Exchange will take or only those for the DM SN? {note:title=JBG}
## Related: Can you give an example of a message that would have no body (it is listed as optional)?
{note:title=JBG}In my copy, 'Header' is listed as optional. I expect many messages might not have a header. Uhh, no examples come to mind in particular though.
# Is the assumption that the VPN connection is handled by the IO's true?
# If the direct instrument access occurs over VPN connection, are we foregoing some of the CI functionality? For example, will logging still need to be done, but in a different way? Will authentication happen on the VPN and will that be synch'd/linked with the CI policies, etc.?
{note:title=JBG}Yes, I think you are forgoing *all* the CI functionality. This is why direct access via VPN would be A Bad Thing. IMHO.
# Is the idea implement IP over AMQP with OOI managed user authentication? Likely to be VPN that's not aligned with the other security or policy components. Look up the requirements \-> do we try to use AMQP \-> This requirement needs to be looked up.
{note:title=JBG}I think we can envision the debate here. IO: "I need total fidelity in the direct access connection." CI: "We really want it all to go through COI. What is total fidelity anyway." IO: "Just give us a direct connection already." At least, that's what I'd say if I were the IO (or the CI).
# For direct instrument access, does the OOI CI still need to enforce policy when things are going through direct access? For example, you don't want somebody turning on a noise generating machine when a passive acoustic experiment is occurring. There is really no way for the end user to know about the impacts his/her actions on other resources. This seems extraordinarily difficult.
# Why is the data process repository in the sensing and acquisition service network? I would think that the vast majority of data processing happens outside of sensing and acquisition and it seems like the responsibility is misplaced.

h4. [Requirements Refinement]