SO96.5.10 1
Abstract: Satellite based systems (e.g. navigation, communication, earth observation, reconnaissance, science) are an emerging application domain that requires advanced system design methods and tools to meet today's design-to-cost and time-to-market requirements. Therefore, Dornier Satellitensysteme GmbH has defined EaSyVaDe, a methodology for Early System Validation of Design. It is based on advanced modeling and simulation techniques and supports all phases from requirement's analysis down to implementation. The associated tool environment (SBSlab) enables system designers to describe, analyze, optimize, and validate system concepts and further refine it to implementation level.
The complexity of satellite based applications (e.g. radio navigation, earth observation, etc.) requires advanced information technology, new and flexible computer architectures and an improved system design methodology. In this paper main focus is on the design methodology and its implementation.
The classical lifecycle approach in system design has some major drawbacks. A good system design relies on a well-written requirement's specification. Around 70% of the product costs are determined by decisions taken during the requirement's specification phase. On the other hand less than 5% of the overall budget is spent for this phase.
In the classical lifecycle a check against the requirements is performed at the end of the design cycle when all decisions are taken. Thus, failures implemented during the requirement's specification phase are detected late in the development cycle and it becomes costly and time consuming to correct them [1].
Early validation of system concepts is essential to avoid costly and time consuming redesign cycles. Since many years prototyping is a proven method to perform requirement's validation [2], [3], [4], [5]. It is an effective method to reduce risk on satellite projects by early focus on feasibility analysis, identification of real requirements, and elimination of unnecessary requirements. Most of these traditional prototyping approaches are based on throw-away prototypes, i.e. critical functions are implemented in a quick and dirty manner and not used for later design and implementation phases.
Based on 30 years of experience in the definition and implementation of satellite based systems Dornier Satellitensysteme GmbH has defined the design methodology EaSyVaDe (= Early System Validation of Design) [6], [7]. It overcomes the drawbacks of the traditional life cycle approach mentioned above. It is based on evolutionary prototyping, i.e. the initial functional-compliant system model migrates into an operational system.
The early validation lifecycle covers the complete specification and design phases. A smooth transition from specification to design shall be achieved by continuous refinement and simulation of the logical and performance models. To achieve early validation of specification and design formal methods and/or simulation models are used as a means to effectively support the consolidation of the software system specification. At each refinement step an executable model is generated and checked against the customer's requirements. Thus, early feedback between customers and designers is possible. Errors and inconsistencies detected during the early phases of the project only cause little costs for correction, compared to the detection in the latter verification phases. Compared to the traditional lifecycle Early Validation allows to perform a lot of verification and validation of specification and design at the early stages of the project. Therefore redesign cycles can be avoided.
The verification phases of the traditional lifecycle cannot be completely cut-off, but a large amount of verification and failure detection can be moved to the early phases by use of verification and simulation techniques.
The alternative lifecycle of Fig. 1 shows early validation during the specification and design phase. But also the implementation phase can be influenced by the use of modeling techniques, if automated code generation either for hardware (e.g. VHDL descriptions) or for software (C or Ada code) is provided by the modeling and simulation tool. Today for most projects only careful use of automated code generation can be made for some parts of the software. Care shall be taken especially to the fact that the automated generated code has to fit into the general design process and into the selected architecture.
In general, the EaSyVaDe approach enhances understanding of the problem and helps to identify appropriate and feasible external behaviors for possible solutions. EaSyVaDe relies on advanced modeling and simulation techniques.
Fig. 1 Conventional vs. EaSyVaDe lifecycle model
The EaSyVaDe methodology is supported by an integrated set of tools called SBSlab (= Satellite Based Systems laboratory). The tool set supports system engineers in the validation of specifications and design space exploration for satellite based systems. During the system specification phase SBSlab helps to create an executable system prototype from given user requirements. Thus, SBSlab enhances understanding of the system's intended behavior and allows to check it against the customer's specification. During the design modeling phase SBSlab allows to refine the initial system model down to implementation level. This includes algorithm development, architecture-compliant modeling and C/Ada code generation for a specified target processor or generation of synthesisable HDL code (HDL = Hardware Description Language, e.g. VHDL).
In particular, the actual implementation of SBSlab supports the following activities:
The design process implemented in SBSlab can be depicted from Fig. 2. The system designer starts with component modeling. He can use either predefined building blocks from a component library and adjust the component parameters to his needs or he can develop new building blocks. The actual component library provides a set of basic building blocks for satellite based navigation systems. Other library elements are under development.
The system architecture and simulation scenarios must be defined next. The system designer interactively selects a subset from the previously modeled components (i.e. satellites, mobile or stationary users) and adds appropriate simulation parameters (e.g. step size, no. of steps). After scenario definition simulation can be carried out followed by the analysis phase. During this phase an assessment of the system architecture takes place. The result of the analysis phase is a new set of system constellation or component parameters. They are used as input to the next simulation run. The main goal of this iterative process is to optimize the system structure and its parameters. To perform a global search in the parameter space it is necessary to automate this process. The actual version of SBSlab does not support this automatic optimization approach yet, but the modular structure allows for later extensions with an optimizer.
Fig. 2: SBSlab phases
Fig. 3 shows the actual configuration of SBSlab. A central database is augmented by a set of editors, pre-/post-processing modules, and the simulator kernel (or execution support system).
Fig. 3: SBSlab configuration
All modules are embedded in a common framework that navigates the system engineer through the design process.
SBSlab is intended to be an open system. It is designed around a commercial database. Modules that follow the database interface specification can be plugged-in easily. The actual implementation of SBSlab supports the design and analysis of satellite navigation systems. By adding other editors and analysis packages SBSlab can be adapted to other domains of applications like for example earth observation.
SBSlab is a heterogeneous environment. All modules that require a close interaction with the system engineer are implemented on a PC under Windows NT, e.g. space and user segment definition. Modules that require computational power run on a UNIX workstation (Sun UltraSparc).
The space segment definition module enables the designer to create groups of satellites with common characteristics, as e.g. geostationary satellites with common mean time between failures (MTBF) and mean time to repair (MTTR) parameters. Once a group is defined individual satellites can be added. The common group parameters are copied to the satellite parameter set. The designer can modify these parameters in order to adapt them to individual satellite characteristics. Satellite orbits are specified either by Kepler parameters or GPS/GLONASS compliant parameter sets. Actual GPS and GLONASS almanac data can be imported directly from the internet.
Other parameters describe subsystem characteristics like for example data storage capacity, downlink datarate or max. available electrical power.
The user/ground segment definition comprises three modules: an editor for stationary and mobile users, an editor for route planning, and an editor for mission plan definition.
The editor for stationary and mobile users allows to specify groups of users with common characteristics, e.g. ground control stations as stationary users. By adding a new user to the group the common characteristics are copied to the user parameter set. These parameters can be modified to allow deviations from the group characteristics. The user parameter set includes the initial user position, model parameters (e.g. mass, max. acceleration, friction) to describe the dynamic behavior of the user, and equipment parameters like for example antenna characteristic.
The route planning editor provides functions either to generate a synthetic route with random data for all route parameters (e.g. inclination, direction) or to set all parameters interactively for a selected route on a map.
A ground control station can be seen a special case of a user characterized by its position and communication facilities. Additional features are to command spacecraft and acquire status information from there. The mission plan editor allows to create operational scenarios, i.e. to put a spacecraft into a specific mode, to command maneuvers, etc.
Model validation with real data is essential to ensure consistency between reality and simulation. Therefore, a GPS receiver interface has been integrated into SBSlab. It is a small module that reads position and almanac data from commercial GPS/GLONASS receivers via serial link and stores them in the database for later processing.
The pre- and post-processing modules provide the interface to the execution support system (simulation kernel). The pre-processing module enables system designers to specify simulation scenarios based on previously entered components' definitions. Multiple simulation scenarios can be defined in order to compare different system constellations. After scenario definition all data and macro command files are generated from the information stored in the database and the execution support system is started.
The execution support system (simulator kernel) is based on commercial tools like for example Xmath/Systembuild or Signal Processing Workstation (SPW). Xmath/Systembuild offers a rich set of library elements for control applications while SPW targets at digital signal processing applications.
As mentioned before, we developed a set of basic building blocks for these tools. One of these basic building blocks is the orbit calculation. Three different algorithms are implemented to calculate the satellite positions. The selection is upon the user's choice depending on his requirements (speed or accuracy). The first algorithm uses the "GPS equations" to calculate the satellites' position vector (x, y, z) in the earth-centered-earth-fixed coordinate system.
The second algorithm is based on a first-order perturbed keplerian orbit model covering the classical orbits used in earth orbiting systems. It is more precise but slower than the first one.
The third algorithm provides the three components of the position vector P and the three components of the velocity vector V of the satellites at each time sample. The new position and velocity components are processed with the method of "f and g series” [8], [9], [10]. The rotation of the Earth is taken into account by computing the Greenwich Angle as a function of the time and location. This algorithm is very useful in all applications where the satellite speed is required. For example, calculation of the Doppler shift for the GPS signal.
Another main building block is a receiver module for navigation signals. This module calculates the user position from the signals sent by the visible satellites. It can also handle multipath effects.
The execution support systems executes the specified simulation scenario. A scenario definition comprises the following information: configuration data, input data, and command sequences (generated by the pre-processing module). The configuration data describe the system architecture as a collection of basic building blocks and their interconnection. The input data include system stimuli and building block parameters. The command sequence contains simulator commands to intialize the simulator, to load all appropriate files, to run the simulation, and to format the simulation results according to the requirements of the post-processing module.
The post-processing module converts the data delivered by the execution support system into the database format.
The analysis package reads the data from the database, performs the specified processing and presents the processed data to a commercial visualization tool. The actual version supports the designer with functions for the analysis of satellite navigation systems. This includes:
All data can be visualized graphically after processing. This includes 2D graphs for xDOP/visibility along the simulated routes (see. Fig. 4), colored plots for visibility/DOP/availability values mapped onto different projections of the earth (e.g. cylindrical, orthographic, Mercator, Mollweide). Also, dynamic visualization of processed data is possible. For example, the changes of the GDOP over 24 hours for a given satellite constellation can be shown as series of frames. One frame represents the GDOP distribution over the earth for a certain time step (see. Fig. 5).
Fig. 4 DOP and visibility values along a given route
Fig. 5 GDOP plot mapped onto a orthographic projection of the earth
EaSyVaDe is an effective method to reduce risk on satellite projects by early focus on feasibility analysis, identification of a realistic and mandatory set of system requirements. The ability to transform the validated models into production code for the target system is a key factor in reducing the life cycle time and costs. Several applications of EaSyVaDe for onboard satellite subsystems have shown the advantages of this approach concerning risk reduction and savings in cost and time. Presently, the methodology is applied to a new satellite based radio navigation system.
SBSlab supports the EaSyVaDe methodology with a set of tools to describe the system structure, the system properties, the internal and external behavior, and user interface aspects. It supports interactive simulation and as well as code generation for different target systems. A powerful execution support system allows to perform true real-time hardware-in-the-loop simulations. Thus, initial system models can be prototyped early in the development cycle and checked against the customer's requirements. These checks are based on simulation to demonstrate correct system behavior under given input conditions.
Extensions of SBSlab will focus on automatic optimization of system parameters and support for distributed interactive simulation (DIS).
[1] P. HSIA, A. DAVIS, D. KUNG: Status Report: Requirements Engineering. In: IEEE Software, Vol. 10, No. 6, Nov. 1993
[2] H. GOMAA, D.B.H. SCOTT: Prototyping as a Tool in the Specification of User Requirements. In: Proc. 5th International Conference on Software Engineering, Washington, D.C.: IEEE Computer Society Press, March 1981
[3] R. BALZER, T.E. CHEATHAM, C. GREEN: Software technology in the 1990´s: Using a new Paradigm. In: Computer, Nov. 1983, pp. 38-45
[4] P.ZAVE: The Operational versus the Conventional Approach to Software Development. In: Communications of the ACM, Vol. 27, No. 2, Feb. 1984, pp. 104-118
[5] LUGI, M. KETABCHI: A Computer Aided Prototyping System. In: IEEE Software, März 1988, pp. 66-72
[6] OMBSIM (On-Board Mangement System Behavioural Simulation), ESTEC contract no. 10430/93/NL/FM(SC), Final Report, Noordwijk, Nov. 1995
[7] R. GERLICH, CH. SCHAFFER, Y. TANURHAM, V. DEBUS: EaSyVaDe/EaSySim: Early System Validation of Design by Behavioural Simulation. In: Proc. ESTEC 3rd Workshop on Simulators for European Space Programmes, Noordwijk, Nov. 1994
[8] A.E.ROY: Orbital Motion, Adam Hilger, 1988
[9] E.M.SOOP Handbook of Geostationary Orbits, 1994
[10] E. EVERHART Universal Variables in Elementary Problems in Celestial Mechanics, University of Denver