asymetric warfare

On Thu, 18 Dec 2003 18:22:34 GMT, Kevin Brooks wrote:

I think that Phil is probably talking about weapons like the IAI Harpy. It
is a relatively inexpensive "CM" used in SEAD operations. The only
significant technology employed by this vehicle is in the sensor (and even
there, a "middle-ranking country" should not have a problem developing or
procuring).

The question really is if it is possible to integrate different sensors
(TV,
IR) on such vehicles, if you can accurately identify targets (based on
some
signature characteristics or library), and how effective it could be (at
not
killing your own or being easily defeated by the enemy).

And those questions are the kind that even the US, with its multi-billion
dollar R&D structure, is tangling with--do you really see some second/third
world potential foe solving that dilemma over the posited period of the next
ten years? I don't.

The problems listed above are information-processing problems, that
is, software problems. Does it really require billions of dollars to
solve these problems? I say no: a few small groups of really
competent programms can be many times more productive than how
software is traditionally written. I've worked as a programmer for
defense contractors (and for other large organisations), and believe
me, there is a *lot* of waste and inefficiency. If the software was
written right, it could probably be done with several orders of
magnitude more efficiency.

Those home on active emitters, keeping their last transmitting location in
their memory in case they drop off the air. That is a big difference from
going after targets that are purely passive and are not radiating (or not
radiating anything you can actually read with a system that could be placed
in such a small weapon--detecting the frequency agile signals from vehicle
FM radios is not going to work).

Most ground vehicles radiate visible lightr, at least during
daytime. At light they radiate IR, which can bre picked up with
similar sensors.

I disagree. On the one hand you are going to have to use a pretty complex CM
of sorts, as we have already seen from the discussion to this point, if you
are going to engage previously unlocated targets, so the idea that these
things will be cheaply turned out in some converted auto garage is not going
to cut it.

Wrong. The complexity is in the *software*. CM hardware can be --
and historically has been -- put together by unskilled slave labour
in squalid conditions.

They will also be expensive--the R&D effort is still required,

Yes. But once software has been written once (and we're talking
millions not billions of dollars) it can be duplicated at zero cost.

since what has been postulated is essentially an autonomous attack system
that does not currently exist even in the US. Third, the number of Patiots
that can be made available is not a trivial number--count the number of
missiles available in the uploaded canisters of a single battery, not to
mention the reminder of its ABL that is accompanying them.

Do you have actual numbers here?

Finally, we have
a rather substantial stock of Stingers, including ones mounted on Avengers
and BFV-Stinger, along with the regular MANPADS.

It would be quite easy for an attack by lots of cruise missiles to
overload the defences at a point.

--
"It's easier to find people online who openly support the KKK than
people who openly support the RIAA" -- comment on Wikipedia
(Email: , but first subtract 275 and reverse
the last two letters).

"phil hunt" wrote in message
. ..
On Thu, 18 Dec 2003 18:22:34 GMT, Kevin Brooks
wrote:

snip

since what has been postulated is essentially an autonomous attack system
that does not currently exist even in the US. Third, the number of
Patiots
that can be made available is not a trivial number--count the number of
missiles available in the uploaded canisters of a single battery, not to
mention the reminder of its ABL that is accompanying them.

Do you have actual numbers here?

Six firing batteries per Patriot battalion, with eight launchers per
battery, equals 48 launchers per battalion. Each launcher has 4 rounds
onboard, so you are talking 192 missiles loaded out and ready to fire--not
sure what the ABL is, but safely assume at least two rounds per tube in the
battery/BN trains structure, so we are looking at what, another 384 rounds
readily available? So total Pats equals about 576 rounds for a single
battalion? Then you have the Avengers, with 36 Avengers in each corps level
ADA Avenger battalion, each with 8 tubes uploaded, so just taking into
account their initial upload you are talking 288 missiles without bothering
to consider their ABL in the trains. But that's not all, folks--each
division has its own ADA battalion, with another 24 Avengers, 24 BSF-V's,
and 40 MANPADS (or a heavy division), so again minus the ammo in the trains,
you have another 328 Stingers there. So your nominal corps force is going to
have somewhere in the neighborhood of beween 576 and 1,100 Patriots covering
it, another thousand plus Stingers (conservative estimate). Are you
beginning to understand why trying to out-tech the US is an unwise move if
you are really interested in asymetric warfare?

Brooks

ess (phil hunt) wrote:
The problems listed above are information-processing problems, that
is, software problems. Does it really require billions of dollars to
solve these problems? I say no: a few small groups of really
competent programms can be many times more productive than how
software is traditionally written.

The issue isn't programmers Phil. The issue the massive amounts of
R&D to develop the information needed to specify the sensor that the
programmers will process the output of. The issue is the massive
amount of R&D needed to develop the algorithms the programmers will
implement to analyze the output of the sensor. The issue is the
thousands of hours of R&D needed to develop the database that the
software will use to compare the output of the sensor with...

Writing the software is but one small piece (howsoever important) of a
much larger and more complex effort.

