loche

Indeed, statechart-simulated system reacts adequately only within a frame of several predefined scenarios. However in some cases drawing statechart is much more faster and easier way to obtain desired object behavior rather than doing detailed modeling. Consider a simple valve. Having input voltage, it's slowly opening until full open. Without voltage it's slowly closing until fully closed. As you can see, observable behavior of valve is very simple. There is no need to model locking mechanics or it's electric motor or turbulence of liquid, flowing through it. And statechart diagram easy suites simulation needs of such kind of objects - I believe I can draw it for 15 minutes :smilewink: The other case, where statecharts might be usefull, is complicated non-interactive processes, which could hardly be modelled directly. For example, current, voltage and power alternations during engine warm-up. The diagram of electric currents during such activity looks puzzly because it's affected by many different factors like chemical processes of accumulators discharge. In this case we just coding several "scenarios", each is characterised by specific outputs, and there is one control statechart which switch from one scenario to another.

Thank you very much for useful information and excuse me for dumb questions :doh: 1 years ago I participated in a similar project "Mi8T, Mi8MTV, Ka225 helicopters trainers" as a leader of airborn systems modeling team, so I was a little bit agitated when read about your project. Here is a link to our department page and the videos. Not much information unfortunatelly. Comparing our systems I can tell: * Our rotor model and hull aerodinamics uses finite elements method. It's based on TSAGI wind tunnels blowing statistics. I'm not sure but it seems more precise. For instance, we are modelling turbulent streams during landing on moving aircraft-carrier. * your damage model is much more detailed. We only imitate "the whole helicopter destruction" and some landing emergencies like "tail boom touchdown". * our environment modelling is also primitive - just some vehicles, aircrafts and ships, moving on predefined trajectories. * our visualisation/sensor system looks similar. It models various weather conditions like different kind of static clouds, fog, rain, day/night cycle, primitive dynamic shadows * for airborn systems modelling we used discrete integration with fixed step and executable statechart diagrams. Our airborn system models seems more detailed. We had implemented most of airborn systems malfunctions, specified in flight engeneer's manual. For instance for Ka226 we modelled such systems as "air system", "anti ice system", "electro system", "fire system", "fuel system", "heating system", "hydro system", "start system", "anti dust dumpers", "communication system", "transmission" and all navigation equipment. Example of Mi8T electro system malfunctions: "left/right generator failure", "accumulators failure", "main/aux current transducer faulire", "voltage loss during warm-up" The differences in level of detalization of our systems is due to different purposes: your model used in gaming, where higher level of interaction needed, and our is used to train newbie pilots, so we need more precise aerodynamics and airborn systems modelling sacrificing realistic environment. P.S. Sorry for my English :smilewink:

Hello. I'm interesting how detailed your helicopter simulation is. Do you simulate auto-rotation mode and vortex ring? Do you simulate any emergency situations like blade segments loss or tail boom rope breakdown? Do you simulate airborne systems malfunctions like various fuel system pump failures or electric system open-circuites ?