Soldier Systems: An Integration Challenge
Like No Other

John Foley & Amyas Godfrey

Download article as PDF

For many years people have talked about ‘Soldier Systems’ when referring to equipment for dismounted soldiers. However is the title ‘Soldier Systems’ in regard to how the equipment carried by a soldier interacts, a true statement? Is it a system? And if not true today can we ever deliver a true Soldier System that interacts and works like a system? Who is responsible for ensuring that the system, and its various elements, all work together as a system and deliver a desired capability? How does the military ensure that the future addition of capability does not have adverse impact on the system? Most importantly, who ensures that the system is there to serve the soldier’s needs and the soldier isn’t there just to carry the system?

With a wide product portfolio of Soldier Equipment, years of experience in delivering Soldier capability, and a ‘first principles’ design Thales UK now feel that they have got the right approach to delivering the Soldier System of the future. From concept to design, development and potential delivery this is an integration challenge unlike any other.

The Soldier System: A True System?

A system, to use one definition, is ‘a set of things working together as an interconnecting network, forming an integrated whole’. Most people would agree that the equipment carried by soldiers today does not currently work together ‘as an interconnecting network’ in and of themselves, except in small parts, but rather needs the ‘connection’ to be carried out by the soldier themselves. It is certainly a long way off from being considered an ‘integrated whole’.

Whilst you could argue that most modern militaries soldier equipment is physically integrated as a system (a rifle sight fits onto a picatinny rail) or tactically integrated (the magnification of the sight is appropriate to the range of the rifle) it is still largely true that the integration of information or data between items of equipment is done in the soldier’s brain. The arrival of Smart Phone-like End User Displays (EUDs) has started to take on some of this processing, but not in any real integrated manner. The brain is still largely the processor of the current Soldier System.

The Soldier Systems equipment market over the last twenty years reflects this. There are three types of equipment procurement, roughly sitting on a progressive timeline but with significant overlaps dependant on customer, they are; Equipment Procurement, C4ISR Procurement, and Capability Procurement, all of which have been and still are referred to sometimes as Soldier Systems.

Equipment procurement is the simple procurement of soldier equipment with, if well done, conscious ‘overarching and interlocking’ capabilities, procured in a systematic way which should increase capability beyond the sum of the parts when delivered together with training. Militaries have done this for the last 100 years and will continue to do so.

C4ISR Centric Procurement began to appear with advances in technology especially around mapping, EUDs, and communications. C4ISR focused procurements look to deliver better Situational Awareness (SA) and connectivity to the soldier. However all of the systems of this type delivered to date within this category have been ‘locked down’ systems and either do not allow additional capability to be added by third parties or are proprietary in their software applications. In this way they are not true ‘Soldier Systems’ but rather C4ISR or Dismounted Situational Awareness (DSA) Systems.

Increasingly we are also seeing the procurement of ‘packets of capability’, which may be an STA system, or a lethality package consisting of a few connected elements, or something else. But these ‘packets’ are still essentially Equipment centric and do not form part of an integrated whole, or Soldier System.

Initially referred to as Man-Worn Power and Data (MWPD), now more often called Soldier Worn Power and Data (SWPD) this concept of a true Soldier System allows the user in principle to share data from any connected device, utilise that data in Software Applications, share and manage power between the devices, and add/attach additional devices (3rd party or future) into the system. It is in effect the soldier’s equivalent of what we have come to expect in our homes and offices where devices, bought from different suppliers, can connect, share data and generally make multi-step processes easier.

Receiving an image by phone and then sending it to your printer is a good example of this where the communications bearer (4G), interconnection hardware (router), WiFi, phone, Apps and printer are supplied by different manufacturers. However, they all recognise the same software programmes (or interact with other programmes) and share data even when the image has been sent by someone with all those same element supplied by different and competing manufacturers/suppliers. Imagine a Soldier System that worked like that?

This type of system by its very nature requires an underlying architecture and is therefore ‘open’ in its intention, however the challenge of inserting that architecture into an existing soldier equipment plan that includes locked down C4ISR-centric equipment, a communications infrastructure, and additional stand-alone equipment capabilities at various stages of their life-cycles adds complexity to an already challenging problem.

