AEROSPACE/DEFENSE TEST
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.
New Technologies
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
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: tjackson@draper.com