Defense Software: Looking Beyond Openness

This article considers defense software issues raised by the adoption of UK MoD and US DoD open architecture initiatives and the impact of disruptive multi-core technology. This article is the second part in a three-part series on open architectures. << Part 1: The goals of open architecture initiatives Issues for Discussion We would argue that whilst both the DeRSCI and ARCI initiatives have had obvious success, the major win has come from the adoption of COTS equipment and that there are still some issues which require further discussion and possible refinement.

The topics raised below address some areas which may not seem directly related to defense software openness per-se, but are for the most part quality related issues that will affect the way that MoD/DoD go about their business. We are therefore arguing that the patient should be considered holistically!

Arrival of Multi-core

The adoption of COTS coincided with a sustained growth in CPU clock speeds and this created a near ideal environment for the approaches taken. Throughout the period, CPU speeds increased steadily, de-risking and simplifying defense software upgrades and extensions, and it was only towards the end of this epoch that 64 bit CPUs appeared (first technical challenge and largely ignored by DeRSCI at least).

Stakeholders could have been forgiven for thinking that this ideal state of affairs could last for a very long time; but storm clouds were gathering.

The final leveling off of CPU speeds prompted Herb Sutter (chair of the ISO C++ committee) to publish his landmark article “The Free lunch is over” in March 2005, it opened with an abrupt wakeup call;

“The biggest sea change in software development since the OO revolution is knocking at the door and its name is concurrency”.

He added;

“Not only are today’s languages and tools inadequate to transform applications into parallel programs, but also it is difficult to find parallelism in mainstream applications, and—worst of all—concurrency requires programmers to think in a way humans find difficult.”.

The Internet is buzzing with similar warnings from similarly authoritative sources.

This not only means that significant portions of existing defense software need to be re-written to work efficiently with multi-core, it also means that it needs to be written in such a way that it doesn’t need to be over-hauled every time the number of cores increases (expected to happen regularly for some time to come).

The figure below gives an indication of the generally accepted landscape (Intel and AMD’s web-sites provide their very latest roadmaps). Whilst increases in CPU speed were considered to be highly benevolent, increases in core population are generally considered highly malevolent (from a defense software developer’s perspective).

Dependence on Standards

The arrival of multi-core has focused most engineers’ minds on two fairly obvious points:

Firstly, a lot of standards assumed by defense software openness initiatives are about to change. Large networks of Ethernet connected cards are about to be replaced by massively faster on-chip communication, so even TCP/IP is expected to be replaced by the new multi-core equivalent (TIPC) for a wide range of cases. This will obviously raise question marks over other standards like DDS and web-services for use in a 21st century on-chip world.

Secondly, and more profoundly, it suggests that reliance on any present day standard is a very high risk option. If a defense software application calls an operating system directly, assumes a device, a protocol or any other standard, it can become locked into it, and may become obsolete as a result. The DeRSCI open architecture initiative has barely published its conclusions and already 32bit Pentium Xeons are last years news, 64bit is here, and even multi-core is unlikely to last the 20 or 30 years required by the military (FPGAs are now looking very interesting).

The AUTOSAR openness initiative however advocates abstraction of the underlying platform, and since their applications do not assume present day technology, they are unlikely to be tied to it for a very long time to come.

Performance

Most would agree that if power consumption, heat, weight, space, cost or mean-time-between-failure are issues then reducing hardware volume through defense software efficiency is paramount. However, some have taken the view that performance is unimportant when compared to openness considerations (use of XML for example).

Those that would see this as a tad cavalier point out that defense software performance doesn’t matter to you unless it turns out to matter to your adversary and if they can extract higher fidelity information from the same technology constraints it could end up mattering a lot. Openness and performance are clearly not mutually exclusive and a balanced compromise should clearly be sought. There are a number of areas where these ideals could come into some degree of conflict;

Multi-core will bring with it a whole raft of performance issues. For example, many widely adopted protocols (e.g. TCP/IP) force the movement of data between sending and receiving objects. When a sonar demonstrator was recently executed at the Intel site in Swindon UK (32 way SMP), the communication overhead for the message passing variant, was more than 300 times that for the reference based equivalent.

The context switching rate between processes is typically a hundred times slower than that between threads, and this will no doubt be a matter of contention when people start pointing out the benefits of integrating defense software “within a single process”.

