EVALUATING PERFORMANCE OF REAL-TIME SOFTWARE COMPONENTS: SATELLITE GROUND CONTROL STATION CASE STUDY

Manu Bhatia1), Roger Johnson2), Janusz Zalewski3)

1)

School of EE&CS and 2) Florida Space Institute University of Central Florida Orlando, FL 32816, USA 3) Computer Science Program Florida Gulf Coast University Ft. Myers, FL 33965, USA

Abstract
This paper presents a new approach to evaluating performance of real-time component based software by introducing a new measure called software sensitivity. The measure is based on the evaluation of relative changes in the number of missed deadlines when their lengths are being decreased. Experimental results were obtained for the satellite ground control stations tracking component developed at the Florida Space Institute.

program loading, and execution of payload specific operations.

FSI TLM Dish

Microdyne Rx'er 1200

Microdyne Combiner 3200

MUX/ DEMUX

Analog I/O (AIO) Subsystem

Key Words
Component based software, real-time software, software performance evaluation, software sensitivity
Future Expansion

Bit Sync

VME Bus

Frontend (FEP) Subsystem

1. Introduction
The objective of this work is to shed some light on realtime performance of software components developed to control a satellite ground station, built according to the principles of component based software engineering [1,2]. To give a proper background, we start with a brief description of a ground stations functionality, as well as a description of software architecture, for which the measure has been developed and the evaluations made. The satellite ground stations are control stations that control the satellite orbiting around the earth, receiving scientific data and communicating with the satellite through antennas. An example of the satellite ground station control system (SGSCS) discussed here and being built at Florida Space Institute is presented in Fig. 1. It is composed of an Analog I/O Subsystem, delivering modulated signals from and to a satellite, a Front-End Subsystem, collecting data in real time, and a Real-Time Processing Subsystem, doing the actual computations based on the received data, and storing them in a mass storage. Payload workstations are also an important part of ground stations. These support high-level commanding,

Internet Gateway

IEEE 1394 Splitter

DB Server SGI Origin 2000

Workstation Workstation

Workstation Workstation Workstation

Realtime Processing (RTP) Subsystem

Figure 1. Physical Diagram of a Ground Station. The requirements of the SGCS include real-time aspects, so that the SGSCS is a dynamic distributed real-time system. At a high level, the most common satellite ground station functions can be divided into five main categories, as follows [3]: Telemetry Processing to receive the data and all other useful information including pictures, video and other files (say, for a weather satellite), sent by the satellite, and to process them accordingly for research and observation. Tracking Functions, such as orbit determination, attitude determination, current and future position of the satellite with respect to the ground station.

Command and Control Functions, that are supposed to command and control the events related to satellite. This subsystem controls the satellite and is constantly communicating with the satellite. Database Functions, which are responsible for storing and retrieving of useful data. For processing the information obtained from the satellite it is required that useful and similar data be stored and observed for later handling. Data Analysis for the data gathered from satellite. This could be done for future data representation, studies, diagnostics and troubleshooting. These data could also be used to trigger real-time processes that will be vital to the satellite health or integrity of the satellite operation.

using quantitative measurements. As a result a Tracking Component of SGSCS has been developed and analyzed quantitatively. In particular, the response time of this component has been studied to determine the real-time behavior. The rest of the paper is structured as follows. In Section 2, we present briefly part of the software requirements for this component, as understood by designers, as well as describe the component design using the UML notation, Section 3 discusses the component implementation and experimental results regarding performance. In Section 4, we present some conclusions.

All the categories and functions discussed above are dependent on each other in one or more ways. An effective means of communication is required among all these functions to perform efficiently. Thus a ground station requires a communication channel, which is responsible for passing messages between different components and modules of the SGSCS. Following the distribution of functionalities, the SGSCS shall comprise a number of respective main modules or components. These components shall communicate with each other through a common channel, with operator interaction provided via a graphical user interface (GUI). Thus, the overall software is divided into the following components, reflected in Fig. 2: Telemetry Component Tracking Component Command and Control Component Database Archive Component Graphical User Interface (GUI) Component, to facilitate the operation of the system.

2. Design for the Tracking Component

