engineering plan pdr - woods hole oceanographic institution · been completed and analyzed, the...

WOODS HOLE OCEANOGRAPHIC INSTITUTION WOODS HOLE, MA 02543

Engineering Plan Document Control No.: 0000000 06-November-2009

6500m HOV Project Stage 1: A-4500 HOV

i A-4500 HOV Project Engineering Plan

Document Control Sheet

Date Originator Description 09-15-09 B. Walden Initial Draft 10-17-09 B. Walden First Revision 10-23-09 B. Walden Second Revision 11-06-09 B. Walden, S. Humphris Third Revision & Addition

of Appendices

ii A-4500 HOV Project Engineering Plan

Table of Contents Page Document Control Sheet i

Table of Contents ii 1.0 Introduction and Background 1 2.0 Personnel Sphere 2 2.1 Personnel Sphere Penetrators 2 2.2 Personnel Sphere Interior 5

3.0 Frame Modifications 5 4.0 Syntactic Foam – Fixed Buoyancy 8 5.0 Energy Storage Systems 11 6.0 Primary Electrical Systems 13 7.0 Command and Control System 15 8.0 Main Hydraulic System 15 9.0 Main Ballast Blow and Vent System 16 10.0 Variable Ballast System 17 11.0 Mercury Trim System 19 12.0 Life Support System 20 13.0 Lighting and Imaging Systems 21 13.1 Lighting System 21

iii A-4500 HOV Project Engineering Plan

13.1.1 Lighting System Detail 22 13.1.2 Lighting Control Electronics 23 13.2 Imaging Systems 24 13.2.1 Internal Video Infrastructure 24 13.2.2 Primary HDTV Cameras 27 13.2.3 Exterior Camera Interface Electronics 27 13.2.4 Manipulator Still Camera 28 13.2.5 Manipulator HDTV Camera 29 13.2.6 Mosaic Cameras 29 13.2.7 Situational Cameras 29 13.3 Support Ship Image Data Processing & Distribution 30 13.3.1 Primary Data Duplication System 30 13.3.2 Still Image Download System 30 13.3.3 Science Data Processing System 31 14.0 Rescue Vehicle System 31 15.0 ABS Classification 33 Appendix I. Energy Analysis of HOV Operations 35 Appendix II. Assessment of Battery Options 42 Appendix III. A-4500 HOV Electrical System Design 51 Appendix IV. Submarine Command and Control System Design 54 Document

1 A-4500 HOV Project Engineering Plan

1.0 Introduction and Background There are two fundamental improvements that could be made to the Alvin submersible allowing it to provide many of the increased capabilities desired by the deep submergence scientific community: 1) improved viewport placement and interior arrangement, and 2) increased energy availability. Accomplishment of either one of these would facilitate numerous beneficial changes, but implementing both together greatly increases what can be accomplished and, in many respects, simplifies the associated engineering. The NSF proposal submitted in 2004 was based upon a plan to construct a new vehicle, perhaps using as little as 10% of the existing submersible’s hardware and instrumentation. The cost quotation resulting from a comprehensive preliminary design indicated that this approach was considerably more expensive than originally estimated and therefore alternative ways to accomplish the objectives were investigated. In July of 2008, Woods Hole Oceanographic Institution (WHOI) proposed a change of direction intended to decrease the scope of the effort beyond that associated with the on-going construction and testing of a new 6500 meter personnel sphere. The plan was to simplify the engineering sufficiently to allow the majority of the goals to be met while remaining nearly within the original budget. This was to be done by using considerably more of the existing Alvin submersible and its technology, thereby reducing the quantity of engineering tasks to a level that could be managed by the National Deep Submergence Facility’s engineering team. To further ensure success, a two-stage approach was suggested. The first stage was to be limited to those tasks required to develop a 4500 meter capability utilizing the new personnel sphere presently under construction. The energy capacity of the new vehicle was to be nearly double that of the present Alvin and the benefits offered by the new sphere’s increased size and viewport arrangement were to be realized. However, the depth rating increase to 6500 meters made possible by the new sphere was to be postponed until a second stage could be scheduled and funded. Success of this approach was recognized to be dependent upon the degree to which existing submersible systems and components could be reused and the amount of engineering effort this would save. The first evaluation of this approach was conducted by the Lockheed Martin engineering team responsible for development of the initial complete replacement vehicle. Their analysis indicated that it was possible to reuse more than half of the existing submersible (both physically and when viewed from a systems perspective), provided the energy storage method intended for the complete replacement vehicle was also available for this approach. This was an important point in that the intended battery was to have the desired increased energy storage capacity (~80 kWh)


and also a weight savings sufficient to offset the decreased buoyancy of the new hull (~1,500 pounds). Based on the strength of the Lockheed findings, WHOI generated a rough project task outline with cost estimates based upon similar work done for other projects (Jason, Jason 2, ABE, Sentry, Nereus, and, most importantly, Alvin). Three high risk areas were identified (also present in the replacement vehicle program): hull electrical and optical fiber penetrators, syntactic foam buoyancy material, and batteries. The first two were considered to have a moderate technical risk, but a substantial schedule risk. The batteries received a high rating in all the risk areas: technical, schedule and financial. This initial analysis has proven to be correct. There are a large number of lesser risks beyond the three identified above. Their evaluation indicates that tasks planned for the stage 1 (A-4500 HOV) effort do not pose technical risks of any consequence. The required engineering is straightforward and is well within the areas of expertise and experience of the personnel available to the Project Management Team. There are, however, many schedule risks resulting from the order in which tasks must be done. The integration of the engineering solutions to various problems, including application of the overarching weight and balance constraints, frequently necessitates an iterative process that takes time. The financial risks in these areas are judged to be minimal provided that scheduling is handled realistically. The following sections present the general engineering approach for construction of the A-4500 HOV and, where possible, provide insight into additional effort required for the Stage 2 6500 meter vehicle (A-6500 HOV).

2.0 Personnel Sphere The Personnel Sphere Construction Plan presents the history, current status, budget and schedule of the construction of the 6500 m personnel sphere. This section details the additional design and work needed to outfit the sphere. 2.1 Personnel Sphere Penetrators The new 6500 meter personnel sphere will utilize electrical and fiber-optic penetrators of a different design than that used with Alvin. The new hull is to have sixteen holes sized to accommodate penetrators with at least 30 #16 wires with spacing suitable for 300 vdc. If fully populated, 480 wires would be available compared to Alvin’s 552. Analysis has


shown that this is a sufficient quantity to allow an electrical system installation nearly identical to Alvin’s. However, the preferred plan for the A-4500 HOV includes replacing as many as four of the electrical penetrators with those designed for optical fiber. This will enable fiber-optic command and data transfers that will eliminate the need for more than half of the copper conductors. Procurement of the electrical and fiber-optic penetrators has progressed sufficiently to eliminate technical risk. Multiple vendors have been located, preliminary designs developed, and final cost quotations received. Once the vendor selection process has been completed, an independent structural analysis will be conducted and the results, design details, and test plan will be submitted to ABS for approval. Estimates based upon the vendor quotations indicate that fully tested and qualified penetrators could be delivered within nine months. The present Alvin personnel sphere has conical holes in the viewport reinforcement inserts for the installation of the electrical penetrators. An external rubber ring provides a low pressure seal, but the primary high pressure seal results from the close tolerance fit of the tapered penetrators within these holes. Internally, the penetrators have two pressure barriers, each with radial O-rings and glass-sealed electrical feed-throughs. The 6500 meter personnel sphere has penetrator reinforcement inserts that are independent of the viewports and do not have tapered holes. The penetrators will utilize face O-rings for the primary seals and an inner radial seal as a back-up. This is the technology utilized for the majority of current high pressure penetrator designs. Figure 1 provides a cutaway view of a preliminary electrical penetrator design for the new personnel sphere. As is the case with the existing Alvin penetrators, two pressure barriers are to be utilized. Each will have dual radial O-rings and an array of 30 glass sealed electrical pin trains.


Figure 1. Preliminary Electrical Penetrator Design Figure 2 provides a view of the preliminary design for the optical fiber penetrators. The design is similar to that of the electrical penetrators in that two independent pressure barriers are utilized. In this case, the fibers are sealed in the barriers utilizing a patented technology unique to the selected vendor and commonly employed for applications required to withstand 30,000 psi.

Figure 2. Preliminary Optical Fiber Penetrator Design All penetrators will be tested to 15,000 psi (1.5 x 6500 meter operational pressure). Both the inner and outer pressure barriers are to be tested independently and as an assembly. In addition, a minimum of eight penetrators (6 electrical and 2 optical fiber) will be installed in the personnel sphere during the final hydrostatic test cycle to operational depth and then removed and independently re-tested. The limited number used for these tests is due


to the requirement to utilize some number of penetrator insert holes for test monitoring instrumentation. 2.2 Personnel Sphere Interior The ergonomic aspects of the new personnel sphere’s interior design are outside the experience level of WHOI personnel available for this project. As a result, we have retained the services of the designer originally employed by Lockheed Martin during their contract. In addition, we have acquired a fiberglass mock-up sphere and have begun construction of a full-scale model of the proposed interior as part of the development process. This will facilitate science community input, as well as having the obvious technical design advantages. At present, three major interior arrangement iterations have been completed and analyzed, the first two having been extensively modified as a result of experience with the mock-up. This process is continuing with the third iteration under construction and evaluation. Figure 3 shows the general concept presently under consideration.

Figure 3. Interior Arrangement Study. Concepts are evaluated with models constructed within the full sized personnel sphere mock-up.

3.0 Frame Modifications The new personnel sphere is larger and heavier than the sphere within Alvin (+6.38” dia., +4018 lbs. air weight, +1368 lbs. water weight). However, installation will be accomplished with redesign of the forward 1/3 of the existing Alvin frame and


replacement of the existing forebody flotation material, including the main ballast tanks. The resulting submersible will be 6” longer (sphere diameter increase) and the center of gravity (CG) will move forward, affecting the single point lifting tee location and the submerged trim. The personnel sphere diameter increase will also result in increased height (6” max), and this can be compensated for by decreasing the sail height. Analysis shows that these changes are not significant and will not substantially alter the new vehicle’s characteristics compared with the current Alvin. The required frame modifications are not structurally difficult problems. Historically, the frame changes required when converting from R/V Lulu’s elevator lift to the Atlantis II single point A-frame launch and recovery system were considerably more challenging, particularly when considering that the forebody release capability was maintained. The design and analysis associated with this conversion was done by the Alvin Group’s mechanical engineering section with the fabrication work contracted to Ti-Fab Inc, the original manufacturer of the frame. Figure 4 shows the existing frame with the single point lift modifications highlighted in yellow.

Figure 4. Alvin’s titanium frame showing the modifications made to allow launch and recovery with a stern A-frame rather than an elevator system. The approach successfully employed previously will be used for the frame modification required for this project, possibly including the choice of fabrication vendor (competitive bids are to be obtained). Figure 5 shows a frame modification concept that meets the requirements as they are currently understood, and Figure 6 shows the new personnel sphere within the modified frame. The associated weight and balance analysis must be continuously refined since it defines the lifting tee’s location. Analysis has shown that the


constraints on the tee’s location easily allow meeting the extreme case conditions bounded by the need to continue use of the existing 5,000 pound lead-acid batteries and the possibility of eventually utilizing a battery having less than half that total weight, as might be the case with lithium based chemistry. The lifting tee’s attachment is to be designed such that its location can be adjusted by a small amount without major changes to the underlying frame structural members.

Figure 5. Alvin frame modifications required to accommodate the new 6500 meter personnel sphere. The new frame components are shown in yellow.

Figure 6. Modified Alvin frame with new personnel sphere installed. The Lockheed Martin manipulator mount design is shown along with a pair of larger variable ballast spheres and the existing Alvin lead-acid battery packs.


4.0 Syntactic Foam – Fixed Buoyancy The availability of syntactic foam flotation material is critical to development of the A-4500 HOV. The replacement personnel sphere requires new forebody foam packages and these are complicated enough to preclude transferring similar items from Alvin. Additionally, constructing the necessary shaped foam blocks from the as-molded product is both expensive and wasteful of material. Therefore, any foam procurements required for the new vehicle should be specified for use at the eventual 6500 meter operational depth in order to prevent the need to eventually repeat the procurement process. Obtaining syntactic foam suitable for use at 6500 meters is not particularly challenging provided the weight of the foam is not important. However, the amount of foam needed by a submersible and the limitations on available volume necessitates obtaining the lightest foam possible within the budget and schedule constraints. Project engineers have developed a syntactic foam specification for foam weighing 31 pounds per cubic foot. Considering the tolerances contained within this specification, it is expected to result in delivery of foam between 31 and 32 lbs/ft3. At present, only two vendors have been located that may be capable of producing the high strength syntactic foam suitable for our application. Both of these are conducting tests in order to evaluate their ability to meet the 31 lbs/ft3 specification. However, neither is optimistic and therefore the A-4500 HOV weight and balance analysis has used foam weighing 36 lbs./ft3. We expect to have realistic density information with price and delivery quotations from both vendors by mid-November. An ROM price and delivery estimate has been obtained from one of the vendors and it justifies considering new syntactic foam to be of low technical risk, but high schedule risk. This can be mitigated substantially by specifying a requirement for partial product shipments during the manufacturing time period. This will allow the time-consuming block forming and shaping process to begin early in the production period. Additionally, the foam manufacturing process is such that changing the procurement specifications to allow heavier foam (i.e. 38 lbs./ft.3) or foam rated for only 4500 meters will make a difference in the delivery schedule. Therefore, the schedule risk can be reduced by purchasing a combination of foam types, while ensuring that use of the “lesser” material is minimized and restricted to blocks having simple shapes and therefore easily replaced. Quality assurance provisions for the manufactured foam provide another complication for the syntactic procurement process. Historically, production quantities of foam are evaluated by a combination of first article destructive testing and production sub-sampling using representative product coupons. This method is known to suffer from the need to assume that the coupons are truly representative despite the fact that syntactic


