A conversation with my son over a McDonald’s sparked a bit of architecture for Autonomous Networked Dynamic-learning Robots (AKA ANDR) and a short story about their use in a near future counterinsurgency operation. You can read the short story (First Mission ANDR12) on my writing and reading blog.
Being an analyst underneath and having worked on over 50 government projects I started off thinking about the requirements I’d write if I was going to procure some combat robots. Here’s the list I came up with, which uses MoSCoW to prioritise them.
- operate without external control signals
- be able to go anywhere a human could
- be resistant to hostile interference or attempts to subvert control
- follow legal commands and obey rules of engagement absolutely
- Learn from experience and share that with other units
- Have a modular construction to facilitate field repair and upgrade to maximise operational numbers
- retain data integrity to the same tolerance as aircraft black boxes to facilitate lessons even when the robot becomes nonfunctional
- Have diverse sensors and multiple redundant systems to ensure operation in a wide range of environments
- be capable of operating without EM emissions and with the minimum IR signature for periods of up to two hours.
- Have a reassuring presence for civilians to facilitate engagement
- look indistinguishable from human soldiers at a distance to maintain surprise
- Have secure communications to their home base and blue tracker/IFF capabilities built in
- Be able to operate the full range of military equipment and weapons that human soldiers would be expected to.
So I’ve got some requirements for my ANDRs. That leads on to a bit of solution design. I’ll be honest here and admit that I committed the cardinal sin of creating the solution and then writing the requirements, but that’s because the conversation with my son involved him asking how you avoid it being hacked.
The best way to avoid something being hacked is to keep it physically and virtually isolated. So that’s what this architecture does.
I can hear you cry ‘Wait! Doesn’t the N in ANDR stand for Networked?’ You’d be correct. The ANDR is networked, but not the decision making bit, and there are various firewalls, encryptions and other controls in place to mitigate some of the vulnerabilities.
The key components are
- Decision engine (i.e. the brain, this needs to be read/execute only and firewalled from all the other components. Updating the software would need physical access to the ANDR unit.)
- The mission profile (a small EPROM unit that would store the current mission profile, orders, RoE and relevant int. It would have an explosive tamper trigger to stop it falling into enemy hands. It would probably need a command authority to update and that would be a base job, not something you would do in the field.)
- Doctrine module. This would be the ‘training’ for the ANDR and it would be divided into two sections. One the legal and absolute restrictions that were read only. It would be isolated from the outside by not being connected to it. It could get an update from the base workshop.
The other part would be TPPs and SOPs that could be updatable by the machine learning module (see below).
- Machine Learning Module. This would be able to monitor all of the inputs and outputs of the physical ANDR unit and draw conclusions from the experience. Its connection to the outside world wouldn’t be send only, to share lessons back home (pending a workshop update for other ANDR units if the analysis showed this was a better method). It would be able to update TPP if, for example, it found the current method didn’t achieve the expected results.
- External HUD. This would be a blue force tracker style update. For firewall and compatibility reasons the ANDR would use visual and audio sensors in the same way as human soldiers would to assimilate data. This would keep them firewalled and also ensure that they had the same info as their human commanders.
The other important thing would be to give the ANDR units an ability to share physically with each other, both modular components to keep them upgradable and maximise serviceability. You’d also want them to have an in field method of sharing lessons, possibly through NFC style readers with physical contact required.
Lastly you’d also give them a hierarchy of trust. It would start with their isolated components, then their physical hardware, validated encrypted Comms and so on down. You’d probably also have some machine learning algorithms for recognising friendly forces and spontaneous chains of command.
ANDR physical attributes
It isn’t strictly necessary, but I reckon you’d want to skin the ANDR units so that they passed for people at first glance. Maybe even at second look too. This would make them a bit less scary, and therefore more useful in dealing with people. They could be really useful as reliable interpreters and also with FR etc in gathering intelligence on who was where.
You’d want to put the brains in the main body, where you could armour it better, and also put the same body armour on as the people had. This would keep your enemy guessing and would also improve the learning capability as it would be less likely to be destroyed. I expect it would be in a similar casing as an aircraft ‘black box’.
How far away?
It’s hard to be sure. There are already reasonable prototypes of a lot of the technology needed. None of them are ready for this yet, but one day they will be. I deliberately didn’t put a date on the story, but I would put a 40% confidence on it happening before 2030 and a 90% by 2050.