![]() |
|
 |
Israeli Navy Command and Control System Development- Case Study |
 |
|
![]() |
Abstract
The Israeli Navy (IN) Command and Control Systems (CCS) considered to be of the most technologically advanced of their kind in the world. In developing CCS, the technological and operational branches of the Israeli Navy (IN) worked hand in hand. The development process required more interdependent technical, operational, and managerial decisions than other types of software systems. The methodology with which the IN developed its CCS, its operational concept, technological principles, and the decision making process deserve review as a model, for developing other software based systems in general and CCS development in particular.
CAPT. Nathan Barak – Background
 The Yom Kippur War was etched into our consciousness as one of the hardest wars fought by the IDF. It is also the war in which the Israeli Navy (IN) achieved total victory over the Syrian and Egyptian Navies. The IN prevailed in all the missile boat battles, and destroyed, in the world's first missile battle five Syrian missile boats at the entrance of the Syrian port of Latakia and three Egyptian missile boats in Damietta. Notwithstanding prevailing in all the war's sea battles, the IN came to the conclusion that in order to improve its battle fitness, it would have to drastically improve its ability to build the tactical picture and control its forces. The difficulty in forming the tactical view was described by LTJG Alex Eyal, DNC officer of INS Keshet, in his after action report from the battle of Port Said during the Yom Kippur War "... what we had for a tactical picture was full of 'chaff' All told, the picture included about 20 different targets 6 of which where our ships and the rest 'chaff'. The picture looked mixed up - even to us. Had we not known that we were in the center of the picture we even would have been hard pressed to identify our patrol partner." The explanations in the after action reports showcase the problems the tactical view construction process and the IN communications protocol were to solve. It should be pointed out that the amount of information processed in the modern CIC has grown by at least one order of magnitude since the Yom Kippur war.
