Download PCES Problem

ADVANCED TECHNOLOGY CENTER
PCES Problem
Gary Wayne Daugherty
[email protected]
May 13, 2017
PCES problem
Table of Contents
1.
BACKGROUND ...................................................................................................................... 3
2.
PROBLEM ............................................................................................................................... 4
3.
REFERENCES ........................................................................................................................ 5
May 13, 2017
2
PCES problem
1. Background
The DARPA PCES program was established to address the problems of Program Composition for
Embedded Systems. According to the original BAA [1] some progress has been made in areas
related to real-time open systems, mobile code research, aspect-oriented programming, and
patterns. “However, technology support is limited and programming for real-time embedded
systems remains a time-intensive and error-prone process.”
The BAA then calls for research in the application of cross-cutting properties (aspects) to core
functional software, and in assuring that such properties fulfill real-time requirements related to
concurrency, synchronization, timing, fault-tolerance, and data persistence. The work in expected
to be in two main areas: one related to program transformation, the other, analysis. The BAA
appears to call for separate work in these areas with respect to each of the properties of interest,
e.g. separate tools for supporting the specification, analysis, and application of synchronization
aspects, etc.
“The focus of the PCES program is on program analysis and (property preserving) composition
techniques that can be used cooperatively to support real-time programming. Underlying issues
include aspect specification, interpretation, and checking; programming reusable and portable
aspect code; and aspect interference analysis. Approaches are strongly preferred that can be
extended to strategies for mobile code. These include strategies for incremental, off-line/on-line,
and staged analysis and composition.”
Officially the four technical topics addressed by the original BAA are:
1.
2.
3.
4.
Aspect Suites for Embedded Systems
Program Representation and Analysis
Program Transformational System
Stage Management System
May 13, 2017
3
PCES problem
2. Problem
The principal problem not yet addressed by the program is adaptation and optimization of the
software for the specific platform upon which it is to run, and the application it is to serve.
Optimization may be addressed in terms of both software and hardware, including hardware
compatible with the DARPA Polymorphous Computing Architecture (PCA) initiative [2]. In
addition to supporting the weaving of new behavior into an existing software core, support may be
provided for program level transformations. An emphasis should be placed on adherence to OMG
standards, and the leveraging of open source software solutions.
Consider the problem in terms of a minimal ORB, packaged for real-time, embedded devices. It
should be possible to adapt the ORB software to meet the needs of a specific type of application
by selecting the services it provides, and by defining the low level policies/patterns that it uses.
These patterns may include those already defined (e.g. by [3] and [4]), optimizations of these
patterns in terms of low level mechanisms, and other domain specific patterns, e.g. for safetycritical, fault-tolerant, FAA certified applications1.
In terms of the same example, it should also be possible for the ORB to adapt the underlying
software and hardware upon which it depends: the operating system, the virtual machine (if any),
the processor2, the protocol stack3, and other hardware elements4. The choice of platform will
restrict the set of options available, and different choices should be expected for different
platforms and applications. Different choices may also be made regarding whether to apply a
particular pattern/optimization statically (before run time) or dynamically (at run time), and
feedback from the run time environment may be used to influence choices, including those made
statically.
Proposals should initially provide at least an off-line solution, with plans for a migration to an online, run-time adaptable approach. Development of an off-line optimizer-generator is considered
an acceptable initial solution [5, slides 90-94]. Other solutions that address the key elements of the
problem (below) are also acceptable.
Key problem elements to be addressed:
1.
Definition of extensible meta-level notations for describing the structure, real-time aspects,
initial connections, and contracts between the model elements of a middleware application
2. Definition of aspect suites/patterns for low level application, ORB, OS, VM and hardware
adaptations and optimizations.
3. Optimization of existing middleware patterns, e.g. those appearing in [3] and [4].
4. Application of aspects/patterns to software written in any of variety of languages, e.g. to
ORBs, operating systems, and virtual machines written in Java, C++, C, etc.
5. Use of software transformations (rewriting rules) and refactoring “before”, “during” and
“after” compilation to optimize the resulting composition.
6. Adaptation of software to conform to guidelines for FAA certification.
7. Adaptation of software to the APIs provided by other software to which it must interface, e.g.
adaptation of the ORB software to various OS, VM and hardware interfaces.
8. Use of hardware to help address various ORB, OS, and pattern related optimizations.
9. Migration from an off-line to an on-line, run-time approach to the problem.
10. Adherence to OMG and other standards and interoperability with commercial tools that
comply with such standards.
The proposal should address integration with other projects already a part of the PCES program,
e.g. through agreement on the meta-level notations (above).
1
Memory allocation policies, for example, come into play for level A applications where traditionally all heap based
allocation must be done during initialization. Similar restrictions apply to requests for other shared resources at run time.
2
If micro-programmable or otherwise adaptable.
3
Whether implemented in software or hardware.
4
Especially those adaptable as defined by the PCA initiative.
May 13, 2017
4
PCES problem
3. References
[1] BAA #00-23: Program Composition For Embedded Systems (PCES), http://www.darpa.mil/
ito/Solicitations/CBD_00-23.html
[2] BAA #00-59: Polymorphous Computing Architectures (PCA) http://www.darpa.mil/ito/
Solicitations/CBD_00-59.html
[3] Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Bushmann. Pattern-Oriented
Software Architecture: Patterns for Concurrent and Networked Objects, Volume 2, John Wiley &
Sons, Ltd, 2000.
[4] Thomas J. Mowbray and Raphael C. Malveau. CORBA Design Patterns, John Wiley & Sons
Inc., 1997.
[5] Dr. Douglas Schmidt, Pattern-Oriented Software Architecture of Concurrent and Networked
Objects, OOPSLA Tutorial, October 16, 2000, http://www.cs.wustl.edu/~schmidt/posa.ppt
May 13, 2017
5