The ALMA Common Software: a developer friendly CORBA-based framework G.Chiozzi d, B.Jeram a, H.Sommer a, A.Caproni e, M.Pesko bc, M.Sekoranja b, K.Zagar c, D.W.Fugate d, P.Di Marcantonio e, R.Cirami e a ESO b JSI c Cosylab d U.Calgary e INAF-AOT

2SPIE 22 June 2004ALMA Common Software Contents ACS Objectives What since 2002? Development lifecycle examples –Telescope mount –Pipeline Future directions The ACS community: projects and users Conclusions Questions & Answers

3SPIE 22 June 2004ALMA Common Software ACS Objectives … much was said already in the previous presentations The strategy to provide common features to our users is: Use as much as possible open-source tools, instead of implementing things. CORBA is now the core middleware Identify the best way to perform a certain task among the many possibilities Wrap with convenience and “uniforming” APIs

4SPIE 22 June 2004ALMA Common Software What since 2002? In 2002 our main concern was to support TICS development Since then: –TICS has been used in “operation” to evaluate the antennas –Many subsystems have done substantial development based on ACS –We had 2 integrations of the complete ALMA Software –We have changed focus on providing support for higher level software, pipeline and data reduction Change is built into the ACS development process

5SPIE 22 June 2004ALMA Common Software A developer’s life Instead of listing ACS features, let’s look at a couple of examples of the process followed by a developer using ACS as the basic application framework. But do not forget that a developer’s life depend’s very much on…..

6SPIE 22 June 2004ALMA Common Software Mount: problem definition –Simple motorized mount controlled via serial port (amateur telescope) –Control and integrate in an ACS based system –Position the mount in (az,el) –Read the actual position from encoder via serial commands

7SPIE 22 June 2004ALMA Common Software Mount: 1- interface definition The contract with external users CORBA Interface Definition Language (IDL): –Operations –Properties –(Events) –(Used interfaces) interface Mount : ACS::CharacteristicComponent { void move(in double az, in double elev); attribute ACS::ROdouble cmdAz; attribute ACS::ROdouble cmdEl; attribute ACS::ROdouble actAz; attribute ACS::ROdouble actEl; };

8SPIE 22 June 2004ALMA Common Software Mount: 2- select impl. language Clients are not concerned A mock up can be easily implemented in Python We want to use the ACS Component/Property/Characteristic design pattern: –C++ –Java We can reuse a Serial DevIO already implemented in C++ by somebody else. We select C++ for our implementation!

9SPIE 22 June 2004ALMA Common Software Mount: 3- write the impl. Implement MountImpl class that inherits from: –CORBA Skeleton –Base ACS implementation classes Implement move() method using properties. Until now we are independent from the HW Use/implement the proper DevIO class to access the HW

10SPIE 22 June 2004ALMA Common Software Mount: 4 – write the CDB We need to write the Configuration Database for: Properties: –Units –Ranges –Archiving Deployment: –Where –What implementation

11SPIE 22 June 2004ALMA Common Software Mount: what have we got? Many things, for example: Control our device with generic GUIs like Object Explorer (OE) Store logs in central logging system Log telemetry information periodically Generate alarms if the mount reaches limits Write Python scripts or Java clients Control remotely using OE from Web Start

12SPIE 22 June 2004ALMA Common Software Pipeline: problem definition Implement a pipeline recipe We can identify two levels of processing: –Hi level processing algorithm: Composed of elementary steps Very dynamic, often changing with time Typically implemented by astronomers –Low level, hi performance algorithms Efficient deployment and load balancing requirements Often using legacy (Fortran) fast and reliable subroutines

13SPIE 22 June 2004ALMA Common Software Pipeline: recipe implementation Astronomer/developer follows a simpler path than the developer of the Mount: –Define the IDL interface. Normally, just pipeline activation method –Implement the component in Python. This executes the steps by calling other components and passing them data –Component deeployment would be dynamic. Probably no CDB needed.

14SPIE 22 June 2004ALMA Common Software Pipeline: what have we got? Developers in the two categories are not required to have the same qualification. Recipe and algorithms are decoupled Deployment and scalability are delegated to the Manager at run time.

15SPIE 22 June 2004ALMA Common Software Future directions Bulk data transfer, HTTP and protocols, Alarm System and other planned packages Optimization, scalability, performance, security Modular installation –Take only what you need Warranty backward compatibility ! New trends: –IDL simulator –Code generation from UML (Data model, State Machines, Components code)

16SPIE 22 June 2004ALMA Common Software State Machine code generation Open ArchitectureWare project:

17SPIE 22 June 2004ALMA Common Software ACS installations and projects

18SPIE 22 June 2004ALMA Common Software Conclusion Fast development since SPIE 2002 Change of focus from Control to High Level software Already proven as basis for the first two releases of the integrated ALMA software system Open source (LGPL license) and based on free development tools and ORBs Growing community of users outside ALMA

19SPIE 22 June 2004ALMA Common Software Questions (& Answers) ACS Papers: –H.Sommer, G.Chiozzi, “Container-component model and XML in ALMA ACS”, ACS Posters: –D.W.Fugate, “A CORBA event system for ALMA common software”, –P.Di Marcantonio, R.Cirami, G.Chiozzi, “ACS sampling system: design, implementation and performance evaluation”, Short Course: “An Introduction to Scalable Frameworks for Observatory Software Infrastructure, G.Chiozzi, Wednesday Cosylab exhibition desk (510)