See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/252557510

A Multi-Layered Approach to the Development of Custom Tactical Data Link

Applications

Article

CITATIONS READS

0 176

7 authors, including:

Ray Dawson Steve Probets

Loughborough University Loughborough University
100 PUBLICATIONS   1,232 CITATIONS    41 PUBLICATIONS   919 CITATIONS   

SEE PROFILE SEE PROFILE

Julian Johnson Suraj Ajit

Holistem Ltd. The University of Northampton
15 PUBLICATIONS   42 CITATIONS    21 PUBLICATIONS   71 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Incose mda View project

SEDRES View project

All content following this page was uploaded by Ray Dawson on 17 June 2014.

The user has requested enhancement of the downloaded file.

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

A Multi-Layered Approach to the Development of

Custom Tactical Data Link Applications
Mr Darren Clowes1, Prof. Ray Dawson2, Dr Steve Probets3, Dr Julian Johnson4 , Mr Chris Holmes5 , Mr Suraj Ajit6,
Mr Rupal Chauhan7
1
Loughborough University, UK, d.clowes@lboro.ac.uk
2
Loughborough University, UK, r.j.dawson@lboro.ac.uk
3
Loughborough University, UK, s.g.probets@lboro.ac.uk
4
BAE Systems, UK, julian.johnson@baesystems.com
5
BAE Systems, UK, Ck.Holmes@baesystems.com
6
BAE Systems, UK, suraj.ajit@baesystems.com
7
BAE Systems, UK, rupal.chauhan@baesystems.com

Abstract
At BAE Systems project teams are working on Tactical Data Link (TDL) development at every stage of the systems development
lifecycle, from concept through to maintenance. The TDL domain is document intensive, the standard for Link 16 alone is over
7000. Platforms are then also required to produce their documents based on these standards. This paper discusses the two main
activities being undertaken by the team at the Systems Engineering Innovation Centre in relation to TDL tools. These activities
are focused on research and exploitation of previous research. The two activities have differing demands and priorities. As such
a shared common multi-layer architecture is proposed for the development of applications under either activity. The architecture
has been developed into 4 layers consisting of presentation, business logic, data access and data storage, with custom business
objects used to pass messages between layers. Having discussed the multi-layered architecture it is evaluated with respect to the
benefits brought to the two activities. In particular it discusses the difficulties in sharing the architecture with Telelogic DOORS
developments and the benefit of the ability to move functionality from research to exploitation quickly.

Keywords – Multi-Layered Architecture, Software Engineering, Web Engineering.

1 Introduction 2.1 Tactical Data Link Domain

Increasingly the design of complex engineered products and
systems (here within referred to as systems) are becoming
more reliant on computer-supported models/representations
of information. One such domain is Tactical Data Links
(TDLs) within Military Standards. At BAE Systems they
have been conducting research into developing new tools to
aid Tactical Data Link Engineers since 2005. Currently the
work has two focuses, a research focus and an exploitation
focus. These focuses have differing demands and activities
with the aim being to exploit as much research development
as quickly as possible to achieve a high return on
investment. Two key areas of work currently are the
research work into hybrid semantic-document models, and
the exploitation work into deploying TDL model-based
techniques to the engineers.
The TDL domain is a collection of related technologies
designed to work within the command, control,
communications, computers, and intelligence (C4i) domain
used in the dissemination of information within a
battlespace to support joint and combined operations. Due
to the nature of these operations several variations have
been evolved to interface with specific unit types within the
battlespace. As such, the TDL domain is often referred to as
a family of standards. The US Department of Defense
identifies these variations of the TDL (TADIL) domain via
a postfix identifier (A, B, C, F, J, K, and M). These
variations may differ in waveforms, bandwidths, protocols
and capabilities. For the purposes of this pilot study Link 16
or TADIL-J standard will be used, this is described in MIL-
STD-6016C.

