Origen del término "Bloque I", "Bloque II", etc.

No estoy seguro, pero creo que proviene de las adquisiciones militares de EE. UU., donde se refiere a los elementos reales (vehículos, sistemas de armas, etc.) que se producen y entregan. Por ejemplo, si desea que se construyan 10 barcos de una sola clase en 4 años, pero el último y mejor sistema de radar no estará disponible de inmediato, el contrato podría referirse a dos "bloques" de barcos, 4 barcos en el Bloque I con el radar más antiguo y 6 barcos en el Bloque II con el nuevo radar.

Para mí, tiene una connotación más concreta que "modelo" o "versión": el bloque es el conjunto real de elementos que van a un cliente, a diferencia de la imagen en el catálogo o el conjunto de dibujos de diseño.

No sé cuánto tiempo ha estado en uso, o dónde comenzó.

El primer uso militar que he visto es en referencia al misil tierra-aire Redeye , que tenía un "Bloque I" ya en 1963. El primer conjunto de satélites GPS contratado en 1974 y lanzado en 1978 se denominó "Bloque I", y la primera versión del Phalanx CIWS que entró en producción en 1978 es "Bloque 0", pero es posible que ese nombre se haya aplicado retroactivamente cuando la actualización del Bloque 1 se convirtió en realidad.

Sin embargo, los tres bloques de desarrollo de Ranger son anteriores a Redeye:

Ranger se diseñó originalmente, a partir de 1959, en tres fases distintas, llamadas "bloques". Cada bloque tenía diferentes objetivos de misión y un diseño de sistema progresivamente más avanzado. Los diseñadores de la misión JPL planearon múltiples lanzamientos en cada bloque, para maximizar la experiencia de ingeniería y el valor científico de la misión y asegurar al menos un vuelo exitoso.

USN también usa "vuelo" exactamente en el mismo sentido que "bloquear".

Según la "palabra espacial de la semana" de The Interplanetary Podcast ocho minutos y medio en el episodio 96 , proviene del "bloque de datos técnicos" del avión militar de EE. UU. (generalmente pintado en el lado de babor cerca de la cabina) El código del modelo toma la forma

$$\begin{matrix} Type&number&variant&version number\\ B&29&B&55\\ F&101&B&40\\ \end{matrix}$$ El número de versión se incrementa convencionalmente en 5 para cada revisión del fabricante, lo que permite incrementos únicos para actualizaciones de campo.

Consulte la página 26 en el documento Fundamentos de ingeniería de sistemas , publicado por el Departamento de Defensa de EE. UU., TEXTO SUPLEMENTARIO PREPARADO POR LA PRENSA DE LA UNIVERSIDAD DE ADQUISICIÓN DE DEFENSA: FORT BELVOIR, VIRGINIA 22060-5565, enero de 2001.

Aquí hay un extracto:

La adquisición evolutiva, por su naturaleza, representa una “adquisición dentro de una adquisición”. En un nivel, el gerente de ingeniería se enfrenta a la gestión y control del sistema a medida que avanza hacia su eventual configuración final y, en otro nivel, está la gestión y control de las modificaciones, o bloques, que se integran sucesivamente en el sistema a medida que se desarrollan. El sistema tiene requisitos asociados, líneas base, revisiones: los elementos normales de la adquisición de un sistema; sin embargo, cada bloque también tiene requisitos específicos, configuración y actividades de administración. El desafío para la gestión técnica es entonces garantizar que se apliquen buenos principios de gestión técnica en el desarrollo de cada bloque,

Tenga en cuenta que el diseño de ingeniería incluye requisitos funcionales y requisitos no funcionales, entre muchos otros requisitos. Los requisitos funcionales describen lo que debe hacer el sistema, y ​​estos requisitos generalmente se diagraman a través de uno o más diagramas de bloques funcionales . En mi mente el término bloquese asocia conceptualmente con los diagramas de bloques funcionales de un sistema porque esos diagramas describen visualmente (a) el conjunto de elementos funcionales que componen el sistema, y ​​(b) cómo se interrelacionan esos elementos funcionales, y (c) lo que el sistema puede y no puede hacer. (Nota: cada requisito funcional, y por lo tanto cada bloque funcional en un diagrama de bloques funcional, tiene múltiples requisitos no funcionales definidos, por ejemplo, requisitos de desempeño que especifican qué tan bien se debe realizar la función).

Como ejemplo, las naves espaciales Apolo se diseñaron en dos bloques: CSM Block I y CSM Block II ( referencia ). Esos dos bloques tenían requisitos funcionales (misión) sustancialmente diferentes y, por lo tanto, los diagramas de bloques funcionales que describen esos dos sistemas habrían tenido diferencias sustanciales.

Tenga en cuenta que no estoy diciendo que bloque signifique diagrama de bloque funcional ; su significado es mucho más amplio que eso. Pero en mi propia mente, como ingeniero, cuando escucho bloque , inmediatamente visualizo los diagramas de bloques funcionales del sistema porque esos diagramas me dan la visión general más rápida de la funcionalidad del sistema: lo que puede y no puede hacer.