...

{+}\[RD01\]+

{+}\[RD01\]+

...

This document describes the architecture for the ALMA Common Software (ACS), taking as applicable the requirements specified in the ALMA Common Software Technical Requirements document

{+}\[RD01\]+

and the ALMA Software Architecture

{+}\[RD33\]{+}

. This document provides a complete picture of the desired ACS functionality for the entire development phase, but individual concepts and features will be developed incrementally over a number of releases, according to the ALMA Common Software Development Plan

+\[RD32\]{+}

. For each release, a detailed plan is developed, identifying the components to be added or revised. Development priorities will be discussed with the community of users during the planning phase of each release.
This issue of the Architecture takes into account the development of the ALMA Test Interferometer Control Software, the work done by the ALMA High Level Analysis team and the requests to ACS from higher level sub-systems as appearing in their respective documents and at the ACS planning meetings. In particular contains extensions that satisfy the needs of data flow software, pipeline, offline or proposal preparation. With version A of this document, it has been decided to use ACS also as the underlying framework for the offline data reduction package (AIPS++). This requirement widens the scope of ACS and introducing new requirements that cover in particular the following areas:

...

ACS is located in between the ALMA application software and other basic commercial or shared software on top of the operating systems and provides a generalized common interface between applications and the hardware in order to facilitate the implementation and the integration in the system of new hardware and software components.
ACS provides basic software services common to the various applications (like antenna control, correlator software, data pipelining)

{+}\[RD01 - 3.1.1. Scope\]+

and consists of software developed specifically for ACS and as well of OS builds and commercial device drivers. All code specifically developed for ACS is under the GNU Lesser General Public License (LGPL)

+\[RD31\]{+}

. Commercial and off the shelf packages are subject to their specific license agreement.
ACS is designed to offer a clear path for the implementation of applications, with the goal of obtaining implicit conformity to design standards and maintainable software

{+}\[RD01 - 3.1.2. Design\]{+}

. The use of ACS software is mandatory in all applications, except when the requested functionality is not provided by ACS

+\[RD01 - 3.1.3. Use\]{+}

. Motivated exceptions (for example based on reuse considerations) have to be discussed and approved on a case by case basis.
The main users of ACS will be the developers of ALMA applications. The generic tools and GUIs provided by ACS to access logs, Configuration Database, active objects and other components of the system will be also used by operators and maintenance staff to perform routine maintenance operations

{+}\[RD01 - 3.2.1. Users\]{+}

.
This document identifies the main packages that will be part of ACS and their high level interrelations. For each package, a section in this document respectively discusses the requirements to clarify them and presents an architectural concept.
Requirements are traced back to the ALMA Common Software Technical Requirements document

{+}\[RD01\]+

whenever they are referenced. An ACS Requirements Compliance Table is maintained in the ACS Software Development Plan

{+}\[RD32\]{+}

.
The concept illustrated here is based on the use of CORBA and takes into account knowledge of various control software projects based on CORBA in the astronomical and High Energy Physics communities, like SOFIA

{+}\[RD10\]{+}

, GTC-Spain

{+}\[RD11\]{+}

, ESRFGrenoble

{+}\[RD03\]{+}

, ANKA-Kalsruhe

{+}\[RD04\]+

etc. A lot of experience has been accumulated in the past years of ACS development, in particular for what concerns the application of these concepts to high level applications and in particular pipeline, offline data reduction and observation preparation. A lot of discussions with the AIPS++ team have helped shaping ACS based on the requirements in these application domains. It has been an initial and explicit decision of the ALMA project to use CORBA technology and at the same time to share software rather than to re-invent it. It is up to documents like this to provide elements to confirm the initial choice of CORBA as adequate.
The reasons for using CORBA are in short: Object Orientation, support for distributed systems, platform independence, it is a communication standard, it provides a variety of services.

...

A reference layout for the system is provided by the ALMA Software
Architecture

{+}\[RD33\]{+}

, as required by

{+}\[RD01 - 2.3. Reference Architecture\]{+}

. The Architecture of the Test Interferometer is described in the TICS Design Concept document

{+}\[RD26\]{+}

.
For the purposes of this document a distributed architecture based on computers at the individual antennas and a number of central computers, connected by an high speed backbone

{+}\[RD01 - 10.4.3. LAN\]+

+\[RD01 - 10.4.4. Backbone\]+

+\[RD01 - 10.5.11. LAN\]{+}

, is assumed

{+}\[RD02\]{+}

.
At both the antenna and the central control building there will be not only Ethernet LAN connectivity but also a Field-bus

{+}\[RD01 - 10.4.5 Field-bus\]+

(the AMB)

+\[RD01 - 10.5.12. Field-bus\]+

connected to various intelligent devices. The fact that the Antenna controller and all or part of these Devices is on Field-bus or LANs shall not make any difference in terms of the architecture proposed here.
Pipeline, offline data reduction and other high level applications are also assumed to be distributed over many hosts, with the need or deploying CPU intensive applications dynamically based on the available resources.

Reference Documents

