SDOE – 678: Agile Tactical Data Processor...1.2 Metaphor Model The Agile Tactical Data Processor Today we are taking a tour of the Agile Tactical Data Processor (ATDP). Tactical

Does Not contain export controlled technical data subject to ITAR Regulation

SSDDOOEE –– 667788:: AAggiillee TTaaccttiiccaall DDaattaa PPrroocceessssoorr

System Design and Operational Effectiveness Stevens Institute of Technology

Hoboken, NJ 07030

Project Developed by:

Kathy Brandt

Class of 24Mar2008

Advisor: Rick Dove

Industry Professor [email protected]

Does Not contain export controlled technical data subject to ITAR Regulation

Table of Contents

1. DETAILED CONCEPTUAL DESIGN DOCUMENTATION ......................................................... 4

1.1 Problem/Opportunity ................................................................................................................................................................. 4

1.2 Metaphor Model ......................................................................................................................................................................... 5

1.3 Response Objectives ................................................................................................................................................................... 7 1.3.1 Reliable .................................................................................................................................................................................. 7 1.3.2 Scalable .................................................................................................................................................................................. 7 1.3.3 Effective Communication of Data ......................................................................................................................................... 7 1.3.4 Performance ........................................................................................................................................................................... 8 1.3.5 Configurable to Customers' Needs ........................................................................................................................................ 8 1.3.6 Rapid Upgrades ..................................................................................................................................................................... 8

1.4 Response Issues/Metrics ............................................................................................................................................................. 9 1.4.1 Proactive Change/Response Issues ........................................................................................................................................ 9

1.4.1.1 Creation/Elimination....................................................................................................................................................... 9 1.4.1.2 Improvement ................................................................................................................................................................... 9 1.4.1.3 Migration ........................................................................................................................................................................ 9 1.4.1.4 Modification ................................................................................................................................................................. 10

1.4.2 Reactive Change/Response Issues ....................................................................................................................................... 10 1.4.2.1 Correction ..................................................................................................................................................................... 10 1.4.2.2 Variation ....................................................................................................................................................................... 11 1.4.2.3 Expansion and Contraction ........................................................................................................................................... 11 1.4.2.4 Reconfiguration ............................................................................................................................................................ 11

1.5 Solution Strategy Map .............................................................................................................................................................. 13 1.5.1 Key Activities ...................................................................................................................................................................... 13

1.6 Applied Principles..................................................................................................................................................................... 15 1.6.1 RRS Principles ..................................................................................................................................................................... 15 1.6.2 Reality Factors ..................................................................................................................................................................... 17

1.7 Closure Matrix .......................................................................................................................................................................... 19 1.7.1 Use Distributed Architecture ............................................................................................................................................... 19 1.7.2 Offer Multiple Display Packages ......................................................................................................................................... 20 1.7.3 Provide Help Functionality .................................................................................................................................................. 20 1.7.4 Offer Multiple Radio Packages ........................................................................................................................................... 20 1.7.5 Offer Multiple Functionality Packages ................................................................................................................................ 21 1.7.6 Use Standard Interfaces ....................................................................................................................................................... 21 1.7.7 Translate Multiple Message Formats ................................................................................................................................... 22 1.7.8 Database and Update Track Information ............................................................................................................................. 22 1.7.9 Use Metadata Files .............................................................................................................................................................. 22 1.7.10 Provide Fault Tolerance ..................................................................................................................................................... 23 1.7.11 Handle Multiple Security Levels ....................................................................................................................................... 23

1.8 Operational Management ........................................................................................................................................................ 24 1.8.1 Integrity Management .......................................................................................................................................................... 24 1.8.2 Infrastructure Evolution ....................................................................................................................................................... 24

2. CONCLUSION .......................................................................................................................... 26

Table of Figures Figure 1: Change Response Issues .................................................................................................................................................. 12 Figure 2: Strategic Objectives and Key Activities ........................................................................................................................... 13 Figure 3: RRS Principles ................................................................................................................................................................. 16 Figure 4: Reality Factors ................................................................................................................................................................. 18 Figure 5: Closure Matrix ................................................................................................................................................................. 19 Figure 6: Conceptual Systems Architecture Graphic “Pattern” ....................................................................................................... 25

Does not contain export controlled technical data subject to ITAR Regulation Page 4 of 26

1. Detailed Conceptual Design Documentation

1.1 Problem/Opportunity Tactical Data Processors (TDP) receive and disseminate tactical information to battlefield commanders and warfighters. The current network in which they operate is changing in order to incorporate multiple stove-piped dissemination systems (similar dissemination systems that have existed independently of each other) into one network with a common format. Not only are the message formats changing, but the transmission method and radios are changing as well. The amount of data from these combined systems will tax the current TDP’s database, and the future throughput and latency requirements are beyond the current system's capability. To make conditions more challenging, the transition period is a lengthy one in which the current message formats will need to coexist with the new format. There are also political pressures at work which could potentially redirect the entire effort in unpredictable ways. The current TDP is a tightly coupled design which makes change difficult. Although, some would claim that just changing the parts that must be changed now is the best route to take, with the pace of technological advancements, increased demands from customers and potential competition in this product area, one could argue that the time is right for a complete rewrite of the current system in order to become a more agile Tactical Data Processor which can easily add and remove functionality as needs change. The best way to meet the challenges in this changing environment is to design a system that is able to change in a quick and cost effective way. In the following sections, a design for an Agile Tactical Data Processor (ATDP) will be presented as a replacement to today's system.


1.2 Metaphor Model