Critically, the soldier themselves must remain at the heart of this system. All the other elements must integrate with them – physically and cognitively – in a manner which enhances all their natural attributes and adds the minimum of additional load.

Here is where the problem lies for Soldier Systems. The Soldier System needs to be fully integrated, from human to power and data harness, attached devices to central interface, and all to a communications bearer. A simple statement which conceals a very complex, interrelated, and to quote a DSTL scientist, “wickedly difficult” problem to solve. In fact, one might say that it is the integration itself which defines a true Soldier System, and that very challenge of integration is what has defined how Thales have approached our next generation Soldier Systems Capability. Thales UK have started to look at the Soldier System Integration issue from first principles, and understanding the difficulties of integration has led to our own distinct Product Design philosophy.

Thales Soldier Systems Product Design Philosophy

Thales globally produces a wide portfolio of Soldier equipment from communications products to night vision goggles, and data processing modules to rifles, which is in service across dozens of militaries worldwide.
Thales in the UK has also derived unique benefit from its position as Prime for the UK Army’s Future Integrated Soldier Technology (FIST) Soldier System, a Cat A programme running from 2003 to 2015. This early attempt to introduce a holistic Soldier System entailed wide-ranging analysis, trials and user consultation, along with close co-operation with DSTL OA (Operational Analysis) work. This experience gave real insight into the priorities for such a future system.

In developing our future Soldier Systems offer Thales has started with the end user, placing a high value on the soldier themselves, their experience and requirements. Thales has worked closely with former soldiers, Army Trials and Development Units, taken feedback from current users, and used operational analysis tools to better understand impact and use even before the first CAD drawing was attempted or prototype developed.

It has also led to an understanding that whilst a Soldier System can significantly improve most phases of combat including targeting, planning, approach, observation, support, and later the phases of reorganise and resupply, the phase that consists of ‘closing with and killing the enemy’ is still a very physical, personal activity. Therefore the technology that soldiers are required to carry to conduct all of the other phases with improved capability cannot hinder them physically, burden them cognitively or blind them situationally from understanding the immediate environment around them in the most dangerous phases.

Additionally – and during all phases – the extent to which a Soldier System needs to be intuitive to the user and not place significant cognitive burden on them cannot be overstated. Ideally the benefits of shared data should reduce any new cognitive load associated with managing or carrying an SWPD capability. The connection methods, power and App management, and general use of the capability should be completely intuitive and appropriate to the type of user who will be adopting it.

Lastly a Soldier System should also be easily maintainable. This is not only limited to replacement of cables, and the upgrade of connectors but should also mean easy access to upgrading and updating software and Apps as required including facilities for highly distributed fleet management.

Safety and security of the system are crucial elements but are not covered in this paper as they require quite a significant analysis and would warrant a paper all on their own.

Through a lengthy concept and design process and with all of the above in consideration Thales has adopted the following guiding principles for the development of our future Soldier Systems:

• Flexible – Flexibility of use is a critical feature in the design of soldier products. It is vital that all such products allow users to reconfigure and adapt them to match varying circumstances and individual needs.
• Scalable – the system must be able to scale up and down for different levels of command and user roles in order to maintain commonality throughout the fleet. The requirements of ‘step-up’, where a sub-ordinate takes command when the commander is wounded or killed, is particularly challenging.
• Low Cost – the cost of the system must be low at procurement and through life, including replacement of damaged elements, because the nature of the user’s role. The Whole Life Cost aspects of Thales soldier products are addressed from the outset, in terms of ensuring the products offer excellent reliability and maintainability and that significant product consumables (e.g. batteries) are open to competitive tendering.
• Low SWAP – the system must be as close to negligible in the addition of size and weight. The power it requires just to run should not be a reason in itself to carry more batteries.
• Intuitive and Appropriate – the system has to be as easy to use as possible so as to not increase burden or activity on the user. The Human-centric nature of soldier products lies at the heart of the Thales design process. The Human Factor (HF) implications are assessed and tested at each development stage.
• Maintainable – the system must be easily maintainable in order to allow upgrade and update of both hardware and software elements.
  

