PLM in Defence Industry – Customer Requirements – Part 2

Introduction

In the recently published paper, PLM in Defence Part 1, Eurostep published a list of 15 requirements to be used in the selection of an information system to manage Product Life Cycle Data in the Defence industry. The 15 requirements were grouped into Business Drivers, Technical drivers and finally Security drivers.

In this paper, PLM in Defence Part 2, the reasons for each requirement identified in Part 1 are given. In most cases it will not be a complete list but hopefully sufficient to indicate why the requirement was identified. The section is intended to back up the core logic provided above which was kept deliberately brief. The reader is forewarned that there is some overlap between the sections given below as the same reasoning can lead to more than one of the identified requirements.

REQ-001: The collection of comprehensive records related to defence systems is necessary

Major defence systems and equipment can be characterized as follows:

• Often complex and sophisticated
• Subject to harsh treatment and conditions
• Subject to ongoing change (updates, resetting, configuration for role)
• Needed at short notice and must be reliable over time
• Expensive and a significant investment
• Long (and getting longer) lifetimes
• Built from components with limited lifetimes
• Operated by highly trained personnel

Essentially defence systems are major purchasing decisions for Governments and therefore have to deliver value each and every time they are called upon. This means that maintenance has to be undertaken and the state of systems known (including readiness and anticipated available life). While there is always risk associated with the use of defence systems in operations, the risk of failure during training and peacetime has to be minimized, especially where operator and civilian safety may be impacted. Defence organizations seek to maximize availability and minimize risk while at the same time keeping costs low. This combination of pressures can only be met by managed processes which require information on both the type and individual level¹. The traditional approach of NATO using NATO stock numbers and form-fit-function equivalence fails to allow for varying supplier manufacturing quality issues and the impact of different use. Thus it becomes appropriate to manage at the level of the individual. Current IT applications can handle the detail, especially when combined with marking systems such as GUID.

¹ Type level refers to the designed system, such as a class of ship or a model of a land vehicle, while individuals are the specific ship or land vehicle or engine within a ship or land vehicle. An example would be the Incheon class of frigates with individuals “ROKS INCHEON” and “ROKS GYEONGGI”.

REQ-002: Defence must consider itself as a provider of information to the industry which may be represented by a collection of partnering companies

The major users of defence systems concluded in the 1970s that the delivery of defence systems should be accompanied by the information needed for its maintenance (and established standards to achieve this aim: USA Mil-Std 1388, UK DEF STAN 00-60, etc.). This was based on a complete transfer of responsibility for the delivered systems from the manufacturer (OEM) to the Defence organization. The OEM then provided spare parts but maintenance was performed by military personnel. This maintained a very clear divide between Industry and the Military. However, in many countries, the increased sophistication of defence systems and the pressures to reduce costs have led to much greater industrial involvement post-delivery of the systems to the military. Some maintenance operations will be performed by the military, especially in operational and war-time scenarios but in many cases, maintenance is being performed by industry while the usage is controlled by the Defence organization. Where responsibility is shared it is necessary to have either common access to the relevant records or information moving between Industry and the Defence Organization. This is accentuated where the Defence system comprises a combination of systems from multiple OEMs, such as ships with control, radar and weapon systems coming from different suppliers and where it makes sense to involve multiple companies in the support of the ship through-life.

We note that some National Defence organizations with a long history of taking over the full maintenance of systems find the need to provide information to the Industry to be a cultural and contractual challenge. This translates into a risk for industry which is then reflected in the price charged.

REQ-003: Approaches for sharing information between Defence and Industry must be flexible to allow for different contract types and KPIs

The different styles of contracting for industrial involvement in the through-life support of defence systems are referred to as Contractor Logistic Support or Performance Based Logistics. There are a set of different levels which are presented as a “Transformation Staircase” as shown in the figure below (taken from the UK Defence Industrial Strategy – Defence White Paper, 2005[5]).

