Environment:

The Capability Driven Architecture (CDA, patent pending) was originated to solve a very difficult problem for Army Aviation. TES was asked to come up with a way to reduce integration costs for integrating various devices onto four different aircraft architectures. This solution was required to not only integrate the devices, but to ensure the reduction in development and life cycle costs associated with the integration.

The CDA, patent pending, architecture can be applied to all capabilities including communications, navigational, sensors, actuators, etc., and, as a proof of concept, it was first developed and demonstrated for radio control as CDA Radio Control (CDA-RC) for military rotorcraft systems. While architectures exist that can claim software reuse, few, if any, can claim software reuse for safety/mission critical applications. CDA eliminates ad hoc development and stovepipe systems resulting in duplication of effort across the various platforms for integrating the same type of equipment. 

The motivation behind the Capability Driven Architecture (CDA, patent pending) design is to provide a common interface to a category of similar devices, much like desktop computer applications have a common interface to the myriad of computer printers and other peripherals.  Currently, safety-critical applications have nothing similar for integrating equipment. What does exist is a mix of disparate platform architectures and stovepipe systems based on proprietary interfaces.

CDA, patent pending, is more than just software architecture. It is also a process for identifying a common Application Programming Interface (API) for disparate environments or devices, as well as a set of tools to support the life cycle of CDA development. When CDA is combined with the native support for the Programmable Control Test Station (PCTS) it is a complete environment for application development, verification, and support.

Challenge:

Slow integration of new sensors and LRUs is costly.

Solution:

A Software Product Line is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process. As any product line, CDA, patent pending, provides for the rapid integration and development of new and varied products without the high cost typically associated with product development.

The CDA Software Product Line has been applied to various applications since its creation, some of which are:

• Radio Control for military aircraft
• Unmanned vehicle controls, verification, and analysis
• Manned vehicle digital dashboard
• Naval Sensor Integration, Contact and Track Capabilities
• Vehicle Integration and Information Management System (VIIMS)
• Third Party LRU software integration verification

Other applications, which are in various phases of development, are User Manual distribution for commercial vehicles, handheld device data collection/distribution, Travel Host, a Software Engineering Test Station, and a Battle Command Test Station.

Since the original development of CDA in 2004, the CDA, patent pending, design has been enhanced.  Not only does it include support for integrating various devices, but it now includes a full application framework for supporting the development of complete systems with many applications running across many computers, with failover recovery, distributed processes with LAN and WAN support, all in a safety/mission-critical environment.

Capabilities:

CDA, patent pending, tools support each stage of the software development lifecycle process.  The process starts with the requirements analysis.  The CDA tool supports the both the creation of the capability and functional interface, as well as the definition of the data which is to be published.  Once the interface is well defined, the requirements document can be auto-generated from the tool.  Additionally, the design of the interface, the design of the code, and the design of the configuration data which implements the data caching can be auto-generated.  Furthermore, besides design and code generations, unit tests can also be generated from CDA tool.

If the interface is implementing a device such as a GPS, the device ICD can be imported into the CDA toolset.  Once the device ICD is imported, it is traced to the service interface.  Once this relatively simple process is accomplished, the interface code and design artifacts can be auto-generated.

Listed below is a description of the application of CDA, patent pending, at each phase:

• Requirements Analysis – Generation of requirements from the Model significantly reduces errors and provides a more complete and correct set of requirements which trace directly to the detailed specifications and code.
• High Level Design – Generation of the High-Level design with accommodations for application-unique design such as tasking/processes. The CDA model supports reuse of the high-level design of each process in that many modules are reused, which includes all of the documents, code, unit testing, and integration testing.
• Detailed Specifications – The detailed specification can be completely generated from the CDA model and toolset. This includes tracing to the requirements as well as tracing to the raw ICD data and API’s.
• Coding – All of the code for handling publish-subscribe data is auto-generated. This eliminates any possible hand-coding errors.  It simply works.  Also, much of the coding style and significant modularity of the software is driven by the CDA process. Therefore, the programmer has to only implement that code which is difficult; they do not spend time on tedious coding which is very error prone.  Instead, they spend their time on the actual application.
• Unit Testing – The modularity of the software developed through CDA give the ability to easily test the modules as well as the opportunity to auto-generate test cases and procedures for each module. This method provides a greatly reduced unit testing effort.
• Integration testing – The publish-subscribe interface provides a well-defined specification for integration testing and simulation. It provides the ability to simulate those inputs that are difficult to provide in a stimulated environment.  This combined with PCTS ability to stimulate those inputs/outputs gives a much more complete integration environment.
• Operational Testing – Testing at this level must still occur, but is significantly simplified due to the correctness and completeness of the modules developed with the CDA process. In addition, the ability to rapidly prototype a functional application early on in the development phase provides important operational feedback, which is invaluable in determining the operational requirements.  This increases the likelihood that the resulting system will function as needed.