400 likes | 620 Views
The LSAR Experience. Peter Chaban L-3 Communications. Introduction. 9 years of combined experience in the Aerospace and Naval industry 7 years experience in Avionics repair (3 rd Line) and Avionics Systems Engineering
E N D
The LSAR Experience Peter Chaban L-3 Communications
Introduction • 9 years of combined experience in the Aerospace and Naval industry • 7 years experience in Avionics repair (3rd Line) and Avionics Systems Engineering • 2 years experience in Naval Logistics working directly with the OmegaPS LSAR OUGM - 2012
Introduction • Important things learned: • The importance of well crafted technical manuals • The importance of equipment repair turnaround times • The importance of design feedback on commonly failing components. i.e. APX-77 RT, $800 MOSFET’s • The importance of RAM analysis to all items subject to failure in a system • Example – Foam incident – should never have happened OUGM - 2012
* photo from scott.af.mil OUGM - 2012
Introduction • Topics for discussion • 1. Oracle Server Tweaks for Better Performance • 2. Configuring Join Functions in Oracle Discoverer • 3. Maintenance Manual Generation from the LSAR OUGM - 2012
1. Oracle Server Tweaks OUGM - 2012
Oracle Server Tweaks • Contract Obligation to Generate 1388-2B reports • RCM Summary (LSA-050) • FMECA (LSA-056) • Large LSAR database (7800+ parts) • Sluggish OmegaPS Performance Experienced • RCM Summary Generation – 6 Hours • FMECA Report Generation – 8+ Hours OUGM - 2012
Oracle Server Tweaks • Changes IT department made to Oracle Server to improve performance • Increased all essential tablespaces • Recreated database statistics for cost-based analyzer and scheduled it as a daily task • Doubled Windows Page File • Uninstalled or disabled all unnecessary apps and services • Added new Symantec exclusions for Oracle data files • Rebooted server to flush stagnant RAM OUGM - 2012
Oracle Server Tweaks • Results were amazing • New RCM Summary Processing time – 1 hour • New FMECA Report Processing time – 1.5 hours • Biggest server performance gains due to • Recreating database statistics (for cost based analyzer) • Uninstalling or Disabling unnecessary applications • Adding Symantec Exclusions for Oracle data files OUGM - 2012
2. Configuring Joins in Oracle Discoverer OUGM - 2012
Configuring Joins • Oracle Discoverer is a tool used to create custom Adhoc search queries • The data returned often spans multiple tables • Perfect for the 1388-2B architecture • Joining is necessary to search for data between multiple tables when they share a common column of data • Example – LCN is included in almost all of the 1388-2B tables OUGM - 2012
Configuring Joins • Depending on how the join is configured, the returned query results can vary • Data can appear to be fully populated when items are actually missing • Not ideal for data reviewing or validation • Example OUGM - 2012
Configuring Joins • It is required to build a Query that shows all items with the following criteria: • Is candidate • Has a failure rate • Has an Operational Availability • Purpose of this data is for the LSA to review for completeness OUGM - 2012
Configuring Joins OUGM - 2012
Configuring Joins • This query returns the following data: • Shows BIKE01AK is missing a Failure Rate • But it also appears that some items are missing OUGM - 2012
Configuring Joins • The query is re-run with the Operational Availability requirement removed • These results are different • Since BIKE05AA now shows up, its Op. Availability must not be filled in OUGM - 2012
Configuring Joins • Still not convinced that all of the data is being shown, the query is run for a 3rd time with the Failure Rate criteria removed • There results are also different: • Items BIKE07 and BIKE09 now show up which means their Failure Rates must not be filled in OUGM - 2012
Configuring Joins • The missing items shown in the previous slides were omitted because they did not meet all 4 of the original query’s criteria: • LCN – From XB table • LCN – From BA table (candidate item) • Failure Rate – From BD Table • Operational Availability – From BE Table • It is useful to know what’s missing • Understanding the basics of table joins OUGM - 2012
Configuring Joins • When you perform a query on multiple tables a Join function is used to link together a common column of data in each table (i.e. LCN) • The Join configuration will determine what data to return when a direct 1 to 1 correlation of data is missing in the joined tables • Types of Joins • Many different types and configurations (x6) • Join configurations used in Oracle Discoverer • Outer Join on Master • Outer Join on Detail OUGM - 2012
Configuring Joins • Join Example 1: The query is configured to “Join” the XB table to the BD table via the LCN. The data requested is the Nomenclature and MTBF. The Join type selected is “Outer Join on Detail”. • The returned results: OUGM - 2012
Configuring Joins • Join Example 2: The query configuration is the same, however the Join type selected is “Outer Join on Master”. • The returned results: OUGM - 2012
Configuring Joins • How to configure the Join in Oracle Discoverer • Log into Oracle Discoverer Administration Edition • Expand the table you wish to configure • Right click on desired join • Select “Edit Join” OUGM - 2012
Configuring Joins • How to configure the Join in Oracle Discoverer • Click “Options” • Then select the type of desired Join OUGM - 2012
Configuring Joins • Going back to the first example and changing the type of join to “on master” will produce the following results: Was: OUGM - 2012
Configuring Joins • Further Notes: • When creating a query based on multiple tables, the first table selected is the master and the second table is the detail. • If a third table is added to the query, it is considered to be the detail table to the second table and the second table is the master to the third. • Since the first table is not considered to be the master to the third table, the Join configuration of the third table will only affect the second and third tables, not the first. OUGM - 2012
Configuring Joins • Further Notes: • A user can only configure a table join to “master” if all dependant table joins are also joining to “master”. Otherwise an error will be generated. • Changes made in Oracle Discoverer Administration Edition will not be reflected in Desktop Edition until the user reconnects to the database. OUGM - 2012
3. Maintenance Manual Generation from the LSAR OUGM - 2012
Maintenance Manual Generation from the LSAR • Our customer responsibilities include: • Generation of Maintenance Manuals in a CFTO format • Review and Validation of Maintenance Manual data • Synchronization of LSAR to Manual • Preparation of LSAR data for customer upload into their own specific databases • Future Manual and LSAR Revisions based upon new or changed data (mainly part data) OUGM - 2012
Maintenance Manual Generation from the LSAR • The raw data mainly comes in from 2 different OEM sources: • OEM Maintenance Task Analysis Reports (MTA) • OEM Maintainer Technical Documentation Reports (Doc-002) • MTA report is used by the LSA for data entry into the LSAR • The Doc-002 is used by the Tech Writer to create the Maintenance Manuals. • In a perfect world, the MTA and Doc-002 would always agree with each other, however this is sometimes not the case OUGM - 2012
Maintenance Manual Generation from the LSAR • As the data is processed, our current LSAR and Manual generation software configuration does not allow for seamless integration between the two • Data has to be formatted and entered twice into each data set • Data reviews have to be completed twice on each data set • Changes have to be incorporated twice to each data set • There is constant effort involved in maintaining synchronization • Very easy for them to get out of sync OUGM - 2012
Maintenance Manual Generation from the LSAR • Additional effort required for data changes • Part number change in LSAR is easy • Part number change in Maintenance Manual can be difficult • If the LSAR and Manual shared the same data, a change in the LSAR could be automatically reflected in the Manual. • The result is automatic data validation and synchronization • Time savings • Cost savings OUGM - 2012
Maintenance Manual Generation from the LSAR • Activities to mitigate the un-synchronization of data. • LRU Part numbers were removed from subtask narratives • Subtask narratives were rewritten to eliminate specific tooling nomenclature • Manually entering IPL (page, figure & item number) data into OmegaPS and outputting it into an Excel format. This data is then stitched into the CFTO as a separate table. OUGM - 2012
Maintenance Manual Generation from the LSAR • Insight from Frank Hallam (Pennant) • Pennant has developed extensions for the generation of NY and MQ type CFTO documents (Planned Maintenance). • Pennant has developed extensions (with a Fall release schedule) for MY type CFTO documents (illustrated parts lists). • Pennant is endeavoring to cover off all Maintenance related CFTO’s in the next year. • Pennant has S1000D capacity however it is logical to drive the complete CFTO process from a single source – OmegaPS. OUGM - 2012
Maintenance Manual Generation from the LSAR • Industry demand will drive the OmegaPS software toolset • Cost savings through reduced work effort will justify an add-on with this capacity • Accuracy of data and quality of product delivered will be greatly improved • Customer will be happier if they can spend less to keep their manuals up to date OUGM - 2012
Questions / Comments Peter Chaban Engineering Support Specialist, HCM LSA Lead, CET HCM/FELEX & CP140 Defence Logistics Management L-3 Communications, Enfield Nova Scotia 902-873-2000, x6457 peter.chaban@l-3com.com OUGM - 2012