[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?
Peter,
To answer directly; no, and no
(neither).
The basis of typical activity is provided in C032 -
representing_activity - see Fig 3, it is an activity_method.
There is no entity called typical_activity (though it
might have been a good idea, for clarity and consistency
elsewhere).
Tim From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 31 January 2006 10:41 To: 'Tim Turner'; 'Gyllström Leif'; 'Gordon Robb' Cc: plcs-dex@lists.oasis-open.org 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 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]