Another potentially contentious issue is the UK MoD’s CPU redundancy rule. This states that CPUs should not be more than 50% loaded and therefore immediately halves the performance that can be achieved for a given platform. Although it was introduced for very good reasons, the situation has changed in a number of respects;

Modern processors (especially cache based architectures) are extremely complex, and in truth very few engineers could meaningfully estimate how long it would take their PC to invert a large matrix of a given rank purely from the manufacturers specification alone.

Not only that but multi-core is going to make performance even harder to predict because of uncertainties introduced by Amdahl’s law, load balancing, and various scheduling latencies. Many have argued that the so called 50% redundancy is seldom usable anyway and in truth could just as likely be due to poor scheduling as deliberate planning.

Unless the defense software developer can show their application running twice as fast with all CPUs loaded, it is unlikely to be a usable contingency anyway. There could be a strong case for doing away with the existing limitation altogether and instead mandating software scalability as part of some broader quality enforcement scheme (more on this below).

Single Source Suppliers

It might also be worth reviewing the ‘single source supplier’ situation because in practice the industry (UK at least) has continued to use Microsoft products, Greenhill’s Integrity, UML IDEs with sole-supplier features (that don’t necessarily interoperate with alternatives) and many other single source products without incident, and provided smaller suppliers are happy to provide their source in ESCROW, this would appear to be an unnecessary restriction which has proven difficult to apply in practice.

If we include suppliers who provide common standards like TCP/IP, but exclude those who have the only solution for a chosen hardware platform (therefore single source in every practical sense), then the innovation and flexibility of choice currently provided by COTS could well be stifled. A lot of today’s mainstream innovations started life as single source product.

Architecture Granularity

The DeRSCI sonar Generic Open Architecture (GOA) study (version 4.1) identifies four defense software sub-systems for passive sonar and concludes that a finer granularity would make the number of interconnections “untenable” (in this case it is three). The AUTOSAR openness initiative (ref [4]) by contrast, opts for a much finer granularity.

We would argue that the GOA proposals need revisiting for both technical and business reasons, and furthermore, believe that the feasibility of the finer grain case is demonstrated by AUTOSAR.

The GOA proposes interoperability at the level of a passive sonar signal processing module and since each of these is ‘particular sonar specific’, there will for example be a requirement for contractors to deliver a 2054 signal processing sub-system.

However, since there is only one customer for this, it is difficult to imagine contractors that lose the initial bid being motivated to produce one anyway (just in case the customer wants one in the future). This may mean that the customer will have only one supplier (after the bid) and unless they own the delivered source, and it is suitably documented, could be just as locked-in as they always were.

The AUTOSAR openness initiative on the other hand, opts for components at a granularity for which they have more than one application, which encourages more than one solution (lots of companies produce batteries, bulbs, bolts and spark plugs because lots of products use them).

The GOA implies that the AUTOSAR openness approach is too difficult (untenable) but there is strong evidence that this is not the case.

The figure below shows a property of most component based systems, which is that as granularity becomes finer, structure becomes more uniform. In fact if we go down to the sub-atomic particle extreme the entire Universe is constructed from a handful of highly re-usable fundamental particles!

Just as many diverse electronics applications are composed from the same resistors, capacitors, chips etc., so many defense software applications are composed from the same software components. In particular, passive sonar are constructed from FFTs, filters, loggers, and many other re-usable software sub-components. AUTOSAR capitalizes on this, whereas the GOA does not.

Component interfacing technologies have progressed considerably in the last few years and it is easy to take for granted the fact that we can cut a Visio diagram from a Power Point presentation, and paste it straight into a Word document without being unduly concerned about which version of Visio, Power Point or Word we are using.

Clearly this particular technology is unsuitable for sonar interfaces but it highlights the art of the possible and makes a case for including technology in what are currently process led initiatives. We argue strongly for replacing all paper interfaces with formal machine managed alternatives and have already demonstrated the feasibility of the approach for in-service sonar (e.g. sonar 2170).

The time savings and accuracy afforded by machine automation vastly improve the interoperable grain size and therefore considerably increase defense software re-use and competition.

>> Part 3: A Proposal for Improving Defense Software Quality