Issue raised against: aviation_maintenance

Comment: (Rob Bodington 07-03-28)
The DEX now uses the latest templates

The mapping of Maintenance activity is not done in accordance with the intended usage of the PLCS entities Activity and Activity_actual. The Activity entity shall deal with the information related to the planned work, whereas the Activity_actual shall deal with the information record throughout the performance of an activity. The mapping in Figure 5 does not show this distinction. The mapping of the maintenance activity should include both Activity, Activity_actual and Activity_happening entities. There should probably be two "assigning_activity" templates used, one for the relationship between the Activity (i.e. the planned) and one for the Activity_actual (i.e. the recorded).

The assignments of "assigning_time" representing the planned start , and planned end shall be assigned to the Activity entity. So should also the "assigning_process_property" representing expected man hours, and the "assigning_identification" that identifies the Maintenance activity.

Comment: (Rob Bodington 07-03-28)

I think that you were reviewing an out of date copy. The maintenance activity is represented by the template representing_work_done. This contains an Activity_actual related to an activity by Activity_happening. The related activity is the Directed_activity which is part of representing_work_order.

The assignments of properties, people etc, are all assigned to the Actual_activity in the template representing_work_done

The mapping of the link to a predefined maintenance task (choosen_method) in figure 5 should relate to a Task_method_version, instead of a Activity_method. This would allow for versions of Maintenance Tasks. (see DEX 3, task set).

Comment: (Rob Bodington 07-03-28)
There was an agreement that the a work order and typical activity would be described by an activity_method which is then related to a task - if appropriate, by an Activity_method_realization. That way the DEX does not enforce the use of Task - which some business processes do not support

The text under "Reportable_activity.reporting_organization" and "Reportable_activity.reporting_person" should probably refer to the reporting organization/person instead of as now, the one who undertook the activity.

Comment: (Rob Bodington 07-03-30)
Corrected

The mapping of Reportable_item.previous_part_numbers and Reportable_item.previous_serial_numbers in figure 10 should use Dated_effectivity instead of "assigning_time" representing start/end dates.

Comment: (Rob Bodington 07-04-18)
Corrected

The mapping of NSN in figure 5 is not in line with other mappings done (e.g.) UK_Defence. There has been a discussion on representing NATO Stock Items as Resource_items, and not assign the NSN directly to the Part.

Comment: (Rob Bodington 07-03-28)
We are not referring to a NATO Stock Item. We are saying that this part (or product as realized) has been classified by this NSN number. It is a classification. We are not referring to a resource item. My understanding was that was the UK_Defence approach as well.

Comment: (Trisha Rollo 07-07-06)
Also see GYL-8,,GYL-56, GYL-86, MB-22

Comment: (Rob Bodington 07-08-15)
Changed to use representing_resource_item_realization to represent NSN. Furthermore, the NSN IS assigned to Part.

Reportable_item_property is probably not a good name, since its usage is limited to recorded values. Suggestion rename to e.g "Reportable_item_recorded_property" (or measured or...)

Comment: (Rob Bodington 07-03-30)
It is used as a value for a task trigger as well. The intent is to provide a scoping model rather than a detailed model

We should not use the Resource_as_realized_resource_item.quantity attribute, but use a property assignment instead. (figure 14)

Comment: (Rob Bodington 07-04-18)
Why?

Comment: (Rob Bodington 07-11-15)
Changed to use resource propoerties

Why is the NSN assigned to a Product_as_realized. A product as realized is always related to a Part, which in turn..... Also see issue GYL-5

Comment: (Rob Bodington 07-03-28)
See GYL-5, GYL-56, GYL-86, MB-22

Comment: (Rob Bodington 07-08-15)
It is not assigned to a Product_as_realized - it is assigned to a Part.

Comment: (Rob Bodington 07-11-15)
The NSN is represented as resource item. The part of product_as_realised is identified as a resource item which is identified by its NSN.

Figure 18 (EXPRESS_G diagram for representing a usage activity) should be reworked in accordance with the issue GYL-1.

Comment: (Rob Bodington 07-03-30)
The diagram has been redrawn to use the template reporting_product_usage

Figure 26 (EXPRESS_G diagram for new PN, SN and NSN) should use Dated_effectivity instead of "assigning_time" representing start/end dates (Also see issue GYL-4).

Comment: (Rob Bodington 07-04-18)
Corrected

Figure 15 - note needs adding to figure about the use of template (similar to that in figure 11).

Comment: (Trisha Rollo 2007-04-11)
Figure 15 has been amended to add note

Maintenance_work_order.maintenance_organization is the Maintenance Organization raising the Maintenance Work Order . This also contradicts the PLCS representation statement which indicates the organization conducting the maintenance.

Comment: (Trisha Rollo 2007-04-11)
work order requires both organizations, amended

Fig 9 should show an approval. There should also be a template table and text

Comment: (Trisha Rollo 2007-04-11)
Figure 9, template and text amended

How do we represent the relationship between LCN number (breakdown) and part number.

Comment: (Rob Bodington 07-11-15)
The LCN is represented by a breakdown element. The parts that can be fitted in that position are them related to the breakdown element by a Breakdown_element_realization

How is an unknown or not required version number identified

Comment: (Rob Bodington 07-04-18)
This is described in the capability representing part

Representing a reportable item/PLCS representation /Part referencing capability rather than template: (For details of identification, see the capability: C001: assigning_identifiers and the template: C001: assigning_identifiers). Should state (For details of identification, see the capability: C001: assigning_identifiers and the template: assigning_identification).

Comment: (Trisha Rollo 2007-04-12)
text amended

Representing a reportable item / Figure 11 should show both Manufacturing and owning organizations of the part. PLCS representation needs to reflect this also

Comment: (Trisha Rollo 2007-04-11)
Figure 11, template table and text amended

Figure 13 is wrong it is missing view_defn_context . PLCS representation needs to reflect that this would be part of the template representing_product_as_realized.

Comment: (Trisha Rollo 2007-04-11)
Figure 13 and PLCS representation amended

Representing properties on a reportable item/PLCS representation words explaining property_value_relationship or time, organization and value type required

Comment: (Trisha Rollo 2007-04-11)
PLCS representation amended

Figures 7,11,13,15,17,19,25,27 and 29.need references to other figures completing

Comment: (Rob Bodington 07-04-18)
Corrected

Representing replaced parts need to clarify what is the difference between this and installing parts - trackable versus non trackable STItems.

Comment: (Trisha Rollo 2007-04-13)
PLCS representation amended

PLCS representation sections should be amended to reflect the style of Representing state of a reportable item

Comment: (Trisha Rollo 2007-04-16)
Done: Representing a message Representing a maintenance work order Representing reportable item maintenance activity Representing a reportable item Representing properties on a reportable item Representing replaced parts Representing installation/removal position on an aircraft Representing a reportable item usage activity Representing reportable item location Representing related components Representing change of Part Number, Serial Number, and NSN Representing Inventory Gain and Loss Awaiting: Representing Task extensions

Maintenance work order PLCS. The PLCS seems to contradict the figure. In the figure the assigning_activity relates the r_p_a_r for the end item to the r_w_o, and not the r_p_a_r for the reportable item.

Comment: (Rob Bodington 07-04-18)
Corrected.

2 Related DEXs ......Product operational information. The procedures ........ This full stop seems wrong. Possibly a colon?

Comment: (Rob Bodington 07-06-28)
OK - corrected

3 Scope ......items life ........ I think we also need health. eg "pressure" in a tyre; max pressure during sortie for an engine stage.

Comment: (Rob Bodington 07-06-28)
OK - propose we add: The health of a reportable item, e.g tyre pressure

Comment: (Trisha Rollo 07-07-04)
done The health of a reportable item, e.g tyre pressure

4 Business Process ......Removal and evacuation -> Repair/Overhaul ........ These seem to be reasons for removing an item, but not activities in themselves. I do not see how they differ from "Removal".

Comment: (Rob Bodington 07-07-04)
These have been derived from the DA2410 - we need to discuss changing it

Comment: (Rob Bodington 08-01-03)
Different business practices such as the 2140 may record the type of maintenance activity.

5 Inventory activities .......Gains To Inventory -> Loss to inventory ........ Are these part of the AM DEX, or are they covered by DEX 8? If the purpose is to say "this asset is now mine", and "this asset is no longer mine" then it probably is part of this DEX. My intent for this when discussing LITS data was for Inventory Gain to provide all the information about the asset. That is probably the purpose of DEX 8 for status, and this DEX for history of maintenance.

Comment: (Rob Bodington 07-11-15)
The purpose is to say "this asset is now mine", and "this asset is no longer mine". The section has been clarified to explain this and to show

6 Information Model Product usage information .... Possibly include "operating environment"?

Comment: (Trisha Rollo 07-07-04)
done

6 Information Model Product usage .... I think that health is required here. eg "maximum operating temperature" Health is a measure that must be within a given range; may be one of "between A and B"; "less than A" "more than A".

Comment: (Rob Bodington 08-01-03)
The DEX reports actual properties recorded. "maximum operating temperature" would just be another property.

6 Information Model Product usage Serviceability change This activity reports when a serviceable, uninstalled item .... Also applies to aircraft.

Comment: (Trisha Rollo 07-07-04)
done added "or end item"

6 Information Model Product usage Serviceability change .....rejection .... I'm not sure about the term "rejection". Examples I might use are "maintenance has become due" and "an operator has identified a fault".

Comment: (Trisha Rollo 07-07-04)
done - the engine manufacturers use rejection so keeping it, but added these examples

6 Information Model Removal of Serviceable Reportable Items for Controlled Exchange ............ Should this state that the installation is reported as a separate, related, Installation activity?

Comment: (Trisha Rollo 07-07-04)
done - added statement

6 Information Model Lifing extension ...........date........ It is not "date"; it is the life value

Comment: (Trisha Rollo 07-07-05)
done - changed to state life value, e.g. date

6 Information Model Lifing extension ...........tasks........ It is not "tasks" in general; it is "maintenance activity is due"; The maintenance activity may be "discard the part" for finite life.

Comment: (Trisha Rollo 07-07-05)
done - added maintenance activities

6 Information Model Maintenance ..........approved........ Is it just "approval" or is it other task life-cycle activities, such as recording effort; recording task completion; recording task coordination? In general, I thing it is recording management information about the maintenance activity whereas the other items are recording what happened to the asset.

Comment: (Trisha Rollo 07-07-05)
done - changed

6 Information Model Loss to inventory ..........has be decommissioned ........ typo: "been"

Comment: (Trisha Rollo 07-07-05)
done - changed

6 Information Model Maintenance work order .......... I had previously said that Sapphire allows multiple "arisings" ("observations"/"symptoms") on a work order.. I am advised that this is incorrect. Sapphire has a concept off "work package", which is a group of Work Orders to be addressed together (eg grouped by trade) and allocated to one person to "manage". The allocation of work orders to a work package is a manual process in Sapphire; A work order must be part of a Work Package for Sapphire to allow work to be recorded. I have not seen anything in the DEX that would allow "Work packages" to be passed.

Comment: (Rob Bodington 07-11-15)
You can relate work orders together. So to represent a package of work orders, you have one work order for the package, which is related to the set making up the package

7 Aviation Maintenance - Implementation details .......... It is a little confusing in this section that the template names do not reflect the names in the diagram. eg: "Template: #1 representing_product_as_realized " rather than "Template: #1 Reportable Item".

Comment: (Trisha Rollo 07-07-05)
done - entered title after Template number

9 Business information .....required, see: Section: . ..... Missing reference.

Comment: (Trisha Rollo 07-07-05)
fixed

Template #1 (Figure 5): .....Local_time........... This says "local time", but subsequent comment ("offset") suggests that time should be UTC, not local.

Comment: (Trisha Rollo 07-07-06)
Wording changed

ap239_id_class_name: .....the message (Message) of the message............ No make sense to me

Comment: (Trisha Rollo 07-07-05)
Wording is confusing; needs to be assessed but it is default wording

Comment: (Rob Bodington 08-01-03)
Improved definition

Figure 6 UML model representing a maintenance work order Maintenance_activity ............ Should there be something related to this identifying who did it; resources used, etc, or does that come later?

Comment: (Trisha Rollo 07-07-05)
Figure and wording amended

Figure 6 UML model representing a maintenance work order Repair_overhaul ............ Does this also cover the case where an asset is removed and returned to stores? I believe it is "any removal where there is no immediate plan to fit either to the same position or to another position or end-item.". As such I think the name is misleading.

Comment: (Rob Bodington 08-01-03)
The activities are given as examples.

10 PLCS representation ............ feel that these sections would be better organised with the diagram before the description. It took me a while to realise that the template numbers were referring to the later diagram rather than to an earlier diagram.

Comment: (Trisha Rollo 07-07-06)
statement added

