Origin of term "Block I", "Block II", etc

Question

In NASA spacecraft development, subsequent versions of a design are referred to as "Block 1", "Block 2", etc.

What is the origin of this naming convention? Why not just call them "Version 1", "Version 2" (or "Model 1", "Model 2")?

Answer 1

I am not sure, but I think it comes from US military procurement, where it refers to the actual items (vehicles, weapons systems, etc.) being produced and delivered. For example, if you want 10 ships of a single class built over 4 years, but the latest and greatest radar system won't be available right away, the contract might refer to two "blocks" of ships, 4 ships in Block I with the older radar, and 6 ships in Block II with the new radar.

To me, it connotes something more concrete than "model" or "version" -- the block is the actual set of items going to a customer, as opposed to the picture in the catalog or the set of design drawings.

I don't know how long it's been in use, or where it started.

The earliest military use I've seen is in reference to the Redeye surface-to-air missile, which had a "Block I" as early as 1963. The first set of GPS satellites contracted in 1974 and launched in 1978 was referred to as "Block I", and the first version of the Phalanx CIWS that went into production in 1978 is "Block 0", but that name may well have been retroactively applied when the Block 1 upgrade became a thing.

Ranger's three development blocks predate Redeye, though:

Ranger was originally designed, beginning in 1959, in three distinct phases, called "blocks". Each block had different mission objectives and progressively more advanced system design. The JPL mission designers planned multiple launches in each block, to maximize the engineering experience and scientific value of the mission and to assure at least one successful flight.

USN also uses "flight" in exactly the same sense as "block".

Answer 2

According to The Interplanetary Podcast's "space word of the week" eight an a half minutes in to episode 96, it comes from the US military aircraft "technical data block" (usually painted on the port side near the cockpit) The model code takes the form $$\begin{matrix} Type&number&variant&version number\\ B&29&B&55\\ F&101&B&40\\ \end{matrix} $$ The version number is conventionally increased by 5 for each manufacturers revision, allowing single increments for field upgrades.

Answer 3

See page 26 in the document Systems Engineering Fundamentals, published by the U.S. Department of Defense, SUPPLEMENTARY TEXT PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS: FORT BELVOIR, VIRGINIA 22060-5565, January 2001.

Here's an excerpt:

Evolutionary acquisition, by its nature, represents an “acquisition within an acquisition.” On one level, the engineering manager is confronted with the management and control of the system as it progresses to its eventual final configuration, and,on another level, there is the management and control of the modifications, or blocks, that are successively integrated into the system as they are developed. The system has associated requirements, baselines, reviews—the normal elements of a system acquisition; however, each block also has specified requirements, configuration, and management activities. The challenge for technical management then becomes to ensure that good technical management principles are applied to the development of each block, while simultaneously ensuring that the definition and control of requirements and baselines at the system level include and accommodate the evolving architecture.

Note that engineering design includes functional requirements and non-functional requirements, among many other requirements. Functional requirements describe what the system must do, and these requirements are typically diagrammed via one or more functional block diagrams. In my mind the term block is conceptually associated with a system's functional block diagram(s) because those diagrams visually describe (a) the set of functional elements that comprise the system, and (b) how those functional elements interrelate, and (c) what the system can and cannot do. (NB: Each functional requirement—and therefore each functional block in a functional block diagram—has multiple non-functional requirements defined for it—e.g., performance requirements that specify how well the function must be performed.)

As an example, the Apollo spacecraft were designed in two blocks: CSM Block I and CSM Block II (reference). Those two blocks had substantially different functional (mission) requirements, and therefore the functional block diagrams that describe those two systems would have had substantial differences.

Note that I am not saying that block means functional block diagram; its meaning is much wider than that. But in my own mind, as an engineer, when I hear block I immediately envision the system's functional block diagrams because those diagrams give me the quickest overview of the system's functionality: what it can and cannot do.