foam is not homogeneous. The existing specification compensates for this by specifying a high factor of safety, particularly in the case of hydrostatic crush pressure where FS=1.7. For submersibles working at depths such as Alvin’s this has not been a problem since foam manufactured by standard methods can have a reasonable density and still pass the specified test requirements. However, for 6500 meter operations, the test method and resulting need for a high factor of safety results in foam with a density considerably greater than desired or prohibitively expensive. A possible solution is to change the specification such that 100% testing is required rather than sub sampling and thereby guarantee that a product deficiency will be detected rather than compensated for by a high factor of safety. In theory, a process of this nature would be superior to the existing procedures except that experiments have indicated that its possible for syntactic foam to be damaged by hydrostatic pressure without showing visual signs. If this is true, the testing process could be doing more harm than good. Fortunately, utilizing acoustic emissions monitoring to detect damage or failure appears to be the ideal solution. Experimentation has shown that acoustic monitoring during hydrostatic testing clearly and decisively allows detecting the point at which syntactic foam begins to fail, even in cases where subsequent visual inspections have not indicated damage. The method is easily applied once the pressure test facility is properly equipped and the results are unambiguous and automatically documented. We plan to modify the specifications generated for 31 lb. foam mentioned above by correcting the acceptable density in accordance with the results of the on-going testing. In addition, the specifications will require a first article, full block crush test value in excess of 1.4 x the 6500 m operational pressure and, thereafter, 100% full block testing to 1.25 x operational pressure. All hydrostatic testing is to be done using specified acoustic monitoring procedures. This test procedure will need to be approved by ABS and documentation for submittal is under development. Figure 7 provides an overview of the syntactic foam volumes and possible arrangement required for the A-4500 HOV utilizing the existing Alvin lead-acid batteries. The analysis assumes 6500 meter rated foam having a density of 36 lbs./ft.3. The overall frontal area has been constrained to essentially the same as the present Alvin in an attempt to maintain the forward motion hydrodynamic drag coefficient. The width is the same as Alvin’s since this constraint allows passing through the existing submersible hangar door on R/V Atlantis. The horizontal plane area is greater than existing, which will increase the vertical drag, but this effect will be mitigated to some extent by a smoother aft body shape resulting in a decreased upper horizontal plane area. More importantly, the service weight droppers are to be modified to allow use of increased ascent and decent weights in order to compensate for the vertical drag increase. Complete analysis of the


hydrodynamic characteristics can be done only after the syntactic foam density is known and the volume of required foam established. At this point in the design, calculations indicate that it will be possible to essentially maintain the present Alvin’s horizontal and vertical transit characteristics and improve upon them with the A-6500 HOV modifications as a consequence of lighter replacement batteries.

Figure 7. Arrangement of 6500 meter rated 36 lbs./ft3 syntactic foam sufficient to accommodate the 6500 meter personnel sphere and the existing Alvin lead-acid batteries. As mentioned previously, the new personnel sphere is 6” greater in diameter than the present Alvin sphere and therefore it will not be possible to reuse major components from the existing forebody, including the forward main ballast tanks, bathtub and sail, in addition to the present syntactic foam. As with the single point lift frame modifications, these items were designed by Alvin group personnel and many were constructed in-house. The work involved in developing designs for these components is well within the capabilities of the existing Alvin engineering and operations groups. The required fabrications can be accomplished by any competent boatyard or fiberglass shop and this type of work is done routinely during all Alvin major overhauls. Figure 8 provides an overview of the preliminary A-4500 vehicle design, including concepts for the required fixed buoyancy assemblies and the sail.


Figure 8. Preliminary design overview of the A-4500 HOV showing installation of the 6500 meter personnel sphere with the required flotation material

5.0 Energy Storage System A review of recent Alvin dive history shows that dives are terminated in approximately equal proportions by operational constraints, completion of planned activities, and depletion of available power (see Appendix I). The data available does not indicate the degree of power conservation effort required by the pilot and science party necessary to obtain these results, but most dives could benefit from increased energy capacity. Alvin’s present usable lead-acid battery capacity is approximately 40 kWh (after de-rating to maintain acceptable cycle life), and is contained within two of the existing three battery bays. Although space would allow a third battery, it has not been installed due to the impact on the vehicle’s size and weight. Installation of a third battery would require the addition of approximately 50 cubic feet of syntactic foam and would preclude the present use of the third battery bay for down-looking cameras, sonars, and other science instrumentation. Energy storage technology has been of major importance for many years, resulting in the advancements that have enabled laptop computers, cell phones, portable electric tools,


and many other common products. The primary characteristics of many of the currently available battery types would seem to make them well suited for use in a submersible. However, in most cases, close investigation results in discovery of problems that either preclude use of the technology or indicate that considerable development effort would be required. Lithium-based batteries are one of the few exceptions; they are presently in use within a number of deep submergence vehicles, including the Japanese Shinkai 6500 human occupied submersible. Investigations conducted in the early stages of the HOV 6500 Project indicated that lithium-ion batteries were available that could provide the desired energy storage improvement. Unfortunately, during a WHOI engineering visit to a battery vendor’s manufacturing facility, one of the lithium-based batteries under test caught fire. By itself this was not considered to be a major problem since the battery was undergoing abusive testing. However, a month later, a similar battery caught fire while installed in a submersible vehicle and caused substantial damage, despite the fact that the fire was detected quickly and the vehicle was available to fire fighters. These two fires have caused many battery powered systems operators to reconsider the safety measures that must be taken when high capacity lithium batteries are utilized. The likely resulting “rules”, “requirements” and “guidelines” will undoubtedly apply to the Alvin replacement and, when finalized, will need to be factored into the design. This represents an unexpected scheduling problem since the battery safety analysis is ongoing and therefore updated safety guidelines have not been made available. The energy storage system is obviously a major contributor to the weight and balance analysis of the new vehicle. The initial concept was based upon the availability of lithium-ion batteries that weigh half as much as the existing Alvin lead-acid batteries, but have almost twice the energy storage capacity. If batteries of this type are not available for the A-4500 HOV design, additional flotation material will be necessary to compensate for any increased weight of the alternative. An investigation has been conducted into the availability of alternative energy storage solutions and the results are presented in Appendix II – “Assessment of Battery Options”. It demonstrates that, when all the variables are considered, there are no practical alternatives available for use in the A-4500 HOV other than continued use of Alvin’s existing lead-acid batteries. As a result, all of the A-4500 HOV preliminary design decisions have been made with the knowledge that the existing lead-acid batteries will need to be utilized. The possibility of increasing the capacity of the existing lead-acid battery has been investigated, but the calculations to date indicate that the vehicle’s size and weight constraints prevent adding the required additional lead-acid cells; at a minimum, a complete 120 volt battery assembly would be required.


Appendix I – Energy Analysis of HOV Operations – provides an energy analysis conducted to determine the consequences of continued use of the existing Alvin batteries. The analysis shows that the A-4500 HOV’s performance characteristics will be similar to those of the existing Alvin rather than greatly improved as was originally intended. However, once the lithium-based battery technology becomes more mature and is proven to be safe for human-occupied vehicle applications, we will replace the lead acid batteries in the A-4500 HOV with lithium-based battery technology in the A-6500 HOV.

6.0 Primary Electrical Systems The majority of the systems and components installed external to the personnel sphere will be those presently used on Alvin. The major changes will be in the electrical area, primarily as a result of the availability of the personnel sphere’s fiber optic penetrators and of a redesign of the command and control system. The design will be guided by the fundamental principles responsible for Alvin’s safety and reliability, but the hardware will be different and four new pressure housings will be required: two for primary electrical system control and two for instrumentation power and data interfaces. These pressure housings will be designed for 6500 meters in preparation for Stage 2 of the project. Much of the hardware necessary for the A-4500 HOV is presently in use on other NDSF vehicles. Those components that have been identified as new or requiring extensive modification have been evaluated for this application with no problems of consequence discovered. The design has not progressed sufficiently to allow final component selection, and therefore it has not been possible to accurately define the pressure housing requirements, but they will be similar to the WHOI-designed titanium housings presently used on the Jason 2 ROV and Alvin for the thruster, variable ballast, and hydraulic system motor controllers. The eventual final designs will have weight and balance implications, but the on-going weight and balance analysis includes a substantial margin of error for these items. Appendix III – A-4500 HOV Electrical System Design – describes the requirements and preliminary design of the A-4500 HOV electrical system. Management of the instrumentation power and data I/O forms an important part of this system, and it is a substantial departure from the present Alvin installation due to its use of the fiber optic penetrators available with the new personnel sphere. The design is modular and utilizes a number of proven, off-the-shelf components, plus an interface circuit board specifically designed for the intended purpose by WHOI project engineers. The board provides for


digitally-controlled voltage conversion, power switching, and ground detection. Prototypes have been constructed and successfully tested. Figure 9 provides a simplified overview of the design depicting four primary power channels and six data channels. The number of channels can be increased by adding additional modules up to the space constraints of the two planned “data system” pressure housings. The A-4500 HOV design incorporates a third similar but smaller pressure housing dedicated to science basket and manipulator instrumentation. Control and monitoring software running on computers within the personnel sphere communicates with external instrumentation and hardware via Ethernet connections utilizing one or more of the available fiber optic links. Circuitry within the external pressure housings convert the fiber signals back to the more easily managed copper-based Ethernet after which they provide connectivity to a number of off-the-shelf components and the newly designed instrumentation interface cards mentioned above. Science instrumentation requirements will be met by a combination of data channels provided by Ethernet to serial converters and power control enabled by the interface cards. The simplicity of the system facilitates tailoring to the requirements of specific instruments as well as future expansion. There will be direct Ethernet connections available for instruments that can utilize them, and there will be four uncommitted optical fibers available for high bandwidth science use or operational expansion.

Figure 9 – Simplified view of the A-4500 HOV instrumentation power control and data communications system. The design is modular and easily expanded to increase the number of power and digital channels.


7.0 Command and Control System The interior of the new personnel sphere requires a careful design encompassing both engineering and ergonomic considerations. The command and control system philosophy is fundamental to this design process since it defines many of the component volume and location constraints. We will utilize the technology presently in use with the Jason 2 and Nereus vehicles. This has been developed at WHOI with the understanding that it would migrate to use by all of the vehicles of the NDSF as time and funding allowed. The 6500 meter personnel sphere’s fiber-optic penetrators enable this technology’s application in the new vehicle and the design has progressed sufficiently to eliminate technical risk. Appendix IV – Command and Control System Description – provides the system specifications and resulting basic design. A fundamental aspect of the command and control system is the use of computers, touch screens, and similar technologically complex components. Historically, the Alvin design has purposely avoided complexity of this type for systems requiring the highest degree of reliability. This practice will be continued in the new design. At a minimum, the following items will be “hard wired” to their inboard control switches: Battery drop components Manipulator jettison hardware Science basket release Service releases (ascent and decent weight droppers) Rescue buoy deployment device Primary communications equipment (UQC, Radio) Leak detectors Situational awareness lights & cameras Battery contactor control Secondary propulsion, variable ballast & main ballast controls

8.0 Main Hydraulic System The existing Alvin hydraulic system is shown in Figure 10. This system is used primarily for the two manipulators, the mercury trim system, and to change the orientation of two of the aft electric thrusters. A four-valve manifold is provided for science applications and connections are available at the science basket interface. The primary power for the system is a 5 hp, 120 vdc brushless motor, identical to that used for the variable ballast


system. In fact, the arrangement of the variable ballast and hydraulic pumps is such that either or both of the electric motors can be used to drive either pump. Improvements to this system, including increased pressure and flow, are possible but the majority depend upon the availability of higher horsepower electric motors. These will be easily obtained when the primary battery voltage is increased to 240 vdc as planned for the A-6500 HOV but weight and efficiency concerns are preventing their consideration for use with the present 110 vdc system. As a result, A-4500 HOV does not involve changes to this system beyond those necessary for interface with the new command and control system.

Figure 10. Main Hydraulic System

9.0 Main Ballast Blow and Vent System Alvin’s main ballast system uses compressed air stored in two titanium pressure spheres to blow the water from five fiberglass ballast tanks having a total volume of approximately 40 cubic feet. This provides about 2,500 pounds of buoyancy, which is used to hold the submersible on the surface during launch operations until the pilot is ready to dive, and also to provide increased stability during recovery in order to prevent excessive motion due to swimmer activities. The five tanks are divided into three groups as shown in Figure 11. Each group has independent, solenoid-operated blow and vent


valves. The tanks are open on the bottom and therefore freely flood or empty in accordance with the controlling air pressure. The vent valves are designed to allow connection to a source of compressed air carried by the launch and recovery support boat in case the blow system malfunctions. The A-4500 HOV will require replacement ballast tanks because of the new personnel sphere and associated syntactic foam. The forward tanks are located against the existing sphere within the existing foam blocks and therefore do not have the correct shape for use with the new sphere. The aft tank will need to be moved further aft in order to make room for additional syntactic foam required as a result of the new sphere’s increased weight. The remainder of the blow and vent system will remain as shown in Figure 11.

Figure 11. Existing Main Ballast Blow and Vent System

10.0 Variable Ballast System Figure 12 provides a simplified diagram of the variable ballast system presently installed in Alvin. In basic terms, it allows pumping water in and out of the fixed volume provided by six 24” titanium spheres. This allows the weight of the submersible to be adjusted over a range of approximately 400 pounds during a dive, thereby enabling attaining neutral buoyancy at varying depths and with different scientific payloads. The system uses a


specially designed 6000 psi saltwater pump in conjunction with a set of hydraulically actuated flow control valves. The control valve hydraulic power is provided by an independent, small hydraulic plant, which is not interfaced to the main hydraulic system. The pump is driven by a 5 hp, 120 volt electric motor identical to that of the main hydraulic system. This system has proven to be effective and trouble free over many years of use within Alvin. The A-4500 HOV does not require it to be changed, but modification will be required for 6500 m operations. The six spheres are not adequate for 6500 m, and the 5 hp motor is undersized for a reasonable pumping rate at the required 10,000 psi head pressure (the pump itself is adequate for use at these pressures). The solution for the A-6500 HOV is to replace the six spheres with two larger spheres designed and certified for the higher pressure. It will be possible to increase the pump horsepower because of the planned primary voltage increase from 120 vdc to 240 vdc once lithium-based batteries are used. The A-4500 HOV preliminary design includes the space and frame modifications necessary to support two ~30 inch diameter, 6500 m rated spheres. Actual replacement of the spheres is not recommended for the A-4500 HOV because, based upon preliminary design information, the two new spheres are expected to be considerably heavier than the existing six spheres. The new spheres must be located near the vehicle’s center of gravity in order to prevent ballast changes from affecting trim. This makes their weight a substantial issue when added to the requirement to float both the new personnel sphere and the existing lead-acid batteries. In the longer term, this problem will be mitigated by the increased buoyancy margin provided by replacement batteries. Additionally, experience with electron beam welding technology used for the personnel sphere is likely to result in the ability to design replacement spheres that are lighter but still able to meet ABS guidelines. At this point in the preliminary design process, approval for continued use of the existing spheres has not been obtained from ABS. Their use at 4500 m requires a minimum internal pressure, and it will be necessary to show ABS engineers that the design includes the safeguards necessary to ensure that this minimum pressure is maintained. This should not be difficult; internal pressure monitoring has been part of the Alvin operational procedures for the past 40 years. However, if these spheres cannot meet ABS requirements, it will be necessary to proceed with the replacements planned for the A-6500 HOV.


