I built my first home made 1000 watt RF amp when i was 14 years old, it used a residential line tranformer core (out of the can full of PCB oil) turned backwards for the supply.

What is happening here is that the people makeing the decisions are not the techs, and the techs have been too far removed from the deliberating process.

A system that was truly modular could adapt to any new requirment you threw at it, this goes double for the new software defined radio as long as its technical specs, factors such as freq range, reciver quality characteristics such as sensitivity, internal noise, dynamic range etc, are defined.

Software defined radios do have some limits however the cheap MMIC at the heart of all our wifi cards are not within the range of software definable tech so you need traditional down conversion behind it, and transmitter gear of any power at all is freq range limited.

And I would caution at the one size fits all approach.

Give me one of those radios, and I could design something to disrupt it. design a transmitter to aggravate a self resonat characteristic on one of its front end components.

Spread spectrum is hard to jam, so you would attack the charateristic of a front end part etc.

one output stage covering 2mhz-2ghz at power would be a major feat, i doubt they did that without more than one output stage.

Now they want to extend that ?

Perhaps by pulling out the 2-50mhz module and inserting the 2-4 gig module, getting really wideband at power becomes tech dreamland fast.

But all at once ?
I think they are guilty of overreach.

We are a silicon based society in electronics, but there is a reason Broadcast radio and TV still uses vac Tubes for power.

One of the interesting things to watch is the Pentagon's tendency to bundle lots of things that could probably be done better separately into one humongous program, given to one contractor.

Why couldn't DoD's own people define the software and hardware standards, have repeated comment/question periods in the design, and then contract out the specific components? Why write one set of detailed requirements that stop short of specifying the standard completely, hand them off to a contractor to complete, and then change them later?

Can somebody explain?

My guess: because with one contractor, there's one party to hold accountable if the project fails or falters, and that's worth more to the key decision makers at various levels. I see that same dynamic in business all the time.

A more decentralized approach may or may not reduce project risk, but it absolutely increased the personal risk to the project and program managers both within the Pentagon bureaucracy and with respect to Congress. Who also like things to be neat, tidy, and accountable.

Some projects do step out of this mold, and the war has spawned a few of them. But something the size and complexity of JTRS is not a likely candidate.

That's just an educated guess, of course. I could be wrong...

As one involved in the JTRS/FCS fray, I must say that it certainly looks different from the inside than it does from the outside. So I'll make this a long-ish post, to try to get at some dynamics that might not be obvious to outsiders.

The two perspectives are not contradictory, but those outside get only a tiny part of what's happening, then extrapolate it based on their model of 'how things work', and come to inferences that just do not accord with reality. Plus they miss things that seem like long, tenuous chains of guesswork to outsiders - but which are solid everyday experience to those inside.

This cuts both ways. Some things are better than outsiders think; some are worse. And, like any dynamic system, most of the project's energy goes into maintaining day-to-day coherent functioning, which makes a lot of it rather dull.

The biggest problem with JTRS/FCS is the big problem that all non-tiny US defense projects have: far too much up front paperwork, far too little real and early experimentation (as opposed to staged 'demos' with pre-determined outcomes), far too many layers of paperwork, and far too little decisionmaking by technical experts.

This is a result of several factors, the greatest of which is the need to make non-technical government minders feel comfortable. This controls everything else, because w/o government comfort you lose the contract. And you only get the contract if they feel comfortable going in. So it's like selective survival in a Darwinian system of evolution: an amazing number of subtle and complicated effects arise from this one simple, brute fact.

And what they are comfortable with is bureacratic procedure - not science and engineering. Sure they know a bunch of buzz-words (and schedules and budgets and very powerful people), but anyone who can't explain the Fourier transform, or the FFT algorithm, or how a stream cipher relates to spread spectrum, or why simple encrypt-then-sign does not guarantee security has no business claiming they understand the technology of secure radios. How can you talk about the problems of battery-powered wide spectrum mobile radios unless you can explain something as basic as the tradeoff between bandwidth and power? And I mean 'explain' in the rather deep sense of 'derive the equation governing the tradeoff'. That is, I mean 'explain' and 'understand' the way a scientist means them. Anyone in defense work knows how bureacrats respond when asked such a challenging question (politely and indirectly, of course). Of course, managers can not always get deep into the details of everything, but they need to have the technical background and habits of mind to know when they are seeing something real, and when they are dealing with a buzzword artist. At the very least, they should understand the difference between 'desirable results of success' and 'technical means of achieving success'.

