[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Assignment of Time properties - to task or person?
|
Tim, When you say ‘typical activity’,
are you referring to the entity Activity then, as opposed to Directed_activity
or Activity_actual, or are you envisaging the creation of a new (sub-type)
entity? Peter -- Peter Bergström From: Tim Turner
[mailto:tjt@lsc.co.uk] Thanks Gordon, you are quite correct in
stating the requirements, but the modelling aspect is not always 1:1 with
reality, nor is it always efficient to do so. At the task level this is
effectively a quantity measure (of time) of a required resource (type
of person) who has a certain skill. At the planning level, more or
less time might be allotted depending upon other factors not applicable at the
time the effort was predicted. Hence it is (task-wise) a quantity (time) that
has to be associated with the resource_item (person), rather than the actual
time taken or the time allotted to the task itself in any particular plan. My earlier solution was
correct, but not optimal. Having discussed with Leif G. we both realised that
rather than use an assigned_property, we should really use a resource_property,
on the principle that the time required is a property of the required resource
- and that most assigned_properties are assigned to products, not resources
(but there's no hard rule anywhere to state this). The revised slide is
attached. This raised some
questions about how to separate the functions of task and activity representation
across the Dexs, and the separation between them. Tasks can (and are) defined
as part of the support solution against the design of the product. Activities
entered into a plan are defined with an individual occurrence of the product in
mind and provide the authority for either a typical (set) of activities to be
carried out, or an identified subset of the typical, or perhaps identified
tasks within several typical sets (or even a combination). The level of refinement
and specification of resources realized for a planned activity, however,
cannot reproduce those defined at levels below that of the task. That is, there
is not a direct equivalent of a task_element (or subtype) within the
model for activities. In order to achieve this requires re-creating the task
and it's components. The model supports
typical activities or groupings of tasks to an instance of activity_method
through activity_method_realization relationships. Hence a typical activity
might be defined to address a specific issue or maintenance requirement. Within
Dex4, at the planning level the whole of the typical_activity may be authorized
to proceed as a work item. However, equally as likely, is that the typical
activity will be approved, but only specific tasks (or task_elements) within
will be authorized through an applied_activity_assignment. Where there are no
typical activities defined, the model allows the planned activity to identify a
(single) task as it's chosen_method, and to identify the task_elements to be
carried out through an instance of applied_activity_assignment (as
necessary). However, this is unsatisfactory if more than one task is
required for the activity. [Thus the reasoning behind a Typical Activity].
There is one other mechanism that can achieve this, but requires the use of a
hierarchical structure (one deep) built using activity_method_relationships
between both sub-activities and tasks on one hand and activity_relationships
between the main <planned> activity and the sub-activities. While the prior mechanism
for dealing with sets of tasks makes use of activity_method as a collector, and
is perhaps simpler, if this is not present within Dex3, it will hinder
interoperation. However, the latter mechanism would require an almost mirroring
of the task structure revealing a more complicated model, but one which might
provide the ability to assign resource refinements at the level of
task_elements when planning. Task elements are
important when considering planning for multiple tasks since some tasks will
naturally overlap in some of their initial preparation elements or closedown
operations. E.g. 3 tasks dealing with a car engine might require the
bonnet(hood) to be opened in preparation as the first task_element in a
sequence, but this element only needs to be planned for once if the activities
can be scheduled together. Hence, authorising only those required is of
interest. Of course different
planning systems will have different capabilities and requirements in these
matters. For basic planning systems it could be assumed that resource
realizations will apply to those defined at the task_method_version level and
all those elements subsumed, whereas for those systems planning in
greater detail, realized resources may be applied at either the task_method_version
or at the individual task_element level. The use of a typical
activity does not preclude the ability to define a hierarchy of (sub)activities
to further identify resources being realized at the level of task_elements, but
the exclusion of activity_method from Dex3 to regards, Tim From: Gordon
Robb Tim, In respect to a DEX 4
requirement I would consider that the recipients require to know the skill set
and man hour duration required to complete the task. In respect to Air
Technical Publications each work card provides the skill set and man-hours
required therefore your option 2 is the better option On feedback of the task
[DEX 9] the recipients may have used 2 men and done it in 2 hours, and/or used
a higher skill set [technician/artificer] Gordon From: Tim
Turner Thanks Leif, I found several different
approaches in Dex3 & task related capabilities, but my example seems not to
fit squarely into these. We are not dealing with the actual time (as recorded)
here either (yet), though I see your point regarding the realized/actuals. It is not
possible to create a required_resource_by_resource_item for time, as
this is not defined as a resource_item. That is, time itself, cannot be
modelled as a resource on it's own. The only mechanism appears to be
through another resource_item, like you mention, which was my clumsy way of
explaining option 1. Having defined a type_of_person representation already,
I can also use the (mandatory) type_of_person_definition to point at using
the assigned_property.described_element. As you also hinted, person &
organization etc., are also in the property assignment select type list. I attach 2 slides to
illustrate, but I think your third way - is my option 1. But of course I could be
missing your entire point... regards, Tim NB - On an entirely
separate note (to ALL), is there general consensus that where quantity
information is not provided for an item (e.g. resource), that by default
only a single item is inferred? From: Gyllström
Leif [mailto:leif.gyllstrom@aerotechtelub.se] Tim I'd say that you shall
use a third alternative : -
Required_resource, and
assign a property to Required resource representing planned required time -
Resource_as_realized and
assign a property to Resource_as_realized representing actual time Then you can use a
consistent approach regardless of whether you use a Person, Type_of_person,
Oragnization or Organization_type as the
Resource Regards Leif From: Tim Turner [mailto:tjt@lsc.co.uk]
The time required to perform a task, by 1 (mechanic) person is 4 hours. Looking at the model, I see that it is possible for me to represent this
in one of two ways; 1. By modelling the duration as an assigned_property of the (resource)
type_of_person_definition - i.e. 1 mechanic required for 4 hours or, 2. By again modelling the duration as an assigned_property, but this
time associated with the task_method_version_assignment instance. The fundamental question is whether the time required (duration) should
be a function of the task, or as a function of the person. Note: this task may be assigned to more than one item through the
task_method_version_assignment. However, the time required is for each task,
thus option 2 forces each item to have it's own task_method_version_assignment
and a repetition of the duration property for each. The alternative, option 1,
assigning the duration to the resource_property would appear to make more
sense, since the duration may change if the skill level of the person assigned
changed. Is this in agreement with other modeller views? Kind regards, NB. Option 2 might be used where the effort is defined in terms of each
item that the task is defined/used with. E.g. if for item a) the task takes 4
hours, but for item b) the time is 5 hours. Option 1 appears best used if the time is the same for all items that
the task is applicable to. ************************************************************************* DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY
MARKED*** The information in this message is confidential and may
be legally privileged. It is intended solely for the addressee. Access to
this message by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, or distribution of the message, or any
action or omission taken by you in reliance on it, is prohibited and may be
unlawful. Please immediately contact the sender if you have received this
message in error. This e-mail originates from LSC Group. Registered in England
& Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport,
Plymouth, PL1 4SG DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]