ACS status and latest development The ACS Team

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

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 2

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 1999. • ½ 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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 3

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

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. Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 5

Supported Platforms • Operating system: Linux, RH-E + other flavours (some projects also use MS-Windows) • Real-time: RTAI and Vx. Works • Languages: C++, JAVA, Python • CORBA middleware: TAO (& ACE) (C++), Jac. ORB (Java), Omniorb (Python), CORBA services. • Embedded ACS Container: PC 104, Debian, 300 Mhz Geode, 256 MB RAM, 256 MB flash (Cosy. LAB micro. IOC) Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 6

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 7

Component Container/Component model ACS container 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 All application software is written as Components that run inside Containers that ACS provides. 19. November 2002 8

Container/Component IFs functional interface: container service interface observe() CORBA ORBs Services 19. November 2002 Comp init() clean. Up() Comp lifecycle interface: get. Component(“Comp. B”); Logger get. Logger(); container Manager deployment configurations other ACS services 9

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 10

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. Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 11

Master Component • • ALMA subsystems interact with the 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 Master. Component in code • • Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 12

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 13

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 14

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. log. Warning(‘my little message') • Context information added automatically (class/method/thread name, timestamp, …) Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 15

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

Error System • Exception handling across processes, operating systems, languages. • Hides shortcomings of CORBA exceptions – allows daisy-chained exceptions (“Error. Trace”) – 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 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 17

ACS Alarm System: Laser • Collaboration with CERN • 1 st official release with ACS 6. 0 Reuse the Laser Alarm Console Reimplementatio n of Laser interfaces Keep the same API CERN Laser ACS Component/Container replaces J 2 EE IDL interfaces replace EJB interfaces acsjms implements jms for ACS on top of Notification Channel The challenge: reuse a complete subsystem/service in a very different software infrastructure

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) Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 19

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 20

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 21

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

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 • • • Garching 15 th – 19 th 2007 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% 3 rd ALMA Common Software Workshop 23

Device Control: Component-Property-Characteristics • Component: software representing a physical/logical device Characteristic Model 0. . n Characteristic (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) Garching 15 th – 19 th 2007 type 0. . n Component 0. . n Property Standard pattern for control systems 3 rd ALMA Common Software Workshop 24

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 25

Device Control: Device Abstraction (“Dev. IO”) • 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 Dev. IO “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. Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 26

Transparent XML Integration Flat-XML API seen from outside XML 19. November 2002 container Comp Transparent-XML API seen by the Component Comp Mapping code layer container 27

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 28

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 http: //www. eso. org/~almamgr/Alma. Acs/Performance/Benchmark. Doc/ Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 29

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 Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 30

Questions (& Answers) Documentation, papers and other information: • http: //www. eso. org/projects/alma/develop/acs Garching 15 th – 19 th 2007 3 rd ALMA Common Software Workshop 31