Thales logo

A flexible soldier system – the key to meeting user needs

By John Foley and Amyas Godfrey

PDF icon Download article as PDF

The Thales Intelligent Hub, known as the Flexible Soldier Hub (FiSH), embedded into the SHArc load carriage.

The Thales Intelligent Hub, known as the Flexible Soldier Hub (FiSH), embedded into the SHArc load carriage.

In today’s software driven world we are very used to the routine of ‘upgrading’. Even when it comes to hardware, these days you can usually purchase a new product, plug it into your computer or home/office system and it will be up and running in a matter of minutes, complete with interface apps, conformal cables and shared power. Just think about plugging something into your laptop by USB or connecting by WiFi or Bluetooth. Indeed most software upgrades happen when you are asleep as ethereal web-based administrators suggest, then arrange, the best time to download the latest version, upgrade or fix. In this way the ‘system’ we are used to in our daily lives is very flexible. Different people will have similar setups at home or in the office with a combination of similar products (computers, phones, printers) all achieving the same ultimate aim or effect but set up in slightly differing ways to suit the user, their desk, their habits, their work.

Why can’t dismounted soldier systems work like this? The answer is; they can if they are designed to do so, but design needs to start with practical ‘use case’ questions and understanding the world that the dismounted soldier inhabits, then applying that to the soldier system infrastructure that underpins the systems’ ability to be flexible.

Designing equipment and systems for use by dismounted soldiers poses numerous challenges. The enhanced capability offered has to be balanced against the increases in bulk, weight, power consumption, cost, and cognitive burden. For conventional items of equipment this is a well understood (if still quite difficult) process to manage. A new weapon sight offering an increase in detection range can be balanced against its increase in size, weight and cost. A new radio offering enhanced range and a new set of communication services has to be balanced against an increase in size, cost, spectrum requirements and power consumption.

Four hours after leaving their Patrol Base, via Company Headquarters at Forward Operating Base Alma, Lieutenant Hackett and his troops piled out of their MRV-P vehicles which had taken them cross-country to Battle Group HQ. Camp Dragon was a pleasant enough place, nestled at the head of a valley, a few cafes and shops, set-up by entrepreneurial locals had sprung up around the front gate, but Hackett wasn’t here for R&R. 2 Platoon, or rather half of it, had come to BG HQ to see the Quarter Master who had some new equipment to issue which had arrived in theatre as an Urgent Operational Requirement, or UOR. The other half of 2 Platoon under Sergeant Jones had remained at the PB, and would rotate through the QM tomorrow if all went to plan.

Waving off Captain Ellis, who had hitched a ride from Company HQ, Lt Hackett, looked on as Corporal Roddis, went through the automatic process of assembling the men in a tidy gaggle, accounting for kit and rifles, before checking that each vehicle was empty.

“All good, sir”, she said, jumping down from the back step of one of the vehicles.

“Thanks Corporal, after we’ve cleared weapons, get the vehicles parked up where the RSM won’t notice, and meet me at the QM’s. I’ll let them know we’re here and get the process started.”

“Roger that, boss”, and with that Cpl Roddis and Lt Hackett moved to the unloading bay, pointing their weapons towards the sand. Checking each other ‘clear’, Cpl Roddis then began clearing the rest of the team, whilst the Boss trudged off through the squelching mud to find the QM, wondering to himself how long this was going to take.

These ‘Trade-Off Decisions’ can be made with some confidence since users are already familiar with precisely what functionality they seek from the various items of equipment and, as a community, are well able to judge if the additional “costs”, such as size, weight, power and money, are justified by the enhancements in “benefits”, such as range and performance. In many areas there are mature, validated Operational Analysis (OA) models which assist the user community in evaluating the impact of specific functional enhancements on the outcome of engagements and Battle Field Missions (BFMs).

However these Trade-Off Decisions are far more difficult to make in the emerging area of Soldier System Integration where users are provided with additional infrastructure equipment whose sole purpose is to integrate the various discrete items of equipment they carry in order to realise shared Power & Data (P&D) benefits. There are currently no validated OA models to assist in comparing alternative approaches to realising Soldier Integration.