Real-time satellite tracking is monitoring where the satellite is now and where it is going. Information you can get from real-time tracking includes satellite location (latitude, longitude, altitude or position vector), satellite velocity (speed, heading, flight path angle or velocity vector), azimuth and elevation pointing or look angles and the determination of Doppler shift on communication frequencies caused by relative motion between a satellite and an observer. The spacecraft attitude is a measure of how the satellite is oriented in the space. In this project the Tracking Component is responsible for position functions, such as orbit computation, attitude and position control of the satellite at any point of time. It shall be able to take a set of observations of a satellite and find the corresponding orbit. It shall be able to control the attitude of a satellite to assure proper alignment. The Tracking Components outputs and inputs shall be available to other components. To determine the orbit [4], eight elements are required, called keplerian elements. Keplerian elements provide a mathematical description of a satellite's orbit. Satellite tracking software reads the keplerian elements and provides graphical and/or tabular orbital predictions. The keplerian elements are a set of numbers which allow satellite tracking programs to calculate a satellite's position in space. They give us specific information about a satellite's orbit at a specific moment. Once these elements are known for a specific time, the satellite's position in space can be predicted using complex mathematical calculations. However, the accuracy of the position prediction degrades as time goes by. The predicted position of a satellite using 7 days old keplerian elements is more accurate than a prediction using 3 months old ones. The design of the Tracking Component makes use of the Unified Modeling Language (UML). Rhapsody design tool that supports UML has been used to produce respective diagrams, which could further be used to generate code [5]. The design presented in the form of

Satellite
Telemetry Component

Antennas and Hardware

COMMUNICATION CHANNEL

Database Component

Tracking Component

Comm/CTRL Component

GUI Component

Figure 2. Logical Diagram of the SGSCS Software. The specific objective of this project was to develop and analyze the behavior of a part of the SGSCS software

diagrams depicts the whole SGSCS software system. The top-level design is shown in Fig. 3. and illustrates interaction between different components. Detailed design of the Tracking Component has been done in the form of an object model diagram, activity diagrams and statechart diagrams.

Figure 3. SGSCS Component Diagram. One example of the decomposition of the Tracking Component is shown separately in Fig. 4. The diagram includes the interfaces available for Tracking Component: GetSatelliteParameters, GetSiteParameter and Track. They are used by the client to request the tracking data. Client sends requests to the Tracking Component using these interfaces and receives the tracking data from the Server.

interface Tracking { void GetSatelliteParams( in char chosen_satellite_c, out long catalog_no_c, out double EpochDay_c, out long ElementSet_c, out double Inclination_c, out double EpochRAAN_c, out double Eccentricity_c, out double EpochArgPerigee_c, out double EpochMeanAnomal_c, out double epochMeanMotion_c, out double OrbitalDecay_c, out long EpochOrbitNum_c, out double semi_major_axis_c, out double anomaly_period_c, out double apogee_c, out double perigee_c, out double ref_perigee_c, out double translate_freq_c, out double invert_c, out double BeaconFreq_c, out double perigeePhase_c, out long MaxPhase_c, out double EpochYear_c, out long PrintApogee_c); void GetSiteParams(); void Track(); void SetSimulationParams(); void InitialComputation(); }; //end of interface file Tracking.idl

Figure 5. Interface for the Tracking Component.

3. Implementation and Experimental Results

The Tracking Component has been implemented in three different ways: - in CORBA for MICO implementation in C++ under Solaris operating system [6] - in Rhapsody with code generation for C++ under Solaris [5] - in C++ under Solaris. The reason to implement this module in three different ways is to measure the response time for the CORBA implementation and see how much overhead is added because of communication, by comparing the CORBA execution against plain execution of the module which does not require client requests to be sent. Below we present only the implementation in MICO CORBA 2.3.7 and respective experiments. In the first experiment, a single client requests 100 sets of data from the server. After receiving reply for one request, another request is sent to the server and this is repeated until 100 requests are completed. The time of response is recorded for every request. The following graph in Figure 6 shows the respective behavior expressed in terms of the number of times the deadlines are missed for a specific software architecture and configuration [7]. The number of missed deadlines is

Figure 4. SGSCS Tracking Component Diagram. Specific format for the Tracking Component interface, including detailed data definitions has been shown in Fig. 5. All parameters and their types have been chosen according to the satellite tracking principles [4].

shown with respect to the lengths of deadlines to capture the significance of shortening deadlines and its impact on software behavior.

service requests, again in terms of the percentage of deadlines missed versus deadline length. Finally, similar experiments were conducted for five clients, when they are invoked simultaneously to request data from server. Respective results are shown in Figure 8. The cumulative behavior for one, three and five clients is plotted in the graph as shown below in Figure 9. The cumulative results show nearly linear increase in response time for increasing the number of clients, which validates the measurement process.

% deadlines missed - one client % deadlines missed

100 80 60 40 20 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

Cumulative results Response time (in ms) 35000 30000 25000 20000 15000 10000 5000 0 1 3 No. of clients 5

Deadline set (in millisec)

Figure 6. Missed Deadlines for a Single Client.

% of deadlines missed - three clients

% deadlines missed

100 80 60 40 20 0
00 30 00 90 0 0 00 00 15 21 Deadline set 0 00 27