At the top end of the transformation staircase, the supplier of support (often but not always the OEM) is paid according to measures of achieved availability or delivered capability (such as hours flown or days at sea). These key performance indicators (KPIs) can be influenced by many factors and are often calculated using a collection of different related measures. The appropriate measures vary between system types and between contracts. Typically, they depend on data provided by both the Defence organization and the support supplier. The measures can be varied over time and in different situations (peace versus active missions).

REQ-004: Product information must deal with individual items as well as types of items and maintain the relationship between individuals and their associated designs and other data (such as Technical Publications)

The reasons for handling information at both the “Type” and “Individual” levels have been introduced previously. Change is a fact of life for defence systems. The reasons for change include obsolescence, changes in role, upgrades, re-setting and introduction of new capabilities. Similarly, individual systems are often configured for different roles. The changes apply to the product, its related spares, facilities and equipment as well as the different related information sets (such as maintenance and repair documentation, operator and maintainer training, spares and initial procurement lists, etc.). However, the related information is often held in different repositories developed in disconnected IT systems and stored in different formats and media. Hence change has to be managed across a broad information set as well as the physical items. This can only be achieved if the relationships are held and managed that enable the impact of change to be assessed.

REQ-005: Product information must deal with locations and the actors (people or organizations) with responsibility for individual items and designs

Defence systems are often moved and also go in and out of storage depending on threat levels, etc. They are then taken on operations and over time mixed with other generations of the same product. Different parts of the Defence Organization (such as the Navy and Air Forces) often have common equipment and it is not uncommon for spares to be pooled and items transferred between parts. In the simplest case, the people’s requirement stems from the need to know who to investigate after something has gone wrong. However, the need also comes from legislation and regulation, especially in Air domains where the qualifications of maintainers and operators must be known.

REQ-006: Minimize lock-in to commercial/proprietary systems

In its simplest, there are three main reasons for this requirement:

• New applications will come into being that provide better approaches to the management of Defence systems;
• Software becomes obsolescent as the hardware it runs on does the same or its supplier ceases support for older versions;
• There is a considerable investment made to collect data over time and that investment is at risk if the data cannot be extracted.

Avoiding lock-in is the first step in a two-stage risk management strategy. The second stage follows below.

REQ-007: Maximize the use of standards and other means to render information independent from applications

Defence systems can have life spans in excess of 30 years. During that kind of period, the IT applications and the operating systems on which they run will go through several generations. It is unusual to find software more than 10 years old which is still supported, let alone the hardware and media. Thus standards are a means to provide to extract the data in a well-defined structure where that structure will have greater stability over time than those used by proprietary or bespoke applications. The LOTAR (LOng Term Archiving and Retrieval) activities are a good example of this strategy being applied on an Industry level.

There are of course provisos and further refinements applicable to the use of standards. The standards used should encode information in a manner that makes processing content possible.

REQ-008: Plan for a heterogeneous IT environment

At the time of writing in our opinion, there is no single application system providing the functionality required to manage the complete life cycle of Defence Systems. The split between (and increasing competition where they overlap) the PLM, ERP and MRO vendors provides ample evidence of this. Thus the use of a single system is not realistic. Furthermore, the different OEMs and Logistics providers that need to interact with a Defence organization will have made their own choices of systems to suit their own business needs (which are not the same as a Defence organization!). Therefore, there will be different applications being used.

REQ-009: Enable tracking of changes to design and to product individual configurations

The need to maintain the capability of Defence systems in a world of continuously developing threats results in many design changes which are then implemented on existing systems (unlike the consumer world where such change is implemented in the next generation product). Thus Defence systems are often subject to change via maintenance changes, major overhauls or resetting2. After changes have been applied, the provision of the correct spares, maintenance and related information is all dependent on knowing what the system actually is (i.e. which changes have been applied).

