All Issues

DEX Issues

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

Issue raised against: fault_states

Comment: (Rob Bodington 05-11-30)
Added

Issue raised against: maintenance_plan

Issue raised against: operational_feedback

Comment: (Rob Bodington 05-02-18)
Corrected

Issue raised against: product_breakdown_for_support

Issue raised against: product_as_individual

Comment: (Tim Turner 04-09-02)
Re-worded

Issue raised against: task_set

Comment: (Leif Gyllstrom 2008-03-05)
Corrected.

Comment: (Leif Gyllstrom 2008-03-05)
Entire DEX structure has been revised.

Comment: (Leif Gyllstrom 2008-03-05)
Current representation is agreed within the PLCS Core Team, and is harmonized between the Task Set DEX and the Aviation Maintenance DEX.

Comment: (Core team review 2008-12-09)
Accept. But change Av DEX as well.

Comment: (Tim Turner 2010-2-05)
Done for DEX3.

1. I would have expected this cross-reference to DEX1 to read exactly the same as the Avn Mnt DEX viz DEX (D001):- Product Breakdown for Support. This DEX can be used to specify the as designed product structure of an aircraft. It will incorporate a breakdown structure detailing what components can be fitted into which positions on the aircraft;
2. The 'configuration effectivities' is basically incorrect – the DEX does not use the "Configuration Effectivity" module but a series of 'effectivity' templates
3. Why isn't the DEX using DEX 8? There will be occasions where the 'product' is in-service and requires additional Tasks.

Comment: (Core team review 2008-12-09)
Accept 1st para, 2nd ok, Reject 3rd statement.

Comment: (Peter Bergström 2008-12-29)
Wording changed to the wording in aviation maintenance dex. Thereby issue 1 and 2 are OK.
No action taken on issue 3.

"Scope
Identification of the product (supported item), to which the task applies."

The Avn Mnt DEX uses "Reporting the authorisation to undertake a maintenance task on a reportable item (an asset)"
This diversion from 'standardized PLCS jargon' between the 2 OASIS PLCS DEXs COULD be confusing for new 'players'. This Task DEX uses PIF [Product in Focus] throughout. Could this be resolved to a 'PIF' statement in both DEXs?

Comment: (Core team review 2008-12-09)
Accept; Should use PIF throughout both Task & Av DEXs.

Comment: (Peter Bergström 2008-12-29)
"Product in focus" originally meant all the data about all the products that you are interested in managing. It was not used to identify a specific part or breakdown_element, or even the end_item product, but to identify the entire scope of your interest, i.e. all your products and systems of products.
This is the definition use in ISO 10303-239. If you want to use the now common definition of "product in focus" (the thing you are interested in just now, i.e. a part, breakdown_element, or individual) in the DEXs, you need to re-define the concept and highlight the difference in use between the ISO standard and the DEXs.

Comment: (Tim Turner 2010-2-05)
DEX3 now refers to PIF

ISO 10303-239 Activity model - ISO 10303-239 Activity model definitions, Identify potential task
2nd bullet - "configuration change management tasks to be undertaken by support participants such as fitting a local modification or conducting an audit of product configuration;"

• This statement seems very confusing. The subject matter should be Configuration Management not CCM.
• What is a 'local modification'
• What is 'an audit of product configuration'

The statement should be corrected to read "Configuration Management tasks to be undertaken by support participants such as modification implementations or conducting a physical configuration audit of the product'.

Comment: (Core team review 2008-12-09)
Reject.

Task specification Business Information Requirements - Detailed Information Requirements, Product in focus identification
Product in focus identification
Identification of the product in focus to which the task specification applies. Identification of the product in focus includes the progression codes such as revision numbers.
NOTE At least one identification needs to be assigned to the product in focus.

What are progression codes?

Comment: (Core team review 2008-12-09)
Accept; Keep progression codes, but add to terminology section.

Comment: (Peter Bergström 2008-12-29)
Term "progression codes" added.

Task specification Business Information Requirements - Detailed Information Requirements, Task effectivity / applicability
Referenced text: The validity of a task, or part thereof, may be constrained to a specific context. These constraints are referred to as effectivity or applicability

Why a 'or' when the rest of the script uses '/' and (_) and in reality why mention applicability at all when no reference is placed on its usage.

Comment: (Core team review 2008-12-09)
Accept; remove usage of the term 'applicability'.

Comment: (Peter Bergström 2008-12-29)
Applicability removed.

Terms
The 'Terms' section does not include a list of terms and acronyms used in the DEX that needs further explanation.

Add list of terms/acronyms

Comment: (Core team review 2008-12-09)
Accept.

Comment: (Tim Turner 2010-2-05)
DEX3 now has terms defined

Reference Data Library
The item property_value_representation_determination is not contained in the RDL yet is used in Figure 23, Template 46.

Add element and definition to the RDL.

Comment: (Core team review 2008-12-09)
Reject; Class exists.

Reference Data Library
The element labour_time_planned has the same definition as labour_time_consumed.

Revise definition for labour_time_planned to indicate that it is planned labour hours.

Comment: (Core team review 2008-12-09)
Accpeted; Change definition for labour_time_planned

Comment: (Tim Turner 2010-2-05)
Redefined

Comment: (Core team review 2008-12-09)
Change DEX long name to Task Set; Change wording accordingly to clarify that a set means at least one (task). A message shall contain one or more task specifications.