Basic “cost” metrics such as size, weight, power and cost can be readily defined and compared but the comparison of the benefits delivered by different approaches to integration, or indeed integration at all, are not easy to come by. This comparison needs to be based on a clear understanding of the value delivered to the user from the various “integration services” offered. Some of these can be quantified and even modelled. Centralised power, for example, can be shown to offer significant weight and cost benefits as well as major logistic improvements. Shared data benefits can lead to more automated processes, especially through software applications, and indeed might lead to a higher tempo of operations, or better informed decision making. However the extent to which the system allows the user to adapt it to their evolving needs, the system’s “flexibility”, is critical to its use and successful adoption by the dismounted soldier yet it is very hard to quantify.

In the process of designing or procuring a new soldier integrated system decisions need to be made regarding the value of the benefits offered by the various options. Where there are no hard quantifiable criteria to compare benefits then an alternative approach is needed. The approach adopted here is to employ a series of Use Cases which will allow the development/procurement community to “walk through” the user’s experiences of operating various system capabilities.

There are many potential Use Cases, this initial set seeks to primarily explore the “flexibility” benefits.

The Thales SHArc with ‘brace’ to ensure continuous connection when changing dress states.

The Thales SHArc with ‘brace’ to ensure continuous connection when changing dress states.

Lt Hackett’s Platoon Upgrade: A Use Case Use Case Context

This analysis is set a decade in the future; Q3 2029. The Soldier System infrastructure has been widely rolled out across the UK Army for many years. It is mature and its use is well understood. All the support features needed are in place. This Use Case considers a platoon who, as part of an infantry company deployed abroad, are being issued with a set of new equipment. It seeks to explore and understand the various issues this exercise poses.

A number of different types/classes of equipment are considered, so that the different challenges they pose can be fully explored. The analysis seeks to explore both the technical issues and the user-centric issues posed by operating and managing a Soldier System upgrade in an operational environment.

The baseline system

The baseline system in service in 2029 comprises a Power & Data (P&D) hub, supporting a number of power sources linked to a radio (from the DSA programme) and various other devices. The system is worn by both commanders and riflemen and they share a completely common set of batteries. The commander systems are more complex in that they have additional equipment attached and are fitted with a more capable hub to cater for them. They support the Situational Awareness (SA) display, the attachment of a targeting observation sight and a military GPS unit. The system conforms to the GSA Standard (DEF STAN 23-012) and is managed from the “intelligent” hub.

For the purposes of this exercise the system considered is based on the Thales SHArc (Soldier Harness Architecture) product. That is the system most familiar to the authors. Other systems will face the same set of challenges so the points made are completely general.

The SHArc system includes the load carriage harness (belt & yoke) through which the hub and cabling are routed. The hub is located at the rear of the belt. The cables all run within the belt and within the “braces” which are attached to the yoke and allow the user to rapidly transition between different dress states by swapping the protective vest elements without removing any cables or devices. A range of connectors for the various items of equipment are fitted within the belts and braces where equipment can be connected and fixed in place using the molle straps.

A ‘Maintainer’ attaching a new cable into the hub and preparing to upload new software. This can be done at unit and even company level.

A ‘Maintainer’ attaching a new cable into the hub and preparing to upload new software. This can be done at unit and even company level.

Each user is fitted with the appropriate size of SHArc harness and then has the internal cabling fitted to suit their specific needs. Equipment connectors are fitted to the optimum location for each user and the internal cabling is then run back to the hub. A range of standard SHArc cable lengths are available to fit different locations and user sizes.

The allowed locations of each equipment and equipment combinations around the user are managed by the Soldier Integration Authority (IA). They have defined the allowed equipment combinations and the constraints on their locations. This is necessary in order to manage emergent issues from co-location of equipment around the user. These issues include Human Factors (HF) aspects, external integration needs such as fitting within platform or vehicle seats, and Electro-Magnetic Compatibility (EMC) management.

Each infantry company has a number of personnel who are trained and authorised to manage the fitting of cables, connectors and equipment around the SHArc harness. They also manage software upgrades and data downloading. These individuals (Maintainers) have the appropriate tools and access to appropriate facilities to ensure that cable connections are fitted properly, and seals are maintained and IA integration instructions and constraints are followed. When users need to have cables and connectors on their system moved they arrange for a Maintainer to do this for them. Moving connectors around the system is not a field activity. It can be done in a forward area but ideally under some degree of cover. The Maintainers also operate the system updates. They have Maintainer laptops which are used to connect to SHArc hubs in order to update software patches and virus protection, to load additional software and in order to download user’s data as required. This level of access is carefully controlled in order to maintain system security.

The Upgrade Equipment