In the IN the thought took hold that the battle will be won by the combatant who builds the (correct) tactical picture first. "Speed is an important variable in building effective C&C systems. The faster a ship produces its tactical view, the faster it can reach any needed decisions, plan, and synchronize with other forces." From here started the development of necessary doctrine and advanced technological capabilities in the field of tactical view construction and navel warfare.
Until the start of the 1990's the IN had a whole slew of different systems for use in the CIC, ranging from the basic map table to various computerized tactical display systems as appropriate for the platform. These computerized systems where developed by different units of the navy and defense related companies without any centralized management of the (often overlapping) development effort and with no consistent tactical concept. The communications protocol used to send information between systems was based on the lowest common denominator i.e. a basic message passing system that did not leverage the available information and did not allow for a clear picture to be rapidly constructed. Any change in this underlying protocol would require much resources to adapt all the systems that use it and would "crash" any system was not upgraded to handle the change.
The development of appropriate doctrine in the field of tactical view construction, and the lightning changes in the computer world brought about a concentration of resources needed for CCS development and the creation of the C&C Branch in the Weapons Dept. and the C&C Development Branch in the Computer Development Dept. of the Israeli Navy.
With the IN entering the development cycle for the Saar5 class ships the following dilemma presented itself; We could either force the Saar5 ships to accept the limitations of the existing technology, or we could make a clean break from the constraints of the past.
The decision not to remain bound to the lowest common denominator, and to instead take advantage of the improved capabilities of the more advanced systems for building the tactical view led to the development of a new, common, "Navy protocol". This protocol is not only a unified language between CCSs, but part and parcel of the new paradigm of in tactical view construction procedure and force management.
Tactical view construction in the marine theatre.
In the Yom Kippur war it became clear that during the fighting the ships' crews were flooded with information, much of which was partial and misleading. The battle would be won by the force that succeeded in forming the correct tactical view first.
In building a tactical picture, a great deal of emphasis is placed on fusing information received from sensors with different abilities, and the crossing of information from the ship's own sensors and the sensors of the other ships in the force. Each sensor gives part of the picture that by its self does not allow effective decision making and offensive planning. Illustration #1 shows the detection picture in a relatively simple scenario which includes two enemy ships, one merchantman and several land based radar stations. The friendly force contains three ships,each using only two of its sensors, radar and ESM . The total number of target reports is quite large and hampers proper comprehension of the scenario. Use of radar targets only is insufficient for target identification .
Accordingly, it is impossible to fire a missile salvo without additional data. Even though triangulation with ESM enables target identification, it does not supply a position accurate enough for missile fire. Diagram #2 shows the actual view of the area.
In the real world situation, where many electronic warfare and other sensors would be in simultaneous operation, the job of separating between enemy warships and neutral merchantmen is immeasurably more difficult.
Centralized management and force coordination and resource management.
The character of Command and Control Systems changed not only due to the quality and character of the information that it receives from sensors, but also with the involvement of Command and Control Systems in every phase of the battle process. In order to obtain a relative advantage, it is necessary to utilize all the capabilities of the weapon systems. Leveraging these capabilities is expressed in the coordination and synchronization of the offensive processes of all the vessels, resource allocation according to the priorities of the force, synchronization of the threat picture, and optimal responses, taking into account the advantages and shortcomings of each and every offensive and defensive system.
Since warfare at sea is characterized by limited resources a fighting force is required to appropriately allocate its resources for offense and defense, according to expectated needs of offense, defense, and threat level. C&C Systems in the newconcept of the IN were not supposed to be just a computerized map table, but an integrated tactical picture building system controlling and synchronizing all the weapon systems. "C&C Systems are designed to support operational decisions and implementing effective operations faster than the enemy in every confrontation and every situation."
Combat Command and Control Systems in their advanced forms are not just tactical display systems, but battle management systems synchronizing and utilizing the abilities of every weapon system at its disposal. In practice, they direct all of the weapon systems.
The accepted direction of Command and Control Systems in the navy is built on the concept of Combat Management Systems (CMS). With the CMS approach, a tactical picture is centrally built and then distributed to all the different systems. But beyond this, the allocation of resources (offensive resources/weapons and the various defensive measures) is centrally allocated, including assigning targets for attack, resource allocation according to the threat picture, and the like.
In the CMS architecture all systems sit on a central bus (effectively a pipe through which all the messages between systems travel). The Sensors report their respective detections the the CCS, which builds a tactical picture and distributes it to all of the systems. In parallel, the C&C System evaluates the situation and allocates resources to counter threats in a centralized fashion.
At sea, analysis occurs not at the level of the individual systems , but at the procedural level: detection process, identification and classification process, defensive process, and the offensive process. Each system participating in the process is in and of itself important, but the emphasis is placed squarely on the entire process than on any individual system. The great investment in integrating the different systems was intended to produce an advantage in relation to the abilities of hostile countries. "The Naval arm must be fit for combat against western weapons no worsethan the quality of our own…. The next step is to develop a network of available resources and a backup apparatus" . Integration of weapon systems, data mining and optimized resource utilization are a force multiplier and generate the relative advantage over countries that are arming themselves with western weapons.
The decision making process
The decision to create a new navy protocol and to take advantage of the advanced capabilities in the field of tactical picture formation and control in the Saar5 obligated the IN to deliver a solution to all the different systems in a short amount of time. Updating and rewriting the software for all the existing systems and installing new C&C Systems was not possible. The price quote received from the defense industryfor upgrading the existing systems installed in some of the missile boats brought home the fact that upgrades and compatibility for the new protocol would be very costly and frought with problems. In parallel the Weapons Systems Department and IN Computer Center presented a proposal to develop a modular product line for C&C systems using a uniform basic infrastructure and consistent application that would address the different needs of C&C Systems whether at sea, in the air, or shore based.
The primary objection raised by different bodies in the Navy was CCS and intelligence system development are characterized by constant change resulting from changes in the combat doctrine, from experience gained in operational activities, from technological change, and changes in connected weapon systems.
A particularly large drive for change comes from the experience gained by using the system and its influence upon the battle. "An effective CCS accommodates and supplies the means to handle changing situations. Developing C&C Systems is a continuous process of adaptation" . The attempt to avoid changes to the C&C Systems failed again and again. Every new weapon system requires changes to the CCS. Any significant change in a weapon system requires accompanying changes in the CCS. CCS development by the defense industry with a "Fix Price" model would lead to neverending modifications, high costs, and a lack of flexibility in the implementation which would adversly affect the quality of the system in regard to technological progress, environment, and users.
Due to the nature of C&C Systems, the Navy's commander, R. Adm Ami Ayalon, decided that independent development of C&C Systems within the Navy would be considered a "Core Capability".
C&C systems, more than any other type of system, must fit the user "like a glove" at all times. The Navy's commander noted in 1992 that "there is a distinct advantage to building C&C in the navy itself. The continuing changes and the integration between the operator and the developer are extremely important when bringing the product to completion".
In my opinion, one shouldn't take the decision to mean that C&C systems are Core Capability since civilian companies are not included in C&C system development in the Navy. However, it is plain that the Navy must retain full control when developing and upgrading its C&C systems, since it will be impossible to fully transfer the responsibility for developing C&C systems to industry in the light of the changes needed during product development, when the very essence of the product can alter. The development of a C&C system together with industry requires a model that allows for flexibility during the development process.
The "product line" approach within C&C systems, the ability to combine processes that are different in character and the ability of the Navy to independently develop projects of these sizes, seemed imaginary at the start of the 90's. In order to test the process and the ability to develop systems of the size needed and in the relatively short timescales that are required àîì"ç and the Navy computer center were asked to develop a C&C system for the ðö"ì ship and to prove the capability on one of the Navy ships. The development was completed on time and provided the Navy with a top-level C&C system. The development was expanded to all the äñè"ìéí in the Navy and after that was authorized as the control system for the beaches and to all the flying and floating systems in the Navy. Every single stage was authorized separately, based on the total experience from the previous Technology Aspects.
The development of the Command and Control system was based on several fundamental principles that greatly contributed to the success of the development process. The first principal was: Develop a product line covering all the C&C needs of the navy. The second principal was that we would develop our C&C system in process called Evolutionary Acquisition with emphasis on the core technologies and additional capabilities added in each cycle of the spiral development model (more on this later). The last principle was: Base ourselves on an open architecture, flexible implementation, and readily available Consumer-off-the-shelf (COTS ) technology, which could be expected to be upgraded with the progress of technology.
Product line development Developing the software foundations for a software based system constitutes a heavy investment and implies the highest risk. The basic requirements from the software infrastructure and basic mechanisms are similar to other systems with similar requirements, for example, other types of C&C systems. The objects in a naval C&C system, procedures used in building a tactical picture, the basic requirements (i.e. maps, multiple displays, external interfaces etc) and the navy protocol are the same or at least very similar. The investment in basic software infrastructure includes defining objects, building the database, defining procedures, a messaging system, Inter-process Communication system, graphics systems with masking/displaying abilities, and so on. Varying systems truly have different characteristics, different requirements and different needs that sometimes have implications on the basic software infrastructure and system architecture. Nevertheless, often, with the correct building of the basic software infrastructure there is no need for the foundation software and mechanisms to be different. In the last few years there is trend towards use of software environments based on J2EE and .NET that broaden the use of shared infrastructure beyond the services of the operating system but comprise a framework does not naturally take advantage of the shared application foundations. "Modular systems are a network of subcomponents that create a product becomes one entity, whose organization may be configured according to each customer's needs and preferences ."
There is a great deal of significance in using a similar software infrastructure. The aspiration to reuse software stems from software maturity which is a critical parameter, and economizing the checks already made on the thousands of lines of code already written and verified. The optimal exploitation of software reuse will be in the realm of the software infrastructure (which comprises, as mentioned above, the most important and central part of every system.) When using Object Oriented Design (OOD) technology, infrastructure means realizing a large amount of functionality including object definition, common classes, required operations upon classes, inheritance attributes, display operations, etc.
One of the binding necessities for software heavy projects, is the development of comprehensive infrastructure and product lines as opposed to specialized systems. The cost of such infrastructure development is far too large for any one project or lone customer. From this standpoint, independent CCS development within the navy is a disadvantage. With a proper model for cooperation, it is possible to divide the costs with the commercial sector and to leverage the investment with reuse for other projects. The time required for architectural maturity and sifting the bugs may be greater that the project timetable. Therefore, it is desirable to use proven architectures, or an architecture that will serve several projects, and not a specialized architecture. Using a common architecture for a product line will ensure proper investment and long term support for the software infrastructure. It is vital to ensure that the design and infrastructure meet all the requirements of the product line and that using a particular architecture in one application does not constrain another application. "A modular application architecture may be leveraged for use in a large number of applications, in differing variations, by connecting and adapting the various components" .
At the time that the ideas were being formed, the widespread opinion was that the differences in doctrine, technical operation, and viewpoint on the various processes, means, and objects between the shore, air, and seaborne facilities would make unifying their systems impossible. The "product line" concept is worthy of evaluation even where is seems that the differences outweigh the similarities.
The greatest contribution of the "product line" concept was not only technological, but primarily, operational. Unification of the systems allowed the formation of a common language, smoother transitions for personel from one area to another, integration of the lessons and theories from one area to the benefit of another, reuse of developmental effort, more reliable inter-system interfaces, and the system wide upgrade due to the implementation of any change in the operational requirements.
This "product line" concept, which was also implemented in the product line of the Navy's training simulators, could be generalized for other systems families, and is implemented in a (too) small number of defense contracters in practice. Implementing the concept requires finding the appropriate development techniques and architectures that support the process.
Open System and Constant Upgrade
CCS's require, more than any other system, flexibility due to changes in technology, operational specification, connected systems, and so forth. Therefore, the most basic requirement in developing such systems is an open architecture (Open System) and full modularity. The imperative to develop a product line further clarified and widened the need for a flexible, open architecture. Israeli Navy commander R. Adm Yedidia Ya'ari, in an address to the Navy's officers, summarized the drive for constant improvement as, "Victory belongs to the one that upgrades first."
In general and simplified terms, the chosen architecture for the Navy's CCS is based on a Bus (a sort of pipe through which flows information) upon which is connected all of the processes. Each process listens for the messages that interest it, processes the data, and then transmits on the bus that processed data which might interest other processes. (Publish / Subscribe) In this way, the processes do not know one another and replacing a graphical process, for example, in response to changes in graphics technology, or moving to a new platform, does not necessitate any changes in the other processes. This kind of implementation even enables distribution of the system processes amongst a number of different computers, without any need to change the software, except for configuration files. This capability aided in improving performance and load balancing in shore installations by adding an additional computer - but without any further development effort.
The architecture for the Navy's family of CCS's is described in illustration 5. In this architecture, the processes that interface to other systems "sit" on the bus and report any data that is received by the various sensors. The other processes, such as the logic process and the display process, listen and decide which messages interest them and what they should do upon receiving an update.
The architecture of the 'Zoharim' (the CCS of the Saar4) also supports testing processes, a structured apparatus for recording all system events, and the ability to play these events back until the point where the anomaly was detected. The testing processes and playback capability are a critical component in heavily software based systems allowing rapid acquisition of system stability within a relatively short time.
When considering an architecture of this type, it is necessary to give proper attention to those areas which require a real-time response. A range of solutions exist that allow for rapid response without detracting from the basic architecture.
This architecture has proved itself over the past decade. A similar infrastructure/application was adapted for the shore, airborne, and seaborne CCS, despite the differences in the control logic and data distribution. Furthermore, the same architecture has been run in differing environments and different platforms - both on Unix workstations and on PC based Linux, with negligible investment when compared to a similar effort with separate, specialized systems.
Flexibility to technological change, adaptability for a product line, and testability are the central parameters in planning and molding the software architecture of a CCS. Flexibility is shown by the ability to change a single process due to technological changes or in converting an implementation to another platform without damaging the rest of the system components.
Flexibility in CCS software development is, of itself, not sufficient. A great deal of flexibility in hardware upgradability is also required. At the beginning of the 90's, when the use of COTS products in military applications was in its infancy, we decided to use civilian technology and work environments that were in mass use by the non-military world. The central principle, that now seems far clearer, was to take advantage of the large investment by the private sector in technology and software infrastructure.
In order to enable simple and easy simple upgrades, we used completely civilian technology placed in an "incubator", a protective case that protected the hardware from outside environmental conditions, leaving the interior in a state acceptable to civilian office standards. Since, in the civilian world it is accepted practice to keep backward compatibility with previous technology, the incubator concept enabled simple, fast, and inexpensive upgrades of systems and technology. Furthermore, it was possible to use identical hardware for both seaborne and shore based use. The cost of the incubator is negligible compared to the cost of upgrading any system which is not in mass production.
Spiral Model Implementation. The model that the IN used in developing its C&C system was defined by Bohem. This model is at its core primarily risk driven, and designed to deal with the riskiest and most critical section of the project development at an early stage. Technological risks, environment risks, budget risks, and other dangers that are result of the users, , the software environment, and the chosen technologies.
Every full turn around the spiral represents a full process which ends with operationally useful product. Early identification of risks makes it possible to define the stages of development such that risks are dealt with earlier, where the available options are greater. In the spiral model described in figure 6, every circle includes requirements definition, risk assessment, design, implementation and integration.
The spiral model makes it easier to concentrate on the main task. When confronting the problem of over-specification, not only do we "educate" people to remove unnecessary requirements, but also, we push off the less important changes and features to later stages. Even if we don't get to implement everything, we haven't ruined the essence of the system.
The most important factor, aside from early identification of risks and prioritizing requirements, is the early feedback from the actual users regarding system performance and field testing. Adapting the system to the operational requirements in heavily software based systems and CCS's in particular, is itself a risk. Early integration of the basic components enables field testing, drawing conclusions for further trips around the spiral, and a more accurate appraisal of the status of the project. This approach combines the fighting echelon in the development process and ensures better adjustment to the user, (Voice of the Customer). "An effective Command and Control ensemble consists of a combination of well trained manpower, coherent doctrine, and high quality automation".
The spiral model helps reduce the time required to launch a product into its work environment and to adapt that product to the operational requirements and the experience gained with its use.
A similar approach to the spiral developmental model can be found in the words of General (Ret.) Dr. Ben Yisrael regarding Command, Control, and Intelligence Systems: "Reducing the time factor must be one of the major goals in every developmental policy. Contrary to widespread belief, this goal is often attainable." Ben Yisrael recommends that the time coefficient for a complete loop be smaller than that of doctrinal changes and operational requirements. Furthermore, it should be smaller than the term of office of the project staff. In his opinion, "CCS development that lasts too long is almost predestined to failure."
The spiral model is especially fitting for cases where much change is expected during the course of development. However, application of the spiral development model with a "Fixed Price" pricing concept is more difficult in projects that are not developed in-house, and which require specification, content, and contract to be drawn up in advance. Bohem points out the difficulties with contracts that are not "Design to Cost"as required by the classic spiral model. He suggests widening the model to accommodate Fixed Price. In the author's opinion, even when using Fixed Price pricing with external contractors, the spiral model has important advantages. Amongst them are: a focus on the most important features and delay of change to the later stages, creation of a cash flow that reflects the operational yield, creation of motivation to keep the project team together, and more.
The spiral model has limitations and disadvantages that were not discussed by Bohem in the document in which he presented the model. The most popular model in the early 90's, particularly amongst the world's defense contractors, was the "Waterfall Model" . The waterfall model assumes that "there are no small software changes" and that "the cost of change rises exponentially as a function of time". Accordingly, the principals of the waterfall model were set such that all requirements must be defined without any uncertainty prior to the design and coding stages and all features are developed concurrently (This model has since been refined and made more flexible). The spiral model does not relate to the overhead due to duplication and repetition of testing at each full cycle of the spiral. Development with the spiral concept requires an architecture that supports change thoughout the development process, like that described above. It also requires automated testing so that testing is possible with relatively little effort and automation in the area of version release. Since CCS's are expected, by definition, to change, it is important to prepare for version release and iterative processes in advance.
Projects developed with the spiral model must have change-tolerant architectures and testing automation so that the overhead due to rounds of testing and version creation are minimalized.
Development in stages was the central approach to developing CCS in the Israeli Navy. It caused a dynamic prioritization of operational requirements such that the important requirements were implemented first and the phenomenon of implementing unneeded features was negligible. The model enabled analysis of the product that had been already delivered to the (fighting units) end user, drawing conclusions, and adapting the work plan of the next spiral cycle according to the lessons learned.
Developing the system in small stages enabled minimization of the risks in the decision-making procedures in the Navy's management. The Defense Department's comptroller examined this approach and wrote "Developing the CCS system in small cycles, while simultaneously proving its technical and operational abilities, proved itself a was great contribution to the success of the development and its application in the Navy."
Conclusion
The CCS's in the Israeli Navy are one of the most important components of the Navy's strength and its advantage against hostile nations. The quantity of data, the rapid speeds, and the complexity of the weapons systems require rapidly building the correct tactical picture and synchronizing the weapons systems so as to take maximum advantage of the capabilities and resources of the weapon systems and the fighting force.
CAPT. Natan Barak has a B.Sc. In Computer Science and a M.S. is Business Management plus more than 20 years experience in weapon systems development both in in-house development and with the defense contractors.
CAPT. Barak was the commander of the Israeli Navies C4I Unit.
click here to return the articles page
|
|
|