The problem with Systems Engineering...

I should probably start by explaining that these are personal views only, and generated from over a decade's worth of experience, mostly in military engineering either working for, or with direct contact with Systems Engineering departments and engineers. There are a wealth of examples I have not included, most supporting but a few contradicting the below arguments and analysis; of course there are always exceptions to any rule and the below sums up the overwhelming majority of my experiences so far over a number of companies with a variety of approaches.

Systems Engineering is generally defined as an ‘interdisciplinary approach and means to enable the realization of successful systems’ and ‘focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem’ (as stated by INCOSE). It aims to consider engineering systems as a whole rather than to just concentrate on one particular component within them.

This approach has been wholeheartedly embraced by military and government companies and agencies and relatively large systems engineering departments have grown which are now central to most large projects. This approach isn’t quite so prevalent in other industrial sectors, however, which tend to rely on the more “traditional” mechanical, electrical and software core with additional specialists under a chief engineer or technical lead.

The key problem arises because in practice systems engineering doesn’t work like this. Most ‘systems engineers’ are not truly multi-disciplinary engineers and are more akin to project engineers or project managers in both form and function. There seems to be an ingrained belief that to run a successful project a company will use ‘robust processes’ (creating or borrowing any that do not already exist), apply ‘systems engineering principles’, crank the handle and out will plop a perfectly adequate product. And it generally does, but the price for this ‘low-risk’ approach is a bloated team structure, an extremely high project cost and a long development and production phase. The final product, due to the processes and checks performed along the way (refer to the systems engineering ‘V’ model below) ‘does what it says on the tin’ but nothing more, because the systems engineering ideal of multi-disciplinary operation which should pick up on the interactions between requirements hasn’t been properly implemented. In fact, it is not only not implemented, it is actively repressed. The term ‘scope creep’ is often mentioned alongside poorly performing projects and refers to changes in base requirements or functionality (usually but not always initiated by the customer) that have negative time, cost and resource implications on the project, and has led to a somewhat blinkered approach to requirement analysis and test. The segregation of requirements is further emphasised due to the content of military projects where specialist or security restricted components are utilised (biased away from multi-disciplinary engineering) leading to exponential increases in effort and documentation. Therefore requirement interactions aren’t addressed and the product is never or poorly optimised, a fact that is in part recognised by the industry and summed up with the statement that the product shouldn’t or won’t be ‘gold plated’. In non systems-engineering led companies (which to be fair generally have less complex systems/products) this doesn’t happen so much and is helped (especially in automotive and consumer electronics sectors) by an emphasis on cost reduction across all disciplines leading to cross-department communication and negotiation.

Diagram courtesy of "Clarus Concept of Operations", Publication No. FHWA-JPO-05-072, 

Federal Highway Administration (FHWA), 2005

A suitable but flippant analogy might be the rise of the modern pop industry where there are a set of well documented ‘processes’ involved in releasing a new song (usually involving a televised competition, a set of calculated press releases and stories, a generic and simplistic backing track, some nursery-rhyme lyrics and a revealing stage costume) which almost guarantee a high volume of sales for what is by any standard a low quality product (if strangely popular).

The advent of CAD, for example, has totally transformed the front end of mechanical engineering, but it has led to a reliance on technology in designing components. There are still occasions when a bit of cardboard and some tape to make a space model is quicker and more informative than computer modelling, but that is not what the process dictates and is shunned in favour of a computer screen.

Modelling, also, is now seriously considered as part of the process, probably reducing the prototyping phase of development, but is only really beneficial if models created are validated on actual hardware. This validation step can easily be skimmed over, with 'proof' of a component or subsystems requirement compliance shown on a computer screen or presentation media and another valuable link to actual hands-on engineering is diminished.

