Back in the mid ‘90s when I was first introduced to aerospace technical documentation, I couldn’t help but be thoroughly impressed by the sheer sophistication of technology being applied. While the document management systems I’d worked with before seemed quite hi-tech (scanners that could deskew pages and store them on multi-spindle optical jukeboxes), this was serious business; content would be strictly separate from formatting, with proper structure and rules enforced. References would be validated; metadata would take care of tracking revisions and effective configurations. No scanned images anymore, but advanced vector formats supporting hotspotting.

The benefits were obvious to more than just ambitious engineers. In addition to the underlying SGML standard, suitably complex in itself and laden with arcane features, there was “The Spec” (a.k.a. ATA Spec 2100, having recently graduated from a digital appendix of the paper based Spec 100). This made sure that the brilliance of generalized markup would be harnessed to address the needs of the aviation industry.

While this all seemed quite impressive at the time, the question now remains how did this seemingly unlimited potential for documentation actually work in practice? A couple of decades later, I’d like to share some of my observations and thoughts here.

One Spec to Rule them All…

I’ve had the opportunity to work with a good number of aerospace customers across the globe and I’ve encountered as many ways of interpreting and implementing The Spec, all of them deviating more or less from the standard. This was equally perplexing and frustrating – in some areas The Spec wasn’t comprehensive enough to support real life projects, and was too restrictive in others. Looking back, some patterns appear to be consistent:

First, there are different requirements and “worldviews” among user types:

  • Airframe manufacturers
  • Engine manufacturers
  • Component manufacturers
  • Operators
  • Maintenance/Repair shops

Next, specific domains have different focus and priorities:

  • Maintenance
  • Repair
  • Functional Testing
  • Airworthiness

Lastly, from the technology point of view, the nature of data in various publication types requires different handling:

  • Procedural/Descriptive – best match for the hierarchical SGML/XML support
  • Parts Catalogs – database extracts wrapped in SGML
  • Fault Isolation – decision trees with specific requirements
  • Wiring Diagrams – large and complex graphics wrapped in SGML/XML

Use a Bigger Hammer!

Lessons learned are reflected in a succession of iterative updates to The Spec that essentially created a new legacy of older/superseded versions, requiring either special handling or migration to a newer release.

Sadly, current fragmentation of The Spec is not primarily caused by its evolution, but by the “creative” adoption by the industry. After all, in many respects The Spec is a set of recommendations and guidelines rather than a strict, normative specification. This leaves a lot left to interpretation, and in many cases projects implemented arbitrary extensions while dropping any #REQUIRED bits that didn’t fit at the time. As things evolve, most manufacturers have different programs documented to a different standard. This leaves major operators struggling to consolidate what was supposed to be the “same” information for dozens of equipment types and variants from various sources.

Beware of Graphic Content

Going beyond text, there are countless opportunities to improve technical documentation with graphics and multimedia. Primary standardized illustration format is CGM. Is it just a coincidence that it never became widely adopted and lacks support in current web browsers and operating systems? Even the W3C backed WebCGM initiative failed to promote CGM as an easily distributable format. In fact, last update from W3C is: “The WebCGM Working Group is now closed”.

While the technical standards of the textual part evolved dramatically (SGML was simplified into XML and supplemented with a multitude of complementary technologies enabling transformation, linking, querying and form processing), technical illustrations lack a format or migration path that would facilitate their digital consumption on the current and emerging devices.

Bike of Reference

Although The Spec is sprinkled with snippets and fragments of markup to illustrate its constructs, these come from different sources and aren’t always consistent. Any claimed compliance with The Spec cannot be easily verified and there is no accepted comprehensive reference that could be used for that.

While the S1000D specification introduced a sample data set (Bike), it’s not intended to be a conformance test tool – partly since it only covers a limited scope of the data modules and markup options.

Similarly there is no consistency in the visual presentation of data. Most implementations are based on the original ATA Spec 100 guidelines. Again, for a period of time sample stylesheets were distributed with S1000D spec, without the goal of serving as a reference. This initiative has been discontinued.

Did you say COTS or Cost?

One of the main goals of standardization is improved efficiency and lowered costs. Indeed, most customers are looking for commercial off-the-shelf (COTS) solutions, as the cost of developing bespoke systems is prohibitive. So you pick a product to match your requirements and budget, load your data and you’re in business, having saved a lot of money, right?

One could argue about semantics of configuration versus customization, it seems that after decades of experience in the industry, what best vendors can offer is a flexible, configurable, and extensible platform that will accommodate countless existing variations and grow with the ever-evolving requirements.

Now What?

So The Spec is imperfect and slow to evolve. At the same time, the industry pushes for solutions that go beyond standardizing technical documentation for its own sake – it needs to be integrated into related business areas ranging from engineering changes to maintenance planning, material provisioning, and repair job execution.

Fortunately, current technology gives us powerful tools to transform and repurpose data, and customers with an investment in structured formats have a distinct advantage. Starting with the existing foundation, one exciting opportunity is to tap into the latest evolution of web technologies driven by HTML5, expanding the user space to current and upcoming mobile devices. Google Glass, anybody?