The Agile Tactical Data Processor Today we are taking a tour of the Agile Tactical Data Processor (ATDP). Tactical Data Processors receive and disseminate tactical information to battlefield commanders and warfighters in a timely manner. ATDPs reside in a network of multiple Data Providers and Data Users where the ATDPs can be configured in a variety of ways to provide all the needed functionality for a particular user or provider. Before we begin the tour, we need a little background on the environment in which the ATDPs reside. The network is actually a network of networks spanning the globe. The data passing over the network consists of tactical information about real world entities such as airfields, aircraft, ships, emitters, and the relationships between various entities. The Data Providers in the network initially acquire information which is then formatted, managed, and broadcast to the network via various transmission means. Currently, there are not only various radios with different packaging for the data sent to the network, but there are also various formats for the data due to the fact that the various networks evolved separately and are now starting to be joined to better take advantage of all the collected data. The Data Users and Providers in this network vary in their needs. Some need only to accept a single type of feed using a single radio type. Other Data Users/Providers may need multiple feeds with different formats coming in over different radio assets or LAN-based systems. Data Users/Providers may want to forward the information out over the various transmit mediums, or filter it and display it, alert on defined events, or just save it as a scenario to play back later. Because there is so much variety in the role of the Data User/Provider, an agile system that can be configured for the specific role makes sense. Also, as the network continues to evolve toward a single standard format, outdated formats and functionality can be easily removed. The areas that we will be touring today consists of radio interface packages, data formatting packages, data translator packages, database packages, display packages, and user capability packages. To begin our tour, we start with the construction of the ATDP. Every ATDP gets a standard framework that consists of packages with well-defined interfaces. These standard packages allow the different ATDPs to be configured to operate on a peer-to-peer basis where scaling and redundancy are needed. Our first stop on the tour views the data interface packages. This is where all the data enters and exits the system. There are multiple radios that can interface with the ATDP. Each radio tends to have some similarities, but they are not all the same. In the ATDP, there is a generic function that can be used with a metadata file that “customizes” the function for configuring a particular radio. As many unique radios as are needed for the ATDP can be configured in. At run time, they can be selected through a menu system in order to configure and initiate communication with the radio(s). There is also the capability to receive and transmit data over a LAN. Multiple LAN connections can be set up through a menu system. Moving on, we can view the data formatting packages. Each unique radio has its own unique packaging. As data is received from a radio, the packaging needs to be stripped prior to acting on that data. Likewise, before data can be transmitted, the appropriate packaging must be added in order for the radio to be able to process the data. Only the necessary formatting packages for an ATDP need to be built in. Now that we have seen how an ATDP can receive/transmit some data and add/take off the packaging, we will move on to view the translator packages. One of the things that an ATDP might do with the data is to translate it to a different format. This might be just so it can be shipped to another Data User who only understands a particular format, or it might be so the data can be understood internally, added to the


database, and operated on. The translator engine runs based on metadata files that define the message formats as well as the translation rules. The metadata files make it easy to incorporate new message formats or remove outdated ones. The next stop, after receiving data and translating it to a format the ATDP can understand, is to put that data in a database where it can be managed and used for display purposes as well as transmission purposes. The data is organized in the database according to “message tracks” so that if newer information about that “message track” comes in, the track can be updated. Information is held in the database until it times out or newer information takes precedence. The database is central to having accurate displays and functionality. It is also a key piece in allowing scalability with peer ATDPs. In order to allow for scalability, the database package can be placed on one or more ATDPs acting as a group. One ATDP would then act as a database server. One or more of the other ATDPs in the group could also have a database package to act as backup(s). Now that there is data in the database, we can see what the display packages of the ATDP have to offer. There are two aspects to the agility of the display area. One takes place when the ATDP is built, and the other takes place when the user configures the display area for use. When the ATDP is built, there are various COTS map packages that can be used. By having a modular interface to the map package, separate map packages can be linked in with minimal impact to the code. This allows the ATDP to take advantage of the latest advances in COTS map packages. Once the ATDP is deployed for use and the operator initializes it, the operator can customize the display area with various map displays, windows to display information about selected objects on the map, advisory windows, alert windows, port monitoring windows, and scrolling text windows showing a textual display of incoming information. As data comes into the ATDP, the displays are updated in near real-time. The final stop on the tour is to view the user capability packages. There are various capabilities that can operate on the incoming information. One function allows the ability to log incoming data for later replay. Another function allows the user to combine incoming data into a new message and output that data to the network as a producer. Another capability provides a filter function that that can be used to create filters using drawing tools overlaid on a geographic map. Filters can also be set up from text windows where filter parameters on the message data can be entered. Alert messages can also be set up to warn the user when certain events occur based on proximity, identity, threat type, or terrain. These warnings can be either audible or visual. As you can see from the various areas within the ATDP, there are many capabilities that can be offered. By having a modular design for the ATDP, the ATDP is able to change as needed for the various roles that currently exist, as well as making it readily adaptable to future modifications. That concludes our tour of the ATDP.


1.3 Response Objectives The strategic objectives for an Agile Tactical Data Processor (ATDP) are the characteristics of the system that are going to differentiate it from its competition. Although there are many objectives that could be listed for an ATDP, they must be prioritized in order to know where to focus the design. The top strategic objectives are as follows:

Reliable Scalable Effective Communication of Data Performance Configurable to Customers' Needs Rapid Upgrades

1.3.1 Reliable System reliability is of utmost important when dealing with tactical information. Users in the field need a system that they can count on to transmit their information. They may be on the move and do not have time to try a second time if an operation fails. Reliability is important not only from the standpoint of not losing data and displaying it correctly so that the decisions based on the data are correct, but also from an error handling and fault tolerance standpoint. The ATDP should be designed so that errors are recognized and appropriate action taken if necessary. This can include shutting a particular ATDP down in a system where multiple ATDPs are working together. Although this objective does not in itself require the system to be agile, it is important to make sure that designing an agile system does not compromise the reliability of the system.

1.3.2 Scalable

Scalability is important in order to meet different customers’ needs as well as meeting future needs. The system should be scalable from the standpoint of being able to add more modules in order to handle increasing data loads, or extra functionality. Likewise, the system should be capable of being scaled down to fit specific needs without unnecessary functionality that might overburden a small hardware platform such as a laptop.

1.3.3 Effective Communication of Data The ATDP receives, translates, filters, correlates, displays, and transmits data. Various users may have different ways in which they can best understand that data. Because of this, the presentation of data must be flexible with many options available to users so they can customize how they get the picture provided by the data. In some cases, this may be a particular map package such as Google Earth. In other cases, effective communication of data may mean that a system needs data in a particular format.


