Modifying the MARK 6 Guidance System Part 1
Draper Laboratory has been the design agent for all U.S. Navy strategic guidance systems since Polaris and for the U.S. Air Force Peacekeeper missile guidance system. In addition, Draper has designed or helped develop radiation-hard, highly reliable inertial sensors for all of the U.S. strategic systems.
The Two Assemblies Comprising the
MARK 6 Guidance System
As the prime contractor for the Navy's Trident D5 missile guidance system, the company oversees the MARK 6 MOD 1 development team of more than 700 engineers from Draper and its major subcontractors as it modernizes the missile's MARK 6 inertial guidance system. The goal is to extend the MARK 6 guidance system life to 2042 while lowering the Navy's future maintenance and support costs and providing a flexible architecture to support new missions and upgrades. Draper continues to maintain the MARK 6 guidance system currently deployed in the Trident submarine fleet.
Critical to MARK 6 MOD 1 program success is affordability and technical risk reduction. Draper is employing sophisticated modeling and simulation techniques to verify designs well in advance of fabricating production hardware. These models also are integrated into a virtual guidance system to provide stimulus to subsystem prototypes to verify their designs.
MARK 6 Guidance System
The MARK 6 guidance system is an integral element of the Trident weapon system. The system comprises a fleet of nuclear submarines capable of launching missiles as part of the nuclear deterrent maintained by the U.S. Navy. It fills the role of the navigation and guidance system on-board the missile.
In short, the purpose of the guidance system is to guide the missile along a trajectory to release points with the proper velocity, such that a reentry body, when released along this ballistic path, will hit the target with the required accuracy. The release points are determined by the guidance system using targeting information provided by the submarine's fire control.
To achieve this goal, the guidance system's primary functional requirements are to determine position, velocity, and attitude of the missile; issue steering commands to the missile; and maintain executive control of the system's modes once in flight. The guidance system also provides the necessary capability to calibrate and test the system while resident in the submarine as part of the overall weapon system operations.
The MARK 6 guidance system consists of two packages: an Electronics Assembly (EA), hosting the system's flight computers; and an Inertial Measurement Unit (IMU), hosting the system's inertial sensors. Both the EA and IMU are physically mounted on the equipment section of the missile. The EA interfaces to the submarine's fire control system and the missile's Flight Control Electronics Assembly (FCEA). The IMU continually senses the motion of the equipment section, providing data for navigation by the mission computer in the EA.
Before launch, the MARK 6 guidance system is initialized by the submarine's navigation system. After launch, the guidance system navigates and guides the missile along the trajectory specified by the mission loaded by fire control.
Internally, the MARK 6 system navigates in an inertial reference frame, which appears essentially fixed in space as the missile travels along its flight. To accomplish this, the IMU consists of a set of four gimbals, joined by rotating axes providing the necessary degrees of freedom to allow the outer case to rotate independently of the inner-most gimbal.
It is on this inner-most gimbal, known as the stable member, that the system's inertial sensors are mounted. The stable member is held fixed in inertial space at an attitude initialized by the fire control system during a pre-launch sequence. Once the orientation of the stable member is established, a control loop takes over. The loop monitors displacement signals from gyroscopes mounted on the stable member and drives torque motors about each of the gimbal axes as necessary to keep the displacement of the stable member as close to zero as possible.
Also mounted on the stable member is a triad of accelerometers. These sensors measure changes in velocity in the stable member's body frame. Data from the accelerometers is used to compute the total velocity and position of the missile while the angular displacement measured about each gimbal axis provides the data for computing the missile's attitude. These computations are performed by the mission computer in the EA and fed into the guidance equations to determine the appropriate commands for the missile to send it along its trajectory.
Although the preceding capability provides considerable navigation accuracy, additional accuracy is achieved through a stellar sighting performed midway through flight. Using a charge coupled device (CCD) mounted on the stable member, the system sights a star and performs a navigation update to remove any uncertainty in the system's initial conditions and thereby further increasing the accuracy of the overall system.
Development of the MARK 6 MOD 1
The success of the MARK 6 system has led to its upgrade, with the request to provide the same capability over a much longer time period than the original system was designed to serve. Because the MARK 6 is scheduled to be retired within the next decade, the U.S. Navy asked Draper Laboratory to explore options for extending its life. The stated goals were to:
• Extend the service life of the MARK 6 system.
• Continue to meet the demonstrated accuracy and reliability.
• Maintain all coordinated interfaces with other elements in the Trident system.
• Reduce life cycle cost.
• Allow for future mission adaptability and technology insertion.
Systems Engineering Approach
To achieve the goals for MARK 6 MOD 1, Draper pursued a formal systems engineering approach which integrated simulation and test throughout as a means to minimize risk, verify the evolution of the design at each stage of the design process, and speed integration. The effort has been divided into the following phases:
• Concept Development Phase: October 2002 to September 2003
• Preliminary Design Phase: October 2003 to September 2005
• Detailed Design Phase: October 2005 to September 2007
• Pre-Production and Test Phase: October 2007 to September 2011
• Production and Support Phases: October 2009 to …
With each phase, the program would execute requirements analyses, design and implementation, and verification activities, progressing toward the final, verified design in a spiral fashion. At the current state of the program, the detailed design of the system is complete with several prototypes built, verification that the system meets its requirements is underway, and the transition to production is beginning.
Concept Development Phase
During the concept development phase, the full range of options for meeting the customer's requirements was explored. This included identifying new technologies available to the design, describing the possible architectures, and ranking the options. A solution which reused as much of the existing MARK 6 system was possible, both in terms of concept of design and hardware, and would provide the most cost-effective and minimal risk solution to the customer.
Preliminary Design Phase
The preliminary design phase further supported this decision, with an architecture being formally defined, partitioning the high-level requirements into lower-level module requirements and describing the interfaces between the modules. At this time, the technology space to implement the system narrowed, with the most viable sensor suites and electronic options carried forward for further study. In September 2005, a Preliminary Design Review was held, at which time the architecture of the new MARK 6 MOD 1 system and its module requirements were reviewed.
Detailed Design Phase
Next, the detailed design phase began with the design of module hardware and the embedded flight software in response to the derived requirements. Throughout this phase, prototype hardware and software were built and tested. At the end of the detailed design phase, a prototype system consisting of all the electronics modules and a simulated missile and sensors was demonstrated, verifying the design at the system's Critical Design Review.
The program now is in the preproduction and test phase, with several complete prototype systems built and undergoing a range of development tests.
The design of the MARK 6 MOD 1 is based on the 4-gimballed, inertially stabilized system design of the MARK 6. It reuses as much of the existing system as possible, including the physical cases and covers for the EA and IMU, the gimbals, and torque motors and resolvers about the gimbals' axes. New technology also has been included in the MARK 6 MOD 1 design, including new sensors and digital processing elements.
The existing MARK 6 system employs mechanical dynamically-tuned gyroscopes; the MARK 6 MOD 1 system will use interferometric fiber-optic gyroscopes (IFOGs), providing a solid-state solution to measuring the angular displacement of the stable member. The accelerometers have been upgraded to further improve the reliability of the proven design of the existing MARK 6 Pendulous Integrating Gyroscopic Accelerometers (PIGAs).
The stellar-sensing CCD also has been improved with increased resolution. Electronics in the system also have been upgraded, including the incorporation of a space-hardened processor based on the commercially available PowerPC design as well as denser and faster memories than were used in the original MARK 6 system. Another major design enhancement was the inclusion of ASICs in the MARK 6 MOD 1 design used to implement the control logic required for the various sensors.
The modular architecture and design of the internal databus of the MARK 6 MOD 1 have proven to be invaluable to the design process. The backbone of this design is its Shared Serial Data Network (SSDN), which provides communications among all of the electronics modules in the system. Throughout design, the interface to each module was clearly defined and controlled by the systems engineering team as tables of message definitions, allowing a fair degree of decoupling among the module design teams as long as the interfaces remained coordinated.
The modularity in the MARK 6 MOD 1 design also benefitted the simulation and test environments. Each module had a clear interface around which the simulations and test benches were designed. This allowed incremental development, check-out, and integration of the electronics modules, significantly reducing schedule risk to the program as the design matured.
Although many paths can be taken to achieve the goal of meeting customer expectation, the one pursued in this case integrated as many aspects of collaboration and system verification through simulation and test as early as possible.
System Test and Evaluation Assets
It is important to understand the infrastructure created to facilitate the simulation and test capabilities. This includes establishing common processes and resources for the Trident community as well as tools needed to simplify common tasks.
Software Engineering Process Group
Given that a significant amount of software would be created as a part of development, including not only the embedded flight software but simulation and test programs, a software engineering process group was established to define policies and procedures for the software teams to follow. The group also would educate the community in best practices for software development. This not only placed emphasis on the sound development of all software on the program, but also encouraged communications among software teams and adoption of common practices and methodologies. The result has been a set of assets including templates, guidelines, and checklists for teams to use in their efforts, training sessions for educating teams and ensuring consistency across the program, and continual process improvement in the development of software.
Central Computing Environment
In a relatively large program with engineers located across the country, the need to collaborate with a consistent set of tools was essential. In response to this challenge, a central computing environment was established that provided a controlled environment for design tasks, the execution simulations, and analysis of data sets. A scalable server, a SunFire 6900, with access restricted to the authorized engineers involved with the MARK 6 MOD 1 program was established.
Engineers at Draper could directly access the machine to perform their work while remotely located engineers used a virtual private network (VPN) established to provide secure access to the server through corporate firewalls. In this way, Draper was able to control which tools were used across the program and ensure consistency and repeatability for critical design and analysis tasks.
Modeling and Simulation Model Repository
Major activities that took advantage of this computational resource early in the program were modeling and simulation. With simulation being integral to the design process from the beginning, a central model repository was established. The content of the repository included individual models, supporting documentation, and test cases used to verify the models. With the overall MARK 6 MOD 1 development program broken down into design teams for the individual modules, each design team was responsible for contributing models of their design to the central repository.
A separate team was charged with integrating these models per the system design in a simulation called the virtual system, which then was available to the community for system-level analyses and data set generation. As designers updated their models in the repository, the integration team would work from the repository to update the full system simulation, keeping the simulation up-to-date with the evolving and maturing system design.
A Central ICD Database
The modular design of the MARK 6 MOD 1 system and its SSDN backbone for inter-module communications was very beneficial to the design process. The design of the SSDN was primarily captured in a relational database early in the program, defining the content, format, and timing of all data exchanged across the databus.
With a central and consistent definition of all the message traffic, the interface control document (ICD) could be readily generated and updated as the system design evolved. The ICD, central to defining the interfaces between modules in the system, also became a key element to the simulation, test, and analysis efforts.
Tools to process the ICD were established to transform the data into structures for the embedded flight software, databus model libraries for simulation development, test software to monitor traffic on the prototype systems, and scripts for plotting and analyzing test and simulation data. In this way, all of the teams on the program were using a consistent definition of the messages in the system. When changes were required, updates were implemented in the central ICD database through a controlled process, and all teams maintained consistency with each other.
Test Data Repository
Finally, realizing that a tremendous amount of data would be generated through the testing and analysis of the system, a Web-based repository for test data was established. This Web-based portal was accessible across the development and test teams on the program and allowed the tests to be cataloged with information about each test's goals, conditions, logged raw data, and any memoranda capturing resulting analyses. In this way, valuable data was immediately available to the community for a wide range of verification activities, and historical data is preserved for reference and comparison as needed.
Part 2 of this article will discuss hardware development, various environmental test cells, and the analyses executed throughout design and verification. It will appear in EE's October issue.
About the Author
Todd Jackson, Ph.D., is a systems engineer in the Modeling and Simulation Group at Draper Laboratory. Dr. Jackson has participated in the design process of the Trident MK6 MOD1, supporting both the design of the system and development of simulations and related infrastructure to verify the design. He is a graduate of Princeton University with a B.S.E. in aerospace engineering and earned his Ph.D. in computer-aided design and fabrication from MIT. e-mail: firstname.lastname@example.org