In order to address and develop each of these concept design principles, Thales has embarked on an approach that uses a spiral development methodology at its heart. Spiral development has two advantages which particularly suit the development of Soldier Systems. Firstly SWPD is a new area for the user and they are still developing their own understanding of requirements. Spiral Development will allow the user to test capability and derive requirements. Secondly, spiral development will allow us to include user feedback early on in the development cycle thereby maintaining a minimalist, light touch element to the capability and ensure that the system is intuitive and unobtrusive for the end user. The Army Warfighting Experimentation (AWE) programme run by the UK MoD and facilitated by the Infantry Trials and Development Unit (ITDU) has been very helpful in providing access to end users, realistic scenarios, and honest feedback.

Integration Issues

Whilst the Thales Soldier System has been designed with a core set of guiding principles, the System itself does not sit in isolation from the soldier or from other elements such as vehicles. It must be integrated into its environment, that of the dismounted soldier. The entire Soldier System, as Thales sees it, consists of a number of capability areas, which can be delivered individually or together. These capability areas include: Situational Awareness, Communication systems, Surveillance and Target Acquisition, Power Management, Weapon sub-systems, Vehicle Interfaces, and Data Usage and Accessibility.

Whilst technology evolution has now made many of these proposed capability enhancements viable individually the introduction of multiple and diverse, electronic devices brings its own integration challenges. There are, perhaps uniquely, a complex range of ‘Integration Issues‘ that arise in dealing with Soldier Systems. Some of these challenging issues are:

• Human Platform - No other area of System integration has a human as the platform. Whereas vehicles and ships as a fleet are all the same size, weight, and performance there is infinite variability in soldiers including both physical and cognitive characteristics.
• Diverse Range of Tasks - Whilst a vehicle or ship can be defined more easily by a role, a soldier may act differently within each role depending on task, operation, phase of operation, activity, theatre of operations or environment. Additionally, they may again act differently in any of these combinations based on command position. Highly complex and diverse Operational Analysis (OA) and user assessment is needed to capture the full extent of capability needed for a Soldier System to remain relevant against this staggering range of applications.
• Non-homogenous user groups - There is no “one size fits all”, even within a single Army. Dismounted users need the freedom to adapt their systems at local unit level to match the way they operate. Marines have different requirements from Artillery, as do Engineers from Infantry. Each may have a different way of carriage, or specific environmental requirements such as submersion, extreme cold, or ingress/egress from armoured vehicles, to name but a few.
• Platform within a Platform - A Soldier System needs to operate alongside and within other major platforms. They also need to be able to operate in isolation and not have a critical dependence on those platforms. The range of Platforms is very large so managing and optimising the Soldier System interfaces to all of them is a challenge, especially when those platforms are also evolving and may be variable within a platform fleet.

There is no such thing as ‘the right Soldier System configuration’ because of the sheer range of variety amongst the soldiers as platforms, tasks, operations, operating environments and interactions with other systems. Whatever is provided needs to be flexible with regards to the location of devices around the user. This includes load carriage that allows re-position of items with an inherent cabling or connecting approach that lets users share power and data with devices which are re-located both on a day-to-day basis as well as being able to be radically reconfigured to meet specialised and emerging needs.

Flexibility is as much true of the software as it is for the hardware. Software used to access, process and share the data around all the connected devices, and to cater for new devices when they are attached, must be ‘open’ or flexible. The use of suitable MiddleWare (MW) appears to be the optimal approach to achieve a solution that offers this, but the precise definition of all the relevant performance parameters and requirements for that MW is a complex task. This MW definition has very significant implications for downstream system integrity (e.g. safety and security compliance) and needs to carefully considered before any system is brought into service.

Every aspect of integration points to a paramount need for the Soldier System to be flexible. This cannot be stressed enough and an inflexible Soldier System is a costly, temporary solution, for limited users, conducting a limited range of tasks.