Let me give a tiny example of how this abstract problem can manifest itself in concrete instances. Details have been altered to contradict reality in inessential ways, so as to protect the identities. I was once on a project where the obvious way to do essentially the whole problem was to setup and solve a XXX problem. (I won't say what XXX was, because that might enable someone involved to recognize which project is being discussed). But it was really basic stuff - like a Laplace transformation. It didn't need to be anything complicated. Following the analogy, it would be Laplace, not Esscher transforms, or wavelet transforms, or anything but the plain vanilla Laplace (and not the equally simple Fourier transform). Basically, there were two or three basic techniques that might be applied, and a zillion sophisticated ones. A layman would be lost, but an expert would find it trivial.

Of course, there was some data-massaging on the input side and some pretty graphics on the output side, but the core problem was pretty simple (but very large). To an expert, to someone who really 'gets' the connection between mathematics and the real world, it was obvious in a flash (see the book "Blink"). But to someone who understands math as just a bunch of painful squiggles a teacher once forced upon them, there can never be any intuitively obvious connection between practical problems and formal solutions.

In fact, it was obvious at a glance that XXX was the ONLY reasonable approach. But the government folks simply could not accept the judgement of the experts whom they had hired specifically for their expert judgement. For the government folks, there just had to be a whole 'system engineering process', with all the documentation, cross-checking, and second-guessing that enables and requires. So they called in a second team, who listened to the problem statement, then declared that XXX was the only reasonable approach. The second team included some nationally prominent leaders in the community with very good government connections. But that snap judgement did not have requirements decomposition, functional decomposition of the domain, UML object model, sequence diagrams, tool justification, validation, requirements cross-walk, analysis of alternatives, etc. In short, not enough paperwork. So the government imposed a complicated and multi-month process of analysis on the team - which dutifully ran through the whole process for months, and finally concluded that XXX was the way to go.

The government folks then decided that the experts were just 'gaming the system' to arrive at a pre-determined conclusion, and called in a third team! Of course, they were presented with only a briefing on the problem, not on the history of the program. They took one look at the problem, declared that XXX was obvious way to go, and asked why anyone would even bother seeking an expert opinion in such an obvious matter.

... crickets chirping, soft breezes whispering ...

But by then the money was pretty much exhausted, and the project was terminated shortly thereafter - with absolutely no result besides frustration all around.

Anyone in defense work can cite a bunch of similar examples.

We do get work done, but there is a tremendous overhead of wasted effort that goes along with each little bit of real progress. And the only solution the government bureacrats have to late and expensive programs is to impose more bureacratic procedures. Which just makes it worse, like so many people's neurotic responses to their problems. The amazing thing is not the burdens which we all carry, but how much we imperfect people really do accomplish in this very imperfect world.

So I repeat: the biggest impediment to all US defense programs is the need to do excessive bureacratic busywork to reassure non-technical government managers.

Of course planning, budgeting, and accoutability are absolutely required for success. But it is like most neurosis: they were once reasonable and adaptive behaviors - but when done to an excessive degree, and/or outside the situation in which they were helpful, they become a harmful neurosis. And the government requires that their procedures get mirrored in the private firms, so the neurosis spreads. We do our contracting the way Soviets tried to do military operations - with minutely detailed and inflexible orders. We do not use German 'auftragtaktik' on anything but tiny projects, even though we claim we do. (This is part of why DARPA is so successful.) A primary requirement of auftragstaktik is trust in one's colleagues - and that is exactly what is missing (as the above story illustrates).

On several occaisons, we have worked with foreign governments. They were so different that some of our very-senior folks were confused and worried. It was like seeing a long-term prisoner suddenly ejected into freedom: they just did not know how to function in a very self-directed way, without the constant intrusive control. Essentially, the foreigner customers would negotiate the goals, cost, schedule - then step away! They did not try to control - or even monitor - every aspect of how we acheived those goals. When our very-senior folks tentatively asked (in essence) why they were not bugging us every day about every little detail the customer replied (in essence) "we trust you to do it well; why else would we hire you?" Amusingly, even the Germans were less intrusive and controlling than the Americans, though the Germans were the most controlling of any non-Americans for which we have worked. I think it has something to do with the European tendency to automatically respect and defer to experts with titles, while the American tendency is to distrust anyone who seems intellectual.

So JTRS and FCS face challenges - but the greatest ones are imposed by ourselves. "No man is free who is not master of himself", and inflexible neurotic behavior is the most common loss of self-mastery in persons and organizations.

Thanks, laocoon. Folks, his/her description is a dead-on account of things from the engineer's viewpoint.

Let's see if I can supplement that as someone who was a program manager back in the day and teaches a systems engineering process.

An engineer's job is to make his/her system/sub-system work. In other words, engineers are (rightly) focused on the internal implementation of their project.

Systems engineering deals with complexity. In particular, systems engineering deals with systems made up of many parts which interact. Often those parts are themselves complex systems.

So what? you ask. My software/hardware/comm network is pretty complex and I manage to get it to work, if the boss/customer stays out of my way.

Okay, often engineers do just that. But sometimes there's a tradeoff that needs to be made. Sometimes it's quite difficult to determine the best overall design approach, i.e. the approach that optimizes the overall system, because of the complexity involved.

For instance, to take an example from my past, one project team may use a computational algorithm that is quite standard, seems appropriate to the intended use of the device and entails a known and acceptable loss of precision in its calculations.

Not a problem - if that software operates in a standalong mode or is only loosely coupled with other software systems.

But if it is part of a chain of programs, each of which processes data in a stream and then passes it along to the next program, it suddenly becomes a lot more important to figure out what impact the loss of precision in our project team's design will have on the whole system of programs. Is there a subtle conflict between the nature and extent of data distortion in this step and what happens at other steps?

That's not intuitively obvious without some careful analysis. Most of the time the analysis will confirm that the project team's approach is the right one. Occasionally, though, it turns out that the best overall approach is for our team to use an algorithm that is somewhat less optimal when seen from the perspective of only their portion of the system.

Systems engineering is a set of techniques for figuring out that sort of thing.

Program managers are the people with overall responsibility for fielding a system that has the desired operational capability. Nearly always, in defense programs, that system must play as part of a larger, more complex system of interacting capabilities. For instance, radios are one part of a very complex connected battlefield.

So a program manager uses review and systems engineering processes to manage risk.

I've seen this from both sides. I've lead very small, rapid time-to-market product engineering teams that beat out the big guys with hardware and software that worked. But then, noone's life depended on that equipment, we weren't rolling out hundreds of thousands of them at once, we could upgrade as necessary and the equipment didn't have to interact in real time with a wide variety of other stuff in a dependable way for 20 years.

Hence the paperwork from the government side. Is it overdone? Sometimes, sure. But remember that situation a while back where a spacecraft was lost because one team was using meters/centimeters for a calculation and the other team assumed the numbers were inches / feet?

That's what the systems engineering process guards against. Among other contributions ....

Robin,

I think you are dead-on about what system engineering is supposed to do. But it usually does not work out that way, except on small projects. I was addressing the problem of why such a nice set of theories don't work out so well in practice. Compare to communism: it sounds good and noble in theory, and works very well in small groups (e.g. one family) - but it is a disaster in non-small groups.

I forgot to add that I am a program manager and a business developer, as well as scientist. I understand the manager's perspective quite well, I've certainly made my share of budget-driven programatic decisions, and I've certainly raked folks over the coals for having their progress metrics out of kilter. But while some project metrics are useful, and it is absolutely essential that we have them, nevertheless 95% are what the psychologists call "displacement activities": irrelevant things we do because we can't address the real problem, but can't stand to do nothing. So we do something irrelevant and try to persuade ourselves that it helps. It creates the illusion of control which helps non-technical people cope with the agonizing uncertainty of waiting while their career hangs in jeopardy.

Don't think I'm 'standing up for engineers against management'. Narrow-minded technologists are as frustrating as narrow-minded managers. I often have to tell engineers to get their heads up out of the weeds and pay attention to the big picture.

I once asked an engineer what how much package Z was going to weigh, and she replied "I have no **** idea", so I launched into the following routine.

L: "Does it weigh more than 1 ounce?"
E: "Of course!"
L: "Does it weight less than 1 ton?"
E: "Of course!"
L: "OK, so you do have some idea. Now tell me what you do know."

Well, it turns out that she wasn't sure whether it would be 500 lbs or 550 lbs. All I needed to know was whether it was over 750, and we were deadlocked, wasting time while she agonized over irrelvent details.

I've seen it from both sides, too. The neurotic detail obsession of engineers can be a real problem, but it is not the kind of thing that can kill a multi-billion dollar project.

Another thing which is challenging about FCS is that it is a "system of systems" project. They are not designing a "system" (i.e. fully equipped vehicle) but a whole fleet of interacting vehicles. You absolutely can not design something that big and complex by analyzing every little detail. That might work when work when designing a tank, but not FCS. You have to take a multi-level perspective, integrating abstracted models of the whole thing with detailed individual models.

I agree that 'system engineering' is supposed to help figure that sort of thing out. But it does not work that way in practice, partially because system engineering is not engineering, as I learned twenty years ago. It is a set of US-government approved procedures for the management of engineering projects. I know it inside out, and I practice it every day.

In real engineering, in a certain sense, scale does not matter. F=MA at all scales, from nano-technology to detecting large planets around distant stars. Calculating the Lyapunov exponent of a process is the same, whether you look at the second-to-second variations of a stock's price or the million-year variations in the orbit of Pluto. No one would argue that nanotechnology is 'just like' astrophysics, but there is a sense in which both are built on real physical law, not upon agreements between persons. SE is a set of agreed procedures. They are good ones when applied with common sense and good will - but they are still just agreed-upon conventions.

Because it is not really engineering but a management process, SE is just another place for the same neurosis-formation process to play out, not a cure for the process. A reasonable amount of SE is absolutely essential for success, I've done it on every project I've managed, I've taught it to my subordinates, and it is invaluable - but it does not stop the dynamics of human psychology from operating.

The tools of SE are great in the right place in the right amount, "but when done to an excessive degree, and/or outside the situation in which they were helpful, they become a harmful neurosis."

Here's another example. We had to review the work of a team which was doing a trade-off study whose objective was to select a technology for a task. Important detail: they were only to select the technology, not to schedule the work, estimate the budget, or any of the other necessary follow-on. Just say "Use technology X, not Y or Z,"

There were maybe two dozen technologies they considered. Most were completely and prima facia infeasible. Of the half-dozen left, one was better in every single respect than all the others. Cheaper, lighter, better, faster to deploy, lower risk to develop, and so on. It was better than all the alternatives in every dimension, and very obviously so. Everyone agreed to this. Just by listing the alternatives it was obvious.

Yet they spent months and months, and millions of taxpayer dollars, doing an exhaustive analysis of the exact numerical margin by which it was superior along each dimension. Why? See my previous post!

And the system engineering process does not really guard against small or large errors to anything like the degree people would like to think it does. I've seen a half-decade of paper analysis via system engineering get blown away by one morning of real experimentation. The SE folks had been so burdened by the paperwork involved in trying to process just one concept that they never had time to consider any other. The burden of paperwork had removed all mental agility (which is part of what's wrong with our whole intelligence apparatis, IMHO).

