Towards an Agent Computing Platform for Distributed ... - IEEE Xplore

I. INTRODUCTION

Towards an Agent Computing Platform for Distributed Computing on Satellites

CHRISTOPHER P. BRIDGES, Member, IEEE TANYA VLADIMIROVA, Member, IEEE Surrey Space Centre

Today’s mobile devices and countless other embedded devices now aim to use networking technologies utilizing the latest electronics and software to provide new functions. Distributed satellite systems, seen to be analogous to mobile ad hoc networks (MANET), perform new mission functions with high mobility and intermittent connectivity that make satellite network management and operations difficult. New drivers and requirements are outlined for node and network levels in any given topology requiring real-time client-server or peer-to-peer (P2P) networking applications. To meet these requirements a novel agent computing platform (ACP) is proposed utilizing technologies from the multi-processor and agent middleware fields for real-time Java networking and mobile ad hoc network-based distributed computing applications at a minimal overhead to existing systems. The Java optimised processor (JOP) is investigated and embedded into an existing LEON3-based system-on-a-chip (SoC) design to provide a new fault-tolerant, parallel processing, and network functionalities. Agent middleware is discussed and compared for porting to the new dual processor design with a new middleware instance manager thread to enable software resets at runtime on the Java processor without halting the processor. After verification these two technologies are combined and discussed in depth to highlight key technological problems of this real-time ACP implementation.

Manuscript received August 14, 2011; revised May 6 and November 4, 2012; released for publication November 29, 2012. IEEE Log No. T-AES/49/3/944616. Refereeing of this contribution was handled by P. Willett. This work was carried out under the ESPACENET Project and funded by EPSRC under Grant EP/C546318/1 and the PhD+ Scheme. Authors’ addresses: C. P. Bridges, Surrey Space Centre, University of Surrey, Guildford, Surrey GU27XH, UK, Email: ([email protected]); T. Vladimirova, Department of Engineering, University of Leicester, University Rd., Leicester, LE1 7RH, UK, and Surrey Space Centre, University of Surrey, UK.

c 2013 IEEE 0018-9251/13/$26.00 ° 1824

The latest mobile, wireless, and embedded devices have led to the advent of smaller cost-effective electronics goods and the ability to share computing services through wireless infrastructures. Constantly changing environments meant that the typical client-server paradigm, used in traditional networking applications, may not be the best scheme to use. Disconnected computing, where the network is often lost and found regularly, and mobility are now important issues in wireless and embedded environments where undesirable characteristics such as intermittence, low bandwidth, high latency, or high communication expenses are found. One such application domain is distributed satellite systems (DSS) [1]. A DSS will essentially use multiple spacecraft in varying configurations to achieve a mission’s goals collaboratively. These mission concepts require communication between satellites, referred to as intersatellite links (ISL), to build networks of distributed spacecraft for missions requiring increased special/temporal performance through distributed operations or to decrease the cost per bit of returned data using multiple images or measurements; analogous to the modern terrestrial mobile ad hoc networks (MANET). The key research problems preventing these missions are the ISL and computing technologies needed for managing the data and resources in the topology for a highly mobile space-based network using ground proven technologies or methods. This research proposes the use of a low Earth orbit-based flower constellation or relative motion formation to reduce thruster and propellant costs and provide real mission requirements towards a DSS. These baseline missions could also demonstrate the novel agent computing platform (ACP) to provide a future proof networking-based processing scheme. It is based on a new dual processor system-on-a-chip (SoC) design for real-time node level processing using C and network level processing using Java. This new SoC design will also provide an upgrade to an existing satellite-based embedded system towards a service-oriented, agent-based middleware configuration for MANET operations. This paper presents orbital parameters for a distributed mission scenario which can utilise the ACP for constellation management. By combining the fields of Java-based processors and agent middleware, a hard real-time ACP is designed for next generation distributed computing applications in satellite systems. II.

BACKGROUND INFORMATION

In terrestrial systems distributed computing technologies are common place to distribute computationally intensive tasks over wired and wireless networks such as those found in

IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 49, NO. 3

JULY 2013

smart-phones, laptops, and servers for Internet applications. Distributed computing is typically enabled by middleware, a software layer offering services to connect software components across a network for integration or sharing computing resources. Java-based technologies have been key in enabling many distributed applications using the Internet protocol suite (IP) and existing application programming interfaces (APIs). As such, opportunities to communicate over vast distances offer new and data-intensive services, such as those found in video-over-IP (VoIP) or cloud storage and computing. A. Related Work: Terrestrial Computing Terrestrial distributed computing is applied to two very different areas. One area aims at highly networked, high performance computing (HPC) for virtual organisations with extremely large pools of resources. The other targets embedded environments, such as wireless sensor networks (WSN), where computing ability, memory, power, and communications are extremely limited compared with HPC systems. New abstractions in software have been used to realise a distributed computing environment using mobile agents [2], a mobile software entity to provide distributed communications or control. Agents can encapsulate any distributed computing paradigm or communication model to sense the environment and perform tasks or set behaviours (similar to smart-phone apps). The most common agent middleware platforms are Java agent development (JADE) [3] or foundation for intelligent physical agents—open source (FIPA-OS) [4], both providing sets of middleware services for agent management, messaging, and mobility. JADE is also extended for wireless embedded devices: light extensible agent platform (LEAP). Agents operate on these platforms using behaviours and any Java-based APIs as applications on top of the middleware. Modern agent middleware solutions, however, are typically written in Java which are typically unsuited to real-time mission-critical embedded systems due to problems with large standard libraries, a slow and undeterminable execution model, and dynamic class loading times, to name a few reasons. To overcome these issues there are numerous real-time Java processing and execution technologies that explore methods of implementing a Java runtime environment (JRE) or Java virtual machine (JVM) for embedded systems. Table I displays some of the main methods for real-time Java execution, from the application layer with specifications or libraries for coding, such as safety critical Java (SCJ) [5], to just-in-time or ahead-of-time compilers like Cacao [6] which uses 1 MB RAM, or finally with hardware implementations such as Java optimized processor (JOP) [7] or secure hardware agent platform (SHAP)

TABLE I Real-Time Java Execution Technologies Layer

Examples

Real-Time Specifications and Libs. SCJ [5] Just-in-Time (JIT) Compilation Cacao [6] Ahead-of-Time (AOT) Comp. Pico Perc [9] and Jam.VM [10] Hardware Impl. of JRE/JVM JOP [7] and SHAP [8]