Comment: (Peter Bergström 2008-12-12)
The DEX do address many task specifications, the message may have several content_items, one for each task specification. DEX Long name has been changed, and the text in abstract, introduction, and business overview have been slightly modify to clarify the relationship between a Task Set and Task Specifications.

Comment: (Core team review 2008-12-09)
Accept; Add effectivity statements to the business info overview & scope sections.

Comment: (Peter Bergström 2008-12-29)
Effectivity statements added to sections Scope and Business Information.

Comment: (Core team review 2008-12-09)
Accept; Need to look into attachment.

Comment: (Peter Bergström 2008-12-29)
Suggestions accepted as they are. Scope section updated.

Comment: (Core team review 2008-12-09)
Accept; Change Task resource model in overview to reflect what is actually stated in the DEX

Comment: (Peter Bergström 2008-12-29)
Changes made to section Business Overview and Business Information Overview. Task resource model is no longer used as a concept. The list of required resources in section Business Information Overview has been complemented by a new text paragraph at the end.

Issue raised against: work_package_definition

The section "Documenting the Definition of activities" states:

The definition of an Activity has been harmonized with the mechanism defined for defining tasks (see DEX 3), to enable a consistent, interoperable approach. This effectively treats the definition as a Document attached to the Activity identified.

I could not find this in DEX 3, and further more I would have thought that the definition of an activity should be done by assigning a document to an activity_method.

The DEX states:

The Approval_assignment links the Work_order to an Approval. The Approval_assignment shall in these circumstances be classified as a "Work_order_approval" (urn:plcs:rdl:std:Work_order_approval) (a sub-class of "Approval_assignment_role" (urn:plcs:rdl:std:Approval_assignment_role)).

I am not sure that there is a requirement to use reference data to make a distinction between what is being approved. It is sufficient to just the Approval_assignment with no classification as specified in the templates.

Capability Issues

Issue raised against: assigning_approvals

Comment: (mikeward 2004-08-16)
Agreed. Capability revised.

Comment: (mikeward 2004-08-20)
Agreed. Capability revised.

Comment: (Rob Bodington 04-08-19)
The approval status should continue to be used. Reference data should be used to provide the possible statuses.

Comment: (mikeward 2004-08-20)
Note added to State capability.

Comment: (Mike Ward 2005-01-07)
Agreed. Capability revised.

Comment: (Rob Bodington 06-06-20)
It is not obvious what the different functions of reference data for approval assignment and approval are. Hence, only approval is classified. The text has been expanded.

Comment: (Peter Bergstrom 2006-04-15)
Templates added.

Comment: (Rob Bodington 06-01-23)
I have just removed the offending /IGNORES from the path The same problem occurs in Approving_person_organization.approval_date = '/IGNORE' The diagrams still need to be updated.

Comment: (Peter Bergstrom 2006-04-15)
Diagrams corrected.

Comment: (Rob Bodington 06-02-01)
I would prefer Option 1. The EXPRESS-G and the path should be updated accordingly.

Comment: (Peter Bergstrom 2006-04-15)
I chose a different solution, because of the following: An approval may authorized by a person (in an organization) or by an organization (no person identified or mentioned), at least thats my understanding of the business overview. I therefore created a third template, assigning_approving_organization (and renamed the other one to assigning_approving_person), and the three templates are now not within each other (since there is a choise of a person or organization, they cannot be). This poses another syntactical problem in that it is now possible to assign only an assigning_approval, without either a person or an organization, and I cannot enforce that in the path syntax. See further issue PBM-1. However, it is no longer a problem of not accessing the reference_parameters...

Comment: (Peter Bergstrom 2006-04-15)
Three templates have been added: assigning_approval, assigning_approving_person, and assigning_approving_organization.

Comment: (Peter Bergstrom 2006-04-15)
corrected.

Comment: (Peter Bergstrom 2006-04-15)
The identification of a person is now optional.

Comment: (Peter Bergstrom 2006-04-15)
Corrected.

Comment: (Peter Bergstrom 2006-04-15)
Corrected, I think...

Comment: (Rob Bodington 06-06-20)
The prose text is acceptable

The capability has attempted to use the assignment of dates to approvals and Approving_person_organization by using the assigning_calendar_date template rather than the date attributes Approval.planned_date Approval.actual_date and Approving_person_organization.approval_date. The rational being that date assignment should be used everywhere in dexlib to enable the assignment of multiple dates. For example, there may be a requirements to assigned more than one date to the Approving_person_organization.

However, the AP239 model does not permit the assignment of a date time to Approving_person_organization. The options are therefore:

1. Use the date attributes and the representing_date_time template
2. Use the date assignment for the Approval and the attribute Approving_person_organization.approval_date
3. Raise a SEDS against PLCS and use the date assignment everywhere

The proposal is to use option 1 as this in keeping with the original model and raise a SEDS to allow the assignment of a date to Approving_person_organization.

Comment: (Rob Bodington 06-06-20)
Option 3 has been implemented. A SEDS has been raised, and the a modified schema added to dexlib. See dexlib/docs/issues/infrastructure_issues.xml#RBN-58

Comment: (Rob Bodington 06-06-23)
corrected

Person_in_organization and organization is represented in templates related to other capabilities. The template assigning_approval doesn't include the entity approving_person_organization which is required.

New template: assigning_approval_person_organization (asg_apr_pers_org) which contains approval, approval_assignment, approval_status, approving_person_organization (with references to proposed new templates repr_person and repr_org.)

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.

