To make a reasonable (conservative) cost estimate we have used the basic design below. This is not necessarily the actual design which will be used inside the camera, in particular some or all modules currently shown in the "Guider Linux Box" may move into the DAQ, and as a consequence some of the communication paths with the observatory may differ from those shown. In particular the DAQ/Guider may communicate to/from the TCS without going via CCS/OCS.
Strawman assumptions ("Stubbs Model")
- Guiding Star Catalog and any other configuration needed for guiding are considered part of "camera configuration" and delivered to the camera using the standard configuration system. CCS will record this in the configuration database and ensure the correct configuration is delivered to the Guider.
- We will use a very simple interface between the Guider HCU and the "Guider ROI Selection" and "Guider Centroid Finding" modules. One possibility is that those modules are written as standalone (C++/Python) modules and the Guider HCU starts them and communicates with them via stdin/stdout pipes. Guider configuration would be stored as files in the linux file system on the guider linux box.
- Data flow is as shown below
- Pointing info (per visit) provided by OCS and relayed by CCS to guider linux box.
- Configuration delivered as needed by OCS, stored in camera database and on the guider linux box.
- Guider ROI selection is sent to the Guider HCU, where it is converted to sequencer code (and/or sequencer parameters) loaded into the guider REBs
- Data flows from DAQ to to guider centroid finding (using existing planned push/pull interface)
- Guider centroid fining output is relayed by CCS/OCS to TCS. Some test will be required to confirm that this can meet the latency requirements. Alternatives are a direct interface from guider box to OCS.
CCS work required
- Extend Corner raft/CCS ICD to clarify details above (1 week – manager)
- Extend CCS/OCS ICD (LSE-71) to include above functionality (1 week – manager)
- Perform tests to confirm required latency for delivery of messages from "Guider Centroid Finding" to TCS. This can be folded into existing plans for CCS/OCS/DM testing and could be done by the summer. (This assumes that testing the DAQ->"Guider Centroid Finding" latency/throughput is a Corner Raft/DAQ responsibility).
- Include simulated guider functionality in early CCS/OCS pathfinder exercises (2 weeks software engineer)
- Develop and Test Guider HCU (6 weeks software engineer)
- CCS support for additional tests of complete guider system during I&T, Pathfinder, ComCam and commissioning (4 weeks software engineer)
Total: 12 weeks of software engineer effort, and 2 weeks of management ("free").