This Use Case considers a platoon who are receiving some equipment upgrades, which need to be connected to the SHArc system. The new equipment comprises:

COTS HUMS device: This is a Commercial Off-The-Shelf (COTS) medical sensor (Health and User Monitoring Sensor). It is not designed to conform to the GSA Standard so it requires a software adaptor to link it into the GSA hub.

HMD (Helmet Mounted Display): This is a helmet mounted display capability providing tactical information to the user. It is GSA compliant equipment so it can plug directly into the SHArc GSA hub.

The Upgrade Process

The platoon comprises 8 commanders (Comd) and 20 riflemen (Rfn). The new equipment, training and fitting processes are managed together. A deployed training team introduces the new equipment and conducts the training programme. This is done in conjunction with the company Maintainer who is available to fit the new cables and connectors to each user’s system. The training and re-fitting of the SHArc systems are done on a platoon basis.

Every user has an appropriate number of spare ports on their SHArc hub to allow them to fit two new devices. The extent to which this is true will depend on the approach taken to spare ports when the original SHArc systems are procured. To minimise size and weight these could be procured with the bare minimum of ports needed for equipment at that time, plus one spare port. Then to allow additional equipment to be fitted either an additional hub can be added (daisy chained) or the original hub can be replaced by a larger hub with more ports. Alternatively the original hubs could be procured with some small number of additional spare ports to allow for subsequent expansion. There are pros and cons to each approach. The use of multiple hubs inevitably adds more weight and bulk. Replacing hubs is likely to be expensive but could result in leaner systems in terms of size and weight. Providing a reasonable degree of expansion capability does appear to be the optimum approach, but the decision will depend on the size and weight implications this drives.

COTS HUMS device – training & fitting:

In this OA scenario the process of fitting deployed soldiers with a new non-GSA, COTS HUMS device starts with the platoon being given a training session on its purpose and operation. In this case the HUMS device is worn by the user on a chest strap and connects through to the external GSA system (worn on the outside of all the load carriage) using a Near Field Communications (NFC) link. The user has some degree of choice in where they want to locate the external side of the NFC device, as long as it matches up with the strap location on the chest. Each user can select between a number of optional positions around the chest, but these are required to line up with the SHArc braces through which cables are run up the chest.

The SHArc hub connects to the HUMS device via an NFC transducer located at the end of a cable, fitted to the GSA connector. For each user the preferred HUMS sensor location is defined. The Maintainer measures the distance between this location and the hub and selects the best cable from the standard set of SHArc cable lengths at their disposal. The external GSA connector on the cable is fitted to the closest molle and is fitted into position using the innovative SHArc “widget” (a lightweight adapter which allows connector locations to be both easily moved yet firmly locked into place). The internal end of the cable is fed through the nearest access slit (either through a laser cut molle system, or specially cut access holes) into the brace and from there is manoeuvred through to the belt and around to the hub.

If the device were fully GSA compliant then this would be sufficient for it to now function in conjunction with the rest of the system. However since it is a non-GSA COTS device it requires additional “adaptor” software to be located in the hub in order to translate its own interface features into a GSA-compliant interface. Loading this software requires the Maintainer laptop, which is fitted with the appropriate security features to allow it to modify the software within the hub.

As the intention is that the HUMS data from this new COTS device will be transmitted over the soldier radio network to the commander, the commander’s display device now also needs to be furnished with appropriate software to receive this data. This is also loaded on by the Maintainer. Since the HUMS data is sensitive personal information it is encoded before being transmitted by each user and the level of information made available to a commander is highly limited. Only suitable qualified personnel have the access levels to see the detailed information but the local commander will be provided with high level warning information on their display.

Having completed the physical equipping and software upgrades, the platoon then complete the training session and a system test exercise, checking that each user’s system is working correctly and that the fit to each user is acceptable.

HMD device – training & fitting:

In this OA scenario the fitting of a simple HMD follows a similar process. The platoon are initially given a training presentation on what the HMD is and how to operate it. Each user is then issued with the elements that are to be fitted to their own personal helmets. This system has a cable off of the back of the helmet connecting to a chest/shoulder mounted Quick Release (QR) connector, which in turn leads to a cable running down to the hub. This system also requires additional software in the hub, to operate the HMD, and additional software located in the commander’s display unit to set up and manage the HMD and various attendant capabilities of this new system. The location of the chest mounted connector is constrained to being on the upper left hand side of the torso because of the usual position of the rifle butt in the firing position.