Assigning_approvals has 3 templates. Currently the the template assigning_approval has to either refer to the template assigning_approving_person or assigning_approving_organization. The templates assigning_approving_person and assigning_approving_organization have both the entity approving_person_organization and then refer to either person or organization. As suggested in issues related to capabilities representing_person_in_organization and assinging_organization the part representing person_in_organization and organization should be part of such capabilities and not part of assigning_approval. If these parts are replaced by references to other templates the two templates only include the entity approving_person_organization.

This leads to the proposal to make the two templates assigning_approving_person and assigning_approving_organization obsolete and either include the entity into assigning_approval or create a new template beside assigning_approval (see DNV-09).

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.

Issue raised against: assigning_codes

No explicit resources exist in AP239 to support exchange of codes in a robust manner. The proposed idea of populating Class.name with the code value may not be fully satisfactory. Some inputs to this discussion are forwarded by document 20050818_Codes and descriptors.doc (distributed by e-mail), and an alternative approach is indicated.

Suggest 2 para reworded.

Was:

Codes are often used to simplify the classification or characterization of a specific type of object. Each code is a shorthand for a specific term defined within a classification system. This type of codes are often used in legacy applications where the number of characters used were absolutly crucial. The amount of codes used by existing applications are to extencive to be expected to be defined in reference data libraries, prior to the realization of data exchanges including these codes.

Codes are often used to simplify the classification or characterization of a specific type of object. Each code is shorthand for a specific term defined within a classification system. This type of codes are often used in legacy applications where the code has a fixed character length and the different fields in the code have meaning.

Each individual code value used by existing applications could be defined in a reference data library prior to any data exchange. However, the number of codes in use is likely to make this prohibitive. Consequently the coded value will be exchanged and reference data used to define the type of the code.

Comment: (Leif Gyllstrom 05-10-10)
Change done according the proposal above.

I think that there is room for confusion between codes used as a classification and codes used for identification. A part number may well be a code. When it is used to identify a part, identification assignment should be used. I think that this needs to be stated in this capability. I also think that an example showing the classification of the part number should also be provided.

Suggest including something along the lines of:

Codes are strings that are structured according to some convention. Often different sets of characters within the string carry a particular meaning. For example, part numbers are sometimes made up of a set of strings, with each set carrying some meaning. For example, product function, manufacturing plant etc. Structured codes are traditionally used for two purposes:

Identification - the code provides an identifier for something. For example a part number or serial number.

Classification - the content and structure of a code provides information about the classification of whatever the code is assigned to. For example, the first 4 characters in a part number may indicate the function of the part. NATO Stock Numbers are examples where this is the case.

Where the code is being used for identification, the capability C001: assigning_identifiers should be used.

This capability, assigning_codes, should only be used

Comment: (Leif Gyllstrom 05-10-10)
Clarification provided within the additional usage section.

Comment: (Leif Gyllstrom 05-10-10)
Changed the template name to assigning_code.

Comment: (Leif Gyllstrom 05-10-04)
Done.

Issue raised against: assigning_date_time

Comment: (Peter Bergström 2007-04-12)
This no longer appears to be the case. Issue must have been corrected without documenting it.

Comment: (Peter Bergström 2007-04-12)
Figure numbering in templates corrected.

Comment: (Peter Bergström 2007-04-12)
Already fixed, but not documented.

Comment: (Rob Bodington 06-06-23)
Parameters can be bound in the instantiation path without them necessarily being declared as the reference parameter - local variables in affect. Having said that, it makes sense to make to bind Date_or_date_time_assignment to a reference parameter so that additional classifications can be made. The same issue is against assigning_time. Both have been updated.

Comment: (Rob Bodington 06-06-28)
Modified

Issue raised against: assigning_descriptor

Comment: (Tim Turner 20 april 2006 17:51)
From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: den 20 april 2006 17:51 To: 'plcs-dex@lists.oasis-open.org' Subject: [plcs-dex] Assigning_descriptor I would like to be able to specialize the descriptor classification for use with assigning_descriptor. However, the template fixes the class_name assigned to the document to be 'descriptor', rather than making this the type associated with an optional input parameter. With an optional parameter of type class 'descriptor', we would be able to characterize the descriptor into appropriate sub-classifications (mentioned in the capability), such as notes, remarks, comments etc.,. Any application will still know that any of the above are of type 'descriptor' through the class hierarchy. Would there be any objection to making this minor modification to the template definition, before I submit an unworthy issue? Kind regards, Tim

Comment: (Peter Bergström [mailto:peter.bergstrom@eurostep.com] 20 April 2006 17:46)
-----Original Message----- From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 20 April 2006 17:46 To: 'Tim Turner'; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Assigning_descriptor I think this is fine, especially if you supply a default value ‘descriptor’ for the new parameter. Then nothing will change for existing usages… Peter --------------------------------------------------------------------------------

Comment: (Rob Bodington [mailto:rob.bodington@eurostep.com] 20 April 2006 12:59)
From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 20 April 2006 12:59 To: peter.bergstrom@eurostep.com; 'Tim Turner'; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Assigning_descriptor I agree with Peter – it should be fine so long as you add the default. Regards Rob

Comment: (Leif Gyllstrom 2007-05-02)
Defining the type of descriptor being assigned is done by classification of Document_assignment. There is no need for specializing the classification of Document as well. Therefore is the issue rejected.

Comment: (Leif Gyllstrom 05-10-06)
Note added to the introduction.

Comment: (Leif Gyllstrom 05-10-04)
Added

Comment: (Leif Gyllstrom 05-10-04)
Text added.

