Motivation towards the Agent Paradigm

Examples of spontaneous collapse of distributed networks [201] include well documented telecommunications outages where router software upgrades (having passed scaled-down test-bed examinations) malfunctioned in real life causing large scale outages. Router timing errors only emerged during fully operational interactions, something test-bed examinations did not pick up. This is also true in a distributed computing environment on multiple mobile nodes where complex algorithms are being implemented to perform a multiple mission goals and overcome connectivity issues associated with LEO satellites. A. Carzaniga’s paper [202] presents some interesting future uses o f Agent systems using mobile code for distributed applications. Some applications elaborated here include:

Chapter 3.Distributed Satellite Systems

Deployment, U pgrading and M aintenance: The exploitation of mobile code to support software deployment and maintenance is veiy useful in a highly distributed environment. Mobile code paradigms would allow the action of installation o f new software units (such as IP blocks in an FPGA) or rebuilding of an application with new parameters locally at each satellite without the need of communications to individual picosatellites from ground. Proactive reconfiguration by comparing both hardware characteristics and software features for configuring and installation could be automated. Functionality could be added or removed dependent on the satellite’s resources. E.g. after critical testing and simulation, a fault is found in the communication software which limits the downlink’s data rate. Therefore a software patch can be uploaded to the current server satellite for distribution.

Customisation of Services: Agents on board satellites could provide a flexible service for both server and client roles dependent on their current hardware and software status. This allows Agents to be reactive in their communications to other satellites. E.g. If there are limited resources for the collection of sensor data on a client satellite, it will require storage on the network. It can communicate with the closest satellite, which identifies it as a server satellite and cannot be used for storage but reserve power for ground link. The server satellite can then suggest the next closest. Communicating with this satellite identifies itself as another client satellite with a damaged payload and can provide storage services to the rest of the network. Data transfer starts and data collection can continue.

Disconnected O perations: Identified physical links include a novel smart antenna system (low power with distances up to 10 km using 802.11 IEEE standards) [203] and a standard AX.25 communications system (typical with CubeSats) for downlinks, see Appendix A. Without an attitude determination and control system, the picosatellites could be tumbling and moving in differing orbits making intersatellite communications difficult. Unreliable links with low- bandwidth and low-reliability require new methods for allowing flexibility in the system. Improving granularity in the client-server paradigm would allow a greater number o f operations but would increase local resource use, complexity and reduce flexibility for change.

Agents by their autonomous nature are designed to handle complex and unreliable networking. Research in how to manage power for communications and memory could make efficient use of the resources on-board. E.g. a satellite is disconnected and saves the data to transmit securely in a

‘reduced state’ in static memory allocation instead o f large dynamic memory allocation.

Im proved F ault Tolerance: Traditional client-server systems request data and services from remote environments which can then be executed locally. But if a return result is only partially complete, there are problems in addressing the state and possible recovery. As Agents encapsulate all state information in a single component, the information can be traced and recovered.

Chapter 3.Distributed Satellite Systems

Destructive space environment effects could be mitigated using Agents to detect hardware or even software errors.

3.6

Summary

This chapter primarily looks at the areas of picosatellites, distributed satellite systems, and what technologies have been used towards distributed computing in space.

With the advent of the CubeSat standard and availability of various commercial off the shelf sub­ systems, picosatellite designs are very popular - especially for educational establishments. They can be built and launched at a fraction o f the cost o f large missions. A major review o f all picosatellite missions finds that current on-board computing use microcontrollers for low cost/power. The majority of missions currently launched are focused at technology demonstration o f components and sensors for gaining flight heritage.

Distributed satellite systems terms are overviewed to find that there many satellite scenarios under review: namely clustering, formation flying, virtual satellites (also called fractionation), and space sensor networks. These new satellite systems are analogous to a highly mobile wireless sensor network as they have very minimal computing resources to sense and communicate a given environment. When overviewing the current distributed missions, only one mission offers intersatellite connectivity with on-board processing (Iridium) in a stable constellation. All future distributed missions discussed are all technology development exercises in intersatellite connectivity and on-board processing (and optimisation thereof).

The deployment of picosatellites is simulated to find that this is a key area in employing a distributed mission and two constellation designs were developed: string-of-pearl and the Flower constellation. Without orbit maintenance, the string-of-pearl design found perturbation issues are too great but the Flower constellation offers a stable scenario where satellites oscillate between each other giving a periodically intermittent link.

A popular distributed computing technology used in space includes the terrestrial TCP/IP stack and custom delay tolerant network protocols which uses end point IP addresses. Further review of Agent systems for space concludes that the full benefits o f autonomy, code mobility, and distributed operation control are not utilised. Only simple scheduling (RAX) and suggested on­ board autonomy software (TechSat-21) are investigated.

Chapter 4. A^ent Computing Platform

Chapter 4

4 Agent Computing Platform

This chapter looks at combining the key findings from the terrestrial domain in Chapter 2 and the space domain in Chapter 3 to derive the requirements for a new computing platform for distributed satellite systems. Section 4.1 highlights the previous chapter and summarises the key drivers towards an Agent computing platform in distributed space mission applications. Section 4.2 proposes a new Agent-based distributed computing platform utilising a Java co-processor and embedded Agent middleware.