Talk:Common Berthing Mechanism

Clear Passage Geometry

@Garyvdm;

A recent change to the CBM page has left it in a problematic state with respect to both accuracy and citation.

Prior to the recent change, the text was worded to be consistent with the reference cited: the CBM, when mated, does indeed provide a 50" diameter passage. This was as worded in the specification, to which the assertion referred.

The design of the hatch (which is not part of the CBM) constrains that passage differently than does the CBM itself, and is the actual source of the "square with rounded corners". Where two hatches face each other, a closeout panel is installed; the panel follows the outline of the hatch beam. If it is necessary to reflect the as-designed passage through the mated vestibule (which is not the same as a CBM), then the reference will need to be removed. A new citation will, of course, need to be inserted.

The CBM itself is actually about 6 feet in diameter. A comprehensive revision to the CBM page is in work based on an expanded set of sources (if I am counting correctly, around 130). It will correctly distinguish between the two geometric issues, and discuss the relationship between them.

I'll leave it to you whether to reverse the recent change for the short (I hope!) period before the revised write-up is ready for publication. Naturally, the revision will be subject to all of the normal collaborative editing practices, and I eagerly anticipate your detailed review of it. It is always nice to know somebody is paying attention! Not fred999 (talk) 23:16, 12 April 2020 (UTC)

I came to this article looking for a specification of what size/shapes the CBM must allow to pass (eg the ISPR racks) but failed. Article seems to say the rounded corner square (shown in so many images) is a bulkhead plate rather than part of the CBM per se. A google image search shows the CBM 'square' as 127 cm wide and tall. - Rod57 (talk) 17:01, 20 August 2020 (UTC)

If the article merely seems to say that the berthing plate (bulkhead) is not part of the CBM, then the the failure is mine alone. My intention was for that fact to be explicit ("...6 feet (1.8 m) across. At least one end of the vestibule is often limited in diameter by a smaller bulkhead penetration") . The geometry that ultimately constrains the size (and shape) of what passes between the modules is not part of the CBM, and can (therefore) vary from one installation to another. I included File:System Rack 1 into US Lab.jpg in the gallery to try & make the reality more clear. No part of the CBM is present in that photograph. The CBM is only required to provide a 50" diameter crew passageway down the center. It was never allocated a requirement for passing any particular size of equipment. Not fred999 (talk) 20:00, 20 August 2020 (UTC)

Overview of the July 2020 Re-write

Full disclosure: as will be noted from my user page, I had a modest part in developing the CBM. The project started before I got there and continued after I left (shortly before first use). It may be of further interest to know that my background on the project now known as "International Space Station" extended beyond the CBM, having worked several different aspects on several occasions (although not continuously) from 1982 through mid-2001.

The present organization of the article is my fifth major version. The first four don't warrant much discussion: they all failed to flow. The approach taken here gradually leads the reader from relatively non-technical material of general interest into the proverbial weeds (although not very far). One or more enterprising editors might, if the notion strikes them, be able to generate additional articles from the references and external links that would allow some of the history sections to be down-scoped & referenced to the (new) article. If I'd found articles that adequately addressed those topics, those sections would have been shorter.

Some enterprising editor having the skill and knowledge to archive the talk page prior to this point might wish to do so. I don't have a strongly-held opinion on that topic, but it might be more useful down the road.

The following notes address each major section, in the same order they're found in the re-written article.

Implementation Notes

Introduction

This section provides a very simplified discussion of the CBM's "what" and "how". To the best of my ability, all of the assertions are substantiated elsewhere in the article so, as suggested by the relevant Help: pages, no citations are included here.

The "Facts" table addresses "specified mass" because several different weights were found in the literature, none of which included any useful description of what was actually included. Actual mass may be different than specified, but the specification's intended complement is unambiguous.

Design Overview

The basic features of the design are addressed for each major type. Little attempt is made to present details in the main body, although some of the explanatory notes provided a glimpse into more detailed material. Essential functions and physical characteristics are introduced and described, along with the terminology used to discuss them. Specifications that dominated the intended capability are introduced, as are the fundamental distinctions between the various types of CBM and the original intent for each type.