Comment: (Leif Gyllstrom 05-10-04)
Changed.

Comment: (Leif Gyllstrom 05-10-06)
Section added.

Comment: (Leif Gyllstrom 05-10-04)
Done

Comment: (Leif Gyllstrom 05-10-06)
Done.

Comment: (Leif Gyllstrom 05-11-06)
Product_category isn't required. This is a missunderstanding. Se Issue RBN-1 below.

Comment: (Leif Gyllstrom 05-11-06)
Added.

Comment: (Leif Gyllstrom 05-11-06)
OK

Comment: (Leif Gyllstrom 05-11-06)
Added.

Comment: (Leif Gyllstrom 05-11-06)
An issue against all capabilities, and not explicitly assigning_descriptor.

Comment: (Leif Gyllstrom 05-11-06)
Corrected.

Issue raised against: assigning_document_properties

Issue raised against: assigning_effectivity

There is a need to assign product_as_individual_effectivity to product and support data, e.g. to relate a breakdown_element to it's parent product.

Proposal: Add NEW template Assigning_product_as_individual_effectivity (asg_p_a_ind_eff) containing Effectivity_assignment (classified) and a Product_as_individual_effectivity (optional classification) relating to a Product_as_individual.

When implementing translators, there will be cases where the end effectivity is known, but the start effectivity is not known. The start dates are mandatory in template representing_dated_effectivity. To get around this, it is suggested to create a new template 'representing_dated_effectivity_end' that would use an event for the start_bound of Dated_effectivity.

ENTITY Dated_effectivity
SUBTYPE OF (Effectivity);
start_bound : date_or_event;
end_bound : OPTIONAL date_or_event;
END_ENTITY;

The Event could be simply Event.id="start_effectivity"

Comment: (Tim Turner 19th Apr 2005)
Capability 1.8 was updated with the content from version 1.7

Comment: (Tim Turner 28th Jun 2004)
Accepted. Done.

Comment: (Rob Bodington 06-06-28)
Modified

Issue raised against: assigning_identifiers

Comment: (Peter Bergström 2007-05-24)
No, it should be listed in the underlying template/capability instead.

There is a need to represent a code with its description and explicit reference to its encoding system (C093 does not contain description and does not reference the encoding system explicitly).

Proposal: Add NEW template to C001 called representing_code (repr_code) with the associated name and reference to the encoding system used.

Identification_assignment.identifier (with reference data as per example 1 hereafter) holds the code_name, and is referenced by either an encoding system document or an instance of assigning_descriptor (C095). The Identification_assignment is classified by an internal class (with reference data as per example 1) where Class.name holds the "name". An organization shall optionally be assigned Identification_assignment the same way as in template assigning_identification.

• For an instance of Representing_code, the Identification_assignment providing the "code" (e.g. Identification_assignment.identifier="3") shall be assigned Reference data that specifically identifies the type of code (e.g. "Safety_code"). The Class entity that holds the "name" associated with the "code" (e.g. Class.name="Critical") is assigned Reference data that specifically identifies the type of name (e.g. "Safety_code_name"), applying the postfix "_name" to reference data name assigned to the code.
• Rule 1: For an instance of Identification_assignment there shall be one instance of Assigning_referenced_document classified as Encoding_system or one instance of Assigning_descriptor addressing the code origin.
• Mapping rule 1: If neither Encoding document nor description exists in the population, populate Assigning_descriptor. Document.description with "/NULL".

Comment: (Peter Bergström 2007-05-24)
Codes should be handled as described in Capability assigning_codes. That means that using your example above, you use template assigning_code and give the code (e.g. "3") in parameter class_code and assign a reference data class (e.g. "Safety_code" in param code_class_name) representing the encoding system, to give it a meaning. What's missing here is of course the description of what the code means ("Critical"), but the reference data class (code_class_name) defintion should point you to the definition of all codes. You just have to use a code_class_name that is specific to your classification codes, "Safety_code" is not enough.
You could also define each code as a reference data class, and use assigning_reference_data. That would give you the exact definition for each code immediately, and that definition would probably say what encoding system you use as well.
I think it is wrong to provide the definition of the code in instance data, as suggested above. As soon as you enter the world of reference data, you should not provide further information about that data in the instance file, but through the class definition and description.
I see no need for a new template here.

Comment: (Tim Turner 05th Feb 2004)
Characterization revised. Overview updated. Examples and model diagrams updated.

Comment: (Tim Turner 05th Feb 2004)
Empty issue

Comment: (Tim Turner 19th Apr 2005)
Capability 1.32 was updated with the content from version 1.28

Comment: (Tim Turner 18th Oct 2004)
Fixed

Comment: (Tim Turner 18th Oct 2004)
Not an issue against the capability. Closed.

Comment: (Tim Turner 18th Oct 2004)
Fixed

Comment: (Tim Turner 18th Oct 2004)
Not sure that i understand the question/issue. I think that each PAR is a separate version (that exists), therefore, it would have a different serial number to any other version. Assigning identifiers does not deal with versions. Actually, I shouldn't have used serial number as another type of identification for a Part - since this is at the design stage - NSN would have been better example. Raise another issue to clarify the question if required.

Comment: (Tim Turner 12th Nov 2005)
Example updated and problem fixed.

Comment: (Tim Turner 12th Nov 2005)
Added clarification on difference between identifiers and codes to the business overview section. There are several examples of part type codes (aka part number) being assigned and classified as such.

Comment: (Tim Turner 12th Nov 2005)
I assume that this is to enable users to specify the reference data library, rather than have it hard coded. Will work on it.