1.3.4 Performance Performance includes throughput rates as well as latency rates for data processed in the system. The ATDP must meet the demanding requirements in this area as well as be prepared for higher expectations in the future. As stove-piped networks migrate to the network and the network transitions to a higher broadcast data rate, the amount of data handled will continue to increase. This objective ties in with the objective to be scalable.

1.3.5 Configurable to Customers' Needs Configuring each ATDP to customers’ needs is what will allow the ATDP to function as a Data Producer or a Data User in whatever configuration is needed. Custom configuration allows various radios, various message formats, various map packages, various displays and various user capabilities to be configured into the ATDP for a particular user. It ties in with the objective to be scalable. One example would be an airborne platform that would like the ATDP to be incorporated in order to receive the data, but wants the data displayed on the airborne platform’s existing display. In this case, the display packages would not be configured into the system, and the message format for the airborne platform would be incorporated so the data could be fed to the existing display system.

1.3.6 Rapid Upgrades

The ATDP should be able to incorporate new radio types, messages, map packages, and functionality without major rewrites to the existing code. Adding a new radio type, for example, would take advantage of a standard interface and engine that reads a metadata file that is unique to the radio in order to incorporate an interface to that radio. The same is true for adding a new message interface and the translation to/from it.


1.4 Response Issues/Metrics In order to be agile, a system must be able to respond to unforeseen change rapidly and in a cost effective way. Agile Tactical Data Processors will have many issues that they will have to respond to either proactively or reactively in order to be an effective tool for the warfighters. By considering these issues during the design phase, the resulting system will be more capable of changing to meet future needs.

1.4.1 Proactive Change/Response Issues

1.4.1.1 Creation/Elimination

In the course of operation, an Agile Tactical Data Processor will create systems of various configurations. When configured as a Data User, an ATDP will receive data and display that information to an operator who will make decisions based on the data. When configured as a Data Provider, an ATDP will gather, correlate, and create data to transmit to others. Being able to quickly and cost effectively configure multiple types of systems allows the ATDP to be deployed to more customers potentially leading to more data on the network and an improved picture of events. The response metrics associated with creation and elimination of various configurations are cost, time, and scope. With a modular design for all the functionality, tailoring each ATDP should be relatively quick and cost efficient. The modular design also allows for unknown needs to be easily incorporated as long as the need is something that can be accommodated in a modular way. The module inventory allows flexibility, while the modular structure allows response ability.

1.4.1.2 Improvement

Over time there are many areas of an ATDP that can proactively be changed. One of these is the user interface. User interfaces have changed quite a bit in the past, and it is only reasonable to assume that those changes will continue to occur at an increasing pace. In order to best adapt over time, algorithms for functionality need to be in separate modules so that, as much as possible, the user interface only takes parameters for display and entered data. The metric associated with improving the user interface is scope. Separating out the interface allows for future agility.

1.4.1.3 Migration

Migration is another area that should be proactively addressed over time. Migration to different platforms such as a web-based system is a likely area for the future in order to disseminate the data as widely as possible and take advantage of existing infrastructure. Again, modularizing functions in order to allow a service oriented distributed architecture will make a transition to a web-based system easier.


All metrics apply in this case because a migration to a web-based system would be much faster and cost efficient when compared to migrating a monolithic system such as the current TDP. This means that the chances of making the changes correctly (meeting specification targets) are high. In addition, the magnitude of the change would be reflected with the scope metric. Automatic detection of assets is another migration which might occur. Initially, this is envisioned as a method for detecting which radios are connected to an ATDP and bringing the radios up automatically using defaults. This area would also include automatically detecting what functionality is present within a distributed system of ATDPs by multicasting information about an ATDP as it comes up, and having all the ATDPs that receive the multicast message broadcast their information. The metrics associated with automatic detection of assets would be scope because of the range of possible change.

1.4.1.4 Modification

Modification in the form of handling new radios as they become available can be expected to be a likely issue to be proactively addressed. There are currently multiple radios in development for the future waveform. As they become available, the ATDP will need to interface to them. Being able to handle the new radios by reusing existing functions with a metadata file created for the new radio makes the modifications very cost efficient. The cost and quality metrics would demonstrate the change proficiency for these types of modifications to the system. Creating the metadata files may or may not be faster than cloning some functionality and modifying it, but the cost of testing modified code would be greater than testing a metadata file with a proven “engine”.

1.4.2 Reactive Change/Response Issues

1.4.2.1 Correction

There will likely be many reactive issues that an ATDP system will encounter. Correction to improve throughput is one likely area. Data tends to increase along with increases in technology. In addition, as the network continues to provide solid tactical data, more allies want to be a part of it providing more platforms and hence more data. Users don’t like to give up the information they are used to, but as new types of data or new sources become available, users want that data as well. Having a distributed, scalable system is a good way to ensure that future throughput needs can be met. Migrating to faster machines can help, but only within the limits of the current technology. The metrics that apply to improving throughput would be time and quality. In the existing TDP, an effort was undertaken to improve throughput that required a major restructuring of the code. It took quite a bit of time and while throughput improvements were gained, many errors were introduced


that had to be corrected. Having a scalable system would greatly improve the time to improve throughput as well as reducing the risk of errors.

1.4.2.2 Variation

Over time there will be a need to handle variations in the system. One of those variations will be different versions of the data formats. Handling different versions is necessary because once an ATDP is produced with a given message format, changes can take place, and newer ATDPs will need to be produced with the latest version. The ATDPs out in the field may not be able to change right away, yet they still need to be able to communication with each other. For this type of variation, it is important to design the ATDP with a solid translator engine that can accept metadata rules files. That way, any revision of a message format can be sent out in the form of new metadata files for the format and translation rules for the format. The files can be incorporated when they are received. In the meantime, the translator engine must be built to handle exceptions, so that it translates what it can, but if it receives something it doesn’t have rules for, the translator should skip it. Cost, time, and quality metrics apply in this case because the ability to make changes with just a metadata file means that the changes are very quick and cost efficient. In addition, less testing is needed because the engine itself is proven, so only the new rules need to be tested.

