support task records, including product data collected by the task; Business Need Introduction This exchange enables the transmission of information on the condition and usage of a supported product.   Feedback includes: support task records, including product data collected by the task; product state and usage records; resource element state and usage records; product configuration information; any issues arising from work. The first few slides have been taken directly from Dexlib and they stand alone showing the Business Need and the Scope of the Operational Feedback DEX.

Business Process This DEX enables the transmission of information on the condition and usage of a supported product gathered during its operation. This DEX will provide inputs and triggers for maintenance tasks (Work_package_definition) and feedback information generated through the execution of maintenance tasks is covered by the Work_ package_ report DEX. Examples of information about the usage of a supported product: flying hours on an aircraft; mileage travelled by an automobile; number of starts for an electrical generator; volume of fluid pumped through a pipeline or process plant; operational cycles for a gas turbine engine; occurences of operation outside preset limits i.e. overspeed, or overstress; feedback from system monitoring; fatigue index; location of the part or product. The DEX enables the transmission of information on the condition and usage of a supported product gathered during its operation. Note that this DEX will provide Inputs and for maintenance tasks – Work_package definition FB information generated through the execution of maintenance tasks is covered by the Work_package_report DEX The bullet points show some typical examples of the sort of usage information of a supported product.

The following are WITHIN the scope of this DEX: Recording the transmission of information; Reporting the usage of a product as realized; (Note the usage is the activities that a product has been engaged in). Reporting the current configuration of the product as realized; Reporting the condition of a product as realized, before, during or after performing a support activity or operational usage, recorded as properties, states or observations; (Note this includes reporting the fault state, as defined or otherwise in the FME(C)A, observed on a product as realized). Reporting the location of the product as realized; The identification of the FME(C)A. (Note the definition of the FME(C)A is covered by the Fault_states DEX). The environment is which a product was operating. The activities that fall within the Scope of this DEX are shown in the slide and the individual bullet points are all self evident.

Scope (2) The following are OUTSIDE the scope of this DEX: Reporting the work performed on a product as realized; Reporting the resources used to perform work on a product as realized. (Note the reporting of work performed and resources used is covered by the Work_package_report DEX). The definition of the FME(C)A. (Note the definition of the FME(C)A is covered by the fault states DEX). Again this slide is self explanatory

Overview Use of a Reference Data Library Transmission of feedback information Capability (C010) Reference data Capability (C014) Messaging Identification of the subject of the feedback: the Product as realized Capability (C060) Referencing Product as realized Operational feedback Capability (C066) Representing a Work request Capability (C068) configuration State of the Product as realized Capability (C049) Representing product location Capability (C041) Representing an observed state Capability (C048) evaluated condition Capability (C044) actual environment Capability (C030) Representing and assigning properties Capability (C064) Representing Work done Capability (C011) Referencing Documentsed results (FEM(C)A) Activities that the Product as realized was engaged in Capability (C032) activity Capability (C046) variance Capability (C037) Assigning Documents Capability (C005) Capability (C065) order Information Management Capability (C016) Person Organization Capability (C036) Assigning Date Time Capability (C058) justification Capability (C001) Assigning Identifiers Capability (C019) Assigning Approvals This diagram was developed by Rob Bodington and diagrammatically shows all the Capabilities used by the Operational Feedback DEX . 1. The best collective name for the Areas on a a Blue Background is CAPABILITY FUNCTIONAL GROUP Points to note are: a. The 9 capabilities shown in a GREEN BOX are DEX 7 capabilities – they have been developed by Rob B and are all 90% complete (Testing to be done). b. The 13 capabilities shown in the OFF WHITE boxes are dependent capabilities which are being developed by modellers in other teams and are at varying stages of development (from complete to not assigned). If I could have fitted them on the slide I should have also included Assigning Approvals C019 and Representing Location C027) c. The 8 capabilities shown with a RED OUTLINE are dependent capabilities that we consider AT RISK mainly because a dedicated modeller has not been asigned - Assigning Approvals would have a RED Outline.