Comment: (Tim Turner 13th Nov 2005)
I believe that by including assigning_identification_with_no_organization (as suggested by RBN-8 - that refers to the same template), that this issue is closed.

Comment: (Tim Turner 12th Nov 2005)
Working on it.

Comment: (Tim Turner 13th Nov 2005)
Now added to C001

Comment: (Tim Turner 12th Nov 2005)
Description emboying above added.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Removed.

Comment: (Tim Turner 12th Nov 2005)
Re-formatted.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Removed.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Re-formatted.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 29th Nov 2005)
Fixed.

Comment: (Tim Turner 29th Nov 2005)
Fixed.

Issue raised against: assigning_location

Comment: (Rob Bodington 06-11-11)
Moved to the template assigning_location

Issue raised against: assigning_organization

There is no template for relating an organization to another organization. Currently the entity Organization_relationship is only present in C016 Representing_person_organization.

Proposal: NEW Template called "asg_org_rel" (assigning_organization_relationship): The template describes the relationship between two organizations classified using assigning_reference_data.

The OASIS cap C094 assigning_organization doesn't include the entity Organization_relationship therefore we suggest to add this to C094 and add a new template for the relationship."

Comment: (Peter Bergström 2007-05-24)
The only reason to create a template for the relationship is to make the classification of the relationship clearly visible, but it might not be necessary? We would get very many templates if we did this for every relationship... It should however be clearly described in the Capability.

This issue is related to the proposal of the new template assigning_organization_relationship and this template to be part of assigning_organization capability (C094) instead of representing_person_organization (C016).

Should the name of the capability be changed to representing_organization with one template called assigning_organization and the new template called representing_person_organization

This issue is related to the proposal of a new template assigning_organization_relationship to be part of assigning_organization.

The capability assigning_organization (C094) doesn't include the entity Organization_relationship (currently only available as part of representing_person_organization). The entity needs to be added to the capability in order to be able to add the new template.

Comment: (Peter Bergström 2007-05-24)
I agree, regardless if we have a new template or not the Capability must deal with the relationship.

Comment: (Rob Bodington 06-06-21)
The capability now specifies the use of assigning_location.

Comment: (Rob Bodington 05-11-18)
assigning_classified_identification renamed to assigning_identification_with_no_organization and moved to assigning_identifiers capability

Comment: (Rob Bodington 06-06-26)
Updated

Comment: (Rob Bodington 05-10-26)
Updated

Comment: (Rob Bodington 06-06-21)
Yes - this capability requires the use of the template assigning_identification_with_no_organization which is defined in the capability assigning_identifiers

Templates such as assigning_approving_organization need to reference an organization (similiar assigning_approving_person need to reference person_in_organization). Organization should be represented independently and referenced.

Proposal: NEW Template called "repr_org" (representing_organization): The template describes an organization when its only role is its existence without an entity approving_person_organization. This makes it easier to relate organizations to an organization hierarchy or e.g. approving_person_organization.

The template consists of the entity organization with the assigned templates as described in assigning_approving_organization as well as an optional assigning_address .

Comment: (Peter Bergström 2007-05-24)
This is a good idea, since there are entities whose attributes refer to Organization, see for example template assigning_approval.

Comment: (Rob Bodington 08-02-15)
A new template representing_organization has been created.

Issue raised against: assigning_product_properties

Comment: ( )

Comment: (Ian Bailey 2003-03-29)
Words have been altered in line with Rob's comment

Comment: (Ian Bailey 2003-03-29)
Reference has been changed

Comment: (Ian Bailey 04-03-29)
I was assuming that AP239 would not use independent_property as you are mandating reference data. It doesn't make much sense to define a standard property twice.

Comment: (Tom Hendrix 04-05-07)
In the pdm schema there is a notion of a "definitional" independent property. Perhaps something like a material specification. Is classification suitable for this sort of assignment?

Comment: (Ian Bailey 2004-05-10)
I think classification (reference data) is perfect for this. I spoke to Rob and he thought we weren't using independent property. One for the PLCS modellers to resolve, I think !

Comment: (Tim Turner 2004-06-17)
I certainly agree that we shouldn't have alternative ways to represent the same thing and there appears to be little push from Dex1 team to have this. I picked it up from the initial Dex 1 spec - not knowing that there was any agreement to abandone it for the Dexs. Another one of those "nuggets" no one knows about!

Comment: (Ian Bailey 2003-03-29)
The attribute you need is actually called "rep" and is imported as far as I can see in the usage section. Does this fix your problem ?

Comment: (Tim Turner 2004-06-17)
Yes fixed: - reps are now in the model!

Comment: (Ian Bailey 2003-03-29)
Does it need to be specified in this capability ? Surely the dependent and related capabilities sections in the other capabilities define which entities the properties can be assigned to ?

Comment: (Tom Hendrix 04-05-07)
Since the scope is only products, why not show a Product_view_definition in the select. All others in the scope of this capability are subtypes of this.

Comment: (Ian Bailey 2004-05-10)
I've done as Tom suggested, but left this issue open - do we need to consider properties being assigned to view_definition_relationship instances also ?

Comment: (Tim Turner 2004-06-17)
The property_assignment_select type population is now resolved. I think it was a problem in the longform generator back in March. Not sure about properties being assigned to view_definition_relationship instances. Can only see a need if there's a requirement to place properties on relationships between products e.g. alternate_part_relationship may have some sort of property governing it's use - but I rather think that might be treading on the effectivity ground. I'll let you decide if you want to close this Ian.