[8] which are both implemented as soft cores for use in field programmable gate arrays (FPGAs) and SoC solutions. The majority of these Java processing techniques are aimed to operate with soft real-time guarantees except for hardware implementations, which are aimed at hard real-time guarantees. Many of these implementations, from RTSJ/SCJ implementations running on small embedded targets to server grids, have the potential to be leveraged for use in satellite applications towards distributed satellite missions. B. Related Work: Spacecraft Computing In space systems, like terrestrial systems, the use of IP has been used on numerous missions, most notably from Surrey [11—13], for providing point-to-point-based IP communication. The next-generation flight computer at Surrey is the OBC750 [14], and a number of measurements on the same architecture using Ada, C, and Java were already published in 2003 [15]. They utilised real-time operating systems, such as VxWorks, for deterministic control processes. In the study, Aicas’ JamaicaVM was slower than the C alternatives and recommended that Java methods should avoid looped object creation and that future testing is required. In the same year Astrium and Aicas researched a hard real-time virtual machine for AOT Java compilation for space applications. It is compiled with real-time operating systems RTEMS or VxWorks and is targeted to operate on the LEON processor. NASA’s Deep Space One (or DS1) was the first satellite that used an intelligent agent to control a spacecraft on an experiment called remote agent experiment (or RAX) in 1999 [16]. RAX was used to remotely plan, execute, and reconfigure various schedules and modes of the spacecraft over a period of 2 days from 19 May 1999 autonomously. TechSat-21 however was the first proposed satellite system encountered to suggest using agent technology in space using multiple spacecraft [17]. In 2010 the DAFA Project also implemented service-based agent applications for end-user Earth observation images as well as GMES and exploration scenarios [18]. These developments are particularly significant, not only to leverage existing technologies but also to 1) provide easily implementable and portable code techniques utilizing Java, and 2) to provide service

BRIDGES & VLADIMIROVA: TOWARDS AN ACP FOR DISTRIBUTED COMPUTING ON SATELLITES

1825

and distributed software tools for autonomous and networked operations. III. DISTRIBUTED SATELLITE REFERENCE MISSION The cost of developing space systems suitable for the harsh space environment, launch, and ground-based control station maintainance often runs into the tens of millions of pounds (£). Despite this the cost of building satellites has reduced through two significant trends, namely, the use of commercial off-the-shelf (COTS) parts and miniaturisation. In turn new space mission architectures have been developed such as DSS. A summary of these missions is found in [19] where the existing DSS missions are compared in the following key areas: the use of ISL, the use of on-board distributed computing, the constellation design, and the cost. Each constellation made progress towards DSS and given high deployment and orbit maintenance costs, but no current mission meets all the requirements towards intersatellite communications using the following:

Fig. 1. Flower constellation (routing via ISL to ground).

1) multiple satellites due to the high fuel/propellant cost to maintain a constellation, 2) on-board processing for data aggregation and collection for autonomous constellation management, and the utilisation of smaller cost-effective platforms. A. Candidate Constellation Topologies An investigation into constellation designs and perturbation dynamics using satellites with a mass of 100 g to 1 kg, commonly called picosatellites [20], confirmed that some constellations can provide stable DSS orbit scenarios [21]. In a low Earth orbit (LEO), the string-of pearl constellation can achieve a DSS mission measured in months, whilst the flower constellation can achieve very stable orbit dynamics, estimated to be over 20 yr [21]. The string-of-pearl constellation is a simple leader/follower formation separated typically during deployment from the launcher resulting in a true anomaly separation, whilst the flower constellation has critically inclined orbits for repeat groundtrack systems. An example flower constellation is shown in Fig. 1 with 9 satellites in a “flower” topology, communicating to ground. These constellation scenarios provide a basis for more capable missions requiring redundancy and increased temporal/spatial resolutions. But as each satellite node progresses in its orbit, the connectivity opportunity or satellite access to 1) other satellite nodes and 2) the ground is intermittent, and how to route data to ground can be complex, as shown in the access chart for the constellation in Fig. 2. The ISL range varies in this topology to between 300—3900 km, but a link budget for a maximum of 400 km is shown for a 1 Mb S-band link. This range is comparible to the existing Iridium constellation 1826

Fig. 2. ISL and groundstation link access for each networked satellite node over time (ISLs Sat1 to Sat2 or Sat9 are not < 400 km).

which operates ISLs at 4000 km. One of the early demonstrators of these technologies is a recent European Space Agency (ESA) mission called PRISMA [22] that has also utilised low-rate ISL and autonomous operations to achieve stable formation flying operations under 50 km utilising relative motion techniques in the Hills Clohesy-Wiltshire (HCW) frame [23]. These new DSS missions can be argued as MANETs, but with a collective set of mission goals requiring hard real-time functionality, there is a need to provide fault-tolerant distributed computing and networking functionalities towards robust and adaptable in-orbit satellite network management. B. MANET Computing Drivers and Requirements As discussed in Section II-A, terrestrial distributed computing systems use Java for IP-based networking applications. Agent technologies also use a Java


JULY 2013

environment that provides distributed services for control/communication applications. Both terrestrial and space-based embedded computing and software are highly optimized for reduced memory and power consumption. In addition space systems are sized based on a specific payload or mission application and then optimized for low mass; reducing the cost of launch. In typical satellite design reliability in the space environment and low-power operation are key drivers in on-board data handling (OBDH) subsystems. However, distributed space systems currently focus on the many technological drivers. These are primarily ISL communications and networking towards resource sharing to provide formation flying or clustering missions with greater science return/E. Support for the new satellite formation or cluster mobility can utilize existing terrestrial techniques and technologies for greater fault-tolerant operations. As such, the DSS scenarios provide new challenges and requirements in OBDH subsystems. New generic distributed computing service requirements for MANET scenarios can also be described as follows. Node Level Functionality Requirements (individuals). 1) Energy efficient distributed computing platform; using: a) low footprint (in ROM or Flash Memory), b) low active memory usage (in RAM), c) ensure normal satellite operations can occur with minimal overhead. 2) Storing and forwarding of data using distributed computing paradigms in real-time; including: a) “high-priority” applications using a client/server paradigm–Payload data through the network such as imaging data, larger science payloads, and data aggregation, b) “low-priority” applications using a Peer-to-peer (P2P) paradigm–telemetry and telecommand (TT&C), position and velocity states (relative GPS measurements), byte size payload data, and network management data, c) enable future applications for distributed operations, autonomy, and artificial intelligence based on current terrestrial software systems whilst allowing legacy code. Network Level Functionality Requirements (clusters). 1) Ad hoc intersatellite networking capabilities for initial formation and new member addition. 2) Adaptable and redundant ground-link communication schemes, i.e., main “sink” to ground. 3) Proactive and reactive topology schemes for various mobility patterns. Following NASA’s technology readiness level (TRL) guide, this research aims to provide proof of

