or you might end up getting results that don't match what you thought they would, especially if the simulation will be flown by crews that are type rated on the aircraft you're simulating.
I know quite a bit about this subject, as I spent several years working very closely with BAE research labs at Bristol on a very complex A320 like simulation that they did a number of research projects on as part of several europe wide programmes, and my responsibility was a substantial part of the PC software integration, and much of the hardware side of it, along with the integration with some very specialised eye movement tracking equipment.
It's network PC based, (it uses 12 for the basic simulation and visuals, has dual crew capability, a full glareshield fit, which operates in a very similar manner to the aircraft, and a full overhead panel that I'm going to mention in more detail in a moment, and we also had to put in throttles and other centre console items that work the way the real aircraft does, including reverse thrust activators, blocked until the simulation is happy that the wheels are on the ground.
The most important thing to be aware of, and which will cause you huge pain if it's wrong is that for certain emergencies, the crew have specific memory items that they do, and they are mandatory at the start of the analysis procedure, before they even think about going to look at check lists or ECAM actions, and if they can't carry out those mandatory items on the sim you build, if they then have to stop and think about how they are going to deal with the differences, there is then the risk of invalidating what follows.
To try and avoid this at Bristol, we ended up having to build a complete replication of the A320 overhead panel, including the dual illumination of many of the switches, and we then had to get substantial parts of it to work in the way that the A320 does, and getting accurate information was one of our biggest headaches, even though the project was being controlled and coordinated by an Airbus partner.
There are other issues as well, but these were the areas that caused most of the problems. The other issue will be how you drive some of the secondary instruments so that the failures are meaningful, if you're using Magenta and Flight simulator, while some things can be made to happen, the integration of the systems area in FS will make it VERY hard to get things to synchronise in a way that will make the analysis of what's failed into an accurate one.
The best of luck with this, I know from painful experience that you're heading off on a very bumpy road.
Another thought, if you're using FS, don't even think of going down the road of manual reversion landings, the flight model just is not stable enough to be able to do it with any degree of accuracy. Many of the other subtle failures that have been suggested here are also going to be hard to reproduce, as you won't have access at a deep enough level into the core of the simulation to make the end result accurate enough that it can be correctly diagnosed.
Many of the items suggested above are valid, but doing them won't be possible, as the underlying systems that will be affected are not dynamically modelled in a way that will allow you to control what's being displayed, so the instruments will not give information in a manner that will aid diagnosis, and getting the overhead to synchronise so that it helps will also not be easy.
If that sounds discouraging, it's not meant to, but it is intended to act as a gentle warning that some of the things that might be "nice" to do are not going to be practical at the level of simulation you're aiming at using.
Hope it helps a little