1.4.2.3 Expansion and Contraction

An issue that could require a reactive response related to expansion and contraction would be the flow control to an external entity. In this case, it could mean storing the data until there’s a slowdown in the input data and the system can catch up. Or it could mean that filtering is necessary with less important data thrown away. A scalable, modular ATDP would handle either scenario. In the first case, more hardware might be needed to buffer the data, or distribute the burden. In the second case, a new function might be added to act on the data stream. The time and quality metrics would best show the ATDPs change proficiency with respect to expansion and contraction via hardware. To be able to scale a system with more processors and existing functionality would be very fast and should not affect the robustness of the system negatively compared to having to change code. In the case of expanding via adding a new function, the scope metric would apply. In a system that is modular with well-defined interfaces, inserting a new module to act on some data between point A and point B would demonstrate an ability to handle unanticipated change.

1.4.2.4 Reconfiguration

The final reactive area that needs to be considered is reconfiguration. One example is where a physical relocation of the radios causes a timing problem that prevents communication. In this situation having a distributed system could allow the functionality critical to the timing to remain co-located with the radios.


The metric associated with this change would be quality because the change alleviates a timing problem which causes the system not to function to specifications. Most likely cost and time would indicate good change proficiency because it ought to be much cheaper and quicker to distribute the functionality, than to change communication mediums to something faster.

Figure 1: Change Response Issues

Correction

Variation

Reconfigu-ration

Expansion(and

Contractionof Capacity)

Migration

Improvement

Modification(Add/Sub

Capability)

Creation(and

Elimination)

Pro

acti

veR

eac

tive

Pro

acti

veR

eac

tive

Change Domain

• Improve throughput [t], improve user interface [s], and improve displays [s, q], improve help files [q], and improve system maintenance/development [c, q]

• Creates and eliminates Data User and Data Provider systems of various configurations i.e. information displays according to incoming data and operator requests, data filters based on operator requests or system configuration, log files of data, interfaces with radios, interfaces with networks, interfaces to various maps [c, t, s]

• Migration to web-based system, new Operating Systems, migration to faster or additional PCs, and to airborne systems [t, q, c, s]

• automate detection of assets and connection to them [t, q]

• Addition of new radio type interfaces, new data format types, new translations, and new displays [c, t, q]

• Throughput (if it is not fast enough in field), errors in translations (or errors in general), improper interactions with radios, overcome errors in the radio, loss of data, detection of duplicate data, reconnect to radios or network when connection is lost, resend data when it doesn’t make it to destination [t, q]

• Physical relocation where distances between radios and PC may cause timing problems [q]• Airborne systems [s]• DTD changes [s]• Multiple TDPs acting together for certain situations [s, q, c]

• Data bursts and backups, higher than expected sustained data rates, higher than expected high priority data rates [t, q]

• Flow control to external entity [t, q]• Removal of user/other interface [s]

• Tailor TDP for appropriate radio assets and message formats [c, q]• Revision of map data [s]• Handling for different revisions of message formats [c, q]

Change/Response Issue


1.5 Solution Strategy Map In section 1.3, the important response objectives for the ATDP were discussed. In order to meet those objectives, certain functional activities must be part of the design strategy. The following figure shows a solution strategy map for the ATDP.

Figure 2: Strategic Objectives and Key Activities

1.5.1 Key Activities

As seen in the Figure 2, there are multiple key activities that will drive the design of the ATDP. Most can be tied back to the previous section and will provide the ability to meet future needs in an agile way. Having a distributed architecture is important for making sure that the system can be expanded to multiple processors as necessary. This is primarily to offload functions in order to increase performance of individual modules. A distributed architecture allows scalability as well as fault tolerance. Care must be taken when deciding how to distribute the modules so that performance is improved as opposed to being impacted.

PerformancePerformance

Use standard interfaces

Providefault tolerance

Translatebetween multiplemessage formats

Offer multipleradio packages

Offermultipledisplay

packages

Rapid UpgradesRapid Upgrades

Effective Effective CommunicationCommunication

of Dataof Data

Handle multiple security levels

for data

Use distributed architecture

- Strategic Themes/Values

- Functional Activities

- Strategic Themes/Values

- Functional Activities

ScalableScalable

Use metadatafiles

Database and update track information

Provide helpfunctionality for

ease of use

ReliableReliable

Configurable toConfigurable toCustomersCustomers

NeedsNeeds

Offer multiplefunctionality

packages


Using standard interfaces such as TCP/IP and UDP/IP contributes to reliability as well as effective communication. Standard interfaces also allow plug and play capability which enables configuring to customer needs and rapid upgrades. One area where plug and play may not be standard is the off-the-shelf map packages. In order to better support potentially different interfaces, “standardizing” the internal interface can be achieved with “coupler” modules. These modules would form an interface between the off-the-shelf map package and the internal map functions. By switching these out for the various map packages, the internal map functionality should remain unchanged. Offering multiple radio packages, display packages, functionality packages, etc. can all be thought of together. They could essentially be grouped as multiple functionality packages, but have been broken out just to be a little more descriptive. The fact that there are multiple choices of displays, maps, functions, radios, etc. that can either be configured in, or chosen during use, allows effective communication and allows the ATDP to be configurable to the customers needs. Translation between multiple message formats is a key activity to incorporate the different stove-piped networks. This contributes to effective communication. Tied to this is the use of metadata files. The metadata files are used for defining the message formats as well as the translation rules which leads to rapid upgrades. Other activities that add to effective communication of data are help functionality and databasing and updating track information. The help functionality doesn’t need much explanation other than to say it should be constructed in a modular fashion so that when configuring the various systems, only the matching help is available. As far as databasing track information, some TDPs only display the information as it is received. By databasing, newer information can be used in conjunction with older data for a more complete picture. Providing the capability for fault tolerance increases the reliability of the system. With the ability to have multiple ATDPs acting together, if they are regularly checking the status of each other, then if the ATDP that is acting as the database server goes down, one of the other ATDPs can take over that role. This is needed in certain locations where the ATDP is acting as a relay between networks.


