1. 10/12/2003NGC/SW NGC: the sw view

2. 10/12/2003NGC/SW Caveat Only very basic issues are covered No details, no “ready to go” solutions Not even requirements! No FIERA vs. IRACE! This presentation has only been “discussed” among IR & ODT SW It is not (yet ) a common proposal

3. 10/12/2003NGC/SW Targets? Key points: Integration in (available) VLT environment Performance: speed, time accuracy, error recovery, etc. Maintenance: simplicity, evolution of requirements (functionalities), environment (new hardware and software)

4. 10/12/2003NGC/SW Backward Compatibility Do we want backward compatibility to FIERA/IRACE? –Not an issue for FIERA: no upgrade foreseen, instruments can run like this for > 5 years –An issue for IRACE: possible failure of irreplaceable parts If only one system is involved (IRACE?), an interface layer towards the “past” is easier. Two are unrealistic.

5. 10/12/2003NGC/SW Main “actors” (1) Observer (e.g. OS, operator) Detector specialists/Engineers Maintenance (hw/sw) FITS (files and dictionaries, DICB) TCS AO subsystem ? (1) In UML notation an actor is an external entity which interacts with our system; they also carry out the use cases.

6. 10/12/2003NGC/SW Sequences Creation/HW Tests Format (ASCII?) Created by Engineers only Configuration Control (more engineers may work on a system at the same time) User interface to create them (WES?) Atomic tests on real HW (for engineers only) Scripting language for Engineers’ tests

7. 10/12/2003NGC/SW Integration/Readout Different exposure times per window DCS Synchronization with: –Other DCS(s) –TCS (autoguiding) –Secondary (e.g. va et vien, chopping?) –Deformable mirrors I.e. synchronization with an external signal (e.g. TIM) Speed reading the sensor (mainly HW issue, e.g. gigalink) During integration operations (e.g. HIT modes) Drift scanning? (issues: FITS files generated continuously, readout with open shutter) Readout/display requirements are quite different between ODT & IR (Joerg will talk about it)

8. 10/12/2003NGC/SW Data Flow (science) Telescope & Instrument Observer Photons Detector electronics + ccd/ir device Pixels ImageFITS file IWS Pixel Processor We both (IR and ODT) do the same thing: we get photons and we transform it in an image through some “pixel processor”

9. 10/12/2003NGC/SW Data Flow (sensors) Photons Detector electronics + ccd/ir device Pixels Image Pixel Processor We still do the same thing: we get photons and we transform it in an image through some “pixel processor” e.g. AO subsystem Commands (?) Telescope & Instrument

10. 10/12/2003NGC/SW Pixels Processing: what? Soft-windows: no sequences required, made in SW Reordering Centroiding (for autoguiding) Filtering (e.g. cosmic rays removal) IR procedures (too many: collapsed! ) Bias subtraction?

11. 10/12/2003NGC/SW Pixels processing: where? This may be a HOT topic ;-) Keep in mind I’m only listing areas to be investigated. Then: IR requirements are “harder” than optical ones, i.e. what is ok for IR will also be ok for optical. Now: Linux box, DSP, LCU or… ?

12. 10/12/2003NGC/SW Pixels processing: where? (cont.) Pros and cons are only “symbolic”, this list is non exhaustive usw… Linux box is the solution used by IR: –Pros: it works! –Cons: impossible to match required performances using CCS due to threads issue (Peter, Joerg?) DSP –Pros: DSP are meant to do this job –Cons: no standard environment for DSP at ESO Standard LCU –Pros: standard at ESO –Cons: not enough computing power

13. 10/12/2003NGC/SW Pixels processing: where? (cont.) My personal considerations (slides added last minute, NOT discussed with the others) What about trying to have something (i.e. pixel processor) in common among ODT, IR & AO? All in all we are all dealing with pixels and we work in close connection: we provide pixels/images, they process pixels/images