Fig. 3. ACP: Concept overview.

concept, critical analysis, and validation under lab conditions. This equates to a TRL of 4. IV. AGENT COMPUTING PLATFORM To meet the requirements for a number of MANET scenarios, a dual processor SoC design is proposed for node and network operations with respective software to complete the ACP as shown in Fig. 3. Therefore, to use Java, all exceptions or errors must be autonomously handled which is not currently achieved in modern middleware solutions and must be addressed. By separating the functionality into two areas, an existing embedded processor can be utilized in the same device as the experimental networking core with no I/O modification to the existing design, minimal overhead in logic, and the necessary external wireless components to enable a space-based network. An FPGA-based approach would allow for IP-core (or “soft core”) component reuse, and need up development, implementation, and testing of these experimental designs. The following two sections describe the SoC design and considerations and the embedded agent middleware platform. A. Dual Processor System on a Chip For the dual-core processor design, there are a number of options available to implement soft-core processors and buses such as the Altera Cortex [24], Xilinx MicroBlaze [25], or OpenCores OpenRISC 1000 [26] libraries. For space applications Aeroflex Gaisler’s LEON2/3-FT (fault-tolerant) processors [27] are used at ESA, and a general purpose LEON3 library [28] is available for academic aerospace research. Given the application domain and existing in-house cores and experience, the LEON3 library was chosen for node-level functions. As previously described in Section II, to accommodate a state-of-the-art agent computing environment, a JVM or JRE is required to provide a heterogeneous Java platform on which to realise an agent middleware as a communication medium between various platforms. As Java-based software solutions, such as JIT compilation, are not typically


1827

TABLE II Memory Footprint and Real-Time Comparison Size (MB)

Real-Time

1. Full Software using CORBA (LEON3, RTEMS, C++, ORB, 802.11 Driver, TCP/IP, Dyn. Lib.) [34]

1.739

AOT

2. Full Software using Java (x86, RTEMS, JRE 1.4 Std. Lib, CDC 1.0)

17.782

JIT

3. Hardware and Software Design (LEON3 and JOP, CDC 1.0, JADE-LEAP) 3b. As above with ProGuard Minimization (LEON3 and JOP, CDC 1.0, JADE-LEAP)

1.106

H/W

0.305

H/W

4. Full Software using GCJ (O3, G0 Options) (LEON3, RTEMS, GCJ Lib., JADE-LEAP)

6.220

AOT

5. Full Software using Fiji-VM 0.9.0 (LEON3, RTEMS, Fiji-VM Lib., JADE-LEAP)

1.625

AOT

OSI Software Layer Method

Fig. 4. Hardware and software layer design.

considered to operate in hard real-time in embedded systems, this work takes advantage of the open-source JOP [7], a hardware implementation of a virtual machine, for hard real-time Java functionality in a resource-limited embedded OBDH satellite subsystem. JOP is chosen as it is the smallest and fastest Java core to date. JOP is a RISC and stack based architecture used to execute Java bytecodes using precompiled microcode instructions. By utilising JOP in an FPGA along with the LEON3 processor, the benefits include the following. 1) Moving software to hardware; reducing the middleware memory footprint with increased FPGA utilisation and real-time Java functionality. 2) Enabling Java applications, such as Internet networking applications or agents, for real-time applications at JRE 1.1.8. 1) SoC Design Considerations: This dual processor architecture is defined by the memory sharing scheme in place between processor cores for access to external RAM and is achieved using the AMBA2 bus from ARM [29]. This design operates as a multiple instruction stream, multiple data stream (MIMD) architecture where each processor fetches its own instructions and data–essentially operating thread-level parallelism allowing many tasks to be performed simultaneously [30]. To reflect the dual processor design, the software design is layered as shown in Fig. 4, where interprocess communication (IPC), for exchanging data across multiple processes, can occur [31]. The AMBA2 bus from ARM can provide a robust hardware communication scheme using register-based buffering for read and write operations on the bus. For finding initial memory requirements, static and runtime measurements can be taken from a number of solutions. Since the standard desktop JRE is too big for embedded devices, Sun Microsystems provides a scaled version of Java to meet embedded device resources called Java 2 Micro Edition (or J2ME). The J2ME is composed of a virtual machine and a minimal set of class libraries that enables developers with base Java functionality for a range of embedded devices that share similar characteristics, such as network connectivity. Currently, two J2ME configurations are defined: the connected 1828

limited device configuration (CLDC) [32] and the connected device configuration (CDC) [33]. CDC succeeded Personal Java (or pjava) and is based on an earlier 1.1.8 Java revision. Both CDC and CLDC configurations are designed for intermittent network connections and utilize embedded processors with limited memory such as mobile phones, two-way pagers, or personal data assistants (PDAs). Either 16-or 32-bit microprocessor units (MPUs) are required and a minimum of 2 MB of RAM is required for the CDC or pjava implementations and associated applications. The full JRE 1.4 requires over 15 MB alone and is a major deterrent for using Java on embedded devices. A comparison of previous and current solutions highlighting memory footprint and real-time functionality can be found in Table II. From Table II it can be seen that the third option offers the smallest memory footprint whilst retaining hard real-time functionality using a hardware/software design with CDC 1.0, JADE-LEAP, and agent applications at a footprint of 1.1 MB. Compared with a CORBA-based implementation, the proposed system would reduce the footprint by 37%. The disadvantage here is the lack of code mobility or dynamic classloading at runtime, reducing the system’s flexibility. The main program will need to react and adapt in the event of transients or errors. 2) On-Chip Shared Memory and Caches: The LEON3 system implements a standard data and instruction cache, but JOP implements a stack cache for address generation for stack and variable pointers and a method cache for method invoking and returns. JOP’s configurable 1 KB cache size was determined by a previous analysis of JRE 1.4 method lengths being 98% less than 1 KB [35] and can be increased if on-chip resources are available.


JULY 2013

Fig. 5. SoC architecture.

Multi-core system designs use shared memory for fast data transfer between the cores. Once the memory has been mapped, core synchronization is required between the processes for storing or fetching data to and from shared memory, often called symmetric (shared memory) multiprocessing (SMP). This is achieved using open-source AMBA2 bus interfaces: the advanced high-performance bus (AHB) for on-chip networking and the advanced peripheral bus (APB) for I/O. An overview of the major cores is shown in Fig. 5. Other key cores include the LEON3 debug support unit (DSU) for performing online debugging (or tracing) of the processor and the JTAG unit for debugging purposes. Other cores not shown in Fig. 5 but implemented in the design include memory controllers, interrupt controllers, timers, and status registers [28]. 3) Java Processor Design Extensions: The advantage of using FPGA devices is that a mix of sources can be used, allowing for versatile designs with differing memory architectures and IP cores. This can also lead to high development time and costs. Therefore, the JOP core is integrated as an IP library to the Gaisler GRLIB for use in future real-time embedded Java processor projects. Adding JOP as a nonheterogeneous Java-based network processor has led to the following extensions.