No existing graphics (e.g., on-orbit photographs) could be found that provided a common scale and matching perspective for the major CBM types. The graphics for this section were expressly built to do so, albeit originally for a different venue. Detailed substantiation for their construction is included in their discussion pages on Commons.

Operations

Summaries of the basic operations are addressed. In this context, "operation" ("what you do with the dingus") is distinct from "function" ("what the dingus does"). The section relies heavily on flight documentation produced by NASA's Mission Operations Directorate for flights of the Space Shuttle as the ISS was assembled. Overall context is provided by reference to "The International Space Station: Operating an Outpost in the New Frontier", written by NASA's Space Station Flight Directors.

To the extent possible, each subsection provides a brief discussion of contingency operations relevant to the operation. In some cases, extensive contingency operations are available, in which case the notes point to the documentation.

There have been some instances where features of the CBM have been exploited in ways that the specifications did not foresee. I've called them "Opportunities" because I could not come up with a succinct title that better expressed the idea. Some enterprising editor might well improve on that title, and might also undertake to keep an eye on the Bishop Airlock Module to update the sub-section once it becomes operational.

It is entirely possible (perhaps even likely!) that there have been changes in operations since the Space Shuttle program ended. Late in the drafting process, I noticed that the timeline for accessing the vestibule might have been compressed, possibly by minimizing the leak check's dwell time. Some enterprising editor might find a way to determine what happened there, and when it changed...the wall where I've been beating my head was approaching structural failure, and I had to move on before I could really dig into it.

Developmental History

This section addresses the historical and technical contexts of the CBM, with just a slight lift of the veil in both directions.

Astute nerds will notice that the introductory material is a bit "ontological" in nature, providing information about what kinds of abstract topics are relevant to the CBM. The non-nerd will, hopefully, note that there are a couple of nice pictures to look at, and walk away feeling like they've gathered a tiny bit of insight about Engineering the assembly of really big things on orbit.

In effect, the introductory material provides background material for subsequent history sub-sections. Including it as a stand-alone unit allowed a much easier explanation of changes in the design as they came along, consolidating much of the technical referencing into a single location. It walks up to, but sticks no more than a couple of toes over, the line beyond which Engineering education is happening (which would, of course, violate wiki-intent). It is also easy to skip over, if desired.

The introductory material relies heavily on a small number of broadly-structured books, and on NASA's basic description of the environment in which spacecraft operate. It also relies on (but does not much quote) Zipay's mind-boggling description of module pressure structures and their verification.

In general, this section is organized by time frame. Additional sub-sections could easily be inserted, if new information becomes available to some enterprising editor.

The Origin sub-section supplies the "why" of a CBM, building on the rationale that motivated NASA to seek alternatives to docking. A much, much longer treatise on the topic could be written. Such an essay might have been incorporated into the existing Spacecraft docking and berthing mechanism article, but it would force a pretty significant change to the organization thereof. I did not (and do not) wish to entertain that project. Hence, this sub-section's quick turn toward the very specific topic of berthing-as-used-for-NASA-space-station.

The remaining five sub-sections chronologically map to the available documentation, summarizing each body of work and, where useful-but-brief, providing some contemporary context.

Galleries

As is usually the case, it is easier to describe a design with pictures than with words. All of my previous drafts tried to integrate pictures into the text...but that isn't very easy to do with the usual wiki-standards. IMHO, the key to a successful draft was to altogether remove the geometric details from the text, moving them into a set of pictures.

In effect, much of the "Design Gallery" is treated as if it is an old-school photographic drawing, where "find numbers" have been overlayed on a photograph. The technique allowed descriptive text, which might someday be translated, to be in the caption. Doing it off-line allowed me to avoid having to learn using the wiki-tools. All such photographs are available on line; some enterprising editor may wish to re-create each figure using the wiki-methods. The original sources are all available in the original upload pages (most of which are on commons).

