LLAMA Observatory Software Toy Model

General Description

The main goal of this project is to develop a more or less complete LLAMA Observing Software Toy Model, LOS(TM) for short, in the three days time frame allocated for the workshop. The software development cycle will include the system integration and tests.

Some of the concepts illustrated with these project are:

  • ACS Component/Container model
  • ACS Services: Logging and Error systems
  • ACS Components simulation
  • Language transparency and interoperability
  • Distributed deployment
  • Test driven development (unit testing)
  • Continuous Integration

The development will have a fixed deadline (last day of the course) and will be distributed in several teams. De-scoping will be allowed if needed to meet the deadline. Interface changes will have to be negotiated between the interesting parties and informed in due time to the rest of the developers.

To declare the project a success the software should be able to perform an automatic observation of at least one proposal composed of one target.

Legacy software

The following components coming from external projects are available and will be used. They are all located inside the LOS/EXTERNAL module in git:

  • Console
  • Telescope DevIO (simulated)

Requirements

Actors

There are two main external actors for this software project: Astronomers and Operators.

  • Astronomers will interact with the system through a Database component. They should be able to store a proposal, to query for the status of a given proposal, and to retrieve the proposal observations once the proposal has been executed.

  • Operators will interact with the system through a Console component. They should be able to start and stop automatic observations, and to get direct access to low level components for maintenance purposes.

LOS component breakdown and responsibilities

LOS will be composed of five components: Database, Console, Scheduler, Telescope and Instrument. Each component will have the following responsibilities:

  • Database. This is the system entry point for the astronomers. Besides allowing an astronomer to store a target list, query for the status and retrieve the proposal observations, it provides methods to get the proposals currently inserted into the database, to set a status to a given proposal and to insert a given observation into the database.
    • A Proposal consists of one TargetList (which is a list of one or more Target ), an identifier and a status (0 - queued, 1 - running, 2 - ready). A unique identifier is assigned by the database component and returned to user after storing his TargetList.
    • A Target consists of a Position specification, a exposure time and a target identifier assigned by the astronomer. The target identifiers should be unique per proposal.
    • A Position is simply the telescope position to be reached for that observation.

  • Scheduler. The Scheduler is responsible to select a proposal from the database, execute it, store the observations, and to manage the proposal lifecyle. The observation is done automatically as soon as the scheduler is requested to start. On stop it will complete the proposal before suspending the automatic mode.

  • Console. This is the system entry point for the operators. It allows the operator to start/stop the scheduler automatic mode, and provides them manual access to the low level components.

  • Telecope. This component communicates with the low level component controlling the hardware, and executes an observation (i.e. moves the telescope to a given position and acquires the image for a given exposure time once the telescope is in position).

  • Instrument. This component sets the camera on and off and it allows a user to take an image with a given exposure time.

All the types used in the exercise are defined in the ICD module (git Location LOS/ICD).

Interfaces

The initial interfaces are stored in git in LOS/ICD. They can be modified if needed but this will have to be negotiated on a case by case basis between the interested parties and will have to be noted down in a change request publicly available.

Implementation Languages

The implementation languages are already specified taking into account the information provided in the list of participants, Although this can be modified if needed.

Communication Diagrams

The following two communication diagrams illustrate the two main use cases to be implemented for this project.

Proposal Lifecyle

Proposal-Lifecycle-web.png

Automatic Proposal Execution

Automatic-Proposal-Executions-web.png

Teams

The work has been divided in component development teams of 2 persons each, plus an integration team . Each team has to be ready to negotiate the scope of its portion if needed to be able to meet the deadline (which is fixed). The teams role and responsibilities are the following:

  • Database. Responsible of the implementation of the Database component.
  • Scheduler. Responsible of the implementation of the Scheduler component.
  • Console. Responsible of the implementation of the Console component.
  • Telescope. Responsible of the implementation of the Telescope component.
  • Instrument. Responsible of the implementation of the Instrument component.
  • Integration. Responsible of developing end to end tests, system integration and deployment, simulation components. Member of this team should be also ready to support each team in test development.

References

-- Jorge Ibsen - 2014-08-11

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Automatic-Proposal-Executions-web.png r1 manage 47.2 K 2014-08-24 - 22:16 JorgeIbsen Automatic Proposal Execution
PNGpng Proposal-Lifecycle-web.png r1 manage 15.5 K 2014-08-24 - 22:00 JorgeIbsen Proposal Lifecycle
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2014-11-06 - GuillermoGCastro
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback