1. 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.

2. 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.

3. 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.

4. 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

5. 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.

6. 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.

7. 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.

8. 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

9. 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.

10. 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

11. 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

12. 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

13. 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