Kartik wrote:The general FCS is a mix of g-demand at higher speeds and alpha-demand at lower speeds.
I don't know what a "general" one is, but the kind of mixed mode ones you are talking about is a specific instance of a design. It is a design choice made for whatever reasons. There is nothing that says that this is how things should be. It is a preference that is all. The handling would be different I think. Going by the control design,my guess is that an alpha rate FCS would hold a particular alpha demanded if stick is let go, and a g demand one would probably hold a particular g if the stick is let go.
Who said that design goes through multiple iterative spirals ? I've been in multiple aircraft design programs and they didn't go through multiple iterative spirals. The reason is simply that time is a luxury and the schedule drives the design- you need to get the drawings out to the supplier within very short time spans to get them to be able to meet their timelines for supplying parts.
Pardon the French. But
design is ALWAYS through multiple iterative spirals , even if you don't realize it . The reason for that is design is a multiple variable, multiple constraint optimization problem. There is no single analytic solution for such an optimization problem, but has to be arrived via iterations.
Take something as simple and sophomoric as a classic linear optimization problem you solve with the Simplex method using the computer between your ears and a pencil. Something like, points A, B, C and you should visit A before C and what should be the optimal route kind of problems. Try something like that in Excel (which is very easy) and the first thing you need to tell Excel how much iterations it should do before popping an answer (without that, there is no solution and is a singularity).
Think all that is airy fairy, well, let me tell you something that should ring very close if you are a structural engineer. Take an elementary case of a beam of lenght L and mass M and that is freely supported at the ends . The analytic solution of that is elementary and any moron who managed to pass undergrad Engg Mech class would answer that. Now if you are asked to solve that elementary problem, with very TFTA Finite Element Analysis, you would start off by breaking the beam into two of lengths L/2, impose end point conditions and start solving. The fidelity would be less for L/2 and will be far from the analytic solution , but quickly converges when the number of lengths start approaching say 6 to 8 ! (basically FEA is dumbing down a problem and then increasing fidelity, the equivalent of the mathematics of fitting a curve by assuming straight lines for a dx segments and then taking the limiting case of dx -> 0, but in math, the extending dx->0, the supercomputer between the ears does an elegant and brilliant job to have an analytic solution, but the electronic computer does some additions and subtractions very fast and comes up with an approximate solution)
When at the Madrassa we learnt the FEA stuff for class room purposes we did by hand for elementary cases. Kampooter was only when you wanted to increase fidelity and you decide on the number of iterations based on the convergence criteria desired (say from x to x+1 trial, the solution goes from y to Y+-dy where dy is very small and you stop). So, even in a CAD/CAM tool, you do an FEA analysis of a structure, the computer DOES the iterations behind the scenes, even though you seem to see an instantaneous solution on the screen. Oh well, that is the problem with the TFTA WYSWIG GUI interfaces these days. You tend to lose knowledge of how , what and why is exactly being done.
When you adjust any part of a design on a CAD/CAM tool, the entire thing is optimized by the computer, through well, iterations!
The only place where you dont do that is in exam /text book problems where there the problem is well defined and there are analytic solutions. In no other real world case is that possible.
What happens is that due to very short timelines or lack of experience, designers go with less optimal designs in the first cut, without thinking of ways to improve the design, and stress engineers instead of trying to optimize that design, simply go through their analysis and if it passes all checks with all margins positive, the design is released to suppliers.
Sorry, It didn't happen even in the days of slide rules & pre electronic calculator days. Like I said in the FEA example, at an overall system level, these things converge very quickly within two or three iterations to something quite close to optimal. In this day and age with computers and CAD/CAM etc, these kind of things take next to no time. Where things take time is at a detail design /component/subcomponent level where too the iterations/design optimizations are now possible within reasonable times thanks to the enormous computing power.
That is how the weight adds up over time as parts overshoot their initial weight estimates. The target weight didn't go up to 6500 kg like you claim- the weight went to 6500 kgs because of caution, conservativeness with methods used for design/stress and maybe in some cases, changed user requirements.
In most cases, the intial weight estimates of systems and stuff are usually pretty close to actual (because you tend to use off the shelf stuff, whose weights are well known and can use weights of comparables). The "surprises" are only in the brand new stuff you are developing from scratch (like the airframe weight for instance, or the landing gear weight if it is not an off the shelf / resize from existing item thing).
The bolded part of your post is a huge leap into the unknown, which while plausible is quite improbable and ranks along with causes such as "they used too much glue" in the list of probabilities.
Yes, in the first cut, because of lack of real world use of composites and stuff, there probably was over design , with the idea that as real world experience starts trickling in from the flight test program, you go through another iteration in terms of structural design for final optimization, but there is no way, you would arrive at a close to 20% weight increase (1t in a 5.5t airframe) for that sort of stuff as the final case. Something like 5% to 7% would be okay for final, 10 to 12% upper limit, beyond that, it has to be by design and no other reason, unless the engineers were Paki (which I assure you they are not). I would put the weight increase to additional systems being added and some amount of required strengthening as a result.
And yes, if you and I can read from the boards that the weight is going to be 6.5t empty, the structural enggs in ADA can surely read that as well! It is very simple that the strength has to be commensurate with a 6.5t airframe and if a 5.5t airframe design had been arrived at, it must by necessity have been strengthened.
Why would they not publish any change to the MTOW if that has been done? The Tejas Mk2's MTOW may go up (I hope it doesn't) but from all ADA figures published so far (including those that state 8G performance), MTOW is same.
That is why I smell a rat on the MTOW. Maybe the didn't put in a stronger undercarriage in the MK1 to qualify that MTOW (just a guess), the airframe definitely is more MTOW capable I think.
So apart from that, what else can lead to a fighter designed for 9Gs to be now able to get to 8Gs ? It has to be the excess airframe empty weight.
No. I told you already why that excess weight theory doesn't sound true. There are other reasons. For full 9g, I would estimate the alpha required is something like possibly 26 to 28 deg in a level turn with a bank angle of close to 85 deg. I don't think they are there. Even for FOC, I dont think they are promising that kind of alpha and hence the g limit.Maybe later they will get there with the EADS helping out. The FCS is probably not mature enough for that. Also, as a conscious decision until the full fatigue life estimates from service experience and large sample batches are in, you do want to limit G s pulled, maybe the fatigue tests for that kind of G loading is not done yet with the test specimens, who knows, there could be tons of reasons.
.