The Maintainer assists each user in turn with the exact chest location preferred by each user and once done a distance between this and the soldier’s hub is measured. The best fit SHARC standard cable is selected. The GSA external connector on this is located into the nearest molle feature and is fixed into place with a SHArc “widget”. The helmet QR connector is different from the GSA standard connector so an additional “GSA-QR” cable is required, with the QR connector also being fitted to the molle features using the SHArc “widget”. There is an alternative approach where the SHArc cable is fitted with the QR connector needed for the helmet cable – thus saving the cost and reliability issues of having an adaptor cable fitted. This choice will be made by the Soldier IA.
Having fitted the external end of the SHArc cable to the optimum position on the left hand brace the Maintainer then feeds the internal connector end of this cable through into the brace and down inside the belt itself, and connects it into the hub.

Sat in a large army green tent, Lt Hackett and his troops were coming to the end of their second briefing of the day outlining the characteristics, use and integration options of two new pieces of equipment. They could have laid on a brew for us Hackett thought to himself, just as the instructor from the QM’s department asked if there were any questions. Taking this as his queue, Lt Hackett jumped to his feet and turned to look at his troops. No questions.

“Good”, said the instructor, “Now, under the direction of your Platoon Commander and Company Maintainer, Sergeant Gregory, let’s get this kit hooked up. Health kit is on your left, Helmet kit on your right, take one each. I’ll give you two hours to get it all fitted and the software uploaded, shall we meet back here at 1400? That will let you grab some scoff as well. Mr Hackett?”

“Thank you Colour Sergeant, Corporal Roddis, let’s get this done.” And with that Lt Hackett’s troops sprang into action, knowing that the quicker they got this done the more time they’d have at the NAAFI. Every soldier knew what to do; grabbing the new kit, finding a clear space on a nearby table, and straight away starting to open up their kit to access the heart of their Soldier System, the Flexible Soldier Hub or FiSH.

Approaching Lt Hackett, Sgt Gregory the Maintainer spoke to everyone as he walked: “As soon as you’ve worked out where you want everything to go give me a shout and I’ll check it over and update your FiSH.” Arriving at the Platoon Commander, “Go on Sir, give us your display and I’ll get that updated while you sort out your kit”.

The HMD is a GSA device and requires no adaptor software in order to function as part of the system. However the HMD is a complex sub-system and it does require software within another connected device in order to provide the algorithms to drive the various commands to the HMD. It is possible for this software to be located in the hub itself as a “virtual device” rather than another physical device connected to the hub. The SHArc hub caters for this by allowing third party software to be loaded, under appropriate security conditions. For the HMD this “virtual device” will appear to the rest of the system exactly as any other GSA device would; exchanging data, conducting calculations and providing instructions to the HMD itself. The “virtual device” approach is adopted in this example.

The commanders will also need to have additional HMD software added to their display devices. This is software needed to set up and manage the HMDs from their display devices. The Maintainer attaches their laptop to each commander display device, completes the security dialogue and loads the HMD software onto each.

Once the whole platoon is fitted with the HMD devices and software the training is completed at platoon level with systems checks and field exercises.

The Soldier Integration Authority will already have fully tested and qualified both the HUMS and simple HMD devices and software. This will include defining allowed position for items to be located about the user. The adaptor software will have been supplied to the Maintainer and loaded onto the Maintainer laptop, with appropriate security provisions, ahead of any integration event. This will all be distributed in advance; along with the devices themselves, additional spare cable sets, and the training material. It may seem that this process adds complexity or additional burden to the current military system of logistics, training and supply. However it is not to dissimilar to current ways of rolling out new equipment, and it is necessary in order to realise the benefits of technology, especially the rapid upgrade cycle of software driven technology.

Although the process of validation by the Soldier Integration Authority needs to be in place for this to be managed there also needs to be a high degree of flexibility in the application of the process in order to meet the needs of individual soldiers.

The SHArc ‘widget’ flexible connector/adaptor on molle belt kit.

The SHArc ‘widget’ flexible connector/adaptor on molle belt kit.

Flexibility - On the User

The SHArc product allows users to reconfigure the layout of the connected devices around their system. The manner in which cables are routed and connectors are fitted is specifically designed to allow this. This is because it is recognised that users are different in size, shape and manner of movement and there can be no “one size fits all” solution. Soldiers are not vehicles or platforms in this sense and allowing users to get an optimised fit to suit their specific needs is important.

