Friday, November 6, 2015

How not to use applicability

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:

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.