ANTI-MISSILE DEFENCE FOR EUROPE (III)
Rome, 20th-21st April 1993
ASSEMBLY OF WESTERN EUROPEAN UNION
ANTI-MISSILE DEFENCE FOR EUROPE (III)
Rome, 20th-21st April 1993
Office of the Clerk of the Assembly of WEU
Wednesday, 21st April 1993
Conditions for a European anti-missile defence policy
(Copyright 1993 by C.J. Rhodes)
Mr. FOXWELL (Ferranti International System Integration, United Kingdom).
For the foreseeable future a growing emphasis will be placed upon the need to address out-of-area operations and limited threats from a number of sources including tactical ballistic missiles. Central to this need will be the achievement of an interoperable multinational TMD C3I infrastructure. Recent work, in developing methods for the testing of interoperability within systems, has suggested ways of developing the concepts of the ISO/OSI 7 layer model into a profile or system model capable of describing system interoperability and development requirements. Making extensive use of modern analysis and development techniques such as object oriented analysis (OOA) and development (OOD), the approach also reflects modern management techniques notably those developed for total quality management (TQM). 2. Introduction
With the dismantling of the Soviet Union and the formation of the Commonwealth of Independent States, the traditionally accepted threat to the West has declined and is now of less direct relevance to the way that defence operations should be managed, although the fundamental principles remain unchanged. Under these conditions it is reasonable for national and international defence strategy to address a more ill-defined threat than previously, rather than a specific axis. For this and other well-documented reasons, a complete reappraisal of western defence needs is evolving and for the foreseeable future a growing emphasis will probably be placed upon theatre missile defence (TMD), including ballistic missile defence (BMD). This reflects the proliferation of ballistic missiles and the possibility of limited missile strikes from a variety of sources. In addition, such weapons can also represent a serious threat to out-of-area operations. It also recognises the increasing availability and affordability of TMD and BMD systems and the fact that deterrence alone is unlikely to be effective against much of the modern ballistic missile threat. Additionally, new and possibly radical uses for platforms may be found, such as the use of naval vessels as BMD units. This changing perspective is typified by the change in emphasis of the United States SDI programme from esoteric space weapons and platforms to the global protection against limited strikes (GPALS) programme.
Although it is too early to define precisely what the requirements of such programmes and developments will be, they will clearly be reliant upon robust and sophisticated C3I infrastructures. These can be more accurately described as "super-systems" made up of a number of autonomous systems reliant upon the achievement of interoperability for their successful integration. To help avoid costly rectification programmes, assessment of these interoperability needs is required at the beginning of the development life-cycle. Once identified, these needs should form an integral part of the system requirement specification.
In 1983 the International Organisation for Standardisation (ISO) published a reference model for describing data communications architectures. This has subsequently been redrafted as CCITT X.200, more generally known as the open system interconnection (OSI) layer model. The advances in technology and use of communications systems and the need to address problems associated with the achievement of interoperability within super-systems is now widely recognised. The adoption by many authorities of the concepts of the ISO/OSI 7 layer model to help address similar problems is a reflection of a common need. The purpose of this paper is to examine how these concepts may be applied to assist in establishing integrated super- systems, such as those required to support TMD, by recognising, and hence addressing at an early stage in the development cycle, such a system's interoperability needs. It considers the problems confronting the specifiers and developers of new systems, the importance of interoperability and the means for developing models of proposed systems to ensure that user requirements are fully understood and ultimately reflected in a detailed design specification. 3. Background
It is an unfortunate fact that new systems, particularly large distributed ones, have invariably been either late, over budget or did not perform. Although there have been many reasons for this the most usual were:
- the user needs were not understood;
- ever-increasing complexity of systems;
- the systems were inflexible to changing requirements; - a lack of traceability from customer to developer;
- unrealistic or increased expectations.
Within the new environment described earlier, this is a situation that is likely to deteriorate further unless appropriate remedial action is taken.
Because changing requirements (i.e. in response to a changing political environment) are to be expected, it is becoming recognised that the specification of new systems cannot be fixed at their inception in the form that is currently accepted. This is particularly true of systems requiring an extended (e.g. more than 3 years) development cycle.
Our perception, therefore, of what constitutes a completed system will require modification. For example, large integrated systems such as conceived for GPALS will, probably, never be completed in the accepted sense. Rather they will continue to evolve in capability as defence needs likewise evolve and change. This evolution will be such that systems entering service could in time possess none of their original component sub-systems.
However, cost estimates for new systems or for modifications to existing systems often have to be made before a full understanding of system requirements is obtained.
There exists, therefore, a conflict between addressing changing system requirements and the need to estimate acquisition costs well in advance of system development and procurement. Such conflicts can be resolved through the use of "cost-plus" contracts. However, these can and have sometimes been used as an excuse to develop ever more complex systems, irrespective of whether such a need existed. Alternatively, fixed-price contracts can address the problem by the use of "change-engineering" instructions. However, both these solutions, and particularly the latter, are still reliant upon the availability of funding set aside on the basis that such changes were predicted during the original cost estimating. Experience has shown that such funding has invariably underestimated the requirement.
To resolve the conflict of frequent change within a strict budget there is a need to develop a procurement strategy based upon the concept of evolving system capability rather than "one- off" acquisition. Such an approach need not require the development of "new" sub-systems, but whenever possible the integration of existing systems. Obtaining the maximum utility from what already exists, procuring proven sub-systems when required and developing "new" only after these alternatives have been explored offers the potential of true cost-effective system procurement. This approach provides the potential for maximum benefit with minimum cost and performance risk to supplier and customer alike.
Nevertheless, the evolutionary approach is still not without risk. It can increase severely the risk of ambiguities appearing in requirements, of systems having only rudimentary capabilities and of development costs continuing to run out of control. Containing these risks requires a shift in emphasis when carrying out requirement analysis and in particular system design. It is no longer acceptable to carry out such analysis only on the basis of known technology. Rather it is necessary to determine a system framework that can support long-term and undefined needs whilst at the same time providing the capability for absorbing new requirements and technologies as they arise. If such an approach is to be successful it must necessarily address interoperability issues at the outset. Failure to make such provision will inevitably lead to major over-runs in both costs and in-service dates.
The most fundamental of the changes required to our current mode of working is to make the development process more user accessible. At present, once an initial statement of requirement has been made, the customer can be effectively isolated from the development process. Any interim documentation presented for his approval can be incomprehensible to him and protected by complex contractual conditions. Once the means for basic communication between the customer and supplier is lost then the opportunity for developing a satisfactory system is likewise lost.
Important though greater user awareness is, so too is the provision of improved communication of the user need to the system developers. As the user perception of his requirement is usually expressed in functional terms (i.e. what service the system is to provide) whilst the engineer's perception is in object terms (i.e. what is required to provide the service), a simple translation of the two perspectives is required.
To take advantage of changes in technology and to enable rapid response to changing needs, new systems require to be based upon an open system architecture. Where possible such an architecture should take full advantage of available international standards.
To help ensure maximum cost-benefit, greater emphasis needs to be placed upon the determination of priorities, both operational and technological, and regular reviews of these priorities should become a major feature of the system development process.
Recognition of these problems in achieving system
integration and the need for practical solutions has led directly to the approach offered in this paper.
For many years, there has been a tendency for large-scale distributed systems to be conceived and built as an amalgamation of a number of smaller systems. Such "systems of systems" appear to be merely extensions of the normal engineering situation where most systems are usually composed of a number of sub-systems which can often operate independently to perform a complete function of some sort and so be properly defined as smaller systems in their own right. Given this, why do the large "systems of systems" or "super-systems" seem to produce a disproportionate number of problems when compared to their smaller counterparts? One of the main reasons is that in unitary systems the component sub-systems are chosen to fit into the overall design. With super-systems, however, we often have the situation where the component systems are already in place, and may be performing their specific design functions quite adequately, so that the designer has no real choice over the main components of his super-system.
Another characteristic of super-systems is that the component systems have often been procured by different agencies and at different times and, even when intended for the same type of operation, often work in quite dissimilar ways.
The problem in evolving the super-system is how to integrate component systems so that they work as a combined whole, and in our new world of change how this can be maintained as new requirements are identified. The answer lies in achieving and maintaining interoperability between them and experience, much of it in military systems, is that this has very rarely been as successful as intended.
The increasing size, power and complexity of super-systems, as proposed for GPALS, is such that complete comprehension of these systems is probably beyond the intellectual capability of any one individual to understand. If this is so, then it is difficult to see how such systems can be specified without a careful analysis of the operational requirement (what do we want to do and what information do we need to do it?), and its subsequent breakdown into smaller and understandable "problem domains". That this was true before the need to provide the flexibility required to respond to frequent changes in requirement serves to stress the problems now faced by system specifiers, analysts and developers.
Operational needs, whether fixed or evolving, are, in human terms, functionally oriented, whilst the equipment required to satisfy them is object oriented. The need to translate evolving functional needs into evolving object specifications without losing sight of the original operational concept indentifies yet another problem that must be overcome if system interoperability is to be fully addressed. A two-tier analysis is proposed; the first a functional analysis of user requirements, the second an object oriented analysis of the system required to satisfy the former. The result of this analysis is a model that unambiguously translates the user needs, both current and projected, into a system specification capable of being adapted to meet evolving needs.
Command and control
Command and control can be summarised by the information, decision, action (IDA) cycle (Figure 1a) which is based upon the standard management decision cycle of discover, choose, and act. In this cycle, actions are determined by decisions based upon available information, the results of which are used to update the information available for subsequent decision-making. Figure 1a
Operationally, the C3I infrastructure supporting super- systems mirrors this cycle by performing tasks of the type illustrated in the generic command cycle shown in Figure 1b. Figure 1b
To perform any given operation it is necessary to have a clear understanding or picture of the current situation. By assessing this situation and taking into account any existing rules or policy, an appropriate response can be made. This response will generally fall into one of two categories: immediate action, or a plan for future action which will provide the direction for those implementing the response. The results of implementing the response will then be combined with additional information from other sources and historical or other information, such as resource availability held in a database, to provide a new situation picture, which in turn will be reassessed. However, for this cycle to function correctly, the information content and flow must support the operation required and be free of ambiguities. Irrelevant information will not only place an unnecessary load on the system, but it will also increase the risk of introducing ambiguities and chance confusion to operators and decision-makers.
The need to reduce the level of information to only that needed to specifically support a particular operational need is fundamental. However, as described earlier, super-systems will be required to evolve and with this evolution the level of information available and required must be expected to increase. With time, therefore, the level of information required for effective decision-making will become greater than can be interpreted correctly by human operaters. This situation could be mitigated by the use of knowledge based systems (KBS) and artificial intelligence (AI). It is to be hoped that current research into these technologies will be sufficiently mature by that time to make their use a practical proposition.
Extended air defence
The command cycle described above, however, hides the complex system structure required to support such an activity.
Figure 2 shows a stylised representation of a possible extended air defence (EAD) super-system to support operations of the type described earlier. The figure shows three operational levels, strategic, force tactical and tactical:
Strategic (light grey) is represented by the Joint Operations Centre (JOC) command information system (CIS). This system has a number of local area networks (LAN) and associated data storage, management and retrieval facilities in addition to communication circuits to the individual service force tactical centres (NAVAL CCIS, LAND CCIS and AIR CCIS) and to higher national authority (HNA).
Force tactical centres (dark grey) provide C2 to their tactical forces. In addition to their own LANs they have direct communication with their peer centres as well as with the JOC. Tactical (white) forces are shown communicating via tactical data link (TDL) nets. Three such forces are shown, naval operating on Link A, air force and the BMD units operating on Link B. The BMD units could be deployed out-of-area in which case they would, more realistically, report directly into an appropriate CCIS or the JOC CIS.
Additional communications are provided by a ship-shore-ship- buffer (SSSB), which provides translation of naval Link A data into a format suitable for integration into an extended air defence ground environment (EADGE). An AEW is shown providing additional support for both the naval force and the EADGE. The naval "gateway" unit provides the means for exchanging tactical information between units belonging to the naval Link A and the air force Link B nets. Note that the naval units if appropriately equipped could provide a TMD capability in addition to that already provided by the BMD units.
This diagram illustrates a complex, although common, scenario. Each of the constituent forces is, in its own right, operating a super-system of C3I sub-systems and the interconnection is an extension of the size and complexity rather than a totally new problem. In effect the EAD system is really a set of nested super-systems each of which will have similer types of interoperability requirements and problems. Whilst the EAD system is depicted here as "the" super-system, in the future this is unlikely to be so. Rather, it will be just one of a set of nested super-systems supporting a much larger multinational system such as could be conceived for the global protection against limited strike (GPALS) programme.
This structure could equally represent the combination of command systems involved in a joint force on deployed operations. In this case, forces may well be multinational and interoperability requirements may have to consider language as well as other aspects of information exchange needs. Furthermore, the JOC may have to report to higher authority within more than one nation. It is important to stress that the overall performance of a super-system such as this relies just as much on human actions as it does upon the performance of its technical components and its effectiveness might only be able to be judged by the extent to which the operators manage to co-ordinate their activities. The human elements, therefore, have to be considered as integral components and not merely as external users of the super-system. 5. Interoperability
Interoperability is a quality required by all inter-communicating systems. A formal dictionary definition for interoperability, viz. the quality of being mutually operated, can be derived from "inter", a prefix meaning together, mutually or reciprocally, and "operability", the quality of being operated.
However, to understand what is necessary to achieve interoperability requires that this formal definition be refined to satisfy the specific needs of C3I. For this purpose, interoperability can more accurately be defined as the ability of a system to correctly exchange, by means of mutual operation, useful information with other systems in support of an operational task, where a system is a collection of one or more computers, associated software, peripheral equipment, communications equipment, physical processes, operators and users, etc. This definition is centred upon the need to exchange and act upon useful information. As C3I systems will invariably rely upon the performance of operators and the reaction of information users for the immediately foreseeable future, this definition implicitly requires that the presentation of information at the human computer interface (HCI) is in a form that supports the correct exchange of person to person information.
It should be stressed, however, that this does not require that HCI's be identical for all participants within a "super- system". Rather, they should be in the form most suitable for the operator, taking into account such factors as natural language and culture. The use of graphical user interfaces (GUIs) can go a considerable way to achieving commonality, but even then tailoring to individual needs will still be required.
In an ideal world it should be expected that agreed standards would be sufficient to achieve interoperability. However, in the real world, standards provide options, both technical and in information interpretation and usage, and a single standard may provide several equally valid options for a system implementation. Therefore, while use of common standards is fundamental, it cannot alone guarantee that compatibility, let alone interoperability, can be achieved within super- systems. Hard-won experience has shown the availability of options within a single standard makes it necessary to develop a method of directing this choice to that required to support a specific operational requirement. At their most basic, EAD systems will not function unless there is a genuine need and desire for co-operation. Service or individual insularity will prevent interoperability as effectively as any technical failure. This can be described as the interoperability problem domain (Figure 3).
This diagram shows that the achievement of interoperability is based upon recognition of the need for co-operation in addressing a perceived problem. Analysis of how this is to be achieved defines the precise interoperability need. The next step is to determine the roles to be performed by the participants in terms of operational functions. In ascending order, system communication needs, organisational units or platforms required to intercommunicate and their individual tasks in terms of functions will be determined. Only after these stages have been completed will the detailed technical requirements be addressed. Of major significance, the illustration shows how much of the analysis is user oriented as opposed to subject or technically oriented.
The system profile
The apparent availability of choices or options within a single standard (Figure 4) makes it necessary to develop a tool capable of limiting this choice to that required to support a specific operational requirement and which meets agreed interoperability criteria.
One such tool is the profile. Profiles are a selection of base standards in support of a particular application along with the specification of selected options, parameters, etc. As such they can serve as specifications for the level of implementation of the selected base standards (e.g. a NATO data link) in support of an operational role or roles.
Figure 5 provides a representation of how a profile, by removing the uncertainty of choice, is used to generate a design specification that will wholly satisfy the user (operational) requirement. The final specification is based on one or more of the available options. The importance of the profile is such that the interoperability definition given earlier can have appended to it: "while operating under the requirements and constraints of the relevant base standard and profile".
The purpose of the profile, therefore, is to generate an unambiguous statement of the requirement and standard(s) to be used in pursuit of the achievement of interoperability. 6. A system model
A majority initiative by the MOD to address the problems of interoperability within the United Kingdom air defence system (UKADS) was initiated in 1988. Although the full impact of the study's final report has yet to be seen, many of its recommendations are being implemented and its main guiding principles promoted. However, this paper represents the considered view of the author and should not be taken to represent United Kingdom MOD policy or practice.
Although UKADS is an existing, although continually evolving, super-system, the problems it faces are just those described above; how to take existing and new systems and integrate them to make a successful super-system. The requirement analysis technique is based upon a functional decomposition of the operational requirements and functions of a total system drawn, at the highest level, as a three-dimensional matrix, representing operational functions, unit (entity) combinations and communication media (Figure 6). Each occupied element of the matrix is then decomposed to identify individual interoperability requirements (IORs) where an IOR is defined as an operationally recognisable activity or sequence of activities with a definable initating action, a definable concluding action and which involves the exchange of information between two entities. An IOR may decompose into further, lower level, IORs but it is important to note that each IOR, at whatever level, explicitly recognises the operational reasons for exchanging information. Also, at all but the lowest level, each IOR has supporting IORs, thus recognising the hierarchy of information exchange engendered by any complex, distributed information management system. At the highest level this exchange invariably takes the form of human to human exchange.
(Function and object orientation)
These two fundamental features (recognition of operational requirements and the hierarchical requirements and the hierarchy of information exchange) allow the approach to be used as a powerful tool which will support designing for interoperability. When used in this way, IORs may be decomposed to provide that part of a system profile which provide interoperability specifications between entities. More generally, they provide an unambiguous statement of the requirement and the base standards and options to be implemented for interoperability. Whilst this decomposition is eminently suitable for requirement analysis and interoperability testing, a further enhancement is required before it can be fully applied as a profile for system specification. This refinement involves mapping the functions to the objects required to carry them out and the establishment of a formal relationship between the objects making up the system and the OSI 7 layer model. In this respect, it is necessary to recognise that operators and information users are also objects fulfilling functions within the system.
The extended OSI model
The decomposition of the matrix and subject to subject exchanges suggests a hierarchy of layers similar to the structure of the ISO/OSI 7 layer model. These layers can be formally identified and drawn as a model representing individual platforms making up a super-system (Figure 7).
Figure 8 shows a simplified representation of the existing ISO 7 layer model communicating with the new model so providing the additional specification detail required to assist in achieving interoperability within an EAD or similar system. Because of this model's close relationship to the uppermost layer of the OSI model and because it specifically addresses the application needs of the user, it has been designated the "application model".
The sixth layer of the OSI model is specifically identified and defined as protocol conversion. It is of particular relevance to systems such as an EADS as it represents the layer normally associated with front end processors within which the protocols for gateway operation have to be implemented. Within this layer, conversion between net protocols and internal (application) protocols will usually also be performed.
Thus, the extended model consists of the ISO/OSI 7 layer model linked to the application model and addresses the needs of interoperability by showing the layers oriented to address the specific needs of the user (functionally oriented) and task and object system (object oriented) as described below:
User oriented layers. The first of the "user" layers represents the problem domain and defines the command and control (functional) requirements of the subject system, e.g. airspace management. It should be noted that in the context of a super-system this represents a first level of decomposition into smaller (lower order) problem domains that are more readily understood. The second user layer defines the service(s) required to fulfil the C2 requirements specified within the problem domain.
Task oriented layers. The "task" layers define the management of information necessary to provide the subject services. Each of the objects within the layers supports the functional information exchange determined during the requirement analysis phase (i.e. specific IORs). Three layers are identified here, although, depending upon the system being modelled, more or less may be required.
System oriented layers. The system oriented layers include the objects that provide general system management and housekeeping, such as data bases and their associated management systems, together with the objects that are identified and described by the OSI 7 layer model. Within the application model, the objects which have to exchange information with the application layer of the OSI model are defined.
Although the approach proposed has been developed to simplify the method for determining operational/system requirements and flowing these through to system developers, it is still potentially a repetitive and time-consuming process. Clearly, in times of rapid change and uncertainty, speed of decision is of the essence. As with the MOD study, however, the approach taken has been viewed as being ultimately computer- based. The functional matrix is a structure that can be easily supported by a basis data base system. The use of modern CASE tools can facilitate the subsequent matric decomposition and system modelling required to generate representative system profiles. Ultimately systems developed to provide such facilities should be capable of linking to test systems and other facilities at home and abroad. Currently, there are a number of initiatives in this field, notably in the United States and in the United Kingdom. In the United Kingdom the development, by the MOD, of a requirement analysis tool (RAT) based upon the approach described in this paper is a notable and innovative first step in addressing interoperability as part of the requirement analysis process. It is to be hoped that this tool wll ultimately be integrated into a wider and more international distributed test and evaluation system.
The proposed approach provides the basis for a through life implementation philosophy which can support configuration management and implementation planning for an entity through all phases of its life-cycle; specification, design, acceptance/test, and modification/enhancement. Also, by focusing upon the function rather than the unit or communications medium, the approach can, when appropriate, consider these independently of the individual units within a complex system. This means it can be used to support the evolutionary development of a super-system which embodies many component systems and individual operating units. Some of these already exist and others may yet have to be installed but all will be required to interoperate to satisfy the super-system's overall task. It is, thus, an approach that lends itself to the future evolution of GPALS.
When incorporating existing systems into super-systems it is particularly important that the internal information exchange requirements and capabilities of component systems and operating units are fully analysed and defined. In these situations it is unlikely that there will be commonality in the HCIs of the component systems. Attention has therefore to be paid to the possibility of incompatibilities in the way information is presented to different operators resulting in different interpretations of that information and consequent lack of the shared understanding which is the basis of successful interoperation.
Designing a new system to be incorporated into a super- system requires not only a clear understanding of the requirements of the system to be developed, but a clear understanding of the implementations of the systems with which it is to interoperate. The two-tiered approach (functional analysis of user requirements and object oriented analysis of the system required to support the former) proposed provides a framework or design shell to be completed as part of the requirement and design specification stages of system development.
This will be in the form of a complementary system model based upon the requirement matrix and the application model. When complete it should provide the system profile and development process (Figure 9), and give an unambiguous statement of interoperability requirements and a definition/interpretation of the required base standards. Moreover, because it relates the functional operational requirements to the physical objects in the system, it offers a ready means of communication between the system users, system developers and system procurers at an early stage in the project life cycle and enables design changes to be easily, quickly and cost-effectively accomplished.
In the context of acceptance and testing for interoperability, the approach defines unique IORs which can individually and collectively be measured for their ability to support the hierarchy of IORs required to satisfy particular operational requirements.
From the descriptions given, it can be seen that the functional and object models, together used as a system profile, form a ready means of communication between the system developers and the system procurers. By showing functions and interfunctional relationships, the profile can identify what interoperability tests are required and the order in which they should be performed. When developing enhancements to super- system components, use of the approach ensures that account is taken of the requirements and constraints imposed by other component systems and media so that, as well as embodying design for interoperability, it assists in the identification of any possible side effects resulting from proposed design changes. Thus it provides an effective tool for use in configuration control within the super-system. The central role of the model to this process is illustrated in Figure 10. Projecting into the future this figure shows the profile as a central part of a test/reference system.
8. System perspectives
This paper has considered the benefits to be gained from adopting a total systems approach to the specification of extended air systems. The essential message is to keep it simple, even though the apparent complexity of such systems makes this directive appear naive. The approach proposed in this paper, however, shows that this can be achieved by decomposing the system into simpler and more easily-understood sub-systems. Furthermore, the approach accepts the limitations of the component sub-systems by concentrating on the whole systems needs. This requires that the component sub-systems are integrated in a way that maximises their collective performance, through the achievement of interoperability. An alternative approach that concentrates on the maximising of sub-system performance could and does result in costs accruing that are out of proportion to the gains accrued by the whole system. The goal in terms of performance, therefore, is that "the whole [system performance] is greater than the sum [of performances offered by all] of its parts".
In March 1992, NATO held a symposium on crisis management. Interoperability was held up as a key issue. The conclusion was that standardisation is the key to the achievement of interoperability. As this paper has tried to show, standards are just one of many issues that must be addressed. Certainly without them interoperability cannot be achieved - and that has always been known. Also well known is the fact that even when standards are adhered to and even when the same engineered systems are used, interoperability continues to be a problem. That this argument is now over ten years old serves only to illustrate the fact that short-term and easily-understood problems are still the ones principally addressed whilst the real problems remain and continue to remain unresolved.
Although the emphasis in this paper has been how collective system performance can be optimised, it has approached this primarily as a system engineering task. Consequently the need for integrated TMD has been assumed rather than evaluated. Improving collective performance through interoperability is, however, reliant upon organisation, human actions and collaboration as much as it is upon technology, no matter how user oriented that technology may be. There is, therefore, a need to investigate further how and to what level TMD integration is required. Although, ultimately, this is for the military planners and politicians to decide, a rigorous systems engineering approach, similar to that proposed in this paper, will help identify where such decisions are required.
Equally, the techniques described are applicable to many different problem domains. They apply wherever interoperability is a requirement, and are not unique to EAD or TMD, or even military systems.
The value of reference systems, test beds and simulation for the evaluation of complex systems has already been demonstrated by work in several countries, particularly the United Kingdom and the United States. How such facilities can be used to assist in the aforementioned decision-making process, the development of concepts of operations and subsequently act as a reference authority for onward system development can be deduced from Figure 8. For systems such as GPALS, the value of networking such facilities, to enable easy access for all potential participants, should likewise be given careful consideration.
The gathering and dissemination of intelligence information will be a major factor in internationally integrated TMD. However, the widely distributed C3I required to support this may aggravate further the problem of maintaining security of classified information. Although outside the scope of this paper, the determination and resolution of these problems should be addressed as part of the analysis process already described. This section has raised topics associated with the wider issues of TMD rather than system integration as an engineering activity. However, as shown earlier these are as important to the achievement of the interoperability required to support TMD as the "pure" engineering topics. Consequently, ignoring them could have as deterious an effect on these programmes as poor engineering.
These topics have further emphasised why system engineering should not be addressed in isolation from the real world. If this counsel is followed then the problems described at the beginning of this paper will be reduced. Ambiguities in requirements will be diminished, systems will be capable of evolving to meet changed needs, risk will be reduced and unnecessary costs removed.
Super-systems constructed from successful component systems often fail to achieve their desired performance and this can very frequently be attributed to the fact that the component systems fail to interoperate. Normal design processes usually concentrate on the system interfaces which ensures inter-connectivity but does not ensure that a system receiving information is able to do anything with it. A particular problem is ensuring that the information actually reaches the operator who needs it and has to react to it, in a comprehensible and meaningful form.
The proposed approach provides a means of ensuring that operational requirements for interoperability can be properly and consistently met in the design of the component systems, particularly in the presentation of information to the operators involved. The traceability of design back to requirement also provides an effective tool for configuration control during the through life development of super-systems. This enables it to be used for integrating existing systems or introducing new systems into super-systems. As a has been shown in this paper, interoperability is much more than the study of message standards and protocols, important though they are. It is rather about the achievement of system integration and for the future, therefore, it is within this context that interoperability should be approached.