r=black height=1> Yahoo! is not affiliated with the authors of this page or responsible for its content.
11TH ICCRTS COALITION COMMAND AND CONTROL IN THE NETWORKED ERA 11TH ICCRTS
COALITION COMMAND AND CONTROL IN THE NETWORKED ERA

Architectural Description of the UK Common Core Combat System

Topic C2 Architecture

Dr Lyn Owen
(Point of Contact)
QinetiQ
Winfrith Technology Centre
Dorchester
DT4 8XJ
Telephone +44 1305 212996
LOwen@QinetiQ.com


Dr Rodger Manning
QinetiQ
Winfrith Technology Centre
Dorchester
DT4 8XJ
Telephone +44 1305 212450
RAManning@QinetiQ.com


Ms Claire Burt
Dstl
Winfrith Technology Centre
Dorchester
DT4 8XJ
Telephone +44 1305 256025
CMBurt@dstl.gov.uk


Dr Andrew Flinn
Defence Science & Technology - Underwater Systems
British Defence Staff
British Embassy
3100 Massachusetts Ave, N.W.
Washington. D.C.
Tel: 202-588-6727
Andrew.Flinn@moduk.org



ABSTRACT

In 2005, the UK embarked on a major new initiative, the Common Core Combat
System (CCCS), to deliver a new open architecture and COTS-based combat system
for Royal Navy submarines. The initiative is a collaborative programme bringing
together DEC (UWE), DPA, DLO, Dstl and UK Industry to drive down cost of
underwater platforms and to support reuse and capability insertion.
The CCCS will comprise common platform networks, interfaces and equipment fits to
be introduced incrementally to all RN submarines The approach is radical in that it
seeks to put in place an architecture that can evolve over the life of the platforms.
The CCCS Architectural Description is being developed incrementally and is widely
peer reviewed by a consortium of UK industry under MOD governance.
A CCCS Testbed is proposed to validate the architecture and to de-risk the CCCS
programme. The Testbed includes innovative components developed via a series of
research strands including open architecture sonar and tactical and environmental
data servers.
The paper describes the major drivers of the CCCS architecture, the architecture
itself and shows, using the example of the Testbed, how instances of the architecture
are used to generate specific system designs for individual incremental builds of the
CCCS through time.

INTRODUCTION

The UK currently has several unique classes of nuclear powered submarines in
service of which no two have the same combat system configuration. Each combat
system variant can be defined by the core combat system equipment i.e. Sonar,
Command System and Data Highway resulting in around nine unique equipments
which have to be supported. Therefore, there is the potential for saving support costs
and manpower if the three variants can be reduced to one Common Core of
equipments.
In 2005, embarked on a major new initiative, the Common Core Combat System
(CCCS), to deliver a new open architecture and Commercial Off-The-Shelf (COTS)-
based combat system for Royal Navy submarines. The initiative is a collaborative
programme bringing together DEC (UWE), DPA, DLO, Dstl and UK Industry to drive
down cost of underwater platforms and to support reuse and capability insertion.
The main aim of the CCCS programme is thus to introduce commonality within the
combat system design across the Submarine Flotilla. In addition, the CCCS
programme must ensure that the architecture is sufficiently flexible and adaptable to
allow cost-effective sustainment, upgrade and extension to include other combat
system equipments as the opportunity or new requirements arise.
This goal is being achieved by utilising new developments in open system design
principles and open system architectures, and by exploiting standards-based
computing technologies from the COTS marketplace.
The policy statement from DEC (UWE) states:
The Common Core Combat System is to be a co-ordinated programme to
achieve reduction in whole life costs. CCCS will deliver the system
engineering and software development outputs, necessary to consolidate
separate Sonar, Command System and Data Highway initiatives into a coherent Common Core Combat System for RN submarines, based on open
systems

The CCCS will comprise common platform networks, interfaces and equipment fits to
be introduced incrementally to all RN submarines.
The approach is radical in that it seeks to put in place an architecture that can evolve
over the life of the platforms.
Another area of innovation is that a CCCS Architecture Authority Working Group
(AAWG) has been set up to produce and control the architectural specification.
Chaired by the MoD, this is also attended by representatives from a wide range of
UK industry.

MAJOR ARCHITECTURAL DRIVERS

A primary requirement for the architecture is openness, but openness is really an
enabler: an umbrella concept that is fed by a number of key architectural design
criteria and which yields a range of significant benefits.
It could be said that openness makes some things easier. These include portability,
evolvability and so on. The special needs of the CCCS mean that openness is
particularly required in three critical areas: evolution, variation and support to
procurement.
Evolution
The architecture must allow the specification of an initial procurement of CCCS
components but be sufficiently forward-looking as to be applicable to future systems
and the incorporation of new capability. The architecture specifies a future increment
of the CCCS - in other words a Vision System. This has been done quite deliberately:
without being forward-looking from the very start it will be very difficult indeed to
break out of the structural mould of current combat system design.
Variation
The architecture, and the systems from which it is built, must be applicable to the
complete range of UK submarine platforms with their differing equipment fits.
The architecture is a generic architectural vision for the future UK submarine combat
system, describing a common core of functionality. It is the job of the system
integrator and subsystem suppliers to take this specification and use it to generate a
system design specification for a particular increment of the combat system on a
particular platform.
A significant outcome from this vision system concept is that bridges to legacy and
other equipments are currently not included in this specification. They are regarded
as temporary interfacing components that are needed to interface from the legacy
systems to the evolving common core. Bridges are the province of the system
integrator and subsystem suppliers and their system design specifications.
Support to Procurement
As well as guiding the more detailed and lower level design of the system, the
architecture must provide input to Invitation To Tender (ITT) documents to ensure
that the CCCS subsystems that are to be procured will work together effectively and
achieve their aims. In other words the architecture must provide input into
contractually-binding specifications that ensure interoperability. The architecture provides source information which can be used to aid the
procurement process. It can be referenced from ITTs or, more appropriately, its
content can be used as a basis on which to write requirements, especially openness
requirements, and to inform the tender assessment process.
In order to achieve a coherent and open design that ensures interoperability between
its parts, the architecture needs to state bold decisions. Some of these architectural
decisions must be mandated; others may be regarded as advisory This paves the
way for an architectural compliance process in which the submissions of the bidders
for the CCCS subsystems and the application components might be assessed
against their willingness to adopt the tenets of the CCCS architecture.

THE FORMAT OF THE ARCHITECTURE

The architecture is currently being defined as the CCCS Architectural Description
(AD) using Standard IEEE 1471 Recommended Practice for Architectural Description
of Software Intensive Systems. This describes a process for generating a framework
for an architectural design based on the definition of a series of viewpoints. The
following viewpoints have currently been specified for the CCCS AD and these have
been grouped into the six domains shown in Table 1.

Domain
Viewpoint
Overview
VP.O.1 CCCS Architecture Strategy
A high level description of the major CCCS architectural concepts
VP.S.1 Context and External Interfaces
Boundary of the CCCS and identification of all external interfaces
VP.S 2 Granularity
Definition of the subsystems that make up the CCCS
VP.S.3 Physical Data Model
Physical data model covering the major data elements of the whole
CCCS
VP.S.4 Subsystem Services
For each subsystem, the particular set of services it must provide
to other subsystems and the ones it will require to carry out its
function
VP.S.5 Service Definitions
Detailed definition of every service: its data, protocol, security etc
Structural
VP.S.6 Subsystem-Centric Service Connectivity
For key subsystems, a service connectivity diagram showing how
the particular subsystem interacts with all other subsystems via the
services it provides and uses
VP.B.1 Operational
A set of key UML use cas