|
By
Ulf Olsson
Senior Scientist
CelsiusTech Systems, Naval Systems
When the groundwork for the Ship System 2000 was first laid out, it was a bold architecture in many ways. The dual LAN, the Multi-Function Consoles (operator workstations), the fully distributed
processing scheme -- as well as the whole idea of using a "software first" approach -- were unheard of in the application area. These days, however, such features are quite common, at least in proposed designs. Thus, it seems that the design choices we made were correct, not only because we now see that they work, but the rest of the industry has made
the same decision.
Of more interest to those interested in Ada, however, is obviously the strategies we selected in the software area. We chose four cornerstones for the software architecture:
- a distributed runtime structure based on many programs, communicating via asynchronous message passing to provide independence of hardware configuration;
- Ada as the implementation language and the Rational Environment as the toolset. Both were chosen because we felt that they provided the essential capability to build and maintain a large-scale software system (several millions lines of code);
- reuse-oriented dependency network: we carefully engineered the layer of components so that the likely changes - different combinations of sensors and weapons, different Man-Machine interfaces, different doctrines - would not break the design;
- object-orientation as a set of rules of thumb rather than a religion: this being the best way to design long-lived Ada interfaces.
The purpose of all this was to create a family of software components that would allow us to combine assets for many different customers and ship configurations without having to modify existing, tested and dependable code. This has turned out to be a major success: we have a
large number of system configurations in the field, and an even larger number has been studied for various proposals. We regularly see reuse (or rather commonality) that rates well in excess of 80%, which has led to some rather interesting effects on our personnel structure. As we
now design with reuse rather than for reuse, the production of code becomes less and less of a problem. (Note that this is exactly the opposite of what was supposed to happen in the Software Crisis scenarios!) Instead systems integration personnel and people with a very good knowledge of the end user and his/her problems now dominate our workforce.
Ada's Contribution
Ada itself has contributed significantly in this process. It turned out to be possible to focus on architectural decisions -- layering structures, minimizing, and structuring dependencies, etc. -- and capture those fundamental decisions in Ada specifications. The fact that the most concrete representation of the essence of the architecture is in Ada means that there is much less risk of design rot setting in. Ada makes it really hard to do something, that goes against the intentions
of the original designers!
Ada has also proved itself in the most important area: maintenance. We now have considerable experience that says that it is possible to successfully maintain very large volumes of Ada code, even when the teams have changed members over the years.
It must be noted, however, that the cost of reuse is not zero, as you might be led to believe from some of the myths surrounding it. Basically, you must invest in training so that the new designers have a solid feel for the Software Engineering principles involved, as well as becoming acquainted with the capabilities present in the architecture. If you forget to train your people - and it is more expensive than you think! - reuse will not happen, because they will not know what to reuse, or how.
The Project
Does Ada perform, then? Yes, indeed! Initially we hedged our bets, and kept the option open to recode performance-critical parts - ballistics calculations, for instance - in assembly. However, with no such recodings at all (but using a Floating Point Processor), we now have extensive test firings that prove that this system generation shoots about twice as well as the older systems (which were -- and still are -- extremely accurate)! For us, this conclusively proves, that it is
possible to use Ada - and LAN-based systems. For the most demanding real-time applications.
Nevertheless, it must be noted that this did not happen by itself. Ada is good at hiding the implementation from the user, so ways must be found to communicate to the coder the cost of the
primitives he/she is using, otherwise you end up with code that provides the right functionality. but with unacceptable performance. Another very useful aspect of Ada is its portability. We have now successfully ported the architecture to several hardware and OS platforms, proving that what we have built will be useful assets in the future.
Coming back to the question mark in the title: did we find a pot of gold at the end of the rainbow? Yes, we believe we did. Firstly, we know from several evaluations that we are consistently ranked highest on technical merits. Secondly, our application software is "future proof," we know that it will run well on coming generations of hardware. Thirdly, we can demonstrate high and consistent performance.
It has taken time and a lot of effort to get here, but as I hope I have made myself clear. The results have been well worth it. And it is my personal conviction that without Ada, it would not have been possible at all!
Ulf Olsson, Senior Scientist
CelsiusTech Systems, Naval Systems
S-175 88 JARFALLA, SWEDEN
Phone: +46-8 58 08 40 00
Fax: +46-8 58 03 22 44
Email: ulol@celsiustech.se
|