But none of this is to say that these processes should be removed. Far from it! What it does say is that common sense should be applied in the first instance, and these processes invoked where they are necessary or beneficial (and in no way should safety be bypassed). In general, the earlier in the lifecycle, the less that processes should be mandatory, and as a product progresses through design, modelling and prototype stages they should become more important, becoming mandatory in production and beyond. It should be down to the discretion of the engineers performing these tasks, and it inevitably comes back around to the original problem that there simply aren’t enough truly multi-disciplined engineers and too many project engineers (or however they prefer to call themselves). If we can solve this problem, it should drastically reduce product development times and optimise products (in terms of cost and functionality), which in turn will greatly benefit active military personnel and the taxpayer. It will, essentially, recover some of the flair and innovation that has been lost in engineering over the past years and recent projects. But as this will also increase risk and likely decrease profits for the companies involved, it is unlikely to happen without external intervention (although note that the product cost itself should be reduced which might explain why non-military sectors use more traditional methods in favour of a ‘systems engineering approach’).

I’ll (perhaps controversially) define a multi-disciplined engineer as one who has the base understanding of and ability to apply engineering first principles to understand and solve any engineering problem. These engineers will have applied this knowledge first-hand and are not afraid to try new things, assuming those things are well understood.

Military Remote Control Platforms (article)

This is an article I wrote for ThinkDefence regarding Military Remote Control platforms and systems (land), to date unpublished (except for here!). All pictures should be license-free (please contact me if I have made an error!).

Introduction

Firstly it needs stating that I don’t believe remote control systems can ever entirely replace ‘boots on the ground’ and they should not be viewed as a method by which to do this. But what they are good at is removing personnel from danger, and in doing so can change the rules under which they operate. This is not referring to any offensive capability, but rather the changes possible in platform or system design & capability. A key example of this could be the reduction of necessary armour. This weight reduction could lead to decreased power and transmission requirements and cost (through life), increased mobility (strategic and tactical), payload, range, and the list goes on. This sounds too good to be true, and it probably is if you require high levels of situational awareness and a rapid response to a changing environment. But more about that later

Definitions – Levels of Autonomy:

There are many definitions of the levels of autonomy that can be used to describe systems, but they are perhaps best broken down into four main categories, although there will be ‘gray areas’ between them.

1. Information only – the system will provide a person with information to aid his task (for example a Satellite Navigation system in a car) but otherwise has no control over the physical world.
2. Tele-operation – the system reacts directly to a set of human inputs
3. Semi-Autonomous operation – the system can perform ‘basic’ tasks on its own (such as the recent self-parallel-parking cars)
4. Fully Autonomous – the system is given a mission to perform and does not need any further human input

History

Remote controlled military vehicles aren’t new. Notable examples would be the Soviet Teletank and the German Goliath tracked mine (both around or before WW2), but arguably neither of these was a resounding success. Several decades later, in 1972 remote control entered the mainstream EOD (Explosive Ordnance Disposal) world with the first Wheelbarrow vehicle (so named as it was based on an electric wheelbarrow chassis); since then these ‘robots’ have been phenomenally successful in their EOD role conservatively saving hundreds of lives around the world. Larger platforms have proven useful in recent years, with specific mention of the Israeli remote control Caterpillar D-9 bulldozer (used in an anti-IED or combat engineering role) and the recently in-service UK Terrier, along with the UK’s Panama Snatch vehicles (which have been well covered by previous ThinkDefence posts). And of course the MineWolf family of vehicles that are in service globally dealing with mine clearance.

'Goliath' tracked mine 

Recent programmes/research

There are a number of projects running or that have run regarding the use of autonomous vehicles in the military domain, mostly centring around supporting a squad of infantry either by acting as a bag-carrier, a resupply or medevac platform or in limited cases as fire support. The US has been particularly keen on the idea (most if not all of the UK programmes have stalled somewhat) with the Lockheed Martin MULE (Multifunctional Utility/Logistics and Equipment) briefly kept alive after the demise of FCS, the Lockheed Martin SMSS (Squad Mission Support System) which is similar to the UK/AUS BAE Systems MOATV (Multi-Operated All-Terrain Vehicle), and the Boston Dynamics BigDog (apparently destined for the LSSS or Legged Squad Support System). Going up in size we have the G-NIUS Guardium (a security/patrol UGV), the Gladiator (a sort of multipurpose UGV) and some classed as UCVs (Unmanned Combat Vehicles) such as the BAE Systems ‘Black Knight’ and the General Dynamics unmanned Stryker. I feel obliged to mention Crusher and Ripsaw also as larger demonstrator vehicles designed purely for unmanned off-road use. They also have immensely enjoyable videos.