The reference documents contain background information required to fully understand the structure of this document, the terminology used, the software environment in which ALMA shall be integrated and the interface characteristics to the external systems. 
The following documents are referenced in this document. 
*\[RD01\] ALMA Common Software Technical Requirements{*}, COMP-
70.25.00.00-003-A-SPE, G.Raffi, B.Glendenning, J.Schwarz ([<span style="color: #0000ff">{+}<a href="http://www.eso.org/+" class="external-link" rel="nofollow">http://www.eso.org/+</a></span>|http://www.eso.org/projects/alma/develop/acs/MilestoneReleases/Phase1/ACSTechReqs/Issue1.0/2000-06-05.pdf]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">~almamgr/AlmaAcs/MilestoneReleases/Phase1/ACSTechReqs/Issue1.0/2000-06</span></span>|http://www.eso.org/projects/alma/develop/acs/MilestoneReleases/Phase1/ACSTechReqs/Issue1.0/2000-06-05.pdf][<span style="color: #0000ff"><span style="text-decoration: underline; ">05.pdf</span></span>|http://www.eso.org/projects/alma/develop/acs/MilestoneReleases/Phase1/ACSTechReqs/Issue1.0/2000-06-05.pdf][)|http://www.eso.org/projects/alma/develop/acs/MilestoneReleases/Phase1/ACSTechReqs/Issue1.0/2000-06-05.pdf] 
*\[RD02\] ALMA Construction Project Book{*}, Version 5.00, 2001-08-01 [(|http://www.mma.nrao.edu/projectbk/construction/][<span style="color: #0000ff">{+}<a href="http://www.mma.nrao.edu/projectbk/construction/+" class="external-link" rel="nofollow">http://www.mma.nrao.edu/projectbk/construction/+</a></span>|http://www.mma.nrao.edu/projectbk/construction/][)|http://www.mma.nrao.edu/projectbk/construction/] 
*\[RD03\]* *TANGO - an object oriented control system based on CORBA* 

• Wiki Markup

  J.M.Chaize et al., ICALEPCS'99 Conference, Trieste, IT, 1999 [(|http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/wa2i01.pdf][<span style="color: #0000ff">{+}<a href="http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/wa2i01.pdf+" class="external-link" rel="nofollow">http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/wa2i01.pdf+</a></span>|http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/wa2i01.pdf][)|http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/wa2i01.pdf] *\[RD04\]* *Implementing Distributed Controlled Objects with CORBA* - M.Plesko, PCs and Particle Accelerator Control Workshop, DESY, Hamburg, 1996 (See [<span style="color: #0000ff">{+}<a href="http://kgb.ijs.si/KGB/accomplishments_articles.php+" class="external-link" rel="nofollow">http://kgb.ijs.si/KGB/accomplishments_articles.php+</a></span>|http://kgb.ijs.si/KGB/accomplishments_articles.php][ |http://kgb.ijs.si/KGB/accomplishments_articles.php]for this and other related papers). *\[RD05\]* *SOSH Conventions for Control* - F.DiMajoC.Watson, Software Sharing (SOSH) for Accelerators & Physics Detectors ([<span style="color: #0000ff">{+}<a href="http://www.jlab.org/sosh/+" class="external-link" rel="nofollow">http://www.jlab.org/sosh/+</a></span>|http://www.jlab.org/sosh/][)|http://www.jlab.org/sosh/] *\[RD06\] Java Home Page* - ([<span style="color: #0000ff">{+}<a href="http://java.sun.com/+" class="external-link" rel="nofollow">http://java.sun.com/+</a></span>|http://java.sun.com/][)|http://java.sun.com/] *\[RD07\]* *Real-time CORBA with TAO (the ACE ORB)* - [(|http://www.cs.wustl.edu/~schmidt/TAO.html][<span style="color: #0000ff">{+}<a href="http://www.cs.wustl.edu/~schmidt/TAO.html+" class="external-link" rel="nofollow">http://www.cs.wustl.edu/~schmidt/TAO.html+</a></span>|http://www.cs.wustl.edu/~schmidt/TAO.html][)|http://www.cs.wustl.edu/~schmidt/TAO.html] *\[RD08\] ObjectStore home page* - ([<span style="color: #0000ff">{+}<a href="http://www.odi.com/objectstore/+" class="external-link" rel="nofollow">http://www.odi.com/objectstore/+</a></span>|http://www.odi.com/objectstore/][)|http://www.odi.com/objectstore/] *\[RD09\] MySQL home page* - ([<span style="color: #0000ff">{+}<a href="http://www.mysql.com+" class="external-link" rel="nofollow">http://www.mysql.com+</a></span>|http://www.mysql.com/][)|http://www.mysql.com/] *\[RD10\] SOFIA home page* - ([<span style="color: #0000ff">{+}<a href="http://sofia.arc.nasa.gov/+" class="external-link" rel="nofollow">http://sofia.arc.nasa.gov/+</a></span>|http://sofia.arc.nasa.gov/][)|http://sofia.arc.nasa.gov/] *\[RD11\]* *GTC home page* - ([<span style="color: #0000ff">{+}<a href="http://www.gtc.iac.es/+" class="external-link" rel="nofollow">http://www.gtc.iac.es/+</a></span>|http://www.gtc.iac.es/][)|http://www.gtc.iac.es/] *\[RD12\]* *ALMA Monitor and Control Bus, Interface* *Specification,* ALMAComputing Memo #7, M.Brooks, L.D'Addario,Rev.B 200102-05 *\[RD13\]* *National Instruments LabVIEW{*}- ([<span style="color: #0000ff">{+}<a href="http://www.ni.com/labview/+" class="external-link" rel="nofollow">http://www.ni.com/labview/+</a></span>|http://www.ni.com/labview/][)|http://www.ni.com/labview/] *\[RD14\] CORBA Telecom Log Service* - [(|http://www.omg.org/technology/documents/formal/telecom_log_service.htm][<span style="color: #0000ff">{+}<a href="http://www.omg.org/technology/documents/formal/telecom_log_service.htm+" class="external-link" rel="nofollow">http://www.omg.org/technology/documents/formal/telecom_log_service.htm+</a></span>|http://www.omg.org/technology/documents/formal/telecom_log_service.htm][)|http://www.omg.org/technology/documents/formal/telecom_log_service.htm] *\[RD15\] omniORB Home Page* - ([<span style="color: #0000ff">{+}<a href="http://www.uk.research.att.com/omniORB/+" class="external-link" rel="nofollow">http://www.uk.research.att.com/omniORB/+</a></span>|http://www.uk.research.att.com/omniORB/][)|http://www.uk.research.att.com/omniORB/] *\[RD16\]OpenOrb Home Page* - ([<span style="color: #0000ff">{+}<a href="http://openorb.sourceforge.net/+" class="external-link" rel="nofollow">http://openorb.sourceforge.net/+</a></span>|http://openorb.sourceforge.net/][)|http://openorb.sourceforge.net/] *\[RD17\]ALMA SE Practices - Software Development Process Methodology* *and Tools,* G.Chiozzi, R.Karban, P.Sivera - [(|http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE-SwDev.pdf][<span style="color: #0000ff">{+}<a href="http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE+" class="external-link" rel="nofollow">http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE+</a></span>|http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE-SwDev.pdf][<span style="color: #0000ff"><span style="text-decoration: underline; ">SwDev.pdf</span></span>|http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE-SwDev.pdf][)|http://www.mma.nrao.edu/development/computing/docs/joint/draft/SE-SwDev.pdf] *\[RD18\] eXtensible Markup Language Home Page -* [(|http://www.w3.org/XML/][<span style="color: #0000ff">{+}<a href="http://www.w3.org/XML/+" class="external-link" rel="nofollow">http://www.w3.org/XML/+</a></span>|http://www.w3.org/XML/][)|http://www.w3.org/XML/] *\[RD19\] CERN Laser project home page* ([<span style="color: #0000ff">{+}<a href="http://proj-laser.web.cern.ch/proj+" class="external-link" rel="nofollow">http://proj-laser.web.cern.ch/proj+</a></span>|http://proj-laser.web.cern.ch/proj-laser/][<span style="color: #0000ff"><span style="text-decoration: underline; ">laser/</span></span>|http://proj-laser.web.cern.ch/proj-laser/][)|http://proj-laser.web.cern.ch/proj-laser/] *\[RD20\] IBM DB2 Home Page* - ([<span style="color: #0000ff">{+}<a href="http://www-4.ibm.com/software/data/db2/+" class="external-link" rel="nofollow">http://www-4.ibm.com/software/data/db2/+</a></span>|http://www-4.ibm.com/software/data/db2/][)|http://www-4.ibm.com/software/data/db2/] *\[RD21\] ALMA ACS and AMS Kitt Peak 2000 Test* ,G.Chiozzi et al. [(|http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12-KP.pdf][<span style="color: #0000ff">{+}<a href="http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12+" class="external-link" rel="nofollow">http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12+</a></span>|http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12-KP.pdf][<span style="color: #0000ff"><span style="text-decoration: underline; ">KP.pdf</span></span>|http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12-KP.pdf][)|http://www.mma.nrao.edu/development/computing/docs/joint/notes/2000-12-KP.pdf] *\[RD22\]Design and Initial Implementation of Diagnostic and Error Reporting System of SMA{*}, SMA Technical Memo 132, Q.Zhang. *\[RD23\] The Adaptive Communication Environment (ACE) home page -* [(|http://www.cs.wustl.edu/~schmidt/ACE.html][<span style="color: #0000ff">{+}<a href="http://www.cs.wustl.edu/~schmidt/ACE.html+" class="external-link" rel="nofollow">http://www.cs.wustl.edu/~schmidt/ACE.html+</a></span>|http://www.cs.wustl.edu/~schmidt/ACE.html][)|http://www.cs.wustl.edu/~schmidt/ACE.html] *\[RD24\] Python language home page -* [(|http://www.python.org/][<span style="color: #0000ff">{+}<a href="http://www.python.org/+" class="external-link" rel="nofollow">http://www.python.org/+</a></span>|http://www.python.org/][)|http://www.python.org/] *\[RD25\] Home Page for the Official Tcl/Tk Contributed Sources Archive* - [(|http://www.neosoft.com/tcl/][<span style="color: #0000ff">{+}<a href="http://www.neosoft.com/tcl/+" class="external-link" rel="nofollow">http://www.neosoft.com/tcl/+</a></span>|http://www.neosoft.com/tcl/][)|http://www.neosoft.com/tcl/] *\[RD26\] Test Interferometer Control Software Design* *Concept{*}, B.Glendenning et al., DRAFT 2001-02-15 *\[RD27\] Advanced CORBA Programming with C++,{*}M.HenningS.Vinoski, Addison-Wesley, 1999 *\[RD28\] ALMA Software Glossary,* COMP-70.15.00.00-003-A-GEN [(|http://www.alma.nrao.edu/development/computing/docs/joint/draft/Glossary.htm][<span style="color: #0000ff">{+}<a href="http://www.alma.nrao.edu/development/computing/docs/joint/draft/Glossary.htm+" class="external-link" rel="nofollow">http://www.alma.nrao.edu/development/computing/docs/joint/draft/Glossary.htm+</a></span>|http://www.alma.nrao.edu/development/computing/docs/joint/draft/Glossary.htm] ) *\[RD29\] AMI/ACS Report{*}, R. Lemke, G. Chiozzi 2001-03-20 [(|http://www.eso.org./projects/alma/develop/acs/examples/amitest/AmiReport.pdf][<span style="color: #0000ff">{+}<a href="http://www.eso.org./projects/alma/develop/acs/examples/amitest/AmiReport.pdf+" class="external-link" rel="nofollow">http://www.eso.org./projects/alma/develop/acs/examples/amitest/AmiReport.pdf+</a></span>|http://www.eso.org./projects/alma/develop/acs/examples/amitest/AmiReport.pdf][)|http://www.eso.org./projects/alma/develop/acs/examples/amitest/AmiReport.pdf] *\[RD30\] ALMA Memo #298, Timing and Synchronization{*}, L. DÂ'Addario, 2000-03-09 ([<span style="color: #0000ff">{+}<a href="http://www.alma.nrao.edu/memos/html+" class="external-link" rel="nofollow">http://www.alma.nrao.edu/memos/html+</a></span>|http://www.alma.nrao.edu/memos/html-memos/alma298/memo298.pdf][<span style="color: #0000ff"><span style="text-decoration: underline; ">memos/alma298/memo298.pdf</span></span>|http://www.alma.nrao.edu/memos/html-memos/alma298/memo298.pdf][)|http://www.alma.nrao.edu/memos/html-memos/alma298/memo298.pdf] *\[RD31\] GNU Lesser General Public License (GPL)* [(|http://www.gnu.org/copyleft/lesser.html][<span style="color: #0000ff">{+}<a href="http://www.gnu.org/copyleft/lesser.html+" class="external-link" rel="nofollow">http://www.gnu.org/copyleft/lesser.html+</a></span>|http://www.gnu.org/copyleft/lesser.html][)|http://www.gnu.org/copyleft/lesser.html] *\[RD32\] ALMA Common Software Development Plan,* COMP-70.25.00.00001-C-PLA ([<span style="color: #0000ff">{+}<a href="http://www.eso.org/projects/alma/develop/acs/Plan/index.html+" class="external-link" rel="nofollow">http://www.eso.org/projects/alma/develop/acs/Plan/index.html+</a></span>|http://www.eso.org/projects/alma/develop/acs/Plan/index.html][)|http://www.eso.org/projects/alma/develop/acs/Plan/index.html] *\[RD33\] ALMA Software Architecture{*}, ALMA-70.15.00.00-001-I-GEN, J.Schwarz [(|http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/100017/d20021117183329/No/ALMASoftwareArchitecture.pdf][<span style="color: #0000ff">{+}<a href="http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/10+" class="external-link" rel="nofollow">http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/10+</a></span>|http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/100017/d20021117183329/No/ALMASoftwareArchitecture.pdf] [<span style="color: #0000ff"><span style="text-decoration: underline; ">0017/d20021117183329/No/ALMASoftwareArchitecture.pdf</span></span>|http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/100017/d20021117183329/No/ALMASoftwareArchitecture.pdf][)|http://almaedm.tuc.nrao.edu/forums/alma/dispatch.cgi/Architecture/docProfile/100017/d20021117183329/No/ALMASoftwareArchitecture.pdf] *\[RD34\]JacORB Home Page* ([<span style="color: #0000ff">{+}<a href="http://www.jacorb.org/+" class="external-link" rel="nofollow">http://www.jacorb.org/+</a></span>|http://www.jacorb.org/][)|http://www.jacorb.org/] *\[RD35\] Eclipse Home Page* ([<span style="color: #0000ff">{+}<a href="http://www.eclipse.org/+" class="external-link" rel="nofollow">http://www.eclipse.org/+</a></span>|http://www.eclipse.org/][)|http://www.eclipse.org/] *\[RD36\] Castor Home Page* ([<span style="color: #0000ff">{+}<a href="http://castor.codehaus.org/+" class="external-link" rel="nofollow">http://castor.codehaus.org/+</a></span>|http://castor.codehaus.org/][)|http://castor.codehaus.org/] *\[RD37\] OPUS Home Page* ([<span style="color: #0000ff">{+}<a href="http://www.stsci.edu/software/OPUS/bb.html+" class="external-link" rel="nofollow">http://www.stsci.edu/software/OPUS/bb.html+</a></span>|http://www.stsci.edu/software/OPUS/bb.html][)|http://www.stsci.edu/software/OPUS/bb.html] *\[RD38\] Rational Rose Home Page* ([<span style="color: #0000ff">{+}<a href="http://www.rational.com/+" class="external-link" rel="nofollow">http://www.rational.com/+</a></span>|http://www.rational.com/][)|http://www.rational.com/] *\[RD39\] Open ArchitectureWare project home page* [(|http://sourceforge.net/projects/architecturware/][<span style="color: #0000ff">{+}<a href="http://sourceforge.net/projects/architecturware/+" class="external-link" rel="nofollow">http://sourceforge.net/projects/architecturware/+</a></span>|http://sourceforge.net/projects/architecturware/][)|http://sourceforge.net/projects/architecturware/] *\[RD40\] Java Web Start home page* ([<span style="color: #0000ff">{+}<a href="http://java.sun.com/products/javawebstart/+" class="external-link" rel="nofollow">http://java.sun.com/products/javawebstart/+</a></span>|http://java.sun.com/products/javawebstart/][)|http://java.sun.com/products/javawebstart/] *\[RD41\] ALMA Common Software home page* [(|http://www.eso.org/projects/alma/develop/acs][<span style="color: #0000ff">{+}<a href="http://www.eso.org/projects/alma/develop/acs/+" class="external-link" rel="nofollow">http://www.eso.org/projects/alma/develop/acs/+</a></span>|http://www.eso.org/projects/alma/develop/acs][)|http://www.eso.org/projects/alma/develop/acs] *\[RD42\] CORBA Audio Video Streaming Service* [(|http://www.omg.org/technology/documents/formal/audio.htm][<span style="color: #0000ff">{+}<a href="http://www.omg.org/technology/documents/formal/audio.htm+" class="external-link" rel="nofollow">http://www.omg.org/technology/documents/formal/audio.htm+</a></span>|http://www.omg.org/technology/documents/formal/audio.htm][)|http://www.omg.org/technology/documents/formal/audio.htm] *\[RD43\] The design and performance of a CORBAAudio/Video Streaming* *ServiceCORBA Audio Video Streaming Service* *, D.C.Schmidt et al.,* [(|http://www.cs.wustl.edu/~schmidt/PDF/av.pdf][<span style="color: #0000ff">{+}<a href="http://www.cs.wustl.edu/~schmidt/PDF/av.pdf+" class="external-link" rel="nofollow">http://www.cs.wustl.edu/~schmidt/PDF/av.pdf+</a></span>|http://www.cs.wustl.edu/~schmidt/PDF/av.pdf][)|http://www.cs.wustl.edu/~schmidt/PDF/av.pdf] *\[RD44\] ARCUS Error Handling for Business Information Systems,* K.Renzel, sd&m Muenchen, 2003 [(|http://www.eso.org/projects/alma/develop/acs/OnlineDocs/ARCUSErrorHandling.pdf][<span style="color: #0000ff">{+}<a href="http://www.eso.org/~almamgr/AlmaAcs/OnlineDocs/ARCUSErrorHandling.pdf+" class="external-link" rel="nofollow">http://www.eso.org/~almamgr/AlmaAcs/OnlineDocs/ARCUSErrorHandling.pdf+</a></span>|http://www.eso.org/projects/alma/develop/acs/OnlineDocs/ARCUSErrorHandling.pdf][)|http://www.eso.org/projects/alma/develop/acs/OnlineDocs/ARCUSErrorHandling.pdf] *\[RD45\] EVLA Engineering Software Requirement,* B.Butler et. al. EVLA-SW004, Rev. 1.4, 2003 *\[RD46\] EVLA Array Operations Software Requirements,* J.Campbel et. al. EVLA-SW-003, Rev. 2.5, 2003 *\[RD47\] JFreeChart ({*}[<span style="color: #0000ff">{*}{+}<a href="http://www.jfree.org/jfreechart/+*" class="external-link" rel="nofollow">http://www.jfree.org/jfreechart/+*</a></span>|http://www.jfree.org/jfreechart/][{*})*|http://www.jfree.org/jfreechart/] *\[RD48\] MatplotlibJFreeChart* [{*}(*|http://matplotlib.sourceforge.net/installing.html][<span style="color: #0000ff">{*}{+}<a href="http://matplotlib.sourceforge.net/installing.html+*" class="external-link" rel="nofollow">http://matplotlib.sourceforge.net/installing.html+*</a></span>|http://matplotlib.sourceforge.net/installing.html][{*})*|http://matplotlib.sourceforge.net/installing.html]

  Glossary

  An extended list of glossary definitions, abbreviations and acronyms is part of the main ALMA Software Glossary

  Wiki Markup
  +\[RD28\]{+}

  , available online at the following URL: {+}http://www.mma.nrao.edu/development/computing/docs/joint/draft/Glossary.htm+.
  The following list of abbreviations and acronyms is aimed to help the reader in recalling the extended meaning of the most important short expressions used in this document:

  ABM	Antenna Bus Master
  ACE	ADAPTIVE Communication Environment ({+}http://www.cs.wustl.edu/~schmidt/ACE.html+)
  ACS	ALMA Common Software
  ACU	Antenna Control Unit
  AIPS++	Astronomical Information Processing System ({+}http://aips2.nrao.edu/docs/aips++.html+)
  ALMA	Atacama Large Millimeter Array ({+}http://www.eso.org/projects/alma/+)
  AMB	ALMA Monitor and Control Bus
  ANKA	Synchrotron Radiation Source ANKA ({+}http://www.fzk.de/anka+)
  API	Application Programmatic Interface
  CAN	Controller Area Network
  CORBA	Common Object Request Broker Architecture
  COTS	Commercial Off The Shelf
  CPU	Central Processing Unit
  ESO	European Southern Observatory ({+}http://www.eso.org+)
  FITS	Flexible Image Transport Format
  GUI	Graphical User Interface
  GTC	Gran Telescopio CANARIAS ({+}http://www.gtc.iac.es/+)
  HW	Hardware
  IDL	CORBA Interface Definition Language
  IIOP	Internet Inter-ORB Protocol
  ISO	International Standardization Organisation
  JDBC	Java Database Connectivity
  LAN	Local Area Network
  LCU	Local Control Unit
  M&C	Monitor and Control
  N/A	Not Applicable
  NRAO	National Radio Astronomy Observatory ({+}http://www.nrao.edu/+)
  OMG	Object Management Group ({+}http://www.omg.org/+)
  ORB	Object Request Broker
  OSI	Open Systems Interconnection
  OVRO	Owens Valley Radio Observatory ({+}http://www.ovro.caltech.edu/+)
  RDBMS	Relational Data Base Management System
  RPC	Remote Procedure Call
  SLA	Subprogram Library A (Positional Astronomy Library)
  SW	Software
  TAO	The ACE ORB ({+}http://www.cs.wustl.edu/~schmidt/TAO.html+)
  TBC	To Be Confirmed
  TBD	To Be Defined
  TCL	Tool Command Language ({+}http://www.scriptics.com/resource/+)
  TCL (CORBA)	CORBA Trader Constraint Language
  TICS	ALMA Test Interferometer Control Software
  TPOINT	Telescope Pointing Analysis System
  UML	Unified Modeling Language
  URI	Uniform Resource Identifier ({+}http://www.w3.org/Addressing/+)
  URL	Uniform Resource Locator ({+}http://www.w3.org/Addressing/+)
  UTC	Universal Time Coordinated
  VME	Versa Module Eurocard
  VLT	Very Large Telescope
  WS	Workstation
  XML	eXtensible Markup Language ({+}http://www.w3.org/XML/+)

  ACS Basic Architecture

  Overview

  The ALMA Common Software (ACS) is located in between the ALMA application software (Applications) and other basic commercial or shared software on top of the operating systems. In particular, ACS is based on CORBA (CORBA Middleware), which provides the whole infrastructure for the exchange of messages between distributed objects. Whenever possible, ACS features will be provided using off the shelf components and ACS itself will provide the packaging and the glue between these components.
  The ACS is also based on an Object Oriented architecture

  Wiki Markup
  +\[RD01 - 13.1.1 Distributed Objects and commands\]{+}

  
  The following UML Package Diagram shows the main packages in which ACS has been subdivided.

  
  Figure 2.1: ACS Packages

   
  Each package provides a basic set of services and tools that shall be used by all ALMA applications.
  Packages have been grouped in 4 layers. Packages are allowed to use services provided by other packages on the lower layers and on the same layer, but not on higher layers.
    A 5^th group contains packages for software that is used by many ALMA Subsystems, but that is not used by other ACS packages. These packages are for convenience integrated and distributed together with ACS but are not integral parts of ACS.
  A brief description of the layers and the packages is provided hereafter, while the next chapter will contain a detailed description of the features included in the packages.

...

Distribution of the Adaptive Communication Environment

{+}\[RD23\]{+}

.

1. - Core components

This second layer provides essential components that are necessary for the development of any application

...

The fourth and last layer provides high level APIs and tools. More will be added in the future. The main goals for these packages is to offer a clear path for the implementation of applications, with the goal of obtaining implicit conformity to design standards and maintainable software

{+}\[RD01 - 3.1.2. Design\]{+}

.

• • UIF Libraries

Development tools and widget libraries for User Interface development .

...

The Technical Architecture in the ALMA Software Architecture document

+\[RD33\]{+}

identifies a Container-Component model for software organization and development as our primary instrument for achieving separation of functional from technical concerns.
A Component is defined in

+\[RD33\]+

as a software element that exposes its services through a published interface and explicitly declares its dependencies on other components and services, can be deployed independently and, in addition:

...

For a more detailed discussion of rationale behind the choice of the ComponentContainer model, see the ALMA Software Architecture document

+\[RD33\]{+}

.

Anchor
_Toc125028 _Toc125028

2.3Deployment

The choice of CORBA for the implementation of a Component/Container model and of all services that are part of the previously described packages makes it possible to have every software operation available in a transparent way both locally and at the Control Center in San Pedro. This applies also to all data, logs and alarms

{+}\[RD01 - 12.1.6 Location\]{+}

. The choice for the LAN and access optimization mechanisms, described in the following sections, will ensure that no significant degradation in performance will take place

+\[RD01 - 3.2.4. Local and central operation\]{+}

.
In principle, this same mechanism allows reliable remote access from the US and Europe, although with reduced performance. It is anyway necessary that applications are designed in order to prevent unauthorized access and undesired side effects on the performance of the control system

+\[RD01 - 3.2.5. Remote access\]{+}

. ACS provides the basic building blocks for the implementation of these mechanisms.
All packages in the lower ACS layers are available for developing code both for the Linux

{+}\[RD01 - 10.5.4 OS\]+

and the VxWorks

{+}\[RD01 - 10.5.3 RTOS\]+

platforms. The usage of the ACE C++ toolkit allows writing portable code that can migrate, for example, from Linux to VxWorks and vice versa according to development and run-time needs.
Real Time Linux has replaced VxWorks as the real time development platform in ALMA (limited support for VxWorks is maintained for other projects). In this configuration, only hard real time tasks will run in the real time kernel, while every other task will run in the normal Linux kernel. ACS provides "bridge modules" that allow the real time tasks to communicate with non real time tasks in a standard way. For example, a logging "bridge module" allows the generation of logs on the real time side and their further propagation on the non real time side.
Higher-level components are not usually needed on the real-time platform. In this case Java will be used to provide portability among non real-time platforms (for example Linux and Windows). This will apply in particular for user interface applications.
Some development tools can be required to run or can be more convenient to use on Windows platforms.
Via CORBA, all objects publishing an IDL interface will be available to any environment, host and programming language where a CORBA implementation is available. In particular it will be possible to write client applications for
Components in any CORBA-aware platform. ACS explicitly supports C++, Java, C and Python

+\[RD01 - 10.3.3. Compiled Languages\]+

+\[RD01 - 10.5.6.  Scripting  language\].+

The ACS Component/Container model is then implemented in C+, Java and Python. The three implementations are not identical, but are tailored to the specific application domain of the language. For example, the C+
implementation provides strong support for the
Component/Property/Characteristic pattern of interest for Control Applications
Architecture
and provides a more sophisticated threading model handling of interest for the Pipeline and Offline Data Reduction applications. On the other hand, the Java implementation provides Tight Containers and transparent XML serialization.
The ACS installation procedures will allow selecting the installation platform and will allow selecting between development and run time installations. For a development installation, all development tools will be installed, including compilers and debuggers, while a run-time installation will be much lighter and include only the libraries and components needed at run-time. There is also a separate installation for "pure Java" applications that will be installable and usable from any machine supporting a Java Virtual Machine. This is based on Web Start technology to make installation as simple and automatic as possible, as well as software upgrades.
Per each package, it will be specified at design time what components will be available on each platform and for run-time and development installations.
We foresee 7 different types of deployment nodes (connections in the diagram show the foreseen communication paths among node types, for example a Remote User Station is allowed to communicate only with a Linux run-time workstation):

...

Distribution of the Adaptive Communication Environment

{+}\[RD23\]{+}

. This C++ class library provides support for cross-platform portability and implementation for a wide set of design pattern specific for distributed systems.

...

The requirements document

+\[RD01\]+

specifies as a basic design requirement the adoption of an Object Oriented architecture based on distributed objects

+\[RD01 - 13.1.1 Distributed Objects and commands\]{+}

.
The Technical Architecture in the ALMA Software Architecture document

+\[RD33\]+

identifies a Container-Component model for software organization and development as our primary instrument for achieving separation of functional from technical concerns.
This concept is the basis for the architecture and all services provided by ACS are designed around Components.
3.4.1 Every Component must implement the ComponentLifeCycle interface. This interface foresees the following basic lifecycle operations:

...

3.4.2The Container passes to each Component a ContainerServices object (in C++ this occurs at construction time, while in Java at initialize() time, because of the different traditional ways of using constructors and destructors in the two languages). At that point, the Component can assume that all infrastuctural services it may need have been properly set up by the Container and are available via the ContainerServices object.
3.4.3The architecture of the system is based on CORBA. Component and Container interfaces are described in IDL, and Components and Container are implemented as CORBA objects. The impact of CORBA on component implementation classes is very low or none, varying among languages.
3.4.4For exceptional cases, a component can explicitly ask the container to create an associated CORBA object (called an "OffShoot") and then pass it around in the system.
3.4.5ORB independence and interoperability

+\[RD01 - 10.4.2 ORB Independence\]+

is ensured by basing the Distributed Object implementation on CORBA Inter-ORB
Protocol (IIOP) and Portable Object Adapter (POA) and by not allowing the use of any ORB-specific feature. Interoperability between ORBs has been demonstrated with the the Kitt Peak Test and with the previous releases of ACS, where we have changed ORBs a number of times. The selection of the final ORBs needed for ACS is not part of this Architecture document. The current baseline includes TAO

{+}\[RD07\]+

for C/C++, JacORB

{+}\[RD34\]+

for Java, omniORB

{+}\[RD15\]+

for Python bindings, OpenOrb

+\[RD16\]{+}

for some code generation tools.
3.4.6ACS provides a C+, a Java, and a Python Container Implementation. The three implementations differ in the features offered because C+, Java and Python applications have different requirements, as described in

+\[RD33\]{+}

. Features from one type of component can be implemented also for the other type, if the requirement arises.
3.4.7ContainerSercices and ComponentLifeCycle interfaces are NOT defined as IDL interfaces, since they are used only in the internal communication between Components and Containers and there are language specific differences.
3.4.8Basic functionality provided by ContainerServices is:

...

For more details see the implementation and detailed design documentation. In particular there are various flavours of the getComponent() interface, some described here after.
3.4.9Specific Containers can provide specialised subclasses of ContainerServices with additional features. Components aware of this additional functionality can make use of it, while other Components would ignore it transparently.
3.4.10 Normally a Container will provide each Component with a specific instance of ContainerServices that contains specific context information, but this is left to the responsibility of the Container. Therefore the life cycle of the ContainerServices objects is left to the complete control of the Container.
--------------------------------------------------
3.4.11 Characteristic Components are a subclass of Components tailored to the implementation of objects that describe collections of numerical (typically physical) quantities. They have been designed in particular to represent Control
System objects with monitor and control points or objects with state and configurable parameters. In particular Characteristic Components are described using a 3 tier naming for the logical model

+\[RD03\]+

+\[RD04\]+

+\[RD05\]{+}

:

• Characteristic Component
• Property
• Characteristic

...

3.4.11.6 Another common strategy to handle the case where a data source produces simultaneously the values for many Properties consist in mapping the Properties onto memory-based DevIOs and let a parallel execution thread update all memory locations from the data collected with one single access to the data source.
3.4.11.7 The Characteristic Components - Properties - Characteristics 3 tier logical model is very well established in the community of Control Systems for Physics Experiments

+\[RD03\]+

+\[RD04\]+

+\[RD05\]{+}

, where the name Device is used to identify what we call here Characteristic Component. We prefer to adopt the more generic name, as specified in

+\[RD01 - 13.1.1 Characteristic Components and Commands\]{+}

, because the usage of the ACS is not limited to the realm of the Control System, as in the case of the mentioned references. It provides instead generic services for the development of the whole ALMA software. Proper Device classes are implemented by the Control System development team based on Characteristic Components.
3.4.12 The Characteristic Component model is based on CORBA:
3.4.12.1 A Characteristic Component is a CORBA object
3.4.12.2 A Property is a CORBA object. A class hierarchy with Property class as root implements the basic read-only and read/write versions for the predefined types. This hierarchy provides standard IDL interfaces that shall be used by all clients to access Properties. On the implementation (servant) side, specific subclasses will provide polymorphic access to specific implementations like 'logical', 'simulated', 'CAN', 'RS232', 'Digital IO' and so on.
3.4.12.3 Public interfaces to Characteristic Components and Properties are defined as
CORBA IDL.
3.4.12.4 Characteristics of Characteristic Components and Properties can be accessed through access methods (as shown in figure) and through a generic value = get_characteristic_by_name(name) type of interface at run time. The interface of properties is defined by their IDL and the IDL is the same independently from the implementation (logical, CAN...). But specific implementations will have also specific characteristics. For example a CANLong property has a CANID characteristic. This means that from the property's IDL there is no way to retrieve the CANID using CORBA calls. We provide then a generic interface that can be used to retrieve any characteristic just querying by name. This allows accessing specific Characteristics, like the CAN ID for properties related to CAN monitor points that are not defined in the generic property IDL but are instead implementation specific.
3.4.13 The configuration parameters for all Characteristic Components, i.e. the initial
values for Properties control values and all Characteristics for Properties, are persistently stored in the Configuration Database

+\[RD01 - 4.2.1. Configuration Database\]{+}

. See the section on Configuration Database architecture.
3.4.14 Characteristic Components may have a state. Specific Characteristic Components can have additional sub-states.

+\[RD01 - 13.1.2 Standard Methods\]+

+\[RD01 - 14.1.13 States\]{+}

.
3.4.15 Note: A standard state machine and standard state transition commands could be defined. (Implementation not foreseen for ALMA).
3.4.16 JavaBeans wrap CORBA objects on the client side. Standard Rapid Application Development (RAD) tools like Eclipse

{+}\[RD35\]+

are used to handle them. Given the IDL interface of a Characteristic Component, a code generator automatically produces the corresponding JavaBean. In this way the developer has libraries that provide him direct support for ACS concepts like Characteristic Component/Property/Characteristic, Monitors, and Event and Notification System.
3.4.17 ACS also provides a generic IDL simulator (see section IDL Simulator) to simulate an entire Component.
3.4.18 If an application wants to provide a more sophisticated level of simulation (for
example simulating interrelations between the values of properties), a specific
simulated device should be implemented in parallel to the real device. Switching from the real to the simulated device is handled in the configuration of the Manager (see Management and Access Control section), telling it to start a different implementation of the same device's CORBA interface.
3.4.19

*Note:* As an extension, ACS could provide support for simulation{+}\[RD01 - 3.3.4.+

Simulation] at Property level. All properties that access hardware can be switched in simulation by setting TRUE a simulation characteristic in the configuration database. After this, they behave like "logical properties". This provides basic simulation capabilities. (Implementation not foreseen for ALMA).
3.4.20 Direct Value Retrieval
3.4.20.1 The Property classes provide get() and, in case of writeable Properties, set() methods that can be used to directly access the value of the property from clients

+\[RD01 - 4.1.1 Direct value retrieval\]{+}

. Both synchronous and asynchronous get() and set() methods are provided.
3.4.20.2 Value setting is done using set() property methods. These methods can be called by applications or by specifically designed GUIs. CORBA Dynamic Invocation Interface allows to write generic applications and GUIs (like the Object
Explorer) that are capable of resolving dynamically at run time the structure of Characteristic Components and call set() methods to set the value of Properties

+\[RD01 - 3.2.3. Value setting\]{+}

.
3.4.20.3 DevIO specialization is used to implement properties accessing specific hardware devices, like CAN, RS232, GPIB. CAN properties will always directly access the hardware on the CAN bus at direct value retrieval and not use cached values.
3.4.21 Value Retrieval by Event
3.4.21.1 The Characteristic Component provides a method to create a monitor object for a Property, able to trigger events on Property change or periodically. A callback will be connected to the event and will be called by the monitor object when the specified event occurs

{+}\[RD01 - 13.1.4. Events\]{+}

. Triggered events are delivered directly to the registered object via the callback mechanism in a point-to-point fashion. The value retrieval by event is then very well suited for providing timely feedback to control applications.
3.4.21.2 Events can be generated on any change of value

{+}\[RD01 - 4.1.3 Rate\]{+}

.
3.4.21.3 Note: Other conditions, for example any write, value increase/decrease, value less or greater than set-point could also be included at a later stage. (Implementation not foreseen for ALMA)
3.4.21.4 Timed or periodic events can be generated as follows:

• Periodic, at a specific interval rate

  Wiki Markup
  +\[RD01 - 4.1.3 Rate\]+

• Periodic, at a specific interval rate, synchronized with an absolute array time

  Wiki Markup
  +\[RD01 - 4.1.5 Values at given time\]{+}

  . This also allows periodic events aligned with the monitoring rate. For example, a 1-second rate generates events on the 1-second mark, 5-second rate on the 5-second mark and so on.

...

3.4.21.5 All events will be time stamped with the time at which the value has been acquired (as opposed to the time of delivery of the event). Timed events will be triggered "timers" such that the requested time is the time of acquisition of the value, and not the time of delivery which depends on the network characteristics.
3.4.21.6 The monitor class provides methods to suspend, resume and destroy the monitor
itself.
3.4.21.7 Note: CAN-Properties will have to implement notification on change also for CAN
monitor points although CAN monitor points do not provide a specific support via HW or in the drivers. This can/should be done via polling. If there are clients registered on events on change, an ACS monitor is used to poll and to generate events in case of change of the value of the monitor point. The poll rate is defined by the characteristic change frequency. The polling frequency determines the time resolution of the eventon-change. (implementation not foreseen for ALMA)
3.4.21.8 Note: For performance optimization, the final implementation will not leave to the single Characteristic Component Properties the responsibility of managing timers, but a local centralized manager will take care of that, transparently to client applications. More details will be given in the ACS design. (implementation not foreseen for ALMA)
3.4.21.9 Note: A particular case is a Characteristic Component State Machine. A State Machine class is a Characteristic Component and the current state is represented by a State Property. This State Property can fire events whenever the state changes to allow external objects to monitor it. (implementation not foreseen for ALMA)
3.4.22 Supported implementation languages
The Characteristic Component / Property /characteristic pattern is implemented in C++ and in Java and Python
Note: Java and Python implementations are not complete and contain now all and only the features used in ALMA.
--------------------------------------------------
3.4.23 ACS Java Components provide explicit support for the transparent serialization of instances of entity classes

+\[RD01 - 3.3.2. Serialization\]{+}

. See the section on "Serialization".

...

3.5.1The configuration parameters for all Components and, in particular, for all
Characteristic Components, i.e. the initial values for Properties values and all
Characteristics for Properties, are persistently stored in the Configuration Database

+\[RD01 - 4.2.1. Configuration Database\]{+}

. Any application can make use of the Configuration Database to get access to configuration information.
3.5.2 There are 4 different issues related to the problems addressed by the CDB:

...

3.5.5 When a Characteristic Component is instantiated, it configures itself according to the configuration stored in the Configuration Database

{+}\[RD01 - 3.3.2. Serialization\]{+}

.
3.5.6The implementation of the Configuration Database is hidden in a Configuration Database Access API to allow switching among alternative implementations

{+}\[RD01 - 4.2.2 Database Design\]{+}

.
3.5.7The reference implementation is based on XML files and a Java application loads and parses the XML files. Files are validated at run time and a separate CDB checker can be used to validate offline CDB XML files without the need of loading them in a "live" database.
3.5.8In ALMA, configuration information is stored in the Telescope and Monitoring Configuration Data Base (TMCDB). This is based on the Oracle RDBMS (with the small-footprint RDBMS, hsqldb, used for small-scale testing). Archive, Control and ACS subsystems are responsible for the implementation of the Configuration Database Access API on top of the TMCDB, throught the implementation of a specific Component. This implementation includes roundtrip tools to convert CDB instances between the XML reference implementation and the TMCDB. In this way it is possible to develop locally with the XML implementation and transparently migrate to the final system based on the ALMA Archive and TMCBD. (Being enhanced).
3.5.9All Components have access to the Configuration Database during construction/initialization and later during their operational life. While accessing the CDB is optional for normal components, Characteristic Components must retrieve their configuration information from there.
At a higher level, the Container responsible for the Components (see Container package) provides an interface to set the reference to the configuration database used. In this way it is also easy to switch between different databases at startup time.

...

3.5.9.1We define Characteristics as statically defined in the Configuration Database. This means that is possible to change their value only by changing the configuration database and reloading just the corresponding Characteristic Components

{+}\[RD01 - 14.1.9 Dynamic configuration\]{+}

. This means that they cannot be used for, e.g., calibrations that change at run time. With this definition, calibration values that change at run time should be implemented as Properties, not as Characteristics. "Static" calibration values, for example measured by an engineer and not supposed to change for months can be Characteristics. Characteristics can change with time or can change with the context.
3.5.9.2Note: It is possible to implement also a more dynamic mechanism, but we have not identified a requirement for ALMA. This can be done transparently at a later time extending the Property class with methods to change the value of characteristics but this has not been considered in the first design to avoid increasing the complexity of the system. (Implementation not foreseen for ALMA)
3.5.10 Note: A Visual Configuration Tool (CT) can be implemented on top of the Database Loader. This can be completely independent of all other aspects of CDB and therefore can be implemented at a later stage. ALMA configuration data is edited using the TMCDB tools and therefore no requirement for such Visual Configuration Tool has been recognized. The basic features are described hereafter for a possible future implementation (Implementation not foreseen for ALMA) • The CT allows to visually edit the structure/schema of the configuration database and to fill in the values inside the instantiated database.

...

• the data supplier publishes its data pushing it on a channel, completely unaware of clients getting access to the data, i.e. the data supplier decides how and when data is going to be published
• data consumers subscribe to data sets on the channel without establishing any direct communication with the data suppliers.

  1. 1. The Event and Notification System is the basic mechanism for Indirect Value Retrieval

        Wiki Markup
        +\[RD01 - 4.1.2 Indirect value retrieval\]+

        providing mirroring of data on computers other than where the data are produced. This makes it possible to randomly access data without interfering with the control process

        Wiki Markup
        +\[RD01 - 3.2.2 Value retrieval\]+

        and without knowing if the data is directly available on the client's machine or if it is a mirrored copy

        Wiki Markup
        {+}\[RD01 - 4.1.4 Transparency\]{+}

        .

     2. The CORBA Notification Service provides the infrastructure for the Event and Notification System implementation:

...

The Error System provides the basic mechanism for applications to handle internal errors and to propagate from server to client information related to the failure of a request. An error can be notified to the final user and appear in a GUI window if an action initiated by the user fails (for example a command activated from a GUI fails).
3.7.1The architecture of the ACS Error System is based on the architecture and design patterns described in details in

+\[RD44 -  *ARCUS Error Handling for Business   Information Systems* \]+

.
3.7.2 The Error System propagates error messages making use of OO technology. The basic error reporting mechanism is to throw an exception.
3.7.3The error reporting procedure must be the same regardless of whether the communication is intra-process (local) or inter-process (remote), synchronous or asynchronous.
3.7.4Errors can be propagated through the call chain as an ACS Exception or an ACS Completion to be reported to the action requester

+\[RD01 - 6.3.6 Scope\]{+}

.
3.7.5An ACS Completion is used to report both successful and unsuccessful completion of asynchronous calls. More in general, ACS Completions are used as return value or out-parameter in any case where it is not possible/meaningful to throw an ACS Exception.
3.7.6 The ACS Error System provides a mean to chain consecutive error conditions into
a linked list of error objects. This linked list is also called an Error Trace

+\[RD01 - 6.3.2 Tracing\]{+}

. It is not required that all levels add an entry in the trace, but only the ones that provide useful information.
3.7.7Both ACS Exceptions and ACS Completion contain an Error Trace. The Completion can contain no Error Trace in case of successful completion.
3.7.8Representation (see class diagram for details):
3.7.8.1ACS Error Trace is represented as a recursive CORBA structure, i.e. as a structure that contains information about the error and a reference to another structure of the same type (the previous Error Trace), to build the linked list. The Error Trace contains all information necessary to describe the error and identify uniquely the place where it occurred. In particular it contains an error message and context specific information as list of (name, value) pairs. For example, in the typical case of impossibility of opening a file:

...

3.7.9Inside a process, an ErrorTrace, ACSException and Completion are typically encapsulated into an instance of a Helper class, in the native language used for the implementation of the process (C++, Java and Python helper classes are provided directly by the ACS Error System). This class implements all operations necessary to manipulate respectively Error Trace and ACSException and a Completion CORBA structure.
3.7.10 For inter-process CORBA communication, the ACSException and Completion Helper classes transparently serialize the corresponding CORBA structure and transfer it to the calling process

+\[RD01 - 6.3.1 Definition\]{+}

. There it is deserialized into a new Helper class, if available.
3.7.11 Using this approach only CORBA Structures are transferred between servants and clients and it is not necessary to use Object by Value to transfer a full-fletched object. For languages where a Helper class is available, the encapsulation of the Error Trace structure into the Helper is equivalent to the use of Object by Value. On the other hand, languages where no Helper class is available can still manipulate directly the Error Trace structure. Also, Object by Value support from the ORB is not required.
3.7.12 In a distributed and concurrent environment, an error condition is propagated as an Error Trace over a series of processes until it reaches a client application, which either fixes the problem or logs it. At any level it is possible to:
3.7.12.1 Fully recover the error. The Error Trace is destroyed and no trace remains in the system.
3.7.12.2 Close the Error Trace, logging the whole Trace in the Logging System and then destroying the Error Trace. The error could not be recovered at the higher level responsible for handling it and it goes in the log of anomalous conditions for operator notification and later analysis. This typically happens for unrecoverable errors or when an error has to be recorded for maintenance/debugging purposes. This option is used also to log errors that have been recovered but that we want to record in the log system, for example to perform statistical analysis on the occurrence of certain recoverable anomalous conditions.
3.7.12.3 Propagate the error to the higher level, adding local context-specific details to the Error Trace (including object and line of code where the error occurred). The higher level gets delegated the responsibility of handling the error condition. This strategy implies that we might lose important error logs if the higher level application does not or cannot fulfill its own obligation to log error messages (for example because it crashes). It is therefore allowed at any time to log an important error trace (typically at debug level) as a precautionary measure to make sure it does not get lost. Logging it at Debug level ensures that the redundant information is not visible unless we are looking at logs in debug mode.

...

• The XML specification files allow defining context value pairs.
• Code generation is used generate type safe helper classes in all supported languages from the XML specification files.
• Getters and setters are generated for all context value pairs.

• Each (Completion/Error Type, Error Code) pair is associated in the XML specification files to documentation providing help description of the error and of the recovery procedures to be taken

  Wiki Markup
  {+}\[RD01 - 6.3.5 Configuration\]{+}

  .

• Help handling is implemented as links to XML help pages.

3.7.16 The Error System provides an API to access error documentation. (Not implemented yet)
3.7.17 An Error Editor GUI tool is used by application developers defining new (Completion/Error Type, Error Code) pairs and to manage them (insert, delete, edit the description) without having to edit by hand XML specification files. The tool ensures that (Completion/Error Type, Error Code) pairs are unique in the system and generates one XML specification file for each Completion/Error Type. (Partially implemented)
3.7.18 User interface tools allow navigating through the error logs and through the levels of the Error Trace

+\[RD01 - 6.3.4 Presentation\]{+}

. The logging display GUI is used to browse errors and a specific Error display tools is used to browse the Error Trace corresponding to a single error. (Partially implemented)
3.7.19 Errors have a severity attribute

{+}\[RD01 - 6.3.3 Severity\]+

3.7.20 It is important to take into account that exceptions can skip several layers in the call tree if there is no adequate catch clause. In this case the error stack will not have a complete trace of the call stack.
3.7.21 Particular attention must go into properly declaring exceptions in the signature of methods and in catching them; in C+, specifying exceptions in the signature of a method which then throws an exception not included in that specification can cause the process to abort at run time. The alternative approach, i.e., not specifying any exceptions at all in the signature, cannot be used for CORBA methods. Therefore the ACS error system documentation contains guidelines to follow in implementing proper and safe error/exception handling, in particular in C+.

...

Logging is a general mechanism used to store any kind of status and diagnostic information in an archive, so that it is possible to retrieve and analyze it at a later time.
3.8.1ACS Logging System is based on CORBA Telecom Log Service

{+}\[RD14\]+

and on the ACS Event and Notification System architecture
3.8.2Applications can log information at run time according to specific formats in order to record

{+}\[RD01 - 6.2.1 Logging\]{+}

:

• The execution of actions
• The status of the system
• Anomalous conditions

...

• Device commands - reception and execution of commands from devices

+\[RD01 - 14.1.1 Logging of commands\]+

• Debugging - Optional debugging messages, like notification of entering/leaving specific code sections.
• Unrecoverable programmatic errors
• Alarms - change of status in alarm points
• Miscellaneous log messages. Applications can log events regarded as important to archive, for example receivers changing frequency, antennas set to new targets etc.

3.8.4Each log consists of an XML string with timestamp

{+}\[RD01 - 6.2.1 Logging\]{+}

,
information on the object sending the log and its location in the system, a formatted log message. Context specific information is entered as (name, value) pairs. The XML format is defined in the Log Markup Language (logMl) XML Schema.
3.8.5High level logs (for example logs directed to operators) are "type safe logs" defined in XML files, in a way analogous to error code specifications.

• The XML specification files allow to define context value pairs.
• Code generation is used generate type safe helper classes in all supported languages from the XML specification files.
• Getters and setters are generated for all context value pairs.

• Each type safe log specification is associated in the XML specification files to documentation providing help description of the error and of the recovery procedures to be taken

  Wiki Markup
  {+}\[RD01 - 6.3.5 Configuration\]{+}

  .

• Help handling is implemented as links to XML help pages.

3.8.6 Low level logs can be free format and are not required to be specified in XML type safe definitions.
3.8.7 The logging system is centralized so that eventually the logs are archived in a central log.
3.8.8Log clients can subscribe to the Log Notification Channel. The permanent Log Archive

+\[RD01 - 6.2.2 Persistency\]+

(an RDBMS) is essentially such a client and its implementation is left to the application.
3.8.9Applications log data using the API provided by ACS. This API provides methods for logging information of the different kinds specified above. A C++, Java and Python APIs are provided. The APIs are based on the standard logging facilities provided by the implementation language, when available:

...

3.8.10 Logs can be cached locally on the machine where they are generated by a logging proxy and transmitted to the central log on demand or when the local buffer reaches a predefined size. High priority logs are not cached but are transmitted to the central log immediately. The main purpose of caching is to reduce network traffic.

Figure 3.9: Logging System
3.8.11 In particular the C++ API is optimized for performance and reduced network traffic and implements caching.
3.8.12 In ACS, logs are directly generated in XML format on the publishing side and transported as XML strings inside the logging service. During the ACS 7.x development cycle, we experimented with a binary transport based on IDL structures, hoping that this would improve performance. To our surprise, however, we discovered that the CORBA-encoded structures occupied 3 times as much space as their XML counterparts, and that this produced performance degradations of a factor of 3 in C++ and 15 in Java. Needless to say, this avenue is now closed.
3.8.13 The log API allows for filtering based on the log level, so that log entries with low priority do not get logged. The filter can for example be set to log or not log debug messages. The filter level is determined at run time and can be set through a command or through external configuration files. This filtering is done at the level of the container, so that only log messages that pass the filter are sent out over the network.
3.8.14 The API includes support classes (logging guards) to prevent message flooding. It allows the application developers to control the logging of repeated error messages. We have decided NOT to implement an automatic mechanism capable of detecting whether the same message is being logged at too high a rate, because we think that a reliable implementation is very difficult to achieve and would in any case heavily impact performance. But this means that careless developers can flood the system with logs. We will have to assess later whether to implement a more sophisticated mechanism.
3.8.15 A generic CORBA ACS Logging Service is available for any CORBA application to log even if no specific API is available. The IDL interface of the CORBA ACS Logging Service provides, on top of the standard CORBA Telecom Logging Service, methods for each type of log defined in ACS. Values for the relevant log fields are passed as parameters and the Service takes the responsibility of formatting them in appropriate transport structures and sending them to the CORBA Telecom Logging.
3.8.16 A user interface (logging GUI client) allows to monitor the logs while they are produced, in quasi-real-time, and to browse the historical database off-line. It provides filtering and sorting capabilities

+\[RD01 - 6.2.3 Filtering\]{+}

. It provides searching capabilities. It is useful to filter logs by inclusion and exclusion and logical combinations based on any logging field, like:

...

3.9.1ALMA has a distributed HW pulse, with a 48 ms interval, that the hardware will synchronize to

{+}\[RD01 - 8.1.3. Distributed timing\]+

+\[RD30\]{+}

. Also devices on the CAN bus will be connected to the time bus to allow synchronization.
3.9.2All time data in ACS (APIs, timestamps….) is based on the array time

+\[RD01 - 8.1.1. Standard\]{+}

. We assume that non-Real-Time boxes are simply synchronized to the array time using standard protocols, like NTP.
3.9.3The Time System provides basic service for time handling. It includes:
3.9.3.1Abstract API to access time information in ISO format

+\[RD01 - 8.1.2. API\]+

and to perform time conversion, arithmetic and formatting

+\[RD01 - 5.3.1.+

Time conversion] to/from various time systems (UTC, TAI…).
3.9.3.2 An abstract API for synchronization between applications based on array time.
3.9.3.3Timer classes to trigger events based on time

+\[RD01 - 8.1.4 Services\]{+}

:
3.9.3.3.1 Applications can create instances of the timer class and register callbacks to be executed when the timer event is triggered
3.9.3.3.2 Timers can be periodic (retriggerable) or oneshot events
3.9.4Absolute Time is internally represented in 100 ns since 1582-10-15 00:00:00, based on the OMG Time Service Specification. An IDL typedef is used to define the Time type:

...

3.10.1 The ACS Container package is responsible for the implementation of the Container part of the Container-Component model of ACS. This includes design patterns and high level services to manage the life cycle of Components and Containers themselves

+\[RD01 - 5.1.2. Procedures\]{+}

. This high level management part is implemented in a specific sub-package called the Management and Access Control package.
3.10.2 Containers are supervised and managed by an ACS Manager. Manager and Containers cooperate to provide the following functionality:

...

3.10.16 An Object Explorer User Interface tool is provided to navigate the hierarchy of Components on the naming hierarchy.

{+}\[RD01 - 5.1.3 Browser\]+

• The Object Explorer is equivalent and covers the requirements of the

Device Browser Tool described in the

+\[RD45 - EVLA Engineering Software Requirements, 1.1 Accessing a Single Device\]{+}

.

*_In order to cover all detailed requirements expressed in +\[RD45\]{+}, extensions to the Object Explored will need to be implemented._*

• All objects in the system can be reached by navigating the hierarchy and all object information can be retrieved and edited, including accessibility

...

• The Object Explorer allows to browse the interface

  Wiki Markup
  +\[RD45 - 1.1-R4\]+

  and send any command supported by a Component

  Wiki Markup
  +\[RD45 - 1.1-R5\]+

• It is possible to monitor and draw trend-plots for each property

  Wiki Markup
  +\[RD45 -+

1.1-R3]

• The Object Explorer uses the CORBA Interface Repository to retrieve information on the interfaces provided by the Components in the system.

• Requirements in

  Wiki Markup
  +\[RD45 - 1.1\]+

  not covered by the current Object Explorer implementation are:

• 1.1-R2 - Tabular representation of multiple monitor points
• 1.1-R3 - Plot multiple monitor points on the same plot (this is possible with the ACS Sampling System)
• 1.1-R5.4 - Send a command repetitively
• 1.1-R5.5, 5.7- Save, read and execute sets of commands from file
• 1.1-R8 - Save tabular data with monitor values (this is possible with the ACS Sampling System)
• 1.3 Accessing Multiple Devices

...

3.14.1 Entity data, i.e. complex data structures of moderate volume, are often represented as XML in the ALMA system. According to the ALMA Technical Architecture described in the ALMA Software Architecture

{+}\[RD33\]{+}

, XML is used to:

• define the content and structure of the entity objects that are passed between subsystems
• automatically generate the classes needed to access the data contained in these entity objects, optionally validating changes to a data value by an explicit call to validate() or implicit validation during (un-)marshalling;
• serialize these objects for network transmission;
• facilitate the storage of these.

3.14.2 The primary language used to define data entities in ALMA is UML, c.f. ALMA Software Architecture

{+}\[RD33\]{+}

.
3.14.2.1 UML is used as a higher-level layer, from which the previously hand-crafted XML Schemas are now automatically generated. The data transport format will remain XML though, and the XML schemas are still visible to developers when defining database queries.
3.14.2.2 Support for data modeling, code generation, and data handling in ALMA is split between ACS and the HLA subsystem:

...

3.14.2.3 We assume that access to entity data will be primarily of concern to Java high level applications, therefore ACS priority is to provide optimal support for Java.
3.14.3 Entity data structures are conceptually defined as UML classes. Technically they are defined by means of XML Schemas which are derived automatically from
UML.
3.14.4 Programming language classes (for example Java, C++ and Python) to wrap and facilitate access to entity structures could be generated automatically from the XML Schema (XML binding to language-specific classes). The Castor

{+}\[RD36\]+

open source framework is currently used for Java binding. Castor XML binding provides also validation code for the accessors, based on the XML Schema. A similar, but not as complete, open-source binding framework for Python, generateDS, will be delivered with ACS 8.0. No such facility is currently foreseen (or required) for C++.
3.14.5 For data structures defined in UML, code generators are based on the Open ArchitectureWare Project

+\[RD39\]+

generator framework. We generate from the XMI UML representation:

...

3.14.6 Entity data is passed among Components as XML strings

{+}\[RD01 - 10.5.10 XML\]{+}

. Each Component operation that sends/receives an entity data structure, will have an IDL interface where the corresponding parameter is represented as a CORBA string. This is a commonly accepted way of implementing serialization.

+\[RD01 - 3.3.2. Serialization\]+

and migration

{+}\[RD01 - 3.3.3. Migration\]+

of objects without using CORBA Object by Value (ObV). As already mentioned in the Error System section, ObV is not implemented by most ORBs, is still immature and its usage is problematic.
3.14.7 ACS Java Container makes (un)-marshalling transparent to the user, interposing a proxy class between the IDL stub/skeleton and the implementation:

...

A command is the basic mechanism for communication from users to Distributed
Objects and between Distributed Objects. A command is actually a method of a Component.
3.16.1 Commands are sent to Components

+\[RD01 - 6.1.2. Commands\]+

using remote method invocation. It is based on CORBA

+\[RD01 - 10.4.1. CORBA\]  \[RD01 -  13.1.1. Distributed Objects and Commands\]{+}

.
3.16.1.1 CORBA provides full support for inter-process communication.
3.16.1.2 CORBA objects have a public interface defined with the IDL language

{+}\[RD01 -+

10.3.4. IDL]
3.16.1.3 CORBA objects can be remotely accessed by creating stubs and invoking the defined IDL interface.
3.16.1.4 Any language supported by CORBA can talk to any remote object, independently from implementation language and architecture. The Object Request Broker (ORB) does mapping of calls and marshalling.
3.16.1.5 CORBA defines a standard Internet Inter-ORB Protocol (IIOP) that guarantees interoperability between any CORBA implementation and vendor based on TCP/IP. Any implementation must comply with IIOP, but a vendor can choose to additionally implement high performance transport protocols. For example there are native ATM implementations. Same-process messages are usually implemented as direct function calls while same-CPU messages are based on operating system message queues.
3.16.1.6 Other non-IIOP CORBA messaging protocols, supported by the ORBs used in ACS, can be used to satisfy special communication and security requirements.
3.16.1.7 A call to a method of a CORBA Component, based on its IDL interface, is what can and has to be mapped into the concept of Commands (the method call concept is very similar to RPC).
3.16.2 A command has a well-defined syntax and set of call and return parameters. Full context validation and syntax check of commands is always done when the command is received by the server application

{+}\[RD01 - 6.1.4. Validation\]{+}

. A command can also be checked by the sender, but this is not mandatory except in the case of generic command-sending GUIs

{+}\[RD01 - 6.1.3. Syntax Check\]{+}

. The syntax check would check that the command is valid and that the parameters are within the static ranges.
3.16.3 Commands are synchronous (the caller blocks and waits for a return reply, up to a defined timeout)

+\[RD01 - 6.1.7. Mode\]+

+\[RD01 - 6.1.8. Timeout\]{+}

. Applications should take care of the fact that a synchronous call can block the whole application unless it is issued from a dedicated thread. Replies can be normal replies or error replies

{+}\[RD01 - 6.1.1. Messages\]{+}

.
3.16.4 CORBA Asynchronous Method Invocation (AMI)

+\[RD29\]+

can be used to implement asynchronous calls on the client side using synchronous methods on the servant side. AMI is only supported by a few ORBs, for example TAO and JacORB, but not by omniORB.
3.16.5 Asynchronous command handling using synchronous methods on the servant side can also be done by starting a separate thread, which sends a synchronous command. This way the main thread is not blocked.
3.16.6 Asynchronous command handling can also be implemented using callbacks, in particular when multiple replies need to be sent. ACS provides support for Callbacks and uses callbacks for Monitors.
3.16.7 Using synchronous commands, time-outs are handled using CORBA messaging (implemented in TAO but not in other ORBs)

+\[RD01 - 6.1.6 Command delivery\]{+}

. Intermediate replies are not handled by ACS, but must be taken care of by the application. ACS cannot therefore warranty that requirement

+\[RD01 - 6.1.9 Intermediate replies\]+

is satisfied. This is let to applications.
3.16.8 Commands can be invoked from generic applications, that are able to browse the objects in the systems, show the available commands with the corresponding syntax, check dynamically the syntax of commands and send them

{+}\[RD01 - 6.1.5. Programmatic use\]{+}

.
3.16.9 A server sub-system handling a command shall continue to operate if the client that has issued the command disappears, e.g. between a command being initiated and completed. In this case the server logs a non-critical error, since a wellbehaving client should always wait for replies to initiated actions, and continues.
3.16.10 Components publish their interfaces via IDL interfaces. IDL allows use of inheritance to build new types. IDL allows only defining the pure interface in terms of parameters and types; it does not allow specifying range checking for the parameters. This checking has to be performed by the applications. IDL interfaces are registered in the CORBA Interface Repository (IREP) and made public.

...

The Alarm System provides a mechanism for notifying asynchronously operators and registered applications of the occurrence of important anomalous conditions that can disrupt the observation or be potentially dangerous for the system

{+}\[RD01 - 6.4.1 Definition\]{+}

.
3.17.1 The design and implementation of the ACS Alarm System are based on the Laser system developed by CERN for the LHC accelerator

+\[RD19\]+

and take into account the OVRO hierarchical alarm system

+\[RD22\]  \[RD01 - 6.4.5. Hierarchy\]+

. For more details on the Laser system and for a very good Alarm System Requirements Document see

+\[RD19\]{+}

.
3.17.2 An Alarm System API implemented in C++, Java and Python allows applications to publish Alarms.
3.17.3 Properties are able to trigger alarms. The simple alarm is triggered when the value
of the property exceeds or falls below the alarm limits defined for the property.
3.17.4 Hysteresis could be implemented for the alarm limits (Implementation not foreseen for ALMA).
3.17.5 Alarms are events published on an Alarm Notification Channel. Notification is done when the alarm is set and when it is cleared.
3.17.6 Whenever an alarm is set or cleared, the event is logged in the Logging System

+\[RD01 - 6.4.6. Alarm logging\]{+}

.
3.17.7 Alarm events are characterized by the following information:

• An enumerated state property with the values: GOOD, WARNING, BAD
• A timestamp property describing when the alarm status changed

• A set of description characteristics

  Wiki Markup
  +\[RD01 - 6.4.7. Configuration\]{+}

  , including (on top of the standard ones like description, URL for extended documentation...) a severity

  Wiki Markup
  +\[RD01 - 6.4.3. Severity\]+

3.17.8 An Alarm Server application keeps track of all active alarms.
3.17.9 Hierarchical alarms can be constructed by the Alarm Server that behaves as client on top of the available alarm system and re-publish hierarchical alarms.
3.17.10 The Alarm Server is also responsible to maintain State Alarms. These are alarms that maintain an internal state. In this case the alarm will be incarnated by an Alarm Object whose life cycle is controlled by the Alarm Server. They will have the following additional properties:

• An enumerated occurrence property (FIRST OCCURRENCE, MULTIPLE OCCURRENCE....)

  Wiki Markup
  {+}\[RD01 - 6.4.4. State\]+

• A property holding the status of user acknowledge, when required. Some alarms just disappear when the alarm condition is cleared, but others require an explicit acknowledgment from the operator

  Wiki Markup
  {+}\[RD01 - 6.4.2 Behavior\]+

3.17.11 It is possible to define actions that have to be started on the occurrence of a given alarm condition

+\[RD01 - 6.4.8. Binding\]{+}

. Applications can use normal Notification Channel techniques to request a notification to be sent for the occurrence of specific alarms.
3.17.12 An alarmDisplay GUI provides an operator user interface to the alarms. Using this application the operator can browse through the currently active alarms, request for detailed information and help about a specific alarm, acknowledge alarms when this is required.
3.17.13 The Alarm System supports the definition of reduction rules.

...

3.18.1 Every Property can be sampled at a specified sustained frequency, up to 200 Hz, limited by hardware.
3.18.2 A sampling frequency of 1KHz for a limited number of Distributed Object Properties must be allowed in order to implement a "virtual oscilloscope" whereby, for example, noise sources in the IF chains can be correlated and identified.
3.18.3 The Sampling System is equivalent and covers the requirements of the Fast Data Dump in

+\[RD45 - EVLA Engineering Software Requirements, 1.2 Fast Data Dump\],+

although it is not integrated in the Object Explorer.
3.18.4 The Event and Notification System transports sampling data.
3.18.5 The samples are stored in a data file for later analysis or to be passed to applications like MatLab for analysis of engineering data

+\[RD45 - 1.1-R8\]{+}

. Every sample is time-stamped to allow correlating data from different sources.

+\[RD01 - 4.3.1. Sampling\]+

3.18.6 The samples can be plotted in near real-time on a user interface on the operator terminal or any other user station. The plotting application subscribes to the sampling data from the notification channel, which is fed by the sampling manager, and periodically updates the running plot with the new data

+\[RD01 - 5.1.4 Analysis tool\]{+}

. The plotting application can also display sampling data from data files. The plotting application can be:

• A Java application that uses Java plotting widgets and in particular widgets aware of the Property internal structure to define plotting scales and units.

• A COTS application, like LabView

  Wiki Markup
  {+}\[RD13\]+

  Wiki Markup
  +\[RD01 - 10.5.7 Analysis and plotting\]{+}

  , with advanced plotting and analysis capabilities.

3.18.7 Multiple samples can be super-imposed on the same plot with the same time base, even if the data are received from different distributed objects, possibly on different antennae (Partially implemented). Also, it should be possible to plot samples against one another, an example being VI curves (voltage vs. current) used in biasing mixer junctions (Not implemented yet).
3.18.8 Data transport is optimized. The samples are NOT sent one by one to the central control computer responsible for storing data, but are cached on the local computer and sent in packets (for example with 1 Hz. Frequency). This is of primary importance to keep network load under control.

+\[RD01 - 4.3.1. Sampling\]+

3.18.9 There is a sampling engine implemented as a Component:
3.18.9.1 It can be activated on any local computer
3.18.9.2 Can be configured to sample one or more Properties at given frequencies.
3.18.9.3 It sends periodically at low frequency packets of data to a sampling server that stores the data for later analysis or provides them to near-real-time plotting applications.
3.18.9.4 Sampling must not reduce the performance of the control system or the network. The caching of data will reduce network traffic while assuring that the sampling processes runs with lower priority than control processes will reduce the impact on the performance of the control system.

...

ACS provides support for the transport of bulk data

+\[RD01 - 7.1. Bulk data transfer\]{+}

, to be used for science data.
3.19.1 The following use cases are supported:
3.19.1.1 Push streaming. Connection initiated by the supplier.
A data supplier produces a continuous stream of data for a specific bulk data consumerComponent. Typical example is the Correlator sending continuous streams of data to the Archive.
The basic operations are as follows:

...

The first two options are based on the IIOP transport protocol and therefore suffer from performance limitations, although tests available in the literature show that properly designed buffering limits these problems. Option 1 is better suited for discrete bulk data while option 2 is better suited for streaming.
Option 3 is based on the Audio Video Streaming Service

+\[RD42\]+

defined by CORBA. This specification aims at the streaming and transfer of large amounts of data and satisfies the requirements expressed in

+\[RD01 - 7.1.1 Image pipeline\]{+}

. The handshaking protocol is defined using CORBA IDL Media Control interfaces, but the actual data transfer goes out of band and does not use (but could use) CORBA to transport data. TAO provides an implementation and provides transport over TCP and UDP with excellent performance

{+}\[RD43\]{+}

.
3.19.3.2 The CORBA Audio Video Streaming Service supports all the use cases described above.
3.19.3.2.1 There are the following basic concepts:

...

Anchor
_Toc125049 _Toc125049

3.20 User Interface Libraries and Tools

3.20.1 The Java language

{+}\[RD06\]+

is the current choice for GUI development, in particular coupled with the SWING graphical library
3.20.1.1 A rich set of widgets is part of the standard package.
3.20.1.2 Java is highly platform independent

+\[RD01 - 12.1.1 Portability\]{+}

. GUIs are platform independent and can be developed on any system and run on any other system

{+}\[RD01 - 12.1.2 Extended Portability\]{+}

.
3.20.1.3 Java Applets can run inside Web Browsers for the deployment of low complexity GUIs on remote sites

+\[RD01 - 12.1.2 Extended Portability\]{+}

.
3.20.1.4 Both Java and Web Browsers have good CORBA support. JacORB

+\[RD34\]+

is the ORB currently used to provide CORBA support in Java.
3.20.2 ACS provides in addition a standard set of tools for the development of user interfaces

{+}\[RD01 - 12.1.3 Tools\]{+}

. This includes:
3.20.2.1 Integrated Development Environment. A COTS Java Integrated Development
Environment, including a GUI builder, has to be selected. The current choice is Eclipse

{+}\[RD35\]{+}

, that is a multi-platform, free project, with the Eclipse Visual Editor project plugin. There is no point in developing a proprietary tool.
3.20.2.2 Standard set of widgets for the implementation of applications with common look and feel. The adoption of the Characteristic Component concepts allows reuse of many Java Beans developed in the particle accelerator community specifically for the implementation of control systems. In particular the ABeans developed for ANKA

{+}\[RD04\]+

provide a set of widgets for ACS aware of of the Characteristic Component design pattern. ABeans are integrated in Eclipse

+\[RD35\]+

as a plugin that makes use of the Eclipse Visual Editor. Performance problems with the Abeans implementation limit their usage to small GUI applications, with a limited number of widgets.
3.20.2.3 Standard Java class libraries for the integration with all services provided by the
ACS.
3.20.3 The ALMA Executive subsystem has designed a standard GUI user interface architecture that allows to implement GUI plugins for the main Executive GUI.
3.20.4 Plotting will be an important element in GUIs (see also

+\[RD45 - EVLA  Engineering Software Requirements, 4 Plotting\]  \[RD46 - EVLA Array  Operations Software Requirments, 3.5 Plotting\]{+}

. ACS integrates an advanced
Java GUI class library

+\[RD47 - JFreeChart\]{+}

. Plotting widgets are integrated with ABeans for the development of applications and are available with all tools capable of monitoring values, like Object Explorer.
3.20.5 These Java and Python GUI tools allow developers and end-users to design and create their own display

+\[RD46 - EVLA Array Operations Software Requirments, 2.8 Display Builder\]{+}

.
3.20.6 All GUIs for generic ACS applications, (Object Explorer, logMonitor...) will be developed using ACS standard GUI libraries

+\[RD01 - 12.1.5 ACS GUIs\]{+}

. Tools, prototype and engineering GUIs can be implemented in Python.
3.20.7 GUIs shall not implement any control logic

{+}\[RD01 - 12.1.4 Modularity\]{+}

. They should be dummy applications that simply send commands to Components and access Properties of Characteristic Components for display and update. Any action performed through a GUI shall also be available using command line commands, script or simple programs and no GUI shall be strictly required to drive the system.
3.20.8 Online documentation and help
3.20.8.1 Integration with the Web through the usage of an HTML/XML Browser provides access to online documentation

+\[RD45 - EVLA Engineering Software+

+Requirements, 5 Documentation and Help\]  \[RD46 - EVLA Array Operations  Software Requirments, 1.4 Online Help\]{+}

.
3.20.8.2 Java help
Online help systems, for example for graphical user interfaces, shall use he the JavaHelp extension (http://java.sun.com/products/javahelp/index.jsp): help pages are written in html and they are rendered inside the application by the help browser that it pard of the Java Development Kit (jhall-2.0_02.jar). This allows to deploy help pages locally or throught the web and, the other way around, to reference and access web pages from the application's help browser.

...

3.20.8.6 The Java Web Start

{+}\[RD40\]+

technology is used to deploy and update GUIs and more in general Java applications on remote sites without requiring installation of specific and heavy software packages. Using this technology, GUIs do not run inside the Web Browser but as stand-alone applications.
3.20.8.7 LabView

{+}\[RD13\]+

can be integrated with ACS and be used, for example, as a platform to develop engineering GUIs. It is possible to implement ACS
functions in LabView applications via Code Interface Nodes (CIN). In this way LabVIEW GUIs can control and interact with standard ACS Components.

Anchor
_Toc125050 _Toc125050

3.21 Scripting support

3.21.1 Python

{+}\[RD24\]+

has been the chosen as the scripting language

{+}\[RD01 - 5.2.1 Scripts\]+

+\[RD01 - 10.5.6.Scripting language\]{+}

. Python, i.e. the C++ implementation, will be normally used. Special applications can use JPython (Java implementation).
3.21.2 It is used as a glue language between the high level interfaces and the control and data systems

{+}\[RD01 - 5.2.1 Scripts\]{+}

:
3.21.2.1 High level procedures of a coordination nature
3.21.2.2 System administration, replacing shell script languages for new developments
3.21.2.3 Rapid prototyping
3.21.2.4 Test applications and procedures
3.21.3 A Python Container supports the implementation of high level Components with a strong need for integrated scripting capabilities. Pipeline and data reduction recipes are typical examples. Such components will be used by higher level interfaces as coarse grained building blocks, easily modified and extended, that will in turn use lower level, fine grained C++ or Java Components.
3.21.4 Python provides access to the basic features of all Common Software services

+\[RD01 - 5.2.2.Functionality\]{+}

:
3.21.4.1 CORBA invocation of remote objects
3.21.4.2 A package of support classes implemented in the scripting language itself
3.21.5 Python

{+}\[RD24\]+

satisfies all requirements for the scripting language to be used in ALMA

{+}\[RD01 - 5.2.1 Scripts\]+

+\[RD01 - 10.5.6.Scripting language\]{+}

:

• Object Oriented
• Platform independent.
• Flow control, variables, and procedures.
• Plug and play to install scripting language.
• Connects to CORBA.
• Easy to use for non-programmers.
• Rapid Prototyping Similar to programming languages used in the project.
• GUI development.
• Embeddable into code for interactive applications.

Anchor
_Toc125051 _Toc125051

3.22 IDL Simulator

Simulation

+\[RD01 - 3.3.4. Simulation\]+

is supported within ACS at the level of
Components. That is, ACS provides the necessary libraries for dynamically
implementing IDL interfaces derived from the ACSComponent IDL interface at run-time.
3.22.1 The simulator framework is available by specifying a special Python library as implementing the Component within the ACS Configuration Database
3.22.2 The behavior of simulated components can be configured "ahead of time" using the ACS Configuration Database in cases where a standardized behavior is desired
3.22.3 Complete implementations of all IDL methods and attributes can be implemented on the fly by the simulator framework
3.22.4 The behavior of simulated components can be configured at run-time using:

...

3.23.1 The common software has to provide also an Application Framework allowing an easy implementation of a standard application (a skeleton application) with all essential features

{+}\[RD01 - 5.1.1 Framework\]{+}

. Inheritance and other mechanisms are used to enhance and extend the basic application according to specific application needs.
3.23.2 The application framework enforces common coding solutions and adherence to predefined standards.
3.23.3 The application framework shall be implemented as a set of classes that provide:

...

• State Machines are designed in UML

• The Open ArchitectureWare

  Wiki Markup
  +\[RD39\]+

  generator framework is used to generate Java code implementing the state machine

...

3.25.1 Device drivers for all standard boards (motor control, analog, digital, serial…) and network protocols (serial communication, CAN bus

{+}\[RD01 - 10.5.12 Field-+

bus],…) are provided as part of the ACS delivery, if they are not already part of the operating system, although development of device drivers is not direct responsibility of ACS. They will be typically provided as part of M&C software development and integrated into the ACS releases is considered necessary

{+}\[RD01 - 12.2.1 Hardware Interfaces\]{+}

. This integration must be taken into account both in the design of ACS and of Device Drivers.
3.25.2 A communication library working over CAN is already part of the M&C work

{+}\[RD12\]+

and has been harmonized with these concepts. For every CAN device there must be one or more Objects on the CAN bus master CPU, which are the abstract Characteristic Components corresponding to the physical CAN device.
3.25.3 Low level access to the CAN bus nodes iscompletely hidden to the general user (engineering applications can directly access the CAN nodes).

...

The common software provides and integrates also class libraries for astronomical calculation routines and data reduction (like SLA, TPOINT, AIPS++)

{+}\[RD01 - 5.3.3 Astrometry\]{+}

.
They are off-the-shelf packages only integrated and distributed within ACS. Their installation is optional and depends on the needs of a user for the specific package.
Depending on the specific licensing agreements, such libraries will be publicly available with each ACS installation package or only for specific ALMA internal distributions, where the library is actually used according to the agreed license.

...

• FITS package is made available for the handling of standard file formats (FITS files)

  Wiki Markup
  +\[RD01 - 7.2.1 FITS\]{+}

  .

• Mathematical libraries (Fats, Fitting)

  Wiki Markup
  +\[RD01 - 5.3.2 Mathematics\]{+}

  , units conversion and handling (based on the AIPS++ unit management classes)

• Plotting tools

  Wiki Markup
  +\[RD45 - EVLA Engineering Software Requirements, 4 Plotting\] \[RD46 - EVLA Array Operations Software Requirments, 3.5 Plotting\]{+}

  .

An advanced java class library for plotting and charts

+\[RD47 - JFreeChart\]+

is integrated in ACS as described in the User Interface Libraries and Tools section.
A Python library for plotting is also included to allow plotting from scripting language

+\[RD48 - Matplotlib\]{+}

. These are the building block for the implementation of a generic plotting tool a required in

+\[RD45\]  \[RD46\]+

. We plan to use already available tools built on top of these libraries, with minimal customization.

• Analysis tools

  Wiki Markup
  +\[RD45 - EVLA Engineering Software Requirements, 5+

Analysis]
Python numerical and mathematical libraries are integrated in ACS (see

+\[RD48 - Matplotlib\]+

and the family of related packages). AIPS++ is also available in ACS distributions and interoperable with ACS. These are all the building block needed to write analysis tools easily accessible to engineers and operators. We consider Python the best of the supported languages to provide such features, since users can develop easily own applications build on top of a basic framework.

• Documentation tools

  Wiki Markup
  +\[RD45 - EVLA Engineering Software Requirements,+

+5 Documentation and Help\]  \[RD46 - EVLA Array Operations Software  Requirments, 1.4 Online Help\]{+}

. See also GUI section for online and context sensitive help/documentation from applications.
ACS integrates tools to automatically produce architecture, design and code documentation in the various languages. The documentation is webbased and follows the standards defined by Software Engineering.
Java user interfaces will rely on standard Java documentation tools. ACS Logging System, Error System and Alarm System include features specifically designed to provide online documentation (see respective sections).

...

Security requirements, stated in

+\[RD01 - 9.1 Security\]+

are not analyzed in this document, but there is no indication that they cannot be met with the described architecture.

Anchor
_Toc125059 _Toc125059

4.2Safety

Requirement

+\[RD01 - 9.2.1. Safety\]+

does not impose any particular behavior on ACS, since it states that software based on ACS has no direct responsibility on human and machine safety.
Software limits will be directly supported in ACS

+\[RD01 - 9.2.2. Software limits\]{+}

. Applications will handle software limits as alarms on Properties representing the value to be kept within limit. In a typical case, a value with software and hardware limits will be handled using a 5-state alarm (normal, high/low SW limit, high/low HW limit). Reaching a software limit will trigger a callback in the application responsible to handle the limit condition.

...

Reliability requirements, stated in

+\[RD01 - 9.3 Reliability\]+

are not explicitly analyzed in this document, but there is no indication that they cannot be met with the described architecture. In particular, CORBA itself has been designed having high reliability and availability as a key requirement.

...

The current choices for hardware and software platforms and the architecture for ACS described in the previous sections should ensure that the required performances are achievable.
Basic performance requirements have been verified with ACS 0.0 on the Kitt Peak 12m antenna, with the TICS

+\[RD26\]+

and the Protype Pipeline, at the ATF and in the laboratories.
All performance requirements stated in

+\[RD01 - 9.4. Performance\]+

are being verified. A set of performance measuring suites aimed at implementing a realistic system in term of number and size of objects

+\[RD01 - 3.3.1 Size\]+

and of number of interactions has been implemented. Discussions and results of ACS performance measures are available in the ACS Wiki page {+}http://almasw.hq.eso.org/almasw/bin/view/ACS/AcsPerformances+. This includes a specific feasibility check of CORBA Audio Video Streaming service in relation to astronomical data transfer

+\[RD01 - 10.5.9 Data transfer\]+

and tests of the event and notification system and logging system performance.
For what concerns generic performance considerations for the ORB implementations we use, the corresponding web sites (referenced in the ACS online documentation pages

+\[RD41\]+

) contain a sufficient amount of information.
In the current implementation (ACS 6.0) XML is extensively used for the Configuration Database, for logging and archiving. The performances apper to be an issue for the logging system when low logging levels (trace and debug) are used. Therefore we have now implemented a new version of the logging system that does not use XML as transport protocol. We are evaluating the improvement in perfromance. Performance of XML does not appear to be an issue in the other cases, but this will have to be verified on a lager scale for scalability.

...

ACS is being designed and implemented according to what is specified in

+\[RD01 - 11. Life cycle aspects\]{+}

.
ACS uses procedures and standards already defined by the Software Engineering working group. In particular the software development process is defined by ALMA Common Software Development Plan

+\[RD32\]{+}

. This document describes also the scope and timetable of the planned ACS Releases.

...

Different versions of the system can exist in different places at the same time, with different Configuration Databases, but it must be possible to synchronize them (for example, development is done on a control model, with certain test motors, and installation is done on the telescope, that has different motors)

+\[RD01 - 13.1.5 Configuration\]{+}

.
Code does not always need to be recompiled if new IDL interfaces are made available or if an IDL interface is changed, for example adding new methods

{+}\[RD01 - 13.1.6. Modularity\]{+}

. With TAO and JacORB even if an application's interface changes, both client and server still work if they do not use the new features. It is possible to have the server exporting one version of the interface and the client use another version. If an interface changes, then recompilation is necessary (as expected) only for those programs that use the new feature or the methods that eventually changed signature. This should work also with other ORBs, since it is due to the existing CORBA IIOP protocol. On the other hand, this behavior is not explicitly supported and, should the IIOP protocol ever change, different interfaces might lead to run-time errors. While this is a potentially useful facility, its use would need to be standardized and carefully monitored to avoid unpleasant surprises at runtime. To date, this capability has not been used in ALMA.
ACS will be integrated and tested with any software specified in

+\[RD01 - 12.3.1 The ACS shall be integrated and tested\]{+}

.
5.1.1Portability and de-coupling from HW/SW platform
ACS shall be designed to be portable across Unix, Linux and RTOS platforms for what concerns its upper level components

+\[RD01 - 13.1.7 Portability\]{+}

.
The higher level of software in particular (co-ordination and user interface) should be as much as possible portable and de-coupled from any specific HW and SW platform. This pushes in the direction of the Java language and of the usage of a portable scripting language like Python

{+}\[RD24\]{+}

. Java virtual machines and Java ORBs are available on any platform and for any web browser. At present time there are still compatibility issues between Java Virtual Machines ("compile once, debug everywhere" syndrome), particularly on a UI with live content. Most interfaces are not "alive" and do not expose the incompatibilities, but many ALMA interfaces will have live content. Web browsers are particularly sensitive to compatibility problems since they usually incorporate outdated Java Virtual Machines. Experience has shown that it is best to limit the number of target platforms and that real-world Java programs should run as independent applications.
Java performance (initially an major reason for concern) is now adequate for
GUIs and for high-level coordination applications with no real-time performance requirements. Java performance is much worse when running on a remote XServer with respect to a local X-Server and, even more, a Microsoft Windows desktop. Java GUIs should therefore run preferably locally and not remotely. The ACS Architecture has been designed for this kind of usage.
It is then suggested to use C++ in performance demanding applications and Java everywhere else

+\[RD01 - 10.3.3 Compiled languages\]{+}

, with the exception of low level drivers that can be implemented in plain C language.
Java and C++ interface at the network level through CORBA via IDL interfaces.
Portability of C++ applications among different versions of UNIX and UNIX-like
RTOSs is improved by adopting the ACE libraries

{+}\[RD23\]+

and the Posix standard

+\[RD01 - 10.3.2 High level operating system\]{+}

, although at the RTOS level specific real-time features provided by the operating system (VxWorks for phase 1

+\[RD01 - 10.5.3 RTOS\]{+}

) can be used

{+}\[RD01 - 10.3.1. RTOS\]{+}

.
5.1.2Small, isolated modules for basic services
Basic services (for example logging and error system) must be independent from the other packages. Also, access to control system data must be de-coupled.
CORBA is very well suited for this, since ORBs are available on any platform and also inside web browsers to provide the basic communication layer.

...

The Requirements Compliance Table is now in the ACS Software Development Plan

+\[RD32\]{+}

.
This table provides a trace of all requirements expressed in the applicable ALMA documents.