Soldier Integration Diagram

“If you can’t draw it then you don’t understand it”.

An often quoted aphorism, none-the-less, whilst difficult, it is a worthwhile activity. The diagram shown in Fig 1 is an attempt to capture the entirety of Soldier Systems Integration in a single view. In particular it seeks to provide a basis for identifying and managing all of the key interface relationships.

Figure 1: Thales Soldier Integration Diagram (T-SID) (click image to enlarge)

A good diagram should not need a lot of explanation however here are some guidelines about the Key Elements of the Thales Soldier Integration Diagram (T-SID):

• Soldier - The model builds on the “naked soldier” – who has a host of attributes, some fixed and some dynamic. Selection and training are the two major activities that operate at this level.
• Load Carriage & Protection - The soldier is fitted with a layer which contains all the clothing, protection and load carriage items.
  • These have a “is fitted to” interface relationship with the soldier (blue arrow – services and fit).
  • “Protection” encompasses the range of threats (environment, ballistic, blast, etc) but in this model only includes passive elements which have no power or data needs. So it would include, for example, foam ear plugs but not protective audio headsets.
    
  • There are few “services” between soldier and this layer. User adjustments of load carriage fittings might be one example. One question that arises is: ‘Does the imposition of load onto the user also count as a “service” across this interface, from the load carriage to the user?’
    
• Independent Elements - ‘Independent Elements’ are items and devices attached to the soldier load carriage but not electrically or electronically integrated to it (i.e. not “e-devices”). Some of these are illustrated in Figure 1.
  • Independent devices do not interact directly with each other. They are all independent for power, data and if applicable, the user interface. If they are interconnected via some form of hub – so that they share power and/or data – then that hub is functioning as a limited form of “Power & Data Harness” and needs to be represented under that part of the model (and they all become “e-devices”).
  • The “Independent class” of devices includes inherently “dumb” items such as food, water, ammunition etc., as well as powered devices which contain their own batteries and do not exchange data directly with other devices. This latter set may transition to becoming integrated “e-Devices” in future systems (and are marked with an * in the diagram).
    
  • Devices which exchange data wirelessly with other co-located devices (e.g. via Bluetooth or similar) would still be classed as “e-Devices”. The interconnection does not need to be wired.
    
  • Historically all of the devices on a soldier were independent. If they consumed power they had their own internal batteries and data input/output required manual user interaction. Where appropriate, some of these are now migrating to being inter-connected and are becoming “e-Devices” (see below).
    
• Power & Data Harness:
  • “e-Devices” on the soldier are those which do share power and/or data with each other.
  • The management of “e-Devices” in a coherent fashion around the soldier requires the introduction of some form of power/data harness. This provides the infrastructure for sharing power and/or data between all the e-Devices. This might offer just centralised power, it might offer both power & data or it might even offer just shared data (e.g. over a wireless net).
  • The introduction of this form of Soldier Worn Power & Data (SWPD) layer is now underway on several national programmes.
  • The SWPD layer defines the interfaces for current and future e-Devices and its correct definition is critical in ensuring that the system remains suitable for future needs as well as current e-Devices.
  • It is vital that the design of the SWPD layer offers all the flexibility that soldier systems require. It is unacceptable that the introduction of this layer should also seek to constrain where and how users can fit e-Devices about their bodies.
  • This SWPD layer is an additional load on an already overburdened soldier so there are severe constraints on the size, weight and power required to implement it and these must be balanced at user level against the benefits it confers.
  • The infrastructure needed to link a small, pre-defined set of e-Devices can be achieved using fixed or “dumb” hub which is designed to cater for just those specific devices, but offers no growth. The infrastructure to cater for a wider range of non-specific and future devices needs the hub to be “smart” so that it can be adapted to cater for the power and data exchanges with new devices and new classes of devices. This can also include the ability to host complete sub-systems (e.g. weapon or head sub-system).
  • The benefits conferred by the SWPD layer can be calculated in terms of enhanced user power management (fewer batteries), enhanced logistics, simpler and more reliable integration of data devices and ease of future device upgrades. That is a topic which is not expanded on here since it requires a whole paper in its own right.
  • Issues with evolving to an SWPD layer, such as the introduction of a single point of failure, can be addressed in the detail of the SWPD architecture.
    
