action or a set of actions that consume time and resources and whose performance is necessary to achieve, or
contribute to, the realization of one or more outcomes
Notes:
NOTE 1:
The action or set of actions is something that has taken place, is taking place, or
is expected to take place in the future.
Examples:
EXAMPLE 1:
Changing the design of a bicycle
EXAMPLE 2:
Designing a bicycle
EXAMPLE 3:
Training someone to ride a bicycle
Sources:
ISO 10303-239ed2 transformed to AP239AP233 PSM
ISO/IEC 15288:2003, "Systems and software engineering - System life cycle processes"
[2012-09-17] Mike Ward, Eurostep: dc:alternative added
[2012-08-30] Mike Ward, Eurostep: "{action http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#action}s"
changed to "{actions http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#action}s"
in rdfs:comment and in skos:definition.
[2012-08-23] Rob Bodington, Eurostep: Updated to reflect editorial comments from TNC
and changed state to passed_review
[2012-05-14] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
association of an method with a scheme or task that puts it inot practice
Notes:
NOTE 1:
More than one specification can be associated with the same ActivityMethod.
Examples:
EXAMPLE 1:
For a given planned activity there may be a task specification, a statement of how
task performance is to be logged and a schedule that all apply.
NOTE 1:
An activity method realization relationship may be used to specify sequencing and other constraints between different realizations
for the same method.
EXAMPLE 1:
The activity required to complete a work order, may be decomposed into many sub-activities. These can be related using activity relationships.
[2012-08-30] Mike Ward, Eurostep: "{person In an organization http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PersonInOrganization}"
changed to "{person in organization http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PersonInOrganization}"
in rdfs:comment
[2012-08-30] Mike Ward, Eurostep: "{http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Organization}"
changed to "{organization http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Organization}"
in rdfs:comment
[2012-08-23] Rob Bodington, Eurostep: Updated to reflect editorial comments from TNC
and changed state to passed_review
[2012-05-23] Rob Bodington, Eurostep: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
An AlternateProductRelationship is an association between two instances of Product.
It specifies that any version of the AlternateProductRelationship, may be used in
place of any version of the baseProduct. The relationship established by the AlternateProductRelationship
is not symmetric: if B is an alternate product for A, A is not implied to be an alternate
product for B
Notes:
NOTE 1:
An AlternateProductRelationship for which the baseProduct is an assembly involves
that the entire product structure of the alternateProduct may be used in place of
the baseProduct and its product structure.
NOTE 2:
An AlternateProductRelationship may relate products of any kind, provided both related
instances of Product identify products of the same kind, for example part-part or
document-document.
NOTE 3:
An organization may track design changes for a base part, and establish effectivity
conditions for the use of that base part in various assemblies to be manufactured.
The use of an alternate product implies that an organization does not specify any
particular version of the alternate product nor establish effectivities relating to
it.
NOTE 4:
If a product is an alternate for another product, it is understood that there is no
interest to keep track of which product, the base or any alternates specified, is
used as a particular instance of the base product within a product structure.
Examples:
EXAMPLE 1:
Two bolts of the same size are products. One bolt has a square head and the other
has a hexagonal head. The two bolts are considered equivalent with respect to form,
fit, and function: they both have sufficiently close physical shape, they take up
the same space when used, and they both serve to fasten two things together. Thus,
one of these two bolts could be considered to be an alternate part for the other bolt.
An Analysis is a specialization of Product. It is produced via a reproducible process
Notes:
NOTE 1:
Analysis is the process of studying or examining something in an organized way to
learn more about it, or a particular study or examination of something. The full range
of the analysis process includes mathematical, physical testing, cognitive, chemical,
etc.
An AnalysisDisciplineDefinition is a specialization of ProductViewDefinition. It is
a definition or view of an AnalysisVersion taken from the perspective of the analysing
organization. The AnalysisDisciplineDefinition is controlled by the analysing organization.
The entity may be used to capture the definition of a particular version of an analysis
at any intermediate stage of its development where the definition is not formally
released by an organization at the analysis version level. It may be used to capture
the various stages in the definition cycle of a product
A AnalysisVersionRelationship is a specialization of ProductVersionRelationship that
is used to assert an association between two versions of an analysis
A AnalysisVersionSequence is a specialization of AnalysisVersionRelationship that
is used to assert that the one analysis version (the successor) replaces another (its
predecessor)
An AndStateCauseEffectDefinition is a specialization of StateCauseEffectDefinition.
It relates one or more causing StateDefinition entities and one effect StateDefinition.
All the causing StateDefinition entities must exist prior to the single effect
relationship that indicates that an AssemblyViewRelationship may be substituted by another AssemblyViewRelationship.
Both assembly relationships shall refer to the same ProductViewDefinition of the same
assembly. An AssemblyRelationshipSubstitution defines a one-way substitution: if A
is specified as a substitute for B, B is not implied to be a substitute for A
Notes:
NOTE 1:
As instances of AssemblyViewRelationship establish assembly relationships relevant
in the definition contexts of the assembly, the substitution only apply in these contexts.
NOTE 2:
Consequently, an AssemblyRelationshipSubstitution actually specifies that the product
version that plays the role of component in the substituteRelationship may be replaced
by the product version that plays the role of component in the baseRelationship.
NOTE 3:
The instance of the substitute constituent does not require the same spatial relationship
or the same quantity. A substitute constituent does not require equivalent form, fit,
and function of the constituent for which it is a substitute.
NOTE 1:
An assembly component relationship identifies a (possibly quantified) use of a product view as a component of another product view
NOTE 2:
In different contexts, the structure of an assembly may be described differently.
One assembly description may, for example, may define an intermediate level between
two product versions that is absent from another assembly description.
NOTE 3:
An assembly component relationship may be used to establish assembly relationships during design or to represent the
composition of an assembly existing in the real world.
[2012-09-05] Mike Ward, Eurostep: rdfs:comment and skos:notes edited
[2012-08-28] Mike Ward, Eurostep: Renamed from AssemblyComponentRelationship to AssemblyViewRelationship
and moved from ProductOccurrenceDefinitionRelationship to ViewDefinitionRelationship.
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
An Assumption is the identification of something assumed to be true without proof.
The reason or justification for an assumption being made shall be represented by a
JustificationAssignment being assigned to the Assumption. The item that is assumed
shall be related to the Assumption by an ItemAssumed
Examples:
EXAMPLE 1:
An activity is planned based on the assumption that the resource required to perform
the activity is available at a location.
NOTE 1:
nominated position (or place) on a product where a part specification is attached or can be attached
Examples:
EXAMPLE 1:
A fast jet aircraft has two engines. These engines are removable and interchangeable
between individual aircraft. An attachment slot represents each installation position
for an engine so as to ensure that an accurate record is maintained of which engines
fly in which pairing on which aircraft for how many hours.
[2012-08-30] Mike Ward, Eurostep: "{part http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Part}s"
changed to "{part specifications http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Part}s"
in rdfs:comment.
[2012-08-29] Mike Ward, Eurostep: In skos:note, "Partt" changed to "Part".
[2012-08-23] Rob Bodington, Eurostep: Updated to reflect editorial comments from TNC
and changed state to passed_review
[2012-05-14] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
An AttachmentSlotAsPlanned is a specialization of AttachmentSlotVersion that identifies
an individual that is the subject of a plan to realize an AttachmentSlot
Examples:
EXAMPLE 1:
FlyFasterWithUs Group will buy an aircraft with serial number 1234 next year. The
company wishes to plan the schedule for removal of engines from the aircraft for maintenance
purposes. Instances of the AttachmentSlotAsPlanned entity data type allow the company
to associate individual engines with the aircraft at different times over the planned
period.
An AttachmentSlotAsRealized is a specialization of AttachmentSlotVersion that identifies
an individual that is a realized AttachmentSlot
Examples:
EXAMPLE 1:
FlyFasterWithUs Group operates an aircraft with serial number 1234 next year. The
company records which individual engines power the aircraft at different times during
the lifetime of the aircraft.
An AttachmentSlotDefinition is a specialization of ProductViewDefinition that identifies
a view of an AttachmentSlot
Examples:
EXAMPLE 1:
An airworthiness authority requires an airline company to report which individual
engines power the aircraft at different times during the lifetime of the aircraft.
An AttachmentSlotDesignToPlanned is a relationship between a design version of an
AttachmentSlot and a planned individual that conforms to the design
Examples:
EXAMPLE 1:
WeMakeBigPlanes Limited plans production of aircraft serial number 1234 with a starboard
engine attachment slot that is to conform to design version 1.34.
An AttachmentSlotDesignToRealized is a relationship between a design version of an
AttachmentSlot and a realized individual that conforms to the design
Examples:
EXAMPLE 1:
WeMakeBigPlanes Limited builds aircraft serial number 1234 with a starboard engine
attachment slot that conforms to design version 1.34.
An AttachmentSlotOnProduct is a relationship between a product and an AttachmentSlot
that is a location on the product at which to install removable parts
Examples:
EXAMPLE 1:
An aircraft has a pylon mounting on a wing as a location at which to install various
equipment. An instance of the AttachmentSlotOnProduct entity data type identifies
which attachment slot corresponds to the pylon.
An AttachmentSlotVersion is a specialization of ProductVersion that identifies a version
of AttachmentSlot
Notes:
NOTE 1:
This is a generic concept of version, in most situations it is possible and more specific
to represent a version as AttachmentSlotDesign, AttachmentSlotAsPlanned or AttachmentSlotAsRealized.
An AxisPlacement is a specialization of DetailedGeometricModelElement that defines
a right-handed, 2D or 3D, coordinate system. If the AxisPlacement belongs to a 3D
geometric space, the third direction of the coordinate system is defined by the vector
product of x-axis and y-axis. An AxisPlacement may be an AxisPlacement2d or an AxisPlacement3d
[2012-08-30] Mike Ward, Eurostep: "{breakdown element http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#BreakdownElement}s"
changed to "{breakdown elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#BreakdownElement}s"
in rdfs:comment.
[2012-08-23] Rob Bodington, Eurostep: Updated to reflect editorial comments from TNC
and changed state to passed_review
[2012-05-14] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A CartesianTransformation2d is a specialization of DetailedGeometricModelElement.
It is defined in a 2D geometric space by a 2*2 matrix and a cartesian point. Let be:
M, the 2*2 multiplication matrix of the cartesian transformation; A, the point of
the cartesian transformation; P, a point in the geometric space; Q, the result of
the application of the transformation to P. The coordinates of Q shall be obtained
by the formula: Q = M*P + A
A CartesianTransformation3d is a specialization of DetailedGeometricModelElement that
is a geometric transformation defined in a 3D geometric space by a 3*3 matrix and
a cartesian point. Let be: M, the 3*3 multiplication matrix of the cartesian transformation;
A, the point of the cartesian transformation; P, a point in the geometric space; Q,
the result of the application of the transformation to P. The coordinates of Q shall
be obtained by the formula: Q = M*P + A
A CausalConsequence is a specialization of ViewDefinitionRelationship that identifies
secondary effects related to or resulting from a particular RiskConsequence
Notes:
NOTE 1:
A CausalConsequence is considered as an aftereffect of an immediate CausalConsequence.
An CollectionVersionRelationship is a specialization of ProductVersionRelationship
that represents an association between two CollectionVersion instances
Class label: Collection version sequence relationship
Class specification
Description:
An CollectionVersionSequenceRelationship is a specialization of CollectionVersionRelationship
that represents a sequential association between two CollectionVersion instances
EXAMPLE 1:
A set of data relevant to the design of the SS Titanic and a set of data relevant
to the as-built description of the SS Titanic might be represented as two instances
of collection view definition.
A ComponentUpperLevelIdentification is a specialization of AssemblyViewRelationship.
It identifies a component of an assembly with respect to an upper level in the assembly
structure. The identified component is the version of product, indirectly referred
to as the ProductOccurrenceDefinitionRelationship of the subAssemblyRelationship.
The upper level assembly is the version of product, indirectly referred to as the
ProductOccurrenceDefinitionRelationship of the upperAssemblyRelationship
Notes:
NOTE 1:
A ComponentUpperLevelIdentification does not add a component in an assembly, it provides
a means to further characterize a component with respect to an upper level assembly.
Examples:
EXAMPLE 1:
A ComponentUpperLevelIdentification may be used to assign a property to a component
that applies in the context of a particular upper level assembly.
A CompositionOfState is a specialization of state relationship and it relates the
nature of states in relation to one another, where two or more State parts compose
a whole State; and furthermore, whole states can become parts of yet another whole
State
A CompositionOfStateDefinition is a specialization of StateDefinitionRelationship.
It relates StateDefinition entities to one another, when two or more StateDefinition
entities act as parts to compose a whole StateDefinition; and furthermore, whole StateDefinition
entities can become parts of yet another whole StateDefinition
A ConcurrentElements is a specialization of StructuredTaskElement that comprises a
set of actions to be performed during the time required for the longest task. No specific
order is required
A ConditionEvaluation is a record of the evaluation of a Condition and the subsequent
result
Examples:
EXAMPLE 1:
A Condition is "If the measured value of oil pressure from gauge 3 on a car is less
than 2 bar then check the oil level" When the condition is evaluated it is recorded
by an instance of ConditionEvaluation. The measured value of oil pressure from gauge
3 on car with VIN 12345678 is 1.9 bar. Therefore the result of the evaluated the condition
is true.
A ConditionEvaluationParameter is an identification of the product or activity data
used in the evaluation of the Condition identified by the ConditionEvaluation
Notes:
NOTE 1:
The product or activity data is defined in . The contents of this select type are
defined in application modules that use this module.
Examples:
EXAMPLE 1:
The measured value of oil pressure from gauge 3 on car with VIN 12345678 (value =
1.9 bar).
EXAMPLE 1:
"If the engine has been running for 10000 hours AND the engine is fitted with a clog-up-quick
Oil filter then change the oil filter" is an example of two conditions related by
a logical AND.
A ContextualItemShape is a specialization of ItemShape that identifies the shape of
a product version in the context of its use in another product version. The product
version whose contextual shape is identified, is the product version associated with
the ViewDefinitionRelationship of the ViewDefinitionUsage
Examples:
EXAMPLE 1:
Flexible part may have several shapes, each associated with a particular occurrence
of the part in assemblies.
[2012-08-30] Mike Ward, Eurostep: "{descriptor http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Descriptor}s"
changed to "{descriptors http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Descriptor}s"
in rdfs:comment.
[2012-08-29] Mike Ward, Eurostep: rdfs:comment added.
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A DetailedGeometricModelElement is a specialization of RepresentationItem. It identifies
a geometric construct. Only non abstract specializations of the DetailedGeometricModelElement
entity data type can be instantiated
file that contains computer interpretable data and is stored on an electronic device or
on optical, magnetic, or electronic media, or a combination thereof
A DistributionByValue is a specialization of ProbabilityDistribution that explicitly
lists pairs of random variable values and function values
Notes:
NOTE 1:
DistributionByValue is used where there is no named distribution which can be used
to identify the distribution, for example, when the distribution is derived from observation.
An ElementConstraint is a specialization of TaskElementRelationship that signifies
a constraint between TaskElements. The constraint may only apply within the context
of a TaskMethod or TaskElement, specified as the context
historical record of the transmission of a message
Notes:
NOTE 1:
Envelope is used to record the audit data for sending and acknowledging a message. Because it is an historical record, each envelope is only used once and so is not versioned.
An EnvironmentDefinition is a specialization of Product that is used to identify the
definition of typical environment in which a product is to be, has been or is planned
to be deployed in, operated in, or supported in
A EnvironmentDefinitionView is a specialization of ProductViewDefinition that provides
a view of a version of an environment definition relevant for one or more application
domains. This view collects the characteristics that define an environment
Notes:
NOTE 1:
The characteristics include the resources available, the locations in which the product
is to operate as well as climatic conditions such temperature ranges.
Class label: Environment view definition relationship
Class specification
Description:
A EnvironmentViewDefinitionRelationship is a specialization of ViewDefinitionRelationship
that represents an association between two EnvironmentDefinitionView instances
collection of items used together to provide a single piece of evidence within a Validation or ]verification http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#Verification]
Examples:
EXAMPLE 1:
For example a document and its approval by a customer may be used together to provide
evidence of customer acceptance
An ExperienceInstance is a particular episode of contact with and/or observation of
facts or events which contributes to the accumulation of knowledge or skill. The nature,
duration and worth of the ExperienceInstance can be described using assigned properties
or by referring to activities or tasks
Examples:
EXAMPLE 1:
100 flying hours in a Tornado jet.
EXAMPLE 2:
2 years work on same type of milling machine.
[2012-08-30] Mike Ward, Eurostep: {property definition} changed to {property} in skos:note
and {property http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#property}
changed to {property http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#property}
in skos:comment
[2012-08-30] Mike Ward, Eurostep: dc:alternative added
[2012-08-24] Rob Bodington, Eurostep: Updated to reflect editorial comments from TNC
and changed state to passed_review
[2012-05-15] Rob Bodington, Eurostep: Updated to conform to defined rules for definition
and annotation properties
[2012-01F-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
measurable quantity, dimension, or magnitude adopted as a basis or standard of measurement
for other quantities of the same kind and in terms of which their magnitude is calculated
or expressed
Examples:
EXAMPLE 1:
Ohm is the unit of electrical resistance
EXAMPLE 1:
A service manual may contain graphics for explanatory reasons. In this case, the File
instances that contain the graphics are referenced as related from the File instance
that contains the body of the service manual with DocumentDefinitionRelationship 'reference'.
NOTE 1:
The functional breakdown is a partitioning of a product into a set of related functional elements so as to form explicit, parent-child views.
Examples:
EXAMPLE 1:
A functional breakdown provides a decomposition of an aircraft in terms of high-level processes such as
"flight" and "taxiing" all the way down to low-level functions such as "detect onboard
fuel level", "move tail rudder", and "provide standard tow attachment point".
[2012-08-31] Mike Ward, Eurostep: rdfs:comment, skos:note, and skos:example revised
to reflect decisions from 2012-08-30 review
[2012-08-30] Mike Ward, Eurostep: "{functional elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#FunctionalElement}s"
changed to "{functional elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#FunctionalElement}s"
in rdfs:comment.
[2012-08-30] Mike Ward, Eurostep: "comprising of" changed to "comprising" in rdfs:comment.
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-08-31] Mike Ward, Eurostep: skos:example revised to reflect decisions from 2012-08-30
review
[2012-08-30] Mike Ward, Eurostep: "{functional element}s" changed to "{Functional
elements}" in skos:note
[2012-08-30] Mike Ward, Eurostep: "{breakdown element}" changed to "{breakdown element
http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#BreakdownElement}"
in skos:comment
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A GeometricPlacementOperation is a specialization of DetailedGeometricModelElement.
A GeometricPlacementOperation may be a GeometricPlacement or a GeometricOperatorTransformation
A GlobalLocationRepresentation is a type of LocationRepresentation specified using
geographic means in the global system and values, which could be physical or political
geographic values
A HierarchicalInterfaceConnection is a specialization of InterfaceConnection that
provides an interconnection between components at different levels in an assembly.
Each connection point in the assembly is represented by a InterfaceConnectorOccurrence
Examples:
EXAMPLE 1:
An appliance such as a television has a power lead and attached plug. The plug and
power lead could be represented as an assembly of parts such as the plug pins and
wires. Each connection point of the pins and wires in the assembly is represented
by a InterfaceConnectorOccurrence and an instance of the HierarchicalInterfaceConnection
entity data type identifies the connection of the pins (the parts) to the plug (the
assembly) in the assembly.
NOTE 1:
This relationship may be classified in other modules to provide more specific meanings.
Examples:
EXAMPLE 1:
ISO is an acronym for "International Standard Organization". When ISO and "International
Standard Organization" are used as identifiers for the ISO organization, they may
be related to indicate that ISO is the acronym for "International Standard Organization".
An InformationRight is a definition of what may or may not be done with information
in the sense of legal rights and obligations
Notes:
NOTE 1:
This a general purpose definition of a right that may be applied to many things. The
usage of the InformationRight is represented by InformationUsageRight. The application
of that right to information is represented by InformationUsageRightAssignment.
Examples:
EXAMPLE 1:
Copyright is an InformationRight.
EXAMPLE 2:
For the purposes of developing a new system, details of government furnished equipment
may be made available to a particular project team. The team may copy and use the
information internally, but may not pass it on, either to a third part, or to another
team, and must destroy the information at the end of the contract.
An InformationUsageRight is an application an InformationRight to a particular usage
context
Notes:
NOTE 1:
InformationUsageRight provides a mechanism for recording significant rights within
a product database. The legal significance of the presence or absence of a right is
outside the scope of this part of ISO 10303
NOTE 2:
One view of the distinction between an InformationRight and an InformationUsageRight
is that the InformationRight represents a standard clause in a contract, whereas an
InformationUsageRight represents the fact that the clause is used in a particular
contract.
NOTE 3:
The Approval of an InformationUsageRight carries the meaning that the right is granted
to all information items in the relevant context, as opposed to the approval of an
InformationUsageRightAssignment which is limited to particular items.
NOTE 4:
The context for the usage can be defined through the contract which defines the right,
the organization that grants the right, the person or organization which is granted
the right, and any dates such as the starting or ending dates for the right. The meaning
of each association is identified through the roles of the assignments, and these
are defined through reference-data.
NOTE 1:
If an approval is applied to this entity, it carries the meaning that the particular
set of items is approved for the given usage. This approval generally indicates that
the approval is exceptional, for example, where the information belongs to another
project, and that project agrees to share some particular items of information. There
is a further implication that the set of entities should not be changed once the approval
is given.
relationship of one InformationUsageRight to another
Examples:
EXAMPLE 1:
Where one InformationUsageRight supercedes another, then the original right is pointed
to by the relating attribute, its replacement by the related attribute, and the relationType
attribute takes the value "supercedes".
A InterfaceConnection is an interconnection between a connected pair of InterfaceConnectorOccurrences.
Each InterfaceConnectorOccurrence represents the place where a product used in an
assembly can interact with other products in the assembly
Examples:
EXAMPLE 1:
An appliance such as a television has a power lead and attached plug. The plug and
power lead could be represented as an assembly of parts such as the plug pins and
wires. Each connection point of the pins and wires in the assembly is represented
by a InterfaceConnectorOccurrence and an instance of the InterfaceConnection entity
data type identifies the connection of the pins to the wires in the assembly.
An InterfaceConnector is a specialization of Product that identifies a part of a product
with which one or more other products or the environment interacts
Notes:
NOTE 1:
This is sometimes referred to as a "port".
Examples:
EXAMPLE 1:
A computer has a socket to which to connect a network cable. An instance of the InterfaceConnector
entity data type identifies the role of the socket in the interface and is the subject
of a specification that defines the necessary geometrical and electrical attributes
to ensure a functioning interface between the computer and network hardware.
An InterfaceConnectorAsPlanned is a specialization of InterfaceConnectorVersion that
identifies an individual that is the subject of a plan to realize an InterfaceConnector
Examples:
EXAMPLE 1:
Company Acme Limited is planning to produce an aircraft with serial number 1234 next
month. This aircraft has connectors on each engine for fuel pipes. The company wishes
to plan when each connector will be realized and then identify a date on which an
inspector can test all the realized connectors.
An InterfaceConnectorAsRealized is a specialization of InterfaceConnectorVersion that
identifies an individual that is a realized InterfaceConnector
Examples:
EXAMPLE 1:
Company WeFlySafest Corporation owns and operates an aircraft with serial number 1234.
When landing at Heathrow airport, the pilot reports a loss of fuel pressure on engine
number 4 with serial number A9876 and recommends that an inspector tests the realized
connector on the engine.
An InterfaceConnectorDefinition is a specialization of ProductViewDefinition that
identifies a view of an InterfaceConnector
Examples:
EXAMPLE 1:
A reliability engineer assesses the likely failure modes of design version 3.8 for
the connector between a brake unit and the hydraulic control system. The engineer
generates a set of data that is a specific view of the connector. An instance of the
InterfaceConnectorDefinition entity data type collects these data together.
Class label: Interface connector design to planned
Class specification
Description:
An InterfaceConnectorDesignToPlanned is a relationship between a design version of
an InterfaceConnector and a planned individual that is to conform to the design
Examples:
EXAMPLE 1:
BuildAWidget Incorporated plans production of pump serial number 30301 with an electrical
supply connector that is to conform to design version 2.10.
Class label: Interface connector design to realized
Class specification
Description:
An InterfaceConnectorDesignToRealized is a relationship between a design version of
an InterfaceConnector and a realized individual that conforms to the design
Examples:
EXAMPLE 1:
BuildAWidget Incorporated builds pump serial number 30301 with an electrical supply
connector that conforms to design version 2.11.
A InterfaceConnectorOccurrence is an occurrence of a InterfaceConnectorDefinition.
The InterfaceConnectorOccurrence represents the place where a product used in an assembly
can interact with other products in the assembly. The interaction is represented by
a InterfaceConnection
A InterfaceDefinitionConnection is an interconnection between a connected pair of
InterfaceConnectorDefinitions or, if the point of interconnection is not specified,
the interconnection between a pair of views ( ProductViewDefinitions) on products
Examples:
EXAMPLE 1:
A socket in the wall provides access to the domestic electricity supply. An appliance
such as a television has a power lead and plug that fits into the socket. An instance
of the InterfaceDefinitionConnection entity data type identifies this fitting of the
plug into the socket.
An InterfaceDefinitionFor is a relationship between an InterfaceSpecification and
an item that conforms to the specification
Examples:
EXAMPLE 1:
The infrared transmitter in a television remote control conforms to the specification
that has the identifier 2345/XYZ/001. An instance of the InterfaceDefinitionFor entity
data type is necessary to identify this relationship.
An InterfaceSpecification is a specialization of Product that provides a definition
of necessary attributes for one or more items that participate in an interface
Examples:
EXAMPLE 1:
BSI develops a standard for connecting domestic electrical equipment to the electricity
supply.
An InterfaceSpecificationDefinition is a specialization of ProductViewDefinition that
provides a view of an InterfaceSpecification
Examples:
EXAMPLE 1:
When developing a BSI standard for connecting domestic electrical equipment to the
electricity supply, collected comments from experts form a new view on a version of
the standard.
An ItemAssumed is an association between an Assumption and the item that is being
assumed
Examples:
EXAMPLE 1:
A facility is assumed to exist at a given location. The facility shall be represented
by a ResourceItemAssignment, the location by a Location, and the existence of the
facility at the location, by a LocationAssignment assigning a location to the resource.
An ItemDesignAssociation is the association of a ProductConfiguration with a ProductViewDefinition
or a ProductVersion. It specifies the design that corresponds to the ProductConfiguration.
If the design is a ProductViewDefinition, the ItemDesignAssociation represents the
statement that, in the considered definition context, the product version, that is,
the ProductViewDefinition is a valid way to implement the ProductConfiguration. If
the design is a ProductVersion, the ItemDesignAssociation represents the statement
that, in all definition contexts, the ProductVersion is a valid way to implement the
ProductConfiguration
Notes:
NOTE 1:
The association might not be valid for other versions of the product.
NOTE 2:
This association might not be valid in all definition contexts of the product version.
An ItemUsageEffectivity is an effectivity domain that constrains the use of a product
with or within another product, in the context of a ProductConfiguration. The effectivityDomain
attribute identifies a domain of effectivity. The itemUsageRelationship attribute
identifies a relationship which characterizes the use of the product with or within
another product. The resolvedConfiguration attribute identifies an association between
a ProductConfiguration and a product that implements it. This attribute establishes
the context in which the itemUsageRelationship is considered and constrained. When
the effectivity domain is a range of serial numbers, the serial numbers considered
are those of the ProductConfiguration. When the effectivity domain is defined using
a production lot number, the production lot considered is one of the ProductConfiguration.
When the effectivity domain is an interval of time, the interval of time considered
is related to the production of the ProductConfiguration
Notes:
NOTE 1:
When no effectivity constraint is applied to a ViewDefinitionUsage, the validity or
applicability status of this ViewDefinitionUsage is unknown.
Examples:
EXAMPLE 1:
This relationship may be an assembly-component relationship or a make-from relationship.
the identification and description of the reasons for something
Examples:
EXAMPLE 1:
A justification may be provided for a product design. Similarly, a justification may be provided for why an activity is needed or was undertaken.
a language in which human readable text is written
Notes:
NOTE 1:
The identification of a language by its code as defined in ISO 639-2 and possibly
its country code as specified in ISO 3166-1. The language is used in an exchange as
defined using BCP47.
NOTE 1:
A LocationAssignment is a relationship between a product, event, or person and a location.
There may be distinct assignment for each qualification. for example planned, scheduled
or actual. Each assignment may have a start and end date or time. A location may have
multiple assignments
A MakeFromRelationship is a specialization of ViewDefinitionUsage established between
two instances of PartViewDefinition. It specifies that, in the context of the definition
of the relating part version, the relating part version is considered as resulting
from the manufacturing transformation of the related part version
Notes:
NOTE 1:
The characterization of the process of transformation from the related part version
to the relating part version it out of the scope of this application module.
NOTE 2:
The related part version may identify a raw material or a semi-finished part.
A ManagedResource is a representation of a resource that is provided with resource
management capabilities. The role of a managed resource is determined by classification
Examples:
EXAMPLE 1:
A managed resource can be classified as "Stock line".
A MeasureQualification is a means to provide information about measurements in which
there is an associated uncertainty. The uncertainty may be specified as precision,
qualitative uncertainty, or expanded uncertainty, and the type of the related datum
shall be included. The uncertainty is defined in clause 2 of "The Guide to the Expression
of Uncertainty in Measurement"
collection of information, brought together by an originator (the message definer)
for some particular purpose, generally the fulfillment of a process
Notes:
NOTE 1:
A message is an historical record, intended to be sent using an envelope and in consequence, is not versioned.
NOTE 2:
The same message can be sent several times using different envelope. Once it has been sent once, it cannot be further changed. However it should not
remain unsent, since that is to confuse its functions and therefore its meaning with
other entities such as one of the types of document.
relationship between two related messages. The meaning of the association depends on MessageRelationship.role
Examples:
EXAMPLE 1:
If Message=2 replaces Message=1, then MessageRelationship.related points to Message=2
and MessageRelationship.relating points to Message=1 with MessageRelationship.role="replaces".
[2012-11-14] Mike Ward, Eurostep: skos:prefLabel and rdfs:comment edited
[2012-08-28] Mike Ward, Eurostep: Renamed from NextAssemblyUsage to NextAssemblyViewUsage
and moved from AssemblyComponentRelationship to AssemblyViewRelationship.
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
historical record of something that has occurred during the life of a product or its support environment
Notes:
NOTE 1:
The use of observation is restricted to observations not directly represented in the data model, and it
should not be used where some other reporting data structure is defined.
An ObservationConsequence is an association of an observation to the consequences
that follow from it, where those consequences are in the form of a WorkRequest
Notes:
NOTE 1:
One of the uses of ObservationConsequence is to close one of the feedback loops from
the use of a product to requests for its enhancements.
relationship between two observations. The nature of this relationship is identified by the role.
Where there is a structural relationship between Observation, the semantics of the
structure are identified by the classification of the ObservationRelationship against
reference-data
Examples:
EXAMPLE 1:
The Observation of a persistent fault is composed of a series of Observation of occurrences
of the same fault. That is, ObservationRelationship.related points to the composite
Observation, while ObservationRelationship.relating points to one actual Observation
of the occurrence. The ObservationRelationship.role of the relationship is "observed
instance", while it is classified as "is composed of". In this example, the component
Observation will apply to ProductAsRealized and the consequence will be to rectify
the individual faults, while the composite Observation will apply to a ProductVersion
and the consequence will be a design change.
An ObservedEnvironment is a specialization of Product that represents a record of
observations about the environment in which a product is or has been operating
An ObservedEnvironmentToDefinition is a relationship between a record of a set of
observations about an environment, represented by an ObservedEnvironment, and a typical
environment, represented by an EnvironmentDefinition. The typical environment is the
expected environment about which observations have been made
Class label: Observed environment to definition version
Class specification
Description:
An ObservedEnvironmentToDefinitionVersion is a relationship between a version of the
record of a set of observations about an environment, represented by an ObservedEnvironmentVersion,
and a version of the typical environment, represented by EnvironmentDefinitionVersion.
The typical environment is the expected environment about which observations have
been made
Class label: Observed environment to definition view
Class specification
Description:
An ObservedEnvironmentToDefinitionView is a relationship between a view of the record
of a set of observations about an environment, represented by an ObservedEnvironmentView,
and a view of the typical environment, represented by EnvironmentDefinitionView. The
typical environment is the expected environment about which observations have been
made
An ObservedEnvironmentView is a specialization of ProductViewDefinition that provides
a view of a version of an observed environment relevant for one or more application
domains. This view collects the characteristics of the observations on the environment
Class label: Observed environment view definition relationship
Class specification
Description:
An ObservedEnvironmentViewDefinitionRelationship is a specialization of ViewDefinitionRelationship
that represents an association between two ObservedEnvironmentView instances
An OrStateCauseEffectDefinition is a specialization of StateCauseEffectDefinition.
It relates one or more StateDefinition entities that are causes to a StateDefinition
that is the effect. At least one cause must exist prior to the effect
Class label: Organization based location representation
Class specification
Description:
An OrganizationBasedLocationRepresentation is a specialization of LocationRepresentation
that specifies a location in the context of an organization
Examples:
EXAMPLE 1:
The location "Room 99" in "The Administration Building" of a particular university
might be represented using one instance of OrganizationBasedLocationRepresentation
with two instances of OrganizationalLocationIdentification and one instance of Organization.
relationship between two instances of Organization
Examples:
EXAMPLE 1:
A team belongs to a department which itself belongs to a company. Such an organizational
structure can be described up using instances of OrganizationRelationship.
A ParameterizedDistribution is a specialization of ProbabilityDistribution that is
used to link a named probability distribution to the parameters that define it
Notes:
NOTE 1:
The ParameterizedDistribution of this entity is used to discriminate between alternative
parameterizations of the same distribution.
NOTE 2:
To calculate a value using a ParameterizedDistribution it is necessary to know the
general distribution function, the value of the distribution function parameters,
and the specific random variable value for which the probability evaluation is required.
The Probability Distribution module does not define the formula for the distribution
function, and it is assumed that this is defined externally, either through reference
information or via a "formula" module. This entity provides the distribution function
parameters. The value of the random variable for which the probability is calculated
is provided by the ProbabilityDerivationParameter in the Probability module (see note
2).
[2012-09-03] Mike Ward, Eurostep: Revisions to reflect decisions from 2012-08-30 review:
skos:definition removed; skos:note edited (NB "either" must be between two alternatives);
skos:note added; "part" changed to "part specification"
[2012-08-30] Mike Ward, "{versions http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#version}"
changed to "{versions http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#version}s"
in skos:note
[2012-08-29] Mike Ward, Eurostep: URL for "product" corrected in skos:note and in
rdfs:comment
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
NOTE 1:
A part specification version typically specifies a part that is functionally and physically interchangeable with
the other versions of the same part specification.
Class label: Person or organization or person in organization in position
Class specification
Description:
A PersonOrOrganizationOrPersonInOrganizationInPosition is a Person, Organization,
or PersonInOrganization that holds a Position. A person may hold more than one position
within an organization or organizations. A position in an organization can be held
by more than one person or organization
Examples:
EXAMPLE 1:
A person can hold two positions in an organization: Production Manager and Safety
Officer.
EXAMPLE 2:
Two people can hold the same position in a job-share scheme.
[2012-09-03] Mike Ward, Eurostep: Revisions to reflect decisions from 2012-08-30 review:
skos:note, rdfs:comment, and skos:example edited
[2012-08-30] Mike Ward, Eurostep: "{physical elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PhysicalElement}s"
changed to "{physical elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PhysicalElement}s
in rdfs:comment"
[2012-08-30] Mike Ward, Eurostep: "comprising of" corrected to "comprising"
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
NOTE 1:
A physical document definition may consist of one or many component hardcopy files.
Examples:
EXAMPLE 1:
Paper plots of technical drawings, micro fiche, or paper documents such as calculations
or test reports are examples of physical document definitions.
[2012-09-03] Mike Ward, Eurostep: Revisions to reflect decisions from 2012-08-30 review:
skos:note and rdfs:comment edited and skos:example added
[2012-08-30] Mike Ward, Eurostep: "{physical element}s" changed to "{physical elements}"
in skos:note
[2012-08-30] Mike Ward, Eurostep: "{breakdown element}" changed to "{breakdown element
http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#BreakdownElement}"
in rdfs:comment
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A Position is a function or job performed by a person. It defines responsibilities
and activities. A position that is not fulfilled by a person is a vacancy
A PrecisionQualifier is a specification of the number of significant digits in the
representation of a value. PrecisionQualifier shall be interpreted in accordance with
PrecisionQualifier in part 45 of this standard
Notes:
NOTE 1:
The precision is defined in clause 2 of "The Guide to the Expression of Uncertainty
in Measurement".
A ProbabilityByName is a specialization of Probability whose value belongs to a one
of a set of named classes, rather than by assigning a specific numerical value, which
may not be available
Examples:
EXAMPLE 1:
A safety assessment methodology classes the probability an accident as "very unlikely",
"unlikely", "significantly likely" and "almost certain". Any process that has a "very
likely" or "almost certain" chance of causing serious injury is shut down.
A ProbabilityDerivationParameter is a specialization of NumericalItemWithGlobalUnit
that is used by a ProbabilityDerived in a particular role in order to calculate the
particular probability
Notes:
NOTE 1:
The role name is given by the 'name' attribute inherited from RepresentationItem,
and the set of such names and their interpretation is defined through reference-data.
NOTE 2:
The value attribute, which holds the parameter value, is inherited from the parent
generalization.
Examples:
EXAMPLE 1:
In a coin tossing trial, the probability calculated is that of getting more than 6
heads in ten tosses. The parameter with the role "minimum number of heads" will have
the value "6"
A ProbabilityDerived is a specialization of ProbabilityNumeric that associates a particular
value of ProbabilityNumeric with the source from which the value derived together
with any parameters used to get the particular value
Notes:
NOTE 1:
Where the probability derived from a probability distribution, the parameters of ProbabilityDerived
are those needed to get a single value from the distribution, and not those which
characterize the distribution. For example, in the case of coin tossing, the distribution
is a Binomial distribution, with parameters of 'probability for a single toss', and
'number of tosses', whereas the parameter for the ProbabilityDerived will be the 'number
of heads obtained'.
A ProbabilityDistribution is a specialization of ProbabilityGenerator that is a probability
distribution
Notes:
NOTE 1:
For a full understanding of probability distribution and the terms used, a textbook
on probability theory should be consulted.
NOTE 2:
This entity describes a particular probability distribution, rather than the general
type of distribution. For example, in coin tossing experiment, the number of heads
that may occur is given by a binomial distribution - that is, a type of distribution,
and outside the scope of this module. This module provides the description of the
distribution of a particular experiment, say, 10 tosses of a particular coin. The
actual probability of an outcome, say 6 heads in 10 tosses, is recorded using the
probability module.
NOTE 3:
The attributes 'name', 'id' and 'description' are inherited from the parent generalization.
Representation. The name provides a cue to the particular source of the distribution,
such as "A fair coin tossed 10 times", rather than the type of distribution (in this
case Binomial) which is given by the ProbabilityDistribution.distributionName attribute.
A ProbabilityDistributionParameter is a specialization of NumericalItemWithGlobalUnit
that is one of the set of values that characterizes a probability distribution
Notes:
NOTE 1:
For many common distributions, the mean and the variance are sufficient to characterize
a distribution, and the parameter list may be empty.
NOTE 2:
ProbabilityDistributionParameter inherits the 'name' attribute from its parent generalization,
and this is used to identify the name of the parameter within the particular parameterization.
The value attribute is also inherited.
Examples:
EXAMPLE 1:
The Normal (or Gaussian) distribution has, in the standard parameterization, two parameters:
the mean and the variance
A ProbabilityFunctionValue is a specialization of NumericalItemWithGlobalUnit that
is the value of the probability function at the given random variable value
Notes:
NOTE 1:
The value is an inherited attribute. It is not in general a probability value. In
some functions for continuous distributions, the probability that the random variable
lies between two values is the integral of the function of that range.
A ProbabilityGenerator is a specialization of Representation. It is a source from
the ProbabilityDerived is derived. The ProbabilityDerivationParameters are applied
to the ProbabilityGenerator to get the particular derived value
Notes:
NOTE 1:
A ProbabilityGenerator will generally be either a ProbabilityDistribution or a function
of some statistics.
Examples:
EXAMPLE 1:
A probability of "0.67" is derived from a Normal (or Gaussian) distribution using
the parameter "plus or minus '1.0' standard deviations from the mean"
A ProbabilityNamedValue is a specialization of RepresentationItem that is used to
hold the name of the probability value
Notes:
NOTE 1:
The value attribute is the description inherited from the parent generalization. In
general, this value will be one of an enumeration of possible values defined through
reference-data.
product that specifies an individual artefact that has been made or is planned to be made
Notes:
NOTE 1:
It is likely, but not essential, that the artefact, was or will be made from a product design which will be related to the product as individual by [product design to individual http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ProductDesignToIndividual.
NOTE 2:
Many physical products may be produced from a given design. A single product may lead to many products as individual.
NOTE 3:
products as individual versions of product as individual are used to represent whether an individual artefact has yet to be made or has been
made. The product as individual version specialization Product as planned is used to represent the revision of an individual artefact that has yet to be made
and the specialization product as realized is used to represent the revision of an individual artefact that has been made.
NOTE 4:
Where physical products are being represented, the product as individual represents the physical or planned physical realization of a product.
Examples:
EXAMPLE 1:
The design of a personal computer is represented by a Product.
EXAMPLE 2:
The personal computer that has been ordered, allocated a serial number for manufacturing
planning, but not yet manufactured, is represented by a ProductAsIndividual and an
associated revision represented by ProductAsPlanned.
EXAMPLE 3:
The personal computer with a serial number on a persons desk is represented by a ProductAsIndividual
and an associated revision represented by ProductAsRealized.
EXAMPLE 4:
HMS Daring is the first of a new class of ships known as Type 45 Destroyers. It is
due to enter service in two years time. The Type 45 ship design that applies to HMS
Daring is represented by a Product; The ship HMS Daring is represented by a ProductAsIndividual.
This identifies the planned ship, and when built, the actual ship; The planned revision
of the future ship HMS Daring is represented by a ProductAsPlanned which is related
back to the ProductAsIndividual; When built, the first revision the actual ship, HMS
Daring will be represented by a ProductAsRealized which is related back to the ProductAsIndividual.
EXAMPLE 1:
The car on my drive is represented by a product as individual. The current configuration status of the car can be represented by a product as realized related to the product as individual. If a safety modification is made to the car resulting in a new configuration status
of the car, then this may be represented by a new product as realized.
EXAMPLE 2:
The HMS Daring is the first of a new class of ships known as Type 45 Destroyers and
is due to be built in two years' time. The version of the generic Type 45 ship design
that applies to HMS Daring is represented by a product version; The ship HMS Daring is represented by a product as individual. This identifies the planned ship, and when built, the actual ship; The planned revision
of the future ship HMS Daring is represented by a Product as planned related back to the product as individual; When built, the first revision the actual ship, HMS Daring will be represented by
a product as realized related back to the product as individual.
NOTE 1:
The product as individual view supports the representation of different views of a product as individual for different purposes. Multiple views of the same product as individual are represented by different instances of ProductAsIndividualView for the same product as individual version
A ProductAsPlanned is a specialization of ProductAsIndividualVersion that identifies
a revision of an individual artefact that has yet to be made
Notes:
NOTE 1:
If the planned artefact ( ProductAsPlanned) is subsequently made into an actual artefact
( ProductAsRealized) then they are related by the ProductPlannedToRealized relationship.
NOTE 2:
It may be planned to make the artefact from of a version of a product design ( ProductVersion).
If this is the case, then the relationship between the artefact ( ProductAsPlanned)
and the design ( ProductVersion) is represented by ProductDesignVersionToIndividual.
NOTE 1:
A product as realized's properties can only be known by observation or by derivation from observations.
NOTE 2:
The artefact may have been made from a version of a product (ie a product version). If this is the case, then the relationship between the product as realized and the (product version http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ProductVersion]
is represented by product design version to individual.
A ProductConcept is the identification of a set of similar products that were, are
or will be proposed to customers
Notes:
NOTE 1:
A product concept may be characterized by a set of product features identified by
the customers or derived from customers' needs.
NOTE 2:
The entity data type ProductConcept enables to represent customer-oriented identification
of products that are to be delivered to customers, while the entity data type Product
enables to identify and to track the history of items that are designed and manufactured,
as a tangible solution, or component of the solution, for a product concept.
NOTE 3:
Depending on the kind of industry and products, a product concept might be offered
to the customers in one or many different configurations.
NOTE 4:
The definition of product concepts is driven by market and customer requirements and
forecasting. A ProductConcept often corresponds to the highest level item(s) manufactured
by an organization for customers.
Examples:
EXAMPLE 1:
In an organization which manufactures cars and engines for cars, the car models will
be represented by instances of ProductConcept.
A ProductConfiguration is the identification of a ProductConcept as a configuration
Notes:
NOTE 1:
A ProductConfiguration may identify a variation of a ProductConcept, an entire ProductConcept,
or some portion thereof.
NOTE 2:
A ProductConfiguration can be established prior to the existence of a corresponding
product.
NOTE 3:
The entity ProductConfiguration corresponds to the concept of configuration item defined,
in some configuration management standards, as an item subject to configuration management.
Examples:
EXAMPLE 1:
A ProductConfiguration may represent a component of a contracted product, onto which
severe safety rules apply and for which configuration management is therefore rigorously
applied.
Class label: Product configuration hierarchical relationship
Class specification
Description:
A ProductConfigurationHierarchicalRelationship is a specialization of ProductConfigurationRelationship
that is used to represent a hierarchical relationship between a parent ProductConfiguration
and a child ProductConfiguration
Class label: Product configuration revision sequence
Class specification
Description:
A ProductConfigurationRevisionSequence is a specialization of ProductConfigurationRelationship
that is used to relate a previous version (predecessor) of a ProductConfiguration
to the version that replaces it (successor)
NOTE 1:
A product design to individual associates a product design, represented by product, with a product that is planned to be made or has been made from the design, represented
by product as individual.
A ProductDesignViewToIndividual is a relationship between a product design, represented
by ProductViewDefinition. or ProductConfiguration, and a view of the product that
is planned to be made or has been made ( ProductAsIndividualView) from the design
A ProductGroup is an identification of a set of ProductConcepts, Products, ProductGroups,
ProductVersions or ProductAsIndividuals that have been grouped together
Examples:
EXAMPLE 1:
All the aircraft sold to BigPlanes airways.
A ProductInAttachmentSlot is a specialization of ViewDefinitionUsage that is a relationship
between an AttachmentSlot and a ProductViewDefinition of a Product that is designed
to be attached to the attachment slot
Examples:
EXAMPLE 1:
A long-range fuel tank is designed to be attached to an aircraft in an attachment
slot that corresponds to a pylon mounting on a wing.
A ProductPlannedToRealized is a relationship that establishes that a revision of a
planned artefact represented by ProductAsPlanned has been realized as a revision of
an actual artefact ProductAsRealized
A PromissoryUsage is a specialization of AssemblyViewRelationship. It establishes
a relationship between an assembly and a component, regardless of the number of intermediate
levels between them, which may be established with instances of NextAssemblyUsage
Notes:
NOTE 1:
A PromissoryUsage may be used when the product structure is not completely defined,
to capture the intent that the constituent will be used in that assembly.
[2012-08-28] Mike Ward, Eurostep: Renamed from PromissoryUsage to PromissoryAssemblyViewUsage
and moved from AssemblyComponentRelationship to AssemblyViewRelationship.
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-08-29] Mike Ward, Eurostep: Initial definition. "ExternalPropertyDefiniton"
changed to "ExternalPropertyDefinition" and "property definition" changed to "property"
in rdfs:comment
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-08-29] Mike Ward, Eurostep: skos:prefLabel changed from "Property definition
relationship" to "property definition relationship" and rdfs:comment added.
[2012-08-29] Mike Ward, Eurostep: "{property http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ExternalPropertyDefinition
:PLURAL}" changed to "{properties http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ExternalPropertyDefinition
:PLURAL}" in rdfs:comment
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
rdfs:comment edited and skos:example added.
[2012-08-30] Mike Ward, Eurostep: case of skos:prefLabel corrected
[2012-08-30] Mike Ward, Eurostep: "{property definition http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ExternalPropertyDefinition}"
changed to "{property http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-terms#property}"
in rdfs:comment
[2012-05-15] Rob Bodington, Eurostep: Initial definition
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
rdfs:comment and skos:example edited and skos:example added.
[2012-08-30] Mike Ward, Eurostep: "{property values http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PropertyValue}"
changed to "{property values http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#PropertyValue}s"
in rdfs:comment
[2012-05-15] Rob Bodington, Eurostep: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
EXAMPLE 1:
A Military rank such as Colonel, or Captain
EXAMPLE 2:
A driving licence.
EXAMPLE 3:
A qualification for executing the Ground Running task for RB211 engines.
EXAMPLE 4:
Educational qualification such as GCSE, A level, Degree, Ordinary National Certificate,
Higher National Certificate, City and Guilds, or GNVQ.
A QualitativeUncertainty is a specialization of UncertaintyQualifier. The uncertainty
is defined in clause 2 of "The Guide to the Expression of Uncertainty in Measurement"
A RelatedConditionParameter is a relationship between a ConditionParameter and a ConditionEvaluationParameter.
This relationship is used to record the relationship between the parameters used to
define a condition and the parameters used to evaluate it
Examples:
EXAMPLE 1:
The value of oil pressure (1.9 bar) used in ConditionEvaluation (instance 87) was
a measured value of the parameter used to define condition 29 (oil pressure on gauge
3).
A RepeatCount is a type of LoopingElement. It invokes a specified number of repetitions
of the LoopingElement TaskElement inherited from the LoopingElement parent generalization
A RepeatUntil is a type of LoopingElement. It invokes repetitions of a further TaskElement
and is repeated until the specified condition is satisfied. The element being repeated
shall be executed at least once and the condition tested after the first execution
A RepeatWhile is a type of LoopingElement. It invokes repetitions of a further TaskElement
and is repeated while the specified condition is satisfied. The test condition shall
be evaluated prior to invoking the method and may result in the LoopingElement not
being executed at all
NOTE 1:
An association between a required resource and actions that are needed prior to its
usage.
Examples:
EXAMPLE 1:
A resource required by the activity "12" needs to be calibrated prior to usage. The
calibration activity "21" is associated with the same required resource.
EXAMPLE 2:
A resource required by the task "123" needs to be disposed after its usage. This disposal
task "456" is associated with the same required resource.
EXAMPLE 3:
The assignment can be classified as "required by".
EXAMPLE 4:
task, task step, activity, activity method, organization are examples of entities
to which the resource requirement statement could be related.
A RequiredResourceRequirement is an association of a required resource with one or
more requirement version entities that fulfil the resource requirement
NOTE 1:
Systems engineering tools and organizations may use differing identification mechanisms.
Multiple identifiers may be assigned to a requirement using identifier.
NOTE 2:
The term requirement is used here in the sense that term is used in systems engineering and similar industrial
domains.
NOTE 3:
There may be many versions of a requirement (requirement versions). There may also be more than one domain-specific view of a given requirement version (using requirement view definition). The requirement entity is simply a placeholder for holding a unique requirement.
Most associations and properties are defined at the RequirementViewDefinition level
- that is in the context of a domain.
Examples:
EXAMPLE 1:
A requirement may be identified as "NOx emissions requirement", and uniquely identified
as "Req2".
assignment of a (requirement view http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#RequirementViewDefinition]
to something
Examples:
EXAMPLE 1:
A requirement "the vehicle shall have a maximum power output of at least 150BHP" could
be assigned to the data types which are used to represent the vehicle's engine.
A RequirementCollectionRelationship is a specialization of ViewDefinitionRelationship
that is used to relate a parent (collection) requirement to its member requirements.
This provides a method for collecting together a set of requirements and treating
them as a single requirement, whilst still being able to refer to individual requirements
Notes:
NOTE 1:
The inherited " ViewDefinitionRelationship" and " ViewDefinitionRelationship" attributes
have been renamed for purposes of clarity.
A RequirementSatisfiedBy is a relationship between an item and a requirement, asserting
that the item satisfies the identified requirement
Examples:
EXAMPLE 1:
A data type used to represent a vehicle's engine with a power output of 160BHP could
be asserted to satisfy a requirement "the vehicle shall have a maximum power output of at least 150BHP".
A RequirementSource is a relationship between a requirement (via the RequirementViewDefinition
entity) and the data types representing the source of the requirement
Examples:
EXAMPLE 1:
The source of the requirement "the vehicle shall have a maximum power output of at
least 150BHP" could be a document representing the findings of a market survey of
sports car buyers.
A RequirementVersionRelationship is a specialization of ProductVersionRelationship
that is used to relate a previous version (predecessor) of a requirement to the version
that replaces it (successor)
NOTE 1:
A requirement view definition collects requirement data for specific engineering purposes. Some requirements in
a requirement view definition might impact on different disciplines. Multiple requirement view definitions may present different views of a given requirement for each discipline.
Examples:
EXAMPLE 1:
An engineer may have responsibility for collecting all requirements associated with
the cooling of an engine - covering engine block, tubing, water pump, electric fan.
Class label: Requirement view definition relationship
Class specification
Description:
A RequirementViewDefinitionRelationship is a specialization of ViewDefinitionRelationship.
A RequirementViewDefinitionRelationship is the association between one RequirementViewDefinition
and another
A ResourceEvent is an event or action that affects the balance or availability of
a managed resource. The role of a resource event is determined by classification
Examples:
EXAMPLE 1:
A resource event can be classified as "Planned" or "Actual".
Class label: Resource event correspondence relationship
Class specification
Description:
relationship between a resource event and a corresponding statement of RequiredResource. The meaning
of the relationship is determined by classification
Notes:
NOTE 1:
A resource event can be planned or recorded without having a corresponding resource
requirement statement.
Examples:
EXAMPLE 1:
A resource event correspondence relationship can be classified as "Designated for".
A ResourceGroupRelationship is a specialization of ResourceItemRelationship that specifies
the means to associate two resource items that are part of a resource group. The meaning
of the entity is determined by classification
Examples:
EXAMPLE 1:
The relationship between a facility and compressed air could be classified as "Provides".
EXAMPLE 2:
The relationship between a tool set and a mallet could be classified as "Contains".
A Risk is a specialization of Product that is the potential for realization of unwanted
negative consequences of an event
Notes:
NOTE 1:
A risk can also have a possible positive outcome. In such cases it is often referred
to as an opportunity or reward.
NOTE 2:
ISO GUIDE 73 defines "risk" as the combination of the probability of an event and
its consequence. In some situations, risk is a deviation from the expected.
NOTE 3:
ISO/IEC Guide 51:1999 defines risk as the combination of the probability of occurrence
of harm and the severity of that harm.
NOTE 4:
In the safety field, risk management is focused on prevention and mitigation of harm.
ISO/IEC Guide 51:1999 should be used for safety aspects.
Examples:
EXAMPLE 1:
'Fly-by-wire', the form-fit-function replacement of mechanical devices with a combination
of electrical, hydraulic, and pneumatic units.
EXAMPLE 2:
'Privacy' and 'security' are examples of Risk for the telecommunications industry.
EXAMPLE 3:
'Line shutdown' is an example of Risk in the context of a manufacturing system's reliability.
EXAMPLE 4:
'Transportation jam-up', 'customer anger', 'collateral damage', and 'greater susceptibility
to interruption of supply during crises' are all examples of Risk.
EXAMPLE 5:
Timing such as 'premature rejection' and 'premature commitment' are other examples
of Risk.
A RiskPerception is a specialization of ProductViewDefinition that defines values
or concerns with which a stakeholder views a particular Risk. The context in which
a RiskPerception occurs is represented by RiskPerceptionContext
Notes:
NOTE 1:
Risk will be perceived differently in different contexts, such as in the context of
human safety, mission success, project time schedule, performance or economy.
NOTE 2:
RiskPerception can differ from objective data.
NOTE 3:
RiskPerception depends on the stakeholder's expressed needs, issues, and knowledge.
NOTE 4:
RiskPerception may be used qualitatively or quantitatively to form a risk matrix.
NOTE 5:
There is only one probability for each perceived risk. The probability for something
to happen does not vary depending on the consequences.
A RiskVersion is a specialization of ProductVersion. It defines a form of a risk that
differ in certain respects from an earlier form of that risk or from other forms of
that risk
Notes:
NOTE 1:
Use of RiskVersion allows several RiskPerception instances to be assigned to a specific
Risk.
A Scheme is a specialization of ActivityMethod. It provides the identification and
description of an intended course of action to accomplish an objective. A Scheme enables
the ordering of entries. Dates and times may be specified for entries and time intervals
between entries
Notes:
NOTE 1:
A Scheme may be classified as a Plan or Schedule, and it may be further classified
into specific types of Plans or Schedules.
Examples:
EXAMPLE 1:
Acquisition plan, Maintenance plan, Resource schedule are examples of schemes.
NOTE 1:
The SchemeEntryAssignment links the single items included in Plans and Schedules with
their associated SchemeEntry. These items may be actions, events, or tasks depending
on the nature of the Plan or Schedule.
A SchemeEntryRelationship is a specialization of ActivityMethodRelationship. It relates
two SchemeEntry entities. An association may exists between SchemeEntry entities that
relate to different Scheme or between different SchemeEntry entity instances for the
same Scheme
Notes:
NOTE 1:
The SchemeEntryRelationship provides the ability to relate entries included in Plans
or Schedules in different ways. By applying classifications on the SchemeEntryRelationship
it can be used for different purposes.
Examples:
EXAMPLE 1:
Decomposition, Dependency, and sequencing are examples of kinds of relationships possible
between schema entries.
A SchemeRelationship is a specialization of ActivityMethodRelationship relating two
Schemes
Notes:
NOTE 1:
The SchemeRelationship provides the ability to relate Plans or Schedules represented
by the Scheme entity in different ways. If classifications are available to the schema
using this on, by applying classifications on the SchemeRelationship it can be used
for different purposes.
Examples:
EXAMPLE 1:
Decomposition, based-on, alternative, version are kinds of relationships between Schemes.
NOTE 1:
The SchemeSubjectAssignment links the Plans and Schedules with their associated subjects
or targets. This may indicate the intent of the scheme.
Examples:
EXAMPLE 1:
The maintenance plan for an individual vehicle, where the subject attribute points
to an entity instance representing the individual vehicle.
A SequencingRelationship is a specialization of SchemeEntryRelationship. It defines
a specific type of sequencing and relative timing for two SchemeEntry
Notes:
NOTE 1:
Specific types of sequencing could include start-start, finish-start.
A StandardUncertainty is a specialization of UncertaintyQualifier. A StandardUncertainty
may be an ExpandedUncertainty. The uncertainty is defined in clause 2 of "The Guide
to the Expression of Uncertainty in Measurement"
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
skos:definition and rdfs:comment and skos:examples edited; skos:note deleted; skos:example
added.
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
skos:definition and rdfs:comment and skos:examples edited; skos:note deleted; skos:example
added.
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A StateCauseEffect is a specialization of state relationship and it relates two or
more states as one state causing particular resulting effect state(s). In turn, an
effect state can become a new causing state yielding in yet more effect states
A StateCauseEffectDefinition is a specialization of StateDefinitionRelationship that
is used to define a causal relationship between two sets of StateDefinition entities.
At least one StateDefinition acts as a cause and at least one StateDefinition acts
as a effect
Notes:
NOTE 1:
Additional causal relationships between states can be expressed using the following
subtypes: AndStateCauseEffectDefinition, OrStateCauseEffectDefinition, and XorStateCauseEffectDefinition.
A StateComplementDefinition is a specialization of StateDefinitionRelationship. It
is a relationship among three sets of StateDefinition entities. It defines the complement
of a set of StateDefinition entities relative to a set of StateDefinition entities
that are the universe
Notes:
NOTE 1:
The relationship between a StateDefinition and its complement is symmetrical.
NOTE 2:
The semantics are the same as in elementary set theory.
A StatePredictedToObserved is a specialization of state relationship. It specifies
the relationship between two individual states, one of which is a StatePredicted to
a second state which is a StateObserved
A StateProperSubsetDefinition is a specialization of StateDefinitionRelationship.
It is a relationship between two sets of StateDefinition entities
Notes:
NOTE 1:
The relationship between a state and its environment can be described as a StateProperSubsetDefinition.
The identification of an intrinsic state is the properSubset. The identification of
an extrinsic state is the properSuperset.
A StateSymptomDefinition is a specialization of StateDefinitionRelationship. It relates
two or more StateDefinition entities in regards to symptom, where a symptom is something
that indicates the existence of something else. At least one StateDefinition acts
as a symptomCause and at least one StateDefinition acts as a symptomEffect
A StateTransition is a specialization of state relationship and it relates two or
more states before and after a transition in State, where at least one State is a
start state and at least one State is an end state
A StateTransitionDefinition is a specialization of StateDefinitionRelationship. It
relates two or more StateDefinition entities before and after a transition in state,
where at least one StateDefinition is a startState and at least one StateDefinition
is an endState
A SuppliedPartRelationship is a specialization of ProductVersionRelationship that
relates two instances of ProductVersion that represent the same instance in different
organizational contexts. One of the organizations is the supplier of the instance
to the other organization. This entity is applicable for part versions and document
versions
Notes:
NOTE 1:
The module provides a more general mechanism that can be used to track alias identifiers
for any entity data type that has an id attribute.
NOTE 2:
This entity enables to represent the fact that two organizations may use distinct
identifiers to identify their Product and their versions.
NOTE 3:
This mechanism can only be used in an information system or in exchange files where
the content of the id attribute of instances of Product is not constrained by a particular
identification scheme.
A System is a specialization of Product used to identify a conceptual solution to
a collection of requirements
Notes:
NOTE 1:
Another definition would be "That which is discernible by reproducible measurement
of its characteristics, and has a defined boundary (statically and dynamically) with
respect to the universe".
NOTE 2:
SEDRES Definition: "An assembly of interacting, active components or elements forming
a whole".
NOTE 3:
The concept system is any thing - matter, energy, organization or information or a
combination of these - for which reproducible measurements exist. The concept system
excludes any asserted thing based on personal experience for which no reproducible
measurements exist.
NOTE 1:
The system breakdown is a partitioning of a product into a set of related system elements so as to form explicit, parent-child views.
Examples:
EXAMPLE 1:
A system breakdown provides a decomposition of an aircraft in terms of high-level Systems such as "fuel system" or "flight control system" - which might, in the second example,
further decompose into low-level systems such as "autopilot system" and "instrument
landing system".
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
rdfs:comment, skos:note, and skos:example edited.
[2012-08-30] Mike Ward, Eurostep: "{system elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#SystemElement}s"
changed to "{system elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#SystemElement}s"
in rdfs:comment
[2012-08-30] Mike Ward, Eurostep: "comprising of" corrected to "comprising"
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A SystemBreakdownContext is a specialization of BreakdownContext that is a membership
relationship between a SystemElement and a SystemBreakdown of which the system element
is a member
Examples:
EXAMPLE 1:
A heating system is a member of the breakdown of a climate control system.
A SystemBreakdownVersion is a specialization of BreakdownVersion that identifies a
version of a SystemBreakdown
Examples:
EXAMPLE 1:
A logistics engineer modifies the current systems breakdown for an aircraft and associated
support equipment on the basis of results from a level of repair analysis.
A SystemElementDefinition is a specialization of BreakdownElementDefinition that identifies
a view of a version ( SystemElementVersion) of a SystemElement
Examples:
EXAMPLE 1:
The collision avoidance system element of a system breakdown is subject to a level
of repair analysis to support implementation of optimized maintenance for an aircraft.
A SystemElementUsage is a specialization of BreakdownElementUsage that is a relationship
between a SystemElementDefinition and another SystemElementDefinition that is a constituent
Examples:
EXAMPLE 1:
In a system breakdown, the fuel system might include a fuel storage system and a fuel
injection system as components.
A SystemVersion is a specialization of ProductVersion that represents a particular
version of a system
Notes:
NOTE 1:
In this case, this means "revision". So for a given system (e.g. a fuel injection
system) we may have several versions of the system design (e.g. v1, v1.1 etc.)
A SystemViewDefinition is a specialization of ProductViewDefinition that provides
a view of a system version relevant for one or more application domains
A TaskElementLevels is a type of TaskElement that provides two or more different descriptions
in place of a single method. The actual work will be the same whichever alternative
TaskElement is followed
Notes:
NOTE 1:
This can be used to provide different levels of description of a task for people with
varying levels of experience or expertise.
relationship between a State or a StateDefinition and a TaskElement. The meaning of the entity
is determined by classification. Candidate meanings include: assumed starting state;
required starting state
A TimeIntervalWithBounds is a specialization of TimeInterval. A TimeIntervalWithBounds
is bounded either on one side or both sides. If neither secondaryBound nor Duration
are specified, the time interval begins at the point in time identified by primaryBound
and has no specified end point
A TracingRelationship is a specialization of ViewDefinitionRelationship that shows
tracing from ( TracingRelationship) one requirement to another ( TracingRelationship).
A requirement may trace to many other requirements and vice versa - this is achieved
by creating multiple instances of the tracing relationship entity
Notes:
NOTE 1:
Properties may be attached to tracing relationships. This is intended to deal with
"user defined" attributes which are common on tracing relationships in requirements
tools.
NOTE 2:
The inherited " ViewDefinitionRelationship" and " ViewDefinitionRelationship" attributes
have been renamed for purposes of clarity.
Examples:
EXAMPLE 1:
A requirement on the performance of a catalytic converter in a car may be traced from
a more general emissions requirement.
A TypeOfPersonDefinition is the definition of a TypeOfPerson in terms of required
properties or attributes
Examples:
EXAMPLE 1:
A junior mechanical design engineer could be specified to be either someone who has
3 years experience of working in a mechanical design department, or a degree in mechanical
engineering.
Class label: Type of person definition required attributes relationship
Class specification
Description:
relationship between a TypeOfPersonDefinition and the attributes required to define that type
of person
Examples:
EXAMPLE 1:
The type of person "van driver" is required to possess the qualification named "commercial
driving license" or the experience level "3 years of driving more than 10,000 miles
per year".
An UncertaintyQualifier is a generalization of a StandardUncertainty or a QualitativeUncertainty.
The uncertainty is defined in clause 2 of "The Guide to the Expression of Uncertainty
in Measurement"
A Validation is a subjective assertion that an item is "fit for purpose". Evidence
used in this validation is identified by the inverse attribute validatedBy. Validation
is commonly understood to mean "Have we built the right system?". Validation is concerned
with ensuring that the system will meet the customer’s objectives and expectations.
Validation usually includes testing under normal usage conditions
Notes:
NOTE 1:
It is assumed that meta data supporting the validation will be applied using assignment
entities, such as identification assignment, person and organization assignment etc..
NOTE 2:
An item may pass validation even though some requirements fail verification.
Examples:
EXAMPLE 1:
Every flight of every Space Shuttle has been a "Validation" flight to test the new
design under actual conditions. No two shuttles have flown in the same configuration
and many systems cannot be validated except under actual conditions.
A ValueLimit is a specialization of NumericalItemWithUnit that specifies a qualified
numerical value representing either the lower limit or the upper limit of a particular
quantifiable characteristic
A ValueList is a specialization of MeasureItem that is an ordered collection of MeasureItems
Examples:
EXAMPLE 1:
A MeasureItem may be composed of different values such as 'mass', 'speed', and 'age'
which are all necessary in a given context. The ValueList collects all of them in
a given order, such that each is identifiable by its index in the list.
A ValueSet is a specialization of MeasureItem that is an unordered collection of MeasureItems
Examples:
EXAMPLE 1:
A MeasureItem may be composed of different values such as 'mass', 'speed', and 'age'
which are all necessary in a given context. The ValueSet collects all of them in a
given order, such that each is identifiable by its index in the list.
A ValueWithTolerances is a specialization of MeasureItem that specifies a range of
values by specifying a single nominal value and two tolerances that are offsets from
the single value. The range is defined to be the closed interval [item value + lower
limit, item value + upper limit]
A Verification is an objective assertion of a claim that requirement is satisfied
by a particular item represented in a RequirementSatisfiedBy has been verified. The
evidence used in this verification is identified by the inverse attribute verifiedBy.
Verification is commonly understood to mean "Have we built the system right?". Verification
ensures that the specified requirements have been met. Verification uses the methods
of Test, Analysis, Inspection, Demonstration, Similarity
Notes:
NOTE 1:
It is assumed that meta data supporting the verification will be applied using assignment
entities, such as identification assignment, person and organization assignment etc..
NOTE 2:
Just because an item is verified does not ensure that it meets all stakeholder needs
or expectations, many of these are never specified are of an untestable nature e.g.
"the car should look sporty".
Examples:
EXAMPLE 1:
A data type used to represent a vehicle's engine with a power output of 160BHP could
be asserted to satisfy a requirement "the vehicle shall have a maximum power output
of at least 150BHP". This assertion may be verified by analysis results on simulations
of the engine. In this case the analysis results would be identified in the items
collection of an evidence instance, possibly including the approval of the analysis.
The evidence instance would identify that it is used to support the required verification.
NOTE 1:
A WorkOutputAssignment is an association of a work output statement with the source
that produces or delivers the output. The work output can be planned as well as actual.
EXAMPLE 1:
In case a tyre on a car is flat, a WorkRequest may be created and associated with
the instances that represent the tyre that is flat, the car and the spare wheel.
NOTE 1:
The meaning of the relationship is determined by classification which is identified
by the RelationshipObject property. The possible classifications are subclasses of
.
An XorStateCauseEffectDefinition is a specialization of StateCauseEffectDefinition.
It relates one of the single or many causing state definition(s) and one effect StateDefinition,
whereby any and only one of the causing state definitions exists prior to the single
effect to take place
NOTE 1:
The zonal breakdown is a partitioning of a product into a set of related zone elements so as to form explicit, parent-child views.
Examples:
EXAMPLE 1:
A zonal breakdown provides a decomposition of an aircraft in terms of spaces or high-level conceptual
parts such as 'wing' - which might further decompose into lower-level zones such as
'inner-wing', and 'outer wing'.
[2012-09-04] Mike Ward, Eurostep, Revisions to reflect decisions from 2012-08-30 review:
rdfs:comment and skos:note edited.
[2012-08-30] Mike Ward, Eurostep: "{zone element}s" changed to "{zone elements http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm#ZoneElement}s"
in skos:note
[2012-08-30] Mike Ward, Eurostep: "comprising of" corrected to "comprising"
[2012-05-16] Mats Nilsson, FMV: Updated to conform to defined rules for definition
and annotation properties
[2012-01-26] Steve Yates, Eurostep: Initial definition. Transferred to PLCS PSM ref
data from DEXlib
A ZoneBreakdownContext is a specialization of BreakdownContext that is a membership
relationship between a ZoneElement and a ZoneBreakdown of which the zonal element
is a member
Examples:
EXAMPLE 1:
A 'fire-check zone' might be a member of the zonal breakdown of a building.
A ZoneElementDefinition is a specialization of BreakdownElementDefinition that identifies
a view of a version ( ZoneElementVersion) of a ZoneElement
Examples:
EXAMPLE 1:
For an aircraft, an element 'Right vertical stabilizer tip' is in a zonal breakdown
that an engineer uses for reliability-centred maintenance analysis.
A ZoneElementVersion is a specialization of BreakdownElementVersion that identifies
a version of a ZoneElement
Examples:
EXAMPLE 1:
An engineer defines an inspection task on a breakdown element 'Upper rudder' that
is part of a zonal breakdown of an aircraft. The engineer identifies the corresponding
view of the breakdown element.