10 PLCS representation .......Reportable_item.NSN NATO Stock Number of the reportable item ..... This may be a "domestic" code

Comment: (Trisha Rollo 07-07-06)
Some references amended within document (not template references or diagrams) however see GYL5, GYL-8,GYL-56, GYL-86,

Comment: (Rob Bodington 08-01-03)
Corrected all references to NSN

10 PLCS representation .......Reportable_item.supplier_code ...... NOTE The supply code ..... "NOTE The supplier code"

Comment: (Trisha Rollo 07-07-06)
changed supply to supplier

11 Representing a reportable item 12 PLCS representation ..... This seems to say that the "description" is against a part spec (PLCS "part"). Also need description against the specific part, as Sapphire allows specific comments.

Comment: (Trisha Rollo 07-07-06)
changed - added descriptor

11 Representing a reportable item 12 PLCS representation ....., it is advisable to use the template representing_product_as_realized.......... Surely the DEX should say one or the other, or if they are equivalent (which they don't appear to be to me), then show the digram with the template included.

Comment: (Trisha Rollo 07-07-06)
additional figures showing use of templates referenced added.

13 Representing properties on a reportable item Reportable_item_property.value_type ....., sortie.......... Does this mean that "sortie" would be used for a health measurement, such as "pressure"

We shoudl change this to be: the type of value - either a metered value, a cumulative value or a measured value. The measured value will not have increments. Update the uml diagram.

Comment: (Rob Bodington 08-01-04)
Changed sortie to measured

14 PLCS representation.......... This does not seem to allow for calendar-based items. Calendar-based items should give dates for "last occurred" or "next occurs", and should not (in my opinion) give"how long since" or "how long until" values. The "how long" approach requires calculation on the receiving side to provide "current" data. eg receipt of '10 days to go' needs calculation to show the true "time to go" if, for example, the data were received 3 days ago.

Comment: (Rob Bodington 08-01-04)
PLCS deals with explicit dates/times. The example give. "hours since last repair" is wrong - that is not an explicit property, rather a time on teh last repair activity. The example has changed.

14 PLCS representation.......... It seems to me that there are three distinct cases that need to be defined: a) Life values, where numerics and deltas are required, b) "sortie" (health/consumption) values, where numeric and "current" is required; no deltas. c) Calendar-based values, where absolute date/times are required (possibly with deltas?). Since there are different required/optional sets here, it seems to me that these should be modeled separately.

Comment: (Rob Bodington 08-01-04)
Rather then model an increment/delta explicitly, the sending system sends the past and current value. Calendar based properties are properties against the repair activities - i.e. last done. The three typical cases are:

• life_meter_reading - the value measured on the meter recording the "life" consumed by the reportable item, where the life value is used to trigger a maintenance task;
• life_cumulative - the cumulative life consumed by the reportable item taking into account the changing of meters;
• measured - the value that has been measured but is not used for calculating life. E.g fuel consumed.

14 PLCS representation.......... "Increment" is shown as required. I believe it has no meaning when a "sortie" metric is being reported.

Comment: (Rob Bodington 08-01-04)
Now shown as optional

14 PLCS representation..........it is advisable to use the template............... Similar comment to above

Comment: (Rob Bodington 08-01-03)
Improved text

16 Business information........., see: Section: . ............... Missing reference.

Comment: (Rob Bodington 07-06-29)
Corrected

16 Business information........., spare ............... Does this mean "serialised"?.

Comment: (Rob Bodington 08-01-04)
they could be serialised - the key point is that the installation history of the individual part is not racked. Wording clarified

17 PLCS representation........... The UML shows serial number as an attribute, but I see no representation of this in PLCS.

Comment: (Rob Bodington 08-01-03)
The serial number is an argument to the template "representing_product_as_relaized"

17 PLCS representation.........out of scope ............... Even if in scope, what is actually used may differ from the spec in the task. eg some parts may be "on condition" rather than "always".

Comment: (Rob Bodington 08-01-04)
Actually - reference to the task is in scope - the wording has been changed. It is the task that defines when which part should be used. This dex records what parts were used.

17 PLCS representation..........it is advisable to use the template............... as above

Comment: (Rob Bodington 08-01-03)
Improved text.

19 Business information......... The section heading is Representing installation/removal position on an aircraft, but the section is about history and does not reference a position in any way. There may be several positions in a parent to which a part can be fitted, eg a blade on a rotor head. The whole section is about "what" and "when" and "what to", but not "where". "Where" is needed too (PAC/SAC in LITS).

Comment: (Rob Bodington 08-01-04)
This section has been rewritten to make explicit representation of position using breakdowns

20 PLCS representation......... This seems to bear little relationship to the UML

Comment: (Rob Bodington 08-01-04)
This sections has been rewritten to make explicit representation of position using breakdowns

20 PLCS representation.........The position of the reportable item on the aircraft is represented in the Aviation maintenance DEX by referring to the next higher assembly and the aircraft (or end item) from which the reportable item is removed/installed. ................ As above, I believe this to be inadequate.

Comment: (Rob Bodington 08-01-04)
This sections has been rewritten to make explicit representation of position using breakdowns

20 PLCS representation.........The serial number which identifies the specific reportable item, and the NSN ................ Also need part no and CAGE code.

Comment: (Rob Bodington 08-01-04)
The reportable item is always referenced by serial number, part number and cage code

20 PLCS representation.........The serial number which identifies the specific reportable item, and the NSEach date when the installation / removal occurs is represented ................ I believe a statement is needed on what this means when part A is fitted to part B and then part B is fitted to a/c C and part A is subsequently removed.

Comment: (Rob Bodington 08-01-04)
reworded

21 Representing a reportable item usage activity........... Usage_................. The names used here do not match the UML diagram

Comment: (Rob Bodington 08-01-04)
Added explanatory text

21 Representing a reportable item usage activity........... template #2................. This is shown as optional; I would have thought mandatory, unless it is intended to obtain the date/time from the "sortie" by reference to something in the "sortie" record for the end item. If this latter is the case, then it should be explained.

Comment: (Rob Bodington 08-01-04)
Template #2 assigning_time is optional as the usage of the product may not have finished when the activity is reported.

21 Representing a reportable item usage activity........... Usage_profile.start_time ................ This does not appear to be represented in the PLCS.

Comment: (Rob Bodington 08-01-04)
It is part of the template representing_product_usage

22 PLCS representation................ I'm not sure what is intended to be represented here. Is it the sortie, or is it the usage from the sortie, or both? I would have expected the sortie and the usage from the sortie to be shown separately.