This paper provides an overview of the two main areas of
work and discusses the advantages of developing a multi-
layered architecture to aid BAE Systems in both its research
and exploitation activities in the TDL Domain.
2 The Environment
An overview of Tactical Data Links (TDLs) and the
business activity and organisation is provided to aid in
understanding the requirements and need for a shared
architecture.
The TDL standards are written to cover the full spectrum of
applications. When a TDL is to be implemented on a
platform (generically used to refer to the asset that the TDL
is being integrated into i.e. ship or aircraft), only the
required subset for the platform’s role is implemented. For
example a transport aircraft does not need the fighter and
bomber specific messages, so they are not implemented.
Link 16 does not define platform roles and, as such, the
subset selection is determined by the platform
implementation team. Due to this, every platform is

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
required to produce additional documents based on the
standard.
The MIL-STD-6016C suffers from a number of
shortcomings, the most significant being:
 It is a huge document (over 7300 pages).
 Data is duplicated across many sections and
appendices.
 The sections and appendices are often
interdependent
 Requirements are expressed in a mixture of natural
language and semi-formal prose.
 Some of the notation leads to ambiguity and is
potentially incomplete and inconsistent.
 It is not suitable for machine checking.
2.2 The Business
Tactical Data Links are developed and used across a whole
range of projects/platforms at BAE Systems. The primary
stakeholder for this work is currently Military Air
Solutions; however the work is applicable to any project
requiring the use of TDL information. Project teams are
working on Tactical Data Link (TDL) development at every
stage of the systems development lifecycle, from concept
through to maintenance. As well has being distinctly
separated by the systems development lifecycle stage each
project operates independently resulting in a unique set of
tools being used by each project. In addition two variations
of standards for Tactical Data Links are used across the
projects, the NATO STANAGs and the US Department of
Defence MIL-STDs. The documents are similar with
approximately 2 STANAGs encompassing the same data
that is in the MIL-STD 6016C.
With regards to projects using different tools, the only
common tools related to TDL document are Microsoft
Word and Adobe PDF [1]. A variety of other tools are used
by projects ranging from Matlab to Mandril. More recently
some projects have been moving their TDL material into
Telelogic DOORS. At present just over half the projects
involved in this work are using DOORS with the majority
of the other projects envisioning using the software in the
future for TDL documentation. As such DOORS is a
powerful tool that will be readily available to the majority
of engineers.
At the Systems Engineering Innovation Centre, BAE
Systems have been conducting research into TDL related
improvements for a number of years. Recent research work
has been undertaken to develop a semantic model of the
TDL standard documentation [2]. The current focus is
investigating the possibility and benefits of developing a
hybrid semantic-document model. Elements of each
research project have traditionally been developed in a
tool/technology must appropriate, which has resulted in a
mixture of technologies being used ranging from C#.NET
and Python to SQL Server and XML. Any architecture
which can still support the legacy developments would also
be highly beneficial.
Loughborough University – 20th - 23rd April 2009
The latest research is investigating the topic area of Hybrid
Semantic-Document Models. The hybrid models work is
directed at pushing the boundary, feasibility and
exploitation of a hybrid model (between a semantic and a
document model) approach to representing a complex
system domain. It aims to combine an underlying semantic
model with mapping to a document model to act as a
vehicle for driving out an unambiguous understanding of a
complex domain that is currently represented in a
convention document-only based format. The development
of the architecture has been heavily influenced by the work
in this area, and its legacy components. A common shared
architecture means that work exploitable from this area can
easily be transferred to business applications.
The latest exploitation work is utilising the Semantic
models [3] which underpin the work on Hybrid semantic-
document models to gain some immediate exploitation.
Such work includes automatic detection and generation of
Human Machine Interaction (HMI) requirements, which
has traditionally taken weeks of work by hand on some
projects. Initial investigatory work has also been used to
demonstrate basic interoperability assessments by
comparing two different project’s documentation, processed
through the model to detect differences. Most recently the
team is developing interfaces and techniques to deploy such
functionality through the Telelogic DOORS systems as this
is seen as a cross project tool that can be used to quickly
deploy an exploitation from research discoveries.
An approach to allow rapid exploitation of enhanced
functionality obtained from the latest research across
multiple projects is required to achieve maximum return on
investment. The approach should also support parallel
development of multiple research topics with ideally little
legacy redevelopment.
3 The Architecture
Multi-layered architecture design can be applied to various
stages and elements of any development, from the design of
multi-layered interfaces [3,4,5] to the design of the software
architecture itself [6,7,8,9]. Multi-layered architectures
usually split an application into usually 3 or more layers.
They are often used for distributed applications such as the
proposed TDL work at BAE Systems. The design of a
multi-layered application is flexible such that the number
and complexity of layers are designed to suit the
application. Spaanjaar’s solution [7] makes use of 3 layers,
Data Access, Business Logic and Presentation where as
Bimber et al. [8] make use of 8 layers.
What is common across any multi-layered design is that
each layer is independent and communicates only with its
connecting layers. This independence allows the
development of functionality in each layer to be low
coupled. Low coupling is a highly desirable feature for any
early stage development project where changes may happen
frequently. Low coupling enables any change to have no or
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
limited impact on other modules within the architecture.
By relying on information to be communicated across
layers this too allows for each layer to be developed in the
most suitable technology and similarly the layers can be
distributed independently allowing for easy and rapid
development of service-oriented architecture applications.
For Web-based applications layers have traditionally
followed the idea of multi-tiered platforms, where by the
data and the presentation devices are distinct pieces of
hardware. As such many web applications are developed
with at least 3 layers, presentation, data access and some
logical layer between.
To achieve aims of rapid development of exploitation and
limited legacy redevelopment, a multi-layered architecture
is ideal. Therefore it is proposed to develop a four layer
architecture which is described by figure 1.
Presentation Application Specific e.g.
Layer ASP.NET, Java C++
Business Logic
Layer
Libraries
Data Access
Layer
Data Storage
Functions Database
Driven
Data Storage
Layer
Figure 1 – Overview of Architectural Layers
3.1 Technology Selection
Previous work within the team had resulted in several
applications being developed in varying languages.
Document parsers where written using Python. The
semantic model was developed using XMF Mosaic which is
eclipse oriented and a web based version of the standard
had been developed using ASP.NET and MS SQL. A
solution which does not require the complete
redevelopment of these legacy applications is highly
desirable. Therefore the solution needs to be able to
interface with various different technologies/languages to
achieve this.
At the beginning of the architecture design, the method for
delivering exploitable functionality to the TDL engineers
was still under investigation. As such the architecture
design and the technology used to implement this design
needed to be as flexible as possible for new development as
well as legacy. The design was heavily focused towards the
developments on the hybrid models web application or a
potential windows based application.
The two main areas of development focus on a web-based
distribution of TDL material and a yet to be decided method
of distribution to engineers. This unknown distribution
could be a desktop application, web-based, or service-
oriented application.
The use of Dynamic Link Libraries (DLLs) allows for
functionality to be encapsulated into a library and shared
across numerous technologies that allow for the importing
of DLL functions. This meant that the legacy developments
would require little re-coding by importing the functionality
from developed libraries. The legacy applications would not
need to be completely re-written into the
technology/language used to develop the architecture. It
also meant any new development could make use of
varying technologies/languages ranging from Java to C++.
This allows the most appropriate technology to be used for
the solution.
As a main area of work in the web-based application used
in the hybrid models work, the two main technologies for
any server driven web application are ASP.NET and PHP.
ASP.NET allows for the easy use of DLLs within web
applications as ASP.NET is essentially a compiled language
written in either VB.NET, C#.NET or J#.NET. Although
the use of DLLs is technically possible in PHP through the
win32api, message boards and email groups are listed with
difficulties and problems. In addition the legacy web
application was developed using ASP.NET. As such this
was selected as the technology for the future web
application development. Similarly a pre-existing MS SQL
server was being used already so this was selected in favour
of any development into other SQL Severs such as MySQL
or Oracle. However the final deployment of any exploitable
functionality may have to be re-engineered to run on
corporate facilities that may force the use of Oracle. As
such the multi-layer architecture should and does support
this as simply, only classes within the layer connecting and
querying the database would need re-working.
There is also a variant of Python compatible with Microsoft
.NET framework, IronPython. This means that the previous
Python development could also be directly incorporated
into the ASP.NET application, and similarly any
development of .NET libraries could be incorporated into
the legacy Python developments. DLLs built via the
Microsoft .NET framework seem to provide support for our
legacy and future developments.
However a key objective of the architecture is to ensure the
technology has the flexibility for future development. If the
architecture was developed such that the layers
communicated by passing Microsoft .NET objects such as
ADO Datasets, then any development must also be part of
or import the .NET framework.
To avoid this situation and enable flexibility, another
library is proposed to store custom objects which will hold
the data and can be passed between the layers. By
communicating using these custom objects from a library,
Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
layers need only know of the library, they do not need to
import the necessary .NET library that deals with the object
set.
As such the technology for the development of the libraries
is completely flexible. Each layer could be developed in a
completely different technology. For this project all the
layers except the presentation will be developed using
C#.NET, as the developers are comfortable with this
technology. The presentation layer will make use of the
most suitable technology for the desired result, and the Data
Storage will be maintained by Microsoft SQL Server 2005.
The semantic models will continue to be developed in XMF
Mosaic and exported to XML before being imported into
the database.
3.2 Implementation
The four layers shown in figure 1 are supplemented by a
custom objects library. The custom objects library contains
all the objects used by the system that are used to
communicate between the layers. Examples of the custom
objects in use consist of a paragraph (from document
model) or a Data Item (from semantic model). Every layer
with the exception of the data storage layer imports and
uses the custom objects in this library. Figure 2 provides an
overview how the layers are designed to communicate.
Presentation
Layer
Custom Objects
Business Logic
Layer
Custom Objects
Data Access
Layer
SQL Query/Result
Data Storage
Functions
Data Storage
Layer
Figure 2 – Communication between Layers
Loughborough University – 20th - 23rd April 2009
The Presentation layer consists of the application coding. In
the web based deployment this consists of numerous
ASP.NET files which query the Business Logic layer to
generate pages of the MIL-STD-6016C.
The Business Logic layer has 3 classes compiled into a
Dynamic Link Library used by the Presentation layer. The
classes are designed to handle aspects of the hybrid
semantic-document models work. As such the layer consists
of a semantic reader class for accessing and reading
information from the semantic model, a document reader
class for accessing and reading elements of the document
model and a document lister class to manage access to
different versions of documents. This layer imports queries
the data access layers to obtain data from the databases.
The Data Access layer has been developed primarily as a
converter. This layer consists of many classes which
request data from tables in the database and convert the
returned data into the necessary custom objects that can be
returned to queries from the Business Logic layer. The
majority of classes have a one-to-one relationship with a
database table, however some classes such as paragraph
have been developed to access more tables. The paragraph
Data Access class also reads the corresponding hyperlink
tables such that any hyperlinks related to the paragraph are
all managed by this one class.
The Data Access Layer could access data from the database
by constructing SQL statements and querying the database
with these or by querying stored procedures. As the selected
database is MS SQL, stored procedures have been
developed, which is why the Data Storage layer in figures
1&2 are spilt into 2 functionalities, the physical storage and
the storage functions or stored procedures.
To demonstrate how the classes and layers interact a
sequence diagram is included in Figure 3. This shows how
the Presentation layer file viewpage requests the
information to display a page of the MIL-STD-606C.
DocModelReader is a class in the Business Logic,
Element_DB and XYZ_DB are elements of the Data
Access Layer and Element and XYZ are the custom objects
holding the data being passed. Note that XYZ is intended to
be substituted with the relevant object given the result of
the element query. It could be any of the document or
semantic model objects e.g. section, paragraph, graphic etc.
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
Figure 3 – Viewpage Sequence Diagram
4 Evaluation
The layers have been developed with cross
technology/language development at the centre. By
compiling the functionality into dynamic link libraries
applications can be developed in any technology that allows
the use of these libraries. By using the C#.NET as the
development technology, this does restrict any developed
application to running on a Microsoft Windows
environment. However the use of libraries removes the
restriction to solely use Microsoft languages for any future
development. In addition no .NET framework objects are
returned from functions such as ADO Dataset. Instead the
use of custom business object for all message transfers
between layers again ensures that further development is
not dependent on Microsoft family technologies/languages.
This will hopefully allow the team to easily and rapidly
develop custom applications not just for the TDL domain
but tailored to each individual project. As each project
makes use of their own tools it should be possible in most
cases to add functionality to the tools they are currently
using by including the libraries. This has the potential for
quicker return on investment through faster development,
easier deployment as software should already be available
to engineers and no requirement to train engineers to learn a
new application.
The separation of functionality into the layers has also
allowed individual members of the team to take ownership
over particular classes, they can own the classes which
relate to their area of work. It also means that low coupling
is achieved ensuring that any maintenance and further
development of particular aspects has a low effect on
previous development.
The architecture supports rapid development within the
ASP.NET web application for the hybrid models research.
There are no problems or difficulties in using ASP.NET as
a presentation layer technology. Similarly there are no
problems in the creation of a Desktop application using
Microsoft .NET technologies. The theory is extendable to
other programming languages such as Java and Python,
however this has not been tested. As DOORS is being more
prominent as a Presentation layer tool, issues with the
architecture and DOORS have appeared.
DOORS makes use of it’s own C-like language known as
DXL [10,11]. At present the team are unaware of the
techniques to allow DOORS to operate with dynamic
libraries developed outside of the application. Similarly a
technique for exporting the connections or responding to
queries on the DOORS data store is not known. Although
Smith [11] lists several companies that have been able to
develop and provide interfaces to DOORS, information and
knowledge on the DXL language appears scarce with very
Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
little resources freely available to aid in discovering this
type of information.
As such the architecture is required to be mirrored in
DOORS. The philosophy of the multi-layered architecture
is developed independently within DOORS making use of a
Presentation, Business Logic, Data Access and Data
Storage layers. This approach although not ideal is a current
compromise that does allow for work to continue in
discovering and developing exploitable functionality using
the more user friendly development technologies such as
Java and Microsoft Visual Studio. By using the
architectures side by side the research team are able to
maximise their output by using rapid prototyping
technologies without become stagnated by the DXL
development. Only when an element proves beneficial to
the engineers is the functionality then mirrored into
DOORS. As DOORS is used by several projects already
this allows the business to achieve rapid exploitation of the
research developments, without the need to develop a
secure stable custom application.
The development of this architecture has had to analyse the
wider system of TDL development with BAE Systems.
Each project or sub-system has it’s own demands and
requirements. Which have had to be considered in the
design of the architecture. The design has also focused on
enabling a core architecture to be used in developing a
custom response for each sub-system.
In a wider perspective it is believed using a multi-layered
architecture coupled with hybrid modelling techniques will
be able to aid in the use of legacy designs in future
development. Within complex systems such as military
aviation the lifespan of tools and documents can be in
excess of 30 years. Earlier applications can be difficult and
problematic to update in the future. Earlier experiments in
using this type of architecture and the hybrid models are
able to show that legacy applications can be easily modified
to meet new and developing requirements in the future.
5 Conclusion
Although at present there does not appear to be the
functionality to compose DOORS applications to make use
of the developed dynamic link libraries or similarly develop
dynamic link libraries that use DOORS as the source of
information, the architecture proposed and developed does
allow greater flexibility for the research team based at the
System Engineering Innovation Centre. At present by
mirroring the same levels of architecture and classes, the
functionality developed outside of DOORS can be quickly
assessed and potentially deployed extremely rapidly.
However this only partially meets the original aims of the
architecture.
In particular the architecture allows for:
 Rapid collaborative development.
 Ease of maintenance
