An article with the above title has been written by Henry Canaday and recently published in Aviation Week in which the migration from Paper based delivery to digital delivery of aviation publications is discussed. What is very interesting here is that the views of several large companies involved in aviation have been obtained and are reported.
Of course ATA iSpec 2200 is mentioned as one would expect but the S1000D Specification is also included.
Early in the article Ray Marzulo from Boeing is quoted as saying that iSpec 2200 is being used for engineering and maintenance data. He does not actually say what S1000D is being used for. However he is reported as stressing that "Standards are the glue necessary to avoid one-off solutions".
Common Standards
An interesting comment comes early on in the article where Canaday indicates that "there has been some resistance to common standards". This resistance is apparently coming from companies that would like their own current definitions to industry standards.
I guess that we have all seen companies coming up with their 'marvelous solutions' which will answer all their requirements. Very soon after the production of the solution it is discovered that there are drawbacks to "ploughing their own furrow" when it comes to publications. Information supplying companies can become a bit militant if they have to provide material to a special formulation for just one client.
One thing that does concern me, and I think that this affects not only iSpec2200 but potentially S1000D, is that some companies are specifying the use of certain structure options which are specifically frowned upon in the parent specifications. This obviously relates to Canaday's comment above about resistance.
Migration from iSpec2200 to S1000D
Clearly, as indicated in another posting on this Blog, it is going to be some years, if ever, that the main Aircraft Manufacturers will switch from iSpec2200 to S1000D. With the legacy situation being what it is, and the length of time that some aircraft remain in service, it will not make commercial sense to convert from one to the other for all but some new (very new?) aircraft types.
The way output is going
Included in the article is a couple of paragraphs about Rolls Royce. They have been moving from paper output to PDF files in the first instance. The sort of numbers quoted vary from 520 different publications for 12 engines to 3000 customer locations world wide. Their main thrust in moving to PDF files has resulted in more than 800 customers using their Aeromanager system which is their on-line system. This is very impressive from the odd bits that I have had demonstrated to me. In time no doubt the underlying standard used for authoring will move gradually to S1000D, after all there are large areas of Rolls Royce which are heavily involved in this specification.
At the heart of all systems to be used on long term projects has got to be that of Applicability. The commercial Aerospace industry is well versed in this area. In the early 90s I was involved in the design and creation of a system that could produce a customised Handbook for an aircraft which would then be delivered to a particular Airline. In this system all sgml files contained all the necessary information for a particular part/system and this was 'cut down' in accordance with the configuration database content. I have a feeling that configuration control is very good in the civil aerospace industry but severely lacking in the rest of industry, including the services.
Consistent not Perfect
And finally, one phrase jumped out of the article at me. Towards the end of the Article Northwest Airline's Tim Larson, who is also head of the ATA's e-Business steering group, is quoted as indicating that there are large gains to be made in having a common document delivery method for all aircraft. This is going to ensure that there is a good reuse of information in areas such as Work Cards. He urges manufacturers to be consistent, not perfect in developing the new standards. Clearly this is also where Business Rules are going to have some influence - consistency is king - without it very little data can be shared between projects.
However, he seems to have made a statement which rings slight alarm bells with me. "S1000D has not yet been used for commercial aircraft". This is not quite what I have been led to understand. He then goes on (more bells?)...
"There are still some mismatches between S1000D and ATA standards. And S1000D is still a moving target as version 3.0 replaces 2.3."
Well! We do know that S1000D 2.3 has not yet hit the streets and whilst it may be a moving target, the majority of the S1000D specification remains essentially well established. But what about the 'mismatches' issue raised by Larson. In a slightly simplistic approach from 30+ years in publications there are bound to be mismatches, they are different specifications generated for different reasons.
To be honest, compared with S1000D, generating content using the ATA iSpec2200 specification is far from straightforward for the author where I have found all sorts of 'fudges' are required to give the necessary look and feel required by the specification. Of course there are generations of authors who have grown up on the ATA specifications and so they are used to them but the structures are far more straightforward in S1000D. What is perhaps not quite straight forward are the underlying structures which surround S1000D, not forgetting of course that this specification was initially intended for electronic delivery only and not for paper/PDF output.
And Finally Finally
In spite of my comments above I found this article to be very informative.
If anyone has read a recent article that they think is likely to be of interest to the S1000D world please let me know, or even better, write something about how it strikes you.
No comments:
Post a Comment