14.2 Advanced Concept Description: The Research Problem
Twenty-first century Space Wide Web (SWW) distributed component-based software applications will dwarf today's increasingly complex World Wide Web (WWW) environments, supported by earth-bound low-orbit satellite constellations, and will represent a far more significant investment in terms of development costs, deployment, and maintenance. As we now move into the twenty-first century, part of the cost will come in the effort required to develop, deploy, and maintain the individual software components. Many of these components will be on numerous remote satellites. As now, part of this effort will include implementing the required functionality of components, implementing the required interactions for components, and preparing components to operate in some remote runtime environment. One way to reduce the cost of component development will continue to be the reuse of existing commercial software components that meet the functional requirements. However, in either approach (SWW or Web), the task of integrating these components into vast twenty-first century spacewide distributed systems will be even more substantial because reasoning about and implementing the interactions in such distributed software systems is even now a complex process, even if the underlying communication mechanisms are homogeneous (Bonsard et al. 1997; Garlan et al. 1995).
Once a space application has been fielded, the cost of maintaining and extending this application can be substantial. One common maintenance change made to existing applications is porting to a new environment. However, because new space community environments potentially involve many differences in communication mechanisms and in underlying spacewide networks, making such a change is not trivial. Replacement of existing components is also a common maintenance upgrade, but this can be difficult, particularly if the signature of some service either used or provided is different from signatures of clients.
For these reasons, developing ways to increase the reusability both of the software components and of the applications' architectures is vital. The current benefits of reusing components are many; the development cost is amortized over multiple applications, and if we make no changes to the component, the testing obligations for this component are generally minimal (Rine and Sonnemann 1996, 1998).
There is also a great deal of interest in the idea of reusing the architecture of the applications themselves. The development of new products from the product-line reusable architecture (Rine and Sonnemann 1998) assumes that the following scenario or one similar to it has taken place. Suppose a company has a product that is doing well in the market. Because of an identified possible expansion of the current customer base, a conservative expansion of the current product is formulated by identifying a few variation points based on a variety of new services or functions (Jaber, Rine 1998; Jaber, Nada 1998; Nada and Rine 1998; Nada et al. 1998). Thereafter, the company develops an experience-based software architecture as the centerpiece of this expanding market's new products. Taking advantage of the variation points then leverages the reuse of this architecture.
The product-line reusable architecture is, therefore, initially comprised of abstract components and connectors representing the topology of the architecture and applications (products) to be derived from it (Abowd et al. 1995; Allen and Garlan 1997; Garlan et al. 1995; Shaw and Garlan 1996). At the endpoints of certain connectors, there are specifications of variation points where adapters will be introduced (Jaber, Rine 1998; Jaber, Nada 1998). The variation points were determined as part of the requirements of the software architecture and were selected in cooperation between market and development departments as variations between new product releases. An adapter in the design represents the specification of each variation point in the requirements. The representation of each adapter is incomplete, since at this point adapters that are supposed to communicate and interact with each other on behalf of corresponding components' services have not been introduced. And none of the numerous syntactical mismatches between client and server signatures has yet been resolved.
Unfortunately, neither of these two types of reuse is adequately supported with current technologies. The software architecture and its details are usually not explicitly defined; rather they are implicit in the software components' implementations, making it difficult to reuse. Components are difficult to reuse as well because they are tied to runtime environments and to interactions and must often be modified before reuse. The issue of reuse is even more difficult for components where only the interface of the component is available (e.g., COTs products) (Brown and Wallnau 1996; Clements 1995; Dellarocas 1997a, 1997b).
In this early stage there will be research into the development of scalable tools and techniques that increase the reusability of software components and software architectures. The approach should be based on the idea of developing adapters outside (i.e., external to) components to interconnect and isolate their interactions in message-based systems supporting the utilization of many components. These adapters also need to be quality of service aware in order to allow interoperation over entirely different network types. The requirements of the component interfaces and of the interactions are expressed separately from the component, meaning that we can generate adapters automatically. Because interconnection and interaction issues are addressed separately and implemented automatically, this method decreases the components' perceived complexity, increases their reusability, and simplifies their integration.
Before describing the adapter-based approach to software configuration, a more detailed description is made of the issues that make integration in a component-based system difficult and provide a simple telecommunications-based example. This example is used to illustrate some of the integration problems and how adapters can be used to solve these problems.
14.2.1 Future Supporting Communications Satellites Constellations
In this section we will discuss issues and requirements for a Space Wide Web.
A Scenario Using Future SWW
Considering a future scenario involving planetary and deep space satellites motivates the need for an adaptive Web-based configuration language. Assume that several teams of researchers are scattered across Mars, and that communication between these researchers is supported by a constellation of low-orbit communication satellites, like the present LEOS. Further, suppose that there is a deep space probe exploring the asteroid zone between Mars and Jupiter. Scientists on both Mars and earth would like to be able to dynamically access data from this probe, via a relay between their low-orbit constellations and a ground-or space-based relay station. This access can include running different sets of measurements, changing sensor configuration, and so on. Further, when appropriate, earth scientists would like to share results with their Mars colleagues using push technology, and vice versa. Finally, scientists will want to run their experiments on the deep space probe by writing and then loading the equivalent of a Java-like applet onto the probe.
This scenario raises a number of technological challenges. First, the earth-based and Mars-based scientists may have quite different capabilities in terms of the type and amount of data they can receive from the probe. It may even be desirable to first send the data to earth, have it processed, and then send it back up to Mars. Second, all space-based communication is costly in terms of power consumption, available bandwidth, and round-trip propagation delay. Finally, the dynamics of this situation change due to factors such as changing orbits and relative positions. For instance, it may be better for the probe at times to send to Mars, or to earth, or both. These routing decisions are based upon both the needs of the application and the physical configuration of the communication satellites. In order to make appropriate use of minimal bandwidth and limited power, it is desirable that these semantics are directly reflected from the application down to the network layer. The challenge is to do this in a way that both does not unduly burden the application writer (i.e., the scientist writing the satellite applet) and also makes appropriate usage of network resources. This is possible by developing the SWW-XML and by placing communication control in the appropriate adapters.
Current Low-Orbit Communications Satellite Constellations
The present state-of-the-art low-orbit communications satellite constellations around earth are an integrated combination of ground stations, gateways, uplinks, downlinks, planes, sequences of links between satellites (online and backup), commercial and government satellites, L-bands, K-bands, and so forth. The physics of reliable telephone-like or network-like communications currently depends on low-orbit satellites (e.g., 350?450 miles, L4, etc.) and power utilization based upon current technology. These satellites are often circling above the earth in one of several polar orbit planes, and a number of satellites (online and backup) are in each plane. Communications from users (cellular phones, network computers, Web users, client components, etc.) are routed through a gateway to an initial satellite. From this satellite a nearest neighbor satellite in the constellation is selected, and the "call" route is expanded through additional nearest neighbors until a final satellite is found to send the call down to the receiver (server component, etc.) of the call. Software in orbit-installed satellites are maintained by (1) frequently sending (uplinking) "patches" or modifications to on-board software and (2) continually testing the on-board software either through line-of-sight testing while the satellite is in "view" or by extensive use of on-board testing software when the satellite is not in line-of-sight (i.e., not in "view"). Unfortunately, on-board testing and quality assurance software in the satellite's computer memory take up a significant amount of memory space. Also, the functionality of satellites needs to be modified and adapted as new "environmental" requirements are imposed on the satellites, which is an additional set of quality assurance requirements of the on-board satellite software. If in the future, space, power, and maintenance requirements of satellites significantly increase, how will these requirements be met?
Adaptive Spacecraft Software
To support a space web (e.g., SWW), a futuristic spacecraft (satellite) orbiting a distant planet or moon needs to robustly self-adapt to its target environment. Sometimes this self-adaptation will be needed in order to respond to SWW user commands from earth or from another space colony, and sometimes this self-adaptation will be needed as a satellite reconfigures itself to allow it to perform more effectively or efficiently in a new physical environment. Let us imagine a satellite orbiting a different planet or a different orbit around the same planet for a period of time (e.g., a month). Environmental factors can be different versions of sunlight, temperature, magnetic field, gravity, and solar wind. Suppose a satellite supporting SWW in this research supports imaging. Let us use a client/server model. Suppose the client is the ground station on earth and the server is this satellite. Suppose three software subsystems are embedded in this satellite: command and data handling (CD), flight control, and payload control. Each of these software subsystems runs on a different processor. The CD is basically for receiving uplink commands and routing them through constellations to a given satellite and to a given processor. The flight control software is mainly for the attitude determination and attitude control system (ACS). The payload interface processor (PIP) is for controlling the imaging camera and sending images back to the client. We illustrate an idea of an adaptive ACS. In the future, this idea can be applied to adaptive PIP software.
The ACS follows the control model with three kinds of components: sensor, decision (control) logic, and actuator (Wertz 1997). Generally the set of sensors includes star tracker, sun sensor, magnetometer, gyroscope, and reaction wheel (see Figure 14.1).
Figure 14.1. Adaptive Spacecraft Software: Control Model
The decision logic includes attitude determination and attitude control. The actuator can be a reaction wheel and a torque coil. In fact, the sensor and actuator hardware has some built-in logic to make it flexible. Any of these components can be made adaptive. Let the input sensors be sun sensors, magnetometers, and accelerometers. Let the actuator be torque coils. Assume all these hardware components' performances are acceptable in a new environment. Only the control logic is subjected to modification. For simplicity, let the ACS control logic be only for controlling precession and spinning. In precession (imaging) mode, the goal is to keep the satellite pointing to the sun within a threshold (e.g., 0.2 degree), so that the solar array can observe to maximum solar energy and the finest image can be taken (see Figure 14.2).
Figure 14.2. Adaptive Spacecraft Software: Precession Model
In spinning (at night) mode, the goal is to maintain the satellite spinning at a desired period about Z-axis (see Figure 14.3).
Figure 14.3. Adaptive Spacecraft Software: Spinning Model
Software component adaptation approaches have been developed (Chen 1998; White 1995). One of the tasks in the research is to explore this approach further in the spacecraft software domain. The adaptation procedure can be abstractly suggested by means of the steps shown in Listing 14.1.
Listing 14.1 Algorithm for Adaptation
WHILE (Server's Performance is Unsatisfactory) DO BEGIN The client (ground) receives telemetry (environmental data, state of health) from theserver (satellite). The client adapts the ACS software component by using dynamic compilation algorithms. The client initializes the adapted ACS software component in the server. END.
In practice, on-board memory of the spacecraft is limited. Hence, we robustly adapt the software in the client (step 2). After adaptation, the satellite should well support improved imaging for the space web. A space web client on earth issues service commands to a space satellite to adjust orbit and attitude parameters in order that the satellite payload (e.g., a camera) can take photographs of a planetary body of interest. The client-service commands must be preprocessed by the client's adapter software component so that the commands can be sent in the correct form to the adapter software of the service satellite's software component. Therefore, the service satellite's adapter must have knowledge of the environmental parameters in which the service satellite currently exists. Initially three complementary models must exist for the correct adjustments to be made to the satellite so that it can be in a correct state to begin taking the required images. These three models are depicted in Figures 14.1 (Control Model for the ACS), 14.2 (Precession Model for the ACS), and 14.3 (Spinning Model for the ACS).
| Top |