CAPABILITIES -TABLE The DEX 7 capabilities shown as a table; You will be aware that earlier this month at one our reviews with other teams it became apparent that some of the capabilities developed by Rob in support of DEX 7 sat better in other teams – specificially DEX 4 Work Package Definition and DEX 9 Work Package Reporting . Subsequently Rob has worked on the relevant capabilities splitting them as necessary: the main changes were: C047 Product Change – was deleted and replaced with 3 new capabilities (Representing a work request), (Representing a work order) and (Representing work done). In order to realise these changes it was agreed that we would need to employ (Representing an activity) and (Representing Plans) – a new capability.

DEPENDENT CAPABILITIES -TABLE As stated previously even if all the DEX 7 modelling work / Ref Data / Testing and Validation work is complete the DEX will not be useable without the completion of the Capabilities shown in the slide. The ones shown in RED are critical to DEX 7.

Reference Data Development Rob has completed the Model Reference Data work but we have only just scatched the surface for the Business Reference Data work

Summary of Remaining Work The table summarises our best estimate of the outstanding work required to make this DEX usable. 30 days Modeller effort and 25 days SME to complete the Reference data work, quality checking, testing and validation. The MOD can and will fund this work. Additionally we have estimated that a further 30 days modeller effort will be required to finish the missing capabilites. The MOD cannot fund this. I believe the problem that we have – and I mean all the DEX teams is the delta between Remaining Work and Remaining Resource. We should identify this delta today and feed up to the BFG for resolution because the bottom line is that unless the Resource is forthcoming from the organisations represented around the table the DEXs will not be completed.

Status / Remaining Work Capabilities / DEXs The ones that DEX 7 are responsible for are complete but requires Checking – have all entities been used? Testing – not yet This requires test data + availability of ALL capabilities Testing Requires ALL capabilities used by the DEX to be complete before the consistency of the EXPRESS can be tested. Requires test data to cover the scope of the DEX. Reference Data Model reference data complete Business reference data in work – complete April 2004 The following 4 slides were drawn up from R B input and expand on my summary table and highlight some general outstanding Issues Capabilities / Testing / Ref Data has all been covered

Issues / Remaining Work Quality We need to review ALL the DEX/Capabilities wrt to quality, consistency, accuracy Checklists will help Effort for DEX7 Modeller effort: 3 days Subject Expert: 3 days Validation Check that the DEX EXPRESS is complete Requires all capabilities used by DEX to be in place Requires development of long form – XML or EXPRESS Modeller effort: 2 days Subject Expert: 0 days Testing Neutral test files We should continue development of Bike test data to cover DEX7 The data should provide support to ALL the DEXs We should use the data as an input to translator test rallies Modeller effort: 10 days Subject Expert: 5 days Real test data We should identify some real data from applications Map to DEX7 Modeller effort: ? days Subject Expert: ? days The points raised are for the modellers to consider

Issues / Remaining Work Reference Data “It is modelling!” Needs Subject expert + modeller input Needs scoping Perhaps use TRILS How are we to proceed with ISO 15926? What database is available? Is it web accessible – both as OWL and Web Services? What tools are available for building the ref data? How does it interface to the PLCS model? Effort for DEX7 – Can be funded by MOD Infrastructure development: ???? Modeller effort: 20 days Subject Expert: 20 days Infrastructure How do we publish in OASIS? They may well have different requirements. Improvements HTML publications Paul Nolan committed – progress? Issue logs Rob was particulary keen to raise the issue of how we publish in OASIS – if they do have different requirements then this will clearly add time and cost to the process

Issues / Remaining Work Missing Capabilities – cannot be funded by MOD Properties Modeller effort: 10 days Subject Expert: 5 days Product as realized Subject Expert: 3 days Product configuration Modeller effort: 2 days Subject Expert: 1 days Scheme Modeller effort: 4 days Justification Subject Expert: 0 days Date time, Person Organization TOTAL EFFORT Modeller effort: 30 days Subject Expert: 10 days A breakdown of the missing capabilities required by DEX 7. Finish – Remaining Slides just amplify the Business Process