In a few cases, "find numbers" were not used. Most of those were uploaded at high enough resolution that some enterprising editor could convert them, if so desired.

More photographs could be added...thousands of them are available online. IMHO, however, these capture the basics with enough overlap (to provide a linking context between them) to suffice.

I orbited endlessly on the subject of where to locate the design gallery. It could easily have gone immediately after the "Design Overview", but forced the reader to wade through the most highly detailed information in the article. It could also have been broken into a separate page with only a small loss in continuity. The location was, to be frank, quasi-arbitrary. Some enterprising editor (more wiki-sensitive than I) may wish to give further consideration to this issue. The same commentary is applicable to the operations gallery.

Missions

The Missions table is a very straight-forward listing of all CBM operations I discovered. Any enterprising editor who adds new berths to the list should carefully note that the referencing scheme will require the matching addition of a new (probably status) source. I noticed that similar pages may have been less than perfectly consistent in doing so.

Like the Galleries, the Missions Table is a good candidate for extraction to a dedicated page.

N.B.: Earlier versions of this table, which I added quite some time ago, had more columns. Those were artifacts of the table's original purpose, which was to support a scatter plot of the masses on both sides of the CBM/CBM interface. The plot itself supported a discussion about the relative thermal mass, which really isn't pertinent to a venue that emphasizes neutral substantiation. I have, therefore, deleted all extraneous columns for the current iteration.

Glossary

I saw two distinct problems with terms used in the CBM literature: 1) many of the terms are arcane, even for Engineers and 2) in some cases, more than a single term was used to describe the same topic (sometimes within the same source). The first category required some explanation in order to be of use. The second required a reasonable effort at disambiguation.

Regrettably, the glossary template's tooltip doesn't pop the definition. It seems like that problem should be amenable to solution, since it would be similar to what the harvard templates do. I thought about abusing harvard to give the desired behavior, but decided against it. Some enterprising programmer might be able to make a run at tweaking the glossary template to make the tooltip happen.

Notes and Citations

This section generally follows several of the examples used in the Help: explanations and citations for the main body of the article are integrated into a single set of notes. This approach, which was not my first choice, allowed the notes to deal with differences between sources (which were many) and, where possible, with their resolution. In several cases, no complete resolution was possible; in those cases, the notes indicate which were followed. The approach further allows the main body of the article to be more linear than it would otherwise have been.

The figures depart slightly from that notion: simple citations are incorporated directly into the captions. The captions are essentially used here as a type of note, anyway, and doing it the other seemed unnecessarily complicated when reading. Exceptions to this exception were made when true explanations were necessary.

In all cases, I've used some variant of the harvard templates. I tried other schemes, but that appeared to be the most fully featured.

In many cases, but not all, notes are "bundled" at the end of paragraphs for all the reasons in the Help: pages. In some cases, however, notes were unbundled because it made sense to allow a note to concentrate on a single explanatory topic. That's mostly a matter of style. Other editors may choose to combine them, or further split. As long as the technical content is not corrupted, I don't really "have a dog in that fight".

With a single exception, there is modest re-use of notes. A single note was devised to explain the naming conventions adopted throughout many of the figures. It also observes that several of the figures' discussion pages (mostly on Commons) contain additional substantiation. Other editors may reasonably take exception to allowing any substantiation to be stored with the figure.

Many of the documents contain pagination that does not match that of the pdf. I've tried to clearly indicate which pagination is being used. I think it would be good if some enterprising editor could find time to independently verify that.

References

It turned out that more references were available than I expected when I started, and more details were available in the aggregate. Eventually, I had to compile a Topical Analysis table of 153 documents by 858 (candidate) topics. The table allowed me to winnow redundancies out of the document list...mostly. Some enterprising editor(s) could probably remove a few more documents without loss of substantiated information, but I don't think the number would be very large.

After several false starts, I divided the references into two distinct parts.

