Garching - 15th - 19th January, 2007 ACS: status and latest development The ACS Team

2 Garching 15th – 19th rd ALMA Common Software Workshop What is ACS? ACS is a software infrastructure for the development of distributed systems based on the Component/Container paradigm end-to-end: from data reduction to control applications common application framework and design patterns, not just libraries well tested software that avoids duplication make upgrades and maintenance reasonable common development environment and tools

3 Garching 15th – 19th rd ALMA Common Software Workshop Where are we? Developed for ALMA and used by several other projects. ACS is based on a kernel of software contributed by cosylab and developed for the ANKA Synchrotron. Our collaboration started in Trieste at ICALEPCS ½ of allocated development effort spent until now Total allocated ~30 man years + additional external contribution (~10). 11 th release (now 1 major release per year) Extensively used in the field: –ALMA Test Interferometer and labs –ALMA software integrations –Other projects

4 Garching 15th – 19th rd ALMA Common Software Workshop ACS installations and projects

5 Garching 15th – 19th rd ALMA Common Software Workshop Main Features ACS provides the basic services needed for object oriented distributed computing. Among these: –Transparent remote object invocation –Object deployment and location based on a Container/Component model –Distributed error and alarm handling –Distributed logging –Distributed events –Device control The ACS framework is based on CORBA and built on top of free CORBA implementations.

6 Garching 15th – 19th rd ALMA Common Software Workshop Supported Platforms Operating system: Linux, RH-E + other flavours (some projects also use MS-Windows) Real-time: RTAI and VxWorks Languages: C++, JAVA, Python CORBA middleware: TAO (& ACE) (C++), JacORB (Java), Omniorb (Python), CORBA services. Embedded ACS Container: PC104, Debian, 300Mhz Geode, 256MB RAM, 256 MB flash (CosyLAB microIOC)

7 Garching 15th – 19th rd ALMA Common Software Workshop LGPL and free software The strategy to provide common features to our users is: –Use as much as possible open-source tools, instead of implementing things. Do not reinvent the wheel Reuse experience of other projects Do not pay for licenses Support from user’s community –Identify the best way to perform a task among the possibilities –Wrap with convenience and unifying APIs ACS is distributed under LGPL license

8 Garching 15th – 19th rd ALMA Common Software Workshop Container/Component model ACS container Component My container starts and stops me and offers its services, some of which I don’t notice I only care about the Lifecycle IF of my components Component All application software is written as Components that run inside Containers that ACS provides.

9 Garching 15th – 19th rd ALMA Common Software Workshop Container/Component IFs container Comp CORBA ORBs Services lifecycle interface: init() cleanUp() Comp functional interface: observe() container service interface getComponent(“CompB”); Logger getLogger(); other ACS services Manager deployment configurations

10 Garching 15th – 19th rd ALMA Common Software Workshop Container/Component evolution In recent releases we have improved decoupling of Components and Containers: –Full separation between Container and Container Services Cleaner interfaces Easier to replace Container implementation –Dynamic components –Tasks We have implemented automatic and dynamic deployment of Containers (ACS Daemon). Configuration of the runtime system is being discussed. We are working on better tools to keep aligned the configuration of the various ALMA deployments

11 Garching 15th – 19th rd ALMA Common Software Workshop Central Deployment and System Configuration ACS provides a Configuration Database (CDB) System deployment: CDB contains information about which components should run in which containers –this deployment step must not be hard-coded to allow for flexible scenarios, such as unit tests, integration tests, real system, … CDB contains configuration data to control the runtime behavior of Containers and Components, down to the level of hardware-related “properties”. The important idea is to keep this kind of information central, not spread across computers.

12 Garching 15th – 19th rd ALMA Common Software Workshop Master Component ALMA subsystems interact with the Executive. Executive treat all in the same way.  Lifecycle for subsystems, not only components Fits smoothly into acs concept: -each subsystem needs a mastercomponent -it is a component with a specific interface -ACS defines the underlying state machine Implementation: -a generator (using open-architectureware) maps UML to state machines -generator creates convenience base classes -state machine has been refined in a couple of design iterations The introduction of the Master Component has been very effective. Cost of prototype generator not higher than cost of developing the MasterComponent in code

13 Garching 15th – 19th rd ALMA Common Software Workshop Multithreading and distributed applications Component based systems like ACS are intrinsically: –Highly distributed –Asynchronous and multithreaded Methods can be called at any time, in parallel to the same or other methods. Developers need to be well aware of concurrency issues

14 Garching 15th – 19th rd ALMA Common Software Workshop Multithreading and distributed applications: the solutions ACS addresses the problems in handling concurrency and multithreading by means of: Threading management classes Centralized logging Distributed error handling Dynamic loading/unloading of Components Component’s simulation Tools for automatic regression tests involving distributed Components

