New Handbook explains "Network Enabled Capability"
Join Date: Jan 2005
Location: Racedo blows goats
Posts: 677
Likes: 0
Received 0 Likes
on
0 Posts
Tcu
Agree with most of what you say. I have sat on both sides, equipment and platform and have some sympathies with both parties.
Systems integration is always a difficult problem but to move towards NEC is far more difficult because you are trying to achieve a systems of systems integration. The equipment IPT now not only has to look inwards towards the platform but also outwards to where his system boundaries meet with other systems. eg BOWMAN - Falcon - Skynet - DDNS all have translation issues that have to be managed. Throw in JTIDS and Land/Maritime recognised pictures into the picture, fusion and latency of data also become massive issues.
TCP/IP was mentioned, this does lead to commonality but you do not get guaranteed quality of service. Think internet, is it always there when you want, do allof your e-mails get through. Unfortunatley, not all systems are running TCP/IP, not all are cleared for the same security level of traffic.
There will be many tears before bedtime before NEC even starts to join systems together.
Agree with most of what you say. I have sat on both sides, equipment and platform and have some sympathies with both parties.
Systems integration is always a difficult problem but to move towards NEC is far more difficult because you are trying to achieve a systems of systems integration. The equipment IPT now not only has to look inwards towards the platform but also outwards to where his system boundaries meet with other systems. eg BOWMAN - Falcon - Skynet - DDNS all have translation issues that have to be managed. Throw in JTIDS and Land/Maritime recognised pictures into the picture, fusion and latency of data also become massive issues.
TCP/IP was mentioned, this does lead to commonality but you do not get guaranteed quality of service. Think internet, is it always there when you want, do allof your e-mails get through. Unfortunatley, not all systems are running TCP/IP, not all are cleared for the same security level of traffic.
There will be many tears before bedtime before NEC even starts to join systems together.
I don't own this space under my name. I should have leased it while I still could
Engineer(Retard),
I am not carping as your post is actually readable and understandable even though it is acronym rich. The danger comes when the person writing is not as well versed with the TLA and jargon writing to someone who is completely in the dark.
To read some drivel I get where you keep having to go back to para one to refresh what BSA or NEC or any of the other CR*P means totally destroys the intent - COMMUNICATIONS.
As I said, nothing wrong with your post, the problem lies higher up the food chain.
I am not carping as your post is actually readable and understandable even though it is acronym rich. The danger comes when the person writing is not as well versed with the TLA and jargon writing to someone who is completely in the dark.
To read some drivel I get where you keep having to go back to para one to refresh what BSA or NEC or any of the other CR*P means totally destroys the intent - COMMUNICATIONS.
As I said, nothing wrong with your post, the problem lies higher up the food chain.
Short Blunt Shock
Join Date: Jul 2003
Location: UK
Posts: 631
Likes: 0
Received 0 Likes
on
0 Posts
Tucumseh,
Thaks for explaining some of the difficulties involved - these things are not always (rarely, in fact) visible to end-users like myself. However, I would like to echo part of PN's post above - few of us outside the world of procurement / engineering / IPTs etc understand a word that is being said. To simplify - THERE IS NO POINT IN 'ENABLING' MASS COMMUNICATION IF NOBODY UNDERSTANDS WHAT IS BEING SAID.
Please cut out the corporate speak and w@nk-words. We, the end-users of your many efforts, really need to know 3 things:
1) Exactly what the f**k this is.
2) Exactly what it does.
3) How to use it to enhance our operational capability.
What this appears to be, at present, IMHO, is the usual obfuscation, with unfamiliar language, of a philosophy we have already followed for the last 20 years and have, at least in part, implemented. It is being presented, however, as something 'brand new' for which we need to make sacrifices in other areas of defence spending.
In other words, a pile of tech-speak bulls**t being used to hide a poor exuse for cuts to the budget. A well-known hallmark of this Govt.
16B
Thaks for explaining some of the difficulties involved - these things are not always (rarely, in fact) visible to end-users like myself. However, I would like to echo part of PN's post above - few of us outside the world of procurement / engineering / IPTs etc understand a word that is being said. To simplify - THERE IS NO POINT IN 'ENABLING' MASS COMMUNICATION IF NOBODY UNDERSTANDS WHAT IS BEING SAID.
Please cut out the corporate speak and w@nk-words. We, the end-users of your many efforts, really need to know 3 things:
1) Exactly what the f**k this is.
2) Exactly what it does.
3) How to use it to enhance our operational capability.
What this appears to be, at present, IMHO, is the usual obfuscation, with unfamiliar language, of a philosophy we have already followed for the last 20 years and have, at least in part, implemented. It is being presented, however, as something 'brand new' for which we need to make sacrifices in other areas of defence spending.
In other words, a pile of tech-speak bulls**t being used to hide a poor exuse for cuts to the budget. A well-known hallmark of this Govt.
16B
Join Date: May 2004
Location: Up North
Posts: 801
Likes: 0
Received 0 Likes
on
0 Posts
1) Exactly what the f**k this is.
2) Exactly what it does.
3) How to use it to enhance our operational capability.
What can go wrong? Lots! For a single link, there are diffferent terminals and different implementations of the data-carrying message sets. These have to talk to each other and there needs to be some way of bringing together the information on different links. Also, some of the links need elaborate pre-planning and data load before use. Operator error can cause serious network and information instabilities.
There is a long way to go and I remain sceptical that the full claims of NEC will be met.
Join Date: Jan 2005
Location: Racedo blows goats
Posts: 677
Likes: 0
Received 0 Likes
on
0 Posts
Jess
Good call
PN thanks, I'll switch off autoburble.
The next step to NEC after the dogs explanation is that we have many legacy comms systems, JOCCS, RNCSS, RAFCCIS etc all doing their own thing.
NEC intends to join these together. So in theory you can send the data message from your sensor to anywhere on the joined up networks. Bit like join the dots, but no big picture yet.
Good call
PN thanks, I'll switch off autoburble.
The next step to NEC after the dogs explanation is that we have many legacy comms systems, JOCCS, RNCSS, RAFCCIS etc all doing their own thing.
NEC intends to join these together. So in theory you can send the data message from your sensor to anywhere on the joined up networks. Bit like join the dots, but no big picture yet.
Guest
Posts: n/a
16 Blades, NEC is very likely to use similar protocols as tcp/ip, but modified for the mil net. In fact, most of this stuff should be Commercial off the shelf in my view. Research into commercial electrical technology and software outstrips mil research many times, and in many ways is far more powerful than the crap we get given(apart from nuke hardening, which is a waste of time nowadays). The problem I forsee with these networks will be commonality of standards; at the moment I wouldnt be surprised if the targets the army navy and Air Force have set in achieving NEC are completely different. We instead need to think what do we want to achieve together.
Another problem I forsee; BWOS and their ilk will probably not allow us to modify software source unless they say ok, which = $$$$$ for them. Which means our technology will continue to suck.
Finally, a big question we should be asking should be this; is our research and development leaning towards US or European data standards? What I am getting at is we have to go one way or the other, we cant afford both. So Buff, Team America or Eurotrash?
Another problem I forsee; BWOS and their ilk will probably not allow us to modify software source unless they say ok, which = $$$$$ for them. Which means our technology will continue to suck.
Finally, a big question we should be asking should be this; is our research and development leaning towards US or European data standards? What I am getting at is we have to go one way or the other, we cant afford both. So Buff, Team America or Eurotrash?
16 Blades
Sorry, I didn't think I wrote in technobabble but when you say.......
"What this appears to be, at present, IMHO, is the usual obfuscation, with unfamiliar language, of a philosophy we have already followed for the last 20 years and have, at least in part, implemented. It is being presented, however, as something 'brand new' for which we need to make sacrifices in other areas of defence spending".
YOU ARE ABSOLUTELY RIGHT.
In its most basic form it is often described as the "sensor to shooter link". Ships and aircraft already do this of course, and the wider infantry will get there in 2009 or so (it's already contracted). Anything beyond that very simple implementation depends on funding (and bandwidth). But, too little effort goes into getting the basics right. From my viewpoint, the people who lead this "initiative" understand what to do with the information, but haven't a clue how to acquire it.
What little money there is at the moment is being wasted. Having demonstrated HOW to do it over many years, clearly there are some who know how. I've tried reading that new JSP, and it's mindboggling how such crud can be issued when all they have to do is offer a link on the MoD website to the Def Stan and one to a typical management plan so others can use a common template; preferably that already approved at 2 Star years ago, which is itself a simple extract from the Def Stan. Does the author of the JSP realise such approvals and source documentation exists? Does it not speak volumes that an approved and contracted NEC management plan is a simple and minor extract from a Def Stan last amended in 1990?
Here's an idea. Get the guy who wrote the Def Stan to take over NEC. He'd go through it like a dose of salts. He retired in '92 but he'd do what he always did - hand pick an experienced team, make them better, and let them crack on.
Sorry, I didn't think I wrote in technobabble but when you say.......
"What this appears to be, at present, IMHO, is the usual obfuscation, with unfamiliar language, of a philosophy we have already followed for the last 20 years and have, at least in part, implemented. It is being presented, however, as something 'brand new' for which we need to make sacrifices in other areas of defence spending".
YOU ARE ABSOLUTELY RIGHT.
In its most basic form it is often described as the "sensor to shooter link". Ships and aircraft already do this of course, and the wider infantry will get there in 2009 or so (it's already contracted). Anything beyond that very simple implementation depends on funding (and bandwidth). But, too little effort goes into getting the basics right. From my viewpoint, the people who lead this "initiative" understand what to do with the information, but haven't a clue how to acquire it.
What little money there is at the moment is being wasted. Having demonstrated HOW to do it over many years, clearly there are some who know how. I've tried reading that new JSP, and it's mindboggling how such crud can be issued when all they have to do is offer a link on the MoD website to the Def Stan and one to a typical management plan so others can use a common template; preferably that already approved at 2 Star years ago, which is itself a simple extract from the Def Stan. Does the author of the JSP realise such approvals and source documentation exists? Does it not speak volumes that an approved and contracted NEC management plan is a simple and minor extract from a Def Stan last amended in 1990?
Here's an idea. Get the guy who wrote the Def Stan to take over NEC. He'd go through it like a dose of salts. He retired in '92 but he'd do what he always did - hand pick an experienced team, make them better, and let them crack on.
Short Blunt Shock
Join Date: Jul 2003
Location: UK
Posts: 631
Likes: 0
Received 0 Likes
on
0 Posts
Tucumseh,
Sorry old boy, didn't mean to imply you were perpetuating the muddy waters. I am quite technically-minded, but my tiny Herc-driver brain tends to implode when confronted with nonesense on this level!
Thank you for enlightening me on this issue!
16B
Sorry old boy, didn't mean to imply you were perpetuating the muddy waters. I am quite technically-minded, but my tiny Herc-driver brain tends to implode when confronted with nonesense on this level!
Thank you for enlightening me on this issue!
16B
