-
Notifications
You must be signed in to change notification settings - Fork 26
Project Proposals
Matias Mora edited this page Feb 13, 2015
·
18 revisions
This page lists project ideas for potential developments and collaborations within the ACS Community. Anyone is free to add ideas and/or pick up ideas for development. Please add new ideas at the page bottom, using the project template provided below.
The ACS Community Board is responsible for evaluating project ideas, assigning a relative priority (within the overall Community roadmap), seeking support for development, and keeping this page organized. The Community Control Board is responsible for suggesting feasible project ideas, providing technical guidance for ongoing projects, and enforce adequate coding and testing standards for code that is being integrated to the official Community repository.
Note that this is an intermediate staging area to pitch ideas and seek initial interest and support. Any projects that have been reviewed by the ACB and/or are already being developed should be consolidated in an associated issue ticket. Depending on the complexity and scope, one project proposal could eventually be consolidated into more than one individual task.
- Go to High Priority Projects
- Go to Medium Priority Projects
- Go to Low Priority Projects
- Go to New/Unclassifies Projects
- Description: What is this project about and what are its goals?
- Motivation: Why is this project relevant?
- Sponsor: Who is proposing/supporting/sponsoring this project?
- Priority: When would we like to see this implemented? (Short-term/Mid-term/Long-term/Nice-to-have, assigned by ACB)
- Issue Id: Where is this project being developed? (Link to issue tracker)
- Description: Make ACS compatible with the latest release of the JDK, Java 8.
- Motivation: New features in Java, such as lambda functions, as well as new functionality for GUIs in JavaFX are part of this release. Oracle has announced that it will soon stop issuing updates for the Java 7 SDK; in general, being compatible with the latest JDK is desirable (for example, Java 9 is scheduled to add module support to Java, which is very desirable). ACS has been tested to works without problems with the latest JDK 8 update, but building ACS fails on the compilation of JacORB 3.4; the problem has been fixed in JacORB 3.5, and merging that version into ACS might be all that is required.
- Sponsor: Proposing: J. Schwarz; Sponsoring: TBD
- Priority: High (desirable in the short-term)
- Issue Id: #30
- Description: Provide a community-supported code base for DevIO hardware drivers (e.g. CAN, OPC UA). Consolidate already existing contributions. Provide support for Linux RT Preempt as an alternative for the (proprietary) RTAI support.
- Motivation: Everybody using a control framework needs to interface with hardware devices at some point. ACS provides the DevIO layer to implement hardware drivers accessible through BACI. The implementations already tested by projects using ACS are key piece of software to be shared among projects using the same type of protocols. In particular, extending the support for commonly used hardware protocols is a fundamental part of facilitating the usage of ACS.
- Sponsor: ACB (general ACS usability)
- Priority: High
- Issue Id: #20 (partial)
- Description: Align BACI supported types among all ACS-supported languages (C++, Java, Python).
- Motivation: Since ALMA only uses C++ BACI properties the implementations in Java and Python have been on-demand and are in a relatively incomplete state. While other projects have interest in using Java properties, aligning all three languages is desirable for consistency.
- Sponsor: M. Fuessling; ACB (general ACS usability)
- Priority: High (Java), Low (Python)
- Issue Id: #24
- Description: Create a generic and extensible configuration database that can be stored in SQL tables and modified through a comprehensive GUI. Additionally, an open-source backend, such as MySQL should be supported. Use ALMA's "Telescope Monitor and Control Database" (TMCDB) and TMCDB-Explorer GUI as main reference.
- Motivation: ACS provides an XML configuration database (CDB), which is well suited for relatively small deployments. The TMCDB as developed for ALMA is supported on two database backends, hsqldb, a lightweight java rdbms suitable for unit testing or small installations, and Oracle, an expensive commercial DB chosen for ALMA production use. MySQL is an open-source alternative to Oracle, and in view of the unsuitability of Oracle (or probably any standard RDBMS) for the storage and retrieval of time-series (monitor) data, probably sufficient for most configuration uses. Systems of all sizes may benefit from an SQL-based database and corresponding access tools. While ALMA's TMCDB has proven to be a practical solution, it has many ALMA-specific parts and partially shared with other observatory subsystems. Other users have an interest in using a TMCDB-like solution and have advanced in adapting the relevant parts for their needs.
- Sponsor: Proposed by J. Schwarz and M. Mora
- Priority: High
- Issue Id: #28 (partial)
- Description: Identify a suitable IDE for all ACS-supported languages. Create plugins to integrate the ACS development environment and generate component code skeletons (see "code generation" project). Provide support for an automated ACS testing environment (ACS component code execution), e.g. integrating an acscommandcenter-like GUI, generating xUnit code skeletons, etc. Support easy deployment into target embedded systems (see "embedded platforms" project).
- Motivation: Integrated Development Environments (IDEs) ease the development of code in general and within complex frameworks in particular. They also have the potential to lower the learning curve of newcomers. While ACS ships Eclipse as its default IDE, it does not currently provide any integration. A working prototype of a Java plugin for Eclipse is currently available from a third-party repository.
- Sponsor: ACB (general ACS usability)
- Priority: High
- Issue Id: #32
- Description: CentOS is currently the official community supported platform, and sources are compatible up to CentOS 6. Port ACS to RHEL 7 (equivalent to CentOS 7 and SL 7) and gcc 4.8.2.
- Motivation: Keeping up to date with the latest officially supported Linux OS distribution.
- Sponsor: TBD
- Priority: Medium (desirable in the mid-term)
- Issue Id: #5
- Description: Compile ACS for ARM embedded platforms. Profile ACS container and clients to minimize memory/processor footprint.
- Motivation: For some specific hardware interfacing it is necessary to run at least parts of ACS in attached embedded systems. While modern embedded systems pose relatively less restrictions on memory and CPU resources, applications still need to optimize their use and be compiled for the specific target architecture. ARM in particular is one of the most widely used such platforms nowadays.
- Sponsor: ACB (general ACS usability)
- Priority: Medium (potential research projects)
- Issue Id: #3 (partial)
- Description: Define metrics and monitoring tools to measure service reliabilities. If deficiencies are detected explore improvement possibilities or implementation alternatives.
- Motivation: From operational experiences some ACS services have the potential to be improved or to exchange the underlying engine. Successful replacements such as the use of (proprietary) RTI DDS for the bulk data system instead of TAO A/V at ALMA show that it is possible to significantly improve system robustness and reliability in certain areas. There has been some progress in identifying possible improvements of the C++ logging system (e.g. using Log4cpp instead of TAO Log), and the notification service (e.g. using DDS instead of TAO NS). A systematic profiling and audit of existing services under conditions similar to currently expected use cases is desirable to take informed decisions.
- Sponsor: TBD
- Priority: Medium (potential research projects)
- Issue Id: #6 (partial)
- Description: Extend existing code generation engines (from 3rd party repositories) to all ACS-supported programming languages (Java, Python, C++); in particular code generation based on UML class and state machine models. Provide a code generation engine for characteristic components to expose hardware interfaces (translated into XML spreadsheets) through BACI properties.
- Motivation: Code generation can significantly accelerate the ACS component development process and lower the learning curve by hiding certain complexities and repetitive lines of code from the developer. It can also provide a skeleton implementation based on a UML model, similar to what modern modeling tools and IDEs provide. Successful usage of custom code generation at ALMA and AIRUB have shown this in practice.
- Sponsor: ACB (general ACS usability)
- Priority: Medium
- Issue Id: #20 (partial)
- Description: Implement efficient database support for the current BACI property monitor collector/blobber interfaces. Provide easy to use tools to access monitoring data, both for small and large deployment scenarios.
- Motivation: ACS provides a generic monitor collector mechanism for C++ containers to process any type of BACI values in regular intervals and make them available as "blobs" to a subscribed blobber component (implemented in Java). A blobber can then store monitoring data through a generic DAO interface, which can be implemented using any desired persistence backend. In the case of ALMA at least two different DAOs have been implemented: an SQL database DAO using Hibernate; and a publisher DAO that sends data to an ActiveMQ queue, which can then be consumed by different processes to persist data in various ways (e.g. plain text documents, MongoDB, trending engines, etc.). Further, tools to access monitoring data in an efficient way and produce trending statistics are desirable to add statistical value.
- Sponsor: M. Fuessling
- Priority: Medium
- Issue Id: #20 (partial)
- Description: Implement an asynchronous call engine that is component/container independent. The engine should be generic enough to support any kind of callbacks (derived from the Callback interface), not only ACS callbacks.
- Motivation: Currently only limited support for asynchronous IDL method calls exists in C++ and Java. To provide consistency and ease of maintenance, a more complete and generic approach should be provided.
- Sponsor: ACB (language consistency)
- Priority: Medium
- Issue Id: #31 (partial)
- Description: Improve the way ACS is distributed by avoiding duplicate shipping OS-provided packages, dividing the traditional tarball into modular packages (e.g. RPMs) and updating to an according build system (e.g. automatic dependency resolution among packages).
- Motivation: A large repository makes checking out a full copy impractical, in addition to size restrictions in github. Duplication of third-party binaries is unnecessary if available online. A user could be interested in only certain parts of ACS, or a deployment with limited storage capacity could require deploying only a subset of the distribution (e.g. isolated services; C++ container-only embedded environment).
- Sponsor: ACB (general ACS usability)
- Priority: Low (desirable in the long-term)
- Issue Id: #1, #16, #17 (partial)
- Description: Port ACS to platforms other than RHEL-compatible Linux distributions, such as other Linux distributions (Fedora, Ubuntu, Debian), Apple OSX and MS Windows. Support for 32bits and/or 64bits architectures should be considered in each case. This task must include a plan to maintain compatibility for latest OS releases and the support on one or more build servers (i.e. automated execution of builds and tests and availability of a binary repository).
- Motivation: Different projects have expressed an interested in using ACS on other platforms.
- Sponsor: TBD
- Priority: Low (depends on user requirements)
- Issue Id: #10, #22, #23 (partial)
- Description: Provide "tight" container implementations in C++ and Python. Review and integrate the current C++ implementation (from 3rd party repository).
- Motivation: Currently only the Java container has a "tight" implementation (i.e. allows to intercepts all function calls), using dynamic proxy interfaces. C++ and Python containers are only "porous" (i.e. forwards all functional calls directly to the component implementation objects). Some advantages of providing call interceptors for all supported languages are: (1) error traces could contain more complete messages (e.g. set the SourceObject filed); (2) the component initialization model could be changed freely (i.e. simplify init dependency issues); (3) provide more complete log information, which would allow to trace actions triggered from high-level components/GUIs through the system.
- Sponsor: ACB (language consistency)
- Priority: Low
- Issue Id: #20, #31 (partial)
- Description: Review the Python API and identify missing capabilities compared to other ACS-supported languages. Add missing capabilities.
- Motivation: The Python API is not as complete as the C++ and Java APIs, mainly because of the rather limited use of Python components in existing projects. Capabilities like e.g. repeat guards are missing and should be provided to allow a more intensive usage of Python containers/components.
- Sponsor: ACB (language consistency)
- Priority: Low
- Issue Id: #31
Not yet reviewed by ACB.