2 Here “resetting” is the process of sending a system back to the OEM for a complete update. The system is usually returned as the same individual but with radically changed design data (and therefore different supporting information, maintenance requirements, etc.

Many defence systems have the potential to be configured for different roles, tasks and environments. The changes may involve life components and may also impact the lives of components that are not changed in such configurations. Thus tracking of configuration at the individual level is needed. This is especially the case where the number of delivered systems is small and so statistical approaches are of limited value.

REQ-010: Enable traceability from requirements through into all aspects of product information

Defence systems are typically developed using systems engineering approaches that are initiated with well-defined and structured requirements. The ability to specify such requirements in a disciplined and

comprehensive manner is critical for the success of any major defence acquisition program. Historically any link to those requirements was maintained in the head of the designer. However, approaches (and supporting standards) now allow the tracing of relationships from requirements into designs (and even into individual defence systems to be preserved. This allows proposed changes to be assessed against the original requirements and the impact of changing requirements to be assessed. The effective management of such requirements and their tracing is crucial.

REQ-011: Wherever practicable, prefer information sharing to information exchange

The use of data exchange can be effective where a snapshot of information being moved between applications (and/or organizations) is all that is required. However, for Defence systems, this is rarely the case and any approach to information management across applications (and/or organizations) has to allow for change. Few systems are capable of handling just the differences (“deltas”) so change also means repeated exchanges. Indeed, it can be simpler for the sender to send more information rather than just those elements that have been updated. This of course places the onus on the recipient to sort it out. This can be made more complex by further exchanges internal to the recipient, again making the management of changes/updates a challenge. Once more than two parties are involved (with overlapping information needs) the situation is less well served by exchange-based processes.

The principal advantage of a sharing approach is that it leads to a common reference data set between the applications (and/or organizations). There is one place to put the information and one place to go to get it. A second advantage is that the recipient pulls the data into its applications under its own control and in the manner of its choosing. The content and granularity of imports are not determined by the sender (now better seen as the provider) of the new information. Such imports can be made to fit cleanly with the recipient’s business processes. Sharing approaches also scale well with multiple parties. Access and rights to the common reference data set ensure that parties have visibility of their data without any one party having to manage different (but largely duplicate) exchange streams.

Other advantages of sharing are that it is easier to maintain an effective audit trail and the responsibilities on each party are clear.

Security Requirements REQ-012/013/014/015

It makes sense to provide additional reasoning for the remaining requirements together. They are:

• REQ-012: Minimise external usage of Defence IT systems
• REQ-013: Use IT systems that have flexible security control related to content as well as
• network and system-level access
• REQ-014: Fine-grained control over access to information is needed
• REQ-015: User Identity has to be managed effectively

All Defence organizations now perceive Information security aspects as a new battlefront. Defence Organizations, OEMs, Support organizations and their supply chains are all facing continuous and varying cyber security threats.

A common response to the need to provide access to information is to allow or require those needing access to use the existing IT Applications. This is what is meant by external usage. This carries multiple risks: the system may allow access to more than was intended, the user may not be who he claims to be, and access to the system may provide a route to introduce other threats. Furthermore, external access relies on being able to trust the organization controlling the use of that access and their user identity management.

It is clear that major defence companies are increasingly moving to approaches that restrict and minimize the number of external people with access to internal systems. One such approach is the use of an explicit sharing hub or platform. Such a hub immediately prevents access to more than intended and reduces the ability to introduce threats into internal systems.

References

Abbreviations, Terms, and Definitions

CLS – Contractor Logistic Support (also known as Performance Based Logistics in the USA).

ERP – Enterprise Resource Planning (as characterized by IT systems such as SAP and Oracle).

ITAR – International Traffic in Arms (a set of US Government regulations governing both Arms and the information describing those Arms).

KPI – Key Performance Indicator (a measure used to determine performance which often determines levels of payment).

PBL – Performance Based Logistics (also known as Contractor Logistic Support).

PLCS – Product Lifecycle Support is the Application Protocol AP 239 of the ISO 10303 Standard for the exchange of product model data. PLCS is in effect an information model for the complete lifecycle of complex products.

PLM – Product Lifecycle Management.

TSCP – Transglobal Secure Collaboration Program.