Comment: (Ian Bailey 2004-07-28)
Sounds like we have agreement, issue is now closed.

Comment: (Rob Bodington 04-07-29)
The select gets populated by the long form generator - not by capabilities.

Comment: (Ian Bailey 2003-03-29)
Examples for parts and requirements now added.

Comment: (Ian Bailey 2003-03-29)
Re-arranged text appropriately. Used definition from PDM Schema usage guide.

NOTE    In addition to products, properties can be assigned to activities, described in C077: assigning_process_properties and resources, described in C078: assigning_resource_properties.

Comment: (Ian Bailey 2003-03-29)
Added note - also did this for process properties.

Comment: (Ian Bailey 2003-03-29)
I disagree. This does not map onto any commercial systems I know. Nor does the PDM Schema usage guide mandate this.

Comment: (Rob Bodington 04-09-28)
Agreed.

Comment: (Ian Bailey 2004-05-10)
Changed in line with Tom's comments

Comment: (Ian Bailey 2004-05-10)
Surely the products capability should do this ?

Comment: (Rob Bodington 04-09-28)
Added line in introduction.

Comment: (Ian Bailey 2004-05-10)
Because of the need to configuration manage requirements, requirement is a subtypes of product. If you wish to assign a required property to an activity, you must first assign a requirement and then represent that requirement with your property.

Comment: (Ian Bailey 2004-05-10)
Done

Comment: (Ian Bailey 2004-05-10)
Well spotted !

Comment: (Rob Bodington 04-07-29)
Agreed. This capability should mention the fact that properties can be assigned to documents as part of the introduction . However, the representation of document properties should be part of the document capability - or a separate capability. See Issue RBN-1 against representing_document.

Comment: (Rob Bodington 04-09-28)
The introduction has been updated. The capability "assigning_document_properties" has been implemented.

Comment: (Rob Bodington 04-09-28)
Diagrams updated.

Comment: (Mike Ward 2004-12-23)
Diagrams amended accordingly.

Comment: (Mike Ward 2004-01-25)
Diagrams amended to reflect current status of reference data.

Comment: (Mike Ward 2004-01-25)
Diagrams amended to reflect current status of reference data.

Comment: (Mike Ward 2004-01-25)
New section added.

Comment: (Peter Bergström 2006-04-16)
External classification is used through template assigning_reference_data, because we want the property name to be defined as reference data.

Comment: (Peter Bergström 2006-04-16)
fixed.

Comment: (Peter Bergström 2006-04-16)
Capability has been edited, and figures changed...

Comment: (Peter Bergström 2006-04-16)
I think this issue is outdated, and do not understand what is meant. This capability does not have any Activity_property_representations.

Comment: (Peter Bergstr minor_techicalouml;m 2006-04-16)
The assignment of a property has no longer a date/time assignment, not even an optional one. Since the assignment of a property _may_ be done without giving any value, and since properties may have several representations which may be recoded at different times, it makes no sense. Instead The representation of the property can have a date/time assigned, which is recorded in capabilities C079: representing_properties_numerically, C080: representing_properties_textually, and C084: representing_property_value_ranges. This moves the date/time much closer to the actual value.

Comment: (Peter Bergström 2006-04-16)
This has already been fixed, but the issue was not closed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-06-08)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed. Although there are a lot of other things a property may be assigned to, so I selected a few as examples.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Annotated figure to show value, unit and property name.

Comment: (Peter Bergström 2006-06-27)
Hopefully this is now fixed, most graphics are new.

Comment: (Peter Bergström 2006-06-08)
Neither am I, and I agree that this should preferrably be handled by the structure and classification of reference data. Until there is a place to move this section (if needed) I will keep the section inside a comment in this capability, so it can be inserted somewhere else, but it will not be a visible part of this capability.

Issue raised against: assigning_process_properties

Comment: ( )

Comment: (Peter Bergström 2006-05-18)
Fixed.

Comment: (Peter Bergström 2006-05-18)
Fixed.

Comment: (Peter Bergström 2006-05-18)
I think this is true for many of the abundant subtypes of this part of the model... Will look into it.

Comment: (Peter Bergström 2006-06-05)
The discussion regarding use of subtypes of Value_with_unit and Unit have now been moved to capability 096 Representing_value_with_unit. This issue have been addressed in that section. My standpoint in doing this was the following: The semantics of values should be given in the attribute name referring to them, or in the property class name which they represent. A value is a value. Therefore, the use of Duration and Uncertainty_with_unit have been deprecated, except when the schema explicitly refers to these.

Comment: (Peter Bergström 2006-05-18)
Yes, C077 is applicable to both, hence its name: Assigning_process_properties. I do not know however if there is a real difference in usage with activity and task_method (I though not), can you provide some examples?

Comment: (Peter Bergström 2006-06-05)
The overview now mentions all 'super-entities' that can have process properties. It is assumed that the reader understands that process properties can be assigned also to their subtypes.
I do not think there is a difference between a duration property if it is assigned to a task_method rather than to an activity. A planned_activity is basically the same as its corresponding task_method, except that it is planned (scheduled, although not necessarily with a defined date/time) for a specific individual (or type). At least the (invented) property 'estimated duration' would be the same. There is however a difference that a task_method should not have an Actual_duration, since the task_method itself is a type - it is instantiated as an activity. But this is a difference between task_method and activity, not regarding their property assignments, and it should be discussed in other capabilities dealing with task_method and/or activities. Note that a planned_activity or a directed_activity should also not have properties classified as 'actual_xxx'. The only activity that should have 'actual_' properties is the activity_actual.