1.6 Applied Principles

1.6.1 RRS Principles

The 10 RRS principles can be used when thinking about the ATDP system design in order to consider change enabling design concepts. In the Reusable area of RRS, modularity seems to be a key enabler. Self contained units in a system enable change by minimizing interference when functionality must be changed, as well as by allowing distribution of functions, reuse of functions, and tailoring of products. In the ATDP, the main modules would be the map packages, the radio interface packages, the data translator engine and message format packages, the display packages, the database packages, and user capability packages such as logging, correlation, filtering, and many more. Most of the functionality is accessed via menus. If the functionality is configured into the ATDP, it will appear in the menus. Multiple display packages, for example, could be configured in to a single ATDP giving the user choices at runtime. Most of the modules are fairly self-explanatory with regard to their modularity. The map package, the translation package, and the database packages can use some further explanation. Map packages as mentioned earlier are off-the-shelf packages. An interface module similar to the Silterra case study described in class would be created so that when switching between various map packages, only the interface modules would need to be changed, not the underlying functionality that is doing the real work with the map packages. The database is also an area worth mentioning. In today’s TDP, a single database of “message tracks” is used even though not all the data is really the same type of data. In the future, there will also be data at different security classification levels. For the ATDP, the separate types of data would be broken up into separate databases to potentially increase throughput and allow distribution. The translation package could be designed in multiple ways. For the ATDP, a translation engine that uses “rules” files, or metadata, will be used. The engine will convert any message format to or from an internal format. This way, any message can be converted from any input to any output by having the rules file for that message format to and from the internal format. With all the formats and rules defined using metadata files, it is relatively easy to add and remove formats as necessary. The encapsulated modules are really the key to allowing most of the rest of the RRS principles. Plug Compatibility can be used in the api interface layer to the map package as well as the metadata files for the translator and radio interfaces. Facilitated reuse is enabled by these metadata files. In the Scalable area of RRS, the evolving standards must be considered as to how those changes can be accommodated during the lifecycle of the system. Operating systems change, message catalogs change, and translation rules change (generally due to message format changes or corrections). The metadata files will accommodate the latter two evolving choices. The impact of Operating Systems changes would be lessened by trying to encapsulate OS dependent functions. Unit redundancy and diversity is enabled by the modularity of the system. When the modules are


designed to act independently, then multiple systems can be created which are either the same or have different configurations to meet different needs. For example, one system may need one type of radio and message format, and another system may need multiple radios of different types and multiple message formats to be translated. Elastic capacity is enabled by being able to distribute the modular functionality across separate ATDPs and having them be able to work together to share the work load. One ATDP might act as the database server and another ATDP might interface with the radios and perform translations. In the Reconfigurable area of RRS, the modules allow the system to be distributed. As described in the above scenario where two ATDPs are sharing the work load, a peer-to-peer relationship would exist where one ATDP is independently processing its work and handing off data to the other ATDP for it to independently do its work. Each ATDP would know what its “job” is by its configuration and by establishing priority when it is initialized. For instance, if an ATDP is initialized that has a database server, but another ATDP is already filling that role, the newly initialized ATDP will not take over that role unless the ATDP filling that role goes down. In this way, Distributed Control and Information and Self Organization are fulfilled at the same time as Flat Interaction. Deferred commitment is enabled through the modularity of the functions as well as the metadata files that can be included in the system. The system can be configured to include or exclude functions and metadata files according to a users needs. In addition, multiple choices can be built in and then chosen at run-time by the user.

Figure 3: RRS Principles

Self-Contained Units (Encapsulated Modules)

• Map packages, radio interface packages, data translator packages, databases, display packages, log packages

Evolving Standards (Infrastructure/Framework)

• OS framework, message catalogs, translation rules, data transfer protocols, web protocols, database protocols

Plug Compatibility (Facilitated Interfacing)

• Api interface layer so that calls to map package are not hardcoded; use of metadata files for defining radio interface for quick change out and reuse; metadata files to define translation rules and message formats

Facilitated Reuse

• Metadata files facilitate reuse by providing a generic way to represent data for message formats, translation rules between formats, and interfaces to radios

Elastic Capacity (Scalable)• Allow multiple ATDPs to act as one by load-sharing. Each

ATDP might be configured exactly the same, or they might have different radio assets and message formats. One ATDP in group would act as database server.

Unit Redundancy & Diversity

• Multiple radios of the same or different type may be added to configuration; multiple message formats can be added as input/output types; multiple connections of the same data

Flat Interaction (Peer-Peer, Non-Hierarchical)

• There would be peer to peer relationship between the controlling ATDP within a group of ATDPs. The controlling ATDP would have control of the database

Deferred Commitment

• Configuration of ATDP can be determined at run time through use of appropriate configuration files.

Distributed Control & Information (Decentralization)

• The ability to have multiple ATDPs allows much of the radio control and data processing to be distributed.

• The ability to have multiple modules which handle specific functions.

Self Organization

• If multiple ATDPs are acting together and one goes down, the others can take over load and determine who controls database

Sc

alab

le

Reu

sab

le

Reconfigurable


1.6.2 Reality Factors