Figure 9. Cumulative Results for 1/3/5 Clients (maximum, average, and minimum response times; a dotted line shows the range of responses). These curves are now used to derive a new parameter called software sensitivity [7]. Sensitivity means how fast the results change while deadlines are increased or decreased. Looking at Figures 6 through 8, presenting the graphs of percentage of deadlines missed versus deadlines set, we see the curves are mostly smooth; however some curves fall down more sharply than the others. This makes the difference in sensitivity, since the faster the curve descends the more sensitive respective system is. In other words, small change of a deadline length causes relatively larger changes in the number of deadlines missed. Formally, sensitivity is a parameter that takes into account the slope of each curve, in relative terms, to make curves and respective systems comparable. The first step in calculating the sensitivity is to linearize the curve in the interesting range. To make the linearization simpler, we set the threshold for percentage of deadlines missed to 8%, for sensitivity calculation purposes, and consider only values above 8%. Least Square Approximation technique with Curve Expert [8] is used to obtain the best straight line fits for the corresponding curves. This software takes the values of x and y axes for the points in the curve and returns the corresponding linear equivalent of the curve, in terms of

Figure 7. Missed Deadlines for Three Clients.

% of deadlines missed - five clients

% deadlines missed

100 50 0 Deadline set

Figure 8. Missed Deadlines for Five Clients. In the next set of experiments three clients were run simultaneously requesting data from the server. The following graph in Figure 7 shows the time taken to

the slope of the line, a, and the y-axis intercept, b, which can fit into the line equation, y = ax + b, to plot the straight-line equivalent of the curve. Then, to account for relative differences in absolute values of deadlines for different systems, the actual value of sensitivity is calculated from the straight line fits, according to the formula [9], where (x2,y2) and (x1,y1) are coordinates of respective points on the straight line reflecting the range considered: [(y2-y1)/ (y2+y1)/2] / [(x2-x1)/(x2+x1)/2] That way we allow comparison of different systems, for which deadline lengths are in different ranges, but the systems speed of response, that is, sensitivity, may be equivalent. Sample sensitivity calculations for all three configurations discussed above are presented in Table 1. Table 1. Results of sensitivity evaluation. Experiment A B Sensitivity
Single client Three clients Five clients -0.0246 -0.0046 -0.0091 136.7 101.2 185.0 2.58 2.14 1.98

References
[1] T. Heineman, T. Council, Component-based software engineering: Putting the pieces together (Reading, Mass.:Addison-Wesley, 2001) [2] J. Zalewski, Developing component-based software for real-time systems, Proc. 27th Euromicro Conference, Warsaw, Poland, September 4-6, 2001, 80-87 [3] J.S. Landis J.E. Mulldolland, Low cost satellite ground control facility design, IEEE Aerospace & Electronic Systems, 2(6), 1993, 35-49 [4] Coastal Oceans Observation Lab, Keplerian elements definitions (Piscataway, NJ: Rutgers Univ., 2002)
http://marine.rutgers.edu/mrs/education /class/paul/orbits.html

[5] iLogix Inc., Rhapsody, Burlingham, Mass., 2002,

http://www.ilogix.com/products/rhapsody/

[6] MICO Version 2.3.10, http://www.mico.org/ [7] D. Guo, J, van Katwijk, J. Zalewski, A new benchmark for distributed real-time systems: Some experimental results, Proc. 27th IFAC/IFIP/IEEE Workshop on Real-Time Programming, agw, Poland, May 14-17, 2003, 141-146 [8] D. Hyams, Curve Expert 1.3: A comprehensive curve fitting system for Windows (Hixson, Tenn: 2002)
http://curveexpert.webhop.biz/

4. Conclusion
The purpose of this work was to design, develop and analyze a software component for the Satellite Ground Station Control System using the principles of component based software engineering and following the unified modeling language (UML). As a result, a tracking software component has been developed in three implementations: - CORBA MICO in C++ under Solaris. - Rhapsody generated code in C++ under Solaris. - C++ under Solaris. Timeliness of a response is a fundamental characteristic of real-time systems and the measurement of parameters related to response time plays an important role in proper functioning of the system as a whole. To analyze the response time as a measure of timeliness, experiments were performed for all three implementations of the Tracking Component, with CORBA for one, three and five clients. The response time was analyzed using the percentage of deadlines missed for each implementation of the software. The experiments measured the response time in the range of 3000 to 10000 ms for on client. On increasing the load, i.e., the number of clients sending requests to three and five, the range of response time also increases linearly. A new parameter, sensitivity was also calculated for CORBA experiments, based on the percentage of deadlines missed. It has been observed that the sensitivity decreases proportionally to the number of clients added.

[9] A. Mandviwala, Real-time software development for satellite ground control station, Master Thesis (Orlando, Fla.: University of Central Florida, 2002)