Yes, I know that the Red Team Response is supposed to be part of it, but they (being part of the process) had the same burden. One Blue approach was considered, to deal with the one doctrinal Red response. Unfortunately, the raw junior green suitors who played Red in the simulation that morning were a bit more creative than hundreds of professionals locked into group think. Thank god we tested it in simulation before starting a procurement based on that concept!

For another example. Prior to the 1991 Gulf War, a major US Army testing agency had done all kinds of modeling, simulation, and testing, and concluded that it would take an average of N>1 direct hits from a M1 to reliably kill at T72. Yet we all know now that it is actually slightly less than 1 (because we usually had 1-shot-1-kill, but the shells would occaisonaly punch right through one and kill a second, making 0.5 shells per kill). How could they be so wrong? Because they blindly followed the process.

It's not a question of 'engineering vs. technical ' perspectives. It's a problem of completely losing grip on the real-world problem by becoming enmeshed in incoherent, over-elaborated processes. As long as you see the real-world, the processes are a great help.

Compare and contrast to Cicero's old line: "An excess of law is no law."

But I must go. I have to review a cost-benefit study of different procedures for defining the process of reviewing plans for ....

My sympathies, Laocoon. And for sure SE can be used badly or as a coverup.

There are some very complex systems where SE has been used to great effect by people who knew what they were doing. And I don't just mean the touchy-feely stuff .... I mean very sophisticated modeling and simulation of alternative decomposition of functions into different hardware/software configurations and interfaces. Models and simulations that proved to be within .01% of actual performance when prototypes of the most promising architectures were built.

That's real Systems Engineering and it is an engineering discipline.