Comment: (Peter Bergström 2006-05-03)
I have renamed the template assigning_process_properties, and changed wording in the capability to explain to what entity instances a process property can be assigned.

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (Tom Hendrix 04-05-06)
fixed

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments. In terms of having a standard notation, that's a question for Rob !

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (Peter Bergstrom 2006-05-03)
Template has been added, and now renamed to assigning_process_property.

Comment: (Peter Bergström 2006-06-05)
Is this needed more than a description of how to assign a condition, an approval, an identification, a document, a language_indication, a justification or a task_method (just to mention a few) to an activity_property? Or shouldn't this be described in a capability for how to assign effectivities?
I think we might have a philosophical issue here: If something is not described in the capability, but the schema allows it, is it then not allowed (or deprecated) in the OASIS guidelines? Is it 'illegal'? Especially now with the templates, I can sense an unspoken conception that nothing except what's in the templates (or capabilities) is allowed. I would like this to be true, since life would be easier then, but I fear that we have forgotten to mention a lot of 'common sense' assignments to many entities in all of the capabilities in that case (just look at the list at the beginning of this paragraph!). Maybe we need to decide what 'conformance' to the OASIS PLCS DEXs or Capabilities really mean? And then possibly add all those assignments to all capabilities?
Or maybe I have just misunderstood this issue altogether...?

Comment: (Peter Bergström 2006-06-21)
The PLCS schema allows effectivity to be assigned to a property, not a value. Please provide some examples that show the business requirements for assigning an effectivity to a property.

Comment: (Peter Bergström 2007-05-17)
No further info received. Closed.

Issue raised against: assigning_resource_properties

Comment: ( )

Comment: (Peter Bergström 2006-05-18)
Done.

Comment: (Peter Bergström 2006-05-18)
Done.

Comment: (Mike Ward 2004-01-31)
Classification of Resource_property revised.

Comment: (Rob Bodington 04-09-29)
Added as PLCS ballot comment: 10303-1282 IBY-6

Comment: (Ian Bailey 2004-05-10)
Fixed for all modules in this series.

Comment: (Ian Bailey 2004-05-10)
Fixed.

Comment: (Ian Bailey 2004-05-10)
Fixed.

Comment: (Ian Bailey 2004-05-10)
Good question. Normally, we would use a requirement instance and assign it. However, required_resource is sort of a requirement in itself. However, by shortcuttting the requirement assignment process we'd end up with requirements being handled in two different ways. Any views ?

Comment: (Mike Ward 2004-01-31)
Classification of Resource_property revised.

Comment: (Ian Bailey 2004-05-10)
Oops! There quite a few of those typos. Now fixed.

Comment: (Ian Bailey 2004-05-10)
I'm not sure if the ISO rules apply, but I've changed it anyway.

Comment: (Ian Bailey 2004-05-10)
Done

Comment: (Peter Bergström 2006-05-18)
Done.

Issue raised against: assigning_reference_data

Comment: (Peter Bergström 2007-05-04)
If a leaf class can also be one of the Express entities, I would say yes (however, that might have to be made clear in the text here). All reference data must always a subclass of something in the AP239 schema.

In order to process OWL correctly, the reference data library that is the most specialized rdl must be identified as the context ontology. The context ontology must include all other rdl's in an exchange file. This should be achieved by classifying the most specialized External_data_library as the "Context_ontology".

Figure 1 —  Possible solution

This template should describe how to achieve this, both in text and using an instance example. An OWL class "Context_ontology" has to be created. Possibly, a specific template has to be developed for this.

Comment: (Leif Gyllstrom 07-04-23)
This issue has been moved from the template 'assigning_reference_data', since the context ontology should only be refered to once within a message. However, the usage of context ontology should also be mentioned within the assigning_reference_data capability.

Comment: (Peter Bergström 2007-05-04)
Any External_class_library entity representing a specific, identified RDL should only be instantiated once in a data set (although there is currently no uniqueness constraint in the template to that effect, which I think is incorrect, see issue PBM-3 for template assigning_reference_data). That fact makes this capability just the correct place to do it. What would be a better place?

Comment: (Leif Gyllstrom 05-06-13)
Version 1.9 is reset to the content of version 1.6

Comment: (Leif Gyllstrom 05-06-13)
Done

Comment: (Leif Gyllstrom 05-06-23)
Done

Comment: (Leif Gyllstrom 05-06-23)
Done

Comment: (Leif Gyllstrom 05-10-06)
Removed the usage of Attribute classification as the means of controlling standard values. Added a section under Additional usage guidance.

Comment: (Leif Gyllstrom 05-10-06)
Done

Comment: (Leif Gyllstrom 05-10-06)
Added information about 15926 and PartsLib.

Comment: (Leif Gyllstrom 05-06-23)
Added in both textual description and in the template.

Comment: (Leif Gyllstrom 05-06-23)
All figures replaced

Comment: (Leif Gyllstrom 05-06-23)
Added section under Additional usage guidance. However, recommendation is to use PLCS standard class 'Unknown'

Comment: (Leif Gyllstrom 05-06-23)
Added section under Additional usage guidance

Figure 5 in assigning_reference_data template shows Class.description="/IGNORE" and External_class_library.description="$" They should be consistent.

The following attribute values are permitted:

