brianacooper11 Member



Join Date: Apr 2016 Location: Cincinnati, Ohio, USA Posts: 128





First off, I picked the Tu-22M3 because it's largely an analog airplane. Most systems or cockpit indicators just do a few simple things, and they don't talk as much with each other. The code for them will have low complexity. One measure of this is



Now, before I produce a single line of code, I create a monstrous Design Document (DD). That's where you spell out in plain English or with engineering diagrams what every cockpit indication does, how every single system works in detail. It keeps the software project organized. It highlights work scope creep. It gives you a metric to measure progress. It also, most importantly, allows you to split up work, and I will be delegating like gangbusters. I am in a position due to experience and training, to go through tons of Russian documentation, translate it, and then incorporate the stuff that's relevent to simulation into the design document. In just that respect, I am doing something by myself. But A design document is sufficiently detailed for a programmer with no knowledge of the system to go and implement it in code. My wife is a programmer. Tons of my friends are programmers; they are engineers too, so they have tools like Simulink, detailed below. DD. Delegation. Those are what will make this project awesome and on time.



Engineers like me who have to incorporate electronics on our aircraft or engines are programmers by circumstance, and even then, under duress. We think and communicate in diagrams, equations, concepts. A fuel system isn't a bunch of ones and zeros, it's twelve damned fuel tanks with various pumps, vents, fire suppression systems and cockpit indications. Engineers have long switched to graphical programming environments like Simulink, and to a lesser extent NPSS (Numerical Propulsion Simulation something-or-other) to program simulations of physical systems faster and more accurately than with hand code. It looks like this:









