Introducing Predictable Assembly from Certifiable Components (PACC)
KURT WALLNAU

In September 2002 the SEI launched a new initiative, Predictable Assembly from Certifiable Components (PACC). This new initiative is developing technology and methods that enable software engineers to predict the runtime behavior of assemblies of software components from the properties of those components. This requires that the properties of the components are rigorously defined and trusted and can be certified by independent third parties.

PACC builds on past and, in some cases, ongoing SEI research in software architecture and in the use of commercial off-the-shelf (COTS) software. The work reflects clear industry trends toward greater use of software-component technology and increasing concern with the quality of software systems.

Nothing serves so well as an illustration, so that’s where I’ll start. Then I’ll introduce the key principles and technologies underlying our approach, which is called prediction-enabled component technology (PECT). I’ll wrap up by describing what we’re currently doing, open challenges, and next steps.

A Simple Illustration

In PACC our concern is to predict the runtime behavior of assemblies of components. By runtime behavior we mean any behavior of a system that is directly or indirectly observable on the executing system. For convenience, we refer to any such observable behavior as a runtime property.

In this illustration I’ll use execution latency, i.e., the time it takes an assembly to perform a task, as the runtime property we wish to predict (our work on automatic verification of reliability properties through model checking will be the subject of a future article). The illustration is drawn from a proof of feasibility of PACC for power transmission and distribution (see Predictable Assembly of Substation Automation Systems: An Experiment Report for details).

A power substation serves several purposes, among which is protection and control of primary equipment, such as transformers, circuit breakers, and switches. Our task is to develop, from software components, a controller for a high-voltage switch. One function of the controller is to provide an interface that allows operators to manually open and close the switch. We wish to predict the time it takes a controller to process operator requests, and the time it takes the controller to report on the change in switch status.

The illustration in Figure 1 presents the gestalt of the software engineering task in terms of PACC. We assume that a set of software components already exists, and that the service time of these components (defined as the time it takes the component to do its work, assuming no blocking or preemption) has been obtained (1 in the figure). The software engineer selects a set of candidate components, and composes their specifications to produce a model of the controller assembly, which is analyzed and from which latency is predicted (2 in the figure). If the predicted latency satisfies requirements, the components (rather than their specifications) are composed and the resulting assembly is deployed. Predictions are only predictions if there is a possibility that they are wrong, so some validation is required of the deployed assembly (3 in the figure).

Figure 1: A Predictable Substation Assembly

This much might have been guessed from the name of the PACC initiative. However, technology being developed by the SEI aims to increase the level of automation in the assembly, prediction, and composition processes, and to provide an objective and quantified basis for trusting component properties and the predictions that are based on these properties. In particular, using this example:

• Latency prediction for user-selected controller operations (e.g., from arrival of an operator request on w until the switch is signaled on x in Figure 1) is computed automatically from assembly specifications.
• The analysis model used to make latency predictions defines precisely what runtime properties of components must be known and how these properties are specified and obtained. Thus, the properties of components that must be trusted are precisely those that enable predictions of assembly runtime behavior.
• The assumptions underlying the analysis model about how components interact with their environment and with each other are made explicit. Assemblies are well formed if they satisfy these assumptions. Well-formedness is checked automatically—thus, assembly behavior is predictable by construction.
• The accuracy and reliability of analysis-model predictions is objectively validated using statistically sound sampling and measurement. These qualities of predictions are certifiable properties of the analysis model itself, and are specified as a confidence interval for predictions—e.g., 9 out of 10 predictions will have an upper error bound of 3% with a 95% confidence.

We are concerned with more than just the timing properties of assemblies—e.g., reliability (an area of current work) and security (an area for future work). Therefore, the technology being developed by the SEI to enable PACC can be applied to many analysis models.

Prediction-Enabled Component Technology—Just the Basics

Our approach to achieving the above objectives is to use prediction-enabled component technology (PECT). Here I will limit the description of PECT to the simple core ideas. Readers interested in the more comprehensive treatment are referred to Volume III: A Technology for Predictable Assembly from Certifiable Components.