1) JOP AMBA interface: JOP uses the SimpCon bus scheme [36], whilst the LEON3 uses the ARM AMBA2 bus. 2) Exceptions: JOP, like any JVM, has exceptions that could cause the processor to stall or exit from operation. These are handled via addressable APB registers or autonomously with a core reset. 3) Bootloading: Both the LEON3 and JOP require off-chip memory areas, typically in PROMs or FLASH, to hold the software bootloaders. These interfaces are available to both cores so they can run separately from each other. The AMBA interface includes a new asynchronous AHB bus master for 1) DMA access between on-chip memory and off-chip memory read and write operations, and 2) register-based communication to the LEON3. It also includes a new APB slave for communication with the memory controller, and hardware exception handling for automatic recovery as shown in Fig. 6. The JOP CPU core operates 4 pipelined stages [37]; the memory core provides an interface between the main memory and the CPU, whilst the extension core provides some extended functionalities (multiplier unit, memory and I/O controller, and multiplexer). The original I/O module has been replaced by AMBA interfaces. The new AMBA interfaces send configuration information to


1829

TABLE III Summary of Integration Utilisation on GR-XC3C-1500 FPGA Board Component

LCs Used

LEON3 CPU+AMBA Bus System JOP CPU+AMBA Interface LEON3+JOP+AMBA Bus

9,164 3,252 12,116

2) Null pointer–where a referenced object address contains no object address. 3) Array out of bounds–a checking signal where access to a variable or array is not possible. Software exceptions include the following.

Fig. 6. JOP IP core wrapper.

the AHB arbiter and are configurable by other AHB masters, such as the LEON3, to set JOP’s start and output addresses and read exceptions and debugging DMA signals. The LEON3, with both master and slave functions, is able to request (as a master) and serve (as a slave) to other cores on the AHB bus, whereas JOP can only request as a master with the simple APB slave for simple control and debugging. The LEON3 processor software applications are developed using Gaisler RTEMS 4.6 Tools [38], and JOP applications are developed using the JOP Tools [39] (discussed later in Section III-B.3). Additionally, JOP’s internal bus width is extended from 16 to 32 bits, which is in line with the AHB bus width, which will improve the bytecode instruction fetch cycle. 4) Autonomous Recovery using Exceptions: Exception handling is problematic in many autonomous fault-tolerant aerospace systems. Some relevant examples are discussed by H. Hecht [40] and include examples of catastrophic failures with an Ariane-5 launcher and the Mars Polar Lander. Hardware failures on satellite electronic subsystems occur from radiation effects such as charging, single event effects (SEE), and total ionic dose (TID). For this SoC design two types of failures are defined: global failure, where many functional areas of the device are affected requiring a hard reset, and a recoverable failure, where processes in hardware and software can cause functional errors but are correctable using detection and correction schemes (EDAC). For the Java processor the recoverable errors are directly mapped to hardware and software exceptions. Hardware exceptions include the following. 1) Stack overflow–where the stack becomes full, e.g., from recursive calling or large call depth. 1830

1) Network Exceptions–where timing or protocol constraints not met lead to an exit exception. 2) Application specific exceptions or program exits. Each of these hardware exceptions typically results in the stalling of the processor, and a hard reset is required, whilst software exceptions do not have to result in a full hard reset. In the space environment hardware exception errors can be caused from SEE (high energy protons and heavy ions), but software exceptions could occur due to unhandled network connections or lack of autonomy within programs. Therefore, hardware exceptions in the SoC design will all cause an automatic reset and so operationally the processor can be brought back online in the shortest time possible and the APB slave register bank is utilized allowing other AHB master cores to assess JOP’s operational status. For software exceptions a supervisory instance manager thread is used (described later in Section III-B.2). 5) SoC Prototyping: The development board used for experimentation was the GR-XC3S-1500 FPGA Development Board from Pender [41]. It has 1 £ 8 MB PROM, 64 MB SDRAM, a clock speed of 50 MHz, and requires 3.3 V for I/O and 1.2 V at the core. Table III presents the difference in on-chip LC utilisation between the LEON3, the JOP with an AMBA interface, and finally, the combined LEON3 and JOP with AMBA interfaces showing that adding JOP uses an additional 2952 LCs. This minor increase in LCs will also increase the power consumed as more registers and logic are being used. Implementation results of this design give a maximum frequency of 58.023 MHz when targeting the Spartan-3 1500 FPGA. Typically, additional arbitration and use of shared memory due to the addition of the JOP core would suggest that the maximum speed of the whole design will also be reduced. Three key signal domains to check as follows.


JULY 2013

Fig. 7. Output from GRMON startup code showing IP-core addresses with JOP showing AHB master and APB slave interfaces.

1) LEON3 CPU to memory controller (8.444 ns through logic, 13.099 ns through routing, 16 levels of logic = 58:023 MHz). 2) JOP wrapper registers to memory controller for read and write (3.678 ns through logic, 7.481 ns through routing, 5 levels of logic = 89:613 MHz). 3) LEON3 CPU to ethernet 10/100 transmitter (5.519 ns through logic, 7.031 ns through routing, 8 levels of logic = 79:679 MHz). Power is measured as both static power, typically based on the transistor count, and dynamic power, based on the switching or toggle rate of the transistors. Power consumption of the three configurations is estimated in Xilinx’s XPower [42] including the LEON3, JOP, and LEON plus JOP for each FPGA design excluding any off-chip components. Input variables include an ambient temperature of 10± C, zero airflow, and Spartan-3 package thermal resistance (² JA) ± C/W of 20.4 and maximum junction temperature of 93:6± C. For a standard toggle rate, which is how often the output changes with respect to 100 input clock signals, of 12.5% and operating at 40 MHz, the complete SoC dual processor core design is predicted to consume 291 mW with negligible overhead difference compared with the other separate designs of a single LEON3 or a single JOP configuration. A comparison of the power consumed at a higher toggle rate of 75% between the LEON3, JOP, and LEON3 plus JOP shows that there is an estimated power increase of 29 mW compared with a single JOP configuration and an increase of 13 mW compared with a single LEON3 configuration. Successful downloading and testing of the bitstream configuration onto the Spartan-3 development board introduced in Section V-A was achieved using GRMON [43], which is an online debugger for the LEON3 DSU core. The debug UART from Fig. 7 is used to check the AMBA bus configuration. When both the LEON3 and JOP were under load, there was an increase of 23.1 mW from 1.5147 to 1.5378 W. The programs used for a loaded application were a genetic algorithm application [44] on the LEON3 and a UDP loopback testbench application on the JOP. The UDP loopback testbench application demonstrates the operation of method and class loading with execution of Java bytecode towards IP-based network applications in parallel with the

