The life cycles of today’s military equipment can be extended to close to 100 years. The ability to manage equipment modification over this period has implications for the modification of equipment documentation as well. Functionality for the management of change has been provided within the overall architecture.
The functionality is enabled via the following:
• Change level - building block attribute that specifies the version of this particular building block. This is related to the version introduced in the BFN naming convention.
• Change - building block attribute with values add, modify/delete. This is meant to be used by an SGML differencing engine that will mark building blocks as to their change status from the last version. This attribute would be used to generate change bars in paper documents.
• Effectivity - building block attribute introduced to handle a variation in equipment where both versions of the product are being maintained in the field.
There might be a requirement for a supplier to be able to publish various versions of an information product. Certainly if the supplier had a robust configuration management system this could be accomplished. However, even those with a simple file based system could accomplish this by simply saving the following information:
• Information Product Plan;
• Catalog linking Information Product to all entities at time 1;
• Catalog linking Information Product to all entities at time 2;
• All versions of entities.
The following illustrates how a single information plan can produce two different versions of an information product provided the correct catalog and appropriate versions of entities are provided.
Producing Information Product Versions
In the above, the same information product plan will produce different version of the information product based on mappings in the input Catalog. The catalogs must be baselined versions, each representing a released version of the information product.