Comment: (Rob Bodington 08-01-04)
By "usage from the sortie" I presume you mean the properties resulting from the usage - they are separate - the wording has been clarified

Figure 20................ What does the bit about a business DEX mean?

Figure 20 UML................ Symptoms do not necessarily come from usage. They can come from inspection or "accident" such as "it fell off the lorry". Can this be represented?

Comment: (Rob Bodington 08-01-04)
Yes - PLCS supports this - the text has been modified accordingly.

Figure 20 ........not operating correctly................. Not quite. It means that the item is considered to have a defect; investigation may or may not find this to be true.# For example, with electronic kut it is common practice to replace several items without determining which are faulty, on the basis that getting the aircraft serviceable is important; determining which iteactually caused the fault can be done in slower time.

Comment: (Rob Bodington 08-01-04)
Improved text

Figure 20 ........UML Class definitions................. I don't see anything in here that covers "Asset Condition", which is a sub-classification of "Unserviceable" for assets, such as test, repair, scrap

Comment: (Rob Bodington 08-01-04)
Added to Serviceability.status

Figure 20 ........Fault -> requirements ................ I think this should be "specification".

Comment: (Rob Bodington 08-01-04)
Corrected

Figure 20 ........Fault_status.deferred_to..........This could be a date, ................ There is a specific "deferred to date" attribute, so how is this expected to be used? I would guess that it would be better to keep it as a numeric life metric plus metric value. Although reading further, it looks like this is just the value, with the metric being identified in deferred_to_metric

Comment: (Rob Bodington 08-01-04)
Improved description

Figure 20 ........Symptom.........performance ................ I'm not sure "performance" is quite right, but it is difficult to think of another term. Possibly "usability".

Comment: (Rob Bodington 08-01-04)
Using "operation"

Figure 20 ........Symptom.flight_safetey_hazard ................. affect ................ "effect"

Comment: (Rob Bodington 08-01-04)
corrected

Figure 20 ........Symptom.whenhow_source .................. who ................ Can also be "discovered" by monitoring systems such as HUMS (Heath and Usage Monitoring System)

Comment: (Rob Bodington 08-01-04)
Agreed

Figure 20 ........Servicability_status.organization ............. Serviceability Change ................ Clarity: There are two changes: Into state; Out of State. I believe it is "at the start date".

Comment: (Rob Bodington 08-01-04)
reworded

Figure 22 ................ This suggests that template #3 is mandatory. I believe it to be optional.

Comment: (Rob Bodington 08-01-04)
made optional

Figure 22 ................ Template #8 is referenced from text, but I don't see it in the diagram.

Comment: (Rob Bodington 08-01-04)
Now part of assigning_observation template

24 PLCS representation.............. Symptoms ................ Should there be some description of #13 and #16?

Comment: (Rob Bodington 08-01-04)
Now references description elsewhere

24 PLCS representation.............. Symptoms ........known........ I think a different word or phrase is needed here. A fault is "kown" once it occurs. It is possibly "common" faults or "faults forseen by the manufacturer"

Comment: (Rob Bodington 08-01-04)
reworded

24 PLCS representation.............. Symptoms .......#18....... I think this should be #12.

Comment: (Rob Bodington 08-01-04)
corrected

24 PLCS representation.............. Faults and States .......#7....... Believe should be #22

Comment: (Rob Bodington 08-01-04)
corrected

24 PLCS representation.............. This should not be confused with the code that is used to identify and the state type - these are represented by reference data and are set as parameters in the template. ....... I don't understand this bit.

Comment: (Rob Bodington 08-01-04)
Improved text

24 PLCS representation.............. first by an assessed state, then once the fault has been confirmed though measurement for example, by an asserted state. ....... Is this required, or can there be just an asserted state?

Comment: (Rob Bodington 08-01-04)
Now optional

24 PLCS representation.............. In addition many applications . ....... Missing word(s)?

Comment: (Rob Bodington 08-01-04)
corrected

24 PLCS representation.............. , in which case the state is identified by the template #8 and #4 assigning_identification. . ....... Are you saying that in general the state may be represented in one of two ways a) By reference to state definition; b) by explicit value?

Comment: (Rob Bodington 08-01-04)
It is just an identifier used to track faults - clarified text

24 PLCS representation.............. The dates when the fault was identified and rectified ....... I'm unclear what the meaning of these are, in particular start and end of "assessed" and any relationship to start of "asserted".

Comment: (Rob Bodington 08-01-04)
Added; "The time that the fault was "asserted" is the time that the fault "assessment" phase ended, so #6 and #9 would have the same values."

Figure 24 .............. What is the "geographical feedback report"?.

Comment: (Rob Bodington 08-01-04)
Redrawn diagram

26 Business information.............Location_history.status_at_exchange.............. I'm not entirely sure why this is needed. I guess it is what LITS records, for some reason, rather than determining it when required. I do recall that EPMS used to give conflicting data when different histories were compared, because it stored "A when B chganged" and "B whenm A changed" history, but treated each separately so that when both changed at the same time it would give something strange. Is there the possibility that by tagging "value of A when B changed" could give different results to a query on the underlying data of the form "what was the value of A when B changed?"?

Comment: (Rob Bodington 08-01-04)
This came from 2410 form - the requirement is to report the serviceablity status of an asset when it changes location

27 PLCS representation.............#1 representing_work_done and described in detail in Section: .............. I believe that location change is not part of maintenance work. It is the result of a decision made outside the maintenance arena.

Comment: (Rob Bodington 08-01-04)
Agree - modified

27 PLCS representation.............asserted state .............. Items removed from aircraft and returned for repair probably have an assessed state but not an asserted state (maintainer believes them to be faulty, but this is not confirmed until assessed in the maintenance bay).

Comment: (Rob Bodington 08-01-04)
Agree - ammeded

29 Business information.............. I don't understand what this message is forhow it will be used.

Comment: (Rob Bodington 08-01-04)
Clarified introduction

Figure 27 .............. This seems to say that NSN is required to identify a product_as_realized. NSN is optional.

Comment: (Rob Bodington 08-01-04)
Made it optional

32 Business information........... It is not only during repair/overhaul. It may be that the exact part fitted is not known, so is allocated a "temporary" identifier. When the part is eventually accessed or removed for some reason, the true identitity may be revealed. The true identifier may then be set by a change of part/serial number. Sapphire provides a function to allocate part numbers and serial numbers to parts that are known to be fitted but exact details are not known. This may also result in a change of CAGE code. but it looks like this may be catered for as the "Part" defines CAGE code. BUT does CAGE code need to be identified explicitly in th ediagram?

