DEEP GREEN - or, how to cut down on donkeywork in BG HQ

Discussion in 'Staff College and Staff Officers' started by Gravelbelly, Jul 22, 2007.

Welcome to the Army Rumour Service, ARRSE

The UK's largest and busiest UNofficial military website.

The heart of the site is the forum area, including:

  1. This announcement by the American DARPA is interesting - they've described what they want their next generation decision support tools to achieve (lots of cute but worrying graphics, and a certain degree of hand-waving). From a Computer Science spot the geek point of view, it seems quite plausible.

    Jim Storr's comments in the most recent BAR may well apply, but it will be interesting to see what the winning proposals turn out like. Actually holding an open competition is a cute way of doing it....

    Anyway, for all those who've had fun at CAST doing Ops Officer, enjoy:
  2. in_the_cheapseats

    in_the_cheapseats LE Moderator

    You may be interested to know that some work that I have been involved (as part of a DTC Info Fusion project) has been working on proving technology for exactly this requirement for the UK. The project has been running for the last 3 1/2 years.

    It is still early doors in regard to TRL and hampered by a lack of ability to gain enough information from across the battlefield to truly automate the command support system (NEC is needed but to a level of performance way above what we have now) but we are getting there.

    For those geeks amongst you, if you want to know a little more, PM me and I can give you direction to some open source papers
  3. Call me a luddite, but it does sound a little like getting a computer to do your thinking for you?

    Having said that, the Sketch to Plan and Sketch to Decide stuff would be fun, as would the computerised wargaming of Blitzkrieg (no more moving pieces of sticky!). Any idea how long this would take to come to fruition at current rates?

    Is it just me or is the comment "This will keep the enemy firmly inside our decision cycle" not quite what they meant?
  4. It shouldn't do. Computers are great for mechanical, donkeywork tasks ("add up all the numbers in this column" / "calculate how long it will take a convoy of X packets to get from A to B using the A383 if it uses formation SOPs for packet separation and average speed")

    Computers are pish at originality. Kind of hard to predict it in order to program it, you see.

    So; what you do is you soup up the "design tools". That's why document editors have spillchuckers, and programmers get compilers that turn a computer language into an executable, rather than having to write everything in 1s and 0s.

    The question is what you can make easier. By way of example, who plays solitaire with real cards these days? The computer has taken on the responsibility of shuffling, dealing, checking the rules, and scoring. You still get to enjoy the game, but without the boring bits; you can go back a step, and play it out a different way.

    I will confess to having a few ideas on the "design tools" front, but that's just the happy coincidence of being an ex-Ops Officer as well as a software engineer to trade, working on design tools....
  5. I lasted 3 pages - shocking!

    Bottom line - taking the problems in Iraq and Afghanistan - there is no need in many HQs for rapid decisions this seems to be more of the network centric mantra - to succeed in our current environment we need people who are educated in how insurgencies work, supported by OGD with a mandate and funding to make things happen and a willingness to be patient and last the course and of course decent intelligence.

    I admit I failed to get past page 3 but was there a button/function on the thing to switch off media/government/public intervention?

    From what I see the ability to conjure up all of the resources into a particular area exist with current technology - COA development ain't that hard and resourcing NAIs/TAIs is a doddle provided adequate direction is given. To my mind this is Cold War mindset along with a lot of other stuff we are buying into.

    As an ex-CAST Observer Controller my experience was that the thing that increased tempo was the Combat Estimate rather than a lot of bone computer programs we ended up trialling.
  6. We must not be under the impression that computers will speed up decision making. The Yanks make the mistake of thinking that 'metrics' will make their life easier. B*llocks in my view.

    What we do need is well trained officers in BG HQ who get plenty of practise. It is led by the BG 2IC who must set out the procedures. This starts with a thorough understanding of the 7 Questions, which is relevant fm Pl level up to Bde. Once a BG HQ gets its act together and G2 staff know where they fit in with G3/ ISTAR/ G4/ Info Ops/ CIMIC etc, then we will be getting somewhere.

    Where IT will help is in terms of situational awareness, but prob not until the next iteration of Bowman comes out next year and ComBat actually starts to work (it's tonk at the moment).

    Bottom line: Practise using BG CPXs, then BC2T then CAST then an FTX. It is no surprise that the BG HQs who have had most practise are normally the best. For example, whilst I disagree with some of their methods, the LWC BG HQ has a well practised system that works for them.
  7. in_the_cheapseats

    in_the_cheapseats LE Moderator


    Just remember that this work is not really for the here and now. Certainly for the UK it is more probable this is 10+years out timeframe and more likely even further as the comms links needed may be beyond BOWMAN.

    This is not talking about IT in the simple form it is now. It is dealing with semi autonomous AI, in other words a "learning" machine. Remember the capability of IT in the early 90s? I did JDSC in 96 where the computer geek of the course told me to buy a DX-4 100MHz with 128RAM which would be good enough to last me a long long time..... 8O

    I doubt anyone would argue that the capability of IT has increased exponentially since then; why not again in the next 10 years?

    Who here thought that unmanned weapon bearing platforms would be deployed in the here and now in the numbers they now are 10 yrs ago? I didn't.

    Who would have thought that huge numbers of people would be playing (experiencing? - your call) "real life" in a virtual environment ? I certainly didn't. Star Trek stuff, isn't it.....?

    Current thoughts are that there is a real possiblity that the next role out of fast jets may be the last that are manned.

    What other uses can IT / AI offer to the warfighter?

    IT (and iterations of) tech is moving forward at an extraordinary rate. We all see it happening day by day. This project and others like them are looking to flex that tech into the military arena.

    Lastly, the days that technology development is driven by military requirement are long gone. We bastardise civil applications and bend them to our uses. Whatever we do from now on, just remember what we deploy from here on in will always be behind what is available on the open market.

    Scary, eh?

    PS to those that asked for some open source material - I'm not blowing you out. Expect the links in the next couple of days
  8. Some years ago, I argued that technology was speeding up as the second wave of computers (arguably, the first wave was the mainframe and the second was the personal computer) facilitated faster development.

    I joined the "Internet" earlier than most, in the late 80s with Compuserve, but although I did all the groundwork and understood the technology, made the mistake of thinking that the technology would become more complex, and that the "computer in every home" was unlikely because most people would not want to hack into their computers every night! Wrong...

    I have since heard a friend (a bit of a geek) use the expression "if you think this is changing quickly, just wait for the next ten years..." and I agree with him. To misquote Bachmann Turner Overdrive, "We ain't seen nothing yet"!
  9. In my limited experience BG work effectively providing the fol conditions are met:

    The BG staff have a solid understanding of the organisation and duties of the staff, and C3 at both BG and formation level.
    They practise their role frequently and are allowed sufficient latitude to make mistakes during the training.

    When planning:

    The CCIR are well-defined and timely.
    The staff have sufficient time to provide robust info.
    The COA developed thereafter are realistic.

    When executing:

    Excessive control and monitoring of the BG is not imposed by the BG HQ
    Key risk is managed
    Overly complicated OpO are not issued.

    I believe this process may have been undermined and badly damaged by the introduction of ICSC, with its consequent removal of quality staff training for Captains, but I stand by to be corrected.

    In summary they must know what they have to do, by when, and both they, and their superiors, must understand their strengths and limitations. If DEEP GREEN can assist this then so much the better, but the inherent danger is info overload and an over-reliance on the COA developed by the system.

    My experience is that a good understanding of one's profession, sufficient mission rehearsal, but above all human intuition, are key to delivering the goods, and not vast amounts of info, however well processed and presented.
  10. Or was it already being broken by an arguably over dogmatic focus on process at CAST without ever actually testing whether the plan worked in a suitably challenging environment? Cf Lt Col Storr's report on GW2, and the fairly comprehensive issues he identified with timely planning down to the BG level. You do however raise the question, which has been knocking around idly for a while of whether a Bde will get a Lt Col COS and an SO2 Plans...
  11. What has changed that would indicate a need for a Bde COS to be a Lt Col? Is it an effect of the late delivery, and subsequent lack of time to develop staff skills, of staff trg; or is it a need to invent additional Lt Col posts to solve the increasingly dire promotion prospects for the majority of Majs; or that existing COS simply are not delivering (the last being something that I would unhesitatingly rule out).

    An SO2 Plans would presumably act as the COS bag-carrier, or would it be a straight replacement for the existing SO2 J5 Plans - in effect no change.

    In addition, how would the relationship change between COS/DCOS - superior rank inevitably brings with it a feeling that your 'subordinate' must be supervised, a reality that would bring an unhealthy and unwelcome intrusion of the G3 staff into the CSS world.
  12. in_the_cheapseats

    in_the_cheapseats LE Moderator

    I'm with PAW on this one. In the here and now, correct, appropriate and timely training of staff gives you ability to keep the rank levels and structures of HQ staffs.

    A need to increase rank ceiling for post is little more than a sad reflection on just how poor the staff and technical training regime for officers is in the Services at the mo.
  13. So here's another question. Should we stand up and say "CAST is exactly that - a trainer". You do the basic drills, in slow time, until you understand the full process. Once you've got a BG HQ that understands the process, you can understand where to cut corners, where to add resource, what to prioritise, where to rely on intuition.

    The same happens with TEWTs for YOs. We teach and test using a mechanistic approach to problem solving (the estimate); but then we accept that in reality, Lt Snooks is going to look at the situation, use his intuition, go "f**k it, left flanking", and come up with a plan that is 90% as good as anything that takes half an hour to consider.

    So; if we accept CAST or the Pl TEWT as vehicles for developing intuitive skills, they make sense. If we just assume that they are "how we should be doing things for real", then we're doomed, and all the IT support on the planet won't help.

    I'd like to think that the CAST staff watch the process in action, choose which "process" lessons they want to bring out, and force the exercise play in a direction to do so; white-box testing, if you like. It is a staff trainer, after all.

    Realistically, the "plan working in a suitably challenging environment" training can only really be tested on TESEX. After all, the plan is reliant on the people involved in executing it. You could try the same plan with different BGs, or the same BG with different sub-units, and get different results; chaos theory can apply (tiny changes in the initial conditions have significant impact on the end result; "for want of a nail", etc).

    My thought is that the whole staff process is terrifyingly similar to software engineering. There are analogies all over the place; how do you specify what you want the plan to achieve? How do you break the plan down into manageable chunks? How do you test whether it's a good plan?

    It's the less obvious aspects that always interested me; as an engineer, I spend a lot of time thinking up new edge cases that will break my design. Am I designing my plan to the same information as everyone else (a new Bde trace comes out, but doesn't make it to all sub-units simultaneously)? How good am I at changing my plan slightly (a boundary moves, how quickly can I revisit my planning assumptions and detect necessary changes)?

    An IT-based system won't outperform a well-trained staff on the top of their game. But I suspect that there's scope to support a staff who are short on sleep and resources; error detection, if you like.
  14. OK, here goes. The pain in the arrse with any system is data entry; always has been. Handwriting a set of orders in full, with all headings is a pain. Typing it in is almost as slow; and doing it on anything other than a full-size keyboard is unrealistic. There's copying down your commander's orders, extracting your bits, generating your plan, giving your orders. And so on, and so forth.

    So, if you can come up with a scheme that captures most of the data for you, big plus. If it can be shared so that everyone else doesn't have to re-enter that information in order to use it, bonus.

    I understand that the IT stuff lasts down to BG HQ, arguably Coy HQ for a deliberate task, and that after that it's back to an Aide Memoire and varying amounts of cuff. But anyway...

    First step - how about automating those parts of the orders that can be extracted automatically, just like those pretty coloured drawings in the pamphlets? There's a saving, for a start. Task Org, Sit En Forces, Comd's intent 1 up, Comd's ME, Svc Sp, Comd & Sig - lots of good stuff.

    Second step - Grab all of the symbols out of the IPB. If you've marked an NAI, TAI, or DP, then there needs to be a sub-unit tasked on to it.

    Third step - how about an easy capture of the Scheme of Manoeuvre? Do it diagram fashion, a la FRAGO. Some drag and drop symbols, and you can capture most of the information. Left flanking? Location of Assy Area / FUP / LD? OOM? Boundaries? Competent types can write a large chunk of a set of orders from a set of map symbols, so a computer should be able to do it easily.

    Fourth step - sequencing, or all of those things that go onto the CAST diagrams where time runs from left to right. Fire plans, etc. One row per task as identified in the IPB. Drag the sub-units from the task-org onto the tasks at hand. You've now captured what's being done and when.

    All of the above can be done just as reliably and quickly (possibly quicker) with a whiteboard and marker. The problem is that it can't be shared that way. But if you can use a standard set of staff diagrams, and write "electronically", then congratulations - you can save it, change it, check it, send it to other HQs (even - terrifyingly - have a duplicate copy at BG Alt or Step-up; there's a novel idea).

    As for testing, the support tools don't need to do creativity - they do the things that any experienced officer does when looking at a set of orders. They look for missing things (what, no order of march on the route to the FUP?) or for the inconsistencies. If plans are being shared left and right, up and down, you might even spot them early; for instance, you change a boundary, and a sub-unit doesn't pick up on the fact that it's got another task as identified at a higher level. (The analogy is a software linker, rather than a compiler).
  15. in_the_cheapseats

    in_the_cheapseats LE Moderator

    Gravel belly

    All good stuff and all that should be sent towards staff from C2DC in Warminster who have a limited influence on ComBAT development. Saying that, my money's on GD coming back with "that's not in the contract".......

    I know the "system" is still looking at ideas for BCIP 6 development. Get in now with the ideas. I'm not saying there is anything staggeringly new in what you say but good common sense sometimes needs reiteration and if there are enough people saying it, you might get something done. The only time you will get something like this through is at the time of a major drop/rewrite.

    With CAST and C2DC sitting right beside each other they are in a good position to experiment and prove the additional military benefit too.