(Some systems just can't be thrown together in the lab to see how things might work. Satellites and their sensor systems, for instance. Others will no doubt occur to readers. And some are not cost-effective to do that way even if it is feasible.)

The problem is that the softer parts of SE are easy to codify in processes that do indeed eat up time / energy. But don't knock the real discipline for that ...

The problem with the major DoD procurements is that Systems Engineering has decayed as a disipline due to factors both political and demographic.

The golden age of systems engineering was the 1960s and the space race. The Aerospace industry, where DoD spent most of its procurment bucks, has had the engineers and managers of that generation retire after the 1980's defense build up.

They were so few and so over worked that they did not have time to train adequate replacements in the disipline.

We have also has a number of major procurment scandles in those 40 odd years that limited the rotation between senior contractor management and the senior DoD, so the government policy makers are plug ingnorant as to the implications of their purely political decisions on the actual engineering.

Add to that the order of magnitude lower number of major systems engineering projects and you have a general collapse of competence in major military procurements all around.

What I expect will happen as far as military internet issues is concerned is the Army signals troops are going to patch something together with small business types and make it work. This will leave the Big military procuremnt companies scrambling as long as the war lasts.

If the war lasts too long then thing will get really interesting in the Chinese sense of the word for the "Iron Triangle of Interest" as the Internet will expose directly to the major Congresional/Defense company money interests what works and what does not.

When the Army is screaming for more C-17s and UAVs carrying JDAMs during a shooting war, it is going to be hard to sell F22s and F35s.

Folks,

Consider Robin's examples of system engineering.
(1) Systems must be designed by a recursive process of first functional analysis and then system synthesis.
(2) Separately optimizing subsystems usually does not optimize the whole system.

These are unarguably true and valuable principles, and the teachers of SE are performing a valuable service by teaching not only them but also the tools and procedures that let people effectively act in accordance with them (rather than just thrashing around in a well-intentioned but disorganized crowd).

But the problem for me is that they seem too ubiquitous to say "this is a key tenent of system engineering". I agree that F=MA and the vector addition of forces are so important that they must be taught in any architectural curriculum (you must design the shape and location of beams so as to keep the beams' long-run displacement at zero inspite of gravity, wind, etc.), but I'd be pretty reluctant to say that F=MA, iterated integrals, or vector addition are essentially architectural notions. They simply are ubiquitous notions that appear in many places, with architecture being just one such place. Ditto for the above two principles and SE.

I'm sure that Robin or I could add a few more such general and important principles to the list, but the ubiquity problem remains. I think that SE can best be understood by looking at the non-ubiquitous parts that make SE unique, as distinct from architecture, basic programming, and so on. Read an SE book. You'll see that the main content is a body of recommended procedures for managing and tracking the recursive application of these principle to large projects. That is, SE is a set of procedures for the management of engineering projects. That's not a put-down: double entry accounting is a social convention (which the soviets rejected) for talking about money, which is another social convention (which the soviets briefly rejected). But accounting is crucially important, just like money. Nevertheless, accounting is no more engineering than is SE.

I think Trent is pretty close to me on this one. I think it was Machiavelli who said 'the man of talent is only appreciated in wartime', and the rest of the time the courtiers fight out palace intrigues. I think that's why so much of our defense and aerospace establishment has decayed. We are like blind cave fish: unless our life or death depends on a capability, it atrophies. The discipline of SE, like operations research, has evolved into a degenerate form that thrives in a bloated, legalistic, peacetime environment. OR in WWII involved both research and operations; these days it has neither. It is all about estimating the performance of systems using computer algorithms. Real operations are not researched, because we do not have a massive war going on. So SE is not alone on its evolutionary path.

If we got into a situation where thousands of our middle and top leaders felt that their personal physical survival depended on getting real physical results (instead of having their budgets depend on winning word games against each other), we'd see a dramatic change. Both the Israeli and Iranian leadership find themselves in that position, and each in their own way is extremely competant and no-nonsense (they play ridiculous politics in other realms), as were even the soviet leaders during WWII. The Israelis are surrounded by foreign foes, while the mullahs are surrounded by domestic foes, but each is under a lot of evolutionary pressure from constant attack.

Unfortunately, I don't see our leaders being really energized in that way unless we have a disaster like half of DC goes up in smoke. I hope for our own sake that that never happens; I also suspect that our opponents (having read the Lind/Hammes paper on 4GW and the Chinese manual on 'Unrestricted Warfare') will keep their assaults safely below the threshold of massive response. That's what the manual says to do, and they sure don't want to experience what the Taliban and Saddam experienced.

I think that both the Chinese (who wrote "Unrestricted Warfare") and Islamists will be clever enough to pursue their goals without massive open confrontation. But the Chinese might choose to make a horrifying example of someone, to deter the US from a direct confrontation. I also think that the Islamists have learned that frontal invasion is no longer necessary to invade the West. It was the only way in the 700's to 1600's, when Christian xenophobia kept them out. But now they can bypass the military conquest and just move in by the millions peacefully, then start the same old process of Islamization that they did in (for example) Iran. Check out their treatment of the Zoroastrians, as documented by Boyce and others. I'm not saying there is a big conspiracy of 'eeevil muslims', but that's the way the unconscious group dynamics have worked out each time in the past.

Actually, this leads to one of my big gripes-as-a-good-citizen. How the heck are FCS, JTRS, and C17 going to help us win 4GW? I think we should have a new thread on that topic. Any starters?

I hear you on SE texts and recursive mgmt, Laocoon.

It's only a start, but I can say from first hand experience that there are some very skilled and experienced people working to restore some neglected disciplines in SE. Some, like my husband, earned their chops in unmanned space systems. Others have .... other experience, some of it quite operational in nature.

I share your sense of urgency on the war front, tho.

Telenko

"The golden age of systems engineering was the 1960s and the space race. The Aerospace industry, where DoD spent most of its procurment bucks, has had the engineers and managers of that generation retire after the 1980's defense build up."

Major issue in my book. Primarily because young blood aren't encouraged to enter the field. Those that do are chastised for not looking at greener pastures and more exotic jobs or looking at history past which is not the chic thing to do. Bottom line the old and new technologies exist side by side each with its own benefits and draw backs. The new technology changes that have been promised / touted are not coming quick enough or fall short of old technology solutions. As a case in point the FAA comes to mind not to mention the IRS, INS, financial and insurance industries that can not rely on newer technology alone. The real horse power is in these industries remain in the mainframes I/O capability, data capacity and data retrieval. Mid-range and open systems can not handle the massive amounts of data or computing power required to process the data. (The Federal Reserve Board and I had lively discussion on this point.) To prove my point take a look at all the gray hair in a multitude of large computer technology industry compared to the hungry eyes of young start ups vying for the same jobs. Take a look at the retirees that have been signed by consulting companies only to return to their current positions under different employ.

Now to the point of the matter which is those who are responsible for bean counters and bean counting care not as much about the technology as they care about the price. Be it manpower or off the shelf products (in a market world). In the government world the majority of this doesn't matter until the public questions the expenditure of the dollar. Then it matters as to who / whom authorized the project, who / whom authorized the expenditure and finally who / whom is responsible for the resulting product. The public wants the same accountability in the government that it expects in a free market.

We can argue all day about whether the technical jock sees the global implications (entire project). This problem in and of itself is nothing more than a communication and expectation issue. One or the other is negligent in coherently explaining the parameters of the project.

Any 12 year old kid who puts a model together has a holistic view of the desired result before they even start the project. Through detail and design the model builder is capable of achieving that goal. It is when the goal is not clearly defined that one realizes the infinite possibilities of producing a washing machine instead of a car given the resources and tools available.

There's another reason that SE skills deteriorated in the 90s. The Clinton Administration saw defense as a place to cut costs and evaluated systems primarily in terms of short-term financial gain.

Result? Lack of skills in some agencies to do sophisticated technical / operational tradeoffs.

You have given me a perspective on the process that I'd been lacking.

By the way, about that Mars polar lander that Robyn mentioned.

But remember that situation a while back where a spacecraft was lost because one team was using meters/centimeters for a calculation and the other team assumed the numbers were inches / feet?

laocoon

The linux guys turned tradition and conventional wisdom on its head, and opened a can of technical engineering whoop ass on the closed shops.

You might Look at Eric Raymonds stuff, for a start.

You echoed a malady i stated earlier, the techies, the nerds, are too removed from deliberation.

Their usual first question is often "OMG, you told them we could do that?, we are doomed."

I imagine you could design a wideband MMIC that could give you a dozen watts out for 250,000 $ each, Perhaps, maybe, barely,, what, now its gotta range above 2 gigs, uhhh our part cant do that, and I donno if we can make a part that can do that .....

Beware those sales sluts, they will promise the moon, tell the customer all is fine untill 2 weeks past deadline, when the only information he has is "we havent yet figured a way to do that"

All the real work is done by a small minority of perhaps 3 nerds anyway, perhaps they should quit their job, go make the widjit, come back and sell it to the company.

hey lefties, this crap is what you want running your life ? ahem.

My, my what a passionate discussion...
I can see that the various disciplines, (be they real engineers or not), have the long knives out and are all so danged frustrated and pissed off with this project &/or at each other that they are blowing it all out their azz-is before they cut throats....
Well, it is a methodology, I suppose....but I AM glad I don't have a cock in the pit....
Now, if someone in the know is in the mood..
Could anyone please tell me where I could find and read the technical problem failure reports and analyzes posted thus far?
Where may I read the project technical forensic engineering analysis test and integration trend reports?
I am not very clever, so I am unclear where to look to find this information and I would really be most grateful for anyone's assistance in finding this information.
Thank-you for your patience and for helping me in this search effort...it is most appreciated.

Raymond,

I just saw a technical article on the radio. It is quite interesting.

They take the I and Q signals run it tthrough a CORDIC filter and some other magic and come out with an amplitude and phase (sorta frequency but not exactly) signal that is predistorted to eliminate IM and then used to AM and PM modulate the RF amplifier.

I have worked out a similar scheme using passive components for SSB.

The RF amplifier can then be class E for really high efficiency.

I'll see if I can dig up the article and leave a reference for those interested in more technical details.

M. Simon
bq. The RF amplifier can then be class E for really high efficiency.

But remember, this is wideband, so the Q of the parasitic parts at the output really sucks.

Yeah, ive run really high currents of really short duration to where a Tube resembled more an SCR than an analog device ... and gotten really high eff close to 90% .. but one thing I had was a really high Q at the output, we are talking 4-O weld lead on a ceramic form for the inductor, and surplus vac caps you would find in a 50kw AM/BC final ... so you could get output power closing on 7kw out of a single 4-1000A. what would normally melt it.

But think about the wideband problem, that means no Q, you have problems running really steep operating angles, because your parasitics wont fill in the rest of the waveform.

Its a problem, and above 200 mhz, your already looking at part structures that just cant give you high peak currents.

Course, the pragmatist would simply break up the bandpass and have several output packages, but combining them is a special issue here, because you cant screw up phase sync.

I donno seems like a tuff nut to me, it might have been better to off the marketing dweeb that got you in the fix.

Small signals ? no problemo ... at power, what was that freq coverage I had to deliver again ?

Hmm Rat poison in his lunch sounds good to me...

I work in commercial/military aerospace.

The big deal these days (an effort I helped pioneer by reducing the cost 10X and the time 5X) is in the loop testing using a simulated aircraft. This gets out the ambiguities in the specs and qualifies beginning hardware.

Now this is basic functional testing not margins testing which needs to be more sophisticated. Thing is it can be done cheap and quick so the tester is available for first hardware (usually the test guys get about 3 months to do the job - very rushed for aerospace considering the hardware and software requirements). I figured out a process that got the hardware done in under two months leaving one month for the software guys to test. I was planning to do the software too in the beginning, but there is only so much time.

Now the first one of these I built was used for development of a mil aircraft. And there was no war on at the time. Just an impossible schedule to meet.

We are getting better in some parts of the systems engineering field. I did have the advantage of working for some very smart managers who figured out how to get the best out of me.

As any one in the field knows the test equipment is always at the tail end of the whip. The black box guys use up all their alloted time, the project margin, and some extra. However, test eqpt. is blamed, always, for project time slips. So my bosses had an incentive to give me a free hand. They were desperate to avoid being the goats.

In any case - there are places where systems engineers are doing it right.

Test early and test often.

Raymond,

You are right about Class E.

I was just reading the article yesterday and now I can't find it. Darn.

The article had some scope phase traces that looked good. The amplitude did not look as good but they claimed it was linearized by feedback.

Yeah, a pretty tough problem.

Still they are doing some pretty amazing stuff with RF these days.

If I find the article I'll post magazine and page. Plus url if I can find it.

Let me try to pull some of these great comments together. First, from the article AnotherAnon pointed to (re: the NASA failure):

Even at that time, NASA managers hinted that much more had gone wrong. "People sometimes make errors," said Edward Weiler, NASA associate administrator for space science. "The problem here was not the error; it was the failure of NASA's systems engineering, and the checks and balances in our processes, to detect the error. That's why we lost the spacecraft."

In an internal memo dated 18 October, not intended for non-JPL readers, a laboratory official summarized the way thinking was developing: "There might have been some overconfidence, inadequate robustness in our processes, designs, or operations, inadequate modeling and simulation of the operations, and failure to heed early warnings." No, it was not a simple mistake at all, as NASA finally explained in detail on 10 November.

And then from M. Simon's comment #18:

The big deal these days (an effort I helped pioneer by reducing the cost 10X and the time 5X) is in the loop testing using a simulated aircraft. This gets out the ambiguities in the specs and qualifies beginning hardware.

Now this is basic functional testing not margins testing which needs to be more sophisticated. .... Test early and test often.

I would add: analyze early and often, as well.

JTRS, spacecraft .. these are complex systems which can (and should be) be analyzed at different levels of requirements, functionality and performance responses, as M. Simon points out.

There are other kinds of systems as well. A base camp for the Army is a complex system. Designing it, flowing materials, equipment and personnel to a new base camp in the right order and with the right timing, is a systems engineering problem.

The Army as an organization is a complex system. Identifying the right organizational structure for the Army in the face of new missions and challenges is a systems engineering problem.

The Bradley and the Stryker vehicles are systems. Choosing the right weapon for upgrading the on-vehicle gun on the Bradley is a systems engineering problem.

Specifying and integrating dozens of new technologies into a whole-soldier system for Objective Force - think nanotech body armor with biometric scanning that will not only identify if the soldier is wounded, it will apply selective pressure to control bleeding until the medics come, plus smart weapons and full access to sensor and intel data through a heads up display - that's a systems engineering problem too.

My colleagues have worked and are working every one of those issues. And a central tool and technique they use is modeling and simulation. Which is why, for instance, the US Military Academy has a systems engineering major that includes both combat simulation courses and also a very sophisticated modeling and simulation lab for acquisition management courses.

Raymond's point about Linux is well taken. One could argue that they are doing what-SE-intends in a distributed, fluid, and somewhat less hierarchical system, while not using the SE procedures. There are versions of unit testing, integration testing, regression testing, and so on - but my hard-core SE buddies would reject the whole OS bazaar out of hand, starting with "it's just too chaotic". That's part of why I'm so convinced 'SE is a set of US government-recommended practices for the management of engineering projects', but is not itself engineering.

The US Govt recommends one set. The Soviets had a second set of recommended procedures for doing what-SE-intends (though I've not been able to get definitive documentation; any suppliers listening?); the open source community has a third way to doing what-SE-intends. But for each field of real engineering, there's really only one way to do it. For two examples, the Ricatti equation is the same in Chinese as English, and the US weapon inspectors analyzed Iraqi's arabic-language WMD notes by just reading the equations. (BTW, I know the OS process well. You can look up a few of my open source projects on sourceforge, though not under 'laocoon'. And we all know the FSF work of my classmate, Richard Stallman.)

BTW, please don't whack those 'sales sluts' too hard. Some are just irritating people, true, but a lot are good folks who are painfully aware of being caught up in a game that requires competitive lying.

I think the perspectives on why the practice of SE has degenerated is very good. I think that Trent, Simon and AnotherAnon provide good pointers on how, when, and why the evolutionary pressure was taken off, which let evolution take off on a different path.

It's not really fair to say that (e.g.) Operations Research has 'degenerated'. Cave fish did not just lose their eyes; they developed new behaviors and metabolic tricks. Like cave fish, OR has evolved in the new environment, which consists of doing computer analysis to win congressional budget battles over funding of systems. Each word of that is carefully chosen. For example, some kinds of perfectly valid analysis are never undertaken, because Congress has decided that decisions will be made on the basis of legally mandated metrics. Hence, the models provide those metrics - and not others. Realistic processes that actually do occur are not modeled, and no research is funded on how to model them, because those processes are not part of the pseudo-economic cost-benefit paradigm used to justify the congressional metrics. In short, making the models more realistic would make the data less usable in Congress. This outline of an argument could be greatly elaborated by naming committees, budget documents, and so on, but that would be tedious.

For another, Congressional budget battles are a rather unique enivronment. It is adversarial, and the people involved are buracratized lawyers. Hence, the procedures have evolved to produce results that can stand up in that environment. Often, everyone knows that the best way to get an answer is to just ask some grunt who has actually 'seen the elephant' - but that would not stand up in committee. So we do hugely over-documented studies (if you can't dazzle 'em with brilliance, baffle 'em with bull****) that (sometimes) eventually just reproduce what the grunt said. And even when they don't, we just say "that's the best we've got" and go forward. But it's only 'best' in the sense of being able to win the budget battle in committee; 'best' in the sense of accuracy is what the grunt said. But if we tried to use the most accurate data (grunt talk) rather than the most defensible data (computer output), then we'd get shot down and something really random would get done. Given the environment, it is the most ethical thing to do, with the tax payers' money and our soldiers' lives, to go forward into a winnable fight with a defensible 70% answer than to go forward into a sure-loss with an 80% answer. Does anyone have a better, practicable solution?

To follow up on Robin's point, the current 'we are at war' mindset is pretty shallow. It's as far from real wartime mindset as the TSA airport farce is from real security. TSA is doing what Bruce Scheier calls 'security theater': an act designed to create the illusion of security in the minds of those who willingly suspend disbelief. If you can ignore the fact that they are just crowds of actors strutting around in makeup, the Wagner operas can be pretty compelling. But if you pay attention to reality (or a real warrior comes onto stage with real killing), then the theater is revealed as ludicrous play-acting (yes, I know that's redundant, latin scholars).

What's missing from our OR, SE, and war planning is the kind of "utter honesty" that Feynman referred to in his essay on Cargo Cult Science
I think that what Robin is describing is the real SE, like the real science Feynman describes, and what I'm bemoaning is cargo cult system engineering, cargo cult security, and so on.

I've know some Wall Street quants, and they do have that utter honesty about their work. Their work is ruthlessly tested every day, and their personal welfare is directly affected by the results. Again, unstoppably, evolution happens.

I'm happy with bazaars and open source for many kinds of software.

But if my team is designing and building the flight control system for a fighter aircraft - something that lives depend on - you better damn well believe we are going to use a top-down, heavily structured process and validate and verify the hell out of it!

What laocoon is pointing to is real, though. Those processes can become a cargo cult - which is what you do when you don't have knowledge but want to mimic what worked for powerful and prestigious programs.

The key is to scale down processes to fit the situation. That's what I did in industry for things that weren't mission critical -- used the key concepts from more structured processes, applied them informally and with input from everyone on our small team, and beat out Siemens and Rockwell in their own marketplace.

But not for the mission-critical, human-lives stuff.

Robin

But if my team is designing and building the flight control system for a fighter aircraft

But will your testing find whats wrong with that little amp running open loop gain ?

There are more lessons than those showing up front.

Lots of the linux coders are leftists, holding up the community project as proof that a form of leftism might possibly work.

But its just the opposite, the people coding are self selecting, they had no burocrat that assigned them the job, the code had to survive/compete in a market based on peer review and merit. all those things that determine the winner in the free market, both of products and ideas, esp in linux where the two become one and the same.

Structure is no subsitute for talent, (another reason leftism dont work)

Creation is an art form, engineering is merely application.

The angle im coming at this is I see the enviroment as stiffling, suffocating. all the things that condemn leftism.

So to a large extent, while accepting that this is the system we have, it seems to suffer from leftist-flavored poison.

How could we fix this problem, where are the nerds, the pilots with air combat hours? those that would know when the faint scent of cooking epoxy is bad?

The math tells you a heatsink thats too big is just as wrong as one thats too small. those that mount their own parts to sinks knows that isnt true.

it wasnt just the openness that gave me a system that has not crashed since may 1995, but the fact that its designers had authority over their own work. (condemns leftism again, heh this is fun)

That amp I built in my youth belongs to someone else now, but it is still working.

In every case of human advancement, you will find this critical ingredient of success, and in every case of failure that generates more finger pointing than knowlege advancement, you can usually trace back to the opposite.

I Had an engineer friend who worked for boeing, like me, he had a childhood of building his own stuff. compared to his peers, this made him an apparent uber god and he found himself working in the circut sneeker group looking for engineering faults.

The first few shuttle landings,, did you know they kept the nose wheel locked and steered with the brakes ?

In the nose wheel servo. some a-hole had left a 741 running open loop gain, it could occilate, and the nosewheel would steer hard over.

Yeah its fixed now, but testing couldnt find it.

You actually have to build real things with 741s to know that its mfr specs cant really be trusted, and that open loop gain on that part is wrong.

So the Shuttle got its steering back after the addition of a small resistor and cap that are bought by the pound and no longer steer with the brakes.

If the nerds had been left in charge we would not have lost our two shuttles, they knew about the joint sealant change due to envirowacko clintonistas put in authority at NASA, they knew about the new stuff and the cold, they knew about the envirowacko change to the tank foam, they screamed about the tile damage that suddenly appeared after the foam change.

But like the loss of the mars probes, nobody listened to the nerds.

There is a reason talent chose those materials, that the talent-less clintonistas changed that destroyed the shuttles.

And Gavin needs to be given the boot to his ass, such Leftist-flavored Elitist attitude that does not have his ear acuetly tuned to the vibrations emenating from the talent working under him has no place in that job.

Put the nerds back in charge. have em talk directly with the end users, give them control of the big Red buttons.

America outperforms the rest of the world for a Reason, there are lessons there, if you are not blinded by a leftist mental disorder so that you cant see it.

Raymond, you certainly are persistent in applying your political philosophy to life .... ;-)

I'm wondering if you have actually worked in formal validation and verification environment on mission-critical systems. No shame in not having done so - but your comment suggests you're not familiar with, e.g., the important role that peer review plays in the process. In fact, good processes work precisely because the DO involve the "nerds" in looking for what might go wrong before it does.

You actually have to build real things with 741s to know that its mfr specs cant really be trusted

As an old software type, I long ago learned not to trust h/w specs LOL.

Raymond, you certainly are persistent in applying your political philosophy to life .... ;-)

Im doing more than that, im hinting that there is an inherent dysfuction in the leftist brain that expresses itself in non-political activities.

I saying i could make a scientific demonstration of that, that it is repeatble, with predictatble results.

And when you are modeling the human creature, thats saying a lot, as I should not have to tell you.

There is a reason billions of dollars was spent on a utopian system kernel, an idea of the utopian thinkers of the 60s.

Perhaps I should point you to Linus Torvalds views on the microkernel, as applied to the context of the times. much of the debate is preserved in usenet posts, and we have Linus's latter commentary on the issue. and its just such a wonderfull example of what im talking about.

Your worldview affects how you look at things, how you come at problems, how you react to stimuli.

Its part of a "total person" type concept.

You can learn how the entire universe works by using electrons as playthings, but some cant learn as much due to politcal baggage.

You think thats strange ? Guess what, reality can be strange, those that dont know that dont yet have the slightest grasp of reality.

Which of course is what makes some segments of the left amusing, and pathetic at the same time, can you think of an entire swath of them that have as a pillar of their religion the out right rejection of reality, Objective truth et al?

So, does your politics, the way your brain works
(which is the cause, and which, is the effect? hmm?)
have effects in areas where one might think it should not factor ?

Im saying it does, and the effects can be profound.

Your sex does too ! but thats,, well,,, almost,, a different discussion.

Robin Burk - I hinted at some of this to you before. Systems Engineering is further down the waterfall then you think.

Start with the USSR's dream - TRIZ - to discover what you really want and really need to do - even at the government level and refine the TRIZ solution.

Take the TRIZ model and approach the companies. They can apply Systems Engineering to that and make it work. But, a few back and forths on the TRIZ model is good to do before sealing that contract.

Don't forget the simplest thing TRIZ ever showed the Russians.. A light bulb on their lunar lander just needed a filiment not a glass bulb. Saved them inventing a shock-resistant glass enclosure just a cheap wire in a clamp - instant flood. (vacuum in space so its done..)

3dc is referring to a paradigm for problem solving .... you can find some articles about it here. This one is particularly apropos to engineering.

3dc, I'm admittedly new to TRIZ. But it strikes me - a veteran of 4 generations of software analysis and design techniques - as a variant on the state transition models that software engineers have used for some time (especially for real-time control systems). It also looks similar to systems dynamics modeling, with its stocks and flows.

I'm not sure I see the conflict between this and systems engineering, even at the earlier stages of a project. My students learn to do functional decomposition and functional flow analysis without reference to the specific technical design that will be used to implement the system. Perhaps what TRIZ does is push that down to the detailed design level, which by definition requires the involvement of the specific discipline engineers?

There's an earlier step yet which is even more important, and that is to decide what your requirements are -- and specifically what tradeoffs you are willing to make. Multiple objective decision analysis, a technique that my students also learn and which has been applied to some very complex, mission-critical systems, gets at the specific priorities and tradeoffs among objectives for the system.

Equally important, it nails down measures of evaluation -- how, specifically, will we MEASURE the performance of proposed alternatives with regard to each objective?

Once you've decided that, you can prototype or simulate to get expected performance of alternative architectures/designs for each objective. Weight those by the priority for the objective, sum them up, and you get a total value score for each alternative course of action / design. Now you can also do cost/benefit analysis.

And ... do sensitivity analysis to see how much, if at all, any inaccuracies or subjectivity matters to your choice.

I'll need to read more about TRIZ to comment further.

Reading of functional decompositions and all this methodology reminds me of a computer science class I once took. We had a programming project and had to go through the whole process of entity relationship diagrams, flow charts etc. etc. I think it was a useful process to go through once or twice.

After that I found that the perspectives I gained were automatically integrated into my thinking and explicitly going through the methodology just slowed me down (a lot). I've written software used by many people, computational fluids codes, software to control complex experiments, but I can honestly say that for me the most important thing is to have been through the methodology once or twice and to have a feel for the overall problem and what you are trying to achieve. It used to be that you needed a clearer idea of exactly how you would go about things before even starting, but with the advent of object oriented programming (which is also just a state of mind) you can write useful code and to some extent work out the overarching structure of the program as you go along, sort of a combination of top down and bottom up.

For complex designs I understand that you need more than one person, and that design teams have to be more explicit and documented so there are no misunderstandings between members. I just wanted to add something about the human side of all this because it hasn't been discussed much: Humans are just glorified apes and the majority of what we learn and respond to is embedded in our social context - things like chatting in the corridor and just generally being around your coworkers. In fact it's our optimal mode of learning.

When you're designing something new a lot of good quality communication is needed, and social context is a critical ingredient of that communication. If engineer A is talking with engineer B in some other organization, the language is different has different meanings, the culture is different, the implicit design values people hold are different, and you can have two people hold a perfectly rational conversation and both walk away thinking they understand each other when in fact they don't.

OK, so why do we care? When you have a team of people working together on a design, paperwork quenches the whole process and breaks down effective face-to-face communication, sending people scurrying back to their offices. At Caltech we practice a form of concurrent engineering for conceptual design in which teams all work on a very focused design activity in the same room for a few hours every few days, with intervening time used for individual preparation. It's very important to have people spend time together in the same room and for all of them to have a sense of the overall design.

If you structure the group design process right, it throws up questions that then become impromptu conversations between different members of the team. Design responsibilities are 'auctioned' and so the design problem decomposes according to who is most able to solve each subproblem. Groups of closely coupled problems condense into 'subsystems' (e.g. structures, propulsion, avionics) and the flow of data between different disciplines and subsystems emerges as each conversation creates a new link. Very often someone will need the result of a calculation that has already been implemented by someone else, but because everybody's in the same room it's easier to ask before embarking on something involved - the barrier to communication is much lower. The whole process condenses weeks or months of relatively solitary work mediated by wasteful meetings into something closer to the essence of design. Or in other words it's more of critical mass event.

Anyway, it's an approach that JPL and Caltech use and industry is starting to take on. I think it has merit, at least for conceptual design, but from my conceptual design perspective this mode of operation is an ideal that should translate to other areas. Fluctuating specifications and expensive design problems later on mostly originate from a lack of earlier communication. So with that in mind surely it's better to integrate the elements of a mindset that are useful into to the group design methodology, and to discard the kind of explicit and formal procedure that can be useful the first couple of times but thereafter impedes good communication.

P.S. I realize that the stuff you guys do has to be different in many ways. I just wonder if something of this approach couldn't help?

This discussion about SE and design processes is all fine and good, but I think that they are all beside the point re:JTRS. What good SE or design process is effective when the requirements keep changing ?

Consider:

- JTRS is a "Joint" program, and as such, that accepted idiot requirements from all over the DoD planet. Many of these joint requirements were levied by services that later abandoned Cluster 1 to start their own service-specific cluster.

- Was required to run 30+ legacy "waveforms" (and counting) without any analysis as to what operational scenarios supported them, or any analysis of what waveforms could be 'migrated' to a 'modern' waveform.

- Had numerous requirements levied on it by OSD NII as the communications and networking "catch basin" to solve joint interoperability problems -AFTER the radio had passed Critical Design Review. Joe has it exactly right in the article about CYA bureaucrats.

- Got screwed in that NSA reneged on agreements about basic hardware and software implementations AFTER pre-EDM's were delivered (despite funding a dozen NSA 'experts for 4 years), such that they had to go back to the ASIC drawing board.

Also, I think that it is important to point out that Boeing's approach in Cluster 1 is more as a "integrator", as they do not 'manufacture' radios. If this is any indication of how well Boeing integrates, FCS is doomed.