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 [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.

1 - Base Tools

The bottom layer contains base tools that are distributed as part of ACS to provide a uniform development and run time environment on top of the operating system for all higher layers and applications. These are essentially off-the-shelf components and ACS itself just provides packaging and installation and distribution support. This ensures that all installations of ACS (development and run-time) will have the same basic set of tools with versions kept under configuration control.

The exact set of tools and versions are described in the documentation coming with each ACS release. Being these normally big packages the ACS installation procedures will have to offer the options of installing the tools in binary format, building them from sources or using an independent installation.

Three main packages have been identified in this layer:

• Development tools
  Software development tools (compilers, configuration controls tools, languages, debuggers, documentation tools).

• CORBA Middleware
  Packaging of off-the-shelf CORBA implementations (ORB and services) to cover the languages and operating systems supported by ACS.

• ACE
  Distribution of the Adaptive Communication Environment[RD23].

2 - Core components

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

• ACS Component
  Base interfaces and classes for Component part of the ACS Component Model. In particular C++ Distributed Objects, Properties and Characteristics are implemented in this package.

• Configuration Database
  Interfaces and basic implementation for the Configuration Database from where ACS Components retrieve their initial configuration

• Event and Notification System
  The Event and Notification System provides a generic mechanism to asynchronously pass information between data publishers and data subscribers, in a many-to-many relation scheme.

• Error System
  API for handling and logging run-time errors, tools for defining error conditions, tools for browsing and analyzing run-time errors.

• Logging System
  API for logging of data, actions and events. Transport of logs from the producer to the central archive. Tools for browsing logs.

• Time System
  Time and synchronization services.

3 - Services

The third layer implements services that are not strictly necessary for the development of prototypes and test applications or that are meant to allow optimization of the performances of the system:

• ACS Container
  Design patterns, protocols and high level services for Component/Container life-cycle management.

• Serialization Plugs
  This package provides a generic mechanism to serialize entity data between high level applications, typically written in Java.

• Archiving System
  API and services for archiving monitoring data and events from the run time system. Tools to browse, monitor and administer the flow of data toward the archive.

• Command System
  Tools for the definition of commands, API for run-time command syntax checking, API and tools for dynamic command invocation.

• Alarm System
  API and tools for configuration of hierarchical alarm conditions, API for requesting notification of alarms at the application level, tools for displaying and handling the list of active alarms.

• Sampling
  Low level engine and high level tools for fast data sampling (virtual oscilloscope).

• Bulk Data
  API and services for the transport of bulk science data (images or big data files) and continuous data streaming.

4 - API and High-level tools

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 .

• Parameters
  Support libraries and classes for "parameter sets", i.e support for definition, parsing and validation of sets of parameters, plus some additional metadata such as help information, valid ranges, default values, whether the parameters are required or optional, etc.

• Task
  A task is a concise program which starts up, performs some processing, and then shuts down. A task may or may not require other more advanced ACS services, depending on context.

• Scripting
  Scripting language and access libraries for the integration with ACS core components.

• ACS Application Framework
  Implementation of design patterns and to allow the development of standard  C++, Java and Python applications using ACS services.

• ACS Installer
  Tolls for installing ACS with different options.

5 - Integrated APIs and tools

The 5^th  group of packages contains 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. The list of packages will be extended according to the ALMA integration needs. If considered useful, some packages can be hidden on the back of an ACS abstraction layer with the purpose of facilitating the usage of the package and its integration with other ACS facilities (like error and alarm handling). In this case the package would be moved in layer 4 of the ACS architecture.

• Device Drivers
  Low-level device drivers for commonly used devices

• Astronomical libraries
  Libraries for astronomical calculations and data reduction.

• External libraries
  Support for the handling of FITS files is just an example of other high-level components that will be integrated and/or distributed as part of ACS.

Component Container model

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:

• "is coarse grained: In contrast to a programming language class, a component has a much larger granularity and thus usually more responsibilities. Internally, a component can be made up of classes, or, if no OO language is used, can be made up of any other suitable constructs. Component based development and OO are not technically related."

• "requires a runtime environment: A components cannot exist on its own, it requires something which provides it with some necessary services." This "something" is called a Container.

• "is remotely accessible, in order to support distributed, component based applications."

The division of responsibilities between Components and Containers enables decisions about where individual components are deployed to be deferred until runtime. If the container manages component security as well, authorization policies can be configured at run time in the same way.

A Component is required to provide:

• a Lifecycle interface, so that the Container where it resides can manage it

• a Service interface, that is the interface it exposes to clients

A Container is required to provide:

• an implementation for all basic services used by the Components

• a ContainerServices interface used by the Components to get access to the services

ACS provides a simple implementation of the Component-Container model implemented in C++, Java and Python.

In order to decouple the Component and Container implementations, the ACS Component package contains the definition of all the interfaces needed for the implementation of Components and the default implementation of the interface which can be used as base classes for the Components themselves.

The ACS Container package contains the actual implementation for the Container model, including the high level management of Containers (Manager). The following diagram provides an overview class diagram of the Component-Container model. More details are given in the description of the Component and Container architectural packages.

Figure 2.2: ACS Component-Container overview class diagram

For a more detailed discussion of rationale behind the choice of the Component-Container model, see the ALMA Software Architecture document [RD33].

Deployment

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

Figure 2.3: ACS Deployment

• Linux Development workstation
  Linux is the main development and run-time platform.
  This installation includes all ACS components necessary for development and at run-time. 

• Windows Development workstation
  Windows is a development and run-time platform for Java based applications and user interfaces. In some cases and in particular for very high level tools that have to be installed on the premises of astronomers, it is explicitly required that they be supported on various platforms. Developing not only from a Linux but also from a Windows environment would help in ensuring better compliance with Java Virtual Machines on various platforms.
  An ACS Windows Development installation will allow installing Java development tools and Java libraries for development, including CORBA ORB and services.
  We assume that an ACS developer will have a Windows desktop used for Java development and as a terminal to connect to a Linux Development Workstation. This does not exclude users having access only to Linux workstations but limit their capability and/or comfort in developing Java applications. 

• Linux Real Time Computer
  Linux real time computers can be normal PCs or VME racks with Intel CPU running a real time Linux kernel.

• Linux run-time workstation
  When disk space is an issue for small run-time only boxes, it will be possible to deploy on ACS runtime libraries and components. The main limitation of this configuration is that it offers very poor debugging capabilities in case of problems, with respect to a full development installation 

• Remote user station
  A very light ACS installation will be provided for users that need only to run Java/Python applications to remotely interact with other ALMA subsystems. This will allow installing only Java/Python ACS run time libraries and applications (including CORBA ORB and services) on Linux, Windows or other operating systems supporting a Java Virtual Machine (officially supported and tested Java Virtual Machines will be defined at each ACS and specific application release) or a Python interpreter.

• VxWorks real-time computer (not used in ALMA)
  VxWorks computers are used only as run time platforms, as a cross-development computer is necessary to develop code.
  ACS will deploy on VxWorks only run time libraries, which are downloaded from a file server at boot time or when needed.
  VxWorks computers have been phased out from ALMA and replaced by computers running a real-time Linux kernel. 

• Linux VxWorks cross-development workstation
  The VxWorks cross development environment is installed on a Linux workstation. This includes all development tools and ACS components. Typically the same development workstation should be used for Linux and VxWorks development. We are constrained by the fact that WindRiver does not support Linux as a VxWorks cross-development environment for the version of VxWorks we support in ACS. We have now a cross development environment for Linux, but we cannot run Wind River debugging and development tools there. Therefore we use normally Linux for cross-development, but it might be convenient to keep available Sun workstations when we need to run Wind River development tools. Sun has been phased out from ALMA together with VxWorks.