LEON3 processor. The targeted development board was configured with the SoC design bitstream and debugged using a JTAG cable. As the core is designed to be attached as a “plug-n-play” (PnP) device, it is used to check for the JOP IP core. GRMON is an online debugger for the LEON3 processor using the DSU. B. Embedded Agent Middleware As described in Section II, there are various agent middleware options available to develop an embedded version of agent middleware, with the majority using a derivative of JADE or FIPA-OS. But each agent platform has dependencies based on a particular JRE. For example, JADE can be implemented based on JRE 1.4 or as JADE-LEAP using JRE 1.2. JADE-LEAP can then be configured under J2ME, CDC (or pjava), and the mobile information device profile (MIDP) stack which uses the CLDC specification. FIPA-OS is also considered along with MicroFIPA-OS, targeted for mobile phones. JOP implements the concurrent-copy garbage collection (GC) model using SCJ specifications that interleaves a GC thread for automatic memory management with a main program [45]. The GC is not studied further in this research. 1) Critical Analysis of Existing Agent Middleware: An in-depth comparison of the middleware footprints, RAM usage, startup time, and portability to the Java processor JOP, was carried out using a new method probe which takes a heap measurement at every method entry [46]. The method probe was developed using Eclipse’s Probekit from the Test and Performance Tools Platform (TPTP) Project [47] to log RAM measurements at method entry. This will aid in the future for identifying blocks of code that cause increased memory usage. Each agent middleware platform performs a standardised testbench with the following parameters. 1) Graphical user interfaces are to be removed and the middleware startup automated including a startup time output using the System.currentTimeMillis() method from JRE 1.0. 2) Basic agent management service (AMS) and directory facilitator (DF) services are to be loaded. These are two core services used to register and find agents across other platforms. 3) Load 1 “HelloWorld” agent and complete registration with AMS and DF. Output the time to mark the ending of the testbench and exit application once complete. Looking at the number of probe entries, the heap memory required to complete the given testbench is shown in Fig. 8. From Fig. 8 there is a clear minimisation of both memory and method calls from all the JADE platforms as the target is compiled to earlier


1831

Fig. 8. Comparison of RAM usage for platform startup using probe (without FIPA-OS due to initiation of integrated task manager that uses almost double the number of classes to complete task) [46].

(and smaller) Java revisions. The MicroFIPA-OS configuration, despite using more memory, uses almost half as many method calls to complete the testbench, thus potentially requiring a smaller stack depth for the agent middleware applications. The JADE-LEAP-pjava under the JRE 1.1.8 or CDC specification operated with the lowest memory. When the testbench ends, the memory stabilizes with all runs. When choosing between MicroFIPA-OS and JADE-LEAP-pjava options, both memory and call depth must be considered. The smaller the call depth of the application, the fewer values and references are required to be on the stack resulting in fewer clocked registers implemented in the FPGA SoC solution–ultimately reducing the power consumption. However, low memory usage also results in lower off-chip memory power consumption. The choice here was to investigate JADE-LEAP compiled under pjava for the final configuration with low RAM and memory footprint together with a fast startup time of 328 ms. This software configuration offers the following. 1) the CDC stack of standard Java methods usable for networking applications at JRE 1.1.8, either offered by JOP in hardware or in open-source software for emulation, 2) the lowest memory consumption when compared with other competing systems, 3) agent functionality through JADE-LEAP with cloning capabilities. 1832

This configuration has since been taken forward for development and its footprint reduced to 305 KB using ProGuard [48], an open source Java software shrinking tool, for shrinking, optimisation, and obfuscation, keeping only the required core classes for the middleware operation and communication. Shrinking analyses the main application and removes unused classes, fields, and methods. Optimizations include removing debug and logging codes, making classes static and final, and reducing variable allocation (mostly coding optimizations). Obfuscation is the replacement of naming in the classes, fields, and methods with simple characters and values. Despite being used to ensure that the code cannot be reverse engineered for greater security when the final agent middleware is deployed, it also compacts the code. When compared with previous middleware solutions in Table II, the minimisation achieves a 72% footprint reduction of the existing JADE-LEAP-pjava solution and 64% of the CORBA solution [34], making it a very small agent-based middleware solution for networked embedded systems. 2) Agent Middleware Functionalities: Implemented functionality includes service distribution, parallel threading of distributed computing tasks, and data distribution using TCP/IP and UDP. Additional functions added allow for on-demand network topology reconfiguration using soft restarts of the middleware, called the Instance Manager. In standard WSN or MANET systems, there is typically a main node or sink with which the end user interacts. But in the hostile space environment with high mobility, each node’s connectivity to each other could be easily compromised through poor link budgets, resulting in the single threaded operation to be compromised and exit. Soft restarts will enable new startup arguments held as CDC Java profiles to be run in a separate and fully handled thread for the agent middleware together with new topology and service configurations (as required). So instead of typically exiting the runtime and performing a complete hardware reset, controlled exception exit codes are utilised to restart the thread under a safe profile configuration and take full advantage of how the agent middleware operates using multiple CDC Java profiles. 3) Combined LEON3 and JOP Application Image: As JOP avoids dynamic class loading, all required classes must be loaded on startup with known start addresses. The Java application is first compiled to bytecode and then mapped into sequences using a table of instructions into microcodes for more complex functionality to output a given .jop file, as described in [39]. To overcome the shared memory architecture, compilation of each core’s application must be stored together in the same total static image (often called the footprint). Table IV describes the


JULY 2013

TABLE IV Application Creation Files and Processes for LEON3 RTEMS 4.6 and JOP LEON3 RTEMS 4.6 Initial Files Processes

Output Format

JOP

C, C++, header files

Java, Jar files

Compile into 1 or more object files (sparc-rtems-gcc)

Compile java files into bytecode (javac)

Create final image (sparc-rtems-mkprom)

Assemble microcoded JVM and produce memory initialization files based on bytecode (Jopa)

prom.out (32-bit)

Convert bytecode to JOP mapped sequences (JOPizer) prom.jop (32-bit)

