Systems Engineering and Management - from a Project Manager's perspective

I've spoken to a number of people regarding my posts on the problems with systems engineering and my take on how to manage projects in an effective way, but following a conversation with my (little) brother who has become a somewhat successful project manager it has made me realise that there is another side to this problem.

People

It started with some advice he had been given, which went something along the lines of "pick the best people you can for your project". Obvious, yes, but the reason was that if you pick the best people you then don't need to have all the necessary processes in place as they don't need them in order to get the job done. And apparently without them they work much better. But the flip side is that if you don't have the right people, those processes are vital to ensure that you get any decent work out of them at all.

So whilst he agreed with all of my previous points when dealing with the 'right people' he absolutely disagreed with them if those people weren't part of the project. Interestingly this is one of Kelly Johnson's famous "Rules of Management" (No. 3 - Use a small number of good people, 10% to 25% compared to the so-called normal systems).

And so we appear to have a two tier-system, both in terms of managers and engineers, with a 'good' manager understanding when to use fixed process (and more importantly with what people) and when not to, and a 'good' engineer able to work outside of fixed process when applicable. Unfortunately it seems both are rarities in the modern workplace, and perhaps the next best question is why, and what can we do about improving this. And perhaps the problem isn't with the current interpretation of Systems Engineering or Project Management but the people who are doing it.

August update

A very quick update; there has been lots of work done, most of which isn't ready to be published or isn't going to be (for obvious reasons). 

Our existing platform upgrade plans are sufficiently mature to start cutting metal and dust off the MIG.

