Applications Products Support About EuroSim
|
Home
Contact
Applications Products Support About EuroSim |
|
|
FeaturesEuroSim Client/Server ArchitectureThe execution of a model occurs in a client/server environment; the main client is the Test Conductor user interface, which reflects the state of the simulation and allows requests to be made wrt simulation execution which are then sent via events to the simulation server; other clients include data monitors which are continually sent the updated values of the specified API data variables. The server has two parts: a synchronous part which is responsible for the hard real-time behaviour of the simulation, and an asynchronous part which decouples activities such as model data input and output (stimuli and recording), checking for manual triggering of actions, checking simulation state change requests, etc. 
Distributed Architecture A distinction is made between the clients of the simulator (eg. processes representing the Test Conductor and Observer, processes such as the on-line monitors) and the actual simulation processes. This means that multiple clients can easily be interfaced to the server process, and also that use can be made of local terminals for the front-end whilst using more powerful machines to execute the actual simulation. The interface between client and server is implemented through various virtual channels which send and receive events. On start-up, clients connect to one or more channels, according to the type of event(s) in which they have an interest. For example, there is a channel for the simulation control events (eg. freeze, run), another one for the mission events (eg, executeAction, openMission, saveMission). The use of channels allows messages to be broadcast to all interested clients where necessary, eg. a closeMission event can be communicated to all relevant parties via the mission channel; a stopSimulation event can be picked up by an external simulator which is connected as a client via the control channel. The asynchronous server process is also responsible for checking the requests from the client processes. This means that if a request to pause the simulation is sent as an event from the TestController, it is checked by the server process, and if approved, then the transition to stand-by is initiated and an event is broadcast to the TestController (and other appropriate clients) to inform that the simulation is going to the stand-by state. Esim-daemon The 'esim-daemon' is a typical Unix daemon (ie. a Unix process permanently running in the background) which provides the mechanism for starting EuroSim simulation processes and for configuring the target hardware. A machine in a network running this daemon is called a EuroSim Simulation Server. A simulation server can launch simulators, ie. executable versions of the simulation models. In a network, there may be several simulation servers available at any time. A simulation server can support several (non realtime) simulators at any time (see below). The functions of the esim-daemon are fourfold:
|