I've worked as a programmer for defense contractors (and for other large
organisations), and believe me, there is a *lot* of waste and inefficiency.
if the software was written right, it could probably be done with several orders
of magnitude more efficiency.

You could have the tightest, fastest, most efficient analysis code in
the world... But it's all meaningless without the other things that go
into making a targeting system. What you have is the typical myopia
of the programmer.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

On Thu, 18 Dec 2003 22:17:34 GMT, Derek Lyons wrote:
(phil hunt) wrote:
The problems listed above are information-processing problems, that
is, software problems. Does it really require billions of dollars to
solve these problems? I say no: a few small groups of really
competent programms can be many times more productive than how
software is traditionally written.

The issue isn't programmers Phil. The issue the massive amounts of
R&D to develop the information needed to specify the sensor that the
programmers will process the output of.

The sensors needed are visual and IR imaging. It doesn't require a
massive R&D program to determine that, or to decide which
combinations of number of pixels and widths of field of view are
appropriate.

The issue is the massive
amount of R&D needed to develop the algorithms the programmers will
implement to analyze the output of the sensor.

Do you know anything about programming? If you did, you'd know that
developing algorithms is what programmers do.


--
"It's easier to find people online who openly support the KKK than
people who openly support the RIAA" -- comment on Wikipedia
(Email: , but first subtract 275 and reverse
the last two letters).

ess (phil hunt) wrote:

On Thu, 18 Dec 2003 22:17:34 GMT, Derek Lyons wrote:
(phil hunt) wrote:
The problems listed above are information-processing problems, that
is, software problems. Does it really require billions of dollars to
solve these problems? I say no: a few small groups of really
competent programms can be many times more productive than how
software is traditionally written.

The issue isn't programmers Phil. The issue the massive amounts of
R&D to develop the information needed to specify the sensor that the
programmers will process the output of.

The sensors needed are visual and IR imaging. It doesn't require a
massive R&D program to determine that, or to decide which
combinations of number of pixels and widths of field of view are
appropriate.

Ah, another problem handwaved away. You not only lack a clue, you are
aggressive in avoiding obtaining one.

The issue is the massive
amount of R&D needed to develop the algorithms the programmers will
implement to analyze the output of the sensor.

Do you know anything about programming? If you did, you'd know that
developing algorithms is what programmers do.

Do *you* know anything about programming? If you did, you'd know that
developing the algorithm and implementing the same are two different,
howsoever intertwined, processes.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

Derek Lyons wrote:
(phil hunt) wrote:
[...]
The issue isn't programmers Phil. The issue the massive amounts of
R&D to develop the information needed to specify the sensor that the
programmers will process the output of.

The sensors needed are visual and IR imaging. It doesn't require a
massive R&D program to determine that, or to decide which
combinations of number of pixels and widths of field of view are
appropriate.

Ah, another problem handwaved away. You not only lack a clue, you are
aggressive in avoiding obtaining one.

Hmm.

I've done several iterations of this problem,
though not with systems that went to full scale
development or production.

I believe that for suitably moderated operational
requirements, the problem can be much simpler than I
believe Derek thinks it is.

I belive that Phil is grossly underestimating the
real requirements, even for those suitably moderated
operational requirements.

There is a fair amount of open source material on
various small guided weapon R&D and proposals.
Unless those were all wrong, it can be a lot simpler
than current 'standard' weapons programs.

But few of those have progressed to production.
The new Marines/Navy Spike missile is one
exception, and to some degree is the exception
that probably proves the rule. Their R&D budget
essentially was hidden in the slush funds at China Lake
for a couple of years, and the missile itself is estimated
to cost at most a few thousand dollars.


-george william herbert

On 20 Dec 2003 14:25:46 -0800, George William Herbert wrote:
Derek Lyons wrote:
(phil hunt) wrote:
[...]
The issue isn't programmers Phil. The issue the massive amounts of
R&D to develop the information needed to specify the sensor that the
programmers will process the output of.

The sensors needed are visual and IR imaging. It doesn't require a
massive R&D program to determine that, or to decide which
combinations of number of pixels and widths of field of view are
appropriate.

Ah, another problem handwaved away. You not only lack a clue, you are
aggressive in avoiding obtaining one.

I've done several iterations of this problem,
though not with systems that went to full scale
development or production.

I believe that for suitably moderated operational
requirements, the problem can be much simpler than I
believe Derek thinks it is.

I belive that Phil is grossly underestimating the
real requirements, even for those suitably moderated
operational requirements.

Which requirements am I underestimating? (Bear in mind I'm
considering missiles for several different roles).

But few of those have progressed to production.
The new Marines/Navy Spike missile is one
exception,

This is the Israeli ATGM, isn't it?

and to some degree is the exception
that probably proves the rule. Their R&D budget
essentially was hidden in the slush funds at China Lake
for a couple of years, and the missile itself is estimated
to cost at most a few thousand dollars.

And uses visual and IIR homing.

--
"It's easier to find people online who openly support the KKK than
people who openly support the RIAA" -- comment on Wikipedia
(Email: , but first subtract 275 and reverse
the last two letters).

phil hunt wrote:
George William Herbert wrote:
I've done several iterations of this problem,
though not with systems that went to full scale
development or production.

