Integration study for maintenance plan JAS 39 Gripen

(1)

BACHELOR THESIS IN

AERONAUTICAL ENGINEERING

15 CREDITS, BASIC LEVEL 300

Integration study for maintenance

plan JAS 39 Gripen

Author: Petter Norin Report code: MDH.IDT.FLYG.0201.2008.GN300.15HP.M

(2)

ABSTRACT

To be able to have control over the maintenance with today’s advanced fighter airplanes a durable system for technical publications is a must.

This thesis is focused on problem areas when implementing PumaX for developing the maintenance plan for the Gripen fighter. Experience with PumaX as a tool exists and these have been analyzed to define specific problem areas. Because of too great extent four items were selected – customization, faulty data, quality assurance and serial status.

Through examination of previous experiences theoretical solution suggestions has been developed. Schematics for corrective actions and a separate application were done to take care of the customization. In the application it was revealed that possible faulty data could also be corrected. An already existing web application within SAAB could be used for the review process. In this way any document in PumaX is quality assured and no new application has to be introduced for the task. After an analysis of how the serial status concept could be implemented it was revealed that not all functions in PumaX could be used when applying the serial status.

SAMMANFATTNING

För att ha kontroll över underhållet med dagens avancerade stridsflygplan ett hållbart system för tekniska publikationer är ett måste.

Denna uppsatts har fokuserats på problemområden vid införande av PumaX vid framtagande av underhållsplan till Gripen. Erfarenheter med PumaX som verktyg finns och dessa har analyserats för att definiera specifika problemområden. På grund av omfattningen valdes fyra punkter ut - kundanpassning, feldatahantering, kvalitetssäkring och seriestatus.

Genom att undersöka tidigare erfarenheter har teoretiska lösningsförslag arbetats fram. Scheman för avhjälpande åtgärder och en separat applikation gjordes som tar hand om kundanpassningen. I samma applikation kom det fram att eventuell feldata likaså kunde korrigeras. En redan existerande web-applikation inom SAAB kunde användas för kvalitetssäkring. På detta sätt kan vilket dokument som helst i PumaX kvalitetssäkras och ingen ny applikation behövdes introduceras för uppgiften. Efter en analys av hur seriestatuskonceptet kunde implementeras kom det fram att inte alla funktioner i PumaX kunde användas vid applicering av seriestatus.

Date: 27 June 2008

Carried out at: SAAB Aerotech Advisor at MDH: Tommy Nygren

Advisor at SAAB Aerotech: Thomas Ström Examinator: Gustav Enebog

(3)

PREFACE

This thesis is a result of the demands of making the development process for the Gripen maintenance plan more efficient and standardize how it is created.

I would like to thank all people working with technical publications at SAAB Aerotech in Linköping for all guidance and encouragement. A special thanks to my mentors Thomas Ström SAAB and Tommy Nygren MDH.

Linköping, June 2008 Petter Norin

(4)

NOMENCLATURE

A/C Aircraft

ACS Aircraft Computer System

AECMA Association Européenne des Constructeurs de Materiel Aerospatial AIA Aerospace Industries Association

ASD Aerospace and Defence Industries Association ATA Air Transport Association of America

CRASS Change request analysis support system CSDB Common Source Database

CZ Czech Republic

DTD Document Type Definition ETPS Empire Test Pilots’ School

