Skip to end of metadata
Go to start of metadata

(Information below originated from: [CI-CG Common Driver Architecture Questions] )
(Added by Michael Eder, last edited by Michael Eder on May 03, 2012)

CI-CG Common Driver Architecture

CG-CI Proof of Concept

It was agreed that CI and CG would undertake a proof of concept exercise to demonstrate how CI could slot in their common instrument driver and have it be controlled by the existing CG infrastructure. While there exist a number of questions regarding the actual scope and effectiveness of this proof of concept the following sections outline some of the issues that have been raised as well as if and how they have been resolved.
The [Serial to IP Design Issues Power Point] also raises some design issues.
Under CI development and confluence there exist a page for the prototype development. Because this page is not in a shared confluence space this page will refer to that page but issues relating to this prototype will be documented here. The CI prototype CG – CI common driver confluence page can be found here. Prototype CG-CI Common Driver.
The diagram below illustrates the current architecture of the proof of concept.

What are the key goals of the common driver architecture as well as the RDA drumstick solution.

The overriding goals appear to be:

  1. Simplify the integration by allowing CI and CG to have their own platforms that communicate via IP messaging.
    1. This will allow both CI and CG to develop their systems independent of the other and not have to worry about such things as OS versions, packages, memory and disk space, system building and releasing, etc. that would have to be addressed if they shared a common competition element.
  2. Utilize the common driver so that driver code does not need to be written multiple times.


Some of these overriding goals appear to be contradicted as illustrated by the questions below.

Brief notes on terminology:
  • Embedded CI implies the RDA gum stick solution with CI running on its own computational element talking to the processes and the instruments connected to the CGSN 7370.
  • Non-embedded CI, common driver solution, implies that the CI common driver is being controlled by CI instrument agent light (called the CI logger in the prototype) that provides the adaption between the CGSN control and command and the control command at the common instrument driver gets from the CI infrastructure.

Note - CI responses to questions below are in blue.  