In addition to considering the RRS principles during the design phase, considering Reality Factors, situations the system will likely face once it is in operation, is also a good way to get a systems designer to think in terms of creating a more agile system. For an ATDP, there are always going to be Human Factors such as operators who are not of equal competence. Having multiple packages helps with this because some operators may find things more intuitive when presented one way vs. another. Including “wizards” for step by step help as well as automating some radio setup will all help in this area. A more difficult issue to address is that those who have “empires” built around their current stove-piped networks may be reluctant to change. Providing capability very similar to what they are using in their current operations so that their change is minimized (through the selection of package choices), may make them more amenable to accepting a new system. In the area of Organizational Behavior, scope changes could overreach funding. There has been a limit to the funding toward the current TDP and that is not expected to change in the future (or at least not in the positive direction). Future changes to the system may be hard pressed for adequate funding making agility in the form of assuring future changes are low-cost very important. The Technology Pace could be a factor in regard to the timeline for getting rid of a certain current standard. If migration doesn’t happen by a certain date, one of the existing stove-piped networks will end up taking over and the new system could potentially become OBE (overcome by events). As far as the technology pace in general, it is difficult to keep up with and due to the time it can take from start of development to the delivery (which is influenced by the fixed funding), initial plans could be out of date. The best way to accommodate this is with flexibility in design so that portability to different hardware, OS, are quickly and cost effectively accomplished when needed. System Complexity could be a problem for the ATDP in use because there are so many interactions that it is nearly impossible to test every condition. In use, new configurations could create untested situations that don’t work correctly or negatively impact throughput. Also, the increasing system complexity could require distribution to the point that throughput is affected. Globalization could negatively affect that ATDP if there are failures. Any failures would have widespread visibility and could cause users to not trust the system and look for alternatives. In addition, some of the stove-piped networks may be harder to incorporate than others. Although it seems unlikely, if allies were to change, the security of the system would be compromised requiring potentially widespread changes to the system in the area of encryption, message formats, etc. Creeping Agile Practices could affect the system over time if modifications to the system are made without considering the agility that was designed into the system. Careless changes could reduce modularity and flexibility. Agile Adversaries could be a problem for the ATDP if they come up with a solution that takes significantly less bandwidth or has higher throughput of data. Having a scalable system should help counteract this threat, although there is a price to pay in terms of timing with a distributed system. Care must be taken that timing isn’t adversely affected when functions are distributed.


Figure 4: Reality Factors

Reality Factors

Organizational Behavior – Survival rules rule, nobody's in control...• Scope changes overreach funding; • Slow to get rid of stovepiped networks (Organizations using current network unable to make decisions on direction and control progress

in that direction)

Human Behavior – Human error, whimsy, expediency, arrogance...• Operators not qualified (or incompetent) and unable to understand/operate the user interface; • People in charge of current stovepiped systems reluctant to change and potentially lose control of their “empire”;

Technology Pace – Accelerating vulnerability-introductions, sparse testing...• Obsolescence of current standard “X” could happen before new network in place; • Hard to keep up with rapidly advancing technology from the standpoint of knowing what is available, as well as testing thoroughly once

new technology is incorporated

System Complexity – Incomprehensible, highly networked, unintended consequences, emergence...• Hard to communicate all necessary information between different development (task) areas. Can lead to design flaws/incompatibility;

testing all the rules in the various metadata files for radios, message formats, and translations is difficult and really requires automation; Might overload system that can't be distributed due to location/funding. ; Overload user with data;

Globalization – Partners with different ethics, values, infrastructures...• Failures would have widespread visibility; • Infrastructures of some stovepiped systems may be harder to incorporate and effect system negatively• Change in current political alliances could compromise security of system

Agile Adversaries – Distributed, collaborative, self organizing, proactive...• Competitor might find solution that takes less bandwidth or displays/correlates data better.

Creeping Agile Practices – Outsourcing, webservices, transparency, COTS, SOA...• Developers that modify system after initial system delivery may not follow agile design spec if they weren't involved from the start.


1.7 Closure Matrix The following Closure Matrix can be used to see how the Key Activities for the ATDP map to handling the proactive and reactive issues for the system in an agile way. By working through the matrix, areas that need further consideration can be determined.

Activities (Functions)123456789

1011

Principle-Based Activities, and Issues ServedCreate Various Configurations all 2-9,11 2,4-9 24579 16 23459 16 1,10 1 1245910 9Improve User Interface 26 26 26 2 6Migrate to Different Platform 124579 24579 6 2459 2459 1Automatic Detection of Assets 4610 10 4 46 4610Add/Sub Radios 49 49 49 49 49 4 49 9Throughput 1,11 11 1,11 1,11 1,11Support Revs. for Msg. Fmts. 79 79 79 79 79 79 79 9Data Bursts and Flow Control 15811 58 5 1811 1811

Physical relocation challenges1 1 1R

ea

cti

ve

Use Distributed ArchitectureOffer Multiple Display PackagesProvide Help FunctionalityOffer Multiple Radio PackagesOffer Multiple Functionality Packages

Issues (Requirements)

Pro

ac

tiv

e

Red

un

dac

y &

Div

ersi

ty

Ev

olv

ing

Sta

nd

ard

s

Database and Update Track Information

Handle Multiple Security Levels Se

lf C

on

tain

ed

Un

its

Plu

g C

om

pa

tib

ilit

y

Se

lf O

rga

niz

ati

on

Ela

sti

c C

ap

ac

ity

De

ferr

ed

Co

mm

itm

en

t

Dis

trib

ute

d C

on

tro

l & In

fo

Fa

cil

ita

ted

Re

-Us

e

Fla

t In

tera

cti

on

(P

to

P)

Use Metadata FilesProvide Fault Tolerance

Use Standard InterfacesTranslate Multiple Message Formats

Figure 5: Closure Matrix

1.7.1 Use Distributed Architecture

Using a distributed architecture facilitates the creation of various configurations by allowing the various modules to be put on the same or separate processors. It provides an architecture which lends itself well to flat interaction and distributed control and information. It particularly allows for elastic capacity by enabling more processors to be utilized if needed. For example if the data throughput rate can’t be met on a single processor, separating some functions such as translations to a separate processor, or separating the various databases based on security level could be accomplished to speed the throughput. A distributed architecture also enables redundancy if two processors are needed to handle the same function, such as translations. Self organization is also tied to using a distributed architecture because each module can act on its own and react to errors on another processor if needed. An example of this would be fault tolerance. A distributed architecture may also facilitate migration to a different platform by allowing distributed control and information. A tightly coupled system will be much harder to migrate because the destination platform may not have the bandwidth to accommodate all the features. A distributed system has a much better chance of being flexible enough to fit into a new platform. A distributed architecture is also important when reacting to an increased throughput need. The self