Comment: (Rob Bodington 08-01-04)
Improved text. Also - CAGE code IS the supplier code.

33 PLCS representation The UID ........ I don't understand what "UID" represents in the real world.

Comment: (Rob Bodington 08-01-04)
DoDs IUID - added more description

36 Business information ........ Tasks may also be given negative extesions, for example to reflect stress or damage caused in unusual circumstances.

Comment: (Rob Bodington 08-01-04)
Added text

36 Business information ........particular fault occurs,.................... These cannot be extended because extensions are against metrics. These tasks may be deferred.

Comment: (Rob Bodington 08-01-04)
Added text

36 Business information ........delayed.................... Tasks may also be given negative extesions, for example to reflect stress or damage caused in unusual circumstances

Comment: (Rob Bodington 08-01-04)
Added text

36 Business information ........Task_execution_trigger .................... Task Execution is conditional. For example, a task may be applicable only in certain operating conditions, or when part is fitted in a particular position. Therefore probably need to have an "active" attribute to specify whether or not the task will be triggered when the limit is reached (whether or not the task is applicable in the current environment). I believe this is needed so that queries don't suggest that a task has not been triggered when it is not applicable.

Comment: (Rob Bodington 08-01-04)
That is what teh condition does

36 Business information ........Task_extension ...... Task_extension.extended_percentage_of_interval .....The percentage .................... I believe that this should be cumulative. The cumulative percentage is needed because that is what determines the overall effect of the extension. Possibly two attributes needed: delta and cumulative. Looking further, it looks like "required" items are deltas for this instance and "extended" are cumulatives. A bit more explanation might be useful.

36 Business information ........Task_extension.max_permissible_extension .......... The maximum permissible extension allowed for a Standard Maintenance Task minus the total percentage extension assigned. .................... I'm not sure about this one. The name seems wrong (it should be something like "permissible_extension_remaining")

Comment: (Rob Bodington 08-01-04)
removed

37 PLCS representation ..............The Condition, Condition_assignment and Condition_parameter are all instantiated by the template #4 assigning_condition ................... This seems to be saying that the conditions for the task execution trigger are being sent. Is that coorect, and if so, then the question is "should we send the conditions?". Or is this representing the fact that a condition has changed? It seems to me thatthe only condition is "metric reaches threshold" and we are just passing information about a change to the threshold and not about the condition itself.

Comment: (Rob Bodington 08-01-04)
The condition is the trigger - so should be sent.

37 PLCS representation ..............#5 representing_numeric_property ................... How are date/time limits represented?

Comment: (Rob Bodington 08-01-04)
Added date time explanation

The template representing message had changed producing errors

Comment: (Trisha Rollo 07-06-15)
amended to reflect updated template.

Tables and Figures are to large for an A4 presentation.

Comment: (Rob Bodington 08-01-04)
All corrected

Activity performed by reportable item should use a more generic template than "representing_product_usage". Issue is raised against the template as well. See Figure 3, template #2.

Comment: (Rob Bodington 07-11-18)
The issue has been addressed in the template. There is a real difference between work "done to" a product and work "done by" a product. The template makes it clear when to use the different templates.

The usage of template "referencing_resource_as_realized" should be replaced by the new template "representing_resource_as_realized" throughout the DEX. E.g. see Figure 3, template #16.

Comment: (Rob Bodington 07-10-24)
Actually it should be replaced by assigning_realized_resource. Changes made

Location on product should be using "Product_based_location_representation". The DEX should also enable the representation of an Breakdown_element to be the carrier of the "Product_based_location_representation", i.e. the location is determined by a Breakdown_element as is often done within an LSA. E.g. see figure 3, template #14.

Comment: (Rob Bodington 08-01-04)
The location is now represented using breakdown.

Comment: (Rob Bodington 07-06-28)
We should reword this. We are not doing scheduling - Reporting the maintenance activities authorised to be undertaken on a reportable item or activities that have been undertaken ;

Comment: (Rob Bodington 07-06-28)
OK - reword to: removal and re installation of items to allow access to other reportable items;

Comment: (Rob Bodington 08-01-04)
Due to data protection it is unlikely that people will be identified

Comment: (Rob Bodington 08-01-04)
New XML schema generated

Comment: (Rob Bodington 08-01-04)
This is clear in the template

Comment: (Rob Bodington 07-11-18)
now: Figure 37 EXPRESS-G diagram for state of a reportable item The servicability status IS a code represented by reference data. The identification is used to track the individual state.

Comment: (Rob Bodington 07-08-15)
Implemented

Comment: (Rob Bodington 07-11-18)
Now: Figure 15 EXPRESS-G diagram for reportable item maintenance activity Now uses assigning_realized_resource and representing_resource_item_realization. Also added sections to describe resources used: Representing resource: trades used and Representing resource: replaced parts

Comment: (Rob Bodington 07-11-18)
Checked and introduced Reporter_of

Should be clear whether the istallation history is represented as one instance of "assebly_component_relationship" (i.e. promissory_usage or next_assembly_usage) per installation, or if there's one instance with a set of installations/removals attached to it. E.g. see figure 3, template #15. Proposal is one instance per installation.

Comment: (Rob Bodington 07-11-18)
Explained as a note in section: Representing installation/removal position on an aircraft - PLCS representation

The record of work done should use a more generalized template than "representing_work_done". Issue raised against the template as well. Figure 3, template #7.

Comment: (Rob Bodington 07-11-18)
The issues has been addressed in the template. The work done template makes it explicit that the activity actual is in response to a work order.

It should be clrear whether the message may contain multiple reportable activities, i.e. many "DEX instances". See figure 4, the UML diagram and Figure 5 template table #1.

Template table #1 (Figure 5). The 'content' input parameter should reflect that a message may consist of multiple instances of Activity_actual.

Comment: (Rob Bodington 07-11-18)
The message currently only allows there to be ONE content item. Content_item_selected.contents should be an aggregate. This has been raised as an issue against representing_message

Comment: (Rob Bodington 08-01-08)
The template has been modified and the text in the dex clarified.

It should be made explicit in the DEX that a failure report (see concpts in figure 4) shall be represented as a Work_request. The identification of a failure report is the identification of a work_request.

Comment: (Rob Bodington 08-01-04)
Changed to Work_order_issue_date