I believe that for suitably moderated operational
requirements, the problem can be much simpler than I
believe Derek thinks it is.

I belive that Phil is grossly underestimating the
real requirements, even for those suitably moderated
operational requirements.

Which requirements am I underestimating? (Bear in mind I'm
considering missiles for several different roles).

Let me give you an example... assume that you need a certain
pixel width of an object to successfully identify it
(say, 10 pixels across) with a certain contrast ratio.

You also have certain limitations on the maneuverability
of the airframe this is all one. It can't pull more than
a certain number of G's etc.

To successfully design the homing mechanism, you need to
assess the distance and light or background noise conditions
of the frequencies you're looking at (visual, IIR, whatever)
and the magnification of the imaging system and its optical
resolution. You need to have a wide enough field of view that
you can see the targets as you fly along searching, but not
so wide that you won't be able to discriminate a target
until it's so close that maneuvering to hit it becomes
a serious problem. You need to assess the impact on
the sensor and field of view of the background coloration
across the target areas, etc.

With a much simpler system, laser spot homing, I spent
some months working out that nested set of problems.
Taking one shortcut made the weapon not lock on if
the ballistic miss trajectory was too far off.
Taking another meant that it typically locked
on early in a portion of its flight that led to
it flying out of control as it lost energy trying
to track the laser spot as it flew out. It would
scrub too much forwards velocity off early and then
start to come down too short of the target and stall
out trying to correct for that. Bigger lifting
surfaces would solve that but cause other problems
for weapon packaging. The final solution was to
modify the trajectory limitations, with the more
aggressive sensor system. Which scrubbed a bit off
the maximum range (could still reach the old range,
but if your aim was off too much in the initial
firing it would just out and out miss short).

You actually have to sit down, design a notional design,
put a notional sensor on it, figure out what the
parameters are, and simulate it for a while to see
what the gotchas are. That requires models of the
sensor, guidance, optics or transmitter, target
behaviour, aerodynamics, and trajectory / movement
dynamics of the weapon.

Even getting a rough first pass of that to tell you
what the roughly right answers are is nontrivial,
can easily be months of work, and requires experience
across a very wide range of diciplines (or a keen
ability to figure out what you don't know and find
it via research).

But few of those have progressed to production.
The new Marines/Navy Spike missile is one
exception,

This is the Israeli ATGM, isn't it?

No, there are two missiles named Spike,
and I'm referring to the US Navy / China Lake one.
http://www.nawcwpns.navy.mil/~pao/pg...es/SpikeND.htm


-george william herbert

On Sat, 20 Dec 2003 21:45:56 GMT, Derek Lyons wrote:
(phil hunt) wrote:
The issue is the massive
amount of R&D needed to develop the algorithms the programmers will
implement to analyze the output of the sensor.

Do you know anything about programming? If you did, you'd know that
developing algorithms is what programmers do.

Do *you* know anything about programming?

I've already told you, it's my profession. Now, are you going to
anwser my question: have you every done any programming, and if so,
how much and in what languages?

Failure to answer will be considered as evidence of trolldom.

--
"It's easier to find people online who openly support the KKK than
people who openly support the RIAA" -- comment on Wikipedia
(Email: , but first subtract 275 and reverse
the last two letters).

ess (phil hunt) wrote:

:On Sat, 20 Dec 2003 21:45:56 GMT, Derek Lyons wrote:
(phil hunt) wrote:
:The issue is the massive
:amount of R&D needed to develop the algorithms the programmers will
:implement to analyze the output of the sensor.
:
:Do you know anything about programming? If you did, you'd know that
:developing algorithms is what programmers do.
:
:Do *you* know anything about programming?
:
:I've already told you, it's my profession. Now, are you going to
:anwser my question: have you every done any programming, and if so,
:how much and in what languages?

That you ask "in what languages" indeed indicates that you are a
PROGRAMMER (rather than, say, a software or systems engineer) and, as
such, have very little clue about what is being discussed here.
Computer languages are like candy; when you need another one, you just
pluck it out of the bowl and eat it.

How much? I stopped counting a long, long time ago. The system I'm
about to field is something like a quarter of a million lines of code
(yes, I had help) on a Windows box. Also done work on VMS and various
forms of Unix, as well as assorted micro-clones (like OS9) and
embedded stuff. Languages range from assembly through Fortran
(various flavours), Pascal, Ada, C, C++, Visual C++ (which is sort of
like C++, but larded with megaliths of Microsoft Magic Crap), Java.
I've done 'toys' (where 'toy' is a systems smaller than, say, 50k
SLOC) in LISP, Scheme, SNOBOL IV, FORTH, BASIC, Visual Basic (see
Visual C++, above, for relationship to BASIC), Python, Perl. I'm sure
I'm leaving a bunch out that aren't springing to mind right away.

:Failure to answer will be considered as evidence of trolldom.

So, if he fails to answer, you're a troll?

Of course, if he does answer, then I guess that leaves you as merely a
fool.

--
"Some people get lost in thought because it's such unfamiliar
territory."
--G. Behn