New drive systems are in the latter stages of design too, with parts sent out for laser cutting quotation (can't quite justify our own laser yet....)

Work on the website has also progressed - to be released to the public once finished!

And we have an official looking sign at the entrance to the unit now.

There has also been a large amount of work done on some remote wireless sensors - more details on those to follow in a later post!

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.

New demonstrator platform - Saboteur 8x8

With the temporary delay in the arrival of the ZZ3 'rolling chassis' we have obtained a Saboteur Mk IVa 8x8 to use as a demonstrator. Bought in a sorry state, work has already begun on restoring this unusual vehicle before the conversion to remote control can begin.

Originally built in 1981 (before the internet became popular) information on this vehicle is scarce. We think it was made originally by Saboteur Vehicle Company Ltd (of England) as amphibious, all-terrain military transportation (the manual mentions being a missile carrier with crew seats) but was never bought by the UK military. It has an aircooled VW Type 127 engine kicking out (according to the engine plate) 40.4kW @ 3600rpm (or around 54hp - making it several times more powerful than the similar-looking ArgoCat) driving a hydraulic pump which in turn drives two hydraulic motors, one for each side, linked via chain to 4 wheels & flotation tyres each. Interestingly it would appear that ours is reversed (essentially running backwards) and was built for agricultural crop spraying with a side mounted cab rather than inboard driving position. Made entirely from aluminium, it has survived in excellent condition (except the tyres) having only 600 hours on the meter and even the engine is turning over nicely now (although it had 3 different types of spark plug fitted and a variety of mismatched leads).

The manual and limited web information indicate that the original vehicle had a top speed of 56kph and a maximum gradient of 60° which would make it unbelievably mobile for a hydraulically driven vehicle. We're looking forward to testing this out! Ours doesn't appear to be immediately amphibious (too many holes) but could probably be converted back to this standard with relative ease.

This vehicle should prove to be an excellent demonstrator; controlling engines and ancillaries, skid-steering, and an introduction (for us) into the world of hydraulics (instead of direct or gearboxed electrical, or mechanical clutch-brake or differential drive). And it should be fun!

Terex ZZ3 overview

A while back I was looking around for a suitable platform for military work (mine clearing, convoy protection, that sort of thing) and came across a vehicle (then) called Otter (or Gaz 3409 'Bobr' (Beaver in Russian), now Terex ZZ3) from a company called Specialist Vehicle Trading. A few conversations with the owner eventually led to a visit to see a couple that were in the UK.

The vehicles were perfect. Weighing in at around 3-3.5t they are fully amphibious and have phenomenal ground mobility too. The pickup version has a very useful cargo area and load capacity and we figured that a teleoperated version with the upper bodywork removed would have well over a tonne payload.

We set about applying our teleoperation architecture to the new platform. In keeping with the modular approach, our main module and drive module are a standard fit with a platform specific interface module being designed to interface to the Cummins 2.8 ISF and vehicle electrics. This interface module also handles the user interface, as part of our target was to replace the Russian-fit 'stick' steering control with a Western-friendly steering wheel or yoke arrangement.

As a testament to the modularity of the teleoperation architecture, the platform was driving through the new control system at the end of the first day of integration, and entirely remotely midday of the second day (which is when these videos were taken).

http://youtu.be/P4veaEZMr6E

http://youtu.be/9alSIcRmnV8

http://youtu.be/HKLJsdnauuY

By day three we had a quad-camera video link fitted (using two forward-looking cameras) and had successfully driven the vehicle on the road (note: we are still unsure as to the legal technicalities of this so we had two qualified tracked vehicle operators on board for the testing).

At this point the decision was made to transition from prototype modules to full production ones, and to swap our manual gearbox vehicle for an automatic version. While doing this we had a couple of high-profile customer demonstrations and took both vehicles (one remote) to the Emergency Services Show (2012) at Stoneleigh where for both days, despite the rain, we demonstrated the remote control ability to show visitors and exhibitors with a high degree of interest.

Currently both vehicles have been returned to their factory in Russia and we are awaiting their return (complete with automatic gearboxes) in order to fit the latest production modules and to finalise the steering automatic calibration routines.

Several people have asked what the intended use of the remote platform is. The key reasons for remote control are to remove people from potential harm and to increase the platforms capabilities by removing people (e.g. taking the vehicle into a burning building, carrying large loads or using it to rescue stranded people (more people per load so less trips)). We have plans to implement a 'virtual hitch' to create a convoy-style arrangement, a remote control manipulator arm (similar to a HIAB) and to add data links to enable extra functionality such as sensors or UAV applications. Whilst we are concentrating on civilian applications, there are many military applications also, not limited to mine detection and clearing, reconnaissance, recovery, convoying and fire support. Our biggest advantages are unparalleled mobility and low cost.

An “Engineering Guide” to agile project management

Project management has become, in many cases, a self-justifying and overly time consuming occupation, acting as overhead to projects and retarding potential progress. This guide aims to show how this effect can be minimised with additional guidelines or rules that will benefit the project, especially in the early stages between project start before the production phase begins. An over-reliance on processes early on when the project is in an increased state of flux also retards potential progress.

No engineering guide would be complete without a reference to Kelly Johnson’s ’14 Rules of Management’ which were formulated and successfully carried out during his time at Lockheed Martin Skunk Works.

But there should be no hard-and-fast rules. Each project is different, run in a different environment with a different group of people and there are no catch-all solutions that will always give an optimum solution.

The key parameters to keep in mind throughout are:

The project flow is shown as an iterative process, starting with an initial set of specifications (generated from customer requirements) which are updated as the design develops. Here the feared ‘scope creep’ can be harnessed as a powerful positive effect as it is primarily restricted to the early modelling and prototype stages which are rapid. It is expected at this stage that a range of suggestions (resulting from modelling and prototyping) are submitted to the customer in order that the base requirements could be modified (note this is a major deficiency in the present systems engineering philosophy).Her

The usual project flow has been modified to highlight early stages including modelling and prototyping. These are regularly missed in contemporary project phases where the focus is on production. Modelling in this case refers to business models (financial and budgetary), operational models (use cases, functionality) and system models (component, subsystem, algorithms), as well as specialist modelling where appropriate (such as FEA or thermal analysis). This is an incredibly important step as it gives confidence that the product is technically and commercially feasible before any ‘metal is cut’. The models are intended to be kept up to date throughout the project from their creation onwards and validated against prototypes and production output when possible.

Project rules:

Personnel:

• No more than 10-20% of the engineering team should be ‘managers’
• Staff numbers to be kept to a bare minimum
• A multi-disciplinary engineer (or systems engineering team for excessively large or complex projects) should lead project decisions
• Using multi-disciplinary engineers eases resourcing issues and will optimise workloads

Planning:

• Mid and Long Term planning to be minimised except for key dates/deliverables and framework
• Budgetary considerations are to be kept updated weekly – project spend and forecast
• Non-essential documentation to be minimised. Essential documentation to be done to high standard.

Engineering team:

• Teams to be co-located for ease of communication
• Teams will be responsible for allocated tasks
• Designing engineers will be responsible for testing
• ‘Beating deadlines’ will be rewarded

Meetings:

• Restrict attendance to required personnel only but publish minutes
• Meetings shall always have actions
• Meetings should occupy no more than 1 hour per day for engineering personnel

Other:

• The customer shall have open access at all stages of the project
• Decisions will be timely
• The rules are flexible, at the discretion of the lead engineer
• Common sense can replace 90% of processes, especially at the start of the project

The beginning! G32 Technologies and Digital Concepts Engineering join forces...

This blog aims to chart the progress of our new joint venture, starting with our optimised teleoperation architecture and associated systems and leading on to all of the spinoffs we've already discussed (and those we haven't) which will consume all available spare time from here on in.

I should have started this some time ago. We've already built the prototype teleoperation system and have it running on several platforms, the most impressive being the Terex ZZ3 (previously Gaz 3409 Bobr) which has already been demonstrated at the Emergency Services Show (2012) at Stoneleigh Park. Since then the system has been productionised, with modules being combined, redesigned and manufactured such that we have Drive, Arm, Radio, Telemetry and GPIO modules ready for other platform integration and several other modules in prototype or build. We have an industrial unit in Hinckley and are in the final stages of repainting and kitting it out. Once fully online we will have electrical, software and mechanical development facilities including a basic machine shop with CNC equipment and a secure external area for gas and fuel and/or battery charging. We have one dedicated vehicle bay which should accommodate pretty much anything short of a main battle tank.

   

I'll aim to update with past achievements before we progress onto the new (and very exciting) projects!