Satellite simulation environment has very important role during software and system verification and testing phase since it is cost effective way to do it. The usage of simulator on software testing and system verification is being increased continuously. For example, in communication,ocean, and meteorological satellite (COMS) program,launched at 27 June 2010, various simulators were used at software and system verification at each phase of software testing, satellite dynamics verification, satellite engineering test bed test, and even satellite integration test phase. In these simulators, various simulation models are integrated inside for their specific simulation capability.For example, from telemetry and telecommand model as on-board computer component to sensor and dynamics model as satellite analysis model, almost everything on satellite can be modeled.

It should be noted that purchasing these models which are already proven may be the most effective way to development simulator rather than starting with scratch from everything, e.g. simulator platform, simulator/man interface, simulator/model interface, and finally model itself. To use pre-developed simulator model, simulator/model interface is very important to maintain the reusability through various simulator platforms.

EuroSim and SIMSAT is widely known as satellite simulator platform and both are being used by European spacecraft development companies and European Space Agency (ESA)/European Space Operations Centre (ESOC)/European Space Research and Technology Centre (ESTEC). They are very powerful platform and have many third parties who provide various simulator models. VEGA and Terma are examples of these third parties.

Unfortunately, there are cases that another specific functionality which is not supported by EuroSim or SIMSAT, is requested. For example if we need to integrate several simulators through ethernet or something else, native function of these simulator platforms is not sufficient to do it since we don't know the detail mechanism of these simulator platforms.

So, simplified and flexible simulator platform to meet the specific requirements has been requested frequently since there are numerous phases and levels on software and system test/verification of satellite. The numerous phases and levels bring various functional requirements about satellite simulator environment.

This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium,provided the original work is properly cited.

Even though new simulator platform is required, existing simulator models shall be used as much as can with minimal design or source code change. So interface between simulator platform and simulator model is requested to maintain consistency of functionality of simulator model when simulator platform is changed.

Simulation model portability (SMP) is one of the good candidates of the interface between simulator platform and simulator model (ESA 2002). SMP is introduced by

ESA and focuses on maintaining the interface consistency with various simulator platform, various development languages, and various operating systems. Those environments which shall be compatible under SMP would be summarized as follows:

- Simulator platform: EuroSim, SIMSAT, Rose and etc.

- Development languages: Java, Ada, C/C++, Fortran

- Operating systems: MS Windows, Linux

SMP standard does not describe detail implementation of the interface, but describes only abstraction interface application programming interface (API) of simulation model interface (SMI).

As depicted in Fig. 1, simulator models are interfaced with simulation platform through SMI APIs. The dotted line in Fig. 1 represents inside relationship between models and solid line in Fig. 1 represents interface with simulator platform via SMI. Through SMI APIs, model can register its service (function) and data to simulator model manager as depicted in Fig. 2. Once the services and data are registered to a simulator platform, the services and data can be used by the simulator core function, e.g. scheduler or javascript as test script from user. The core function is to manage the simulator periodic/aperiodic event thanks to scheduler which is composed of various functions supporting real-time requests.

Simulation scheduler is the most frequently called function in simulation platform. Scheduler distributes time resources such as simulation time and processor emulation time, and manages simulation event. The basic operation of scheduler is that it remembers simulation event, continues the process of processor emulator until the shortest event time is elapsed, and then pauses the processor emulator and jumps the simulation event handler to service the functionality of event. When

the processing of an event is completed, it returns to a paused processing of a processor emulator.

To maintain the compatibility to SMI/SMP of existing simulator models, simulation scheduler is designed to provide simplified SMI APIs to further simulator model. This simulation scheduler shall have minimal dependency with development platform, e.g. operating system and development tools.

As shown in Fig. 3, scheduler allocates processing time to each simulation request, e.g., processor emulator and simulation event. The solid dot line means that this allocation is based on "Soft Real-Time" scheduling concept and the solid line connecting between scheduler and hardware abstraction layer (HAL) I/F means that this allocation is based on "Non Real-Time" scheduling concept. Fig. 4 represents a schedule as a part of scheduler, which is the list of simulation events that happen in SIMWARE of COMS dynamic satellite simulator software. Those events are expected which models will run and when models will run.