• Empty string '' indicates user data managed by the sending system but not provided for data exchange.
• String '/NULL' indicates user data in a mandatory attribute that is not managed by the sending system or currently not known.
• $ is used in the physical file, if an optional attribute is not instantiated.
• Attribute values are set to '/IGNORE' when the information that could be held be the attribute is instead assigned to the instance of the entity.

Based on this, the following attributes should be set: External_class_library.description="$" Class.description="$"

Comment: (Leif Gyllstrom 05-09-21)
Rejected. Guidelines for populating non-used attributes has changed in accordance with the approach used in the figure.

Comment: (Leif Gyllstrom 05-10-03)
This is provided by the template assigning_business_specific_reference_data.

Comment: (Leif Gyllstrom 05-10-04)
Added

Comment: (Rob Bodington 06-01-17)
Corrected

Comment: (Leif Gyllstrom 2007-05-03)
The figures being adressed belongs to a template that has been deprecated.

Comment: (Rob Bodington 06-01-19)
Corrected

Comment: (Leif Gyllstrom 2007-05-03)
The mentioned inconcistensy only appears in the template that has been deprecated.

Comment: (Leif Gyllstrom 2007-05-03)
The mentioned inconcistensy only appears in the template that has been deprecated.

Issue raised against: messaging

Comment: (Rob Bodington 07-01-31)
This has been raised as SEDS #1135 roblem Description: The use of message always requires the use of the escape mechanism to reference items, whereas, in some cases an AP may wish to restrict the usage to particular entities. Suggest: The entity Content_item should be subtyped (oneof) to Content_item_selected and Content_item_reference Content_item would become an abstract type, and the current attributes migrated to Onservation_item_reference Content_item_selected would have a single attribute pointing to an extensible select. Additional Notes: An AP could chose to define the set of things an observation is restricted to by a rule allowing only the Content_item_select subtype and extending the associated select.

Comment: (Rob Bodington 07-01-31)
The model diagram in the template has been modified to show Content_item_selected. The EXPRESS needs to be modified and the SEDS addressed.

Comment: (Sean Barker 2004-03-08)
Revised Messaging now satisfies the requirement.

Comment: (Sean Barker 2004-6-10)
Additional section added on semantics of Acknowledge.

Comment: (Sean Barker 2004-4-26)
Should be raised as issue against Envelope module, where categories should be an enumeration.

Comment: (Sean Barker 2004-4-26)
Issue raised against Envelope Module

Comment: (Sean Barker 2004-4-26)
Corrected

Comment: (Sean Barker 2004-4-26)
Corrected

Comment: (Sean Barker 2006-2-24)
Done

Issue raised against: report_activity_progress

Issue raised against: representing_activity

The template assigning_activity only contains the entity applied_activity_assignment (classified) without other options (see characterization).

There is a general issue about separate templates for assignments, the usage of optional associations in the template versus creating bigger templates with explicit definitions of the content as well small templates referencing each other which needs to be considered.

Proposal: New template assigning_actual_activity (asg_act_act) containing the entities applied_activity_assignment (classified), activity_actual (identified), activity_method (identified, classified).

Representing_activity has a mandatory reference to assigning_time. This is very restrictive and most likely not needed normally, if the source data doesn't contain data on start time then it will be impossible to populate. It should therefore be possible to exchange activity data without identifying date_time.

Proposal: Make time optional in all templates in Representing_activity (assigning_activity, representing_typical_activity, representing_planned_activity, representing_product_usage, representing_activity_actual, assigning_work_output, ...).

Comment: (Peter Bergström 2007-05-24)
Do you have the date in your source data, or in the source system? If so, I think you just set the hour to "12" or "0" or what you like, and it works fine with assigning_time. But if you don't even have the date, I think we have a problem. To me, its a minimum requirement when reporting activities to say what date it was. I'm very hesitant at making asg_time optional, because I think it almost makes the template unnecessary... What do other projects think? Should all dates and time be optional for all activities (even planned and actual)?

The template assigning_activity only contains the entity applied_activity_assignment (classified) without other options (see characterization).

There is a general issue about separate templates for assignments, the usage of optional associations in the template versus creating bigger templates with explicit definitions of the content as well small templates referencing each other which needs to be considered.

Proposal: New Template assigning_activity_method (asg_act_meth) or extension of the existing assigning_activity (asg_act) containing the applied_activity_assignment (classified), activity (classified), activity_method (identified, classified).

Note: differs from the DVN-10 in use of entity activity_actual vs. activity.

Comment: (Rob Bodington 06-06-21)
This has been clarified in the text.

Comment: (Rob Bodington 06-06-21)
The activity_method_realization is not brought into the capability as that would bring in Task etc which are deliberately out of the scope of this capability. The intent is to provide the minimum required to represent activity. The text has been reworded.

Comment: (Rob Bodington 06-06-21)
The text has been reworded

Comment: (Rob Bodington 06-06-23)
The typical activity is used to provide a specification of the activity that could take place. If the activity can be described, then it is typical.

Comment: (Rob Bodington 04-03-27)
activity_method_realization is part of scheme and task capability. So excluded from the usage

Comment: (Rob Bodington 06-06-21)
See 2-TJT

Comment: (Rob Bodington 04-03-26)
Changed the figure title to "Application of planned and actual activities to products."

Comment: (Rob Bodington 04-04-27)
Addressed as suggested.

Comment: (Rob Bodington 04-03-27)
Added to diagram,

Comment: (Rob Bodington 04-03-27)
activity_method_realization is part of scheme and task