Issues against Figure 5 and the defined attributes for Maintenance_activity. Should contract and approval attributes be moved to the Maintenance_work_order, in order to let the Work_order be the collector of "administrative information"?

Comment: (Rob Bodington 07-11-18)
The assumption is that a message should only contain information relevant to a particular contract. It would be bad practise and probably cause security issues to have a message whose contents is covered by multiple contracts. The approval is for sending the message.

Issues against Figure 5 and the defined attributes for Maintenance_work_order. Suggest a renaming of the properties "actual_end_date" and "raised" to "closed" and "created" respectivly. This would reflect the context of a work order since a work order in many cases contains many activities.

Comment: (Rob Bodington 07-11-18)
This is a style issue - we could have reference data for time specific to a work order. The alternative is to use generic ref data and allow the business use to specialize. In this case the generic ref data is "Date_actual_end" which seems appropriate.

Issues against Figure 5 and the defined attributes for Maintenance_work_order. Suggest that the description attribute is moved to the Activity_actual, since Activity_actual is the record, as well as to allow for more than one Activity within one Work_order.

Comment: (Rob Bodington 07-11-18)
There is now a description against the work order and the work done. I.e. a description of what should be done, and what was done.

Issues against Figure 5 and the defined attributes for Maintenance_work_order. Line_of_repair is described as being a type of organization. I would assume that a Work_order is not assigned to the type of organization , but the actual organization that carried out the work (which in turn is of certain type of organization).

Comment: (Rob Bodington 07-11-18)
See: Figure 13 EXPRESS-G diagram for work order The actual organization is assigned to work order. The line of repair is now represented by a Typical organization.

Issues against Figure 5 and the defined attributes for Maintenance_work_order. Suggest that the task_type attribute is moved to the Activity_actual, since Activity_actual is the record, as well as to allow for more than one Activity within one Work_order.

Comment: (Rob Bodington 07-11-18)
This is used to classify work orders ... e.g. a work order for fit/install The work_done is also classified.

Issue against figure 7, template #1. Input parameter 'role_class_name'. Using 'activity_output' as reference data class implies that one can see the changes made to the end item, which is not the case just by referencing the end item as such. Suggest class name 'affected_item', or 'context_item', or something else along this line.

Comment: (Rob Bodington 07-11-18)
This is in keeping with the approach adopted for compatability with the PDM schema. It does in fact affect the end item. Doing work may result in the serviceability status being updated, new parts being fitted, hence the configuration status changing.

Issue against figure 7, template #3. Input parameter 'id'. The identification of the work done is the same as the identification of the work_order. This should not be replicated against each activity entity within the model.

Comment: (Rob Bodington 07-11-18)
It "may be" the same -- some systems may identify the work_order, directed activity differently and the resulting activity_actual differently again.

Issue against figure 7, template #3. The input parameters second, sence, hour_offset, minute_offset seams to an overkill for this kind of reporting.

Comment: (Rob Bodington 07-11-18)
You have to specify the SENSE otherwise you can not deal with time zones. Why not have seconds? Just put 0 if it is not known

Issue against figure 7, template #3, input parameter 'items'. Which view ? This should be exlpicit.

Comment: (Rob Bodington 07-11-18)
Are you suggesting that the DEX mandates a life cycle view?

Comment: (Rob Bodington 08-01-03)
The DEX now recommends that the Utilization_stage view is used.

Issue against figure 7, template #4, input parameter 'id_class_name'. Should the class be changed to 'Work_order_identification_code'?.

Comment: (Rob Bodington 07-11-18)
Yes - the DEX and template have been corrected

Issue against figure 7, template #4, input parameter 'date_class_name'. The class should be more specific, i.e. 'date_actual_created'.

Comment: (Rob Bodington 07-11-18)
See GYL-20

Issue against figure 7, template #4, input parameter 'act_id'. One do not need an additional identifier for the activity. This is given by the work order identification.

Comment: (Rob Bodington 07-11-18)
See GYL-25

Issue against figure 7, template #4, input parameter 'input'. Which view ? This should be exlpicit.

Comment: (Rob Bodington 07-11-18)
See GYL-27

Comment: (Rob Bodington 08-01-03)
The DEX now recommends that the Utilization_stage view is used.

Issue against figure 7, template #6, input parameter 'id_class_name'. Should the class be changed to 'Work_order_identification_code'?.

Comment: (Rob Bodington 07-11-18)
Yes - corrected

Issue against figure 7, templates #6 and #7. The template is to extensive. A "referencing" template would be suitable. E.g. identification of the work request for the change engineering is just to much.

Comment: (Rob Bodington 08-01-08)
Now uses referencing_work order template

Issue against figure 7, template #10, input parameter 'items'. Maintaining organization should be assigned to the "Directed_activity" and not the work order. This would allow for multiple Activites within one Work order. Better let Work_order just be the "encapsulator" of administrative information.

Comment: (Rob Bodington 08-01-05)
Corrected

Issue against figure 7, template #12, input parameter ''state_class_name.' Should be more specific.

Comment: (Rob Bodington 07-11-18)
Changed to State_of_work_order

Issue against figure 7, template #12, input parameter 'assigned_to'. State should be assigned to the "Directed_activity" and not the work order. This would allow for multiple Activites with different states within one Work order. Better let Work_order just be the "encapsulator" of administrative information. Might be that both are required.

Comment: (Rob Bodington 08-01-05)
No - this is the status of the work order NOT the activities. E.g. the work order is closed OR open

Issue against figure 7, template #13, descrption'. Replace completed with closed. Create a date_time_assignment for each Directed_activity that representes the time when the activity was planned to finish.

Comment: (Rob Bodington 08-01-04)
changed

Issue against figure 7, template #13, input parameter 'date_ecl_id'. Be more specific.

Comment: (Rob Bodington 07-11-18)
It is specific.

Issue against figure 7, template #14, input parameter 'is_assigned_to'. Should be assigned to the "Directed_activity" and not the work order. This would allow for multiple Activites with different discriptions within one Work order. Better let Work_order just be the "encapsulator" of administrative information. Might be that both are required.

Comment: (Rob Bodington 08-01-05)
NO - this is a description of the work order NOT the activities.

Issue against figure 7, template #15, description. Replace planned to start with opend. Create a date_time_assignment for each Directed_activity that representes the time when the activity was planned to start.

Comment: (Rob Bodington 08-01-04)
corrected

Issue against figure 7, template #15, input parameter 'date_ecl_id'. Change according to previous issue.

Comment: (Rob Bodington 08-01-05)
I think you mean date_class_name - it is correct