15 Garching 15th – 19th rd ALMA Common Software Workshop Logging System To publish any kind of status and diagnostic information for interested clients and archival. Log records coming from anywhere in the system are centrally joined together. Based on CORBA Telecom Logging Service. Simple API looks like local logging –Java: java.util.logging.Logger (JDK standard) –C++: ACE logging –Python: logger.logWarning(‘my little message') Context information added automatically (class/method/thread name, timestamp, …)

16 Garching 15th – 19th rd ALMA Common Software Workshop Logging performance Average C++ throughput (100 bytes) : Local: 3500 logs/s Remote: 2500 logs/s

17 Garching 15th – 19th rd ALMA Common Software Workshop Error System Exception handling across processes, operating systems, languages. Hides shortcomings of CORBA exceptions –allows daisy-chained exceptions (“ErrorTrace”) –in Java: mapped to native exception mechanism –simulates inheritance hierarchy Code generated from central definitions Not only for exceptions, but also for asynchronous non-error feedback to caller (status info, call completion)

Garching 15th – 19th rd ALMA Common Software Workshop CERN Laser ACS Alarm System: Laser Collaboration with CERN 1 st official release with ACS 6.0 Keep the same API Reuse the Laser Alarm Console ACS Component/Container replaces J2EE acsjms implements jms for ACS on top of Notification Channel IDL interfaces replace EJB interfaces Reimplementatio n of Laser interfaces The challenge: reuse a complete subsystem/service in a very different software infrastructure

19 Garching 15th – 19th rd ALMA Common Software Workshop Communication between Components ACS provides 4 ways to communicate between Components: –Synchronous method calls –Asynchronous method calls (callbacks) –Notification channel (publisher-subscriber) –Bulk data (hi-performance streaming, 60 Mbytes/s)

20 Garching 15th – 19th rd ALMA Common Software Workshop Notification channel usage Notification Channel has been used much more than expected to: –Synchronize subsystems: synchronization events –Publish data to multiple subscribers, not known a priori Preferred to callbacks because easier to implement Very easy to use: evolution of ACS implementation classes, coding conventions and tools Drawbacks: –more difficult to keep track of dependencies –Circular dependencies make a system more fragile

21 Garching 15th – 19th rd ALMA Common Software Workshop Event Handling and Notification Channel Events are widely used in ALMA for synchronization and asynchronous, *-to-* communication. Decoupling of Consumers and Suppliers Very easy interface: –Supplier classes –Consumer classes Contract based on IDL data structures. Strong naming conventions and checking tools Administrative interface Quality of service

22 Garching 15th – 19th rd ALMA Common Software Workshop Events performance Average C++ throughput: 1500 event/s (100 bytes), both remote and local

23 Garching 15th – 19th rd ALMA Common Software Workshop Bulk Data Transfer Requirements from the correlator: –64 MB (megabyte)/sec Based on CORBA A/V streaming service TAO C++ implementation Very easy interface, based on our use cases No CORBA A/V visible Gigabit Ethernet BD throughput 1 receiver around 800 Mbits/s (~100 MB/s) three receivers >700 Mbits/sec. requirements fulfilled CORBA throughput around then 500 Mbit/s (~ 55 MB/s) Estimated gain in the throughput around 30%

24 Garching 15th – 19th rd ALMA Common Software Workshop Device Control: Component-Property-Characteristics Component: software representing a physical/logical device (e.g. temperature sensor, motor) Each Component can have Properties ( e.g. status value, position - control/monitor points). Characteristics of Components and Properties (static configuration data, e.g. serial number, CAN-Bus-ID, default value) Characteristic Model Characteristic 0..n Component 0..n type Property 0..n Standard pattern for control systems

25 Garching 15th – 19th rd ALMA Common Software Workshop Device Control: Support for Properties Clients get/set the value or properties. Clients can monitor property values (callback mechanism) –fixed time intervals –value triggered –alarms GUI widgets: Control GUI applications connect widgets to properties for value display and manipulation

26 Garching 15th – 19th rd ALMA Common Software Workshop Device Control: Device Abstraction (“DevIO”) ACS design of properties decouples functionality from actual storage of the property value: –ACS delivers RO- and RW-properties for Double, Integer, String, Enum types, and arrays of these. –ACS delivers DevIO “plug-ins” for in-memory, CAN bus, socket, Joystick, and other storage. To set/retrieve property values with different hardware, users can write their own plug-ins.

27 Garching 15th – 19th rd ALMA Common Software Workshop container Comp Transparent XML Integration container Comp XML Comp Flat-XML API seen from outside Transparent-XML API seen by the Component Mapping code layer XML

28 Garching 15th – 19th rd ALMA Common Software Workshop Simulation Why simulation? –Distributed development –Features or entire subsystems not yet available –Test a subsystem in isolation Simulation of Components from IDL interface spec. Dumb default or “intelligent” simulation

29 Garching 15th – 19th rd ALMA Common Software Workshop Performance and Benchmarking ACS has performance requirements to satisfy Changes to code and upgrade of external libraries can affect performance Created performance measurements and reporting framework Performance of Component to Component communication, notification channel, logging Effort on performance assessment under way. Soon data available

30 Garching 15th – 19th rd ALMA Common Software Workshop Conclusion Core concepts are now very stable. Most packages are implemented, but not 100% Most of the work comes now from change requests and feedback and not from long term planning items ACS is significantly improving in stability, usability and global consistency. Analysis of the applications developed and of the feedback from the developers tells us what is good, what is bad and how to improve. Having a user’s base in addition to our main project has provided important feedback, cross-fertilization of concepts and ideas and contributed to software quality

31 Garching 15th – 19th rd ALMA Common Software Workshop Questions (& Answers) Documentation, papers and other information: