Modifying the MARK 6 Guidance System

[Lt-Col A. Tack]

Modifying the MARK 6 Guidance System

Part 1

by Todd Jackson, Ph.D., Draper Laboratory

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.

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.

http://img200.imageshack.us/img200/6492/0909aerospacefig1.jpg
The Two Assemblies Comprising the
MARK 6 Guidance System

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.

Link (http://www.evaluationengineering.com/features/2009_september/0909_aerospace.aspx)

[Lt-Col A. Tack]

Modifying the MARK 6 Guidance System

Part 2

by Todd Jackson, Ph.D., Draper Laboratory

As the prime contractor for the U.S. Navy’s Trident D5 missile guidance system, Draper Laboratory 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 life of the MARK 6 to 2042 while lowering the Navy’s future maintenance and support costs and providing a flexible architecture to support new missions and upgrades.

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. It also provides the capability to calibrate and test the system while resident in a submarine as part of the overall weapon system operations.

Part 1, which appeared in the September issue, described the infrastructure developed to facilitate design, simulation, and test of the MARK 6 MOD 1 with an overall systems engineering approach. Part 2 addresses hardware development, various environmental test cells, and the analyses executed throughout design and verification.
Modeling and Simulation

Modeling and simulation are central to the design process for MARK 6 MOD 1 and took the form of developing a series of simulations known as virtual systems.

Functional Simulation

The first virtual system, known as the functional simulation, consists of a simulation faithfully modeling the partitioning of the system into modules in Simulink, with each module represented by models of the control laws and dynamic equations. Simulink, a hybrid simulation tool developed by The MathWorks, is capable of modeling digital processes, discrete events, and continuous time-domain dynamics within a graphical environment.

The shared serial data network (SSDN) model is implemented in a library generated directly from the system interface control document (ICD) through a series of processing scripts. This allows the simulation to accurately model the content and timing of data exchanged between the modules in the system. This was the first full system simulation developed on the program and serves as the truth model capable of generating data sets that can be used as input to open-loop test benches for unit development and tests.

Instruction Set Simulator

The next level of simulation incorporates an instruction set simulator (ISS) based on the Simics tool suite. Simics is a simulation and software verification environment provided by Virtutech. It supports a flexible and scalable simulation incorporating detailed models of electronics with which embedded software interacts.

This technology provides a functionally accurate model of the software-hardware interface in the target processor. The model is capable of executing code compiled for the target processor in a fully virtual environment with control over time and complete visibility into the code execution.

In addition to the off-the-shelf capability provided by Simics, detailed models of the memory controller, databus, and memories were developed in parallel to the design and development of the actual flight computer modules. This allowed the software development process to be decoupled from the hardware delivery schedule.

To provide meaningful stimulus to the flight software under test, data sets logged from the functional simulation were driven into the ISS. The software development teams used this capability to test and debug their designs before the software ever ran on actual hardware.

Flight Software Simulation

As embedded flight software matured, the ISS-based test capabilities were merged into a higher fidelity simulation called the flight software simulation. This simulation consisted of four instances of the ISS, representing the four flight computers in the system, along with the sensor and plant models from the functional simulation integrated within a simulation tool called EASY5.

EASY5 is a multidomain modeling and simulation tool from MSC. It provides a hierarchical, systems engineering view of the simulated models and allows the integration of third-party software.

This environment supported a detailed representation of the databus not only in terms of timing and content, but also message formatting, again derived directly from the ICD. Instead of using control laws in the form of block diagrams to control the system as in the functional simulation, the actual flight software compiled for the target processors would be loaded into the ISSs within flight software simulation, allowing detailed verification of the flight software in a system context.

Detailed System Simulation

The highest fidelity virtual system on the program incorporates the digital VHDL designs of the ASICS and processors using a computer called a Palladium. The Palladium from Cadence is a special-purpose computer known as a hardware accelerator expressly designed for speeding up the verification of digital designs. This technology accelerates the execution of simulations 1,000x over traditional workstation-based simulation.

The seven unique ASIC designs present in the system were integrated into a virtual system per the system design and synthesized into an executable form for the Palladium. This environment emulates the digital logic of the designs at the gate level and executes their logic at a rate of the system clock on the order of tens of megahertz. This level of simulation provides the verification teams a highly accurate and visible means for verifying digital aspects of the design that could not be evaluated by other means.

As the digital designs matured, the dynamic models from the functional simulation were again reused. This time, the gimbals and missile models were executed on a separate UNIX workstation while the digital logic was emulated on the Palladium. Eventually, the capability to fly full missions was established, fully exercising the digital designs over entire mission scenarios and providing design teams with full visibility and access to the ASICs’ states for verification in ways that could not otherwise be accomplished.
Hardware Development and Integration

In parallel to the modeling and simulation activities, hardware was developed. Each module had its own test bench dedicated to support its verification.

For modules interfacing to the SSDN, a communications emulator provided a means to drive message traffic into the module and log its response. Through this emulator, data logged from the virtual systems also could be driven into the hardware prototype, providing meaningful test cases. Also, data logged from the prototype could be brought back into the desktop analysis environment and compared against the expected results from the virtual system. Emulators for other interfaces also were developed, providing the interfaces and behavior of sensors and actuators necessary to verify the electronics module in a unit test environment as much as possible before integration.

As functionality was achieved in prototype modules, they were integrated into the flat system test bench (FSTB) with the goal of complete system integration of all of the electronics modules with a real-time simulation computer and the sensor emulators. In this case, 37 electronics modules in the system were integrated on the laboratory bench. Models running on the simulation computer would feed dynamics into the sensor emulators, identical to those from the module test benches, that would be read by the module electronics.

Commands from the mission processor would be sent to a missile model flying in the simulation computer, allowing closure of all the control loops in the system and demonstration of the full system over a range of operations. This capability provided a means to demonstrate the electronics designs in open architecture in the lab before assembly into the final closed system, permitting probes to be inserted for troubleshooting and verification of intermediate signals between modules.

Environment Test Cells

Simulations are not the only assets available to verification teams. As the full engineering evaluation units are assembled including the sensors in the sealed Inertial Measurement Unit (IMU), test cells are available to evaluate the system. These include the thermal, vibration, and stellar (TVS), centrifuge, and POD test cells.

The TVS test cell is capable of creating dynamic environments on the guidance system for verifying its performance over a range of shock, vibration, and thermal conditions. Not only does this environment stress the performance of the gyroscopes, accelerometers, and gimbal control loops, the test cell also incorporates a star simulator. Sighting a star under these control environments reveals details about the overall system performance and exposes the critical sensitivities of interest for each sensor to the designers.

The precision centrifuge test cell has a radius of 35 feet from its spin axis to its tip and can achieve 25g of acceleration on the UUT and a variety of rate profiles. For testing the MARK 6 MOD 1, both the IMU and Electronics Assembly (EA) are mounted at a distance of 32 feet from the spin axis. Three variable-speed DC motors rotate the centrifuge and, under the current test scenario, bring the guidance system to 7g at a rate of 1g/minute.

Signals from the guidance system are routed through an interface adapter and slip rings to the support equipment and the test station. Sensors are mounted on the end of the arm to sense position relative to surveyed references around the test facility. This instrumentation data is routed to a data acquisition computer to serve as the truth reference against which the performance of the guidance system is measured.

The POD test cell is mounted to the wing of an F-15E and contains the guidance system along with dataloggers, GPS receivers, and an independent IMU to provide instrumentation reference data for subsequent analysis (Figure 1). After take-off, the pilot flies a series of maneuvers designed to generate dynamic loads on the IMU representative of those in a real missile flight. Through a series of turns, dives, and climbs, the IMU senses accelerations and decelerations, exciting various modes in the system.

http://img205.imageshack.us/img205/8727/1009aerofig1.jpg
Figure 1. Pod Test Cell Mounted Under the Wing of an F-15E
Courtesy of the U.S. Navy

Upon landing, the data is removed from the POD for subsequent analysis to verify the performance of the system. Data from the GPS receivers and independent IMU is instrumentation data, providing a reference against which the performance of the guidance system can be analyzed.

Analyses Executed Throughout Design and Verification

Throughout the MARK 6 MOD 1 development, these assets have been used in different ways at the appropriate times to support the design efforts, verify implementation, and mitigate risks.

Verification of Preliminary Interfaces and Requirements

During the preliminary design phase, the system engineering design team was tasked with synthesizing the high-level system requirements into a viable system architecture with derived requirements for modules in the system and definitions for each module’s interface. To support this effort, the development of the functional simulation was tightly integrated with the system design activities.

As requirements for modules were identified, model libraries were updated and integrated into the simulation to evaluate performance at the system level. The ICD evolved with the definition of the module requirements. By generating or auto-coding the databus model directly from the system design team’s ICD, the evolution of the functional simulation remained a high-fidelity representation of the system design. This forced the model of each module in the system simulation to consume and generate its interface data at the specified rates in the system design.

The system design team was able to use the simulation to evaluate the performance of each control loop in the system throughout each mission phase. By the time of the Preliminary Design Review (PDR), the functional simulation had been used to develop and verify requirements for completeness and correctness, including the content and timing of data exchange across the databus. As part of the entry criteria for PDR, the designers were able to demonstrate that the pieces of the system, if built to the derived requirements, should integrate, communicate, and execute as a whole to achieve the higher-level system requirements.

Software Development

Although a processor based upon a commercially available design was chosen for the system’s embedded computers, the full processor modules including support chips and memories were not available to the software developers until well into the program. Rather than delay development of flight software, the software design teams immediately began work on their designs by compiling code for the target environment and executing on the ISS that accurately emulated the flight computers.

The teams started with framework code, developing the lower-level functions required to interact with the processor and I/O interfaces. As the module requirements and the functional simulation matured, both requirements for the application software and test data sets became available.

The software development teams were able to begin work on the four software applications to run on the four separate processors in the system. By directly implementing the system design, the functional simulation was immediately available to generate data sets for driving the code in the open-loop ISS, serving as a truth reference for the expected output for the application code. The developers were able to work in the virtual environments to design and test their software as requirements evolved and the hardware was being developed.

Integration Check-Out and Risk Mitigation

One of the greatest risks in the design of a new system is omitting the flow-down and specification of a lower-level requirement. This results in an incompatibility between modules that is not discovered until late in the program when designs have been solidified and the cost to recover is great. To mitigate this risk, the MARK 6 MOD 1 program set a demonstration of a full system with prototype electronics flying a full mission as entry criteria to its Critical Design Review (CDR). This motivated the early development of the FSTB and forced communications between module design teams and resolution of integration issues early in the program.

With the functional simulation as a reference, the FSTB was incrementally assembled with the prototype modules. As each module was integrated, test scenarios from the lab were compared with the expected behavior observed in the functional simulation.

When it came to software integration, much of the software already had been tested and verified to the scenarios expected to be seen upon integration through the use of the ISS and subsystem test benches. Time spent in the integration lab was dedicated to integration issues between subsystems present only in real hardware and not higher-level functionality issues that were resolved in advance through simulation.

Although the schedule for the FSTB was aggressive, the integration of the mission flight software took only approximately one-quarter of the time allocated. This savings in time is credited to the software development team’s rigorous application of peer reviews and verification through their virtual environments before delivery to the integration teams. Well in advance of system CDR, the design teams were able to demonstrate that the detailed designs of the electronics modules worked in both isolated test beds and a fully integrated system and could perform in all modes of operation across a mission.

Software Verification

The portion of the MARK 6 MOD 1 implemented in software is significant, including control loops for positioning the gimbals in the IMU, interfacing the guidance system to fire control and the missile control electronics, sighting the star, and performing the navigation and guidance calculations. To test the full scope of software, an independent software verification and validation (V&V) team develops test scenarios for execution in the various simulation and test environments.

One of the primary tools available to the V&V team is the flight software simulation. This environment provides the team total control over test scenarios, the ability to inject faults and test corner cases, and visibility into the state of all elements in the simulation including the state of the software execution in the detailed models of the processors in the ISSs.

All of the requirements originally allocated to the software design teams become goals for verification test scenarios that the V&V team creates. As test scenarios are executed in the virtual environments, the status of the design is communicated back to the design teams. Whenever a requirement or the design intent is not met, the design is updated to ensure its quality for the final delivery.

Characterization of System Accuracy

Ultimately, the success of guidance system design is measured in terms of how accurately the system navigates. To characterize the performance of the MARK 6 MOD 1 system, a team dedicated to the accuracy analysis of the system makes extensive use of all available data from the full range of test cells.

In the absence of an exhaustive and prohibitively expensive missile flight test program, the accuracy team designs unique tests intended to excite the system in ways characteristic of the environments expected in flight for each cell. Data from the test cells includes the instrumentation reference data and the navigation data from the guidance system under test.

Using a sophisticated suite of analysis tools developed over years of guidance system design and detailed models of all of the expected error sources in the system, the team assesses the overall accuracy of the system as well as identifies the contribution of each individual error to the overall performance. Presently, MARK 6 MOD 1 has undergone one set of centrifuge tests with another centrifuge series expected in the near future. Preparations also are underway for tests in the TVS and POD test cells.

Conclusion

The design and verification of MARK 6 MOD 1 represent a significant challenge, with the need to meet high expectations set by the existing MARK 6 system in a cost-effective manner. To address this challenge, Draper’s use of a system engineering process that has tightly incorporated simulation and test from the beginning has proved to be a successful approach to the incremental design, development, integration, and test of a system.

At each phase of the program, the system has been tested at the system level to an appropriate level of fidelity. The system architecture, module interfaces, and module requirements were demonstrated through missions flown in a function simulation by PDR; electronic prototypes flying similar missions in the FSTB by CDR; and software verification and system accuracy assessments ongoing through transition to production on the flight software simulation and initial engineering units. Each environment and associated verification activities provide confidence in the design and implementation before the first missile flight. In this incremental, spiraling fashion, risks are retired early, and each subsequent phase of commitment to the design is approached with confidence.

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.

Link (http://www.evaluationengineering.com/features/2009_october/1009_aerospace.aspx)