Issue against figure 7, template #16, input parameter 'items'. Classification of type of work should be assigned to the Directed_activity.

Comment: (Rob Bodington 08-01-05)
This could be either against work_order OR directed_activty - changed to be against directed_activity

Issue against figure 7, template #17, input parameter 'org_assgn_class_name'. Class not does not reflect the statement under the template description.

Comment: (Rob Bodington 07-11-18)
Changed to performer_of

Issue against descriptions under figure 8. Reportable_activity.identifier should not have to be repeted for every instance of Directed_activity and Activity_actual. Identification is given by the Work_order. Might be that each Directed_activity should have an identification within the context of the Work_order identification. This should then be reflected in the uniqueness rules within the template!

Maintenace_activity.actual_end_date. In my mind will an activity be completed, and the work order be closed.

Maintenace_activity.actual_start_date. In my mind will an activity be commenced, and the work order be created.

Maintenace_activity.approval. An approval shall be provided by the work order.

Maintenace_activity.contract, percentage_complete are not part of the upcomming representation. These types of issues confuses me.

Maintenace_activity.planned_end_date. In my mind will an activity be completed, and the work order be closed.

Maintenace_activity.planned_start_date. In my mind will an activity be commenced, and the work order be created.

Comment: (Rob Bodington 08-01-04)
Corrected

Issue against figure 9, template #2. Issue should probably be adressed to the 'referencing_task' template. The variant parameters should not be part of the template. Variants are Tasks in their own right with unique identifications.

Comment: (Rob Bodington 07-11-18)
The template referencing_task has been modified to remove variant

Issue against figure 9, template #7, input parameter 'person_role_class_name'. Class not does not reflect the statement under the template description.

Comment: (Rob Bodington 08-01-05)
Corrected

Issue against figure 9, template #8, input parameter 'date_class_name'. Class not does not reflect the statement under the template description.

Comment: (Rob Bodington 08-01-05)
Correcetd

Issue against figure 9, template #9, input parameter 'items'. Is the Product_as_realized reference enough to reflect the output of the activity? Ref data class should probably be 'Affected_item' or something similar.

Comment: (Rob Bodington 07-11-18)
See GYL-24

Issue against figure 9, template #13. Template shall be replaced with the new template 'representing_resource_as_realized'.

Comment: (Rob Bodington 07-11-18)
See GYL-13

Issue against figure 9, template #14, input parameter 'property_class_name'. Class not does not reflect the statement under the template description.

Comment: (Rob Bodington 07-11-18)
See templates in Figure 15 EXPRESS-G diagram for reportable item maintenance activity Corrected

Issue against figure 9, template #16. There shall be no planned information against the record.

Comment: (Rob Bodington 08-01-05)
Corrected

Issue against figure 9, template #18, input parameter 'property_class_name'. In the DEX3 the class is defined as 'Elapsed_time', which better reflects the statement in the description.

Comment: (Rob Bodington 07-11-18)
Using "Activity_elapsed_duration"

Issue against figure 9, template #23, input parameter 'person_role_class_name'. Class not does not reflect the statement under the template description. It's also redundant to the class given in template #7 which imposible to differentiate.

Comment: (Rob Bodington 07-11-18)
See templates in Figure 15 EXPRESS-G diagram for reportable item maintenance activity Changed to performer_of to indicate the person/org doing the activity,

Issue against figure 9, template #25. The approval shall be against the Work order and not every separate activity. Compare with description under figure 8

Comment: (Rob Bodington 08-01-05)
NO - this is approving the work that HAS been done. Not approving the work to be done. I.e. signing off work - hence an approval of the activity_actual Clarified in the text

Issue against figure 11, templates #1and #7. Are you required to assign the effectivity in every data exchange, or just when the change occured ? Should also be explicit, that when you change the identification, you need two effectivity assignments, one for the new id and one for the old id.

It's also a question on whether the Part changes the identification, or whether thats a new Part. However, a serialized item may change its membership of a Part when the individual serialized item is changed. It then needs to set a pair of effectivities for its membership, ending the old one starting the new one.

Comment: (Rob Bodington 08-01-05)
Agree - the section has been redone to reflect the chnages above

Issue against figure 11, template #4. You could not expect to create reference data for every NSN. At least not in the short run.

NSN shall not be assigned to the Part. A NSN membership for a Part may not be real for all it's versions. Membership may also be qualified per batch (reference to discussion with Leif Tonning). Propose introduction of Resource_item where the NSN is assigned as an identification.

Comment: (Trisha Rollo 07-07-06)
Some references amended however see GYL5, GYL-8, GYL-86, MB-22

Comment: (Rob Bodington 07-08-15)
Changed NSN to be represented by template representing_resource_item_realization.

Comment: (Rob Bodington 07-11-15)
The NSN is represented as resource item. The part of product_as_realised is identified as a resource item which is identified by its NSN.

Issue against figure 11, template #5. Description on serial number change should not be assigned to the Part, but to the seralized item. Also see previous issue.

Comment: (Rob Bodington 07-11-18)
It is a description of a part - the note should say that the description should only be exchanged when the part changes

Issue against figure 13, template #1. Set of 'class_name's are not the same as given in the introduction for this section. Confusing.

Comment: (Rob Bodington 08-01-05)
Agree - the text now describes the lifecycle stages and recommends Utilization_stage

Issue against figure 13, template #3. Which view ?.

Comment: (Rob Bodington 07-11-18)
See GYL-27

Issue against figure 15. Should be using the template 'Representing_resource_as_realized'. See note in figure. Do no use the referencing template.

Comment: (Rob Bodington 07-11-18)
Corrected

Issue against figure 17 and the usage of Effectivity to define installation period. This is not what was agreed way back. Agreement was to use date_time_assignments. See templates #11 and #12.

Comment: (Rob Bodington 07-11-18)
Agreed to use effectivity - classified as Installation_effectivity

Issue against figure 17, templates#1, #5 and #6. Try to be more explicit on the views being used.

Comment: (Rob Bodington 07-11-18)
See GYL-27

Issue against figure 17, template #2 and #4. Representation of installation history, location on product, etc, shall include Breakdown_elements, and Product_based_location_representation.

Comment: (Rob Bodington 07-11-18)
Addressed see: Figure 31 EXPRESS-G diagram for installation/removal of a reportable item in a position on aircraft

Issue against figure 17, template #1. Try to be more explicit on the views being used.

Comment: (Rob Bodington 07-11-18)
See GYL-27