bootloader are stored in the correct RAM address. When running, data can be written to or read from the JOP core’s internal APB registers for configuring: 0x80000e00: Start Address 0x80000e04: Output Address 0x80000e08: JOP Start Signal 0x80000e0A: Debug Signals: (Bits 0—2: DMA Status Signals/Bits 3—5: JOP Exception Status Signals Major events during simulation of the dual processor system are shown in Fig. 10 and include the following.

Fig. 9. Example SREC footprint details (LEON3 at 0x40000000 and JOP at 0x41000000).

files and processes for application development for each processor. SRECORD Tools 1.49 [49] or similar object copy suites can be utilized to convert from a binary format to a .srec format and concatenated together into one footprint with differing start addresses to avoid overlap between each processor’s memory maps. The typical LEON3 SoC design has static code (.text segment) in the .srec file and stored in a PROM at 0x00000000 and data (.data and .bss) immediately after. When the FPGA initialises, the .data segment is copied from the PROM to the RAM at the address 0x40000000. The data segment for JOP is, by default, also linked at 0x4000000 and this would conflict with the LEON3 application. Therefore an offset is used to load JOP’s data segment to 0x41000000 and outputting to 0x42000000. This ensures a separate memory map for each IP core in the SoC design, as shown in Fig. 9. These start addresses can be set in a C program by the LEON3 or hard-coded in the JOP IP core wrapper component to provide a level of development flexibility. Hardware simulation of the HelloWorld Java applications is a success and confirmed in ModelSim using a testbench which simulates the new design and outputting timing diagrams for two key parts of the design: the PROM and SDRAM devices. GRMON is used to load the combined application bootloader. It is also used for confirming that the correct input codes relating to the JOP application in the dual processor

1) At t = 0, the initial registers are set and the PROM starts to load and the LEON3 is initialised. The SDRAM is then loaded which will start the LEON3 application to load the footprint. 2) At t = 130 ¹s, a LEON3 application sets JOPs registers to start the core and provide I/O addresses. JOPs has » 20 reads to fill the method cache from the .jop file of pointers/start using the SimpCon to AMBA interface. 3) At t = 132 ¹s, JOP then reads main memory to fill the method data and arguements. 4) At t = 148 ¹s, JOP starts in parallel with the LEON3 which provides debugging loopback information. IV. EXPERIMENTAL RESULTS This section overviews the simulated and on-board results for the dual processor SoC and embedded agent middleware individually, assessing the performance and added functionality. A. Java Benchmarking on the Multiprocessor SoC Due to the absence of true embedded Java benchmarks, the online community has developed a number of micro benchmarks to measure JVM performance; evaluating the number of clock cycles for single or sets of bytecodes [6]. These include: 1) Sieve–calculates all prime numbers in an incrememental expanded array, 2) Kfl–an industrial application based on distributed motor control, 3) Lift–an automated lift controller in a factory, 4) UDP Client/ Server–a network application which loopbacks messages.


1833

Fig. 10. Post place and route simulation of LEON3 and JOP AHB bus requests. TABLE V SCJ JemBench Application Results

Fig. 11. Raw results of SCJ JemBench applications.

All applications are self-adjusting and stop when the benchmark exceeds the 1 s. The number of iterations per second is then calculated and outputted. Of particular interest is the UDP/IP client application which is a good, and highly practical, case for cache and stack size evaluation in the networking processor. The benchmark applications were run on various platforms including a PC, a mobile phone,1 and the LEON3+JOP FPGA where the results of which can be found in Table V from [18] with additional results on bytecode execution. The X denotes where information was unobtainable at the time of publication. The data for the standard JOP platform are taken from experimental results and published work in [50] and [51] for the standard JOP platform. The PC runs a JRE at version 1.6 on 2 x Pentium 4 3 GHz processors with 1 GB RAM and, as expected, is able to run large iterations of the micro benchmarks in comparison with the FPGA hardware implementations 1 The

mobile phone is an Orange SPV M3100 which operates with a 400 MHz Samsung CPU. 1834

Platform

Speed (MHz)

LEON3+JOP Standard JOP Mob. and MIDP PC and JRE 1.6

40 100 400 2x3000

(Thousands of Iterations/s) Sieve Kfl UDP/IP Lift 1.394 7.386 22.734 771.011

4.810 16.591 82.926 2631

2.595 6.527 36.352 762.6

4.721 12.55 X 1974

due to the larger processor speed and memory bandwidth. The results shown in Fig. 11 explore the overhead of the Java and LEON3 processor SoC design and compares them with other common Java platforms. The standard JOP platform consistently outperforms the new LEON3+JOP configuration in all benchmark applications. Ultimately, the final performance overhead is dependent on the memory interfacing scheme and additional AHB master bus loading/access. B. Optimized Agent Middleware Results This section describes the final results of the completed ACP where the proposed JADE-LEAP-pjava middleware solution, described in Section IV-B, is loaded onto the JOP processor. The instance manager thread, explained in Section IV-B.2, is used to pass arguments such as container configuration, network configuration, services loaded and agents initialized. A simple test on the PC successfully confirms that the instance manager thread passes correct arguments to JADE-LEAP and loads a HelloWorld based output during emulation (as used for the comparison in Section IV-B.1).


JULY 2013

Fig. 12. Call depth of testbench and call origins.

During experimentation on JSim, many classes were missing from JOP’s JRE to run the agent middleware application. These 683 class files were identified and were added to the agent middleware runtime at a cost of 219 kB, a 42% increase in footprint size, using the extensions classloader or classpath method of classloading. Once this was achieved the JADE-LEAP application failed due to stack overflow errors. There are two ways to try and overcome this error: 1) increase the JOP stack, and 2) investigate the call depth of the agent middleware application methods which are loaded onto the stack. JOP’s stack size was increased to 8 KB and a further reduction of the missing runtime classes from 683 to 331 (89% more classes down to a 43% increase) did not prove successful. An experiment on the original testbench (Section IV-B) on the JADE-LEAP looked at the call depth and which applications were native JOP calls, which were additional JRE calls, and finally which were JADE-LEAP calls. Figure 12 shows the cumulative number of calls and their origins. It can be seen that there are a large amount of calls made for the Java-based agent middleware applications and 0 calls for the native JOP processor. The JRE runtime prerequisite calls to run the testbench application account for around 85% of all the calls made, with the final 15% being the middleware and application services. As each method is pushed and popped to and from the stack, the call depth is an important indicator of the on-chip memory requirements. JOP’s stack contains five words on: return information, method arguments as first local variables, other public local variables, and the operand stack for expression evaluation per method invocation. The average stack frame of a native JOP method for these functions is typically between 10 to 20 bytes so with a call depth of 108, the resultant stack size needs to be 2.16 kB. But existing JRE methods are much larger at up to 256 bytes which gives a resultant stack size of 27.648 kB. Unless these existing method sizes

