Virginia Class Submarine

Lead Authors: Heidi Davidz, Alice Squires

This example was developed as a SE example directly for the SEBoK. It describes the Virginia Class submarine sonar system project. In particular, it highlights the approach taken to the development of a sonar system architecture and how this helped in the integration of commercial off the shelf products.

Description

Prior to the Virginia class submarine, sonar systems were comprised of proprietary components and interfaces. However, in the mid-1990s, the United States government transitioned to the use of commercially developed products - or commercial off the shelf (COTS) products - as a cost-saving measure to reduce the escalating costs associated with proprietary-based research and development. The Virginia class submarine system design represented a transition to COTS-based parts and initiated a global change in architectural approaches adopted by the sonar community. The lead ship of the program, Virginia, reduced the number of historically procured parts for nuclear submarines by 60% with the use of standardization. The Virginia class submarine sonar system architecture has improved modularity, commonality, standardization, and reliability, maintainability and testability (RMT) over historical sonar systems.

Architectural Approach: Standardization

Based on the new architectural approacharchitectural approach and the success of the transition, system architecture experts developed an initial set of architecture evaluation metrics:

Commonality
- Physical commonality (within the system)
  - Hardware (HW) commonality (e.g., the number of unique line replaceable units, fasteners, cables, and unique standards implemented)
  - Software (SW) commonality (e.g., the number of unique SW packages implemented, languages, compilers, average SW instantiations, and unique standards implemented)
- Physical familiarity (with other systems)
  - Percentage of vendors and subcontractors known
  - Percentage of HW and SW technology known
- Operational commonality
  - Percentage of operational functions which are automated
  - Number of unique skill codes required
  - Estimated operational training time (e.g., initial and refresh from previous system)
  - Estimated maintenance training time (e.g., initial and refresh from previous system)
Modularity
- Physical modularity (e.g., ease of system element or operating system upgrade)
- Functional modularity (e.g., ease of adding new functionality or upgrading existing functionality)
- Orthogonality
  - Level to which functional requirements are fragmented across multiple processing elements and interfaces
  - Level to which throughput requirements span across interfaces
  - Level to which common specifications are identified
- Abstraction (i.e., the level to which the system architecture provides an option for information hiding)
- Interfaces
  - Number of unique interfaces per system element
  - Number of different networking protocols
  - Explicit versus implicit interfaces
  - Level to which the architecture includes implicit interfaces
  - Number of cables in the system
Standards-based openness
- Interface standards
  - Ratio of the number of interface standards to the number of interfaces
  - Number of vendors for products based on standards
  - Number of business domains that apply/use the standard (e.g., aerospace, medical, and telecommunications)
  - Standard maturity
- Hardware standards
  - Ratio of the number of form factors to the number of line replaceable units (LRUs)
  - Number of vendors for products based on standards
  - Standard maturity
- Software standards
  - Number of proprietary and unique operating systems
  - Number of non-standard databases
  - Number of proprietary middle-ware
  - Number of non-standard languages
- Consistency orientation
  - Common guidelines for implementing diagnostics and performance monitor/fault location (PM/FL)
  - Common guidelines for implementing human-machine interface (HMI)
Reliability, maintainability, and testability
- Reliability (fault tolerance)
- Critical points of fragility (e.g., system loading comprised of percent of processor, memory, and network loading)
- Maintainability (e.g., expected mean time to repair (MTTR), maximum fault group size, whether the system can be operational during maintenance)
- Accessibility (e.g., space restrictions, special tool requirements, special skill requirements)
- Testability
  - Number of LRUs covered by built-in tests (BIT) (BIT coverage)
  - Reproducibility of errors
  - Logging/recording capability
  - Whether the system state at time of system failure can be recreated
  - Online testing (e.g., whether the system is operational during external testing and the ease of access to external test points)
  - Automated input/stimulation insertion

Other Points

The Virginia class submarine acquisition exhibited other best practices. These are discussed by Schank (2011), GAO (2008), and General Dynamics (2002).

These best practices included stringent design trades to keep costs under control, careful consideration of technical maturity of components, and the importance of program stability.

Summary

In summary, the work on the Virginia class submarine prompted a change in the traditional architectural approach used in the sonar community to design submarine sonar and validated the cost savings in both research and development (R&D) and in component costs when transitioning from proprietary interfaces to industry standard interfaces. The identification of a list of feasible architecture evaluation metrics was an added benefit of the effort.

References

Works Cited

GAO. Defense Acquisitions: Assessment of Selected Weapon Programs Report. Washington, DC, USA: US. Government Accountability Office (GAO). March 2009. GAO-09-326SP.

GD Electric Boat Division. The Virginia Class Submarine Program: A Case Study. Groton, CT: General Dynamics. February 2002.

Schank, J.F. et al. Learning from Experience, Volume 2: Lessons from the U.S. Navy's Ohio, Seawolf, and Virginia Submarine Programs. Santa Monica, CA, USA: Rand. 2011. Available at http://www.rand.org/content/dam/rand/pubs/monographs/2011/RAND_MG1128.2.pdf