The first subsection is a list of "authored" documents. Many of these are not appropriately attributable to a single person, even if a name could (somehow) be associated. Therefore, the section starts with a listing of the organizations that are properly attributable, whether as an author or as a publisher. The list uses the harvard templates. In most cases, references in the body of the article are by way of "key text", because the article was more cognitively accessible when the general nature of authoritative documents was immediately evident from how they were referenced. In some cases, however, "technical papers" are referenced by name and date, because the titles are often arcane (unlike most of the organizational documentation).

The first subsection contains links to many technical papers in the NTRS. Technically, I suspect that the URLs violate the wiki practice of linking by way of search pages, but I could not suss out any other means that the server provides to point to "where YOU [meaning me] found it". Some enterprising wiki-editor might well figure that out, in which case all of the links could be changed into better compliance.

The second subsection is a list of NASA status pages. There have been several different flavors of status during the period in question (late 1990's and on). Although the list was built using the standard "cite web" syntax, the standard display syntax produced a very uneven appearance: some of the statuses used a "promotional" title, while others simply indicate a date of issue. The approach taken in this section renders all "status" pages essentially the same, with the focus on their classification and date. I have noticed other wiki pages taken a more mixed approach, which looks (at best) uneven.

Some enterprising editor might wish to evaluate the on-line sources in both subsections to determine if they warrant archiving. If so, said editor will probably remember to update the lists of citations accordingly. Not all of the sources are online, but enough information has been provided to allow procurement. In some cases, an FOIA might be required. JSC (and most other NASA websites) have explicit instructions on how to do so.

Some enterprising editor should probably check my work to ensure that everything on the two lists has, indeed, been called in the body of the article. Also, to independently verify that the citations do, indeed, lead to the sources as listed. I think that both issues are right, but another set of eyeballs is always a good thing. (I found one egregious linkage error during an almost-final proofing pass. Really, another set of eyeballs would be a good thing.)

Some used references are listed below, although they have not been consistently formatted. In most cases, a superior source was found. In a few cases, the material simply wasn't included in the article. Later editors may come to a different conclusion about inclusion.

• Media Release: 2014/04/20. Accessed 2019-12-12.

• Press Release: 2014/09/21. Accessed 2019-12-12.

• Cygnus Mission Overview. Accessed 2019-12-12.

• Carr, Jim, Mission Control Answers Your Questions, Undated (STS-92), ISS Mechanisms & Maintenance Systems Group. Accessed 2019-12-12.

• TRASYS Solves Radiation-Related Thermal Analysis Problems, 2011-08-12, NASA/JSC. Accessed 2020-04-15.

• SpaceX's Dragon Carrying NASA Cargo Resupplies Space Station. Accessed 2019-03-08.

• ISS Mission Page (Orbital). Accessed 2019-12-12.

• STS-92 Presskit, 2000, NASA Johnson Space Center, Houston, TX. Retrieved 2019-12-09.

• SpaceEx 2 Cargo Manifest. Retrieved 2019-12-12.

• NASA/BEAM Fact Sheet. Retrieved 2019-12-12.

• NASA HQ News 2012/05/25. Accessed 2019-12-12.

• NASA/Orbital 2 Press Kit. Retrieved 2019-12-12.

• Japanese Cargo Spacecraft Berthed to Station. Accessed 2019-12-12.

• CRS-11 Mission Overview. Retrieved 2019-12-12.

• ISS Expedition 15 PMA-3 Relocation. Accessed 2019-12-11.

• "Dragon Readied for Launch, European Ship Prepped for Departure". NASA/HQ. 2015-01-09. Retrieved 2019-12-12.

• Shindich, D.; Miskovish, R. S.; Matt, H.; Howe, B.; Rowley, M. (2017-08-21). Thermal and Fluid Analysis and Design of the Nanoracks Airlock® Module (PDF). Thermal & Fluids Analysis Workshop (TFAWS) 2017. NASA/MSFC. TFAWS2017-PT-05. Retrieved 2019-12-11. {{cite conference}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

• Jaffery, Waris S, Robotic Variable Polarity Plasma Arc (VPPA) Welding, 1992, The Boeing Company, The Third National Technology Transfer Conference and Exposition, Baltimore, MD, USA. Retrieved 2020-02-28.

• Hoover, Daniel J. (1987-05-01). Space Station based options for orbiter docking/berthing. The 21st Aerospace Mechanisms Symposium. NASA/JSC. pp. 261–273. Retrieved 2019-12-10.

• NASA/MOD (2008-02-20). PDRS Operations Checklist STS-123 Flight Supplement (PDF). NASA/JSC. JSC-48040-123. Retrieved 2019-12-19.

• NASA/MCC (2008-11-24). STS-126/ULF2 FD 11 Execute Package (PDF). NASA/JSC. Retrieved 2019-02-05.

• NASA/ASAP (1990-03-01). Annual Report of the NASA Aerospace Safety Advisory Panel (1989) [Part 2/3] (PDF). NASA/HQ. Retrieved 2019-12-09.

• Sutton, William G.; Tobbe, Patrick A. (1991-01-01). "The MSFC space station/space operations mechanism test bed". NASA Automated Rendezvous and Capture Review. A Compilation of the Abstracts. (Abstract). NASA/MSFC. Retrieved 2019-12-10. {{citation}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

• PHC (2010). Parker O-Ring Vacuum Sealing Guide (PDF). PHC. ORD 5705. Retrieved 2020-02-27. {{citation}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

• JSC-48040-123, PDRS Operations Checklist STS-123 Flight Supplement, 2008, NASA Johnson Space Center, Houston, TX. Retrieved 2019-12-19.

Assemblies, Moving Mechanical, For Space and Launch Vehicles, General Specification for Contemporary practices for development of spacecraft mechanisms

Here’s What It’s Like to Spend a Year in Space, 2017-08.

CBS News: Final U.S. module attached to space station (UPDATED), 2011-03-01 Installation of the Leonardo MPLM, with timeline table. The timeline looked suspiciously inconsistent with others in the same time frame, but that issue was not pursued.

• NASA Release 96-245, 1996, NASA/KSC Retrieved 2019-12-09.

External Links

This section contains the root sites for many of the individual status pages listed in the reference sections. In some cases, material in the article was discovered by paging through these sites one day at a time. In other cases, material was found using various search engines.

This section also contains interesting sites that, for one reason or another, did not contribute directly to the article. They were both contextually relevant and interesting, but in a peripheral sort of way. Not fred999 (talk) 23:35, 1 July 2020 (UTC)

Revisions of 11 July 2020

@Soumya-8974;

The infobox is now factually incorrect in several ways. I do not see the rationale behind the changes. Please help me understand it.

1. NASA has never manufactured a CBM. Boeing previously made, and commercially sold, CBMs. But they no longer do. CBM are now made elsewhere. The previous version, however, was factually correct: NASA and Boeing collaborated on the development, which is a Life Cycle Phase distinct from "manufacturing". But development, per se, is no longer addressed at all.

2. The revised box labels the CBM as an "Instrument". While this is syntactically true, it is a not a standard usage for complex machinery such as the CBM. I have never seen it used that way in the published literature or in practice. Perhaps you can direct me to some? The box used to label the CBM "Connection Type", which directly addressed the definition of "androgynous". Was the categorization incorrect?

3. The revised box now labels the CBM as a docking system. I have, to date, found no source that considers it to be one.

4. Standard Engineering interpretation of the revised dimensions would take them to mean the CBM is rectangular, which it is not. If we must use the combined syntax ("A in x B in"), is there a way that we can list them in a manner that matches the actual form of the mechanism?

5. The revised box now addresses "Host spacecraft", with which I have no factual disagreement. However, most of the host spacecraft were left off the list, and the "Operator" category has left me confused as to your intent. There have, for example, never been any CBMs used on the ROS. ESA and JAX don't "operate" CBM's, per se: only an ACBM gets "operated", and I am aware of no source that indicates JAXA directly controls the ACBM on Kibō. Also, although it may seem strange, Kibō and Columbus are part of the USOS.

6. Belatedly, I realized the the mass no longer stipulates "specified". There is little information available about the actual mass, which is what the row label now addresses. The only number I could find did not match any of the specification values. It also did not identify the particular configuration for which the weight was quoted. I omitted it because I could not correlate it to the other available data. Not fred999 (talk) 16:56, 12 July 2020 (UTC)

In addition, I am moderately curious to understand the rationale for a couple of other changes that did not impact the factual accuracy of the article:

1. Deletion of the "Orbital Operations" section. Why was that thought to be improper?

2. Deletion of the link to the Design gallery. It seemed to me that the link helped the reader understand that more detail would come later. Some matter of style (of which I am unaware) may have dictated their deletion...but then, I noticed that other such links were not removed, so I am left puzzled.

Thanks in advance for your very kind reply. Not fred999 (talk) 22:44, 11 July 2020 (UTC)

Proposal

There having been no response to date, I propose the following course of action:

1. Restore the previous version of the infobox, which was factually accurate. I will add a dedicated note to directly substantiate the information for future reference.

2. Restore the reference to the Design gallery, making it similar in pattern to the Operations section's reference to the Operations Gallery.

3. Leave the other formatting changes committed on 11 July 2020.

I do not propose to alter any other spacecraft assembly mechanism pages. After a detailed review of the spacecraft instrument template, it seems clear that it was designed for true spacecraft "instruments" (generally sensors) that are truly hosted on a specific spacecraft design (e.g., on a "spacecraft bus"), having some tactical or scientific purpose. The CBM does not meet that description: it is an interface, having the functionality associated with that class of hardware, software, and procedures. Some interested and enterprising editor might wish to undertake an ontological study of such devices to generate a template more appropriately tailored to their nature.

I'll stand by for a few days before taking any action. Not fred999 (talk) 17:25, 15 July 2020 (UTC)

Done.Not fred999 (talk) 18:54, 20 July 2020 (UTC)

Replaced the nostalgic factbox with the newly-created Template:Infobox docking mechanism (despite the name, it can be used on berthing mechanisms as well). It contain similar parameters as the nostalgic factbox. --Soumya-8974 ^talk _contribs ^subpages 17:08, 4 August 2020 (UTC)

Splitting proposal 4 August 2020

Common Berthing Mechanism → Common Berthing Mechanism and CBM development history – The CBM article is too long to the navigate through (the "operations" take 20 mouse scrolls to navigate and the "developmental history" take 40 mouse scrolld to navigate). Therefore, I suggest to split this article into a new article titled CBM development history (consistent with Starship development history). --Soumya-8974 ^talk _contribs ^subpages 17:35, 4 August 2020 (UTC)

The current article is consistent with the guidelines for length, but I have no strongly held opinion either way. There are many articles of greater length and lesser readability. I think it is mostly a matter of editorial style. The outline was built with the notion that it could (if some enterprising editor was motivated to do the work) be split into individual pages for the history section, operations section, missions table, design gallery, and operations gallery. Some short summary paragraphs for the history and operations sections could probably be written for the main article, and there may need to be some re-write in the (new) individual pages so that they don't accidentally presume that the reader has just covered the formerly preceding material. I don't think any great insight to CBM is necessary to do any of that, but will find time to review the new drafts once they've been created. Not fred999 (talk) 22:52, 4 August 2020 (UTC)

I've had a chance to review Starship development history. I hope you weren't suggesting to make a new page modeled after that! A history page for a launch vehicle program that has not yet come close to operational status doesn't make much sense. Once it is actually history (as opposed to "current events") much of what is there will turn out to have been pretty unimportant. Moreover, the talk page clearly indicates quite a bit of controversy on the entire subject of having a stand-alone history page. Many of the arguments for doing so are fairly cogent, making me lean toward leaving the current CBM page's scope as it is.Not fred999 (talk) 17:30, 7 August 2020 (UTC)

As a consumer/reader of this article - I agree with the suggestion to split out the CBM development history. Significant changes AFTER installation on ISS could still be noted in this article. - Rod57 (talk) 17:11, 20 August 2020 (UTC)