Figure 12. Existing Variable Ballast System

11.0 Mercury Trim System Alvin’s present mercury trim system allows transfer of 500 pounds of mercury between containment spheres mounted at the front and back of the submersible. The transfer is accomplished using a secondary hydraulic plant powered by the primary hydraulic system in order to prevent mercury contamination of the primary plant. The general system diagram is shown in Figure 13. This is a simple, efficient and reliable system, which does not use components affected by pressure. Its capacity is adequate for the planned replacement vehicle and could be easily increased if necessary. As a result, the present mercury trim system will be transferred from Alvin without change as part of the A-4500 HOV construction.


Figure 13. Mercury Trim System

12.0 Life Support System The life support analysis performed by Lockheed Martin confirmed the adequacy of the existing Alvin design and will be the basis for the ABS submission. ABS requires that slightly more oxygen be carried within the personnel sphere (an additional eight hour capacity) and the oxygen needs to be carried in slightly smaller flasks. These requirements have been factored into the on-going personnel sphere interior design effort. Figure 14 provides an overview of the primary components of the life support system.


Figure 14. Life Support System 13.0 Lighting and Imaging Systems The following discussion subdivides the lighting and imaging systems into nine major categories:

• Lighting System • Internal Video Infrastructure • Primary HDTV Cameras • External Camera Interface Electronics • Manipulator Still Camera • Manipulator HDTV Video Camera • Mosaic Cameras • Situational Cameras • Support Ship Image Data Distribution

13.1 Lighting System The lighting system for the A-4500 HOV will consist of LED arrays instead of the current mix of arc lights, incandescent and small low power LEDs. The new vehicle’s personnel sphere design represents a significant increase in the observer and pilot’s field of view as a result of the larger viewports and their placement. This increased field of


view is enhanced by a change in the current lighting system in both light locations and the amount of light available in various areas around the submersible. Data provided by the supplier of Alvin’s present lights predicts a substantial power savings in converting to LED arrays versus the current lighting systems. Additionally, there will be an overall improvement in the beam pattern and uniformity of the illumination field. The lighting system can be broken down into the following categories:

• Situational and Emergency Lighting • Forward Piloting and Maneuvering Lighting • Off-axis Panoramic Observer Lighting • Video System Camera Lighting • Down-looking Survey Lighting

The proposed lighting design includes multi-spectral lights for various submersible operational tasks, such as distant piloting visibility and close-up manipulative tasks. Also, a high-intensity pulse-illumination mode is intended in support of ultra-high resolution still imagery, including down-looking optical surveys. The pulse-illuminated mode provides a means for producing pulses of light greater than can be accomplished in the continuous operational mode. 13.1.1 Lighting System Detail The lighting design for the A-4500 HOV uses LED lights due to their increased efficiency and improved beam patterns when compared with the existing HMI technology. Up to eleven 400-watt HMI equivalent LED lights are planned for providing the basic illumination for submersible operations. Of these, as many as nine will be for horizontal viewing while the remaining two will be used for bottom approach illumination and down-looking image surveys.

A set of smaller LED lights will be provided to even out areas in the large LED illumination field pattern. They will also be used for close range side viewport lighting, supplemental lighting for the trainable video cameras, and to provide the illumination required by the pilot’s situational video cameras.

The goal for this design is to provide twice the amount of illumination currently available from the present HMIs. Present estimates indicate that the increased efficiency of the LEDs lights, coupled with improved reflector designs, will allow this to be done for the


same or lower electrical power. All lighting fixtures are to be designed for 6500-meter operations.

Studio Max modeling software is being used to analyze and optimize the lighting arrangement. The lighting hardware is being designed at DSPL in San Diego, CA, and WHOI will evaluate beam pattern and frequency characteristics as prototypes become available. The resulting data, in conjunction with the model, will be used to provide feedback to DSPL during their design process. Changes in the light head reflector design can alter the beam pattern, and the selection of the installed LEDs can be used to tailor the output illumination frequency (color). The Studio Max model will allow experimentation with the tradeoffs between light placement and reflector geometry. The goal is to provide even illumination throughout the pilot and observer fields of view. Physical mounting constraints make this a challenging problem, but utilization of smaller “fill-in” lights will be of benefit. Adjustments to the number and type of LEDs used in each light fixture will allow arriving at an output frequency combination that is a good compromise between the requirements for near field, high illumination sampling and imaging activities and distant viewing for piloting purposes. For example, blue green LEDs may be best suited for high altitude or long-range navigation functions while 5600K LEDs are better suited for HDTV imaging operations. 13.1.2 Lighting Control Electronics LED light sources offer a number of control possibilities beyond that of their arc-lamp predecessors. These are based upon the high variability of light output versus supply current, which ranges from a normal, continuous, high-efficiency level to an instantaneously less efficient, high output, pulsed mode. The A-4500 HOV design includes the electronics necessary to allow these lights be utilized over the range of possibilities as listed and discussed below:

• Normal operations on/off power efficient mode • Ramped or modulated output mode • Pulsed or strobed mode

Normal Operations The LED light fixtures will be controlled from within the personnel sphere via a command and control touch screen GUI interfaced to external power on-off circuitry housed in the power control pressure housings. The light head supply current will be limited to a value optimized for power efficiency. The lighting levels will be determined by the number of activated lights.


Ramped or Modulated Mode In this mode, the LED light output intensity is ramped up briefly during times when still images are acquired, or possibly when beneficial to the science activities for other reasons. The intent is for this mode to replace strobed lighting for still imagery. Strobed or pulsed illumination results in flashes in the video imagery acquired by those cameras not involved in the capture of the still image. Ramping the light level up provides time for the aperture settings for all of the cameras to automatically adjust to the higher light level and the image flash is avoided. The acquired frame-grabbed or still camera image benefits from the reduced aperture setting by having a greatly increased depth of field. Ramp or modulation timing will be as fast as possible but within the individual camera’s capability to compensate for light level changes, therefore making the increased brightness unperceivable on the video imagery. This method will be less energy efficient and experimentation is planned to determine the value of this approach. Pulsed or Strobe Illumination The lighting system design will include provisions for conventional strobed still image lighting. This differs from simply high speed ramped control as discussed above in that the light output is changed too quickly for the cameras to provide automatic adjustment. Instead, in the case of a single camera arrangement, the camera prepares for the flash and, when ready, triggers the strobe. If multiple cameras are involved, as might be the case with a stereo mosaic imaging capability, a central timing processor controls and synchronizes camera preparation and strobe firing. If continuous lighting is not required (implying that motion video is not in use), strobed lighting allows the most efficiency. Down-looking survey cameras frequently operate in this mode. However, if experimentation shows that the ramped mode can provide acceptable efficiencies, it may not be necessary to purchase and install the required strobe timing hardware, thereby saving cost as well as reducing system complexity. 13.2 Imaging Systems 13.2.1 Internal Video Infrastructure The internal video infrastructure is the foundation for present and future imaging system components for the new submersible. The internal video system accommodates all external camera signals and internal computer displays, and distributes them to recording, display, and data overlay subsystems. It also utilizes the submersible’s master timing controller to synchronize cameras and lights as necessary. Software GUIs are utilized to


provide the pilot and observers with the means to control the various aspects of the imaging system. The following component categories are included in the design:

• Camera command and control system • Video routing system • Recording systems • Monitoring and display system • Synchronization and time code generation system

Camera Command and Control System The camera control system provides the means to control all external camera and lens functions. It will also control both cameras and lights for the acquisition of still images, either from a dedicated ultra-high resolution still image camera or as frame-grabs from the high definition video cameras. The still image acquisition GUI will provide both interval and on-demand operational modes. Camera lens and positioning will be managed by a combination of GUIs integrated into the submersible’s command and control system and hand control boxes. Video Routing System The video routing system consists of a 32 input by 32-output serial digital interface (SDI) video router. The router will interface the camera, recorder and computer display source feeds to the monitors and recording devices in the personnel sphere. This system allows source-destination re-configuration without the use of patch cables, and includes the capability to re-clock the SDI source signals such that they are buffered and corrected for signal jitter, thus eliminating a common source of signal degradation. The following in-hull video signal formats will be supported by the SDI router: SMPTE SDI 259M, 292M, 372M and SMPTE 424M. SDTV analog camera feeds will be converted to SMPTE 259M for display on auto-source-detection monitors and displays. Small HDMI/DVI signal converters will be used for computer sources without HD-SDI outputs. Router control will be managed by both a GUI operating on a submersible command and control touch screen and a remote panel controller. The command and control GUI for router control will be fully integrated into the other aspects of the submersible’s control system and will be designed by the command and control development team.


Recording Systems The in-hull recording system consists of the motion HDTV video recorders used to record HDTV video from the selected HDTV external cameras. The recordings will be time-stamped using SMPTE time code from the master time code generator. Additionally, two audio tracks will be available for use with port and starboard internal open microphones. A recording media study is in progress intended to determine the best media and compression format for recording the HDTV motion video. The study is investigating image quality and cost implications of potential changes to the current archiving and science video product workflow. Two general system types are under consideration: one that uses consumable media and one that uses media that can be recycled. The goal is to maintain the present per-dive media costs if possible, although an increase of as much as double is anticipated. Monitoring and Display System The monitoring and display system consists of three 7-inch HDTV LCD flat panel displays for use by the pilot and observers when controlling the external cameras. These panels will be specifically chosen to provide the resolution necessary to correctly evaluate camera function. A pixel-to-pixel zoom feature will facilitate proper focusing of the camera optics and a simple waveform display will be available to allow the camera operator to observe the signal levels and exposure. As previously mentioned, the primary camera and lighting control will be managed by the submersible’s command and control system using the primary touch screens or, alternatively, hand-held controllers. Master Synchronization and Time Code Generator The master timing control system consists of a master synchronization generator, time code generator, and distribution amplifiers. These devices provide synchronization and timing signals as necessary to all imaging hardware in the personnel sphere as well as the external cameras and lighting system. A SMPTE time-code generator will be locked to a NTP time source generated by the submersible’s computer control system. This system will ensure a common time-base for all data collection processes. Figure 15 provides an overview of the internal imaging system hardware.


Figure 15. Imaging System – Internal Block Diagram

13.2.2 Primary HDTV Cameras Two primary single chip 1920x1080 HDTV cameras will be provided for port and starboard forward imaging. These will be integrated with 13X zoom lenses and mounted on the current Alvin pan and tilt mechanisms. One of these cameras has been funded and will be installed on Alvin for use in analog mode early in 2010. This camera’s imaging sensor will be upgraded for the A-4500 HOV to match a second, new camera, to be constructed using hardware that will not become available until later in the year. The sensor upgrade will provide increased light sensitivity and superior color characteristics. Both of these cameras will be used in digital mode following installation of the internal imaging system hardware discussed above. The long focal length zoom lenses will provide the observers with the ability to zoom in on objects at a substantial distance from their viewport and document them as still images and motion HDTV video. 13.2.3 External Camera Interface Electronics External electronics are used to provide a common signal interface between external science camera systems and the control and recording equipment within the personnel sphere. The hardware required for the two primary brow-mounted cameras can be placed within one of the command and control pressure housings but, when the number of high definition cameras increases, an independent 6500 m pressure housing will be necessary.


The system’s primary task is to convert camera control and imaging signals from their native format to that required for transmission through the submersible’s personnel sphere via a fiber optic connection. The first step is to convert the raw LVDS data from the individual camera heads to HD-SDI SMPTE 292 HD Video – the format to be used within the personnel sphere for display and recording. Transmission into the personnel sphere will be accomplished with a fiber optic telemetry system, tailored to the task of supporting the seamless transmission of HDTV imagery at high data rates and high signal to noise levels through an optical fiber. The external pressure housing, closely coupled with an associated, dedicated junction box, will include a number of spare standardized camera interface connections that will greatly simplify future camera additions and replacements. This external interface system also includes the image recording hardware required for each camera in order to capture and time stamp still images at the full LVDS format resolution of the camera imagers. The motion video signals transmitted through the sphere must be down-converted to HD-SDI SMPTE 292 before transmission through the optical fiber and therefore they are not the best source for still image capture. By placing the recording hardware in the external pressure housing, the captured images will be of the highest quality possible. The camera control system will allow image capture by any of the installed principal cameras at a constant user-defined time interval or on demand. The image storage system for each camera will be sized to hold up to 100 images. 13.2.4 Manipulator Still Camera This is recommended as an addition for the A-6500 HOV. It is a 6500m high megapixel digital still camera with resolution and fidelity superior to that of the normal HD captured images. When required, the camera will be mounted on either of the manipulators and controlled by the pilot, utilizing a video feedback system for image framing. Still images will be captured on demand or in fixed interval mode, time stamped, and stored within the camera housing for post-dive downloading. The pixel resolution and digitalization depth of this camera precludes routine transmission of the images through the hull to internal storage systems. If this were done, the usefulness of the camera would be compromised due to the rate at which images could be captured. A better alternative is to provide external recording of the raw image data, thereby eliminating the delays associated with the format conversions necessary for through-hull transmission. The external pressure housing will contain a recording capability sufficient for 50 ultra-high resolution images.


