White Paper

www.tms.mrcy.com INNOVATION THAT MATTERS ™ Corporate Headquarters 50 Minuteman Road • Andover, MA 01810 USA (978) 967-1401 • (866) 627-6951 • Fax (978) 256-3599 trusted Mission solutions 47200 Bayside Parkway Fremont • CA 94538 (510) 252-0870 • Fax: (510) 490-5529 Mercury Systems and Innovation That Matters are trademarks of Mercury Systems, Inc. Other products mentioned may be trademarks or registered trademarks of their respective holders. Mercury Systems, Inc. believes this information is accurate as of its publication date and is not responsible for any inadvertent errors. The information contained herein is subject to change without notice. Copyright © 2018 Mercury Systems, Inc. 3450.00E-0718-wp-Navy-platforms To learn more, visit us at tms.mrcy.com. Common Module Library Architecture Components Integration Platform (Minimize Number of Each Type) (n >> m) Storage Module(s) Input/Output Graphics Display Module(s) Special Function Module(s) Processor Module(s) System 1.0 System 1.1 System 2.0 System 2.2 System 2.2a System 3.5 System 4.0 System 4.n System (n) (m) Modules (n) Systems "Alphabet" "Library of Congress" ... Figure 5: Common Module Library: Analogous to the AEGIS Common Source library, utilizing common modules simplifies logistics, streamlines deployments, and presents an opportunity for module reuse across any number of different programs, not only within the same ship class, but across the entire fleet. Any configuration assembled, tested, and certified in the lab can be taken to the ship as a set of common modules and potentially installed by a ship's company. The subrack switch plane fabric manager is programmed via a containerized configuration file and remains locked down unless specifically otherwise authorized. The fabric manager will interrogate each installed module and allow it to be used only if the unique ID of each module matches that which is stored within the immutable software container (binary file) used to configure the fabric connections between each module in the system. In the future, this structure will allow an automatic (at boot time) audit of all installed modules and configuration of those modules no matter what their location within each of the CMSRs. Module interconnect configurations will be determined at the time of hardware-software integration. The resulting interconnect topology, together with the specific module load out, will be converted to a container (immutable binary file), loaded, and run whenever any or all modules in the system are booted. Whenever a module is removed and replaced or is rebooted, the event will be recorded as a "critical event," and may be prevented under predefined conditions. Long-term cost savings and performance benefits The common module library we are proposing is analogous to the NAVSEA Common Source Library. The CML will consist of environmentally robust microcontainers that may be precertified for the full, extended operational environment for all systems simultaneously. The extreme modularity and "composability" of the CMER and CMSR will facilitate multiple technology- insertion cycles simply by replacing modules on the ship. Whatever has been integrated, tested, and certified in the lab will run with equal performance and results on the target platform. See Figure 5: Common Module Library; The total cost of ownership for these platforms (as mentioned at the beginning of this paper) can be subjective, but the Navy and the Department of Defense as a whole needs to look at ways of reducing long-term life cycle costs while improving performance. And, as we have demonstrated, both the technologies and methods exist so that they can start today.

• Cover