Simulink takes those diagrams and converts them to C-code, and can them compile them into the dll(s) that DCS will use. I can test my logic at a very high level, within simulink, I will do a validation check of the added system in DCS, and it gets checked again when alpha and beta (since there are four positions, maybe we have alpha, beta, gamma and delta testers?) testers get their hands on it. I can even program HUDS (there isn't one in this case) and displays within Simulink/Matlab, and trade args with the airframe and cockpit in this environment. It's far faster and easier in this way. Eventually, there is C++ and lua programming required to tie everything together, but high level stuff is done in Simulink.



I'm not sure I can give a quick explanation here of how I am going to do the flight and engine models. Maybe later. I will be using some modern tools for both that should let me create accurate models quickly, that can then be validated by open source information I have on both. The Tu-22M3 has one or two aerodynamic bugaboos, a nasty stall with the wings swept, plus the wings flex as much as eight degrees at high sweep, high load factor and high angle of attack. That cannot be ignored aerodynamically, but all of these issues have been faced and solved by others before me.



To summarize the things that make this simulation tractable:

- I chose an aircraft with significantly less complexity than it's brethren.

- Design Document

- Delegation

- Graphical programming environment (Simulink/Matlab)

- Modern software tools for speedy flight and engine modeling



In the midst of all this, I personally have two unknowns. At present I'm not sure how to impliment multi-crewing. I know it's been done for two; I assume there is some way to do four. If any of you have solid thoughts on solving that particular item, I'm all ears. I'm also not going to take the time to model the radar reflectivity of the terrain for the radars, so I hope to lean on ED's experience for that, but we'll see what happens.



I hope this was informative, and not preachy.



Brian Reading these responses, I perceive excitement and hope, but I also perceive doubt about eventual success. I also neglected to mention some important details in the initial announcement (updated). I'd like to explain my battle-plan for the programming effort, in the hope that the whole effort will be believable.First off, I picked the Tu-22M3 because it's largely an analog airplane. Most systems or cockpit indicators just do a few simple things, and they don't talk as much with each other. The code for them will have low complexity. One measure of this is cyclomatic complexity . Contrast this with the F/A-18 ED is working on, or any modern real world aircraft for that matter. Their cockpit displays and aircraft systems are extremely integrated, and as the degree of integration or complexity increases, the development effort increases exponentially. That's just my experience. The Tu-22M3 has redundant systems, but they are a 'simple' redundancy: they are in parallel, like power buses, or there are two or more physical units like airspeed indicators. If something breaks, you don't have to program a reaction to it. On modern systems, if something fails, all the computers have a stupid confab about it, and often decide to DO something, like swap channels, or vote on the best source of data, or average the remaining sources of data. The options are endless, and the powers that be dictate that all options must be implemented. Tons of code results. Ask the ED guys about it on the F/A-18. The Tu-160, B-52, B-1B, etc all have at multiple integrated digital systems that would have ground things to a halt. With the Tu-22M3, I don't have to deal with that. If the BN's airspeed indicator dies, he asks the pilot to read him airspeeds. If the autopilot goes out, he starts giving course corrections to the pilot. This isn't ideal in the real world, and that's why we have progress, but for our simulation purposes, it makes my life much, much easier. An Su-24 is similar to to the Tu-22M3 in this respect, but it requires a single player to be in two places at once during the final critical phases of a bombing run or weapons launch, as the pilot is truly directing the airplane, but he doesn't have the attack radar in front of him, and in the final moments, you need EVERYTHING for cross-checking. The Tu-22M3 is a bit old fashioned, in that the pilot hands off the plane to the BN entirely, and you only need to be in that position during the bombing run. You've got the optical bombsight, autopilot control, attack radar, nav radar, and standard six pack instruments all at that single station. Some weapons controls are at EW but you can preset all that, and pickle from the BN seat. A single player doesn't have to go mad. There will be optional AI for the RWR for single player mode. For these reasons of complexity, and a reasonable single player experience, there is only one option in a modern bomber: Tu-22M3.Now, before I produce a single line of code, I create a monstrous Design Document (DD). That's where you spell out in plain English or with engineering diagrams what every cockpit indication does, how every single system works in detail. It keeps the software project organized. It highlights work scope creep. It gives you a metric to measure progress. It also, most importantly, allows you to split up work, and I will be delegating like gangbusters. I am in a position due to experience and training, to go through tons of Russian documentation, translate it, and then incorporate the stuff that's relevent to simulation into the design document. In just that respect, I am doing something by myself. But A design document is sufficiently detailed for a programmer with no knowledge of the system to go and implement it in code. My wife is a programmer. Tons of my friends are programmers; they are engineers too, so they have tools like Simulink, detailed below. DD. Delegation. Those are what will make this project awesome and on time.Engineers like me who have to incorporate electronics on our aircraft or engines are programmers by circumstance, and even then, under duress. We think and communicate in diagrams, equations, concepts. A fuel system isn't a bunch of ones and zeros, it's twelve damned fuel tanks with various pumps, vents, fire suppression systems and cockpit indications. Engineers have long switched to graphical programming environments like Simulink, and to a lesser extent NPSS (Numerical Propulsion Simulation something-or-other) to program simulations of physical systems faster and more accurately than with hand code. It looks like this:Simulink takes those diagrams and converts them to C-code, and can them compile them into the dll(s) that DCS will use. I can test my logic at a very high level, within simulink, I will do a validation check of the added system in DCS, and it gets checked again when alpha and beta (since there are four positions, maybe we have alpha, beta, gamma and delta testers?) testers get their hands on it. I can even program HUDS (there isn't one in this case) and displays within Simulink/Matlab, and trade args with the airframe and cockpit in this environment. It's far faster and easier in this way. Eventually, there is C++ and lua programming required to tie everything together, but high level stuff is done in Simulink.I'm not sure I can give a quick explanation here of how I am going to do the flight and engine models. Maybe later. I will be using some modern tools for both that should let me create accurate models quickly, that can then be validated by open source information I have on both. The Tu-22M3 has one or two aerodynamic bugaboos, a nasty stall with the wings swept, plus the wings flex as much as eight degrees at high sweep, high load factor and high angle of attack. That cannot be ignored aerodynamically, but all of these issues have been faced and solved by others before me.To summarize the things that make this simulation tractable:- I chose an aircraft with significantly less complexity than it's brethren.- Design Document- Delegation- Graphical programming environment (Simulink/Matlab)- Modern software tools for speedy flight and engine modelingIn the midst of all this, I personally have two unknowns. At present I'm not sure how to impliment multi-crewing. I know it's been done for two; I assume there is some way to do four. If any of you have solid thoughts on solving that particular item, I'm all ears. I'm also not going to take the time to model the radar reflectivity of the terrain for the radars, so I hope to lean on ED's experience for that, but we'll see what happens.I hope this was informative, and not preachy.Brian Last edited by brianacooper11; 05-08-2016 at 07:19 PM .