Open Architecture – Technology, Process or Both?

This three-part article considers the UK MoD and US DoD open architecture initiatives; as realized by the ‘Delivering Rapid Sonar COTS Insertion’ (DeRSCI [1]) and ‘Acoustic Rapid COTS Insertion’ (ARCI [2]) initiatives respectively. The reader should be aware that this article was kindly provided by Connective Logic Systems and while every effort has been made to present an objective view, the views expressed herein should be considered as the opinions of CLS.

Both DeRSCI and ARCI have addressed sonar technology (e.g. DeRSCI’s sonar Generic Open Architecture), but the underlying principles are clearly applicable to a very broad range of military programs and the experience gained in pursuit of both programs could have the potential to influence future thinking considerably.

In both cases, these open architecture initiatives are ‘technology light' when compared to the commercial AUTOSAR initiative (see ref [4]), and achieve most of their efficacy through adoption of agreed process. This article considers what has been achieved to date, what could be achieved in the future, and in particular, the possible benefits of an open architecture centric technology.

There is very little doubt that the migration to COTS platforms in particular has been extremely successful, but it might still be worth asking if all the original goals have been fully met, and whether there is actually more work that could be done to improve the situation still further.

Original Goals

The ultimate goals of most technology initiatives are to reduce cost and risk, and increase capability and lifetime. It is important to differentiate the ‘ultimate’ goals of the problem, from the ‘analyzed’ goals of a particular proposed solution. Despite the fact that most people now have fridges, some people continue to eat fish on a Friday, long after the reasons to do so have been forgotten.

The adoption of open architectures as defined by DeRSCI and/or ARCI is believed to address the ultimate goals, but was clearly not intended to become an end in itself. In this case, the agreed way forward was to address a number of specific areas which were perceived to be the key issues.

Bespoke solutions

Twenty years ago in the mid-eighties the prevailing view within most militaries was that COTS solutions were simply not practical. There were a number of reasons for this view, and at that time, most of them probably held water. But the arrival of cheap, powerful, reliable, robust, sophisticated technology during the eighties addressed most of the perceived concerns and inevitably led many to re-appraise the situation.

Attention now turned to the problems associated with bespoke solutions (hardware in particular), most notably, the issues associated with ‘low volume’ manufacture. These included extremely high unit cost, supplier lock-in, and last but not least; small user bases.

With few users there was little incentive to develop sophisticated software tools, and furthermore, potential flaws could take a very long time to be identified (the more users a component has, the quicker its flaws will be found). Finally, because of cost and availability, engineers often ended up with limited access to target hardware which meant that day to day development and maintenance was less efficient than it could have been.

Platform Lock-in

Worse still, the software developed for these platforms was typically hardwired to their architecture, protocols and topology (mapping of functionality to processors). Even minor capability upgrades could involve major software re-engineering, let alone hardware upgrades, which frequently involved complete re-writes.

If the platform became obsolescent, the anticipated software re-use seldom actually materialized. Re-use not only saves money, it also leads to increased reliability (new software means new bugs).

Contractor Lock-in

Competition is generally considered to be healthy and if the extended system lifetimes that the initiatives sought were realized, then it was considered important to avoid lock-in to the original contractors.

Extendibility

This refers to the frequent requirement for a system to be provided with additional functionality, or perhaps to just upgrade some existing functionality. This typically raises two issues.

Firstly, the addition of new functionality often meant that existing (legacy) code needed to be modified. As well as the cost implication, there was the risk of introducing new bugs into old code, and furthermore, the requirement to modify legacy code could also increase reliance on the original contractor.

Secondly, and more annoyingly, any extension or upgrade could increase CPU load and in the worst case, could mean that the hardware topology needs to change (e.g. add more CPUs). This leads to a problem which is frequently underestimated; topology dependence.

In a nutshell; if two components execute in the same process they typically communicate by reference, if they are in the same address space but different processes they use data passing, and if they are in disparate memory spaces then they usually adopt message passing. If the hardware topology changes, software components may need to be re-mapped to the new hardware, and any interfaces that experience a proximity change can require extensive re-working.

The UK MoD were so concerned about this problem that they introduced a rule which prevented CPUs from being more than 50% loaded (as a possible contingency mitigating against topology change). Interestingly this is still largely applied and continues to double the hardware requirement despite the problems of heat, weight, space, power consumption, points of failure, cost etc.

Availability

Although less of a mainstream concern (but nonetheless an issue) the inability for many systems to survive the loss of hardware functionality reduced the mean time between failures for mission critical systems and compromised effectiveness in the field.

Obsolescence

Hardware obsolescence is arguably a fact of life for organizations that need a competitive edge (last decade’s hardware often needs upgrading for performance reasons alone) but software obsolescence on the other hand is regarded as a fairly serious problem.

In practice applications were frequently locked into their existing platforms and optimism for software re-use was often found to be somewhat misplaced. The terms ‘portability’ and ‘scalability’ turned out to mean different things to different parties.

Current Solution

The adopted open architecture solutions to the issues raised above are similar for both initiatives. In essence they are routed in ‘process’ rather than ‘technology’, although the ARCI program did utilize DSR’s MTM middleware in its early stages (we understand that this is no longer the case).

This is in contrast to the AUTOSAR commercial open architecture initiative (automobile standard – see ref [4]) which includes both technology and process. Whilst it is not meant to be in any way disparaging, both DeRSCI and ARCI are essentially process oriented (analogous to eating fish on a Friday), whilst AUTOSAR is essentially technology oriented (analogous to developing a fridge).

Both DeRSCI and ARCI could be broadly considered as having three separate strands that could be (very) briefly summarized as;

Use of COTS Components

Both open architecture initiatives propose adoption of COTS components wherever and whenever possible and both appear to have made considerable cost savings as a result. In addition, both programs have further capitalized by adopting hardware ‘commonality’ across their respective systems.

Adoption of Standards

There are a number of arguments for the standardization of platform characteristics such as operating systems, math libraries, discovery service, communication protocols and processors. These include;

• Most standards are available from more than one supplier which can reduce lock in.
• Standards tend to be portable which mitigates obsolescence.
• If they are open source standards then this further reduces risk.
• Standardization of hardware supports the ‘commonality’ goal.

Open Architecture

One of the more interesting aspects of Rapid COTS Insertion (RCI) initiatives in general is the notion of open architecture. Basically the idea is that the overall system is split into sub-systems, each with a mandated interface. The Generic Open Architecture interface definition for example, specifies;

• Component granularity (identifies sub-system break down)
• Communications hardware (Ethernet etc)
• Communications protocols (TCP, UDP, DDS, web-services etc)
• Data content (XML descriptions etc)

The argument is that partitioning the task into smaller components promotes competition. So if contractor A supplies the 2054 signal processing sub-system and the customer wants it extended or migrated to a new platform, the task can be thrown open to competition; because it’s argued, there will be many providers of 2054 sub-systems.

>> Part 2: Shortfalls of the basic open architecture solution