In 1981 the Royal Australian Navy (RAN) initiated a program to procure a new construction submarine and combat system to replace their aging OBERON class. This combat system development represents a top down approach which has been unconstrained by most of the normal administrative restrictions or specialized commercial interests. The system architecture has followed a basic design rule that form should follow function. This has lead to a federated submarine combat system with smart work stations. A primary design philosophy is one of one console all functions, any console any function. Each operator work station is in effect a mini-combat system. The following note outlines the development background, the system functional organization and architecture.
Historical Background of Combat System Development
Submarine combat system development in the U.S. and abroad over the past 30 years has been dictated by the Navy Department/Laboratory organizational structure and the fragmentation/specialization of the industrial base. Thirty years ago there was some technical basis for this division. The primary system elements, sonar and fire control, used very different technologies. Governmental and industrial organizations grew up around the application of these technologies. In the U.S., Bureau of Ships and Bureau of Ordnance were separate organizations looking over the sonar and fire control/weapon development and procurement. Communication between these divisions was Jess than optimum as would be expected with organizations having their own objectives, and more importantly, funding. Other elements of the combat system; ESM, navigation, communications, countermeasures, etc. were likewise distributed among the various organizations. In Europe, specialist companies, often with governmental interests, also developed along specialist lines. The U.S. Naval Laboratory organization was structured to support this type of development. The Fire Control System Mk 113 and the Sonar system BQQ-1/2 were products of this environment. These sonar and fire control systems, while individually capable and of high quality, tended to be myopic with little consideration for one another or the overall platform mission needs.
Over the years the underlying, supporting technologies have changed, with high speed digital processing being central to all of the combat system development. Likewise we have seen changes in the Navy procurement organization in Washington and with the Naval Laboratory structure in recognition that a combat system is more than the integration of specialist products. Unfortunately, our first attempts along these lines have produced less than satisfactory results, cost overruns, and program cancellations. The focus seemed to switch from integration of specialist system elements to overall system elegance and complexity without the required intermediate step of a top down look at the fleet needs and a realistic appraisal of what is obtainable.
The RAN COLLINS class combat system is being developed based on a top down, function driven organization consistent with the objectives and needs of the RAN. The result has been a hardware-independent functional organization and a greatly simplified system architecture.
COLLINS Class Combat System Development Design Drivers. The COLLINS class combat system is functionally organized to address the submarine’s mission requirements. The key drivers for the combat system development were:
1) Types of patrol areas and mission duration,
2) Weapon types,
3) Traffic density,
4) Crew size and capability, and
5) Cost and Schedule.
Patrol areas/Mission duration.
While the details of the operation of the RAN submarine fleet are considered sensitive, it is apparent from a view of a map of Australia that they have a very large sea area with a 20,000 km coastal boundary to defend. Within the limits of that boundary arc found a wide variety of ocean conditions. The RAN operations are based on a 70 day patrol which makes them very much a blue water submarine navy and places a high premium on system reliability and maintainability. Weapon types. The basic weapon inventory for the COLLINS class is the Mk-48 torpedo, the UGM 84 Harpoon anti-ship missile, and selected mines. The system is designed for potential expansion capability to more advanced weapons. The range of the UGM 84 and anticipated future advanced weapons is sufficient to dictate the employment of long range sensors, such as low frequency hull mounted flank arrays and an Australian designed streamed towed array.
Traffic density.
The traffic density in the region to be patrolled ranges from very low (Tasman Sea) to very high (Indian Ocean). With modem towed array technology it is not difficult to project environments in which the submarine platform will be required to deal with tens or even hundreds of simultaneous tracks. This observation dictates a track management system which is capable of automatically sorting, localizing, and classifying with a minimum of operator interaction. The impact of this is to move the man-machine interface forward in the processing chain to reduce the potential for data overload This effect is shown in Figure 1.
View full article for table data
The crew on the OBERON class was 63, consisting of 7 officers and 56 sailors. The RAN directed that the new construction submarine be designed to be operated by 42 men comprised of 7 officers and 35 sailors. This limitation on crew size dictates a system which is flexible and provides a high degree of automation.
Cost and Schedule. Cost is always a constraint on the design. The RAN combat system procurement is a fixed price contracl This brings with it certain restrictions in the development process, but on balance is likely a guard against excessive complexity, the number one enemy of good design. The development schedule is six years from contract award to beginning of harbor acceptance trials.
COLLINS Class Combat System Functionality.
The functionality of the combat system is matched to the RAN mission requirements and is divided into three top level functional areas; surveillance, track prosecution, and support (see Figure 2.). These functional areas are implemented consistent with an operational philosophy of management by exception for system tracks and management by consent for system threats and targets (the higher priority tracks).
View full article for table data
The surveillance functional area allows the operator to review the tactical situation on progressively refined levels of data processing. The first of the series of surveillance functions is detection. The operator can review the automatic detection process as being carried out by the various sensor subsystems or become directly involved by reviewing detection information from a single sensor or combination of sensors. The operator can cause information from multiple sensors to be displayed simultaneously at a single workstation (Multifunction Common Console (MFCC) or the Command Plot (CP)). He can review the data from up to 8 different sensors simultaneously at a single workstation. He is also provided with audio stereo over high fidelity headsets at each workstation. The headsets also provide command team communication on either manual selection or automatically on a function dependent basis.
Another important difference here from previous systems is the order of reasoning which takes place to select a display. For example, the top function or operator task is detection and subservient to that is processing type and then finally the particular sensor providing the information. Previous systems which were integrations of hardware elements forced the operator to first be an equipment operator and then address the mission important function, i.e. he would be a hull array sonar operator focusing on the hardware (hull array) not the function (detection).
The second of the surveillance functions is classification. Again fully automatic parameter extraction and classification processing is provided working off multiple se!15ors. The operator would be expected to become involved as the track priority increases or as he is alerted by the system. Three modes of classification are provided, manual, computer aided, and automatic. The first two are contained within the track prosecution functional area.
The third surveillance function is target motion analysis (TMA). The system uses a modified maximum likelihood estimation technique as the primary background TMA process. TMA may be performed on tracks being held by multiple sensors using a priority sensor assignment scheme.
Included within the TMA function are automatic contact and track association, which work on kinematic, spectral, and classification information. It also includes data conditioning, and zig detection.
The next of the three functional areas is track prosecution. Where the surveillance functional area is largely accomplished in the background, track prosecution is by definition operator interactive. Track prosecution is viewed as a natural progression of information from surveillance which allows the operator to focus more directly on a single track of interest. The three functions under track prosecution are TMA, Classification, af:!d engagement. While two of these functions are the same as in surveillance their application as focus is quite different.
TMA, under track prosecution, allows the operator to review the input data set, select and/or edit the source data stream from multiple sensors associated with the track, apply constraints, use the MA1E mode, and review any detected track zigs. He will also assign the source of the system from this function.
Classification allows the operator to review the automatic classification solution and underlying reasoning, to work with a modification of a RAN developed computer aided classification technique to perform a directed classification library data base search, edit the track signature, and assign special resources to a particular track of interest.
Engagement provides the operator with the displays and controls necessary to target, preview and conduct an engagement with the Mk 48, the UGM 84, or selected mines. Automatic weapon guidance is provided for the Mk 48 wire guide as are daily and situationally dependent tactical preset recommendations. Under the UGM 84 engagement mode the salvo tube assignment and firing interval calculations are automatically computed to maximize simultaneous missile arrival on target.
The final of the three functional areas is Support. Support contains those functions critical to the mission yet out of the direct tactical mainstream. Functions included in this area are System Management, Navigation, Environmental, Training, Data Recording, PM/FL, and Help.
Architecture. The COLLINS class combat system architecture is best viewed as a federated one with each workstation operating as an independent, yet coordinated, mini-combat system. The system has a form of central processing housed in the System Supervisory Units (SSU). The processing contained in the SSU is that which would be necessary to cause system initialization and maintain background data if all of the workstations were turned off. It also provides for mass storage, the primary sensor interface, control for the data recording activity, and the distnbution of common data to all workstations. Should both SSU’s fail, one of the oper;:ator workstations would be designated to take over and function as an SSU for degraded mode operation. Data communication is over a Rockwell International fiber optic data bus using a hub architecture.
Each of the operator workstations is designed to have a full load of tactical software to alJow the operator to operate in any or all of the functional areas.
Operator Interface. The primary operator interface is via a computer labeled keyboard. The operator may also communicate with the system using trackbalJ, encoders ( 4), keypad or by touch interaction with the colorgraphic CRTs. To assist him in his operation he is also provided with both a key sensitive help function, and a function oriented help (the on-line system training manual).
The optimum organization and use of the 8 operator workstations is still open at this time and remains a most interesting training and operational issue. Since any workstation can do any or all functions, command has more staffing flexibility that he may initially know bow to deal with.
The initial approach will likely be to staff the system with a similar organization as is presently done with the OBERONs, modified only as necessary to access the increased capability. I would expect that this would be replaced shortly with staffing along the system’s natural functional lines. However, the path is open to explore other dimensions of crew organization and training. One could organize by sector as is done in air traffic control systems and provide handoti from sector to sector. Under that arrangement one operator could deal with a single track from detection through weapon launch and control A more natural handoff might be along functional lines. It is expected that many of these issues will be studied and evaluated using the Combat System Simulator located in the Land Based Test Site.
Software. The program for the COLLINS combat system is being written in Ada to Mil Std 1679 and 1815. It is comprised of around 2,000,000 source lines of code. It uses object oriented design (OOD) to reduce the cost of development and maintenance, and to increase the reusability of the resulting code. The requirements documentation was produced using Cadre Teamwork.
Summary. This paper has attempted to provide an overview of a submarine combat system development which is being accomplished independent from most artificial restrictions potentially caused by administrative boundaries. The design is the result of a top down, requirements driven approach. This has resulted in a different functional and physical architecture which seems to offer some operational efficiencies and development economies.
The resulting system promises to provide data access and system control from each operator workstation contributing to a high degree of flexibility and manning and operation.
This is thought to be the first submarine combat system to depart from the classic hardware driven design which bad resulted in an artificial separation of function by company product line rather than user need. The RAN combat system integrates sensor input at the data level and allows the operator to display sensor information independent from the source.
The combat system is modular and therefore scalable to other platforms and user applications. This modular nature makes it easily matched to different sensor types and weapon complements while retaining the feel and operability of a functionally organized system. The structure is largely sensor and weapon independent in that the emphasis is on function e.g. detection, engagement, etc. rather than hardware e.g. type xyz sonar.
