Returning to the dictionary once again, a simulator is defined as ‘a piece of equipment that is designed to represent real conditions’. In the real world, pilots have simulators to mimic the experience of flying without the risk of damage from a crash. In software, most commonly in system testing, simulators will act like the various subsystems that your software will have to communicate with.
Designed to supply a realistic interface, a simulator will mimic the various interfaces in such a way that your software will not know it is talking to a simulator. As far as it is aware the software is in a live environment, and as such is receiving real messages.
For example, for a train control system (TCS), if your code were to send out a request to increase motors to x%, you would expect two things to happen. One, the simulator returns a realistic response to the request that is either positive or negative. Two, that your code responds appropriately to the simulators response or, in the worst case scenario, that it fails safely. Of course, this is an oversimplification of a very complex system, only focusing on one specific interaction between two interfaces. In reality, a simulator for a TCS would have to replicate a multitude of subsystems to ensure a realistic environment.