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.
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 re-compilation 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].
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 X-Server 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].
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.