contained units can be strategically distributed to optimize processing. Distributed control and information allows the separate modules to act on their own so they are not forced to wait on each other. Elastic capacity and redundancy are also enabled with the distributed architecture and are able to alleviate throughput expansion by providing a means of having multiple modules doing similar tasks to share the load. In the case of throughput, the translations are one area where redundancy and elastic capacity would allow throughput improvements. Separate databases for different security levels will also allow throughput improvements although this is only possible if the data is spread across the security levels. The same arguments that were made for throughput can be made for flow control and data bursts. In this category, filtering and buffering become important. In some cases, data can be thrown away to handle these cases, in other cases, the data may just need to be buffered for a short time until the data burst is over. The final area where a distributed architecture is seen to have an impact is in the reactive issue where a physical relocation caused a timing problem with a radio. In this case, being able to distribute modules would allow the module needed for timing with the radios to be co-located with the radios, while the rest of the system is located elsewhere.

1.7.2 Offer Multiple Display Packages

Offering multiple display packages contributes to the agility of the ATDP primarily in the proactive areas allowing for various configurations of the ATDP to be created, improving the user interface as well as easing the migration to different platforms. The modular nature of the display packages contributes to encapsulation of functionality because each module stands on its own and can be configured in and executed from a menu. The display packages contribute to plug compatibility because their user interface is separated from the functionality so that the user interface part of the display is just calling a function. That way if the user interface needs to change, the changes are contained. The display packages allow for reuse between different ATDP configurations such as a Data User vs. a Data Producer, or different platforms such as a ground platform vs. airborne platform. They allow for deferred commitment from both the aspect that they can be configured into the system at the last minute, or even multiple can be configured in and the user can select which one(s) they want to use during operation. They allow redundancy and diversity because multiple displays of the same type can be used, or multiple displays of different types can be used.

1.7.3 Provide Help Functionality

Providing help functionality is important, however it does not contribute much to the agility of the system other than by being designed in modular manner. The help package is a self contained unit and allows for deferred commitment because the final system only gets the help functionality that matches the system configuration.

1.7.4 Offer Multiple Radio Packages

Offering multiple radio packages contributes to the agility of the ATDP primarily in the proactive areas allowing for various configurations of the ATDP to be created as well as easing the migration


to different platforms. The radio packages consist of the functionality to configure a “family” of radios. It uses metadata files which contain the rules for the particular instance of a radio family in order to know how to configure that radio. Since not all families of radios are similar, multiple radio packages may be needed. The modular nature of the radio packages contributes to encapsulation of functionality because each module stands on its own and can be configured in if needed. The radio packages contribute to plug compatibility by their use of metadata files. By “plugging” in a different metadata file, different rules can be followed to bring up a radio. The radio packages allow for reuse between different ATDP configurations depending on their radio needs. They allow for deferred commitment from both the aspect that they can be configured into the system as needed, and the metadata files can be updated or changed at run time. They allow redundancy and diversity because multiple radios of the same type can be used, or multiple radios of different types can be used. Multiple radio packages contribute to automatic detection of assets by using the rules files to figure out what type of radio or radios are connected to an ATDP through trial and error, and then once the type has been determined, automatically bringing them up based on the default information if the user has configured the system this way. This is deferred commitment from the standpoint that it is not necessarily known what the radios are going to be ahead of time. It is also distributed control and information because the radio package is acting on its own to bring up any attached radios. Multiple radio packages contribute to adding and subtraction of radio types because of the modular packages can be configured in the system, or not. This shows elastic capacity as well as redundancy and diversity. Re-use is accomplished not only when different systems are configured with the radio packages, but also by the fact that even between the different families of radio packages, there are some similarities that can be capitalized on if a new family of radios comes along.

1.7.5 Offer Multiple Functionality Packages

Offering multiple functionality packages contributes to the agility of the ATDP primarily in the proactive areas allowing for various configurations of the ATDP to be created as well as easing the migration to different platforms. This area is pretty much identical to the multiple display packages so reference the multiple display packages for the details on where the contributions to agility are.

1.7.6 Use Standard Interfaces

Use of standard interfaces such as TCP/IP and UDP/IP allows for flat interaction between distributed modules. In the case of the ATDP, information can be multicast so that the modules that need the information can pick it up as opposed to the current system where particular messages are sent multiple times directly to modules that need the information. This contributes to the ability to create various configurations because the same communication means can be used within a processor as well as between processors. Standard interfaces can also benefit a proactive move to automatically detect assets. In this case, the automatic detection of assets may be other ATDPs which are co-located in order to load share. When an ATDP is initialized, it can broadcast its information. Any ATDPs that receive the broadcast can register the ATDP and broadcast their information so it can be registered with the new ATDP. The standard interfaces in this case contribute to both distributed control and


information as well as self organization. Finally, standard interfaces can contribute to plug compatibility when migrating to different platforms.

1.7.7 Translate Multiple Message Formats

The ability to translate between multiple message formats is important because various networks will migrate to the new common message format in different timeframes and the message formats will coexist for some period of time. The translator is a generic engine that uses metadata files described below to know how to translate to/from an internal format. By using an internal format, only the rules to/from that format are needed to allow translations between any message format. The translator enables the creation of various configurations because it is generic and doesn’t contain rules for unnecessary message translations. The generic engine is plug compatible with the metadata files and facilitates reuse because any new message format can be incorporated. The translator enables the addition and subtraction of message formats because the actual formatting rules are separate from the engine. Message format revisions are easily incorporated because the metadata files are just updated, not the translator.

1.7.8 Database and Update Track Information