However there are and must be limitations. Cables and devices cannot be positioned with total freedom. There will be specific Human Factors considerations which dictate where certain loads need to go. The requirements to integrate with a wide variety of external platforms and devices may mandate where bulky items need to be positioned. Managing the EMC behaviour of the system will certainly limit the locations for some combinations of devices and maybe the routing of specific cables. These aspects will all be managed by the Soldier Integration Authority who will vet, assess and qualify the integration of all devices/sub-systems before they are allowed to be fitted to the soldier.

In addition users will not be encouraged to move devices themselves. They should get support from a local Maintainer before adding or changing any cables or devices. In reality users could adjust the location of a device already fitted, as long as they did not seek to disconnect the cable from the hub. The SHArc widget fixing the connector to the molle can be manipulated by a user to readjust the position locally. This may well be a useful feature when a maintainer is not available, as long as the user understands the relevant location constraints and the need to not stress cables.

SHarc also allows the user flexibility to step up their role, for example, by allowing the Section 2iC to attach Commander’s devices to the hub, and therefore, the user’s soldier system. This allows rapid adaptability, at the user level, to emerging scenarios, missions and events.

Flexibility - Unit level

In the traditional equipment procurement approach the Army defined, bought and integrated equipment in whole army-sized fleets. This approach has merits and may well be retained for some universal items which all users will find to be identical in whatever unit they may serve. However it is also very constraining. The procurement process is large, expensive and slow. It is a “one shot” process where users get no real opportunity to explore how to best operate with new capabilities and how to improve the way they are delivered in an incremental or “spiral” approach. Critically it also does not allow the Army to track with civilian technology update cycles and almost guarantees that many items will be years, if not decades, out of date – waiting for their next “Big Bang”, whole army, update.

A new procurement philosophy recognises these issues and operates by procuring relevant equipment in “tranches” which allows the opportunity to adopt user feedback and to incorporate technology advances. This does entail managing a mixed fleet of equipment across the Army, with all its attendant logistic and training issues, but the gains are seen to be clearly worth the effort. Indeed this is how civilian companies like Apple manage significantly larger fleets of phones, tablets, and computers.

Equipment allocations are now much more unit-specific. Different versions or types of equipment will be provided to different units, depending on their role and their location in the Readiness Cycle.

However, managing different equipment distributions across different Army units does pose a significant challenge. If those different items of equipment are also all to be integrated into a central Power & Data hub on each user then that challenge can easily become insuperable – unless that integration process can be done automatically using a mandated integration Standard (e.g. GSA 23-012) and an “intelligent hub” which can autonomously cater for new devices. Integration processes employing a “dumb hub” which needs to be modified/re-programmed (or whose controlling device needs such reprogramming) for every new device and/or device combination would rapidly spiral out of control when the range of possible devices starts to grow.

For the “mixed fleet” approach to Army equipment to work with an integrated Soldier System the central hub needs to be “intelligent” so that devices can be simply plugged in and they will immediately function in conjunction with the other devices present. Indeed managing a massive mixed fleet of devices across a widely distributed Army becomes a great deal simpler and less expensive if all such devices can be identified when plugged into a soldier hub and that data shared (in the background across the radio net) so that all active configurations can be tracked and logged.

With the mixed fleet approach different units conducting different missions can have their suite of equipment changed to best suit their needs. Units deploying to artic conditions may be issued with modified equipment (or batteries) designed for low temperature. Units on peace keeping deployments may be issued with additional Non-Governmental Organisation (NGO) communications equipment. Units operating from vehicles may be given additional modules to exchange data with those vehicles. The list is very extensive. The benefits from being able to operate in this manner are compelling; at user level, at Army level and at Treasury level. The ability to successfully reconfigure such equipment around units relies on being able to integrate it efficiently – and that does require an “intelligent hub” operating a GSA approach.

The light was beginning to fade as Lt Hackett and his platoon assembled near the front gate, waiting for the drivers to bring up the vehicles. They had already checked out of the Ops Room, and loaded weapons. They were ready to make what was now going to be a night move back to their patrol base.

“How was that, Dinger?”, Lt Hackett asked to his nearest soldier.

“Alright, Boss, I like the Helmet thing, not sure about the Health one, mind”, said Private Bell.
“What’s wrong with the Health one, is it uncomfortable”?

