Friday, November 6, 2015

How not to use applicability

While attending the S1000D User Forum (UF), I sat in on the following presentation, Creating Applicability Statements that Work for the CCT.

I highly recommend to not following the guidance in this UF presentation regarding service bulletins:

  • It is mixing technical data with product configuration. The ACT's and CCT's roles are to provide the definitions of your product attributes and conditions. The PCT is designed to contain the actual instances of those attributes. Take the English dictionary as an analogy. The dictionary provides the definitions of the words. The actual instances of those words are in separate books, essays, and other English-based writings. What the UF presentation is advocating that for specific, special words, we should include all the various writings that use those words in the dictionary itself.

    The PCT is the only module type designed to capture product configuration. It exists to complete the XML-based model of applicability, but in practice, the PCT either is not used (it's use is optional), is stubbed just to contain the primary keys (to faciliate product selection in a viewer), or is dynamically generated from the product configuration database, not the CSDB.

    For example, for NAVAIR, we have one program that only stores aircraft identifiers in the PCT (called "BUNOs"). When the viewer is launched, the configuration database is queried for the current state of all the other attributes, including service bulletins (NAVAIR calls them Tech Directives) and passes the values to the viewer to initialize applicability state table.

  • PCT-based filtering does NOT require you to assert against the primary product key everytime. This is a strawman the UF presentation argues to justify the model it is advocating. When authoring applicability, you only need to assert on those attributes that are relevant. For example, if a given procedural step is only applicable if a given service bulleting is incorporated, all you need to do is the following:

    <applic id="a001">
      <assert applicPropertyIdent="SB-001"
        applicPropertyType="condition" applicPropertyValues="PRE"/>
    </applic>

    There is nothing that requires you to always have assertion against the product key. If a step is only dependent on certain conditions, you only need to assert against those conditions. Only assert on the entire product if a step is only applicable for entire product instances.

    When maintenance is started, normally the product being worked on would have been selected at the start of maintenance. Therefore, all the production configuration attributes and conditions (represented in the PCT--either statically or dynamically--see above), will have been set into the state table, including the incorporation status of SB-001 for the product.

  • The UF presentation increases the complexity of the viewing system in assigning values into the state table. Instead of just reading all the attribute values from the selected product from the PCT, the viewer now has to parse the <incorporation> section of the CCT, follow several extra ID references, and apply applicability filtering to determine SB values. This introduces unnecessary complexity in the viewing implementation when the same effect can be achieved with the simplier PCT-based model.

  • If you make the assumption that UF presentation regarding service bulletins is the better model, then why not use the model for all attributes? From a data modeling perspective, there is nothing special about service bulletin incorporation state that justifies it being handled differently than any other property (product attribute and/or condition) associated with a product. The UF presentation is basically advocating that for these set of properties, use a complicated way to assign their values, but for all other properties, assign them in the PCT.

The danger of that UF presentation is the presenter was very animated that this is the way you should do service bulletins, and for those in the audience that were new to S1000D, and less knowledgable of how applicability works, they can be lead down an operational path that is more complex and more expensive. Because of this, I voiced my concerns during the Q&A period.

Afterwards, I had a gentlemen come to me and thank me I did say something. He was fairly new to S1000D, and right after the presentation, he worried that the way they were going to use applicability was wrong, because a supposed expert was vocal in saying what was the right way and what was the wrong way. After I voiced my objections, he felt much better that he and his program made valid choices on how to use applicability.

Sometime later, I was informed this service bulletin applicability model was pushed for by Civil Aviation, hence, changes to the S1000D specification to support it. The push for the change came from a large aircraft provider to reflect how they managed their techdata and product configuration over the years. So, instead of the company changing their operations to use a better model, they basically pushed in changes into S1000D so they can continue as business as usual and state they are S1000D conformant.

2 comments:

  1. Hi Earl - I have a few questions - any chance we could talk?

    ReplyDelete
    Replies
    1. Just send me an email so we can share additional contact information. I can be reached at earl@earlhood.com.

      Delete