This week we will be discussing the benefits of using Common Information Repositories (CIRs) in your S1000D Project. Ironically this topic and whether you have a need for CIRs to be implemented, should be driven from engineering and the LSAR. Most LSAR systems will identify parts, spares, consumables and required Warning and Cautions, so this data should have been identified as available to the project when you started documenting your Business Rules.

Now that we know we have the information available from engineering and we documented in our Business Rules that we should put this information into these S1000D objects called Common Information Repositories, how is this going to work in our S1000D environment and what benefits does it offer to the Authoring Team?

Firstly, a little history. CIRs were initially implemented into S1000D in Issue 3.0 as Technical Information Repositories (TIR’s) and were renamed to Common Information Repositories in Issue 4.1. These are individual data modules that act like mini databases of common information.

Prior to the implementation of CIRs, common or repeated information had to be entered into each individual data module. Manually writing the content into each data module did allow for the information to be displayed in the end users Interactive Electronic Technical Manual (IETM). If any of the information needed to be updated, the technical writers were required to update each and every data module with the same changes! This manual repetition of the content goes against the S1000D methodology of “write once, use many”.

In Issue 4.1 and v4.2 of the S1000D Specification, the following types of content can be placed into CIRs:

Functional Item Numbers;

Circuit Breakers;

Parts;

Zones;

Access panels and doors;

Organizations;

Supplies – List of products;

Supplies – List of requirements;

Support equipment;

Applicability;

Warnings;

Cautions.

As we can see from the above list, the information that can be stored in the CIRs is extensive. If we consider our own documentation, I’m sure that there are many instances where duplication of content can be located.

Once the CIR content has been created, the technical writers can then reference this information in multiple data modules. If any of the information needs to be updated, the update is applied once in the CIR. Then when a delivery is generated for the end users, the updated information from the CIR is automatically reflected in each of the data modules.

As mentioned at the start, the project makes the decision if CIRs are to be used and if they are, which types of CIR’s will be needed. This information is documented into the project’s Business Rules.

Once the decision is made to implement CIRs the project needs to determine how to create the CIRs. This information can be created from an LSAR or, if the project does not have access to an LSAR, then the CIRs would be written manually like any other data module. Either the CIRs should be generated prior to the development of the technical data modules, so that the CIR content can be referenced.

If the project makes a decision at a later time to implement CIRs, common content previously written manually in each data module will need to be replaced with a reference to the CIR.

Based on the above information why would a manager think it is OK to not utilise CIR’s or look at implementing them later?

Have we educated our Manager on the data re-use that can be achieved by using CIRs? Has the Program Management analysis shown how much time (money) can be saved in writing when you write CIR’s first, and how much time (money) will be saved in the future when updates occur on this common content?

Let’s make sure we educate our Managers on exactly what a CIR does, along with the statistics and costs (shortfalls) associated, when we don’t work with a set of CIR’s!Reeta Nye
Senior Consultant
OneStrand Inc.