“No, just don’t want you, keeping an eye on my stress levels, I can see you now, on the radio all the time to me – ‘calm down Dinger’, keep going, the enemy machinegun is right in front of you!”, and with that they both burst out laughing.

“I think, Dinger,” said Lt Hackett, “I’m more likely to find out that your monging it because your heart isn’t hammering away!”, adding, “Don’t worry, I have better things to look at than your heart rate. Pretty cool stuff though”.

“Bit too much for me, Boss,” he said, getting his water bottle out, “What’s next? Will they be monitoring how much water I drink from my water bottle?”, and with that Private Bell took a long swig as their vehicles roared up behind them.

Flexibility - Dynamic changes

A further major benefit from utilising an “intelligent” GSA hub arises with the future need to rapidly change equipment on deployed troops. As situations unfold and new threats/opportunities emerge there will be requirements to rapidly deploy new/improved capabilities to units already in forward locations. Many examples of this were seen with UOR’s in recent conflicts, however in the future these equipments may have increasing digital capabilities whose reason for being rapidly deployed is because of the advantage they may give through the data they provide or use.

Where these dynamic changes are required the entire process is greatly simplified if – assuming the new devices are fully GSA compliant – the soldier systems are based on “intelligent hubs”.

The Thales SHArc showing the hub attached to two batteries, a tactical radio, and other connector points with other data enabled but currently unattached devices in a stored position.

The Thales SHArc showing the hub attached to two batteries, a tactical radio, and other connector points with other data enabled but currently unattached devices in a stored position.

An Integration Infrastructure – What Benefits?

It is not easy to measure or assess the level of benefit conferred by fitting users with an integration infrastructure – but only too easy to see the bulk, weight and power costs associated with deploying it. We live in an increasingly digitised age and all areas of our lives and activities are benefiting from an explosion in shared information; shopping, entertainment, business and travel to name just a very few. Soldiers should be expected to share in this, especially if we are going to continue to strive for ‘competitive advantage’ both on the battlefield and in our militaries as a whole on the world stage. There are numerous functions already identified where a transparent background data service can really benefit dismounted soldiers and we can confidently expect this range to expand as the commercial world proliferate more and more devices and capabilities. To exploit this it must be possible to readily connect these new devices to existing systems.

The Generic Soldier Architecture (GSA) provides a framework for integrating new devices in a fully controlled fashion with the minimum of additional bespoke integration development. Providing a common hub which supports GSA makes it very straightforward to modify existing systems, to swap out devices, and to add new devices. Currently any such changes entail a complex integration engineering exercise, typically requiring both hardware changes and software upgrades, often entangled with Intellectual Property (IP) issues. These exercises become increasingly more complex and expensive as the number and sophistication of the connected devices increases.

If the armed forces community really does envisage a future where dismounted users are to gain the full benefits of becoming Digitised Soldiers then it can only be done by investing in a suitable Integration Infrastructure to facilitate this – and one with adequate growth potential to cover short and medium term demands.

Thales logo For more information please visit:
www.thalesgroup.com


John Foley is a Thales Senior Expert in the field of Soldier Systems and has been active in this domain continuously since the NATO NIAG Sub-Group 48 Soldier Study in 1993-4. He subsequently led the UK industrial consortium (Pilkington, Racal & Royal Ordnance) which delivered the UK FIST Technology Demonstrator programme for DERA (1998-2000). He was Technical Director for the Thales Team which won and delivered the Cat-A FIST programme (2003-15), which included a comprehensive Main Gate submission on FIST-C4I and subsequently delivered the CLB (Casualty Locator Beacon) UOR which implemented many of its features. He is now fully involved in leading the development of a suite of Thales Soldier System products and in developing a Thales Soldier System Architecture Model which will be used to guide the definition of soldier-related activities and ensure coherence across Thales’s multi-national and multi-functional organisational structure.

Amyas Godfrey was the Thales Product Line Manager for Soldier Systems from 2014-2018. During this period he was involved in the concept, design and initial trials and experimentation of the new suite of Thales Soldier System products including the vision for a future Soldier System. He is a former British Army Infantry Officer with operational and training instructor experience and has now worked in the Land Defence area within Thales since 2009. Previously he was the Head of the UK Armed Forces Programme at RUSI where he conducted analysis and research into the operational, doctrinal, procurement and training performance of the British Military.

Upcoming Events
Contributors
SoldierMod eBook
Click here for SoldierMod FREE eBook
Other publications by Intercomms:
www.intercomms.net
www.emergencycomms.org