Loughborough University – 20th - 23rd April 2009
 Independent ownership of functional parts
 Cross application development (Web based or
Windows based)
 Various different development languages (i.e.
C#, Java, Python etc)
 Flexibility
Perhaps the most appropriate advantage of the architecture
is the ability to develop on related research areas in the
most appropriate technology/language. The shared
architecture across the current DOORS implementation
therefore provides a suitable bridge between research
development and rapid real life exploitation of the latest
research.
In the future, it could prove even more beneficial if an
advanced technological assessment of the DOORS
development language DXL is undertaken to assess it’s
ability to make use of dynamic link libraries and similarly
the ability to provide connections to its data store to
external applications. Either of these discoveries would then
remove the requirement to mirror the architecture in
DOORS and more general development environments.
6 References
[1] Clowes et al. (2007), "Pilot Studies in Using the
Semantic Knowledge of Information in Large Technical
Documents to Aid User Navigation", Proceedings of the 9th
European Conference on Knowledge Management,
Southampton: UK pp. 129-138.
[2] Johnson, J. (2007), "Improving system dependability via
a model-based approach to Standards", paper read to the
2007 MIT BAE Systems Fall Conference, October,
Cambridge, MA, USA.
[3] Johnson, J. and Holmes C. (2009) “A model-based
approach to a complex requirement-design domain: TDLs”,
Proceedings of International Conference on Systems
Engineering Research 2009, Loughborough, UK 2009
(unpublished)
[3] Gustavsson Christiernin, L. and Torgersson O. (2005)
“Benefits of Multi-Layer Design in Software with Multi-
User Interfaces – A Three Step Case Study” Proceedings
IASTED International Conference on Software
Engineering, Innsbruck, Austria, 2005.
[4] Gustavsson Christiernin, L. (2005) “Multi-layered
design - Theoretical framework and the method in
practise”, Proceedings of the Department of Computing
Science Winter Meeting. Available at:
http://www.cs.chalmers.se/proj/medview/website/medview/
papers/wm05christiernin.pdf [Accessed 18 February 2009]
[5] Shneiderman B. (2003) “Promoting universal usability
with multi-layer interface design” Proceedings of the 2003
conference on Universal Usability, Vancouver, UK pp.1-8
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

[6] Pires, P.F., Benevides M. R. F. and Mattoso M. (2002),

“Building Reliable Web Services Compositions”,
Proceedings of International Workshop Web Services
Research, Standardization, and Deployment, Erfurt,
Germany: Spinger-Verlag, pp. 59-72

[7] Spaanjaars, I. (2007). “Building Layered Web

Applications with Microsoft ASP.NET 2.0.” [Online]
Spaanjaars.com. Available at:
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416
[Accessed 18 February 2009].

[8] Bimber, O., Encarnação L.M., and Stork A. (2000) “A

multi-layered architecture for sketch-based interaction
within virtual environments”, Computers & Graphics,
24(6), pp. 851-867

[9] Crocker A., Olsen A., and Jezierski E. (2002)

“Designing Data Tier Components and Passing Data
Through Tiers” [Online] Microsoft Developer Network
Library. Available at:
http://msdn.microsoft.com/en-us/library/ms978496.aspx
[Accessed 18 February 2009]

[10] Eriksson, M., Morast, H., Börstler, J., and Borg, K.

(2005), “The PLUSS toolkit?: extending telelogic DOORS
and IBM-rational rose to support product line use case
modelling”, Proceedings of the 20th IEEE/ACM
international Conference on Automated Software
Engineering, Long Beach, USA: ACM, pp. 300-304.

[11] Smith, W. (1999). “Best Practices: Application of

DOORS to system integration.” [Online] QSS Quality
Systems and Software Inc. Available at:
http://www.afis.fr/nav/gt/ie/doc/Articles/bestpractices.pdf
[Accessed 18 February 2009].

Loughborough University – 20th - 23rd April 2009

View publication stats