Under "Soft Real-Time" scheduling concept, scheduler tries to make the simulation time same with real world time, i.e., Zulu Time, as close as it can. Scheduler adjusts the simulation time in order to prevent it from deviating from Zulu Time too much.

Under "Non Real-Time" scheduling concept, scheduler does not manage the simulation time since it is almost impossible to handle correctly the delay introduced by HAL I/F. So, scheduler will pause whole simulation time and wait until a feedback is delivered from HAL I/F.

Simulation model consists of service and data and these service and data can be published to simulator platform thanks to SMI APIs like SMIPublishService() API and SMIPublishData() API. Especially service can be used by scheduler for the target entry point of event handler. Scheduled event can be registered by SMIExtScheduleEvent() API with Cycle Time and Delta Time parameters. So, the event handler published by SMIPublishService() API can be called periodically or aperiodically if Cycle Time is assigned or not.

The prototypes of these APIs which are implemented in current porting are summarized as shown in Table 1.

To hold these schedule information, simple data structure based on the above parameter lists shown in Table 1 is introduced. And, special data for Remain Time is added to the data structure. Remain Time designates a time which is left to an event from current simulation time. Remain Time is crucial concept since scheduler works along with processor emulator but with simulator itself. So, minimal thread collaboration is introduced for this scheduler design. Only two threads are necessary. One is for scheduler, and the other is for processor emulator handling. An event which has the shortest Remain Time is supposed to be called after passing the shortest Remain Time.

Because current processing power of personal computer or workstation is much higher than satellite on-board computer, the simulation time is much smaller than real world time. As the result, a user can see the simulation as like quick moving picture. Of course it may be helpful to cover a long time simulation period of low activity quickly. As shown in Fig. 5, load balancing can be used to boost up or slow down the simulation period which shown to user.

So, scheduler operates as shown in Fig. 6 (ESA 2008). Scheduler services the periodical or aperiodical event if applicable. Otherwise processor emulator dominantly possess the simulation time until new event is available. Actually processing time of each event is not reflected at simulation time. If simulation time is too deviated to real world time, Zulu Time, simulation is paused thanks to simulation time balancing (load balancing).

A demo simulator which consists of following item or processing is proposed.

- Simulator model registration

- Simulator model initialization

Add several services through SMIPublish Service() API

- Pusle per second (PPS) handler

- Mil bus handler

Set schedul through SMIExtScheduleEvent() API

- PPS handler, set to 1 sec cycle

- Mil bus handler, set to 4 sec cycle with 4 sec delay

- Scheduler initialization

- Simulation start

Add one shot event

- Just with 30 ms delay

Delete scheduled event through SMIExt DeleteEvent() API

- Second delete Mil bus event after 11 sec from deleting PPS event

- Simulation stop

- Scheduler stop

In this demo simulator, the tested simulator model is the exact same with simulator models which are working on SIMSAT v 4.0. The only difference is TSIM from Aeroflex Gaisler which is used for processor emulator for ERC32 sparc processor. It means there is no dependency to processor emulator for scheduler implementation. Fig. 7 presents a demo of SMI scheduler with example RTEMS program running with TSIM for ERC32. The demonstration is performed by above scheduled items. In left window in Fig. 7, scheduler event is being logged. In right window in Fig. 7, running message from the example RTEMS program is being displayed. So it can be concluded that the demo simulator well represents the scheduler functionality of SIMSAT for the view of compatibility on SMP/SMI under simplified demonstration purpose.

The purpose of developing simulator scheduler is to develop a mission specific simulator platform so as to cover new mission specific requirements more quickly in addition to reuse heritage simulator model compatible with SMP/SMI.

KARI has been developing simulated software test bench (STB) under SIMSAT 4.0 with simulator models which are designed to be compatible with SMP/SMI. Since recently a mission specific requirement is introduced, HAL supported satellite simulator is being considered to be developed (Koo & Lee 2009). It is checked that the proven simulator models can be used if a simulator platform supports SMP/SMI and commercial simulator models can be integrated in the simulator platform.

It would be a meaningful conclusion that the support to the SMP/SMI can reduce risk, cost, development time for the manufacture of the HAL supported satellite simulator.