General Architecture Questions

  1. What is the functionality needed of the port agent? As one can see in the diagrams below the port agent will run exclusively on the 7370 on CGSN platforms.
    1. What, if any, other platforms than CGSN platforms will the port agent be needed for?
      The port agent will be deployed everywhere a CI driver is used on an instrument and provide a generalized interface for the driver to access an instrument regardless of the connection type to the instrument. (refer to figures below)

    2. If the port agent is running on the 7370 how does it integrate into the 7370 (CGSN) software architecture?
      (https://docs.google.com/a/eng.ucsd.edu/drawings/d/1KEFIKNMsK4WHZ7JsIiI2VrccvfxkdcMQzhyoqoVng4o/edit)

(https://docs.google.com/a/eng.ucsd.edu/drawings/d/1GQolEEgN0uZqD-gwIjCS795DOtbSEFoNeGntAIz6cfY/edit)

      1. the CGSN 7370 will need to start and stop the port agent?
        A service / process will be needed to start up the port agent and monitor its health. For RSN this will be the platform agent. Currently CI Logger is responsible for starting the port agent.

      2. the CGSN 7370 will need to be able to determine the status of the port agent?
        What is the scope of the word "status" here: Is the process running? Is it connected to the driver or to the instrument? It seems to CI we would want both a process watchdog and a health watchdog.

      3. the CGSN 7370 need to get status of the port agent communications?
        Status elements need to be defined. However, CI could easily write another agent that hangs off the port agent that is responsible for monitoring health. The goal is to keep the port agent simple and push complexity out to supporting systems.

      4. how does the port agent get information about what serial port to use and how to configure the serial port?
        The configuration is given to the process, on port agent startup, via command line arguments.

      5. if the port agent his instrument agnostic will then not put unanticipated additional effort into the logger in order to determine the context of the information
        It’s CIs understanding that there were already several CG Loggers that were used for AST2 and that CI could leverage those for instrument logging.

        1. is it getting commands and responses?
          The port agent knows which line the data has come in on, i.e. bytes from driver or bytes from instrument, but nothing about context.

        2. how does it know if it has gotten a complete scientific data record?
          The port agent doesn’t know if it has gotten a “complete scientific record”. It simply transports and timestamps bytes of data.

        3. how does a timestamp and knows the time it gets the data is appropriate?
          Not quite sure what this question is asking; however, the port agent doesn’t really know anything about the data. All it knows is that bytes have been read. Those bytes are time stamped and delivered.

    1. What is the port agent serial to IP interface?
      1. Does the port agent read a single bite off the serial port and then send that bite to the instrument driver?
        The data window size is configurable. If the window is set to 1, then it will read one byte per iteration.

        1. If it does this bite by bite there'll be tremendous overhead to transfer one byte.
          That’s why currently we read more than one byte at a time, but CI would like to do some testing on performance to see if we can tune that number better.

        2. This mechanism is the most straightforward and allows for time stamping of every bite (again big overhead) but will provide the instrument driver all the information it needs and to be done totally diagnostically to instrument.
          Not quite sure what this statement means.

        3. Does the port agent need to support either end band or out of band signaling? It is not clear if the interface between the port agent and the common driver can be solely data to the driver from the serial port instrument and data from the driver to the serial port.
          Not sure what end (in?) band vs. out of band means here; however, the port agent is solely used for real time communication between the driver and the instrument which seems to CI to be in band. CI is not sure what out of band communications the port agent would have.

          An OS signal can be sent to the port agent to issue a hard reset to the serial line. This is the only out of band signalling the port agent will support.

      2. Does the port agent send data to the instrument driver more efficiently than bite by bite?
        The port agent will send every time it completes a read. This could be because the input buffer is empty or the data window is full. There is no explicit buffering in the port agent.

        1. If it does this it will mean that the port agent needs to have at least some knowledge of the instrument.
          CI is not sure what “it” is referring to, buffering maybe? No instrument knowledge is required in the port agent.

          The port agent is simply a proxy and will simply pass the data through with a timestamp.

          1. What constitutes a valid instrument data reading record and how does the port agent know when it has gotten such a record?
            This is instrument specific.  The port agent does not need to be aware of the existence of an “instrument data reading record”.  It is the responsibility of the instrument driver to know how to assemble bytes into full samples and properly apply time stamps.

          2. What do you send what you do when you get data that is incomplete?
            In ION, the driver would notify the instrument agent and the instrument agent would take the appropriate action.  It seems to CI that the CI Logger in the non RDA deployment would be where error and alerts are raised.

          3. What is the impact on time stamping?
            Not sure what impact CI should be addressing here. At a higher level the overall organizational impact or at the lower level the computational impact?

            Time stamping, in a higher sense, at the port agent provides the ability to more accurately provide a record of the instance when data is generated by an instrument since this is the first point of contact between the instrument and data management chain.

            At a lower level, time stamping shouldn’t adversely affect the processor in terms of computation cycles being used nor should it add to data latency.

  1. Common instrument driver issues and the interface of the instrument driver to the port agent as well as the CI logger/CI instrument agent/CI instrument agent light.
    1. It is CI's intent to have the instrument driver (common instrument driver) be exactly the same
      CI absolutely agrees. This sounds like a good plan to CI.

      1. where in the CI architecture does the port power control occur and can instrument driver the agnostic to this port power control on both platforms with embedded CI and without embedded CI?
        If the platform supports port power control, then the platform agent will manage it when CI is present. For non RDA, power is still controlled by the systems that are currently in place. The instrument’s only command and control is over the instrument.

    2. Where does the common instrument driver run?
      1. All the same control questions raised with regards to the port agent will apply if the instrument driver runs on the CGSN 7370 platform.
        In a non RDA deployment the driver will run on the 7370. In an RDA deployment the instrument driver can run on either the 7370 or the gumstix. Because the gumstix is 600MHz and the DCL is only 200MHz the gumstix seems like the logical choices. However, there is only 1 gumstix and could be several DCLs. So CI would suggest that the gumstix run where we have the most cycles free.

    3. The CI logger will, in implementations that have embedded CI, be a full-fledged instrument agent. In implementations without embedded CI it will be an instrument agent light. The key functionality difference is that if it handles the control messages that come from the CI system or is taking control messages from the CGSN one.
      The term instrument agent light implies to CI that the light agent will provide a subset of functionality that the ION instrument agent provides. That is not true. What we are currently calling the CI Logger provides an interface between the instrument driver.  It as access to and can provide all the functionality that the instrument driver supports.  In an RDA deployment ION is the command and control interface, in a non RDA deployment it is the DCL Controller.

      1. While there clearly appears to be a one-to-one correspondence between the messages sent by the CI system and the messages sent by the CGSN system (start instrument for example) the operational concepts between these commands are in some instances very different.
        Yes, but for those instances the CI Logger can simply make multiple calls to the driver to achieve the desired behavior.  In the ION world we have the concept of a transaction which batches commands together as one autonomous processes and the CI Logger can mimic this behavior.  

      2. During the course of the prototype we've uncovered some issues regarding how the CI infrastructure, both for embedded as well as non-embedded platforms, works in an autonomous environment.
  2. The logger functionality is still ill-defined for embedded versus non-embedded CI.
    The architecture for the common driver model is sound, but there are still implementation details that need to be worked out.

    1. The CGSN operational view of data is that there exist two types:
      1. command and response data
      2. scientific instrument data
        1. a logger must log in totality both kinds of data.
          This is a new requirement for CI.  However, in the ION world we log both commands and data and this doesn’t seem terribly difficult to replicate in a non RDA deployment.

        2. A logger or some other functionality must make some rudimentary determination if it has gotten a good command response and if it has gotten a good data records.
          It is the responsibility of the instrument driver to make the determination if it has received a good command response and if it has received a good data record(s).

      3. All data must be accurately time stamped.
        Yes.

        1. What functionality determines when good instrument data got accepted?
          Accepted by what? If we get data it should be logged regardless of quality. We can certainly raise alerts and send messages when we determine the data bad, but it doesn’t seem like a good idea to drop the data.

    2. In the instance where CI is embedded in the platform.
      1. The logger should log all data and commands going to and from the instrument?
        Yes.

      2. How will this data be time stamped?
        Data is timestamped by the port agent and it is the data loggers responsibility to package all the bytes together and timestamp appropriately.
    3. Non-embedded CI.
      1. Is a raw logger function needed?
        This sounds like an operational question to CI; however, the port agent will have support to perform raw logging.

      2. What is the logging function provided by the common instrument driver if any?
        Logging of data or diagnostics?  The driver does not do any logging of data.  The instrument agent is responsible for publishing the data and ION will store it.

        Below is the current proof of concept architecture diagram.

CI/CG SBE37 Common Driver Model Proof of Concept

Given this architecture what is the interface between the Port Agent and the CG Data Logger?  Will this be sending data byte by byte or is it more complicated than that and if so what determines the number of bytes sent?

We would employ the same time stamping strategy that RSN is using in their port agent.  Data windows are timestamped as a packet.  The timestamp is taken immediately before a read and the read happens until the buffer is full or a time has passed with no data on the line.  

Where is the data timestamped and what is the architecture to insure that timestamps are correct?

Data is timestamped at the port agent and while there is no specific "architecture" in place to ensure timestamps are correct we will follow a standard model for time stamping data.  It seems that it might be beneficial for the IOs to agree on a single time stamping methodology.  RSN seems to be the furthest along with their strategy and CI is moving to adopt there model. 

What is the mechanism to configure the instrument and how does one change the configuration?

The CI Logger will be responsible for configuring the instrument by providing the interface to the common instrument driver.  We modeled the POC CI logger after the CG Logger so the default configurations are hardcoded into the program, but the architecture will support several options for instrument configurations.  It seems this choice is your.

Building CI Environment

[TS-7370 Setup For CI CG Common Driver] and TS-7370 Notes

Followed the APT repository step

Contacted Steve Foley and got version of python to download

Downloaded Python 2.5.4 from http://www.python.org/download/releases/2.5.4/ for Other platforms.  Transferred gzip-compressed file. Un-compressed and un-tared. 

Did ./configure to create Makefile

Make and Make install

it appears Steve Foley who did the original Python testing on the 7370 felt that version 2.5.4 was the most stable version to use on the Etch version of Linux.  Bill French says he has been using version 2.5.6 and he installed this version as a possible solution to the problems we are having (see below) with regards to the 0MQ Python bindings.  based on Steve Foley's work and his concerns related to "OABI" some investigation as to what changed between these minor revisions should be undertaken.

Downloaded zeromq from http://download.zeromq.org/zeromq-2.2.0.tar.gz

Did ./configure to create Makefile

Make and Make install

Download the tarball source code from zeromq, From the zeromq link download the latest python bindings, at the time of writing https://github.com/zeromq/pyzmq/downloads/pyzmq-2.2.0.tar.gz

It appears that the 0MQ Python bindings are not working on our version of the 7370

Run: python setup.py configure
        python setup.py install (this fails Bill French investigating)

It appears that the 0MQ Python bindings are not working on our version of the 7370.  Bill has installed both the bindings and Python 2.5.6 but this does not appear to fix the problem.

We need to have clear install steps to build the 7370 image, download Python and related libraries.  Verify that Python and CI software is running.  Then we can add the "standard" CGSN load that will not impact these.

The following two diagrams illustrate the current understanding of the architecture for both embedded as well as non-embedded CI utilizing a common driver approach

CI/CG Common Driver Model with Embedded CI

This diagram illustrates questions regarding the functionality of the port agent in this situation where there is embedded CI.  The port agent will run as part of the CGSN infrastructure and is responsible for supporting both the role logging requirements as well as the status requirements that have been identified in the CI and CG interfaces document. 

The issues are raised above in greater detail but primarily of concern is:

  1. What is the functionality of the port agent and the instrument specific logger and how to the interface to each other?
  2. How are these two pieces of software maintained and how they integrated into the CGSN infrastructure in which they run?
  3. What is the functionality that needs to be realized with regards to logging?
  4. CG's perspective is this configuration the port agent would be written in "C" and there would be no additional library or other software (Python) requirements than what the CG system needs.

CI/CG Common Driver Model w/o Embedded CI

With regards the situation where there is no embedded CI the primary concern is what and where is the logging functionality and what are the requirements about what has to get logged.

Clearly both data as well as commands sent to the instrument need to be logged.  Data needs to be time stamped.

What are the platforms (are there any) where there are Common Instrument Drivers and no embedded CI?

How will the components provided by CI be implemented in this environment and what are the requirements (minimal system requirements) that must be maintained to support CI.

What are the  library or other software (Python) requirements for this configuration?

Labels

favourite favourite Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.