Ngc the sw view
Download
1 / 26

NGC: the sw view - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

NGC: the sw view. 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. Targets?. Key points:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' NGC: the sw view' - birch


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Caveat
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

NGC/SW


Targets
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)

NGC/SW


Backward compatibility
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.

NGC/SW


Main actors 1
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.

NGC/SW


Sequences creation hw tests
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

NGC/SW


Integration readout
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)

NGC/SW


Detector electronics + ccd/ir device

Photons

Pixels

We both (IR and ODT) do the same thing: we get photons and we

transform it in an image through some “pixel processor”

Pixel Processor

Image

FITS file

IWS

Data Flow (science)

Telescope & Instrument

Observer

NGC/SW


Data flow sensors
Data Flow (sensors)

Telescope & Instrument

Detector electronics + ccd/ir device

Photons

Pixels

Commands (?)

Image

e.g. AO subsystem

Pixel Processor

We still do the same thing: we get photons and we transform it in

an image through some “pixel processor”

NGC/SW


Pixels processing what
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?

NGC/SW


Pixels processing where
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… ?

NGC/SW


Pixels processing where cont pros and cons are only symbolic this list is non exhaustive usw
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

NGC/SW


Pixels processing where cont
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

NGC/SW


Pixels processing where cont1
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

NGC/SW


Pixels processing where cont2

IWS

LCU

Pixels

VME bus

Quad G4

Quad G4

(…)

Pixels processing: where? (cont.)

Just an idea…..

TEC? (VME standard, LCU types, G4 boards standard….)

Pixel Processor

NGC/SW


S l lcu
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

NGC/SW


Which environment
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

NGC/SW


High level architecture issues
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)

NGC/SW


Generic
Generic

  • Development tools/standards (UML design, code generation tools?)

  • Debugging tools for all environments

  • Integration into Control Model

  • Tests and tools for testing

NGC/SW



Acquisition process

IWS

IWS

Control Server

Control Server

Data Transfer Task

Data Transfer Task

RTD

RTD

Pre-Processor

WS

Data

Transfer

Command

Handler

Data

Transfer

Process

Data

Data

Capture

Acquisition Process Space

Image-Data

Acquisition Process

Application

Specific

Part

Commands

Data

NGC/SW


Dcs processes

DATABASE

FITS-Files

Config.-Files

RTD

Control Server

Data Transfer Task

AcquisitionProcess

Command Server

Acquisition Process

Acquisition Process

Device Driver(s)

Firmware

DSP

DCS Processes

Commands

IWS

Pre-Processor

Workstation

Fiber-Link

Detector

Front-End

LAN

Commands

NGC/SW

Data


Software layers

Graphical

User

Interface

SetClockPattern()

SetVoltage()

StartSequencer()

StopSequencer()

Reset()/Initialize()

SendCommand()

GetReply()

Open()

Close()

Read()

Write()

Ioctl() - Init, DMA, ...

ParseConfigFile()

SetReadoutMode()

SetupExposure()

ConfigureDataCube()

StartExposure()

AbortExposure()

ReceiveImage()

CreateFitsFile()

UpdateDatabase()

DisplayImage()

SingleDmaRead()

ConfigureBuffers()

StartDma()

WaitForData()

StopDma()

ProcessData()

TransferData()

Software Layers

Driver-Level

Driver Interface

Libraries

Controller

Interface

High Level

DCS

NGC/SW


Sequencer programming

Clock-Pattern

FrameStart

RowStart

ShiftColumn

ShiftRow

Pattern Dispatcher/

Micro-Sequence

ReadPixel

RESET

ResetPixel

DELAY

FrameEnd

READ

Sequence

Delay

FrameStart

LOOP 1024

RowStart

LOOP 64

ReadPixel 16

ResetPixel

END

END

RESET

LOOP 10

DELAY 5

LOOP 100

READ

DELAY 20

END

END

Sequencer Programming

Repetition Factors

NGC/SW


Sequencer programming1
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.

NGC/SW


The end
The End

NGC/SW


ad