Lockheed Martin's SMSS

Howe & Howe 'Ripsaw'

There also seems to be a shift from military programmes to civilian/university (or even ‘hobby’) programmes, with DARPA and their series of ‘Grand Challenges’ leading the way. The UK MoD copied this approach with their own Grand Challenge in 2008 with, in my opinion, a disappointing follow-on in terms of industry engagement with the technology. The US have also tried to create an unmanned vehicle control standard, called JAUS (Joint Architecture for Unmanned Systems) which appears to be used sparingly outside of educational facilities (perhaps due to the complexities of applying this to complicated systems, or alternately because the manufacturers of military equipment would rather use proprietary protocols that protect their research and investment!).

However, as far as I am aware, none of these programmes have made it past trials (sometimes advanced trials) for a variety of reasons. Generally these systems can be made to work quite well in a controlled environment but struggle to react to the variety of conditions that they are expected to face. Terrain is an obvious example, with a trained driver instinctively knowing how best to approach and cross obstacles and what to do in the case of unexpected behaviour. There are exceptions, of course, and the controlling systems and software are getting better, but at the moment and in the foreseeable future I think a good human operator has the edge. A remote controlling system will always have an inherent delay (or latency) between sending any command and the system acting upon it, making anything that is time-dependent such as laying on a moving target or dodging other moving vehicles much more difficult. This delay increases with increasing levels of security/encryption and to an extent distance between the platform and controller (which is why Satellite communications have a very noticeable delay). Interestingly the digital video systems (see DEFSTAN 00-82) part of the GVA (Generic Vehicle Architecture) being implemented on new platforms such as FRES also suffer from inherent latency, which is why even the latest vehicles are still equipped with vision blocks/periscopes (and as a backup in case the vision systems fail).

Teleoperated conversions

Of all the remote control vehicles mentioned (and there are dozens of others that I haven’t) there doesn’t appear to be any real bias towards converting an existing vehicle or creating a new one. Indeed with few exceptions, all have the capability for either a human or a remote operator. In doing so, they are sacrificing a huge amount of potential as the vehicle will be optimised for neither. A previous comment to a post I read asked how difficult it would be to convert other vehicles, such as Warrior. The answer is that it is exceptionally easy (especially with Warrior with the way it is controlled – I’d guess we could have it working reliably within a week) to drive it remotely (although you have to consider other factors such as control of the turret, especially loading of the RARDEN, and camera placement) but why would you want to? Warrior was designed to carry troops under armour.

FV510 'Warrior'

The future (open to interpretation/discussion)

So where does the future of remote controlled platforms lie? I for one do not believe that autonomy for land systems is a likely goal for the next few decades or so, rather that teleoperated or semi-autonomous systems in specific roles are much more likely to be accepted into service. Their primary reason should always be to keep humans out of dangerous environments wherever possible but other advantages including a lower base and through-life cost, or a personnel reduction may well prove a greater incentive. Areas of interest we’re looking into now are mine and IED clearing, convoying, reconnaissance & patrolling, communications relaying, search & rescue, recovery, resupply and a host of non-military applications including mines rescue and agriculture. We’re also focusing on using COTS equipment where suitable, which makes any platform or system at least two orders of magnitude cheaper than would currently be required, which, given the emphasis on budget cuts and the ability of the enemy to take out a £4m vehicle with a £100 RPG or mine is not to be underestimated.

To me, though, the key thing I consider is that the best way to stop a soldier being killed by an IED or a bullet is not to have them there in the first place wherever possible.