are accounted for, the methods could not be pushed on to the stack and overflow. As such, a larger FPGA is required for implementing wider and larger stack sizes if JOP was to be used further. Further analysis discovered problems in the JADE-LEAP agent middleware structure, programming styles, and data structure types. For conformity to Java revision 1.1.8 for running on the Java processor JOP, many optimizations were made in Section IV-B.2 to reduce the agent middleware’s code size but rewriting some of the agent functionality would be required to reduce data size of the agent system. Examples include reducing the number of variables, using shorter class/method/variable names, and implementing primitive data types instead of complex data types (such as array instead of java.util.vector). The existing JADE middleware was originally intended for the Internet and desktops with large memories–and this is how it has developed [54]. Summarizing again, the three key issues preventing COTS agent middleware from operating on an embedded Java processor are: 1) the large call depth, 2) large and dynamic classloading size, and 3) lack of implementing with SCJ embedded programming practices–all of which need further investigation. This is a significant finding and limitation of the combining current state-of-the-art agent technologies in software with hardware JVMs and on-chip memories towards real-time agent computing. V.

CONCLUSION

This paper introduces the application domain of distributed satellite systems, which aim at utilizing multiple spacecraft with ISL and on-board computing capabilities to increase spatial and temporal data. Current missions were investigated to conclude that there is a lack of technology demonstration for these exotic missions. A new and novel ACP, utilizing technology from the multicore SoC domain and the agent middleware domains is proposed to meet drivers and requirements for new mobile ad hoc networking applications requiring real-time functionality at minimal overheads. Design and integration of the LEON3 processor and the JOP processor concludes that the design performs as expected as part of an MIMD parallel architecture SoC overcoming complexities in interfacing, exception handling, and bootloading. JADE-LEAP was shown to offer a highly embedded agent middleware and was developed further to provide low ROM and RAM usage as well as autonomous software resets and exception handling at runtime using an instance manager thread. A new rule-based capability function is then implemented to provide information on networked node resources for peer-related MANET applications.


1835

Java benchmark applications were successfully run on the Spartan-3 FPGA board and compared to verify the Java processor’s operation at executing bytecodes. The results show a lower performance using this parallel architecture design compared with the single Java processor core. Experiments to confirm the full Java-based agent middleware running on the SoC design also highlights the limitation of current Java processors which exhibited a large call depth due to few overlapping native and JRE bytecodes. It was also observed that the structure of the agent middleware components was designed for functionality and not for embedded systems.

[12]

Jackson, C., Smithies, C., and Sweeting, M. NASA IP demonstration in-orbit via UOSAT-12 minisatellite. Proceedings of the 52nd International Astronautical Congress (IAC ’01), Toulouse, France, 2001.

[13]

Space Daily AlSAT-1 DMC working well in orbit with first use of IP. Available: www.spacedaily.com (last accessed: Aug. 7, 2009). Surrey Satellite Technology, Ltd. (SSTL) OBC750 LEO flight computer. Surrey Satellite Technology, Ltd. (SSTL), Datasheet, Feb. 3, 2010.

[14]

[15]

Weiskirchner, M. Comparison of the execution times of Ada, C, and Java. EADS Germany, Germany, Sept. 25, 2003.

[16]

Smith, B., et al. Validation and verification of the remote agent for spacecraft autonomy. Proceedings of the IEEE Aerospace Conference, vol. 1, Aspen, CO, 1999, pp. 449—468. Chien, S., et al. The Techsat-21 autonomous space science agent. Proceedings of the 1st International Conference on Autonomous Agents and Multiagent Systems, 2002, Bologna, Italy, pp. 570—577.

REFERENCES [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

1836

Jilla, C. D. and Miller, D. W. Multi-objective, multidisciplinary design optimization methodology for distributed satellite systems. Journal of Spacecraft and Rockets, 41, 1 (Jan. 2004), 39—50. Wooldridge, M. An Introduction to MultiAgent Systems. Hoboken, NJ: Wiley, 2009, p. 366. Bellifemine, F. L., Caire, G., and Greenwood, D. Developing Multi-Agent Systems with JADE. Hoboken, NJ: Wiley, 2007. Poslad, S., Buckle, P., and Hadingham, R. The FIPA-OS agent platform: Open source for open standards. Proceedings of the 5th International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM 2000), Manchester, UK, Apr. 10—12, 2000. Locke, C. D., et al. JSR 302: Safety critical JavaTM technology, Specification. Available: http://jcp.org/en/jsr/detail?id=302. Brandner, F., Thorn, T., and Schoeberl, M. Embedded JIT compilation with CACAO on YARI. Institute of Computer Engineering, Vienna, Austria, June 2008. Schoeberl, M. A Java processor architecture for embedded real-time systems. Journal of Systems Architecture, 54, 1—2 (Jan.—Feb. 2008), 265—286. Zabel, M., et al. SHAP–Secure hardware agent platform. Proceedings of the Dresdner Arbeitstagung Schaltungs und Systementwurf, Dresden, Germany, May 8—9, 2007, pp. 119—126. Atego Aonix Perc Pico. Datasheet, available: www.atego.com/downloads/support/ data-sheets/AonixPerc-Pico.pdf. Aicas JamaicaVM: Java Technology for Critical Applications, Datasheet. Matarasso, C., et al. Multimedia satellite communications experiments to the International Space Station. International Journal of Satellite Communications, 20, 5 (Sept.—Oct. 2002), 333—345.

[17]

[18]

Cesta, A., et al. Injecting on-board autonomy in a multi-agent system for space service providing. Proceedings of the 23rd International Conference on Industrial Engineering and Other Applications of Applied Intelligent Systems (IEA/AIE 2010), Part I, Lecture Notes in Computer Science Series, vol. 6096, Cordoba, Spain, June 1—4, 2010, pp. 154—163, DOI:10.1007/978-3-642-13022-9 16.

[19]

Bridges, C. P. and Vladimirova, T. Real-time agent middleware experiments on Java-based processors towards distributed satellite systems. Proceedings of the 2011 IEEE Aerospace Conference (IEEEAC ’11), Big Sky, MT, Mar. 5—12, 2011, pp. 1—10.

[20]

Heidt, H., et al. CubeSat: A new generation of picosatellite for education and industry low-cost space experimentation. Proceedings of the 14th Annual AIAA/USU Conference on Small Satellites, Logan, UT, Aug. 21—24, 2000. Bridges, C. P. and Vladimirova, T. Agent computing for distributed satellite systems. Proceedings of the 59th International Astronautical Congress (IAC ’08), vol. 11, Glasgow, UK, Sept. 29—Oct. 3, 2008, p. 6937.