14. 10/12/2003NGC/SW Pixels processing: where? (cont.) The idea would be to have the board which is the computing power behind the AO-RTC doing the job: 4 power pc running VxWorks In principle they may also be “stripped down” to e.g. 2 power pc. Pros: commonality through ESO, use of standard sw Cons: possibly expensive

15. 10/12/2003NGC/SW Pixels processing: where? (cont.) Just an idea….. TEC? (VME standard, LCU types, G4 boards standard….) Pixels LCU Quad G4 (…) VME bus IWS Pixel Processor

16. 10/12/2003NGC/SW S/L LCU? It’s the unit that receives commands from the OS, runs DCS, communicates with the detector electronics, sends back the data to the IWS. It’s part of the “pixel processor”. LAN connection may be an issue (Gigabit Ethernet?) Local Control Unit OS Options are: Linux Solaris VxWorks

17. 10/12/2003NGC/SW Which environment? CCS: well known, possibly changes to be asked (e.g. threads issue) ACS (ALMA): new, new technologies used (e.g. CORBA), imho worth a try

18. 10/12/2003NGC/SW High Level Architecture Issues BOSS and CLIP for standard command interfaces and image post-processing? FITS keywords (extensions etc., improve interface to DICB) Exposure handling (e.g. next exposure can start even if the previous has not been already saved) “Lessons learned” implementation (e.g. more informative error messages) …

19. 10/12/2003NGC/SW Generic Development tools/standards (UML design, code generation tools?) Debugging tools for all environments Integration into Control Model Tests and tools for testing

20. 10/12/2003NGC/SW And now Joerg….

21. 10/12/2003NGC/SW Acquisition Process Control Server Data Transfer Task RTD IWS Data Transfe r Data Transfe r Data Captur e Proces s Data Comman d Handler Acquisition Process Space Image-Data Pre-Processor WS Commands Data Application Specific Part Control Server Data Transfer Task RTD IWS

22. 10/12/2003NGC/SW DCS Processes Control Server Data Transfer Task Command Server Device Driver(s) Acquisition Process DATABASE Config.-Files FITS-Files RTD IWS Pre-Processor Workstation Firmware Detector Front-End LAN Fiber-Link Commands Data Commands DSP

23. 10/12/2003NGC/SW Software Layers Reset()/Initialize() SendCommand() GetReply() SingleDmaRead() ConfigureBuffers() StartDma() WaitForData() StopDma() SetClockPattern() SetVoltage() StartSequencer() StopSequencer() ProcessData() TransferData() ParseConfigFile() SetReadoutMode() SetupExposure() ConfigureDataCube () StartExposure() AbortExposure() ReceiveImage() CreateFitsFile() UpdateDatabase() DisplayImage() Open() Close() Read() Write() Ioctl() - Init, DMA,... Driver-LevelDriver Interface Libraries Controller Interface High Level DCS Graphical User Interface

24. 10/12/2003NGC/SW Sequencer Programming RESET LOOP 10 DELAY 5 LOOP 100 READ DELAY 20 END Sequence FrameStart LOOP 1024 RowStart LOOP 64 ReadPixel 16 ResetPixel END RESET READ DELAY Pattern Dispatcher/ Micro-Sequence RowStart ReadPixel FrameStart ShiftColum n ShiftRow ResetPixel FrameEnd Delay Clock-Pattern Repetition Factors

25. 10/12/2003NGC/SW Sequencer Programming Clock-Patterns (smallest unit) are stored in sequencer "memory". The loops are downloaded to sequencer as (checked) structural code and not in ASCII format. ASCII format is interpreted at higher level. Loop parameters and pattern repetition factors must be derived from arbitrary functions depending on DIT, NDIT, NDSAMPLES, NDSKIP,... Special tokens like SYNC ("wait for external trigger"). Loop structures can be executed in real time by FPGA (no processor required). Logical hierarchy in three steps (pattern / micro-sequence / sequence) should be kept.

26. 10/12/2003NGC/SW The End