Database and update track information is a feature in an ATDP where the received information is maintained in a database and updated as new information as opposed to just handing one message at a time. By databasing the information, a more complete picture of events is created. Eventually the data in the database times out and is removed. This functionality slows the throughput of data. The closure matrix shows this functionality contributing in the data burst and flow control area because a system must be able to hold on to the data for slowing the flow of data to a particular destination unless the data is allowed to be thrown away which is generally not an accepted option. The database functionality is modular in the sense that it is encapsulated. In addition, in the ATDP it will be designed such that there are separate databases for the different security levels handled as well as separating data of different types. (The current database treats some data as if it were a track when it is not.) Because of the separation in the databases, this functionality also contributes to distributed control and information as well as elastic capacity. In the proactive area, this functionality contributes to creating various configurations because if only one type of data or one security level is needed, then that would be the only database that would need to be configured in.

1.7.9 Use Metadata Files

Metadata files are text files that contain rules that can be accessed at run time. The radio packages and message translation packages would have generic engines that would access metadata files in order to process various radios and message format translations. This contributes to agility across most of the RRS principles. Because metadata files encapsulate rules for a particular function, they can be seen as self contained units. Because they “plug in” to a generic engine, they enable plug


compatibility. They allow reuse of the generic engines, and allow deferred commitment because they can be added at run-time. They contribute to elastic capacity because there is no limit to the number of rules files that can be added. They don’t restrict redundancy and allow diversity since the same generic engine can use multiple rules files. They allow the flexibility to keep up with evolving standards in the areas of message formats and radio formats because the text files can be easily updated as needed.

1.7.10 Provide Fault Tolerance

Providing fault tolerance is important in some situations where data is relayed from one major network to another. A single failure in that instance could cause a loss of information until the system can either be brought up again or replaced. Providing fault tolerance allows for side-by-side redundancy of an ATDP in the field. With automatic detection of assets, the redundant ATDPs can monitor each other and when necessary, take over for the other. This contributes to agility in the flat interaction and self organization categories.

1.7.11 Handle Multiple Security Levels

Handling multiple security levels primarily benefits the reactive issues in the closure matrix. The main purpose of the security levels is to only allow the right classification of data to the various destinations. It benefits agility by allowing the handling of the data to be distributed. The amount of benefit depends on how the data is split amongst the classification levels. In the area of improving throughput, the encapsulation of the various security levels and the ability to distribute the handling of the different categories allows for elastic capacity as well as redundancy and diversity. It benefits data bursts and flow control in the same manner.


1.8 Operational Management

1.8.1 Integrity Management As changes to the initial ATDP are made, it is important for those involved, the Project Engineer, the Systems Engineers, and the Software Engineers to maintain the modules without compromising the agility of the system. It is sometimes easier and more cost efficient in the short term to hack together a new functionality instead of taking the time to design it properly. There needs to be some oversight of changes, perhaps in the form of reviews, to ensure modifications fit with the agility of the original ATDP system. The module inventory over time will have additions and deletions based on the customers needs. It is important for the Project Engineer to anticipate needs based on knowledge of field operations and the latest technologies that might be used to advantage. Anticipating needs will allow more time to plan out modules to be added instead of trying to add functionality in a reactionary mode. The Project Engineer and Systems Engineers are responsible for creating the different flavors of ATDPs which are released. In doing so, they are responsible for ensuring there are no unintended consequences that the combination of the selected components will create. System assembly of the released ATDP occurs when the selected features are brought together in a build. Once the ATDP is delivered to the field, further customization can occur by the operator’s configuration file selections which predetermines allowed functionality such as which radios are on which port. In addition, during operation, the operator further selects which functionality to run, such as display choices.

1.8.2 Infrastructure Evolution ATDP’s rely on multiple protocols such as message formats that can change over time. The Project Engineer and customer are responsible for coordinating these changes with respect to schedule and deliveries. This coordination is important because the limited funding means that unplanned changes require scope cuts in planned functionality. It is a balancing act to get required functionality out for operators to use on the network, and still keep up with protocol changes that may not be a part of a needed functionality such as Operating System upgrades. By trying to maintain an agile mindset for all development, the ATDP should continue to evolve in an agile way and be able to handle the protocol changes in a cost efficient way.


Figure 6: Conceptual Systems Architecture Graphic “Pattern”

Agile Tactical Data Processor

maps Data translatorsRadio interfaces databases displays Log packages

Infrastructure evolution

System assembly

Module Maintenance

Module inventory

Infrastructure evolution

System assembly

Module Maintenance

Module inventory

Web protocolsData transfer protocols

Translation RulesMessage catalogs

Web protocolsData transfer protocols

Translation RulesMessage catalogs

Infrastructure

config 2 config nconfig 1

Drag & Drop Modules

Plug & Play Rules

IntegrityManagement

Active

Passive

Time

PE/Customer

PE/SE

PE/SE/SWE

PE/Customer

PE/Customer

PE/SE

PE/SE/SWE

PE/Customer

OS Framework

This document


2. Conclusion By considering what issues a TDP might face in the future, it is obvious that the current tightly coupled architecture would not be able to be changed to meet those needs in a timely or cost efficient way. An agile TDP is needed to meet future tactical data processing needs. The proactive/reactive issues and reality factors were initially a good way to recognize that the current TDP is not agile. The RRS principles worked as a framework for considering where to add agility into the TDP. By going back to the proactive/reactive issues and reality factors the agility of the ATDP could be “tested”. Finally, the key activities to meet the strategic objectives of the system were mapped in the closure matrix to get a picture of the overall agility of the system. The closure matrix for the ATDP indicates that the system is fairly agile. For a truly complete design, there are many more issues that might need to be considered and either added to the closure matrix, or ranked in priority over what is currently in the closure matrix. Going through the process in iterations may help give a better picture in the case of a single designer, but preferably differing viewpoints from several designers would result in the best design (as was recommended). In the case of the ATDP, the above process has resulted in a much more response-able design compare to the current TDP. Two areas of concern would be throughput and latency because those can be negatively affected by distributing functionality across multiple processors. This might be an area where a prototype might be beneficial to prove the concept.

Documents

SDOE – 678: Agile Tactical Data Processor...1.2 Metaphor Model The Agile Tactical Data Processor Today we are taking a tour of the Agile Tactical Data Processor (ATDP). Tactical