This camera is to be designed to acquire still images superior in quality and at a higher spatial resolution than that possible with the HDTV cameras. These images are intended to support digital magnification feature extraction. In addition, they should support the ever-increasing resolution requirements of journal and magazine publication. 13.2.5 Manipulator HDTV Video Camera This is recommended for the A-6500 HOV, and is a highly specialized 6500m HDTV camera intended for mounting on either of the two manipulators. The camera’s image fidelity will be superior to the two permanently installed “primary” HD cameras due to the decreased camera to target distance. Details of the camera’s design will be the result of an ongoing hardware and software cooperative effort with Sony America, Inc. 13.2.6 Mosaic Cameras These are recommended for the A-6500 HOV. Down-looking HD cameras are to acquire mapping quality still and motion imagery for the creation of sea floor mosaics. One camera is to be a color while the second is a more sensitive black and white. The cameras will be a minimum of 1920 by 1080 pixels in resolution and mounted in a manner that will allow collection of stereoscopic image pairs. The overall design of this camera system is to be based on similar work done for the U.S. Navy and will not require significant design effort. 13.2.7 Situational Cameras These camera systems provide the pilot with a means for viewing areas surrounding the submersible that are not within the viewport fields of view. The existing Alvin aft-looking cameras will remain in use for the A-4500 HOV, but will be supplemented as necessitated by the vehicle’s design details. As an example, it may be beneficial to provide port and starboard cameras providing a better view of objects and samples contained in the sample basket. These cameras will most likely be standard definition, composite video cameras and, because of their importance to the pilot, their signals will be directly routed into the personnel sphere on copper wires rather than using the fiber optic telemetry system.


Figure 16. Video Camera Locations 13.3 Support Ship Image Data Processing and Distribution The support ship image management system supports offloading imagery data from the submersible, pre-processing, duplication, viewing/analysis, and distribution to the science party and archives.

13.3.1 Primary Data Duplication System The Primary Data Duplication System is designed to duplicate all still and motion image data obtained during a dive in preparation for distribution to the science party and archiving, per NDSF policy. The recording formats and distribution media have not been finalized, but it is anticipated that the primary data duplication system will require a number of recorder/playback machines identical or nearly identical to that used within the personnel sphere. Duplication will preserve audio tracks, time code, and any other available metadata. 13.3.2 Still Image Download System This system is used to download the still image data from storage facilities within the camera interface pressure housing. This is to be accomplished with an optical fiber interface connected to the pressure housing once the submersible is secure in the hanger. The still images will be transferred via the support ship’s network to a processing


computer and RAID storage facility where they will be made available as both raw image files and pre-processed .tiff image files. All images will retain their timestamps and camera identification codes. 13.3.3 Science Data Processing System The Science Data Processing System will ultimately provide the science party with the following capabilities during the cruise:

• Conversion of HDTV media to other supported HDTV distribution formats • Conversion of HDTV media to SDTV supported media • Processing and printing of still image data • Creation of still image mosaics • Non-Linear-HDTV-Video-Editing, NLE.

R/V Atlantis provides some of these capabilities at present. The installed hardware will be upgraded and supplemented in order to accommodate the HD format utilized by the submersible’s video systems and to provide the increased bandwidth necessary for managing the volume of digital image data to be generated. The editing system is to be an HDTV Apple Final Cut Non-Linear Editing System including a Macintosh CPU, RAID Storage system and HD compatible monitors.

14. Rescue Vehicle System The R/V Atlantis carries 10,000 meters of .68 fiber optic cable (46,000 lbs BS) coupled with a traction winch capable of 30,000 pounds tension. Although the A-4500 HOV and future A-6500 HOV designs include sufficient droppable weights to compensate for flooding of the largest floodable volume, there may still be situations where a rudimentary ROV utilizing this winch and cable might be of value. As a result, final design of a simple, “depressor weight” ROV system is in progress with system testing expected to occur in 2010. The concept diagram is shown in Figure 17 and a number of configuration options are shown in Figure 18. Simplicity and the resulting reliability are primary design goals. The vehicle will use 240V, 60 Hz supplied from the surface to drive a 15 HP hydraulic plant, primarily used by (2) five horsepower thrusters. These thrusters will allow heading control and are sufficient to pull the 2500 lb. rescue vehicle 200 m out from directly under the support ship when working at a depth of 2,500 m (350 m at 6500 m depth). When coupled with the R/V Atlantis’ dynamic positioning


system, this will enable the rescue system to maintain a position that allows its video camera to provide an overview of the submersible on the bottom. In Alvin’s forty years of operations, a rescue has never been required, but this bird’s eye view would have been comforting on at least two occasions. The lower end of the rescue vehicle will be designed for the addition of a variety of tool configurations. A hydraulic power take-off system, 110 vac and command and control interfaces will be provided. This will allow the addition of devices such as grabbers, line cutters and, ultimately, a small neutrally buoyant ROV. The A-4500 HOV will incorporate Alvin’s rescue buoy, a float attached to the submersible’s main lifting tee with 100 meters of 10,000 lb breaking strength Kevlar line and containing a navigation transponder or locating beacon. This float can be deployed by the pilot, and provides a means for the rescue system to find and attach itself to the submersible in preparation for attempting to pull the submersible free of the bottom.

Figure 17. Rescue Vehicle Basic Configuration Diagram


Figure 18. Rescue Vehicle System Design Concepts showing various configurations possible utilizing the lower tool attachment interface. The forward mounted video camera’s pan capability works in conjunction with the lights mounted on the tail boom to provide viewing angles between straight ahead and down-looking.

15. ABS Classification The Alvin submersible cannot meet the ABS classification requirements in its present configuration. This is because the vehicle was constructed under U.S. Navy certification rules, which differ from ABS classification standards in a number of areas. Additionally, the ABS classification process relies heavily on surveyor witnessed construction, which has not been part of the continuous Alvin development process. However, analysis of the ABS rules, along with on-going discussions with the ABS engineering group, have shown that ABS classification of a vehicle that uses an extensive amount of the existing submersible’s systems is clearly possible. The few cases that have been investigated in detail have been resolved favorably, and demonstrated the process by which ABS


classification can be obtained. At this point, all present design concepts incorporate consideration for the ABS classification requirements. The basic process for obtaining ABS classification is well documented and understood, and is described in the A-4500 HOV ABS Classification Plan. The details vary with the circumstances and prior ABS classification experience is invaluable. The present project team has limited ABS experience (although the Project Manager has some), and therefore we have obtained the assistance of an outside naval architectural firm. Glosten Associates has been selected based upon their experience level and proven record of success. Additionally, they have been involved in the analysis of the possible requirements for support ship modifications so they are familiar with the project. The following outlines the steps planned for obtaining ABS classification with details provided in the A-4500 HOV Classification Plan. The details of Glosten’s involvement have yet to be finalized.

1. Establish with ABS the project description, classification sought, type of review sought and schedule requirements.

2. Produce a list of submittal documents (calculations, plans, etc.) and submittal schedule and obtain ABS concurrence.

3. Conduct a "kick-off" meeting at ABS to introduce project team members and discuss the planned approach for handling areas known to require special effort.

4. Establish clear project goals for submittals and approvals as well as schedule imperatives.

5. Facilitate or obtain ABS approval of vendor supplied items and documentation.

6. Obtain approval for intended fabrication and testing processes (i.e. welders, pressure test facilities).

7. Obtain approval for final system integration and test procedures (i.e. weight releases, inclining experiment, sea trials, witnessed dive, etc.).

8. Establish a submittal tracking system that records:

• Date of submittal to ABS • Date of receiving ABS review comments • History of follow-on information exchanges including list of ABS

comments for each submittal • Date of final ABS approval.


Appendix I. Energy Analysis of HOV Operations All of the available dive energy for normal HOV operations must be carried in the main battery system. A variety of battery systems are being investigated, which differ widely in chemistry, size, weight, energy capacity and cost. There is also the expectation that the energy requirement of the vehicle will be different from the present Alvin. This study examines the differences in the A-4500 HOV’s working time as a function of the battery capacity and energy consumption. Given the expectation that the A-4500 HOV will continue to use the present lead-acid battery system, the effect on the vehicle’s operating capability is also presented. Currently, this battery system contains 40kWhr of energy, and provides dives of about 8.5 hours in duration, with about 5.5 hours working time. For the purposes of this study, the energy requirements for emergency procedure and the energy capacity of emergency batteries are not included. The present Alvin’s principal energy loads fall into the approximate ranges shown in Table 1.

Load Type Approximate Power

Hotel 800-1000W Lighting 1-2kW Manipulation 1-4kW Propulsion (Transiting) 2-5kW

Propulsion (Maneuvering) 1-7kW

Table 1. Distribution of Alvin’s Principal Energy Loads

The hotel loads are those that are used when the submarine is operating: power control, computers, sensors, communication, and life support. These loads are normally active for the entire dive duration (pre-dive through post-dive) though some are not required during descent or ascent (this applies to many of the sensors). The Alvin operators commonly see 1kW of power while at idle on the bottom. About 200W are utilized by sensors that are not required during descent or ascent. The other loads are only used while working on the bottom or working in the water column. The magnitude of these is estimated based on the particulars of the equipment and operational experience:


Lighting: Alvin is presently fitted with three each 400W lamps (forward), eight each 200W lamps (four on each side) and three each 100W lamps (basket, landing and aft). 2kW represents the load of the forward lamps (for pilot use and imagery) and half of the side lamps (for science use) illuminated. Manipulation: This requires hydraulics, driven by a 5 HP motor, or up to about 4kW. The energy requirement depends greatly on the speed and loading of the manipulative work. Propulsion (Transiting): Alvin pilot experience shows that 2 kW of power devoted to forward thrust (three thrusters consuming a total of 15A from the batteries) moves the submarine at about 1300 m/hour, or 2-3 knots. Recent measurements show that 5 kW results in about 1.4 knots. Propulsion (Maneuvering): Finely controlling the position of Alvin often requires short bursts of high thrust. For motion along the vehicle’s axis, three thrusters are available at over 3HP each, or 7 kW. Other axes have two (vertical, 5 kW) or one (heading, 2 kW). Maneuvering could require any amount of power up to these amounts, or more if thrust in multiple axes is required.

As can be seen, the hotel loads consume much less energy than the other loads, although they tend to be more constant and are active for longer duration. Historically, we know that most of the dive energy is consumed while working; little is consumed during pre-dive, launch and descent, ascent and recovery. Hypothetically, using the hotel load for the entire duration of a dive (8.5 hours) expends 8.5 kWhr of energy. If 2 kW of lighting is used only while working (5.5 hours), another 11 kWhr is consumed. Including a 2 km transit (2/3 kt for 1.5 hours) consumes an additionl 3 kWhr, for a total of 22.5 kWhr. This leaves 17.5 kWhr of energy available for the remaining four hours of working time, allowing an energy consumption rate of over 4 kWhr per working hour. This could be consumed, for example, with four hours of maneuvering and manipulation.


As a result, battery systems with more total capacity will map almost directly into more working time. Figure 1 is a plot1 of Battery Recharge vs. Dive Duration. This shows Alvin battery recharge data from July 5, 2008 through June 18, 2009, covering over 100 dives and a wide variety of science disciplines, locations and depths2. While this is battery recharge data, not energy consumption data, the recharge amount (in Amp-hours returned to the battery) is directly representative of each dive’s energy consumption (in Watt-hours consumed).

Figure 1. Battery Recharge Data for Alvin Dives between July 2008 and June 2009 Figure 1 shows that there are two primary modes of energy consumption. The first, highlighted in the red box, shows many dives falling near a line which intersects the axis at about three hours of dive duration. These are dives terminated due to completion of the work or depletion of the battery’s energy. Note that the first three hours of the dive’s

1 Gomez-Ibanez, D., “Alvin Upgrade Batteries – Alvin 2008-2009 Recharge Logs,” July 17, 2009.

2 These 111 dives included operations in the fields of Biology, Chemistry, Geochemistry, Geology, Physics, Microbiology, ODP Wellhead Download and Physics, in the Cascadia Basin, Coaxial, Costa Rica Trough, EPR 9N, Guaymas Basin, Hoke Seamount, Juan de Fuca and Pacific Northwest, and to depths between 400m and 4400m. Of these, about 1/3 terminated on completion of work, 1/3 on time, 1/3 on power. Only three of the 111 terminated due to weather and three due to submarine problems.


duration represent the average total descent and ascent time, and consume no significant energy. The points within the red box show that for a wide variety of dives, energy consumption is generally a direct function of working time. The second mode, highlighted in the green box, shows many dives of slightly less than nine hours duration with widely varying energy consumption. These are dives ended upon expiration of available time, where operational concerns demanded return to the surface. It is worth noting that the points within the green box represent dives that did not deplete the available energy and could have been longer. For the A-4500 HOV project, a number of possible battery configurations shown in Table 2 have been considered (see Appendix II):

Option Total Energy

System Weight

Cost per Dive

Present Lead-Acid Batteries (2 tanks) 40 kWhr 8000 lb $20

Expanded Lead-Acid Batteries (3 tanks) 60 kWhr 12000 lb $30

Lithium Iron Phosphate Pouch 72 kWhr 6200 lb $300

Lithium Cobalt Pouch

80 kWhr 4600 lb $800

Lithium Cobalt Cylindrical 80 kWhr 6100 lb $300

Table 2. Battery Configurations for the A-4500 HOV

Though widely different in chemistry, capacity, size, weight and cost, the useable working time they would provide to the HOV can be estimated. To do this, two reasonable assumptions have been made:

1. Launch, descent, ascent and recovery will continue to consume a small amount of battery energy, as compared to the other loads.

2. Descent and ascent times will be similar to the present vehicle. Given these, available working time for the various battery options are compared in Figure 2.


Figure 2. Comparison of Expected Dive Time of Different Battery Types

It is recognized that changes to the vehicle will have corresponding changes to the system’s energy needs. In particular, proposed changes to the vehicle’s power control, command/control, propulsion, lighting and imaging systems will impact the total energy consumption compared to the present vehicle, as will the A-4500 HOV’s size, weight, shape, and operating parameters. The effect of these changes has been estimated based upon a design that continues to use the existing lead-acid batteries.

1. The hotel load is estimated to increase by no more than 25%. 2. The available illumination is estimated to increase. However, the lights under

consideration are more efficient and therefore will have similar total energy requirements overall. Present plans based on vendor supplied data call for doubling the existing illumination while remaining within the present energy consumption rate.

3. The propulsion plant will be unchanged, and the submarine’s frontal area will be approximately the same as the existing vehicle. Therefore the energy required for constant speed transits is estimated to be unchanged.

4. The submarine’s mass is expected to increase by a maximum of 25%, which will in turn require 25% more energy while maneuvering (which requires frequent accelerations).

5. Adding dynamic propulsion control is expected to require significantly more propulsion energy than at present. However, use of this capability is optional and therefore no additional energy will be required unless the total impact of its use on the dive is judged to be beneficial.


6. The hydraulic and VB systems are unchanged and therefore their energy requirements will be unchanged.

