Tuesday, May 08, 2018

Component Maintenance Publications

In the last 12 months there have been two specifications for Component Mainteance Publications derived from S1000D Data Modules.
  • Airbus CDIM for the A350 Aircraft
  • ATA Spec 1000BR_4.2 (aka Civil Aviation Busines Rules for S1000D Issue 4.2)

Airbus CDIM for A350 aircraft.

Last year Airbus brought out their specification for creating S1000D Component Mainteancne Publication (CMP) for the A350 aircraft. Their specification clearly was designed to handle how they wished S1000D to be used for their aircaft. The requirements reflected that need and dpecified folder structure, the location of the various files, the Page Layout, the combinations of Data Modules and the generation of divider pages between topics.

I found it verhy intersting seeing how they had produced the Business Rules and the migration into their BREX. They clearly indicate how Airbus want their documents to look and feel.

Clients of ours needed to produce the CMP documents in PDF form for Airbus and we were able to help them in this regard.

The number of choices that our clients had regarding layout, what was to be displayed, and the structure were much reduced which made the cratiion of an application very much easier. Compared with our standard building programme which has umpteen options regarding what is dispalyed and where it is located, and even the structure the A350 building programme is a considerable sawn down affair. As long as the client gets the files in the right place and has the attributes set to the right values building the publkication is very much a single button operation.

Incorporating the Brex into our Editing programme was interesting and testing was even moer interesting. Going througbh the Brex step by step to check is an omission was handled correctly was a real test on the knowledge of where the various elements were located in the schema.

ATA Spec 1000BR_4.2

We were wondering if ATA would come up with an all can do CMP specificatio and they have. The ATA Spec 1000BR_4.2. This is very much a more general set of Business Rules as one would have expected, i.e. A350 Specific against any Aircraft using S1000D Data Modules.

Having been through the Brex incorporation process onece it was interesting to see what differences there were. As expected there were a not that many. It was also interesting to see how the BREX had been written which only confirmed what we had already thought - more than one way of doing it!

We did notice that there were a few problems with the BREX, mainly in inconsistencies. One example was where the rule specifically stated that an element was not to be used but the explanation indicated that it should. Incorporating this Brex into our Editing programme took less time as a result of our prior experience. Testing was just as interesting - find out where an element should have been if it was not excluded.

Just for fun and learning opening one of the Bike Pack data modoules with the ATA Business rules switched in to see how long it took to get it compliant gave an insight into what was going to be invovled for a company creating standard S1000D DMs and converting them to ATA. To be honest it was not that painful and didn't take that long - but that was only one DM and not hundreds.

BREX Checker

What has come out of this is the need for a Brex checker which would work natively with S1000D Brex data modules. I was amazed at the speed at which this worked, even on a folder full of files. Of course the interpreting the report is an acquired skill and it remains to be seen whether the average auhor will be happy to do this or is a nominated person going to be given the job.

A report from one of our clients indicates that the delivered data modules are not always looked at by the same person at athe other end. This has resulted in Data Modules tavelling backwards and forwards with different comments each time. We had no way of knowing what was being used for checking.

Oveall the use of S1000D for comercial aircraft is reaching an interesting stage but where a company is providing S1000D Data Modules for both military and commercial aircraft there could be conflicts especially where different companies are involved - after all an aircraft power supply (just an example and not real life to us) is likely to be used on many aircraft.

Tuesday, October 11, 2016

Working with Warnings and Cautions

Way back When

We have just been involved in the handling of Warnings and Cautions and what was being asked for set the OGCs (Old Grey Cells) grinding away trawling up the early days of S1000D. To be precise Issue 1.6 (Change 6 as it was known then). I remember that the UK MoD spent quite a time looking at just what should happen when a Warning was being used.

Lets put on one side the IETM action on being shown a Warning. Although the method determined on was a bit of a contentious issue with the end users it was the only way to make sure that it was put in front of them. Whether they read them is, of course, another matter.

The mechanics were that one referenced a Warning in a Data Module and each warning should be located in a separate Data Module. Indeed the DefStan group created quite a number of special Hazard Warnings and Cautions which were related to specific situations. The mechanism was straightforward. Reference a warning/caution and it was brought up in front of the user. Each Warning or Caution was in its own Data Module. Easy! Easy to find and easy to modify.

Now

OK, so I know that you don't have to use everything that is provided within S1000D, but who thought up the 'latest mechanism' I wonder. You know, the one which stuffs all the warnings in one or more repository files which then has to be referenced (file and warning id) which is then inserted on the fly.
We have two problems here as far as I can see.
  1. You have a file which contains theoretically hundreds of warnings. So when it needs updating first work out which file contains the one that you need to change and then find it in the file itself.
  2. Just how easy it is to share the warnings between projects?
By having a single warning in a data module the question of updating is much easier, and the ability to share with other projects is also easier.

The question of sharing Data Modules form me was addressed very early. When I was working for another company we had the MoD project manager for a large item of equipment visit us. He has been told that all the legacy Data Modules for some of the equipment which was common across many platforms had to be converted to the latest issue at that time. The reason was that the different issues were incompatible. We were able to demonstrate within 10 minutes that we could create an IETM using Data Modules from the three issues available at that time and they worked perfectly well. So if this is being held up as the reason for the new system it doesn't wash.

Scrutiny

A lot of the problems which occur due to changes which have not, from the end users point of view, been thought out. In a modified system this problem could very easily be solved by making available to a wider audience the proposed changes before they became 'caste in stone'. It is very easy to place a time limit on the 'consultation' period. I realise that this time would perhaps delay the publication of new issues but overall that would be time well spend.

I know that I did mention this mechanism and pointed to the W3C way of working as a possible solution a long time ago. It is certainly a lot easier and quicker than a British or any other standard institution mechanism.

The last time there was deathly silence so I suppose that the same will happen again.