Volume 2, Number 1, March 1999
The Electronic Warfare Operational Support Centre (EWOSC) Database - A User Perspective
Abstract
Military organisations must ensure that electronic warfare (EW) systems used by front-line units are correctly programmed with up-to-date EW information. To accomplish this vital task, an EW Operational Support Centre (EWOSC) facility is an essential requirement to facilitate the minute-to-minute management and dissemination of the relevant EW data in support of operational commands. This short paper introduces the concept of a traditional EWOSC and describes the design of databases to support such an organisation.
Introduction
Military organisations must ensure that electronic warfare (EW) systems used by front-line units are correctly programmed with up-to-date EW information. To accomplish this vital task an EW Operational Support Centre (EWOSC) facility is essential to facilitate the minute-to-minute management and dissemination of the relevant EW data in support of such operational units. One such typical task is to provide geographically/mission-tailored, equipment-specific libraries for use in operationally deployed EW equipments. The main aim is to provide the EW operator with an aid to intercept identification through the use of radar descriptive libraries that are constantly being parsed via Radar Classification Algorithms (RCA’s).
Overview
Many advanced countries that employ the use of EW systems maintain a considerable amount of EW information for use in the assessment of other nations’ Electronic Order of Battle (EOB). In order to do this accurately and efficiently it is necessary to research, validate, analyse and consolidate all EW information from all sources. It is this area of EW support that this short paper is intended to cover.
Data support tasks
The primary role of any traditional EWOSC is to provide single-service/tri-service EW data support to all front-line EW users and equipments. In general terms, the following high-level tasks provide the basis for any EW support activity:
- maintain database on a tri-service basis but always meeting single-service requirements;
- research, validate, analyse and consolidate EW information from all sources;
- update EW Master Database to reflect changes to EW data;
- rapidly disseminate significant database changes to front-line units; and
- maintain a customer support cell to facilitate liaison with the producers and users of EW information; and react positively and promptly to all customer feedback.
The overall aim must always be to provide a process from which a change in the EW environment is recognised, analysed and reacted to in the fastest possible time. The clock is always running.
Sources
EW source information can come in many varied shapes and sizes. It is generally broken into two distinct categories, namely classified and unclassified (open sources); although the latter may have a form ‘commercially sensitive’ caveat attached to it. Generally speaking though, and in this paper, EW source information is referred to as classified and unclassified.
Classified sources
Classified sources are without doubt the safest type of information to be used within an EWOSC. Quite simply, there has to be an accepted level of trust and confidence in the use of this type of EW data. It goes without saying that the providers of such a level of classification will have an in-built vetting system that by default ensures a high degree of security within not only the people but the organisation in general. Secondly, data provided from a classified supplier would normally infer that the EWOSC staff have an above-average knowledge of the quality control procedures applied to the data being provided. This is a very important issue when relying on sources from a ‘third-party friend’.
Typical classified sources can include nationally owned radar parametric data, nationally observed (intercept) data and, in some cases, information derived from bi-lateral/multi-lateral Memorandum of Understanding (MOU).
Unclassified sources
Often referred to as ‘open sources’, unclassified sources can provide a whole host of information about who has what capability, when did they buy, and so forth. Although some of it can be expensive, this does not always have to be the case. So often this type of non-parametric information can be easily gleaned from open press, magazines, manufacturers marketing literature and of course the World Wide Web.
General
However, both these categories have inherent problems. In the case of classified sources consideration must be given to the implications if information that has been derived from an MOU with a ‘friendly nation’. Once this source information has found its way into the Master Database it would be wise to have some form of security level or source tagging attached to the individual field or record. Imagine the embarrassment should this type of data be inadvertently given away to a third party under another MOU thereby violating the agreements set down in any bi-lateral agreement. In the case of unclassified sources the age-old problem of mis-information exists; in addition to the general lack of knowledge of the original provider this situation is a very real prospect and can cause untold damage if not discovered during internal quality control procedures.
EW master database content
The EW Master Database should be recognised as the depository for all source information once it has been through the complete cycle of research, validation, analysis and consolidation by means of internal quality assurance procedures. This formatted data will typically be held and managed in a modern Relational Database Management System (RDBMS) such as Oracle, Sybase, or Informix, although there are certainly other options or indeed a combination of options. As illustrated in Figure 1, the four main types of data held within this structured system are:
- emitter descriptions (generic);
- platforms;
- weapons; and
- intercepts.
Emitters
Emitters are without doubt the most comprehensive type of data to be described within the Master Database. Due to the generic requirement of storage, the number of individual parametric descriptors contained within the emitter data model can range from 25 to several thousand, dependent on the output requirement and sources available to a particular nation. It is because of this level of complexity that this area is the more testing portion of an EWOSC, particularly with regard to analyst experience, maintenance throughput and quality assurance and quality control rules and procedures.
Platforms
Examples of platforms include mobiles, (sea, space, air and sub-surface) and land (both fixed and mobile); there are of course modern variants within these general categories. Unlike emitters, the level of platform knowledge and comprehensiveness of platform descriptions, whilst not an insignificant matter, does not present such a high priority when assigning internal resources.
Weapons systems
Descriptions are often a bone of contention within the EWOSC environment when it comes to the level of data model required to describe weapon system characteristics. There appears to be a continual conflict over who actually should be the provider of such data, namely the Intelligence community or the EW community, perhaps a question of semantics in this case. However, it is not intended to make the argument in this paper. Needless to say, weapon system descriptions should have a minimum amount of information to allow the relationship to be made between a weapon system, an emitter, a platform or indeed an intercept.
Intercepts
Intercepts are a vital area of any EWOSC; not only do they provide a level of emitter or platform identity (albeit on a sliding scale) but they are a controlled source for the emitter analysts during the emitter review process. Many intercepts built up and stored over a period of time form parametric histogram information, which can be used in the development of RCA’s. Intercepts of own friendly units can also provide an early indication of radar malfunction, which can lead to an early rectification of the problem by the transmitting unit.
Data flow
Figure 2 then illustrates the flow of data from the various sources to front-line users.
Generic data to equipment-specific/mission-specific data
The Master Database will generally hold data of a generic nature. This term will usually refer to the emitter parametric descriptions contained within the emitter data model that holds fields to describe radars mode by mode in a globally representative format. It is from the Master Database that the Equipment Specific Database Formats (ESDB) will be generated. These ESDBs are essential for the programming of the individual front-line EW equipments; it is in this phase that the generic data is transformed by way of a software interface (mapping) into the ESDB formats. This process takes into consideration all the capabilities and limitations of each individual equipment, Electronic Support Measure (ESM) or Electronic Counter Measure (ECM). These ESDBs are also tailored to meet the specific threat known to exist within the designated area of operation(s). This step is known as the Mission Specific or Theatre Specific view. It is during this process that accurate and timely knowledge of the enemy Order of Battle (OOB) and EOB is essential. The main aim of this activity is ambiguity reduction, leading to rapid identification of potentially hostile intercepts.
EW database structures – where do they come from?
EW databases designed to support a typical EWOSC are often built from new, that is, there are very commercial-off-the-shelf (COTS) products that will achieve a workable solution (one or two do exist and some details are provided at the end of this paper). However, regardless of how an EWOSC requirement is met, it is true to say that, without the experience and input from the recognised EW user community the end product will not function correctly and the main aim of the EWOSC will simply not be met.
Database design issues
As discussed earlier the traditional EW database will be built within one of a number of RDBMS. Therefore, there are important issues to be considered during the decision-making process to determine which to choose. To be fair, all of the RDBMS mentioned earlier will provide the structure for an effective system. However, as illustrated in the following sections, the dilemmas occur when security, flexibility, development and of course financial issues are considered in depth.
Security
The nature of EW business will often dictate that security is the driving design factor. Security is of particular importance when handling data provided from a third party, especially if it is possible that outputs from the database are destined for a different friendly nation under completely separate MOUs or bi-lateral agreements. If this is a mandate then database design options are narrowed because some RDBMS are better than others in providing a ‘trusted’ system.
However, it must be said that security should not be allowed to be the dominant and overriding decision maker. There is certainly no point in having a top-rate secure system if many of the other areas of functionality do not perform at the required level.
Flexibility and development
Generally speaking the flexibility of any system design is dictated by the associated software tools and the ability to interface with third party packages or libraries. The software tools, generally known as development tools, are used for a large number of areas within the database. Examples of these tools are:
- compilers (various);
- graphical user interface (GUI) builders;
- browsers;
- emulator software (various);
- operating system software; and
- report writers.
Financial considerations
Another significant design issue is the cost of providing an operational database. For example, runtime licence costs will always be a strong consideration depending on the number of site users and servers involved in the particular project. All of the above development tools are likely to have an associated cost either initially or as a runtime licence cost. Without doubt, there is considerable saving to be made if a COTS solution can be found that negates the need to go through the complete development phase. Unfortunately, when taking this approach there is often the “not invented here” syndrome to contend with. This argument, in this context, is entirely without foundation as any EW database will need some internal customisation as all organisations will have unique support requirements; therefore COTS is a very effective way to proceed and should at least be afforded due consideration prior to deciding on any procurement and development strategy.
Having considered all of these issues there will invariably be a need for a compromise to be reached prior to deciding on the RDBMS to be employed. Needless to say there is not, and never will be, such a thing as a ‘best of all worlds’ solution. Nevertheless, a system that can provide 85% to 90% of the required specification would generally be an acceptable compromise situation.
General rules and considerations
It is essential that a comprehensive set of business rules is defined at the earliest stage of database design, for example:
- details of data model: are all current and pending future EW equipment specific requirements covered?;
- level of validation and security required: field level or record level;
- relevant prompts to assist with input errors;
- ability to amend, archive, transfer or delete content;
- choice of RDBMS: does the choice meet the national IT regulations?;
- level of quality assurance: how much is automated, how much must rely on manual quality control?;
- changes to data model: downstream effects of changes to hard code;
- system administration: control of individual user access rights and privileges; and
- data release considerations.
These are just some of the user considerations; the list is by no means exhaustive. Nevertheless, the suggestions are certainly thought-provoking and should be considered during the initial procurement stages of any database design process.
Outputs
The EW database data cycle is illustrated in Figure 3.
The result of the cycle (and the real measure of success of the process) is the quality of the output to the customer. Typical output formats of an EWOSC database are:
formatted, equipment-specific library magnetic media;
hard copy containing textual support to EW equipment libraries;
theatre maps – mission specific data support;
electronic versions of libraries and maps; and
EW training systems.
Once again this list is by no means exhaustive and is merely representative of the standard type of EW output to the EWOSC customer.
Future considerations
As with everything connected with technology, the EW environment moves on at a fair pace. All areas of EW are under continuous development programmes, either within the defence industry or within military organisations. The following areas will most certainly need to be addressed by many of the world’s EW operational support activities either now or in the near future:
- data model to support electro-optic/infra-red and unmanned aerial vehicle (UAV) platforms;
- collection, analysis, storage and output of Specific Emitter Identification Data (in addition to, not replacing, the traditional RF, PRI, PW, Scan and so on);
- object oriented design in conjunction with the traditional RDBMS; and
- full integration to third-party software such as geographic information system (GIS) and messaging systems.
Summary and conclusion
For a nation to have EW assets fitted to front-line units is simply not enough. Without the full support of an EWOSC-type facility, the EW equipments will simply not provide the appropriate service or achieve the operational effectiveness expected of them. To invest large sums of money in such equipments without this critical support is risking the loss of even more expensive ships, aircraft and other ‘non-protected’ units. The lack of good quality and timely EW support data, or data support, has even resulted in mis-identification leading to ‘blue on blue’ – fratricide!
Systematic Software Engineering market a COTS product called EWare, which incorporates functionality similar to that described in this article. EWare has evolved over several years and is described as an EW Library Management System for use within the EWOSC-type of facility. However, EWare is much more than this. As the product matures, it has not only benefited from an internal research and development programme but also from experience gleaned when providing EWare to several of the world’s leading EW nations. By undertaking an appropriate level of customisation for individual organisations the system is more than capable of handling the day-to-day activities of a traditional EWOSC, both single-service and tri-service.