Issue against figure 17, template #1. Try to be more explicit on the views being used.

Comment: (Rob Bodington 07-11-18)
See GYL-27

Issue against figure 19 template #1. Use a more generic template. This template overlaps with other templates. Issue raised against the template as well.

Comment: (Rob Bodington 07-11-18)
Issue addressed The issue has been addressed in the template. There is a real difference between work "done to" a product and work "done by" a product.

Issue against figure 19, template #2, input parameter 'date_class_name'. Class name do not correspond with the template description.

Comment: (Rob Bodington 07-11-18)
See Figure 33 EXPRESS-G diagram for representing a usage activity Corrected

Issue against figure 19, template #3 and #4, input parameter 'la_class name' . Same class name makes it impossible to differentiate between the two templates.

Should you really require the input parameters 'loc_org_id' etc for each instance ???

Comment: (Rob Bodington 07-11-18)
Created start_location / end_location ref data.

Issue against figure 19, template #5. Isn't type of activity given as an input parameter to the 'representing_activity' template ?.

Comment: (Rob Bodington 07-11-18)
Actually - it should be a typical activity (Activity_method) linked by the chosen_method from representing_product_usage. Changed accordingly

Issue against figure 21. The work_request is missing in the figure. A Work request should represent the "failure report", which often is given an identification. The discussion on usage of Observation -> Failure report -> Work order is missing in the representation as well. The assessed_state should be assigned to the failure_report. A failure location activity is often the first activity within a Work order (or a Work order in its own right).

Consider the usage of Work_request instead of Observation.

Comment: (Rob Bodington 07-11-18)
There is a work request shown. The business process is that a symptom is observed, then a work request is raised, then a work order is created.

Issue against figure 22, template #1. Consider the usage of Work_request instead of Observation.

Comment: (Rob Bodington 07-11-18)
See GYL-70

Issue against figure 22, template #3. Use a more generic template. Product usage is not the only time that failures are observed.

Comment: (Rob Bodington 07-11-18)
Added representing_work_done

Issue against figure 22, template #4, input parameter 'person_role_class_name'. Should it be 'reported_by' ? Are both required. The person making the observation is not necessarily the same person that reported observation.

Comment: (Rob Bodington 07-11-18)
Assumed that only the observer is required.

Issue against figure 22, template #5. The observer can not make the judgement whether the observation affects flight safety. Flight safety shall not be assigned to the Observation but to the State_definition of which Asserted_state/Assessed_state are members. Assessed_state shall be assigned to Work_request, and Asserted_state to the Work_order.

Comment: (Rob Bodington 07-11-18)
I agree - the observer is not making a judgment, rather recording a perception of effect on flight safety. Which is what the text states.

Issue against figure 22, template #6. Are all codes represented as reference data ? Or should the template assigning code be used instead ?

Comment: (Rob Bodington 07-11-18)
The assigning_reference data template should make it clear that assigning_code can be used instead

Issue against figure 22, template #6. Do not understand the requirement. However, are all codes represented as reference data ? Should the template assigning code be used instead ?

Comment: (Rob Bodington 07-11-18)
The assigning_reference data template should make it clear that assigning_code can be used instead

Issue against figure 23, template #1. See issues against figure 22 template #5.

Comment: (Rob Bodington 07-11-18)
The assessed states should be assigned to the work order not the work request. The work_request is in response to the symptom. The person raising the work request, should not do any work or make any judgement as to the fault. That occurs when once the work order is authorized.

Issue against figure 23, template #4. In order to sequentially identify observed states, shouldn't the identification be assigned to the State entity (or Observation?) The id seams to be missplaced. also see template #8.

Comment: (Rob Bodington 07-11-18)
Agreed - the identification and descriptions of state assertion and assessment should be against State_observed.

Issue against figure 23, template #9 and #16. What is meant with 'first' assessed ? Is it asserted or not ?

Comment: (Rob Bodington 07-11-18)
Agree - corrected

Issue against figure 23, template #7 and #10. Do you clear both the assessed state and the asserted state ???? I would belive that you only clear the real failure state and not the percieved one !

Comment: (Rob Bodington 07-11-18)
You would clear both

Issue against figure 23, template #14. Use the template 'assigning_code'. This is a classification and not an identification.

Comment: (Rob Bodington 07-11-18)
No - it is an identification of the state_observed used to track the fault. It is not the type of state definition.

Issue against figure 23, template #15. The state_assertion does not represent the state. Therefore should the end of the status be assigned to the State and not the state_assertion.

Comment: (Rob Bodington 07-11-18)
It is representing the period in which the product was in a given servicability state. Hence assigned to state_assertion. It is not the period in which a servicabilty state exists.

Issue against figure 23, template #18. Be more specific on the reference data class.

Comment: (Rob Bodington 07-11-18)
Changed to State_of_work_order

Issue against figure 23, template #21. Consider the usage of the module 'Work_output', or at least provide a guidance on when to use (if it's going to be used at all).

Comment: (Rob Bodington 07-11-18)
I do not believe that it should be used

Issue against figure 23, template #23. Which view?

Comment: (Rob Bodington 07-11-18)
See GYL-27

Issue against figure 29. See previous issue on the usage of NSN. NSN should be assigned to a Resource_item of which the Part is a member.

Comment: (Trisha Rollo 07-07-06)
Some references amended however see GYL5, GYL-8,GYL-56, MB-22

Comment: (Rob Bodington 07-08-15)
Changed NSN to be represented by representing_resource_item_realization.

Issue against figure 31, templates #4 and #5. Isn't the reason for loss or gain of inventory given by the representing work done. Seems redundant.

Comment: (Rob Bodington 08-01-05)
This refers to explicit reasons - modified text to give more explanation

Issue against figures 33 and 34. The relationship between: Task frequency, Activity due, and Product_as_realized property has to be further described.

Issue against figure 33. A Task trigger is never deferred, however a planned Activity may be.

Comment: (Rob Bodington 08-01-05)
Agree - redone section

Comment: (Rob Bodington 08-01-04)
Added

Comment: (Rob Bodington 08-01-08)
removed

Comment: (Rob Bodington 08-01-08)
This is really a business decision. Part of establishing a data exchange is to determine which system has primacy. Furthermore, when PLCS represents a property, it defines the context in which the property value has been established. This context should reflect how something like a life value has been calculated. Hence avoiding the issue raised.

Comment: (Rob Bodington 07-07-26)

Comment: (Rob Bodington 07-10-23)
Added: representing_product_usage representing_work_order representing_work_done representing_work_request