[21]

[22]

Anflo, K. Flight demonstration of an ADN-based propulsion system on the PRISMA satellite. Proceedings of the 42nd AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, Sacramento, CA, July 2006.

[23]

Clohessy, W. and Wiltshire, R. Terminal guidance for satellite rendezvous. Journal of the Aerospace Sciences, 27, 9 (1960), 653—658. Altera Dual-Core ARM Cortex-A9 MPCore Processor. [Online], available: http://www.altera.com/devices/ processor/arm/cortex-a9/m-arm-cortex-a9.html. Xilinx MicroBlaze “Soft Processor Core.” [Online], available: http://www.xilinx.com/tools/ microblaze.htm.

[24]

[25]


JULY 2013

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

OpenCores.org OpenRISC-1000 Main Page. [Online], available: http://opencores.org/or1k/Main Page. Gaisler Research SPARC V8 32-bit Processor LEON3/LEON3-FT CompanionCore. Gaisler Research, Datasheet, www.actel.com/ ipdocs/leon3 ds.pdf (last accessed: July 17, 2009). Gaisler Research GRLIB IP Library User’s Manual. Gaisler Research, Datasheet, gaisler.com/products/grlib/ grip.pdf (last accessed July 7, 2009). Advanced RISC Machines Ltd. (ARM) AMBA Specification Rev 2.0. Advanced RISC Machines Ltd. (ARM), Specification, 1999. Hennessy, J. L. and Patterson, D. A. Computer Architecture–A Quantative Approach (4th ed.). Waltham, MA: Elsevier, pp. 196—202. Coulouris, G., Dollimore, J., and Kindberg, T. Distributed Systems–Concepts and Design (3rd ed.). Reading, MA: Addison-Wesley, 2005, pp. 127—129. Sun Microsystems, Inc. Java ME Website Connected Limited Device Configuration (CLDC). [Online], available: http://java.sun.com/products/cldc/ (last accessed: June 17, 2009). Sun Microsystems, Inc. Java ME Website Connected Configuration (CDC). [Online], available: java.sun.com/products/cdc (last accessed: June 17, 2009). Vladimirova, T., et al. Distributed computing in reconfigurable picosatellite networks. Proceedings of the 2nd NASA/ESA Conference on Adaptive Hardware and Systems (AHS ’07), Edinburgh, UK, Aug. 5—8, 2007, pp. 682—692. Schoeberl, M. JOP Reference Handbook: Building Embedded Systems with a Java Processor. Paramount, CA: CreateSpace, 2009, pp. 61—70. OpenCores SimpCon–A Simple SoC Interconnect. [Online], available: http://www.opencores.org/projects.cgi/ web/simpcon/over view (last accessed: July 7, 2009). Schoeberl, M. JOP Reference Handbook: Building Embedded Systems with a Java Processor. Paramount, CA: CreateSpace, 2009, pp. 55—62. Aeroflex Gaisler LEON/ERC32RTEMS Cross Compilation System (RCC). [Online], available: www.gaisler.com/cms/index.php? option=com content&task=view&id=150&Itemid=31 (last accessed July 9, 2009).

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

Schoeberl, M. JOP Reference Handbook: Building Embedded Systems with a Java Processor. Paramount, CA: CreateSpace, 2009, pp. 9—33. Hecht, H. Requirements for software exception handling. Proceedings of the 2008 IEEE Aerospace Conference (IEEEAC ’08), Big Sky, MT, Mar. 1—8. 2008, pp. 1—7. Pender Electronic Design GR-XC3S-1500 FPGA Board. [Online], available: www.pender.ch/products xc3s.shtml (last accessed: July 5, 2009). Xilinx Inc. Xilinx Spartan–3 Power Estimator (XPower). [Online], available: www.xilinx.com/ise/power tools/ license spartan3.htm (last accessed July 9, 2009). Aeroflex Gaisler GRMON-RCP. [Online], available: www.gaisler.com/cms/index.php? option=com content&task=view&id=39&Itemid=128 (last accessed: July 9, 2009). Tripp, H. and Palmer, P. Distributed behavioural coordination for satellite clusters. Proceedings of the 59th International Astronautical Congress (IAC ’08), Glasgow, UK, Sept. 29—Oct. 3, 2008, p. 6753. Schoeberl, M. JOP Reference Handbook: Building Embedded Systems with a Java Processor. Paramount, CA: CreateSpace, 2009, pp. 9—20. Bridges, C. P. and Vladimirova, T. Agent computing applications in distributed satellite systems. Proceedings of the International Symposium on Autonomous Decentralized Systems (ISADS ’09), Athens, Greece, Mar. 23—25, 2009, pp. 1—8. Eclipse Test & Performance Tools Platform Project [Online], available: www.eclipse.org/tptp (last accessed May 5, 2009). ProGuard, Version 4.3. [Online], available: proguard.sourceforge.net/ (last accessed: July 2, 2009). SRecord 1.49. [Online], available: srecord.sourceforge.net (last accessed: July 9, 2009). Schoeberl, B. M. Time-predictable computer architecture. EURASIP Journal on Embedded Systems, 2009 (Feb. 2009), article ID 758480. Brandner, F., Thorn, T., and Schoeberl, M. Embedded JIT compilation with CACAO on YARI. Proceedings of the 12th IEEE International Symposium on Object/Component/Service-Oriented Real-time Distributed Computing (ISORC 2009), Tokyo, Japan, Mar. 17—20, 2009, pp. 63—70.


1837

Christopher P. Bridges (M’09) B.Eng., Ph.D., is a lecturer at Surrey Space Centre, UK. He has published papers in distributed satellite systems, relative motion for satellites, middleware and networking, software agents, FPGAs, and IP processing cores. His interests are in Java processing, hardware and software techniques, adapting COTS hardware/software technologies, and autonomy. Dr. Bridges is a member of the Institution of Engineering and Technology.

Tanya Vladimirova (M’99) M.Eng., M.Sc., Ph.D., C.Eng., is a professor in the Department of Engineering, University of Leicester and a visiting professor to Surrey Space Centre, University of Surrey, UK. She has been involved in a number of research projects on VLSI design and embedded systems for space applications and has more than 160 publications. Her research interests are in the areas of embedded systems, FPGA/ASIC design, wireless sensor networks, image processing, distributed computing, and artificial intelligence. Dr. Vladimirova is a member of the Institution of Engineering and Technology. 1838


JULY 2013