• e-Devices & Sub-Systems:
  
  • There is a steadily increasing range of soldier devices and sub-systems which consume power and which import/export data. Some of these are illustrated in Figure 1.
  • There is a growing imperative to connect these via some form of SWPD layer to derive the benefits of shared power and data.
  • The obvious current e-Device candidates would be data radios, control/display devices (e.g smartphone), GPS sensors etc. These can also be expected to be joined by other environmental sensors and user Health & User Monitoring Sensors (HUMS).
  • Next Generation head and weapon sub-systems will also become complete e-SubSystems in their own right, operating independently (if required) but also exchanging power and data with the torso-based SWPD layer when connected.
  • Just as Internet Of Things (IoT) has spawned a host of new possibilities the same can be expected with Soldier System e-Devices. This will only fully develop, however, where the SWPD layer is genuinely “open” for 3rd party devices to be integrated.
    
• Soldier System Level:
  • This ensemble comprising the soldier; load carriage & protection; independent devices; the SWPD layer and the e-Devices represent the actual “Soldier System” at an individual level.
  • This is the level at which the overarching “Soldier Platform Authority” has to impose the strict constraints on total load, bulk and location, training burden, cognitive load etc in order to ensure the central soldier remains fully functional, unimpaired and viable.
  • This is also the level at which the Soldier System can be defined, individually and collectively, for analysis of overall Capability.
  • It is also at this level that a “Soldier System Integrator role” is needed in order to ensure that the SWPD layer and associated e-Devices are properly integrated and function coherently. Issues such as collective EMC (which may include Independent devices) need to be addressed at this level.
  • Installing an “open” SWPD layer does not, on its own, guarantee that the collective system will function as expected when new devices are introduced. Even when all the devices are compliant with common system interface standards there can be ‘unexpected emergent features’ There is a need for an on-going System Integrator Role to ensure that System Integrity is maintained especially in relation to safety and security concerns.
  • The System Integrator role also needs to be a through-life function so that the impact of degradation of system elements can be managed. This is especially important in the Soldier System domain where natural usage will impose severe mechanical strain on user worn elements.
• Integration to Platform & External Systems:
  • The Soldier System representation shown in Figure 1 can also be used to identify and assess all the interface implications with external platforms and systems. Doing this analysis at each of the layers in the diagram will help to separate the specific responsibilities for each aspect of interface management, so these can then be allocated as requirements to the right devices or sub-systems.
  • Interfaces to vehicles, for example, need to be analysed at each level:
  • Soldier level addresses basic human issues (seat size, noise levels etc)
  • Load Carriage & Protection level also addresses sizing for seats and ingress/egress along with stowage demands.
  • Independent devices add to sizing and stowage impacts and potential EMC concerns.
    
    • The SWPD layer interface primarily addresses vehicle power and data exchanges.
      
    • The e-Devices layer again poses sizing, EMC and stowage concerns as well as potential data exchange needs.
      
  • This analysis at each Soldier layer can be done for each different type of platform or external system. The whole range of interface requirements between Soldier Systems and all of the Platforms/External Systems can then be identified, grouped and managed.
  • The use of this Soldier Integration Diagram (SID) can assist in the visualisation and tracking of the vast array of combinations of potential external interface requirements in a manner that spreadsheets or similar formats are not well suited to.
• Integration to Logistic & Support Systems:
  • The final interface tracked in the diagram in Figure 1 is for Logistics and Support. This is critically important and is a key driver for both operational outcomes and Whole Life Costs.
  • With extensive usage of e-Devices to provide both HUMS (user and system) and to track consumable status the whole support and re-supply process can become more proactive, efficient and cost-effective.
  • This approach will reduce the user’s physical burden when re-supply is more reliable. The cognitive burden can be reduced when the task of tracking consumables and requesting re-supply is more automated and indeed more predictive.
  • System reliability will be enhanced by the use of HUMS for preventative maintenance.