FMV Försvarets Materiel Verk (Sweden's Defence Materiel Admistration) GPS Gripen Publications Standard

HU Hungary

ILS-DB Integrated Logistic Support Database MAD Maintenance and Availability Data Report

NG Next Generation

OC On Condition

PUB94 Publikationsguide 94 (Publicationguide 94)

SE Sweden

SGML Standard Generalized Markup Language UAV Unmanned Aerial Vehicle

UE Utbytes Enhet (Changeable unit)

VB Vid Behov (OC)

XML eXtensible Markup Language

(5)

Chapter 1 GENERAL INTRODUCTION

1.1 Background

SAAB Aircraft Services section airworthinesspublications intend to change computer application for developing and maintaining their maintenance plan for the Gripen fighter. The maintenance plan has a key role in the whole publication package and because of this it is important that it is handled correctly.

The new application is PumaX and has already been implemented with the maintenance plan for SAAB’s only export customer - South Africa. The maintenance plan is one of many technical publications which are being integrated into PumaX. Because of the amount of data and the design and function of PumaX the transition is tricky and the solution for South Africa is more or less a semi-solution with much to desire.

1.2 Objective

This thesis will focus on some already discovered problems with the implementation of PumaX and how they can be solved. These problem areas have in some extent been discovered in the development of the maintenance plan for South Africa. The idea is by examine the work flow analyze and highlight where enhancements and improvements can be done.

The main goal with the introduction PumaX is to automate most of the data input. In this way much time consuming work with hardcoding can be reduced.

1.3 Problem formulation

Known problems today:

• Where and how will the customization be done? • Input data from ILS-DB being missing or false. • How will the quality assurance be carried out? • Serial status concept hard to implement.

Apart from these there will also be an analysis of the work process PumaX will introduce and how this will differentiate from the one today.

(8)

1.4 Limitations

Due to the fact that a more extensive study will be carried out by SAAB this thesis will be limited to problems defined in 1.3. If bigger unknown problems will rise during the work process these will be limited to just acknowledgment for further studies.

1.5 Introduction gripen maintenance

The maintenance plan is one of the technical publications which influence JAS 39 Gripen’s airworthiness. Therefore it is important that the data specified is adequate and up to date, or else in worst case scenario it will result in a grounded aircraft.

In the beginning of the Gripen era one of the requirements was to minimize the operational costs by half in comparison with the previous Viggen system (See figure 1-1)

Figure 1-1. Production and development cost versus Operational and maintenance cost in respect to previous systems.

To fulfil this Gripen bases preventive maintenance activities on a principle named MSG3. MSG3 is a tool to guide and optimize maintenance activities and to find a balance between corrective and preventive maintenance without jeopardising air safety. It is also used to keep the maintenance and operational costs at minimal. Much because of this Gripen has become famous for being easy to maintain at a low cost with a high availability in comparison with its competitors.

(9)

1.6 Publication standards

When creating a maintenance plan you have to follow a certain publication standard, in SAAB’s case 1000D or ASD/AIA (Aerospace and Defence Industries Association/Aerospace Industries Association) S1000D. SAAB and FMV (Försvarets Materiel Verk (Sweden's Defence Materiel Admistration)) then makes an interpretation of the standard and compile an own standard package. AECMA (Association Européenne des Constructeurs de Materiel Aerospatial) 1000D becomes PUB94 and ASD/AIA S1000D the GPS (Gripen Publications Standard). In this way each manufacturer of maintenance plans has the same standard as base which makes it easier for the different users. The difference between PUB94 and the GPS is that PUB94 is customized for FMV meanwhile the GPS is more natural towards new customers. The standards specify how to write technical publications, i.e. what font size and the design of the publication.

FMV have so far only accepted the old PUB94 standard for their maintenance plan, as can be seen in figure 1-2. South Africa however has accepted the new S1000D standard. In February 2008 Thailand signed a contract for buying six Gripen fighters but there is no decision made for what type of standard they will be using.

Document Aircraft type / user Standard

J0 (SAAB) Test aircrafts PUB94/GPS

J1 (FMV) 39A, 39B SE, ETPS PUB94

J2 (FMV) E17 39C/D PUB94

J3 (FMV) 39C, 39D SE, HU, CZ PUB94

and 39A, 39B E15:5

J4 (ZA) 39C, 39D ZA GPS

and future customers

Figure 1-2. Definition of document types

The goal is to transfer all J3 and J0 documents into PumaX. J1 and J2 will be phased out due to upgrade to the newer 39C and 39D version of Gripen.

(10)

1.7 Design of the maintenance plan

The maintenance plan can be split into three parts, maintenance, configuration and serial status.

1.7.1 Maintenance

In the maintenance chapter information about the maintenance is described such as when tasks are supposed to be carried out, who is doing it, what type of publication that describes the work and where it is done.

To be able to have control over each article they are grouped material wise, for an example all articles that have maintenance affecting the landing gear are one group. The civil aviation has a similar system with ATA (Air Transport Association of America) chapters.

There are about 30 groups with different material types in the maintenance plan today. In Figure 1-3 a part of group 38 -“HJÄLPKRAFTSFÖRSÖRJNING” is illustrated.

Figure 1-3. Maintenance object J1-A-38-32-01-00A, KONTROLLENHET

By the figure it can be seen that it is a J1 document (See marking number 8) and according to figure 1-2 it must therefore be applied to 39A/B Sweden and ETPS (Empire Test Pilots’ School).

(11)

Maintenance objects and documents are codified according to PUB94 (See marking number 1), in this case KONTROLLENHET has object code J1-A-38-32-01-00A. Definition of the whole code can be seen in APPENDIX A , for more definitions regarding the maintenance plan see figure 1-4. There exist about 3600 maintenance tasks in each maintenance plan today for which the main part (about 80%) is OC (On Condition) based.

1 The object code for a specific maintenance, connected with an article in the configuration chapter

2 Denomination of the maintenance object, under a mounting place can be specified (i.e.10KD)

3 Interval for each task (i.e. VB (Vid Behov) or Eng “On Condition”)

4 Where and on what the task is to be maintained, i.e. if it has to be removed from the A/C

5 Tasks are codified with a number i.e. -320A which is a control, under a text is explaining the task

6 Defines the maintenance publication that describes the specific procedure

7 The material group denomination

8 The AECMA code for the publication

9 For what version of A/C the maintenance object is valid and how many. UE defines the unit (i.e. if it is changeable)

Figure 1-4. Table of maintenance plan information

1.7.2 Configuration

For information about which article that is connected to its corresponding maintenance there is a configuration chapter (See figure 1-5). In this way it can be seen what type of maintenance is needed for each type of article. The reason for not placing this information in the maintenance chapters is that it could be too much information in the same place.

Figure 1-5. Configuration object J1-A-38-32-01-00A, KONTROLLENHET

The KONTROLLENHET with object code J1-A-38-32-01-00A can once again be found. According to figure 1-5 there are two KONTROLLENHET which can be installed on the aircraft with that type of maintenance. Other information such as its vendor and supplier number is also being displayed.

(12)

It also says “Se seriestatus” so it can be found in the serial status chapter. It can be different object codes on the same denomination. If so there is some difference between them that affects the maintenance, i.e. different intervals.

1.7.3 Serial status

Gripen is a cutting edge airplane and thereby articles are being changed continuously. It can both be hardware and its software. To keep track on which hardware and software that fits with the correct aircraft there is a third part – serial status.

Even thought Gripen only have been made in six versions, see figure 1-6. The serial status concept makes it some what more complicated. Because of differences between airplanes some articles may only fit in certain individuals. Gripen is upgraded in intervals because not all aircrafts can be modified at the same time, in this way there are different “versions” or serial status of the aircraft. The serial status is defined in a nine figure code (see APPENDIX B )

39A Single seater

39B Twin seater, no AKAN

39C Single seater, NATO compatible (English MFD text, air-refuelling etc)

39D Same as 39C but twin seater and no AKAN.

39E/F(NG)

Different landing gear setup, more fuel capacity, stronger engine, new avionics.

Figure 1-6. Versions of Gripen

In figure 1-7 KONTROLLENHET is valid for four statuses. However there is another edition of the aircraft (first four digits), 1550- (39A) and 8550- (39B).

(13)

Figure 1-7. Edition 1510-, 8510-

One other important information is also seen in the figure - the modstatus. This is an identification code for the software the article has.

In the beginning of the serial status chapter there is a summary of the statuses which is applicable for the particular edition and aircrafts (see figures 1-8 and 1-9).

(14)

Figure 1-9. Edition 1550-, and 8550-

In the 1550-, 8550- edition only F5543-001270 is valid (See figure 1-10). It has been some kind of major modification on the aircraft so it has been given a new edition and only the new KONTROLLENHET are allowed to be mounted.

Figure 1-10. Edition 1550-, and 8550-

When the flight technician is changing an article he first has to look in the aircrafts computer or logbook to identify what serial status the aircraft has. Then look in the serial status chapter to see what article he is suppose to use.

Not all articles have serial status, most likely the articles in the serial status chapter have some kind software in it (as in the example above). The software is easier to change than the hardware and therefore it can be different versions on the same hardware. The software is categorized depending of where the software can be changed. Category 1 is loadable software files that can be changed by a flight technician. Category 2 is software that must be changed on a central workshop.

(15)

On SAAB there exist around seventy different statuses, so in a sense there are seventy different versions of Gripen. To keep track of all these is not an easy task.

So why use this complicated system? Most American fighter manufacturer has another system - updates in blocks. Within a specific interval all aircrafts in the block are updated and then nothing is done until the next block change. The advantage of this is that it is easy to have control over what is in the aircrafts. It also makes it easier to offer customers update packages. However, when doing as SAAB with serial status there can be a continuous flow of upgrades. Aircrafts are in larger extent in top shape and individual customization can more easily be done.

1.8 Summary maintenance plan

It is not difficult to grasp the complexity with integrating the maintenance plan into PumaX. There is a lot of data which is gathered from different databases with occasional faulty cooperation. The compilation is instead man handled with much time consuming work.

The three chapters described above are the main pieces in the maintenance plan. A simplified design diagram is illustrated in APPENDIX C . There is however also other smaller chapters but are being left out in this thesis due to limitations stated in chapter 1.4.

1.9 Work process FMV maintenance plan

Since the start of operating Gripen in 1994 there has been little change in working method of the maintenance plan. Looking back SAAB and FMV have been working very closely when developing a new aircraft and FMV have had great influence on the maintenance plan because of customer demands. Back then there was only one customer in mind – Sweden. This has ended up with a FMV maintenance plan for countries that have received Gripen from FMV - Hungary and Czech Republic. So in a sense there is only one customer for J3 maintenance plans – FMV. When South Africa announced a purchase of 26 Gripens SAAB could disregard from FMV demands and develop an own maintenance plan – the J4 version. But why change something that has worked for a decade? SAABs’ interpretation of the maintenance plan differentiated too much from FMV so the only right thing was to make an own export maintenance plan or a “SAAB version”.

1.9.1 Data input

There are a lot of different sources of input into the maintenance plan. This creates great difficulties. When an update to the maintenance plan is needed each source of data affecting the maintenance plan has to be gathered in time so it all can be “stitched” together.

Maintenance data (illustrated in figure 1-3) are being held in a database called ILS-DB (Integrated Logistic Support Database). ILS-DB is updated when i.e. changes to the maintenance is required such as an interval. These changes can be based on a variety of reasons such as requests from suppliers, MSG3 or the airforce.

(16)

engineer responsible for each material group is making an export of data from ILS-DB for a particular customer’s maintenance plan which ends up in a document called MAD (Maintenance and Availability Data Report). The MAD is analysed when updating the maintenance plan since it is more or less a reflection of ILS-DB. More about ILS-DB is being discussed in chapter 2.2.

The configuration and serial status data (illustrated in figure 1-5 and 1-7) is stored in a database called artemis. This is given out by a section on SAAB responsible for determine the articles and statuses for which they are valid. The output is gathered in a document called “configuration list”.

All software has to be defined in the maintenance plan and is being done from an ACS (Aircraft Computer System) list. When different software can be loaded into the article these need to be illustrated in the serial status chapter (modstatus). So when there are changes to the serial status a new ACS list has to be reviewed. In the example for KONTROLLENHET there were no loadable software files (category 2), it has however software (category 1) and therefore it needs to be defined in the serial status chapter. The ACS list is worked on in a system named sysman.

The last two documents affecting the maintenance plan is the type and system reports. Here the systems are being described and sometimes it has influence on the maintenance plan. If so it has to be checked if it has been incorporated from the MAD report.

If suggestions from the airforces not have been affecting any of the above mentioned documents they end up in CRASS (Change request analysis support system), which must also be taken into consideration.

1.9.2 Work procedures

All datasources described is affecting the maintenance plan and the engineers responsible for assembling the plan need to be very careful not to miss any data when implementing.

Therefore before the data can be gathered the documentation has to be reviewed in respect to the maintenance plan. If any wrongness is found this need to be brought to the attention for the issuer. The MAD and configuration list are reviewed in a web-based system called teamcenter. Documents are being sent in a loop to people affected by the document. If it is an OK from all reviewers it is finally issued. More about the review and quality process can be read in chapter 4.

The maintenance plan is written in an old UNIX environment called interleaf. Data are being hardcoded in SGML (Standard Generalized Markup Language) tables which basically looks like a template for the maintenance plan. The material group responsible sends a “change record” with the MAD report. In this way it is easy to see what changes that have been made since the last issue.

In the configuration list some changes are summarized in the beginning, but to secure that no data will be missed it is often cross read. All other documentation (ACS list, CRASS, System reports) need to be cross read to find out if there are any changes that have to be implemented.

(17)

Once all maintenance chapters have been updated they are sent back to the responsible for each material group. In this way the issuer of the MAD report secures that the changes he has made in ILS-DB have been written correctly in the maintenance plan.

Making a PDF in interleaf is too time consuming so another teamcenter loop is not possible, instead they are printed into hard copies and sent out. The configuration and serial status chapters are not being reviewed. A simplified flow chart is illustrated in figure 1-11. The input data ends up in three chapters which together form the maintenance plan.

Figure 1-11. Work flow chart

1.9.3 Problem identification

The main problem today is that there is too much human interference in the data handling. There are many process steps where data can get faulty and it results in a very time consuming work to isolate what is right or wrong and where.

Double work is also being done since much work is hardcoding instead of exporting data directly.

Making PDF in interleaf is tricky, this ends up with much printing of paper instead of sometimes easier PDF handling.

The databases mentioned have no satisfying cooperation between them and it even misses some vital data, it is up to the engineer to keep track that all data goes hand in hand. Documents are also being worked on in different applications such as different logins into interleaf. Some documents are even written in word.

Much of the information in the configuration list has to be altered to make it applicable to the maintenance plan. For an example even if an article is valid for all aircrafts it is declared as serial status in the configuration list, also there is more articles in the configuration list than needed in the maintenance plan.

(18)

Gripen are today fighting with the top manufacturer for export contracts, the interest for Gripen have never been greater. In the beginning of 2008 more than seven countries have or will receive a quotation for buying Gripen. The odds that none of them buy must be considered unlikely. And with many customers there will be more types of configurations and a more advanced Gripen which in return results in more data. Today’s working process for J3 is not optimized for this and therefore some kind of change must be carried out to simplify the dataflow. By implementing all maintenance plans into PumaX a more modern way of working can be utilized for all customers.

(19)

1.10 PumaX

PumaX is a complete solution package for technical publications, it supports both S1000D and 1000D and it handles everything from data input to delivery. PumaX is made by the Norwegian company corena.

PumaX differentiates a lot from interleaf, instead for hardcoding the data it can be transferred directly from databases. It is windows based with a more user friendly interface and data are being presented in a structured datamodule with a defined DTD (Document Type Definition) structure (more about DTD in chapter 1.14) in comparison with interleafs SGML tables.

The datamodule can be split into two parts, metadata and content. Information about the module is being kept in the metadata, i.e. which customers the module is valid for. The content in the module is presented in SGML code which works much the same as the newer XML (eXtensible Markup Language). SGML and XML is a format for structuring text masses. With specific tags data can be defined and is easy to transfer between different systems. Everything in PumaX is then stored in a database (CSDB) based on oracle. The principle of PumaX is to have a mastermodule with data for all customers so only one datamodule has to be edited. However the master module concept only works with S1000D. Separation of different customers is solved by “inline applicability”. That is when information in the datamodule differentiates between customers, applicability for only particular customers are made. If for an example all text for a maintenance publication is one datamodule it is thereby called the master. If now there is some difference between Sweden and Hungary, inline applicability must be used to separate the two. The specific text marked as applicable for Hungary is then being shown when making a printout for Hungary.

When finally a delivery is to be done, all datamodules valid for the customer are selected and put together into a publicationmodule. The publicationmodule can be delivered in several ways such as pure paper documents or PDF files. In figure 1-12 an overview of the work process is illustrated. When applying PumaX to the maintenance plan not all inputs are required today, there are no particular planning function since the work are being done in such a small scale in comparison with other publications.

(20)

1.11 DTD

To describe the XML or SGML document structure a DTD is required. DTD defines which rules and elements a document has. These elements can both be mandatory or optional. The document standard decides what type of DTD is used. For PUB94 a “BAS-DTD” can be used, however interleaf uses instead a type of table with no definitions to decide what type of tags that can be filled.

1.12 Work process ZA maintenance plan

It is mentioned earlier that South Africa’s maintenance plan already is implemented into PumaX. This is a true in some aspects. South Africa demanded all publications to be written in S1000D. This ended up with a working method much different than used before. The amount of data in the South African maintenance plan is also less than for FMV and the layout differentiates in many places. This is because SAAB only sold the data required to keep the aircraft airworthy. All information for following up the maintenance was left out.

The data transfer into PumaX was made with pre-done XML files, by using special scripts specific data in the different databases could be selected and put in XML files which were loaded into PumaX (See APPENDIX D ). The datamodule was put together materialgroupwise, i.e. all maintenance tasks for chapter 38 -“HJÄLPKRAFTSFÖRSÖRJNING” ended up in one datamodule. A review process had to be done both after to secure that the data was correct.

Since there is only one maintenance plan today for J4 it is also in a sense the master. Once all datamodules were imported and reviewed they were put together into a pulicationmodule.

1.13 Problem isolation regarding FMV implementation

The work procedure in 1.12 seems applicable for all maintenance plans. However this is not the case. As established in figure 1.2 J3 documents use PUB94 and by that the mastermodule concept fails. Even if it was possible there is too much difference between FMV customers to be able to use inline applicability.

Using PumaX built in function to grab data directly from databases is also a too time consuming work because of the amount. The data will indeed be transferred directly, but the data has to be selected each time.

Why not use the scripts as for South Africa then? The responsibility for exporting all the data is done by a consult firm with no experience of working with the maintenance plan. It is not impossible but today there is too much difference between the databases and the maintenance plan for a strictly direct transfer with some sort of script. For South Africa data was reviewed and checked by hand after the transfer was carried out, a neat feature in PumaX also checks certain parameters in the XML file for faults such as publication references.

(21)

The configuration data stored in artemis can not be used properly today, there is no connection between the article and its object code. In ILS-DB however some articles are defined with its maintenance object. This is how it was solved for South Africa and where data was missing it was put in by hand.

The DTD structure used in S1000D also possesses some difficulties. One is that the DTD used for South Africa only three different levels of where the maintenance can be carried out are defined.

By where it means if the maintenance must be carried out in a central workshop or somewhere else. This creates problems due to the fact that there is for an example five levels which the maintenance in Sweden can be done. This problem only occur if FMV decides to change standard to S1000D, if no change is made PUB94 has the “BAS-DTD” which is much more flexible and the maintenance level problem is solved.

The problems described above are some of the obstacles that need to be solved before a full integration is possible. Some of these questions will be answered in the forthcoming chapters.

(22)

Chapter 2 FAULTY DATA

2.1 Introduction

Faulty data is a problem which has already been commented in previous chapters. It is hard to make good food of bad groceries and the same goes for the maintenance plan. It does not matter if the data transfer is being done flawless if the data input is scrambled. Today the maintenance plan and ILS-DB database is not in a one to one relationship which is a requirement to be able to transfer data directly.

2.2 ILS-DB

ILS-DB was introduced in 1998 to serve as a storage area for Gripens maintenance data. The only customer in mind back then was Sweden so in a sense it was more or less custom made for the Swedish airforce. Today it is widen to other customers and products as well, i.e. UAV (Unmanned Aerial Vehicle). The principle of ILS-DB is to have all tasks arranged material group wise and then make connections for each version of product. In this way when choosing to make a MAD all maintenance objects and its tasks can be collected.

The ideal scenario would be to have all data required for the maintenance plan stored in ILS-DB. This is not the case due to insufficient funding for developing ILS-DB further and it is much because of this there are problems today. Since there is not enough room for data in ILS-DB the engineers only focus on the pure maintenance data even though other data sources influence the maintenance plan. There are also some issues for what data that is supposed to be updated in ILS-DB. For an example where maintenance tasks is carried out for Hu and Cz is not updated properly today, this has resulted in ageing information in ILS-DB.

The faulty data is today corrected by the engineer who compiles the maintenance plan since they review all documentation. But then another problem rises, the maintenance plan deviates from ILS-DB. This is not an ideal scenario because it makes it hard to trace information back to its source. It is solved today by a deviation report which states the general differences.

Years have gone by with this working method and today there is a lot of deviation which have to be taken care of before PumaX can be integrated.

(23)

2.3 Solutions

There is two ways of getting around the above mentioned problem. One is to have some kind of application between ILS-DB and the maintenance plan in PumaX. The other is to change the working process for ILS-DB so the data is corrected in the database and transfer can directly be done into PumaX. Both have its advantages and drawbacks.

2.3.1 Method 1, Corrective actions

If the data is corrected in ILS-DB not much is to be changed in comparison with how it was solved for South Africa. Scripts can take data directly and import it into PumaX. In chapter 1.9.1 it was mentioned that every task is connected to a customer in ILS-DB, so one can say that a kind of customization has already been done and the data is defined for each customer. A lot of the learning gathered from South Africa can be utilized and known issues can more easily be solved. However there needs to be an extensive work to make all the changes and applying a new work processes.

The engineers responsible for updating ILS-DB is not fully familiar with how the customers want the maintenance plan which is a requirement to be able to make all corrections right. A continuous dialog must exist to keep them up to date and support them about questions regarding the maintenance plan. It must also be remembered that it is not only for the maintenance plan the data in ILS-DB is being stored. Changes to ILS-DB can affect other publications as well which limits the changes that can be made. A simplified schematic is shown in figure 2-1.

Figure 2-1. Solution schematic method 1

2.3.2 Method 2, New application

The other solution is to have an application between ILS-DB and PumaX. The application can bee seen as a filter for which data are being refined. The most optimal way would be if it could filter the data automatically. However some kind of human supervision is most likely needed. By doing this the ILS-DB database can be kept as it is and the data can be modified in the filter before being integrated into PumaX. This has other benefits as well as can be noted in chapter 3. The drawback is that it demands for a new application. However it does not need to be specially advanced. It could be possible that the XML files with data that has been gathered from ILS-DB can filter the data and make the appropriate changes.

(24)

Possible human intervention can if needed be done in PumaX (i.e changed due to system or type report).

There has not been any inventory for what data that is faulty in ILS-DB. There is some general difference which is stated in the deviation report. Therefore much work will be required in the beginning to isolate what the filter must alter and implementing it. If the application by automatic could fix most of the deviations it would facilitate a lot of the work.

In figure 2-2 a flow chart is shown on how the solution could look like.

Figure 2-2. Solution schematic method 2

2.4 Summary solutions

The main difference between the two methods described is where the customization is done. It can be said that in method one the changes is carried out at the source – ILS-DB. Meanwhile in method two it is done between ILS-DB and the maintenance plan. Also who is doing the changes is an important question. In method two the engineers working daily with the maintenance plan is doing the customization, this may make it sound natural that method two is preferred in comparison with method 1. However developing new scripts or downright a new application has its drawbacks in uncertainties how it would function. In method one it is utterly important that a dialog exist between the engineers typing in ILS-DB and the engineers putting the maintenance plan together so that possible faults can be corrected in ILS-DB.

This is not done today for South Africa’s maintenance plan, the existing faulty data brought with the script is of course corrected manually in PumaX, but when the next update is to be done some of the same errors occur once again.

The methods described are only focusing on the maintenance data, we recall that there are other sources where data are collected and put into the other chapters in the maintenance plan – configuration and serial status. However the main source of faulty data today is from ILS-DB and it is here effort must be put in to make the corrections.

One major question remains to be solved with method two which is how the application will look like. It is most important that the application is user friendly and versatile so changes to the in-data can be changed easily.

(25)

Chapter 3 CUSTOMIZATION

3.1 Introduction

It has already been mentioned that a form of customization is done in ILS-DB. This sounds great, but we recall that ILS-DB was not originally meant for more customers than one – FMV. The scenario today is different with the possibility for more export customers. Also there is not only data from ILS-DB that is going into the maintenance plan. So even if some data are being customized in ILS-DB it is not all gathered in the same place.

3.2 Script based

PumaX have a very sophisticated system to keep track on what is valid for each customer – inline applicability. This solution is not applicable for the maintenance plan due to PUB94 (See chapter 1.16). How can this then be solved in PumaX?

One simple and most likely the only way is to have one set of datamodules for each customer. That is one datamodule for each material group and customer. This will of course end up with a lot of datamodules but since they will be codified they can be separated. PumaX also have a powerful search engine which makes the work easier. Sadly when doing this one of the main ideas with PumaX is lost, the master module concept. There is however other publications on SAAB which has the same system with separate datamodules for each customer just because of the amount of differentiating data.

How could the data be compiled then? Even though ILS-DB is not optimized for more customers than one there is however a sort of customization today. The MAD reports are for an example made from this. If the data from the databases could be gathered with the help of some sort of script which then is imported into a datamodule in PumaX just like South Africa the problem could be solved. This demands of course that there is no faulty data in ILS-DB.

3.3 Application based

There is another way it could be solved if there is still faulty data in ILS-DB. The application in chapter 2.3.2 could be automized and not only correct the data but also make the customization. By making the application just take data valid for the customer in hand it is extended for two tasks. Not only ILS-DB data will be gathered, information from other databases could also be taken and puzzled together. This however demands that the application can be altered in a simple manner. The application must be simple yet effective to be able to make changes when the maintenance plan is updated or changed for a specific customer.

In this way you could say that not much will be different from today. The script will do the same work as being done by man. The only difference is that a script does not make human mistakes. However a strict review or monitoring process will be required to have control over the data transfer. The data can still be wrong at it source, if so it is important

(26)

Much work will be needed with the first maintenance plans made. Since the application needs to be configured and possible faulty data in ILS-DB corrected a phase with much identification work will be carried out in the startup. But once the corrections have been made a lot of time will be saved no matter which solution is chosen.

(27)

Chapter 4 QUALITY ASSURANCE

4.1 Teamcenter

When handling the amount of important information as with the maintenance plan a quality process has to exist to identify possible faults in the data. By making the documents go in a teamcenter loop to affected people these can be isolated.

Teamcenter works such as when a document needs to be reviewed by a user an e-mail informs him that an assignment can be found in teamcenter. Through a web-based interface the document can be found, for an example a MAD report in PDF format. If now he or she founds something that is not correct the document are rejected back to the issuer with a comment stating what is wrong. The document is updated and sent out once again hopefully correct this time. When it is finally approved it is saved in teamcenter with a certain revision. In this way it is easy to have a history and an archive of all documents that have been reviewed.

In APPENDIX E a schematic over a reviews process in teamcenter is presented. The document is being approved by two reviewers but the third founds something that is not correct. The document are rejected back to the issuer which corrects the document and sends it once again with revision 1,2. This time the document is approved by all reviewers and is sent to out to recipients. All editions of the document have been saved in teamcenter.

Today the final maintenance part of the plan is being reviewed before sent to the customer. This is done by the engineers who make the MAD report. However since the maintenance plan are being made in interleaf it is being reviewed on hard copies. This is not an optimal way of doing.

4.2 Appliance to the maintenance plan

With PumaX teamcenter can be utilized for reviewing any of the chapters in the maintenance plan. The final maintenance plan can be exported from PumaX as a PDF. As stated before one material group could be one datamodule so each PDF will consist of one datamodule. This will eliminate all work with printing and running around with paper copies. With interleaf it was also only the maintenance part which was reviewed. Now if wished any chapters can be exported because everything is stored in PumaX. And if wanted be imported into teamcenter and from there make the quality assurance. No new application has to be introduced.

The quality process will be even more important when the data are being transferred directly. Since the data no more will be hardcoded and viewed by human eyes the quality process should be able to secure that nothing will be missed.

(28)

Chapter 5 SERIAL STATUS

5.1 Complex data

The by far most complex part of the maintenance plan is the serial status chapter. It has been commented in chapter 1.7.3 and was there only described in it most simple appearance. The basis for the work coming from ACS lists and configuration lists is not always written correct in respect to the maintenance plan. The information is interpreted differently when applying it to the serial status in the maintenance plan. It is a pure puzzle to figure out what statuses the articles are valid for. And if a customer has more editions on top of that you must be very experienced before taking on the task. All datasources previously mentioned are used in the serial status chapter and this is the key problem when looking on how it could be integrated into PumaX.

It is noted earlier that an application could do the customization but since the serial status is so complex it would be if not impossible at least not make it more effective than it is today. But then you may ask why not take experience of how it was solved for South Africa?

It was indeed a transfer made into PumaX for South Africa but it must be remembered that the serial status chapter is much simpler for South Africa. First of all is it simplified in terms of how much information there is, SAAB did not have to take demands from FMV into consideration which made it possible to erase much information only desired by FMV. Secondly South Africa is so far only operation one Gripen fighter which only uses one status so this simplifies it even more. But sooner or later they will operate up to 26 airplanes and then there may be some problems.

5.2 Conclusion

The question remains how the J3 standard could be integrated into PumaX. Not even the maker of PumaX – Corena, thought that it would be possible to integrate the serial status into the maintenance plan.

This maybe true if you are thinking of integrating the data directly. But the application or transfer script which could be making the transition into PumaX do not have the capability to handle the amount of different sources in an effective way as it looks today. The only solution left is to hardcode the serial status part in PumaX. This however does not sound logical if the goal is to change the working method. Luckily PumaX have a good editor for editing texts much different than interleaf.

Before adding changes to the serial status the data has to be gathered and reviewed so it is known what is applicable for the specific customer. This also have do be done if an application or transfer script would do the job since the data is so scattered. This new gathered information should then be put into the application or transfer script and then imported into PumaX.

(29)

Instead of doing this it should be as easy (or hard) to hardcode it directly into PumaX. The SGML tags where the data will be placed have to be defined first so it will be possible to place data in the correct field.

The focus should from here be to make changes to the core data so direct transfer could be done in the future without having to alter it. If FMV would accept a layout more like South Africa the work may also be more likely to work with some sort of script and the work would be much easier.

(30)

Chapter 6 CONCLUSION

6.1 Summary

Changing a way of work is something that every company or organisation sooner or later have to go through. If it is changing a work process or introducing a new computer application a close study has to be performed before applying the idea.

The questions discussed in this thesis are just some of the areas that have to be taken into consideration when changing the process for developing a maintenance plan for the gripen fighter. An explanation of the main pieces in the maintenance plan was carried out and an analysis of the work process. Both today and how it in theory would look like when using PumaX. By identifying the differences between J3 and J4 maintenance plans the references for PumaX could be set.

Faulty data could be solved by a new application between ILS-DB and PumaX or changing the faulty data at it source. A new application is doable, by fully moving the customization to the engineers working with the maintenance plan they will have total control of the dataflow.

Two methods were discussed and recommended, corrective and application based. Since many changes to the data will be done in the application moving the customization will add no difference. Just like when changing the faulty data the application could make the changes required to separate the customers. However a lot of questions have to be answered regarding the application before it can be a reality.

Teamcenter could be utilized for the quality process. After the data has been gathered in PumaX any part of the maintenance plan can be exported into a PDF and sent into teamcenter. Teamcenter is an application used today by SAAB and it will save both time and money.

The serial status can also be written in PumaX. Since direct transfer of data required for the serial status chapter is not possible for FMV today, it has to be written by hand in PumaX. Even thought this sounds to be no difference from today it will be in datamodules just like the rest of the maintenance plan in PumaX. This will at least simplify some of the work and it is a good first step before a complete transfer is possible.

6.2 Future work

A more complete study is recommended before PumaX can be totally utilized. The problems described in this thesis are just some of the obstacles that have to be overtaken. Many more exist and these may affect the outcome of the solutions discussed.

It is especially recommended that a closer study of the serial status problem is to be done, cooperation between different departments is the key to open a discussion on how the data can be collected in a safe manner.

(31)

The implementation of South Africa was a good experience before changing the work process. Sadly this was more done because of customer demands than making the process more efficient. FMV have shown no direct interest in PumaX and S1000D and often it is as in the case for South Africa the customer who has the last word. However with PumaX a lot potential for a much more efficient way of working is around the corner and much indicate that PumaX will be the application of choice for future development of the maintenance plan.

(32)