RE:

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

Title: RE:

1) Most of the examples seem to be properties:

    a) Name the property ("measured pressure")

    b) represent the property - have fun with representation, representation item, representation context, value with global units. There is a capability for representing properties. As an example of how to make things up at the representation level, you could do better than look at probability and probability distribution, but I couldn't say where.

 

NB: I'm not sure how PLCS should go about defining properties, since agreeing the representation of a properties goes beyond simply recording the property name as reference data, but requires the representation model to be defined.

 

2) Work out what it is being assigned to, and use the appropriate assignment (things, processes and resources have different assignment models, for various reasons).

 

3) Each measurement must be the result of an activity_actual (see activity_as_realized module) related to the defining activity by an activity_happening. Complex activities structures can be constructed through the activity_relationship.

 

4) An activity can use a task to describe activity_method - note task is always a definition - the assertion that a task was done is made by using the task as the method of an activity_actual. A product_as_individual may be assigned to the task through a task_assignment, however, since a task is a definition, it would be a moot point whether this holds the semantics that the task was done on this item. Better to use an activity_method_assignment with an appropriately named role.

 

5) The measured item, if it is indeed an item, can be asserted also by an activity_method_assignment with appropriately named role (don't forget to add the role into reference data). If no such item exists - that is, it is not predefined in the standard product structure, then you will need to define it through one of the breakdowns.

 

Therefore I guess that you don't need any extra entities. I hope this helps.

 

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: Les Debenham [mailto:lad@LSC.CO.UK]
Sent: 01 March 2004 15:39
To: PLCS-MODELERS-L@ATICORP.ORG
Subject:

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.

     Keep this in mind if you answer this message.

Modellers all,

Ian Hickman is working with me on implementations and has come up against some brick walls. To put it in context we are working on recording the results of tasks carried out on a product. The activates are recurrent and could be weekly, monthly, (or even recorded automatically at a frequency of 50hz). We need to ensure the results (of the activity) are recorded in context of the planned activity, the parent task, the actual product the activity was carried out on and the date time of the measurement.

Can he achieve his requirements using existing entities or do  we need his new entities?

Advice from the old (experienced?) hands at STEP is urgently requested.

Note:
I have sent this on the OASIS DEX exploder and the old PLCS modellers exploder in case some of you have yet to transfer. Sorry for any duplications this causes.

Please include Ian in your replies as he is not yet on the exploders

Les Debenham
LSC Group Ltd.
PO Box 77 Devonport House
Durley Park, Bristol BS31 2YH

Tel: +44 117 916 1464
Fax: +44 117 916 1499
Mob: +44 7739 306799
www.lsc.co.uk

 -----Original Message-----
From:   Ian Hickman 
Sent:   01 March 2004 13:38
To:     Les Debenham
Subject:       

I am new to STEP so please forgive any naiveties and a few deliberate simplifications.  The basic problem is that I need to model a series of task activities and their corresponding actual activities. The activities are basically to take measurements of various physical properties of a system e.g. hours run, various pressures, temperatures etc. I have found no way in the STEP model to represent this. I have found something similar for resources (i.e. 'Required_resource_by_resource_item'). I have tried to use this principle to  meet my requirements.

Consider the following:

I need the values.

e.g.

Measured_value
        Value   = 2431234      
        Unit    = Hours

Or

Measured_value
        Value   = 1.8
        Unit    = BAR

I then need to associate the value measured with the item measured

Measured_item   
        Name            = Engine Running total

Or

Measured_item          
        Name            = Inlet Pressure

I need to combine the two i.e.

Measured_value_by_Measured_item     (c.f. Required_resource_by_resource_item!)
        Name                    =  ''
        Measured_value          Measured_value
        Measured_item           Measured_item
e.g.
measured_value (2431234, hours), measured_item (engine running total)

However I note there is not currently such an entity as Measured_value_by_Measured_item





I then need to assign the results to the Activity_Actual (e.g. individual test).

Measured_value_assignment              (c.f. Required_resource_assignment!)
        Assigned_result         Ref Measued_value_by_Measured_item
        item : Activity                 Ref Activity_Actual

e.g.
Assigned result (measured_value (2431234, hours), measured_item (engine running total), Activity_actual (123)




Summary:
To try to illustrate what I am trying to achieve I have invented the following ENTITIES
Measured_item,
Measured_value_by_Measured_item, 
Measured_value_assignment . .    

Are these necessary or is there a better way of doing this?   

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************