How does this diagram help and what practical use is it?

In the development of the Thales Soldier System it has proved to be an invaluable gauge against which we can measure and test assumptions, product design (including understanding what is ‘good enough’), and ensure that the role and function of the soldier remains at the heart of the development of Soldier Systems. It provides a single overview of the whole of Soldier Systems, its relationships with other platforms and systems, and with the external world. As a visual adjunct to the ITDU Soldier Reference centre’s physical representation, the SID can provide a means for tracking the vast array of future variations and combinations.

When fully populated it can show where every item or sub-system fits within the overall soldier system and what relationships it may have. For specific discussions it only needs to be populated with the items of interest – for which it provides a single common view for all parties. For example if discussing integration with the external Morpheus system, only those devices and elements which have some potential impact on that relationship would be shown in that version of the diagram. In this way it is a flexible ‘aide memoir’ to help test multiple soldier equipment issues.

This diagram also provides a common understanding for multiple suppliers. For successful integration management and interfaces it is critical that all parties share a single common view of the problem space. This diagram, therefore, provides a means to capture that in a way which allows it to show the full context for each relationship.

The Soldier System Integrator

One of the most important aspects that is fully brought out in the construction of this type of integration diagram – and in any significant critical thinking about the future of Soldier Systems – is the absolute importance of both the ‘Platform Authority’ and the Soldier System Integrator role that are needed to manage the complex relationships between system elements and external systems.

The Soldier Platform Authority role is required to both determine the optimum capability mix that needs to be delivered by the Soldier System and to police the necessary constraints that protect that platform. No single combination of equipment, devices and sub-systems can meet all soldier-related capability needs. There has to be a range of elements which can be integrated onto both individuals and teams of users in different combinations in order to meet the wide range of varying demands on that system.

It is important that limits be imposed, and policed, in order to ensure that the capability being sought is not compromised and that neither the platform nor the user is impeded or harmed by any form of system overload.

It is now widely accepted that future systems need to offer “open” interfaces so that 3rd party devices can be designed to integrate easily. This is a ‘necessary but insufficient’ condition. On its own, the definition of a suitable set of well-defined interfaces (for example in some form of Generic Soldier Architecture) will not ensure that all systems constructed with compliant elements will function correctly under all relevant conditions.

‘Openess’ is a broad term that can be subject to many interpretations. There will be a learning curve as “Open Soldier Systems” evolve regarding exactly what features have to be defined in the open standards, and to what level of detail. During this period there will inevitably be a series of incompatibility issues to be resolved, so some form of technical System Integrator will be needed required who is in a position to resolve these issues and to ensure that the systems remain functional.

Even when the “openness” aspects are matured, there will always be a need for the existence of someone with responsibility for the Soldier System’s Integrity. Even the most well-designed of systems can exhibit unexpected, emergent properties as additional elements are added and different combinations evolved. Some form of enduring System Integrator role will be needed to take responsibility for managing System Integrity, especially in relation to security and safety concerns. The requirement for this role needs to be factored into the Soldier System procurement process from the outset and should form part of the down-selection decision for any future Soldier System.

CONCLUSION

For a Soldier System to be adopted today it must be minimalistic; dismounted users have enough to carry. It must be financially minimalistic as military procurement and Through Life budgets are invariably constrained, especially at the dismounted soldier level when most money is going to high-end platforms. The System must also be flexible otherwise it will have no application to the infinitely flexible roles and activities of the Soldier themselves.

The art of “Soldier System Engineering” is to recognise that which is absolutely needed for any given set of users and to ensure they can be given just that, whilst being flexible enough to allow future changes as well as being the most cost-effective (where “cost” covers weight, power, bulk, cognitive load, as well as finance).

Understanding the context and application of capabilities into an open system also requires some form of management best fulfilled by a System Integrator role. This role ensures the required capabilities are still being achieved throughout an ever-evolving programme whilst ensuring that both safety and security are not compromised.

For more information 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.