A simulation is a system that exhibits the behavior of and performs all or many of the functions of a real-world entity. As a system, it typically consists of hardware, software, complex electronics, mechanical hardware as framework or housing, etc. But is may consist of only software and the computer hardware on which it runs. A simulation exists because it serves to provide these behaviors and/or functions in a way much more flexible, feasible, cost effective, and controlled manner than the actual system being simulated.
The example of flight simulator is a good one. We have flight simulations for many reasons. Flight simulations provide training for pilots. Companies that build certified flight training simulations are typically as or more complex than the aircraft they simulate and they do it with fidelity (reality) in every way as accurate as the real aircraft. But they can additionally provide the pilot trainee with the experience of flying without the danger. More importantly, the simulation can do things that the real aircraft cannot such as simulate in a totally controlled manner any number of failures of the aircraft that a pilot would have to know how to deal with. These aircraft malfunctions are inserted by the instructor who has an instructor station interface with the simulation and can cause one or more malfunctions to be simulated at any time.
Similarly, there are engineering simulations that are used for developing aircraft (manned and unmanned as well as missiles). These simulations exhibit the planned or required or to-be-developed characteristics of an air vehicle yet to be realized. Thus the simulation represents a virtual capability and is used as an engineering tool to develop, verify, and validate requirements and design for an air vehicle yet to be realized and at various stages of development.
Simulations represent opportunities to model and represent realities and explore real situations in a controlled virtual environment. So, as example, real physical events are possible to simulate that are statistic in nature. Thus Monte Carlo statistical models can realistically and with great fidelity “color” the more deterministic characteristics of an aircraft’s aerodynamics. And various characteristics of the atmosphere can be simulated in a controlled fashion. These include clear air turbulence (CAT), icing conditions, condensing fog, etc. So it is grossly an error to say that simulations are typically of lower fidelity than the actual system being simulated.
What makes a simulation different from an emulation is that the simulation is used as a standalone reference for the desired observable behavior and/or functionality. It is not (typically) used in place of the thing that is being simulated.
Another thing about simulations that has been misrepresented here is that a simulation does not necessarily provide an “exact” interface. That is absolutely not correct. In fact most all engineering simulations simulate exactly any number of desired physical interfaces as the “real” system being simulated. That is the purpose of many, if not all, simulations known as hardware-in-the-loop (HWIL) simulation systems. My organizations use simulations of various entities to interact in real-time with live actual systems. These interactions are used as test capabilities to test new versions of software or such in the systems under test which are stimulated by our simulations. In this capacity, the simulation is used much as an emulation but it is still a simulation because of the other diverse uses of the simulation as a distinctly standalone simulation system.
This brings the discussion to emulation. An emulation is typically like a simulation in that it exhibits desired behavior and/or functions of the “real” system being emulated or simulated. But the primary difference is that an emulation is typically used in an operational context where it is put in place of the “real” system being emulated. Thus it is a representation of a system for purposes of cost, feasibility, flexibility, control, etc.
Unlike what was said earlier, the emulation does not have to be a full exact replication of the system being emulated. Only those features, behaviors, functions of the real system desired are replicated. An emulation does have to function as a surrogate for the real system in an meaningful operational environment as it interfaces with those things the real system would interface and interact with – most typically in real-time. That the emulation is not an exact replication of the system it emulates is so that it can incorporate features not typically available in the real system and do it in a controlled manner.
Example of this is, again, exhibiting in a controlled and commanded fashion any number of off-nominal or failed or degraded (but real) behaviors and/or functions of the actual system that it would be impossible for the actual system to exhibit “on demand”. Consider a system (call it System A) that interacts dynamically within the context of a system of systems. Consider that System A interacts with other systems in this operational context but primarily it interacts with System B. Now consider that System A has behavior that depends on its external temperature and humidity environment or some other environmental condition. How would one test or evaluate software changes System B in its interaction with System A for all possible environmental conditions? Simple, build an emulation of System A in which the emulation could be made to exhibit on demand the exact behavior of System A in any desired environmental conditions. With this System A Emulator, an organization can, in a controlled environment completely test their System B in its operation with System A in any possible environmental condition. And best of all, the emulation may be cheaper than the actual System A and provide features impossible to achieve with a “real” System A.
Now one has the idea of the value and utility of an emulation in engineering. Hopefully this discussion has clarified some points made incorrectly by other commenters above.