Nuraghe Documentation

Transcript

Nuraghe Documentation
Release 0.4
Nuraghe CS team
February 17, 2015
Contents
1
User’s guide: Observing with Nuraghe
1.1 Observing at Medicina with Nuraghe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Observing at Noto with Nuraghe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Observing at SRT with Nuraghe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
1
2
Supervisor on duty
2.1 Medicina SoD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Noto SoD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 SRT SoD guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
3
3
Development guide
3.1 Releasing procedure . . . . . . . .
3.2 What’s new in the next version . . .
3.3 Component development workflow
3.4 Nuraghe components API . . . . .
3.5 Protocols . . . . . . . . . . . . . .
3.6 HOWTOs . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
14
19
21
Nuraghe control software team
4.1 Core developers . . . . . . . .
4.2 Astonomical referees . . . . . .
4.3 Hardware and network support .
4.4 Contributors . . . . . . . . . .
4.5 Responsibilities . . . . . . . . .
4.6 People involved in the project .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
27
27
28
29
4
5
Indices and tables
.
.
.
.
.
.
.
.
.
.
.
.
31
i
ii
CHAPTER 1
User’s guide: Observing with Nuraghe
Contents:
1.1 Observing at Medicina with Nuraghe
Contents:
1.2 Observing at Noto with Nuraghe
Contents:
1.3 Observing at SRT with Nuraghe
Contents:
1
Nuraghe Documentation, Release 0.4
2
Chapter 1. User’s guide: Observing with Nuraghe
CHAPTER 2
Supervisor on duty
Contents:
2.1 Medicina SoD
Contents:
2.2 Noto SoD
Contents:
2.3 SRT SoD guidelines
Questa sezione riporta le linee guida e la documentazione a cui deve far riferimento il supervisor on duty durante
la sua attività al SRT.
2.3.1 Azioni propedeutiche all’osservazione
Prima che inizi l’osservazione, il SoD deve sempre:
• Verificare che Nuraghe sia avviato, altrimenti lo si avvii
• Verificare che Nuraghe sia ready, altrimenti si risolva il problema
• Eseguire il setup in base al ricevitore che dovrà essere utilizzato
• Verificare che Nuraghe sia configurato correttamente, ovvero che dopo il setup globale tutti i sottosistemi
risultino configurati come ci si aspetta
Important: Il SoD non deve partire dall’assunzione che il sistema sia funzionante nemmeno nel caso in cui il
SoD che ha appena terminato il turno gli garantisca che tutto è OK. Quindi prima che inizi l’osservazione deve
sempre seguire scrupolosamente la procedura appena descritta, accertantdosi che tutti gli step diano esito positivo.
Le azioni indicate negli step di sopra sono descritte nei seguenti documenti:
3
Verificare che Nuraghe sia avviato
Avvio di Nuraghe
Verificare che Nuraghe sia ready
La situazione è questa: il SoD ha avviato Nuraghe, seguendo l’attuale Nuraghe from scratch o qualcosa di simile.
Fatto ciò, non siamo ancora sicuri che il sistema sia ready. Infatti il SoD a questo punto potrebbe verificare che
tutti i container siano su e anche avviare le console, ma tutto questo non garantirebbe che il setup vada a buon fine.
Alcuni motivi:
• c’è un reset globale delle emergenze (non previsto nel setup)
• c’è un reset da fare nei servo minori
• un servo minore è in failure
• le schede dei ricevitori non sono raggiungibili perché ci si è dimenticati di chiudere il tool di diagnostica
• il backend che si dovrebbe utilizzare è spento
Se siete d’accordo, ho in mente un check che risolva buona parte di tutto questo in un unico comando da lanciare
da shell prima di nuragheConsole. Ad esempio, se chiamiamo questo comando telescopeCheck, nel
caso in cui tutto sia OK:
$ telescopeCheck
OK
Se c’è da fare un antennaReset (leverei il comando dalla OperatorInput, e lo metterei in carico al SoD –posso
fare in modo che venga lanciato da shell– in modo da separare ancora meglio i ruoli):
$ telescopeCheck
ERROR
An emergency stop reset is required.
You should execute antennaReset (please, be careful)
$ antennaReset
Reset successfully sent
Ora abbiamo risolto questo primo problema, però ci sono altre condizioni che potrebbero non consentire un setup
corretto. Non possiamo fare un check del backend, perchè ancora non sappiamo quale vorrà usare l’utente. Possiamo però avvisare il SoD:
$ telescopeCheck
WARNING
The total power backend is not online.
Fix the problem if you have to use it.
Eseguire il setup
Verificare che Nuraghe sia configurato correttamente
La situazione è questa: è stato eseguito setupXXX da OperatorInput. Il SoD dovrebbe guardare tutte le varie
console per capire se il setup è andato a buon fine. Se siete d’accordo, implemento un check veloce che può essere
eseguito da OperatorInput, con il comando systemCheck. Ad esempio, se tutto è OK:
> systemCheck
OK
System configured (setupCCB)
Se ad esempio il sistema è in setupCCB, ma è scattato il differenziale del SRP:
> systemCheck
ERROR
The SRP is power off
4
Chapter 2. Supervisor on duty
Se è andato giù un container:
> systemCheck
ERROR
The SRT7GHzComponent is not available.
Verify the SRT7GHzContainer is active.
Quindi, quando l’utente ha dei sospetti su qualcosa, può sempre eseguire un systemCheck da OperatorInput,
per verificare al volo che tutto stia andando bene, senza dover passare su nuraghe-mng o altre eventuali macchine
per contare che tutti i container siano attivi, o verificare i log di ciascun container.
Risolvere i problemi
Contents:
Servo minori
Risolvere un setup non riuscito
Problema Dalla console OperatorInput è stato eseguito il setup (comando setupXXX oppure
servoSetup=XXX) ma dopo qualche minuto nella console MinorServo il flag starting è passato da
verde a rosso ed il flag ready è anche lui rosso.
Note: Inserire una immagine della console sei servo minori che mostra la situazione descritta.
Soluzione Su acsCommandCenter (macchina nuraghe-mng), controllare la finestra di log del container dei servo
minori.
Note: Inserire immagine di tale finestra di log.
Ci sono tre possibili soluzioni, a seconda del messaggio di errore riportato nella finestra di log:
• se è riportato “GFR (o SRP o M3R o PFP) in failure”, non ci si può far nulla, se non contattare il responsabile degli impianti (G.Paolo Vargiu) per avvisarlo del malfunzionamento. Questo è un problema ricorrente,
che spesso si risolve riarmando il differenziale nel quadro elettrico del servo minore in avaria
• se è riportato “GFR (o SRP o M3R o PFP) in emergency stop”, si vada alla sezione Fare il reset degli
emergency stop
• se è riportato un messaggio diverso dai precedenti, si vada alla sezione Riavviare la MSCU
Problemi di puntamento
Problema Descrivere l’anomalia... La console deve riportare il setup corretto.
Soluzione Possibilita’:
• container servo giu’
• failure SRP
• messaggio errore differente da failure, in questo caso Riavviare la MSCU
2.3. SRT SoD guidelines
5
Ricevitori
Backends
Active surface
Infine, tutte le procedure, compresa quella indicata in questa pagina, sono elencate di seguito:
Procedures
Contents:
Procedure relative a Nuraghe
Contents:
Azioni propedeutiche all’osservazione Prima che inizi l’osservazione, il SoD deve sempre:
• Verificare che Nuraghe sia avviato, altrimenti lo si avvii
• Verificare che Nuraghe sia ready, altrimenti si risolva il problema
• Eseguire il setup in base al ricevitore che dovrà essere utilizzato
• Verificare che Nuraghe sia configurato correttamente, ovvero che dopo il setup globale tutti i sottosistemi
risultino configurati come ci si aspetta
Important: Il SoD non deve partire dall’assunzione che il sistema sia funzionante nemmeno nel caso in cui il
SoD che ha appena terminato il turno gli garantisca che tutto è OK. Quindi prima che inizi l’osservazione deve
sempre seguire scrupolosamente la procedura appena descritta, accertantdosi che tutti gli step diano esito positivo.
Superficie attiva Section author: Carlo Migoni
Backends Section author: Sergio Poppi
Servo Minori Section author: Marco Buttu, Gian Paolo Vargiu
Fare il reset degli emergency stop Dopo aver premuto un emergency stop nel circuito dei servo minori, per
rendere i servo sistemi operativi non è sufficiente rilasciare il pulsante premuto, ma è necessario fare il reset dell
emergenze. Il reset va fatto premendo il pulsante RESET EMERGENZE esternamente al quadro elettrico del
servo in questione.
Note: Il LED del pulsante QUADRO IN BLOCCO è acceso fisso (non lampeggia) quando vi è un emergency
stop premuto. E’ acceso e lampeggiante quando l’emergency stop è stato rilasciato ma non è stato fatto il reset
delle emergenze. E’ spento quando il servo è pronto per essere utilizzato.
Le seguenti due sezioni spiegano in dettaglio come effettuare il reset.
Reset del GFR o del M3R Per fare il reset degli emergency stop relativi al Gregorian Feed Rotator (GFR) e al
M3 Rotator (M3R), si prema il pulsante RESET EMERGENZE nel fronte quadro dei servo (quando si entra in
EER dal lato ascensore, il quadro lo si trova a sinistra della porta). Di seguito una foto del quadro in questione.
6
Figure 2.1: Figura: Fronte quadro del Gregorian Feed Rotator e M3 Rotator
Reset del PFP o del SRP Per fare il reset degli emergency stop relativi al Primary Focus Positioner (PFP) e
al SubReflector Positioner (SRP), si prema il pulsante RESET EMERGENZE nel fronte quadro di entrambi i
servo. I quadri sono situati in APEX room.
Fare il setup dei soli servo minori Eseguire da OperatoInput il comando servoSetup=XXX. Ad esempio, se
si vuole mettere in fuoco il ricevitore in banda C:
> servoSetup=CCB
Nella console dei servo minori il flag starting dovrebbe diventare verde, come mostrato in figura.
Note: Inserire immagine console servo con flag starting verde
Il setup termina quando il flat starting passa da verde a rosso (sono necessari dai 2 ai 4 minuti, a seconda del
setup). Se il setup è andato a buon fine, nella console dei servo minori il campo actualSetup riporta il codice
del setup appena effettuato, e il flag ready diventa verde. Ad esempio, in figura X è mostrata la console dei servo
minori dopo che è stato concluso con successo un servoSetup=CCB.
Note: Inserire immagine console servo con servoSetup=CCB done
Se il flag starting è diventato rosso ma il flag ready non è diventato verde, come indicato nella figura
seguente, allora c’é stato un problema con il setup.
In questo caso si consulti la sezione Risolvere un setup non riuscito.
Riavviare la MSCU La Minor Servo Control Unit (MSCU) è il server di controllo di tutti i servo minori. E’
un PC embedded situato all’interno del quadro elettrico di M3R e GFR. Per riavviare il server ci si colleghi con
rdesktop:
7
Figure 2.2: Figura: Quadri elettrici del PFP e SRP
Figure 2.3: Figura: La console dei servo minori indica che il sistema non è configurato
8
$ rdesktop-vrdp 192.168.200.16 -f -u Oper
Una volta collegati alla macchina, ci si ritroverà di fronte una schermata come quella mostrata di seguito.
Figure 2.4: Figura: Schermata del desktop della MSCU
Si clicchi con il mouse sopra la finestra di log e si prema il tasto ESC. Dopo qualche secondo la finestra di log si
chiuderà.
Si avvii il server tramite l’icona MSCU Server. Inizialmente la schermata di log sarà come quella mostrata di
seguito.
Figure 2.5: Figura: Finestra di log della MSCU durante l’avvio
Dopo circa un minuto il server sarà avviato, e la schermata della finestra di log sarà analoga a quella riportata di
seguito.
9
Figure 2.6: Figura: Finestra di log della MSCU al termine della procedura d’avvio
Ricevitori Section author: Marco Buttu, Sergio Poppi
Procedure non legate a Nuraghe
Trovare un titolo migliore?
Contents:
Procedure antenna Trovare un titolo migliore
Procedure sui servo minori
Procedure sulla superficie attiva
Procedure sui ricevitori
Procedure sui backends
10
CHAPTER 3
Development guide
Contents:
3.1 Releasing procedure
Nuraghe uses a major.minor.patch nomenclature, so Nuraghe-1.5.2 has a major version of 1, a minor version of
5, and a patch version of 2. The major version zero (0.y.z) is for initial development, when anything may change
at any time, so the public API, the operator input commands and the schedule grammar should not be considered
stable.
3.1.1 Production-ready releases
This section describes the semantic used to assign the version number to the production-ready releases, that is the
releases the astronomers use during their normal observations.
New major versions
New major versions are exceptional, because they only come when strongly incompatible changes are deemed
necessary, and are planned very long in advance.
That means if an astronomer schedule can be executed using Nuraghe-1.x.y, then it will also be executed using
any of the next releases of Nuraghe with major version of 1.
New minor versions
New minor versions are feature releases, so they add functionality in a backwards-compatible manner.
New patch versions
New patch versions are bugfix releases that make backwards-compatible bug fixes
3.1.2 In-development versions
We also have non-production ready versions which get an additional qualifier: beta and release candidate (RC).
The beta versions are aimed at testing by advanced users, not production use, while the RC is aimed at testing by
a group of astronomers, as described in section Release Candidate.
11
Beta
In this stage no more features are accepted. Only bug fixes can now be committed. This is when core developers
should concentrate on the task of fixing regressions and other new issues. The new user’s manual must be released
before the end of this stage.
Release Candidate
A release candidate (RC) must be tested by a group of astronomers, called RC testers. They should interact whit
the core developers in order to report the malfunctions.
This release can only have bugfixes applied that have been reviewed by other core developers, and can become a
final-release only after the RC testers give their approval.
After the final-release is published, the full development cycle starts again for the next minor version. Only the
Project manager can approve new changes to the final releases.
3.2 What’s new in the next version
This section explains the new features (from the user’s point of view) in Nuraghe-0.5, compared to 0.4.
3.2.1 New components
This section lists the new components of Nuraghe-0.5. As usual all the information about how to manage the
components both by the operatorInput console and from the schedule, is fully reported in the user’s manual for
Nuraghe-0.5.
DewarPositioner
Section author: Marco Buttu, Andrea Orlati, Sergio Poppi, Simona Righini
The DewarPositioner component has in charge the derotators management.
XKaBandReceiver
Section author: Marco Buttu, Andrea Orlati
The XKaBandReceiver component manages a dual feed receiver, called Sogliola, that can operate simultaneously
in two bands: X and Ka.
3.2.2 Minor servo system
Section author: Marco Buttu
The MinorServo console displays:
• the position of every minor servo
• a clear status (reset required, ready to move, ecc.)
• proper colors for the flags
Optimizations:
• setup time improved
12
Chapter 3. Development guide
3.2.3 Receivers
Section author: Andrea Orlati
The Receivers console displays:
• the receiver temperatures
3.2.4 OperatorInput
Section author: Marco Buttu, Andrea Orlati
Minor improvements:
• a short and comprehensible error message in case of unexpected errors
3.3 Component development workflow
Abstract
Brief intro about the goal of this section and the TDD in general. See Test Driven Development (TDD) in
Nuraghe for details.
Contents:
3.3.1 Write a hardware simulator
Hardware Simulator and related tests. The same tests must pass both for the hardware and the simulator. An
important goal is to test the hardware interface robustness, in order to simplify the diagnosis of component malfunctions and the Nuraghe maintenance. In that way, if we have to upgrade an hardware firmware or an interface,
we just have to run the tests to be sure the upgrade does not break the system.
3.3.2 Write a hardware communication library
We have to write a hight level library in order to communicate to the hardware from the component, in order to
simplify the component code, its maintenance and its readability, and also the tests (we have to mock the library,
not the protocol).
3.3.3 Write the component
De-couple the ACS interface from the component core. TDD for unit and functional tests.
3.3.4 Integration tests
Integrate the component in Nuraghe
Write the integration tests (subsytems communication), ...
Beta release
Test the Beta in the dev-environment and then in production.
3.3. Component development workflow
13
Release candidate
Give the Release Candidate to the RC testers (in procution)
Final release
See Production-ready releases.
3.3.5 How to fix a bug
Once we have confirmed the existence of a bug, we do not never start fixing it until we have reproduced that bug
in a unit test. So, if we want to fix a bug, we have to:
• work in the nuraghe-x-dev environment
• write a small, simple and fast test that reproduces the bug
• ensure the test breaks
• fix the code
• run the test to confirm it now passes
• run all the regression tests to confirm that the changes does not brake something else
• leave the test in the test directory (forever) in order to ensure that the bag does not reoccur
• commit the changes
• update the changes in production
• run all the tests in production
This is the only way to ensure the Nuraghe stability and robustness, and you will soon realize the TDD is not at
all a lose of time.
3.4 Nuraghe components API
Abstract
Nuraghe is designed following a software architectural pattern called component-container model. During
the normal execution, the ACS framework runs 10xx Nuraghe components, each one has in charge a specific
hardware management (control and monitoring). The goal of this document is to comprehensively explain
the APIs of some Nuraghe components (CLARIFY: ExternalClient because currently is the only one that
provides an ACS-independent Nuraghe interface, but also other component that we want to explain the API
since thier non-trivial configuration).
Contents:
3.4.1 DewarPositioner
14
Abstract
Questo documento è il manuale di utilizzo del component di Nuraghe che gestisce i derotatori, chiamato
DewarPositioner. Il documento è suddiviso in due parti: la sezione Guida per l’astronomo spiega
come interagire con il derotatore tramite la console dell’operator input, mentre la sezione Descrizione delle
API descrive come interagire con il component in modo programmatico, per cui è la parte di riferimento per
chi intende scrivere dei programmi che utilizzano il DewarPotitioner.
Sia la parte per gli astronomi che quella per i programmatori sono suddivise in cinque sezioni, che riguardano
rispettivamente il setup, le configurazioni, il parcheggio, il riavvolgimento e una lista dei comandi o metodi.
Contents:
Guida per l’astronomo
In questa sezione viene descritto come interagire con il DewarPositioner tramite la console operator input.
Esecuzione del setup
Il DewarPositioner gestisce tutti i derotatori alla stessa maniera, per cui in fase di setup è necessario indicare
il codice del derotatore che si intende utilizzare. Il setup viene eseguito con il comando derotatorSetup:
> derotatorSetup=CODE
I codici sono i medesimi che vengono utilizzati per effettuare il setup dell’antenna. Ad esempio, se si vuole
utilizzare il derotatore del ricevitore in banda K:
> derotatorSetup=KKG
Note:
Quando viene eseguito il setup del telescopio viene automaticamente eseguito anche il setup del
DewarPositioner. In altre parole, quando viene dato il comando setupKKG, questo esegue a sua volta
anche derotatorSetup=KKG.
Note: Anche il receiverSetup=KKG fa il derotatorSetup=KKG?
Al termine del setup il derotatore sarà pronto per essere utilizzato. Il comando derotatorGetActualSetup
restituisce il setup attuale, mentre il comando derotatorIsReady ci dice se il derotatore è pronto per essere
movimentato:
> derotatorGetActualSetup
KKG
> derotatorIsReady
True
Durante il setup al derotatore viene comandata la posizione 0, che è quella scelta per l’allineamento iniziale.
Possiamo verificarlo con il comando derotatorGetPosition:
> derotatorGetPosition
0.0084d
Note: Dire che e’ normale che il valore restituito non e’ 0
Ad esempio, per il il derotatore del ricevitore in banda K la posizione iniziale è quella in cui i tre feed 1, 0, 4
sono paralleli all’orizzonte, con il feed 1 a est. Il setup infine imposta i valori di default per la configurazione e la
modalità di riavvolgimento:
3.4. Nuraghe components API
15
> derotatorGetConfiguration
FIXED
> derotatorGetRewindingMode
AUTO
Parleremo delle configurazioni e del riavvolgimento nelle prossime sezioni.
Configurazione
Il DewarPositioner ha cinque configurazioni: fixed, best space coverage, optimized, aligned e custom. Il comando derotatorSetConfiguration consente all’utente di impostare la configurazione desiderata, mentre
il comando derotatorGetConfiguration di leggerla:
> derotatorSetConfiguration=FIXED
FIXED
BSC
> derotatorSetConfiguration=CUSTOM
CUSTOM
Le configurazioni OPTIMIZED e ALIGNED non sono al momento disponibili:
> derotatorSetConfiguration=OPTIMIZED
Error - configuration OPTIMIZED not available
> derotatorSetConfiguration=ALIGNED
Error - configuration ALIGNED not available
Vediamo ora nel dettaglio le varie configurazioni, suddividendole in statiche e dinamiche.
Configurazioni statiche Nelle configurazioni statiche la posizione del derotatore non cambia al variare della
posizione dell’antenna o dell’asse di scansione.
Configurazione fixed In questa configurazione, che è quella che viene impostata come default dal setup, la
posizione del derotatore viene mantenuta fissa al variare della posizione dell’antenna, e questo è il motivo per cui
le è stato assegnato il codice identificativo FIXED.
Nella configurazione FIXED è possibile impostare la posizione del derotatore utilizzando il comando
derotatorSetPosition:
> derotatorSetPosition=30d
30d
Esempio di 𝑎2 .
Se il derotatore si trova in una certa posizione Px e viene impostata la modalità FIXED, viene tenuta la posizione
Px. Il derotatore quindi non viene riportato in posizione di zero sinchè non viene comandata una nuova posizione
con derotatorSetPosition:
50d
FIXED
50d
16
10d
Configurazioni dinamiche Nelle configurazioni statiche la posizione del derotatore non viene aggiornata al
variare della posizione dell’antenna. Nelle configurazioni dinamiche invece il DewarPositioner aggiorna la
posizione del derotatore in funzione della posizione dell’antenna, al fine di compensare l’angolo parallatico (più
un eventuale contributo del galactic parallactic angle, a seconda dell’asse di scansione).
Nelle configurazioni dinamiche la posizione del derotatore è data dalla seguente equazione:
P = Pis(AXIS) + Pip(AZ0,EL0) + Pdp(AZ,EL)
dove Pis è una posizione statica, mentre ... è la cosidetta funzione di derotazione, che serve per compensare
l’angolo parallattico (o il contributo del galactic parallactic angle).
Note: In alcune configurazioni (S-Band) il contributo Pip è nullo.
Ciò che differenzia una configurazione dinamica dall’altra è la posizione iniziale, mentre la funzione di derotazione non cambia, ed è data da:
• D = 0 quando AXIS è HOR_LON o HOR_LAT
• D = P(AZ, EL) quando AXIS è TRACK, EQ_LON, EQ_LAT o GCIRCLE
• D = G(AZ, EL) quando AXIS è GAL_LON o GAL_LAT
Note: Dire che nel caso di D=0 (HOR_LON e HOR_LAT), il valore di Pip è zero In generale, se D=N, con N
fisso indipendentemente da AXIS, EL e AZ, allora Pip=N
dove P(AZ, EL) è la funzione di compensazione dell’angolo parallatico, mentre G(AZ, EL) è quella di compensazione del contributo dovuto al galactic parallactic angle (GPA).
Quando viene impostata una configurazione, la posizione del derotatore non viene aggiornata, visto che non è
ancora noto l’asse di scansione. L’aggiornamento viene comandato da Nuraghe/ESCS nel momento in cui inizia
lo scan.
Configurazione best space coverage Il codice associatò a questa configurazione è BSC:
> derotatorSetConfiguration=BSC
BSC
Quando questa configurazione è attiva, il sistema prima posiziona il derotatore in una posizione iniziale che indicheremo con Pis (il pedice i sta per initial, mentre il secondo pedice indica il tipo di configurazione, e in
questo caso significa space), dopodiché aggiunge a Pis il contributo alla derotazione (che indicheremo con D)
dovuto alla compensazione dell’angolo parallatico più eventuale contributo del galactic parallactic angle, a seconda dell’asse di scansione scelto. La posizione del derotatore, che in questa configurazione indichiamo con Ps,
è quindi data dalla seguente equazione:
Ps = Pis(AXIS) + D(AZ, EL, AXIS) # BSC (Best Space Coverage)
Note: Per un dato derotatore, il valore della posizione iniziale Pi viene letto da una tabella di configurazione e
dipende dall’asse di scansione, per cui abbiamo utilizzato la notazione Pi(AXIS) per indicare che Pi è funzione
dell’asse. Allo stesso modo, la funzione di compensazione dell’angolo (parallatico più eventuale contributo del
GPA) dipende dai valori dell’azimuth, dell’elevazione e dell’asse di scansione, per cui la abbiamo indicata con
D(AZ, EL, AXIS).
I feed vengono disposti in modo tale da avere la miglior copertura spaziale della sorgente durante una scansione.
Tipicamente la miglior copertura viene ottenuta equispaziando, quando possibile, i beam nella direzione ortogo-
3.4. Nuraghe components API
17
nale a quella di scansione (se si sta facendo una scansione in azimuth i feed vengono equispaziati in elevazione,
in modo da ottimizzare la scansione dell’area osservata).
Quando è impostata la modalità BSC all’utente non è consentito il posizionamento del derotatore:
> derotatorSetConfiguration=BSC
Error - setPosition() not allowed in BSC configuration
In questa modalità il set di feed posizionati in modo da garantire la massima copertura spaziale sono stabilti a priori
(ad esempio per il banda K sono i feed 1, 0 e 4), e questo significa che la configurazione BSC non è ottimizzata
per garantire la massima escursione del derotatore.
Configurazione optimized Questa configurazione è analoga alla best space coverage ma a differenza di
quest’ultima, all’inizio di ogni scan la posizione del derotatore viene calcolata oltre che per ottenere la massima
copertura spaziale del multifeed lungo l’asse di scansione, anche per massimizzare la durata dello scan prima
che si renda necessario riavvolgere, per cui la posizione iniziale va scelta in modo che il set di feed garantisca la
massima copertura spaziale durante lo scan, e che sia tale da essere la più vicina possibile a uno dei fine corsa del
derotatore (quello dal quale ci si allontana durante lo scan).
La configurazione optimized è identificata con il codice OPTIMIZED:
OPTIMIZED
Quando è impostata la modalità OPTIMIZED all’utente non è consentito il posizionamento del derotatore:
Error - setPosition() not allowed in OPTIMIZED configuration
Configurazione aligned In questa configurazione, il cui codice identificativo è ALIGNED, viene scelto il set di
feed che si vuole allineare con l’asse di scansione. In Nuraghe/ESCS vi sarà una tabella che riporterà, per ogni
derotatore, i possibili set. La posizione del derotatore è data da:
Pa = Pia(AXIS) + D(AZ, EL, AXIS)
Attention: Se il derotatore non compre un angolo di almento 360°, non è detto che sia possibile allineare un
certo set di feed con un dato asse. In generale però se non è possibile allinearli con un asse, è probabile che li
si possa allineare con quello ortogonale.
Rispetto alle altre configurazioni dinamiche, nella configurazione aligned vi è un ulteriore comando da utilizzare,
chiamato derotatorSetAlignment, che prende come argomento una stringa identificativa dei feed che si
vuole allineare. Nella stringa i feed devono essere separati da un segno meno:
> derotatorSetConfiguration=ALIGNED
> derotatorSetAlignment=0-4
In questo caso viene scelto il set a cui appartengono i feed 0 e 4 (ad esempio, nel caso del banda K verrebbe scelto
il set {1, 0, 4}).
Note: Se non viene scelto un allineamento, allora viene utilizzato un allineamento di default (nel caso del banda
K è quello {1, 0, 4}).
Concludiamo dicendo che così come per la configurazione BSC e OPTIMIZED, anche la ALIGNED non consente
l’utilizzo del comando derotatorSetPosition.
18
Configurazione custom In questa configurazione la posizione iniziale può essere impostata dall’utente, e per
tale motivo a questa configurazione è stato assegnato il codice identificativo CUSTOM. La posizione del derotatore
è data da:
Pc = Pic + D(AZ, EL, AXIS)
Rispetto ai casi di configurazione dinamica appena visti, nella modalità custom è necessario specificare la posizione iniziale, altrimenti verrà utilizzata come Pic la posizione attuale. Ad esempio, se si vuole avere una
posizione iniziale di 30°:
> derotatorSetConfiguration=CUSTOM
Come al solito l’aggiornamento viene avviato da Nuraghe/ESCS nel momento in cui viene comandata la scansione
lundo un dato asse.
Interrompere l’aggiornamento Se si vuole interrompere l’aggiornamento della posizione, si deve impostare la
configurazione fixed. In questo caso il derotatore si fermerà all’ultima posizione comandata.
Descrizione delle API
Di seguito l’elenco completo dei metodi:
setup(CODE) # CODE: KKG, ...
getActualSetup()
getCommandedSetup()
isReady()
isConfigured()
park()
setPosition(POSITION)
getPosition()
setConfiguration(CODE) # CODE: FIXED, BSC, ...
clearConfiguration()
getConfiguration()
startUpdating(AXIS, AZ_SECTION)
stopUpdating()
isTracking()
isUpdating()
isSlewing()
setRewindingMode(MODE) # MODE: MANUAL or AUTO (default)
clearRewindingMode()
setAutoRewindingFeeds(NUMBER_OF_FEEDS)
getRewindingMode()
rewind(NUMBER_OF_FEEDS)
isRewindingRequired()
isRewinding()
getStatus() # Restituisce lo status pubblicato dal NC
... # TODO
3.5 Protocols
Abstract
This section lists some of the protocols we use to communicate to the hardware. If you want to integrate
a device in Nuraghe (a backend, a receiver, etc.), you should read this document in order to find for for a
protocol to choice. If either your device is not listen in this document or for technical reasons your hardware
does not suit the protocols listed here, then please do not go ahead on your own initiative but please, contact
the Project manager or the Core developers.
3.5. Protocols
19
Contents:
3.5.1 Backend protocols
Scrivo in italiano che facciamo prima, poi quando ci siamo accordati traduco e scrivo il documento finale.
Introduzione
Lo scopo è definire un protocollo per comunicare con il sistema ROACH2 (d’ora in avanti SR2), ovvero il sistema
che prende in ingresso delle richieste, esegue delle azioni sulla ROACH2 e da indietro una risposta.
La comunicazione non prevede uno scambio di grandi quantità di informazioni. I dati infatti abbiamo detto che
verranno scritti direttamente dal SR2, il quale recupera le informazioni dell’antenna e il relativo timestamp da un
FITS appositamente scritto da Nuraghe. Cio’ significa che possiamo utilizzare un protocollo testuale.
Detto ciò, l’idea è qualla di definire un protocollo generico, in modo da scrivere la libreria una volta, e utilizzarla
anche per futuri backend o altri dispositivi che lo implementano. Ci occorre:
1. impostare qualcosa (set)
2. leggere qualcosa (get)
Request-response socket
Possiamo definire dei caratteri di inizio e fine comando. In più potrebbe essere utile indicare anche un ID del
comando. Con un esempio ci capiamo meglio. Consideriamo il metodo .setSection():
void setSection(
in long input,
in double freq,
in double bw,
in long feed,
in long pol,
in double sr,
in long bins
);
Supponiamo di chiamare questo metodo nel seguente modo:
setSection(11, 22, 33, 44, 55, 66, 77);
Questa chiamata viene tradotta nel seguente comando, da inviare al sistema backend:
#set:99:section:11,22,33,44,55,66,77\n
Dove 99 è l’ID del comando. La risposta relativa potrebbe essere:
#set:99:OK\n
#set:99:KO:Error message here\n
Note: Può essere utile definire gruppi di parametri? Ad esempio, nel caso in cui un metodo nella IDL definisca
una sequenza, come in questo caso:
setPosition(doubleSeq position, time);
se la posizione è (1, 1, 1), e il tempo è 0:
#set:100:position:[1,1,1],0\n
Se vogliamo ottenere una richiesta, usiamo un comando getSomethig(t) che restituisce il valore della
grandezza something al tempo t:
20
#get:101:something:t\n
La risposta potrebbe esser:
#get:101:timestamp,par1,par2,par3\n
Dove timestamp è il tempo di processamento della risposta da parte del sistema backend.
HTTP
Oppure, visto che in questo modo stiamo praticamente reinventando la ruota, che dite se usiamo direttamente
qualcosa di pronto, come HTTP? In questo caso abbiamo un sacco di opzioni e tutto pronto (anche lato server, ci
sarebbe solo da mappare le API REST agli script eseguiti dal SR2).
Inoltre avremo multiclient, e potremmo scambiare anche informazioni complesse, di più alto livello, come ad
esempio un content-type application/json. Lo svantaggio rispetto al primo caso è che è più pesante.
3.6 HOWTOs
Contents:
3.6.1 Test Driven Development (TDD) in Nuraghe
Section author: Marco Buttu, Marco Bartolini
Abstract
Here the abstract...
Contents:
Introduction
Nuraghe TDD cycle
From functionals to unit (summary of Write the component).
Where to put the tests
The test component directory:
$ tree test/
...
The test/functional directory and its sub-directories contain the functional tests and, as you probably figured out,
the api sub-directory hosts the API while the commands one hosts the command tests.
Note: Do not warry if you do not now that terminology, in the next sections we will give a definition and an
explanation of every of these words.
You can create that directory using the getTemplateForTest command. For instance, if you want to create
that directory for the DewarPositioner component:
3.6. HOWTOs
21
$ cd $NURAGHE_ROOT/Common/Servers/DewarPositionier
$ ls
doc srt
$ getTemplateForTest
$ ls
doc srt test
Functional testing
A test is called functional when it aims to verify the component behavior from the user point of view. The
components usually have two kind of users:
1. operators (human beings) who interact with the component through the operator input console
2. programs (clients or other components) that interact with the component by using its API (calling its
methods)
In the first case, we have to verify the behavior of the commands the operator sends to our component. In other
words, we we have to test the component command() method. We call this kind of functiona tests by the name
of command tests.
In the second case, we have to verify all the other methods defined in component IDL interface. We should prove
they give the expected results and when required, they raise the expected exceptions. We give this functional tests
the name of API tests.
Writing functional test in Python is really straightforward, and of course it is easier than C++, so we will use it in
this section. In the Python standard library there is a unit test framework, called unittest. Unfortunatly the Python
version provied by ACS-8.2 is the old Python 2.5, and its unittest module does not have a lot of useful assertions.
The solution is to install a third part module, unittest2, in order to use it in place of the standard library unittest
module.
Let’s have a real example: the DewarPositioner component. We will see both how to write a command and an
API test (one method and one property).
Command tests
In this section will test the derotatorSetup command. As we said before, we have to think from the user (the
astronomer in that case) point of view. So, let’s see what the user wants to obtain after executing the command
from the operatorInput console:
>
Well, we are ready to write our functional test. The file and the methods must start with test, so we can create a
file called test_derotatorSetup.py inside the functional/commands directory:
# File: test/functional/commands/test_derotatorSetup.py
import unittest2
from DewarPositioner.DewarPositionerImpl import DewarPositionerImpl
class DerotatorSetupCmdTest(unittest2.TestCase):
def test_proper_setup(self):
dp = DewarPositionerImpl()
success, answer = dp.command(’derotatorSetup=KKG’)
self.assertTrue(success) # assertEqual(success, True)
self.assertEqual(answer, ’’)
22
if __name__ == ’__main__’:
unittest2.main()
In case of wrong setup code, the command returns an error message:
> derotatorSetup=GIGIRIVA
Error...
We can add the related test, called test_wrong_setup():
# File: test/functional/commands/test_derotatorSetup.py
import unittest2
class DerotatorSetupCmdTest(unittest2.TestCase):
def setUp(self):
self.dp = DewarPositionerImpl()
success, answer = self.dp.command(’derotatorSetup=KKG’)
self.assertTrue(success)
def test_wrong_setup(self):
success, answer = self.dp.command(’derotatorSetup=GIGIRIVA’)
self.assertFalse(success)
self.assertTrue(answer.startswith(’Error’))
if __name__ == ’__main__’:
unittest2.main()
The setUp() method is called before each test.
Although the DerotatorSetupCmdTest looks easy, it is very effective because now we can modify the
component and run the tests. If it passes, we did not break the command.
To verify the whole setup behavior, we should write an API test, as described in the section API tests.
Guidelines The derotatorGetActualSetup command prints the actual DewarPositioner setup:
none
KKG
So we can think to write the test_proper_setup() in the following way:
success, answer = self.dp.command(’derotatorSetup=KKG’)
success, answer = self.dp.command(’derotatorGetActualSetup’)
self.assertEqual(answer, ’KKG’)
That’s not a good idea, because the tests must be as simple as possible, because we want to take easy both their
maintenance and readability. We have to avoide code duplication between tests and ideally, each test should have
only one assertion. As a rule ot thumb, we can think a long test is an indication of code smell.
Our first version of test_proper_setup() does already everything we need, because it check the
derotatorSetup command:
3.6. HOWTOs
23
• exists
• is correctly executed in case of right setup code
• prints an error message in case of failure
In that case, the problem of the duplication of code between tests can happen only if we write the code before the
test. In fact, if the component code is not yet written, we start by writing the setup test, and that test must check
only the derotatorSetup command. Once the test is written, we write the setup() method and then the
derotatorSetup command. Our test can not pass if we put a derotatorGetActualSetup check inside
it, because the getActualSetup() method and the related derotatorGetActualSetup command do
not exist. That’s one of the reasons we have to follow the TDD approach. Another one is the TDD ensures a
bigger code coverage than a testing after coding approach.
So, if we want to verify the derotatorGetActualSetup returns the KKG code, first of all we have to write
the test:
# File: test/functional/commands/test_derotatorGetActualSetup.py
import unittest2
class DerotatorGetActualSetupCmdTest(unittest2.TestCase):
def test_rigth_code(self):
dp = DewarPositionerImpl()
dp.command(’derotatorSetup=KKG’)
success, answer = dp.command(’derotatorGetActualSetup’)
self.assertEqual(success, True)
self.assertEqual(answer, ’KKG’)
if __name__ == ’__main__’:
unittest2.main()
Now we have to verify the test does not pass (of course, if it pass there is a problem in the test itself). That is
called an expected failure. After we get an expected failure, we can start writing the code.
API tests
In this section we will see how to write an API test, for instance a test for the DewarPositioner.setup()
method. Here is its IDL interface:
/* Take a configuration code and configure the component
*
* This method takes a configuration code, gets the corresponding
* derotator component reference and initializes the DewarPositioner.
* For instance, by giving the code KKG, the DewarPositioner gets the
* KBandDerotator reference and performs its setup. It also sets the
* rewinding mode and configuration default values as:
*
setConfiguration(’FIXED’)
*
setRewindingMode(’AUTO’)
*
*
* @param code the setup mode (for instance: LLP, KKG, CCB, ecc.)
* @throw ComponentErrors::ComponentErrorsEx in case of wrong
* configuration code or derotator component not available
*/
void setup(in string code) raises (ComponentErrors::ComponentErrorsEx);
Unit testing
The goal.
24
C++
Section author: Marco Bartolini
Python
3.6.2 How to install Nuraghe
Section author: Marco Bartolini
Abstract
Here the abstract...
Contents:
Nuraghe provisioning
All the root stuffs required to install packages, ACS and libraries.
Nuraghe deployment
Environment and installation
3.6.3 How to integrate a device in Nuraghe
The goal of this document is to explain the steps you have to follow if you want to integrate a device (a backend,
a receiver, etc.) in Nuraghe. It is really easy, just follow this two steps:
• contact the project manager in order to plan the component development
• from your side, implement the protocol related to your device
That’s all.
3.6. HOWTOs
25
26
CHAPTER 4
Nuraghe control software team
Brief desc.
4.1 Core developers
Leading Nuraghe is a small team of core developers, that is people who have made and continue to make a
significant contribution to the project, and have a good understanding not only of the code, but also the longerterm aims and directions of the project:
• Marco Bartolini
• Marco Buttu
• Carlo Migoni
• Andrea Orlati
• Sergio Poppi
4.2 Astonomical referees
Description of abstonomical referee:
• Sergio Poppi
• Simona Righini
4.3 Hardware and network support
Brief desc of this activity:
• Antonietta Fara
4.4 Contributors
Anyone can be a contributor to Nuraghe project. Being a contributor simply means that you take an interest in
the project and contribute in some way, ranging from asking sensible questions (which documents the project and
provides feedback to developers) through to providing new features as components, patches or user’s specifications.
If you become a valuable contributor to the project, you may well be invited by the core developer to become
member of the team.
27
Here is the list of Nuraghe contributors:
• Andrea Melis
4.5 Responsibilities
4.5.1 Project manager
The project manager heads the whole Nuraghe project and has in charge the software releasing. This responsibility
is currently assegned to Andrea Orlati.
4.5.2 Support scientist
The support scientist is responsible for every communication related to Nuraghe changes that affect the users.
This responsibility is currently assegned to:
• Medicina: Simona Righini
• Noto: ?
• Sardinia Radio Telescope: Sergio Poppi
4.5.3 Observation manager
The observation manager is responsible for to the observations with Nuraghe:
• Medicina: Andrea Orlati
• Noto: ?
• Sardinia Radio Telescope: Carlo Migoni
4.5.4 User’s documentation
The user’s documentation manager is responsible for the User’s guide: Observing with Nuraghe contents. This
responsibility is currently assegned to Simona Righini.
4.5.5 Development
The development manager is responsible for the Development guide contents, for the software (and documentation) repository and for the whole development process. This responsibility is currently assigned to Marco Buttu.
4.5.6 Deploying and continuous integration
This responsibility is currently assigned to Marco Bartolini.
4.5.7 Provisioning
This responsibility is currently assigned to Antonietta Fara.
28
Chapter 4. Nuraghe control software team
4.6 People involved in the project
4.6.1 Marco Bartolini
Marco...
4.6.2 Marco Buttu
Marco Buttu works for the Osservatorio Astronomico di Cagliari, and he is a member of the Sardinia Radio
Telescope staff.
4.6.3 Carlo Migoni
Carlo works for the Osservatorio Astronomico di Cagliari, and he is a member of the Sardinia Radio Telescope
staff.
4.6.4 Antonietta Fara
Antonietta...
4.6.5 Andrea Melis
Andrea Melis...
4.6.6 Andrea Orlati
Andrea...
4.6.7 Sergio Poppi
Sergio works for the Osservatorio Astronomico di Cagliari, and he is a member of the Sardinia Radio Telescope
staff.
4.6.8 Simona Righini
Simona: user manual, software specification definition, ...
4.6. People involved in the project
29
30
Chapter 4. Nuraghe control software team
CHAPTER 5
Indices and tables
• genindex
• search
31
32
Chapter 5. Indices and tables
Index
A
actualSetup, 5
E
emergency stop, 5
F
failure, 5
G
GFR, 5
M
M3R, 5
minor servo, 5
MSCU, 5
P
PFP, 5
R
reset, 5
S
servoSetup, 5
setupCCB, 5
setupKKG, 5
setupLLP, 5
SRP, 5
U
unknown, 5
33

Nuraghe Documentation

Transcript

Documenti analoghi

Nuraghe Santa Vittoria

Il gruppo “Su Nuraghe”, ambasciatore in Europa del

i segreti del nuraghe "perra de part `e susu"

Programma di attività del Circolo Sardo Nuraghe di Losanna per il

William Shakespeare, Sonnet LXXIII Traduzione in sardo di

169 del 1° ottobre

simbolo

Il Nuraghe is Paras