As its name suggests, a PECT is an enhanced component technology. What is a component technology? There is no answer to this question that won’t provoke an argument, any more than there is a universally agreed-upon answer to the question What is a component? Nonetheless, there is growing agreement on the following rough definition:

• A software component is an implementation, ready to execute on some (possibly virtual) machine, with well-defined interfaces that enable third-party composition (roughly, integration with other components).
• A component technology is a component model and runtime environment where
  • the component model specifies what interfaces a component must provide, and how components are allowed to interact with one another and their runtime environment
  • the runtime environment is a container in which component behavior executes and in which components interact. The runtime environment may also provide useful services—persistence, transactions, etc.

Regular readers of this column will notice the similarity between this definition of component model and the usual definition of architectural style (or pattern) as a collection of component types and their allowable patterns of interaction. Even though they may differ in many respects, a component model and architectural style both specify invariants that must be satisfied by any instance of that model/style. These invariants are exactly those “well-formedness” rules that we impose on component assemblies to ensure that they can be analyzed, and therefore to ensure their predictability.

Seen in this light, a component technology can be thought of as an infrastructure for designing, developing, and deploying applications that adhere to a particular architectural style. The infrastructure does restrict the freedom of developers and designers, but in compensation it enforces design and implementation invariants that, in this case, ensure predictability. The tradeoff between restricted freedom and predictability has been seen before—in the development of strongly typed programming languages, now considered an essential element of modern software engineering practice. The long-awaited shift to a higher level of abstraction—from functions and classes to components—is underway.

Figure 2 provides a concise description of the structure of a PECT in the Unified Modeling Language (UML). Even readers not fully familiar with UML should be able to use this model to follow along, as there are only a few points to make that have not already been stated explicitly.

1. The construction language in Figure 2 could well be any architecture description language that supports primitive notions of component and connector. The notation and tools we use (of our own making) will likely be replaced by the first usable UML 2.0 tools.
2. A PECT can and generally will support several analysis models, each of which is “packaged” in its own automated reasoning framework. An interpretation defines an automated translation from assemblies of components specified in the construction language to the reasoning framework.
3. PECT as a general concept does not depend on any component technology, but any PECT will. An abstract component technology specifies the invariants imposed on by a specific component and a collection of reasoning frameworks (each which may impose its own additional invariants).

Figure 2: A UML Model of the Structure of a PECT

The SEI PACC initiative has developed several prototype demonstrations of PECT, and as a result we are gaining experience in the methods and technology infrastructure needed to achieve the levels of automation and trust we are seeking.

Status and Challenges

We are developing methods and tools that will enable the software industry to introduce predictable assembly from certifiable components into practice. Although the initiative is less than a year old, we are already working with an industrial sponsor, the ABB Group (Asea Brown Boveri, Ltd.), to demonstrate PECT feasibility in challenging industrial settings, currently in the domain of industrial robotics. Our current focus is on demonstrating PECT in incrementally more demanding and larger scale industry and DoD settings, and in documenting the methods we use to develop and validate PECTs. We are also broadening our repertoire of reasoning frameworks to include a variety of performance-analysis models, as well as automated verification (through model checking) of specific component and assembly-reliability claims.

Although we believe that we have demonstrated the potential of PECT, there are several challenges that must be met if the ideas are to find widespread use and acceptance:

• Techniques for certifying, and labeling, component properties required by reasoning frameworks must be developed.
• The business case for PECT must be established, since the development of PECTs requires substantial up-front investment.
• The engineering methods and technology needed to build and use PECTS must be better understood, documented, and supported by commercial tools.

Although these are serious challenges, the needs addressed by PACC are real and immediate. Moreover, progress is being made, and not just at the SEI. Academic research and industrial practice are moving in the direction of predictable assembly, and the guaranteed component quality is demanded by the marketplace, by societal needs, and by our own quest to establish rigorous foundations for software engineering practice.

If PACC were to be summed up in a single sentence, it would be that it allows us to shift our focus from predicting the runtime properties of assemblies to building only assemblies whose properties we can predict.

For more information about PACC or to inquire about opportunities to collaborate with the SEI in this research, see the PACC Web site.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.