Estimating the impact of these changes on the vehicle’s available working time is complicated by the unique nature of every dive, and the variety and combination of tasks. It is helpful to note that only the hotel and maneuvering loads (with dynamic positioning disabled) represent energy consumption changes from the present vehicle. It is also helpful to identify some example dives3 and change in total energy requirements for each:

1. A survey dive consisting of mostly sonar or photomosaic transects, requiring mostly propulsion and some lighting but very little maneuvering or hydraulics.

2. A sampling dive for which once set up, there is very little driving or propulsion, some maneuvering and quite a bit of hydraulics and lighting.

3. A combination dive combining even portions of survey, transit, site video documentation and sampling.

For each of these dives, the hotel load is required for the entire 8.5 hour dive duration, therefore requiring up to (1000 watt * 25%) * 8.5 hour = 2100 watt-hr of additional energy. The maneuvering needs of each for these dives could vary from a very small amount to up to 10% of the working time. This will require from no extra energy (example dive #1) to a maximum of (7000 watt * 25%) * 5.5 hours * 10% = 960 watt-hr of additional energy (example dives #2 and #3). The total maximum energy impact of the A-4500 HOV (using the existing lead-acid batteries) is therefore between 2.1 kWhr and 3.3 kWhr of additional energy. For the present 40 kWhr battery system, this additional energy requirement represents between 5.3% and 7.7% of the total energy available, or between 18 and 25 minutes of the present 5.5 hours of working time. Knowing this, management of the energy capacity will continue to be a priority for the pilot and scientific program personnel. Figure 3 shows the potential effect on total dive time for the various battery types. This graph duplicates the dive duration line from Figure 1 (in red), where the Recharge Amount has been mapped into total useable battery capacity4. The proposed battery capacities are plotted against it to show the potential increase in dive time for higher capacity batteries (blue squares), based upon those dives within the last 100 for which energy was a limiting factor. A second line is plotted (in green) to show the maximum 3 German, C., “Scientific Endurance Wishes for the RHOV,” August 27, 2009.

4 The amount of energy returned to the battery is the product of the Recharge Amount and the charge voltage. Lead-acid batteries are about 85% efficient in returning energy during discharge: Battery Capacity (in watt-hr) = Recharge Amount (in amp-hr/battery) * 2 batteries * 142 volts * 85%


expected effect of the energy consumption rate analysis outlined above (up to 25 minutes from a 5.5 hour working time). This is thought to be valid for a vehicle incorporating the modifications necessary for continued use of the existing lead-acid batteries. However, the percentage of dive duration decrease due to the A-4500 HOV design changes would be greater for an expanded lead-acid battery installation (which is not possible due to volume and weight constraints) and less for the lithium based batteries. This is because the expanded lead-acid configuration is both larger and heavier, and would likely incur additional energy requirement increases to transiting as well as maneuvering.

Figure 3. Potential Dive Times for Different Battery Types


Appendix II: Assessment of Battery Options Abstract This Appendix reviews and assesses alternative battery types considered for use in the new A-6500 HOV. The unique features of each battery type are discussed and the batteries are grouped into preferred, less preferred, and not preferred categories. Finally, we briefly outline a development and evaluation effort intended to enable the ultimate use of Lithium-Ion batteries in the A-6500 HOV. 1.0 Background An enlarged and improved personnel sphere will be incorporated into the new A-6500 HOV. The new sphere weighs 11,158 pounds, compared to 7,231 pounds for the existing Alvin sphere. In order to use the existing Atlantis A-frame without modifications for launch and recovery, and to float the less buoyant sphere without the weight of an increased amount of syntactic flotation material, it is desirable to lighten the total battery weight relative to the existing Alvin batteries. Ideally, the batteries should be lightened from an air weight of 5,000 pounds down to approximately 2,500 pounds. To increase maneuverability and bottom time, we would also like to increase the total energy and power available. The initial goal in 2007 was to double the useable energy from the 40kWh available on Alvin to 80kWh, and increase the maximum power from 12kW to 40kW. Based on battery availability and current state of the technology, the total battery energy goals have a threshold of 40kWh and an objective of 80kWh. It is not trivial to improve upon Alvin’s lead acid battery system. Refined over the course of six major updates since 1964, the present lead acid system has excellent reliability and safety, and adequate energy. The present battery has very low replacement cost, although battery maintenance is still a significant part of operating expenses. There are many interesting battery types available today, the most relevant of which are summarized in Table 1. The most important characteristics are energy density at 6500 meters, safety, reliability and cost. Some battery types are not yet mature and require extensive development. Others are obsolete and no longer supported. Ultimately, however, the most promising battery types are all Lithium-ion batteries. The next section presents some of the challenges of this chemistry, and later sections will briefly discuss the development effort required to use them safely.


Among lithium ion batteries, there are three main cathode materials used (cobalt, iron phosphate, and manganese), two different anode materials (graphite and lithium titanate), giving six possible pairings, and countless variations on these basic recipes. In very general terms, a distinction can be made between batteries that maximize energy density (using cobalt in the cathode), and batteries that compromise energy density in return for greater safety and longer life, and do not contain cobalt. Laptop computer and cell phone cells are the former (high energy cobalt) type. Large batteries designed for vehicles are usually the latter type. Most lithium ion cells are not designed for use underwater. Cylindrical cells contain some amount of air, along with the electrodes, inside a rigid metal can. When the air is compressed by external pressure, the can collapses, destroying the cell. Cylindrical cells may be placed in a pressure housing, but this introduces heat induced safety risks in addition to the weight and cost of the housing. If the pressure housing implodes at depth, the energy released is similar to an explosion, and this event would be unsafe for the humans nearby in the personnel sphere. For this reason, Alvin pilots currently maintain a safe “standoff distance” to pressure housings such as glass spheres which may implode unpredictably. Because of the high current routinely discharged by the battery, it is difficult to eliminate all sources of heat which might weaken the pressure housing. The high current by itself may heat up the pressure housing, regardless of battery chemistry. Therefore, any design of any battery using a pressure housing must be considered carefully. The alternative to a pressure housing is to use pressure tolerant cells. Some lithium cells are designed specifically for underwater use, with a collapsible bellows welded to a metal can. Another type is the flexible pouch cell, which does not need a bellows, but may still be damaged if the pouch contains too much unfilled air volume. Most pressure tolerant cells are simply commodity pouch cells that have been selected, qualified and tested to ensure they contain a minimal amount of gas and will work effectively for a specific underwater application.


Table 1. Comparison of battery types considered for use in 6500 meter HOV. All lithium ion batteries are grouped into pressure tolerant and one atmosphere types for clarity. Fire indicates no history of fire. Implosion indicates a completely filled, implosion-proof battery. Power and Energy indicates 50% increase over the present Alvin system is possible. Cost per dive assumes replacement of 80 kWh cells after 5 years and 1,000 dives.

2.0 Preferred Alternatives This short list of four battery types includes those with the shortest additional development time required. In the following lists, “large” cell means >100 Ah, “small” means <10 Ah. Lead acid, pressure tolerant Replacements are inexpensive, but it will be difficult to fit more energy than is presently available, and will be impractical to increase bus voltage from 120 to 240 volts. Although the energy and weight of this arrangement cannot meet the design objective of 80kWh, they do allowing attaining the design threshold of 40kWh. Much of the engineering is done, the performance is proven, and the maintenance requirements are well known.

Battery Type Fire Safety

Implosion Immunity

Power Energy Replacement Cost per Dive

Preferred

Lead Acid, Pressure Tolerant

Yes Yes

Yes no $20 Yes

Lithium Ion, Pressure Tolerant

No Yes Yes Yes $600 Yes

Lithium Ion, One Atmosphere

No No Yes Yes $270

Nickel Metal Hydride, One Atmosphere

No No Yes Yes $160

Silver Zinc, Pressure Tolerant

Yes Yes Yes Yes >$10,000

Nickel Cadmium, Pressure Tolerant

Yes Yes Yes no not available

Sodium Nickel Chloride, One Atmosphere

Yes No Yes Yes $320

Alkaline Primary, One Atmosphere

Yes No Yes Yes $8,000

Aluminum HP Fuel Cell, Pressure Tolerant

Yes Yes No Yes unknown

Hydrogen Oxygen FC One Atmosphere

No No No Yes unknown


Small cobalt pouch cells, pressure tolerant Used by Autosub 6000 and Bluefin AUVs. Lack of cycle testing at higher pressure and discharge rate required by 6500 m HOV. Need to qualify and package existing implementation for operating conditions. Safety criteria for fire aboard support ship needs to be established and rigorously satisfied for this volatile chemistry. Active development. Large iron phosphate pouch cells, pressure tolerant Has the potential to be safe and inexpensive, but pressure tolerance at 6500 meters is untested and fire safety needs to be verified. Large manganese pouch cells also fall in this category of lower-energy lithium cells. Active development.

3.0 Less Preferred Alternatives These alternatives may be technically and economically feasible but would require more development effort than the preferred alternatives. Small cobalt cylindrical, one atmosphere, liquid filled Nonconductive liquid in titanium pressure housing reduces implosion energy and helps transfer heat. Cylindrical cell replacement packs are the most inexpensive type. Heavier than pressure tolerant cobalt cells due to pressure housing and fill fluid. Implosion must be mitigated and tested. Large lithium cell, pressure tolerant prismatic with bellows Currently used on Shinkai 6500, although the existing Yuasa design is deprecated. It would be expensive to develop a unique bellows case. More expensive to replace: $1,881 per dive. Fire safety criteria must be established and verified. Not preferred because of low technology maturity and high cost. Nickel metal hydride, one atmosphere This approach has proven to be reliable in AUVs. A pressure housing is required. Cells can vent hydrogen during charge, creating an explosive mixture in the pressure housing. This can be handled by venting the housing, but requires opening the battery housing with each dive. Energy density is between lead and lithium types. The technology is mature and replacements are inexpensive. Not preferred due to explosion and implosion risks


Small iron phosphate cylindrical, one atmosphere Mass produced iron phosphate cells are less volatile than cobalt cells. Although of lower energy capacity, they are comparable to nickel metal hydride. A pressure housing would still be required with its associated risk of implosion. Though hydrogen off-gassing is not expected, the cells themselves are flammable. Fire safety criteria must be established and verified. Manganese lithium cylindrical cells also fall into this category. Not preferred due to fire safety, lower energy, and implosion risk. Sodium nickel chloride, one atmosphere Used in fleet road vehicles and the NATO submarine rescue system. Large 24 inch diameter pressure housing required. Energy density approximately 150% of lead acid. Implosion risk is acute due to 350°C battery operating temperature, which could weaken the housing if vacuum flask insulation is not maintained. Vacuum flask insulation is inherently an implosion hazard and should be avoided. Not preferred due to low energy and implosion risk. 4.0 Not Preferred Alternatives These battery types are highly unfavorable and would be very difficult and expensive to implement. Although they may offer no more energy than the existing lead acid batteries, they have significant disadvantages. Silver-Zinc, pressure tolerant Used previously on Shinkai 6500, and Navy DSRV’s and the Advanced Seal Delivery System (ASDS). The US Navy replaced the ASDS silver zinc battery based on high cost and lack of reliability. Silver Zinc has potential for energy density equal to lithium ion, but requires more maintenance than present lead acid batteries, and more frequent replacement (25 cycle life). Resulting cost per dive would be >$10K/dive. Nickel cadmium, pressure tolerant This has approximately the same energy density as lead acid. More cells required; higher voltage difficult. The required boutique cells are not available. Cadmium is poisonous and use is restricted. Not preferred. Alkaline primary cells, one atmosphere Unaffordable at $8,000 per dive for 80kWh. Storage, handling and disposal are incompatible with current tempo of operations. Pressure housing i s required.


Aluminum hydrogen peroxide semi fuel cell, pressure tolerant This cell type has energy density comparable to lithium ion, but adequate pulse power (>0.25C) requires a larger and less efficient system, or large batteries. Self-heating and slow demand response are problems with the highly dynamic load of an HOV. Storage and handling of potassium hydroxide and hydrogen peroxide fuels is hazardous. Large batteries would still be required for pulse power. Not preferred due to low power density. Hydrogen oxygen fuel cell Large volume required for storing compressed gases. Power density is low. Hydrogen is flammable and explosive. Hydrogen embrittlement issues in the storage vessel would have to be resolved. Not preferred due to low power density and implosion hazard.

5.0 Lithium Ion Battery Development Roadmap In this section we lay out the steps required to develop a lithium ion battery suitable for use in the A-6500 HOV. Pressure Housing

An important fork in the roadmap is the decision to use a pressure housing or not. If a pressure housing is used, implosion of that housing must be modeled and tested to ensure survival of the submarine and science party. We are still investigating the feasibility of this option. Except for the implosion hazard, the pressure housing battery is programmatically safe. The technology is mature; the pressure housing arrangement has proven to be reliable in many AUVs’ battery installations. The most desirable development path is to avoid a pressure housing and use a pressure tolerant battery. However, no available pressure tolerant cell has yet been tested in a regime representative of use in the A-6500 HOV. There is a small chance that none of the half-dozen vendors of pressure tolerant batteries will survive cycle testing at 6500 m. In that case, a one atmosphere pressure housing may become more attractive even with the engineering required to mitigate the risk of implosion. At this time a pressure housing is less favorable, and the following discussion assumes that a pressure tolerant battery will be used, avoiding the use of a pressure housing. Test Sequence

In order to safely use a large lithium ion battery in the A-6500 HOV, t h e d e s i g n m u s t b e carefully tested. Two related but distinct concerns are pressure tolerance and fire safety.


A pressure tolerant cell must be effectively evacuated of air so that it does not experience a large volume change under pressure. All materials must have enough compliance to withstand pressure cycling without fatigue or leakage. Pressure tolerance must be verified at the cell level in a pressure cycle test on individual cells. Because a large amount of energy is stored in a fundamentally unstable chemical system, the risk of fire propagation must be handled carefully both while the vehicle is submerged and while on board the support vessel. This is done by careful design using best practices and experience from destructive tests on similar large batteries. A large battery is partitioned into small modules such that the worst case energy released from any single section is handled gracefully without further harm to humans or to the vehicle or support ship. Further, the integrity of the partitioning scheme during a worst case event must be modeled and tested so the fire doesn’t spread throughout or beyond the battery. Fire safety can only be tested with a battery packaged appropriately for use in the A-6500 HOV, since the pressure compensation fluid, the orientation and spacing of the cells, and the housing materials will all affect the propagation of fire in the battery. Since fire propagation testing requires a mature package design, while pressure testing can be done on bare cells, it makes sense to do pressure testing first and use it to screen out cells unsuited for pressure tolerant use. Then, with pressure tolerant cells in hand, packaging can be designed and fire propagation tests conducted. Pressure Cycle Test

Large changes in ambient pressure will mechanically stress any cell. If the cell pouch or metal container springs a tiny leak, gas may be generated in a chemical reaction, eventually destroying the cell. To prove that a cell can withstand repeated pressure cycles, it must be tested in a pattern consistent with its intended application. A quantity of candidate cells will be fully charged, subjected to high pressure, and discharged at pressure. This cycle will be repeated sufficiently to simulate a substantial fraction of the batteries’ expected lifetime. At 12 hours per cycle, 200 cycles can be completed in approximately three months of continuous cycling. These cycles represent 20% of the intended life of the cell, and are expected to reveal gross design flaws. This qualification will require a dedicated pressure test chamber fitted with automated controls for unattended operation. Several candidate cells can be cycled at the same time.


Preliminary Housing Design and ABS Approval

If there are any pressure tolerant cells that survive the cycle test, the best candidate can be designed into a pressure compensated housing suitable for use with the A-6500 HOV. Besides sheltering the batteries from contact with seawater, the housing for lithium ion batteries must stop the propagation of fire. Additionally, it must incorporate several other system components such as cables and connectors, switching, fusing, monitoring and communications hardware. Fire Propagation Test

This test will intentionally create conditions for worst case fire propagation, heating the entire battery assembly to its maximum design temperature, introducing external ignition sources to help sustain a fire, and then attempting to start a thermal runaway event by locally heating part of the battery using an external power source. The resulting fire propagation will be monitored for compliance with established criteria. Unfortunately there are no established criteria for the safety of large pressure tolerant lithium-ion batteries. The criteria most applicable to our operating conditions are the guidelines published by the Naval Sea Systems Command, “S9310-AQ-SAF-010 Technical Manual for Batteries”. Their criteria for fire propagation are these four, which are used to evaluate a worst case thermal runaway event:

• Venting of gas/liquid/solid material is permitted.

• Venting of flames is prohibited.

• Rupture of the outer enclosure is prohibited.

• The peak internal pressure must remain below 50% of yield.

Other similar guidelines and criteria have been established by Telcordia for telephone central office installations, “New Equipment Building Systems Requirements GR-63” and by the Department of Energy in the United States Advanced Battery Consortium’s “Electrochemical Storage System Abuse Test Procedure Manual” for testing automotive batteries. We will leverage these existing guidelines and manuals, assembling the tests and criteria most appropriate for the unique operating regime of the A-6500 HOV.


6.0 Conclusion The most promising battery types have been identified to be pressure tolerant lithium-ion batteries which can achieve the design objective of 80kWh. We prefer the pouch cell construction over the metal can with bellows because it is readily available from several vendors, inherently pressure tolerant, and inexpensive. We prefer the iron phosphate cathode chemistry over a cobalt cathode due to its greater chemical stability and reduced fire propagation properties. However, much work remains to package existing cells for use in the A-6500 HOV. Several stages of qualification, design and testing will ensure that the resulting battery will result in safe, reliable operations. Given the above development and qualification requirements for lithium ion batteries, and the timeframe in which a battery is needed for this project, the lead acid battery is the preferred battery for the A-4500 HOV.


Appendix III. A-4500 HOV Electrical System Design Overview

The RHOV electrical system supports these principal goals: - Incorporation of fiber optics for high bandwidth data - Incorporation of high definition video - Improved command & control equipment - Enhanced vehicle control and monitoring - Additional power and data channels over the present vehicle

While supporting these goals, the design incorporates these objectives: - A highly symmetrical design provides common operation across many parts of the

vehicle. This also enhances reliability and safety by distributing functions across different failure groups, to minimize the consequence of single-point failures.

- Reliability is also enhanced by use of redundant power and data paths. - Maintainability is enhanced through the use of common or OEM equipment

throughout the vehicle. Heavy reliance is also given to equipment and techniques already fielded on other systems and vehicles. This provides the operators with familiarity of the equipment and ready sparing and repair.

- Incorporate new penetrator payload.

An overall architecture of the vehicle electrical plant is provided in the Figure.

Architectural Description

High-voltage power for the A-4500 HOV’s normal operation is provided from a single 120Vdc bus, powered by two identical main battery packs. From the batteries, power is first routed through a pair of power bottles, where contactors are provided to the vehicle’s principal loads: propulsion, lighting, data bottles and science, and low-voltage power to the personnel sphere. High-voltage power can also be shifted from one power bottle to the other, as a protection against a main battery failure. Control and monitoring of these bottles is through Ethernet, over optical fiber, from the sphere. An additional Ethernet link is provided between the two bottles as a protection against a communications failure. Most of the vehicle’s instrumentation are operated through a pair of data bottles. These contain an individual low-voltage power and data channel for each instrument circuit. Control and monitoring of these bottles is through Ethernet, over optical fiber, from the sphere. Data communications for the instrumentation is also provided over the same


Ethernet. An additional Ethernet link is provided between the two bottles as a protection against a communications failure. Power to the sphere is provided from both power bottles. These are combined, together with an emergency power source, to provide power to the interior equipment. It is here that the pilot controls and GUI, computers, communications and life support equipment are operated. Additional low-voltage power and data channels are provided for each in-sphere instrument circuit, where the equipment to do this is the same as used in the data bottles. Science equipment is operated through a pair of science bottles. These contain an individual low-voltage power and data channel for each science instrument circuit, where the equipment to do this is the same as used in the data bottles. Control and monitoring of these bottles is through Ethernet, over optical fiber, from the sphere. Data communications for the science instrumentation is also provided over the same Ethernet. An additional fiber optic line is available for science use. Note that the use of the term “bottles” here does not necessarily mean distinct physical pressure cases, but rather distinct logical and functional entities. Depending on the details of the vehicle’s design, these bottles may be divided into multiple pressure cases, or combined into fewer. Critical power channels are under direct control of the pilot with electro-mechanical controls and dedicated copper wiring. The rest of the power switching, both high-voltage and low-voltage, is performed with remote switching equipment under software control, as driven through the pilot’s GUI. Through this remote switching equipment, power to each instrument can be individually controlled and monitored for voltage, current and grounds. Critical data channels also use dedicated copper wiring. The rest make use of Ethernet-based data concentrators. The main batteries are described in detail elsewhere. They provide their own charging connection, and incorporate an internal primary electrical disconnect, to act as a fire stop in the case of a fault within the battery. Control and monitoring of each battery is through a data channel routed through the power bottle. The imaging equipment is described in Section 13 of this document. For the purposes of the electrical plant, it is provided with power and fiber optic connections, and operates as another set of in-sphere and outside equipment. The same set of monitors is used for both the Imaging system (i.e. video display) and the command/control system (i.e. GUI display).


Appendix IV. Submarine Command and Control System

Design Document: Functional Description, Architecture, and Design

1. Introduction This document is a high-level functional specification and architectural design document for the A-4500 HOV Command and Control system. It is organized as follows: Section 1: Introduction: You are reading it! Section 2: Command and Control System Description, reviews some basic architectural

and functional attributes we desire of the new system. Section 3: Command and Control System Software and Hardware Principles, lists more

detailed functional and design characteristics of the system. Section 4: Implementation Details, describes the pieces of the system that we must

actually build using the attributes and characteristics previously described.

2. Command and Control System Description

2.1. Basic Definition and Functions Definition: The Command and Control System is that part of the submarine that allows the pilot (and potentially the observers) to interact with and control the components of the submarine that are remote from physical human touch or sensing, or whose complexity requires integration of multiple inputs and outputs. Other tasks of the Command and Control System are to automate repetitive tasks and to provide assistance to the pilots and observers in safely accomplishing their tasks.

2.2. Basic Principles Architecture: High-level vehicle control resides in the submarine, not in external housings. The vehicle will be populated entirely with multiplexed serial (RS232, RS422, and RS-485) and Ethernet devices. The telemetry system provides passage for all these signal channels. Exclusive of the embedded micros integral to most of the sub-sea serial devices, all computers will reside in the sphere. This does not imply that off-board computers cannot communicate with on-board computers during dive preparations and checkout. Redundancy: The current submarine uses a “port/starboard” division of power and power control, such that either “side” of the submarine can supply the entire submarine


with power. This redundancy shall be maintained throughout the design and build process; variations will be flagged as they occur. Modularity: The Command and Control System uses a two-part system design, partitioning safety-critical from non safety-critical subsystems for cost-effective modular implementation and enhancement. It is comprised of a “core” system of safety-critical subsystems that are essential for safety and control of the submarine, and an “extended” system providing non safety-critical sub systems such as data logging and video recording. This approach has been employed successfully on the current submarine, as well as on the original Jason and Argo II control systems.

The additional constraint we place upon the submarine command and control system is that we shall always be able to return the submarine and its occupants safely to the surface without requiring the use of the computers and software contained in the command and control system. COTS: All submarine computers shall be COTS, and shall be as generic as possible, not requiring purchase from particular vendors or manufacturers. Documentation: The vehicle must be supported by adequate documentation. This documentation must include instruction both on setup and operation of the system. Pre-Existing Conditions: Because we are building upon a long and successful history of safe and effective submarine operation, there are certain key components and operating principles of the existing submarine that are being preserved in the new system. Furthermore, because of the nature of the design and contracting process that has been followed to date, an exhaustive, top-down review of requirements is not necessary at this point of the process. Ample justification for the list of pre-existing conditions in Section 3 can be found in the archive of previously written and reviewed design documentation. In particular, a set of specifications for power control and monitoring devices has been co-developed by the Electrical and Command and Control leads. The specification of this device is attached as Appendix A. The devices are called “Lanecons”, a name ultimately derived from the MBARI D-Con and the WHOI Wecon devices. The upgrade of the submarine is planned to proceed in two phases. Stage 1 will involve replacement of the sphere, and modification of other systems only as necessary. Stage 2 will fully move the submarine into a 6500m capability, and will involve replacement of many other subsystems, including the motor controllers and the thruster motors. Because of the changes that Stage 1 forces on the power switching and analog control fabric, and


because of the obsolescence of the current command and control plant of the submarine, most Command and Control tasks are necessary components of Stage 1. Software Re-Use: Development should be performed with full awareness of the existing software base in the National Deep Submergence Facility and the Deep Submergence Laboratory. This should not just be a retrospective process—we should certainly use existing code if feasible, but when new code is necessary, it will benefit the Facility (and aid in the testing process) if the use of that code can be extended to other components of the facility. Client Server Approach: The ROV control system is based entirely upon a client/server relationship between the main vehicle control software and a set of client Graphical User Interfaces. This approach has been successful, and is in fact close to essential when using the software for AUV control. A similar approach is being followed in the Navigation portions of the software currently under development for Nereus/Sentry. We will adopt this approach. The servers will generically be considered the “core system”.

2.3. Functions of the Command and Control System The following are the basic functions of the Command and Control System.

1. Manage switching/power/batteries. Allow control and monitoring of external switching devices by the pilot. Allow control and monitoring of the batteries to ensure their effective use and safety. Log all data necessary to allow troubleshooting and development efforts. Allow per-dive run-time specification of system configuration. Support battery charging and maintenance on the surface.

2. Control hydraulic systems. Allow the pilot to control and monitor pressure and/or flow of whatever hydraulic devices are provided in the submarine. Allow per-dive run-time specification of system configuration. Log all data to allow troubleshooting and development efforts

3. Manage fault detection and alarms. Provide the pilot with immediate feedback of any and all alarms. Allow clearing/overriding of the alarms as appropriate. Log all alarms and status. Provide environmental monitoring to ensure safe operation of the submarine.

4. Control thrusters/motor controllers/actuators. This control must be both “thrust mode”—pilot inputs are passed directly to the motor controllers--, and “PID mode”, where automated control systems separately control the XY, heading, and vertical thrust axes, based upon feedback from vehicle sensors and pilot input. Support both station-keeping and per-axis waypoint control.

5. Provide integrated navigation. Use all available navigation sensors, including, but not limited to ALBL, DVL, AHRS, depth and altitude sensors to provide


submarine position and velocity information to the pilot and other systems. Allow the surface controller to track the submarine as well.

6. Provide control and indicators to pilot and observers. Provide input devices such as touch screens and joysticks to the pilot. Make data visible and available to the pilot and observers. Distribute data on the submarine network as necessary

7. Log standard sensor and vehicle data and provide capability for data offload. Log science data and observer records. Support existing data systems as appropriate.

8. Provide network capabilities inside the submarine, including time service and (potentially) DHCP addressing for science-supplied computing systems. Isolate the critical vehicle operation network from the non-critical network that is available for other uses.

3. Command and Control System Software and Hardware Principles

3.1. Operating System and Development Environment The core system should maintain POSIX compliance as much as possible, including in particular the following modules:

• POSIX 1003.1a (formerly POSIX.1) – standard Unix library e.g. stdio.

• POSIX 1003.1b (formerly POSIX.4) – real-time clocks, timers, signals.

• POSIX 1003.1c (formerly POSIX.4a) – posix threads.

The system should be capable of supporting soft real-time processing of control loops of at least 10Hz. It is not critical that the control loops run at precisely 10Hz. It is absolutely critical, however, that the system has a clock of at least millisecond resolution that can be interrogated in the control loop. It is critical that the O/S does not allow dropouts greater than about 200 ms, and that any jitter is accurately reflected in the system real-time clock readings. Linux will form the basis for the Command and Control Subsystem. We will build the real time controller system under Linux as follows: • Use Linux native Posix 1 Unix library and p-threads.

• Timers – Use the timing system developed for Jason in the submarine implementation

• Use Linux native GCC compiler.


The current version of the ROV control code runs under many versions of Linux, but the version controlled system currently uses Ubuntu 8.04 LTS (long term support). Unless convincing reasons become apparent, the submarine command and control system will also use this OS version. We will avoid the use of any vendor specific or licensed code, and use open-source code as much as possible. Graphical User Interfaces will be developed using QT, a product of Nokia. There is an open source version of QT available for all platforms—while development may occur using licensed versions of the code, we should strive to always be able to develop using open-source tools. At the time software development begins, we will select a baseline version of QT for all development.

3.2. Code and Configuration Management The core system will use a single compiled version of code that runs on Jason 2, Johns Hopkins University ROV, Nereus, Sentry, and the A-4500 HOV. No special versions or compile-time #ifdefs’s should be necessary to move code between vehicles. A globally accessible vehicle name flag will indicate which vehicle is presently in operation. Use of a single compiled version of the code will facilitate propagating bug fixes and enhancements across the family of vehicles and keep us from having to maintain separate control system codes. The Navigation Engine server will follow similar principles. The extended system (GUI, etc) may differ between vehicles, as it does in the present system. The core system is written in C and C++. Configuration Management will be handled using Subversion. The current repository is maintained at Johns Hopkins University: this will continue unless reasons exist for changing the approach.

3.3. Vehicle-Dependent Core Configuration Parameters The system will employ a single ASCII text configuration file to be read by system on startup. Errors in the configuration file will only stop the topside system from running if they are truly critical; otherwise, errors will be flagged and operators will be alerted, but the system will run as well as it can. Every attempt will be made to eliminate unnecessary, redundant or conflicting types of information in the configuration file. The vehicle configuration resembles a Windows .ini file: • The file is divided into sections, with the beginning of each new section indicated by

a word enclosed in square brackets. Examples appear in subsequent sections of this specification. No trailing delimiter is used; a section ends at the beginning of the section that follows it. No section will be duplicated with a configuration file.


• Within a section, values are distinguished by attribute words, which are followed by an equal sign, separating a following value from the attribute. Code has been written to support the reading of single Boolean, integer, and floating-point values, and of arrays of these values. Default values to be used in the event that the configuration value is not read correctly are hard coded in include files.

• Text that occurs in the configuration file that does not follow this specification is ignored by the code that reads the file. In particular, however, “#” characters are used to distinguish intentional comments in the file.

The configuration file will contain all of the vehicle-specific personalization information such as the following:

• Vehicle configuration – Jason 2, ARGO II, DSL-120A, JHU, Nereus, Sentry, A-4500 HOV or other vehicle specification

• Vehicle power and digital I/O

• Serial and network I/O port configuration information, such as baud rate, IP address, socket number, and destination of incoming and outgoing data

• Locale information such as dive site, local magnetic variation, local system origin and other dive specific parameters

• Vehicle controller information, including Vehicle controller gains: P, I, and D for X, Y, Z, yaw

A configuration analysis capability will exist, so a configuration file can be automatically tested before use and blunders and inconsistent information can be detected.

3.4. Core System Error Log File The system will maintain a high-bandwidth local disk-based time-stamped error log file, with system-defined function that prepends strings with a standard data log header. The log file should be closed out hourly, with filename indicating full date and time. There will be a console viewer for the high-bandwidth data log which will receive copies over the net. This is not the system data logging function; this is a function that will certainly be necessary in development, and probably not during routine operations.

3.5. Core System Data Logging The control system will generate time-stamped data strings including as a minimum, vehicle attitude, navigation thruster status, switch status, and event data. Additionally, the A-4500 HOV will periodically log its own format definitions and copies of its configuration data. One key point here is that NO data string should ever be written into code or changed within code without being documented.


Logging strings can be sent out on a Network broadcast port. They can also be written to local files.

3.6. Core System Software Data Structures The current software has a large and unwieldy “sensor” data structure that maintains information about many types of sensors, some of which have not been used in years. This structure should be cleaned up and new data access functions provided.

3.7. Jasontalk Messages The system will use a defined set of “Jasontalk” messages, which will be a further development and refining of those used for the other vehicles. Any message passing between threads and outside processes will be one of the defined Jasontalk types.

3.8. Core System Software Time Time should be controlled using a NTP server, with low timeout values on the controller. We have been very successful at using a single data structure for time. Experience to date has shown that using a double value for time since Unix time zero (January 1, 1970) works in a satisfactory fashion. A library of function providing the following capabilities is available: • Query system time.

• Convert system time to a double.

• Compute difference of two times.

• Convert double to (year, month, day, Julian day, hour, minute, second, nanosecond).

• Convert (year, month, day, Julian day, hour, minute, second, nanosecond) structure to double.

• Convert double to DSL data string time format.

• Convert DSL data string time format double.

3.9. Core System Message Routing The current messaging API functionality is superb, and has been tested in many applications. The system should make an error log entry whenever it drops messages.

3.10. Core System Software Timers The current system provides specialized timing sub threads that any local thread can call to receive timer messages via its message loops.


3.11. Camera Interface Camera control is a part of the Imaging Subsystems, and is not contained in the command and Control specification.

3.12. Manipulator Interface Manipulator control is a separate subsystem. The Command and Control System only controls their sub-sea power. Note that we will probably want to be able to manually adjust the manipulator hydraulic power pack speed depending on manipulator needs.

3.13. Network Security The control system is insecure in the sense that no passwords or encryption are required to connect to the core system. The entire vehicle network will be totally separated from the science network with a switch/router. The idea is to ensure that the control system network has no external traffic, so no need to implement security features, passwords, and the like.

3.14. Submarine Hardware Environment

3.14.1. Processors The current design for the Command and Control Subsystem features two core processors, plus a spare. One of these processors is the control processor, which runs both the “headless” real time controller and the pilots Graphical User Interface. The second processor runs the “headless” Navigation Engine and the Navigation GUI. The third processor can perform any of the tasks performed by the first two, and is a ready spare. All three of these processors will be identical. The current plan is that they will be mini-ITX based, with at least one available slot for external peripheral boards. It is likely that additional processors will be installed for performance on non-core tasks. These would include operation of the Reson sonar, the imaging sonar, and the frame grabber.

3.14.2. Network The submarine will support a gigabit network, with SNMP managed switches providing redundancy in communications with the external hardware. Figure 1 includes a representation of the top level network architecture. The key to the network architecture is that the Ethernet system forms a ring, allowing redundant access to all nodes. It will be important that this ring topology remain intact and that the submarine control network be isolated from external networks.


Figure 1. Submarine Network Topology

3.14.3. I/O The Command and Control system must support several types of I/O to devices. They include: • Serial (RS-232/RS-485). Serial communications to and from the main processors will

accomplished using network based serial device servers. The leading candidate for these device servers is built by Moxa Communications; we sometimes use the generic term “moxa” to indicate a network based serial device.

• Analog and Digital I/O. There is a wide variety of network based analog and digital input/output systems. The command and control system must support a number of specific types, and should have growth capability for more. The system will include an Ethernet based I/O adaptor such as the ioLogik E4200, which supports digital inputs and outputs as well as both voltage and current input and output modules.

This analog I/O will be used for the following purposes: • Analog output to motor controllers

• Analog output to hydraulic amplifiers

• Control of relays to drive hydraulic solenoid valves


• Measurement of analog quantities, such as temperature

• Digital input/output for sensors and alarm criteria

3.14.4. Monitors/Displays The Command and Control system must support several computer-based outputs—in particular, the Pilot GUI and the Navigation GUI are probably both full-screen systems. They both should use touch screens as well. It would be desirable if the computer outputs were routable along with the video from the submarines imaging systems. However, given the rather key function of the pilot GUI and navigation GUI, these displays should be capable of a direct, non-routed output from the relevant computer. Figure 2 shows the concept, which must be more fully developed to include display of data from legacy and non-control oriented computers, such as imaging and profiling sonar displays and the science computer.


Figure 2. Monitor/Display Concept


4. Implementation Details Figure 2 shows a block diagram of the planned Submarine Command and Control system architecture. Devices and their serial (or network) connections are shown. The submarine core computer communicates via a large number of serial ports and a network connection.

4.1. Submarine Real Time Controller The core computer system consists of a number of threads in a single process. A list of threads follows. Most threads have a single instance. Some threads, like the serial I/O thread, have many instances.

4.1.1. Main Thread This is the process’s int main(int argc, char * argv[]) entrypoint. This thread performs the following steps: • Print code version, compile date and time, present date and time to console screen.

• Launch system logging thread – which opens new log file. All system logging events are then written identically to both log file(s) and to console screen.

• Log code version, compile date and time, present date and time.

• Check for available resources, logging results of each to log file and screen:

• O/S version

• RAM

• Disk space

• Com ports

• Network interface

• Keyboard

• Read ASCII initialization file, initializing data structure entries, logging parse results and the entire file contents as it is read.

• Launch the system processes.

4.1.2. Serial I/O Threads Serial I/O processes for all serial ports (many). These open a specified com port, and perform generic serial I/O. All instances of this thread are identical, only the calling parameters change. Responds to WSS, RSS, WCP, WSX, PNG, and KILL messages. It should be possible to handle parity errors on the sio channel. This is not a requirement for initial delivery of the system.


4.1.3. Network I/O Threads Network I/O processes for all network ports (several). Functionality is nearly identical to Serial I/O threads, but communicates over a pair of sockets.

4.1.4. Sensor Thread Initializes all serial and network based sensors, interrogates them, processes serial responses, and loads this data into the sensor data structure. Provides alarm, logging, and display outputs.

4.1.5. Hotel and Power Management Thread Controls all Lanecon power circuits, does power management, and provides for automated ground fault monitoring. Provides alarm, logging, and display outputs.

4.1.6. Control Thread Performs reference, state, and feedback computation. Issues thruster commands to the Motor Controller Thread. Provides logging and display outputs.

4.1.7. Motor Controller Thread(s) Communicates (via SIO/NIO threads) with the motor controllers that will be used to drive the thrusters and the HPU. Also uses the network based analog I/O device to provide control voltages to these devices. Provides alarm, logging, and display outputs.

4.1.8. Hydraulic Thread Communicates (via SIO/NIO threads) with the hydraulic controller and the hydraulics pressure transducer. Produces logging/distribution output necessary for control via GUI and potential handboxes. Provides alarm, logging, and display outputs.

4.1.9. Joybox Thread Runs the pilot handbox, and provides output to the Control Thread.

4.1.10. Generic Backdoor (command) Threads (several) Performs superset of existing backdoor with several enhancements. Can communicate over a serial port (via a Serial I/O thread) or a network socket pair (via a Network I/O thread). All GUI interfaces will communicate to the system via JasonTalk commands on one of these backdoors.

4.1.11. Timer Thread Sends timer messages to requesting threads at a requested rate.


4.1.12. Data Logging Thread Sends data to a logging system via serial lines and/or network socket, or logs it to disk as requested in the initialization file. This same data output could potentially feed the GUI, and send output to the system console.

4.1.13. Pan and Tilt Thread The submarine uses its existing pan and tilt systems differently than Jason so must use a different pan and tilt. The pan and tilt thread will read analog inputs from control devices, and control a relay output to move the pan and tilt.

4.1.14. Data Thread A thread will collect relevant submarine data from the sensor and control structures and distribute regular messages on the network or serially to external devices and software.

4.1.15. Configuration Transfer Thread GUI’s that communicate with the real time controller will need to obtain configuration information from the controller. In the Jason/Isis/Hercules systems, the GUI makes a request, and a series of configuration messages is sent on the network. Although this has performed satisfactorily, maintenance of the message formats as code and requirements change has been problematic. In the Nereus system (when running in ROV mode) the GUI reads its own ini file, and it is the responsibility of the operators to ensure that the ini file is the same between the vehicle controller and the GUI’s. This presents obvious problems in synchronization. The A-4500 HOV will use a file based method for transferring configuration. When the GUI requests configuration, the controller will read and transfer the configuration file over the net. The GUI will save and read the file itself.

4.2. Vehicle Simulation Development and support of submarine-specific portions of the real time controller will be supported by a simulation engine that will provide inputs to the system when real data are not available. The simulation engine will provide tine varying simulated vehicle pose and associated sensor values to the system for display and processing. These simulated inputs will enter the system in as close to a “real” fashion as possible—i.e., the serial or network I/O threads that would normally receive sensor data should receive the simulated data.


4.3. Pilot Heads-Down Display The pilot will use an alphanumeric display for submarine Heading/Depth Altitude/control parameters. This could be an electro-luminescent or other display mounted directly underneath the forward viewport. It will be a network or serial based device that will receive feeds from the Data Thread.

4.4. Pilot Hand Box The pilot will use a controller similar to existing Jason joy box, but optimized for submarine ergonomics.

4.5. Pilot Instrument Panel (GUI) There will be a panel display with a touch screen running a custom application for vehicle control. This will communicate with the topside computer via a backdoor channel, preferably over the network. The custom application will be similar in concept to the Jason 2 and Nereus GUI’s, but with a much cleaner interface optimized for touch screen use. It will be broken into separate pages. Figure 3 shows a prototype showing the multi-page concept. Selection of the top buttons causes a separate sub page to appear in the lower left side of the screen. The right side of the screen displays data which are constantly available.

Figure 3. Prototype GUI


4.5.1. Power Page This page, separated via a tabbed interface into separate logical groups, allows the pilot to monitor and control the power status of all the devices in the system.

4.5.2. Control Page This page allows the pilot to change the control modes of the submarine, moving different axes of control (such as heading, X/Y, and depth) from thrust to closed loop control. It is also the location where button-auto control is exercised.

4.5.3. Hydraulic Page This page allows control of the individual actuators and valves, and feedback from the controller.

4.5.4. Battery This page allows monitoring of battery environmental and operating parameters.

4.5.5. Actuators This page allows monitoring and control of the motor controllers.

4.5.6. Telemetry This page allows monitoring of the various components of the through-hull telemetry systems and networks.

4.5.7. Sensors This page allows monitoring of data from various submarine sensors.

4.5.8. Alarms This page allows monitoring and control of system alarm indicators. In addition, an array of software driven icons resembling LED’s is always visible, and represents a high-level summation of system alarm status.

4.5.9. Navigation This page presents a summary of the vehicles navigation data and allows rudimentary control of trajectory sources.

4.5.10. Ballast and Variable Ballast This page presents information from the ballasting system and allows control of the ballasting/VB actuators (note: Stage 1 A-4500 HOV will not support these capabilities).


4.5.11. Configuration Transfer As described in Section 4.1.15, the GUI will request configuration from the real time system using a network based file transfer mechanism.

4.6 Navigation Engine This is an application built upon the same Core System Architecture as the Real Time Controller. It is “headless”, built upon a POSIX threaded architecture, and will use much of the same code as the RTC and as the ROV/AUV Controller. The basic function of the Navigation Engine is to accept input using a variety of network and serial input threads connected to sensors such as the Phins inertial navigator and the RDI Doppler. Using command and control input from the Navigation GUI (See Section 0), it will produce a best estimate of submarine state and pose for delivery to the Real Time Controller, the Navigation GUI, and for data logging. It will contain a variety of threads 4.6.1 Main Thread See Section 4.1.1. 4.6.2 Serial I/O Threads See Section 4.1.2. 4.6.3 Network I/O Threads See 4.1.3 Section. 4.6.4 Navigation Sensor Thread See Section 4.1.4. 4.6.5 Sensor Integration Thread Accepts input from the sensor thread and computes vehicle positions and pose using a variety of algorithms, some of which may be embodied in their own thread. The minimal required set of algorithms is: 4.6.5.1. Direct measurement using GPS 4.6.5.2. Direct measurement using ALBL 4.6.5.3. Integration of DVL and attitude measurements to produce a relative position whose constant of integration is supplied by one of the other threads (for example, 0 or 0) or by external entry. Control of which algorithm is used is supplied by external input.


4.6.6 Generic Backdoor (command) Threads (Several -- See Section 4.1.10) The Navigation GUI interface will communicate to the system via Jasontalk commands on one of these backdoors. 4.6.7 Configuration Transfer See Section 4.1.15. 4.7 Navigation GUI This is a wholly new application. It will be written using the QT toolkit and API, and will perform the following functions. It will support the following functions: 4.7.1 Sensor/Algorithm Selection Allows the pilot to select the sensors and algorithms used by the Navigation Engine to generating the vehicle position and pose estimates. 4.7.2 Map Display Present the pilot with a map-based display composed of: 4.7.2.1 Background Map: A map underlay that can be presented in a variety of map

projections and coordinate system. 4.7.2.2 Graticule and Axes: Coordinate display in a variety of projections and

coordinate types and units. 4.7.2.3 Fixed Targets: Target icons and labels for targets entered into the system before

the dive. 4.7.2.4 New Targets: Target icons and labels for targets entered during the dive. 4.7.2.5 Vehicle Models: a scaled rotationally accurate representation of the submarines

real time position. 4.7.2.6 Vehicle Track: A history with controllable length showing vehicle position fixes

over time. 4.7.3 Target Entry Allows entry of targets based upon either current position and range/bearing, or typed in coordinates 4.7.4 Sensor Status and Display Near-real time indicators of sensor status and displays, both graphical and textual of recent data. 4.7.5 Configuration Transfer


See Section 4.5.11. The Navigation GUI method for performing this task will be identical to that used by the vehicle GUI. 4.8 Navigation Simulator Development and support of the Navigation Engine and GUI will be supported by a simulator that will provide inputs from simulated sensors when real data is not available. 4.9 Legacy Systems The A-4500 HOV must support certain “legacy” applications and systems. These systems do not require substantial development, but the architecture must support their continued use. These include: 4.9.1 Imaging Sonar Display The current submarine uses a CTFM sonar for search and obstacle avoidance. This will potentially be replaced in the A-4500 HOV with scanning sonar, similar to that used in the Jason 2 system. This sonar uses a vendor-supplied software application that must be hosted on a Windows-based computer, preferably identical to those used in the command and control systems.

Should the CTFM not be replaced, it places particular demands upon its host computer, including a specific sound board, and these demands will have to be accommodated. 4.9.2 Mapping Sonar Control and Display The current submarine supports a Reson multibeam sonar that is used for sea floor mapping. A laptop computer is used for control and display of the data from this sonar. A computer compatible with those used for command and control will be installed in the A-4500 HOV and the Reson software hosted on this computer. 4.9.3 Science Computer In Alvin, scientific observers are provided with a computer that can host science-provided applications. The same computer hosts the Alvin Frame Grabber, an application that provides a visual dive log to the scientists. In practice, nearly every scientist who wants to run their own application brings their own laptop computer, so this function need not be supported. However, the Frame Grabber must still be supported in the A-4500 HOV. 4.9.4 Event Logging Capability ROV Jason 2 supports a digital event logger that offers keyword/common vocabulary annotation, time stamping, and logging of scientific observations. Effective use of this capability in the A-4500 HOV will require use of a touch screen, and potentially modification of the software to use larger buttons suitable for touch screen use.


5. Appendix A: Lanecon Functions and Command Protocol This Appendix, dated March 13, 2009, is included for information and completeness Those interested in implementing code or procedures based upon the information it contains should ensure that they have the most recent version. Lanecon Functions and Command Protocol

Jh changes 5-9 January 2009 Lja Additions 25 Feb 2009 Lja 27Feb2009 Change Default Address

Change Scratchpad format Change Raw ADC value to 4-character decimal

Lja 3Mar2009 Change calibration data to decimal from hex Lja 4Mar2009 Change to consistent output format

Provide Grounds of both polarities Change ADC values and calibration values back to 3-digit hex

Lja 11Mar2009 Add delay calibration commands Lja 13Mar2009 Increase size of Scratchpad – code v8.2

Functions • Power Supply On/Off • Auxiliary Output On/Off (quantity 4) • Voltage measurement • Current measurement • Ground measurement • Temperature measurement • Address Configuration (Bank address only) • Voltage Configuration • Current Configuration • Ground Configuration • Temperature Configuration • Scratchpad data

Notes • Commands are ASCII, readable, and terminate with either CR or NL. • Responses are ASCII, readable, and terminate with CR-NL. • Commands are case sensitive. Responses are in all capitals. • There is no fixed time for response, but the response does not begin until after the

command is complete. Responses should be as prompt as practical. There is no fixed


timing between the response and the requested action, but should be as close to simultaneous as practical.

• All commands start with ‘#’, a 3 character command type, and a 2-character address. • All responses start with ‘!’, a 3 character command type, and a 2-character board

address. • Command type, Address, command parameters and response values are separated by

white space. • Address (aa) is an 8-bit hex value. The low 4 bits of the address (the unit number)

are set by the unit number switch on the board. The high 4 bits of the address (the bank number) are stored in the on-board configuration. F can be used as a default for an address character

• An address match occurs with the board address (aa), the unit address (Fa), the bank address (aF), or the default address (FF). The full unit number is used in the response, even if default value(s) are used in the command.

• If there is no address match, the board makes no output. • If there is an address match but a command error, the board makes an error response. • Where numerical values are provided, the exact number of characters is required. If

necessary, pad with zeroes as required. Measured values are in decimal, addresses and ADC values are in hex.

• All commands are terminated with a two character checksum before the CR-NL. The checksum is formed by the excusive-or'ing (XOR) of all characters in the command/argument string--except for the checksum itself and the terminator. The starting character (‘#’ or ‘!’) and the space before the checksum is included in the checksum calculation.

• A checksum of FF is considered by all controllers as universally correct and no error check is performed. This permits human intervention in the form of troubleshooting or testing without the need to manually calculate a valid checksum.

• The device requires 12Vdc power, drawing about 30mA. • Communications are through 2-wire RS422 at 38400 baud. One set of RS422 biasing

resistors is required on the bus. 4.7KΩ should be appropriate. One termination resistor of 120Ω should be at each end of the bus.

Control Functions • Control the Power Supply

#WPS aa x cc !SPS aa x cc

x = 0 to turn the Power Supply off 1 to turn the Power Supply on

• Control the Auxiliary Outputs

#WAU aa n x cc


!SAU aa n x cc n = 1 to affect Auxiliary Output 0 2 to affect Auxiliary Output 1 4 to affect Auxiliary Output 2 8 to affect Auxiliary Output 3 Or’ing these values together (in hex) causes multiple Auxiliary Outputs to be affected. x = 0 to turn the specified Auxiliary Output(s) off 1 to turn the specified Auxiliary Output(s) on

Note: The Auxiliary Output controls are independent of the Power Supply control, though they can only provide power if the Power Supply is on.

Read Data Functions

• Report Power Supply Control #RPS aa cc !SPS aa x cc

x = 0 indicates the Power Supply is off 1 indicates the Power Supply is on

• Report Auxiliary Control

#RAU aa cc !SAU aa n cc

n = 1 indicates Auxiliary Output 0 is on 2 indicates Auxiliary Output 1 is on 4 indicates Auxiliary Output 2 is on 8 indicates Auxiliary Output 3 is on Where more than one Auxiliary Output is on, these values are Or’ed together (in hex).

• Read Data – Voltage

#RDV aa cc !SDV aa vv.vv cc

vv.vv is the reported Power Supply Voltage, in volts. The allowable range is 00.00 ≤ vv.vv ≤ 99.99

• Read Data – Current

#RDC aa cc !SDC aa cc.cc cc

cc.cc is the reported Power Supply Current, in amps. This reflects the total current of the primary and auxiliary outputs. The allowable range is 00.00 ≤ cc.cc ≤ 99.99


• Read Data – Grounds #RDG aa cc !SDG aa gg.gg gg.gg cc

gg.gg is the reported circuit Ground value, in dimensionless units. Zero magnitude indicates no ground. Greater magnitude indicates greater ground. The first value is positive grounds (to check for grounds on the negative leg). The second value is negative grounds (to check for grounds on the positive leg). The allowable range is 00.00 ≤ gg.gg ≤ 99.99

• Read Data – Temperature #RDT aa cc !SDT aa tt.tt cc

tt.tt is the reported board Temperature value, in degrees C. The allowable range is -9.99 ≤ tt.tt ≤ 99.99

• Read Data – All #RDA aa cc !SDA aa x n vv.vv cc.cc gg.gg gg.gg tt.tt cc

x is the Power Supply value as described above n is the Auxiliary Output value as described above vv.vv is the Voltage value as described above cc.cc is the Current value as described above gg.gg are the Ground values as described above tt.tt is the Temperature value as described above

Status Functions • Write Bank Address

#WAD aa aa cc !SAD aa aa cc Note: The first aa of this command is the command address. The second aa is the new Bank Address to be stored. Note: The high 4-bit Bank Number is stored in non-volatile memory. The low 4-bit Unit Number of the address is not affected. The complete 8-bit Address is provided in the response.

• Read Address

#RAD aa cc !SAD aa aa cc

• Error Response


!ERR aa mmm x cc mmm is the command type which was received in error x = 1 indicates a command format error

This response is used for a command for which the address and checksum are correct but the command format is not.

2 indicates a checksum error This response is used for a command for which the address is correct but the checksum is not.

3 indicates a channel selection error This response is used for a command for which the address, checksum and command format are correct but the channel selection is not.

Configuration Functions

• Read Raw Data – Voltage #RRV aa cc !SRV aa ddd cc

ddd is the hex ADC value for the Voltage channel The allowable range is 000 ≤ ddd ≤ 3FF

• Read Raw Data – Current

#RRC aa cc !SRC aa dddd c

ddd is the hex ADC value for the Current channel The allowable range is 000 ≤ ddd ≤ 3FF

• Read Raw Data – Ground

#RRG aa cc !SRG aa ddd cc

ddd is the hex ADC value for the Ground channel The allowable range is 000 ≤ ddd ≤ 3FF

• Read Raw Data – Temperature

#RRT aa cc !SRT aa ddd cc

ddd is the hex ADC value for the Temperature channel The allowable range is 000 ≤ ddd ≤ 3FF

• Read Raw Data – Auxiliary Input

#RRA aa cc !SRA aa ddd cc

ddd is the hex ADC value for the Auxiliary Input channel


The allowable range is 000 ≤ ddd ≤ 3FF

• Write Calibration – Voltage #WCV aa vv.vv ddd vv.vv ddd cc !SCV aa vv.vv ddd vv.vv ddd cc

The two pairs (vv.vv,ddd) are stored in non-volatile memory. When subsequent values are read, the ADC value is interpolated between (or extrapolated beyond) these points to calculate the voltage. For best performance, it is best for the two pairs to be as far apart as practical.

• Read Calibration – Voltage #RCV aa cc !SCV aa vv.vv ddd vv.vv ddd cc

• Write Calibration – Current #WCC aa cc.cc ddd cc.cc ddd cc !SCC aa cc.cc ddd cc.cc ddd cc

The two pairs (cc.cc,ddd) are stored in non-volatile memory. When subsequent values are read, the ADC value is interpolated between (or extrapolated beyond) these points to calculate the current. For best performance, it is best for the two pairs to be as far apart as practical.

• Read Calibration – Current #RCC aa cc !SCC aa cc.cc ddd cc.cc ddd cc

• Write Calibration – Ground #WCG aa gg.gg ddd gg.gg ddd cc !SCG aa gg.gg ddd gg.gg ddd cc

The two pairs (gg.gg,ddd) are stored in non-volatile memory. When subsequent values are read, the ADC value is interpolated between (or extrapolated beyond) these points to calculate the ground. For best performance, it is best for the two pairs to be as far apart as practical.

Note: The same calibration values are used for both the positive Ground and negative Ground measurement.

• Read Calibration – Ground #RCG aa cc !SCG aa gg.gg ddd gg.gg ddd cc

• Write Calibration – Temperature #WCT aa tt.tt ddd tt.tt ddd cc


!SCT aa tt.tt ddd tt.tt ddd cc The two pairs (tt.tt,ddd) are stored in non-volatile memory. When subsequent values are read, the ADC value is interpolated between (or extrapolated beyond) these points to calculate the temperature. For best performance, it is best for the two pairs to be as far apart as practical.

Note: A temperature calibration value can not be negative.

• Read Calibration – Temperature #RCT aa cc !SCT aa tt.tt ddd tt.tt ddd cc

• Write Calibration – elays

#WCT aa aaaa gggg cc !SCT aa aaaa gggg cc

The A/D converter delay (aaaa, in micro-seconds) and the Ground Detection delay (gggg, in milli-seconds) are stored in non-volatile memory. These values are used while performing the respective conversions.

• Read Calibration – Delays

#RCT aa cc !SCT aa aaaa gggg cc

• Write Calibration – Scratchpad

#WCS aa xxxxxxxxxxxxxxxxxxxxxxxx cc !SCS aa “xxxxxxxxxxxxxxxxxxxxxxxx” Vvvvv cc

Up to twenty-four characters are stored in non-volatile memory. vvvv is the code revision level.

• Read Calibration – Scratchpad

#RCS aa cc !SCS aa “xxxxxxxxxxxxxxxxxxxxxxxx” Vvvvv cc

xxxxxxxxxxxxxxxxxxxxxxxx is the Scratchpad text, surrounded by quotes. vvvv is the code revision level, preceded with ‘V’.

engineering plan pdr - woods hole oceanographic institution · been completed and analyzed, the...

Documents