PLCSConceptModel: Class: Activity
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Subtypes: Activity_planned  Activity_actual 
Used by: Scheme Activity 
Supports ICOMS: predicted downtimeproduct group usage profile
Definition:
An Activity is the identification of the occurrence of an action that has taken place, is taking place, or is expected to take place in the future.
EXAMPLE    Performing a repair task, performing an inspection, carrying out an operational mission, firing a weapon (once or several times), a training session, running a test using built-in test equipment, doing a pre-flight check, ...
NOTE 1   PLCS allows for planned activities and the corresponding actual activities to be treated as distinct but related to each other. Not all activities are planned and not all planned activities go according to plan. This also allows activities to be recorded using a different structure to that used for planning, such as recording the entire task and only those sub-tasks considered to be safety critical.
NOTE 2   A planned activity can be included in several different plans (see Scheme).
PLCSConceptModel: Class: Activity_actual
On diagrams: Top-level concepts 
Supertypes: Activity 
All Supertype Blocks: Activity  Product 
Used by: Activity_actual 
Supports ICOMS: commissioning feedbackcommissioning task feedbackcompleted taskfeedbackoperator feedback *performance reportproduct historyproduct related feedbackproduct usage recordrelated informationresource feedbackresource usage recordsupport feedbacksupport task exceptionsupport task recordtask feedback *task historytask related feedback
Definition:
Activity_actual is an Activity which records an Activity which has started.
NOTE 1   Activity_actual provides the means to capture a history of relevant actions. It is used along with State and the record of configuration and versions of Part and Realized_product to capture a comprehensive record of Product Life Cycle Support.
NOTE 2   Some relevant activities may last for years. If there is an associated completion date and time, it will have been completed. Otherwise it may be that the end of the activity has not yet been recorded.
NOTE 3   A more detailed history of the progress of an activity may be recorded by capturing states of the activity or through recording sub-activities as further instances of Activity_actual.
EXAMPLE    A vehicle is in for maintenance. An Activity_planned was defined and the relevant resources associated with it. However, an unexpected problem occurs and so the completion of the actual maintenance is delayed for a day while parts are obtained. While waiting, work was done to install new software which would not otherwise have been done until the vehicle was next in the repair shop. This gives rise to a further Activity_actual for the software fit that relates to an Activity_planned in the future.
PLCSConceptModel: Class: Activity_method
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Subtypes: Task  Scheme 
Used by: Activity_method Activity_planned Activity_actual Activity 
Supports ICOMS:
Definition:
An Activity_method is a way to carry out an Activity.
NOTE 1   There may be more than one method for producing a required result. Depending on expertise levels there may be more than one way that a method can be described.
NOTE 2   This definition may be used to characterize a way to resolve a request for action.
EXAMPLE    Procedures for inspection, procedures for repair of equipment, instructions for safe storage of an item or for normal usage of an item,...
PLCSConceptModel: Class: Activity_planned
On diagrams: Top-level concepts 
Supertypes: Activity 
All Supertype Blocks: Activity  Product 
Used by: Activity_planned 
Supports ICOMS: predicted product state and usagesupport opportunitysupport task exception
Definition:
An Activity_planned is an Activity which, when first defined, has yet to start and so is being planned. It is a record of the intent to perform an Activity.
NOTE 1   Not all planned activities result in real activities. Not all real activities are carried out according to expectation. Thus the intent to perform an activity and the performance of the activity are captured by separate concepts to allow comparison. It is a business decision as to how much this capability is required or used.
NOTE 2   An Activity_planned may or may not correspond to an entry in one or more plans (See Scheme).
EXAMPLE    A vehicle is due for maintenance. An Activity_planned is defined and the relevant resources associated with it. The expected maintenance also corresponds to entries in plans defined by the fleet manager and the workshop manager.
PLCSConceptModel: Class: Analysis
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Analysis is record of the results of an examination or study undertaken on a product. It is produced via a reproducible process.
EXAMPLE    A fault state analysis, an engine test
PLCSConceptModel: Class: Approval
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: customer dispositionrejected PSIrejected issue or changerejected solutionsupport system releasevariance
Definition:
Approvals record the disposition of something from a management perspective. They are a formal confirmation of the quality of some activity or product data.
NOTE    An approval may also record a rejection or non-approval of an item.
PLCSConceptModel: Class: Baseline
On diagrams: Top-level concepts 
Used by: Baseline 
Supports ICOMS: configuration recordindividual product state
Definition:
Baselines are used to capture the configuration of a product at some point in time. They are an important tool in recording the history of an item or collection of items of interest.
EXAMPLE    A Baseline can capture a design of a product, the state of an individual product, the state of a set of documents or a set of requirements.
PLCSConceptModel: Class: Breakdown
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Subtypes: System_breakdown  Physical_breakdown  Functional_breakdown  Zonal_breakdown 
Supports ICOMS: affected itemclassified element or relationshiphybrid or other breakdownidentified elementsystem breakdownzonal breakdown
Definition:
A Breakdown provides a means to subdivide something of interest into a set of related elements to which additional information can be attached. This usually takes the form of a tree.
NOTE 1   Some Breakdowns follow well-known conventions, which determine the meaning of the relationships between elements, the types of elements and the criteria used in defining the breakdown. PLCS provides several classic forms of breakdown (shown as subtypes of breakdown in the concept model. It also allows for hybrid and other less conventional breakdowns.
EXAMPLE    Logistic Support Analysis often makes use of physical and functional breakdowns. Spare parts catalogues are often structured according to a breakdown of system, sub-system, possibly sub-sub-system and then graphic. Both Systems Engineers and Logistics Support analysts make use of system breakdowns.
PLCSConceptModel: Class: Certification
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Certification is an assertion of satisfaction of a particular quality criteria.
EXAMPLE    An aircraft is certified for operation.
PLCSConceptModel: Class: Classification
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Classification is used to refine the meaning of the basic constructs provided in PLCS. A label is applied to an item where the label comes from an identified library where it is defined and possibly related to other labels. Formally a Class is a number of things considered together. Such things could be classified using the same label.
NOTE 1   The term 'class' and 'set' are synonyms.
NOTE 2   A class can consist of all things with a particular set of properties. Hence information about the consequences of possessing the set of properties can be assigned to the class. If a thing is classified as being a member of such a class, then a set of properties possessed by the thing can be deduced.
EXAMPLE    A task can be classified as "Safety Critical". PLCS does not provide an entity specific to "Safety Critical tasks", instead classification is used to apply this distinction.
PLCSConceptModel: Class: Condition
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Conditions allow for the fact that some important aspects of Life Cycle Support only apply some of the time. A test is provided as a Condition to determine if, for example, a Task or similar is applicable in some circumstance.
NOTE    This is one of two mechanisms provided to allow for the fact that, for example, a specific Resource is for use under some circumstances only. The other mechanism is Effectivity.
EXAMPLE    "If the engine has been running for 10000 hours then it requires a service" is an example of a conditional statement. The consequence of the condition is "then it requires a service".
PLCSConceptModel: Class: Context
On diagrams: Top-level concepts 
Used by: Product_definition Product_definition 
Supports ICOMS:
Definition:
Much information associated with Product Life Cycle Support is created for use in a specific domain. A Context provides the means to specify the domain, often in association with a Life Cycle phase, which applies to some item.
NOTE    Requirements and vocabularies vary among the industrial activity fields. This entity is used to identify such a domain.
NOTE    Information from the same context may be suitable for aggregating into bigger collections. Similarly it may be appropriate to compare items in the same or related context while comparison between items from un-related contexts should be considered carefully before drawing conclusions.
EXAMPLE    Preliminary electrical design schematics would belong to a context. Measurements obtained by a specific tool applied consistently would belong to a context.
EXAMPLE    For design data, use of a common or related co-ordinate space is equivalent to saying that the data shares a common context.
PLCSConceptModel: Class: Contract
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Verification_and_Validation Project 
Supports ICOMS:
Definition:
A Contract is a binding agreement.
NOTE    PLCS does not provide detailed capabilities for describing Contracts. (They can be included as documents.) The Contract concept is provided to allow reference to Contracts.
PLCSConceptModel: Class: Date_time
On diagrams: Top-level concepts 
Supports ICOMS: first-use date
Definition:
A Date_time is a time on a particular day.
PLCSConceptModel: Class: Document
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: assessment resultsassessment strategyassessment strategy issueaudit issueaudit or verification reportbusiness impact of solutionchange justificationchecklistcommissioning objectivecommissioning programme logiccommissioning task metricsconfiguration management plan *developed structure viewsdocumented problemelicited support needfeedback on support needsimpact assessmentimpact on related changesimpact report on an issueinformation from other systemsinformation management planinformation management rules *information management strategy *information model *information need *information release planinformation to system operator *information updateissuelife cycle directive *naming convention *needed informationperformance reportplan for validationproduct release reportrelated informationrequest for support concept changerequirement directivesolution definition reportsupport engineering objectivessupport information rules *support objective issuesupport opportunity objectivessupport policy *support predictionsupport review resulttransaction repliestransaction requestunresolved support conflictunresolved support drivervariance
Definition:
Document allows for documents (either physical or electronic) to be associated with PLCS data. It is treated as a type of Product and so can be configuration managed in the same way as a Product and included as part of
NOTE    PLCS provides the capability to manage versions of Documents. It also allows for the case where several electronic files comprise the Document and where different formats are derived from the same source.
EXAMPLE    The maintenance instructions for a system may be held as a file and managed as a Document. It may also be included in the Bill-of-Material for the "as-delivered" system.
EXAMPLE    CAD files, drawings, spread sheets, Task and procedures as S1000D files.
PLCSConceptModel: Class: Effectivity
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
An Effectivity provides the means to limit the applicability of some element of Life Cycle Support to a specific domain.
EXAMPLE    A given part may be used in a major assembly but only for some instances of the assembly. The allowed cases are specified as a range of serial numbers.
NOTE    PLCS provides for effectivities controlled by serial numbers, batch numbers, time intervals and dates as well as by Product_individual and by Condition.
PLCSConceptModel: Class: Environment
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: deployment environmentlocal support environmentoperating environmentsupport location capability
Definition:
Environment is used to describe the conditions in which a product is to be, has been or is planned to be deployed in, operated in, or supported in.
NOTE    PLCS provides the capability to record the expected environment for use in analysis and planning, plus the observed environments in which usage and support are carried out.
PLCSConceptModel: Class: Functional_breakdown
On diagrams: Top-level concepts 
Supertypes: Breakdown 
All Supertype Blocks: Breakdown  Product 
Supports ICOMS: functional breakdown
Definition:
A Functional_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of functions. Each function may be broken down further as required.
NOTE    Functional breakdowns are used as the basis for analysing failure modes and their effects. When a component breaks, the effect is to prevent one or more functions from being performed.
EXAMPLE    A functional breakdown provides a decomposition of a vehicle in terms of high-level functional processes such as propulsion, braking, steering, towing, load carrying, etc.
PLCSConceptModel: Class: Id_alias
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Identifiers are assigned to many different items within the scope of PLCS. An individual item may have different Identifiers associated with it over time and by different Organizations.
NOTE    Identifiers are always required to be associated with the Organization who initiated the Identifier. The uniqueness of Identifiers is dependent on the processes of that and other organizations assigning the identifier.
EXAMPLE    Serial numbers, Task identifiers, Part Numbers,...
PLCSConceptModel: Class: Information_right
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Information_right is a declaration of what may or may not be done with identified information from the perspective of legal rights and obligations.
EXAMPLE    The classification of information as Top Secret means that only those with Top Secret clearance can access the data.
PLCSConceptModel: Class: Interface
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: interface
Definition:
An Interface is an interconnection between a connected pair of parts or systems.
NOTE    Interfaces can be complex elements that have their own descriptions (sometimes called Interface Control Documents). Interfaces can also fail when the parts being interfaced have not failed.
EXAMPLE    Consider two pipes joined with flanges. If the connection is not sufficiently tight, the joint will leak yet neither pipe has failed.
EXAMPLE    The radar system has an interface to other systems on a vessel. This covers both physical attachment and electrical/electronic attachments
PLCSConceptModel: Class: Justification
On diagrams: Top-level concepts 
Supports ICOMS: change justificationproduct integrity exception
Definition:
A Justification is the identification and description of the reasons for something. Justification entities may be associated with the data to which they apply.
NOTE    Justification is provided to allow capture of "why" information. It provided to allow organizations to opt to collect richer sets of information around Product Life Cycle Support.
EXAMPLE    A justification may be provided for a product design. Similarly, a justification may be provided for why an activity is needed or was undertaken, such as justifying the approach taken to a complex repair task.
PLCSConceptModel: Class: Location
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Product_individual_version 
Supports ICOMS: assured support solutionidentified support location
Definition:
A Location is a place or position where an activity or event can occur or a product or resource can exist (such as a warehouse).
PLCSConceptModel: Class: Message_envelope
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
Message_Envelope allows for the creation of an historical record of the transmission of a data from and to a PLCS capable system. Its purpose to enable an audit trail where data is sent between systems.
EXAMPLE    Maintenance is performed on a ship using a ship-board maintenance system. The same records need to be available in the system used for fleet management. Message_envelope provides the means to track the passing of the data from on-board to the fleet system.
EXAMPLE    An up-grade of an on-vehicle system is carried out. Additional and revised tasks now exist. These are passed as a message to the vehicle fleet management system. In order to maintain the applicable warranty a record is kept of the supplied data while its contents are added to the appropriate maintenance systems.
PLCSConceptModel: Class: Observation
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Environment Work_request 
Supports ICOMS: assessment deficiencyassessment strategy issueaudit issueaudit or verification reportcommissioning feedbackcommissioning task feedbackevaluated support improvement opportunityfeedbackoperator feedback *performance reportproduct related feedbackrecorded issuerelated informationrelevant support driverrequest to embedrequirement feedbackresource feedbacksafety or support critical issuescheduling problem reportsuggestion for improvementsupport characteristic clarification requestsupport driversupport element status recordsupport feedbacksupport issuesupport metric clarification requestsupport review resultsupport task exceptionunresolved support conflictunresolved support driver
Definition:
An Observation is an historical record of something that has occurred during the life of a product or its support environment. Its use is restricted to observations not directly represented in the data model. It should not be used where some other reporting data structure is defined and applicable (such as State_observed).
PLCSConceptModel: Class: Part
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: affected itemclassified element or relationshipidentified elementproduct needing support
Definition:

A Part is a type of Product that collects the definitional information of the versions of either a part or of a non-countable material.

EXAMPLE    A helicopter and a nut are both Parts.
NOTE 1   A Part does not represent an actual physical object that is or was existing in the real world. In many cases the Part entity represents the design of the item.
NOTE 2   A complex instance of the Part entity and of the Document entity may be created in order to represent a document that is a component of a manufactured product, for example a user manual of a car.
PLCSConceptModel: Class: Person_organization
On diagrams: Top-level concepts 
Supports ICOMS: list of stakeholderspotential support providerrecognized stakeholderselected support provider
Definition:
A Person is an individual human being. An Organization is an administrative structure in which persons are active.
PLCSConceptModel: Class: Physical_breakdown
On diagrams: Top-level concepts 
Supertypes: Breakdown 
All Supertype Blocks: Breakdown  Product 
Supports ICOMS: physical breakdown
Definition:
A Physical_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of physical elements. Each physical element may be broken down further as required.
NOTE    Physical breakdowns are used as the basis for identifying dis-assembly structures. The breakdown stops when the element reached is a single component or a set of such components (such as the fixing nuts on a car wheel) or is an assembly that is replaced without further dis-assembly (a so called Line-removable part).
EXAMPLE    A physical breakdown might provide a decomposition of an vehicle in terms such as body, roof, bonnet, bumpers, seats, etc. This breakdown might be different from a parts only decomposition or from the bill-of-material used in manufacturing the vehicle.
PLCSConceptModel: Class: Planned_product
On diagrams: Top-level concepts 
Supertypes: Product_individual_version 
All Supertype Blocks: Product_individual_version  Product_version 
Supports ICOMS:
Definition:
A Planned_Product is a type of Product_individual_version that identifies a revision of an individual artefact that has yet to be made.
EXAMPLE    A ship is required in 5 years' time. Information will begin to be collected about the intended ship long before it starts to be built and is associated to the Planned_product.
PLCSConceptModel: Class: Product
On diagrams: Top-level concepts 
Realized Interfaces:  
Subtypes: Slot  Work_order  Approval  State  Location  Environment  Requirement  Activity_method  Verification_and_Validation  Observation  Trigger  Product_individual  Breakdown  Resource  System  Contract  Interface  Project  Work_request  Activity  Document  Part 
Used by: Product_individual_version Product Environment Planned_product Activity_method Activity_method Verification_and_Validation Realized_product Contract 
Supports ICOMS:
Definition:
A Product is the parent concept for part, system and all the different "types" of product in PLCS.
NOTE 1   Products that can be represented include: For the purposes of PLCS, Product is used as the overarching concept to cover many items that are of interest and have versions, structure and definitions and that may be subject to configuration management. These include Requirements, Interfaces and Documents.
EXAMPLE 1   The SS Titanic is a product that could be represented by the entity data type Product.
EXAMPLE 2   Lifeboat is a class of products that could be represented by the entity data type Product. Each lifeboat on the SS Titanic is a member of this class.
NOTE 2   A product is identified by an organization or a person in an organization. The definition of the domain of uniqueness and the mechanism for guaranteeing the uniqueness of product id are outside the scope of this application module.
NOTE 3   A product may have zero or more versions. A version of a product is represented with an instance of the entity Product_version or of one of its specializations.
PLCSConceptModel: Class: Product_definition
On diagrams: Top-level concepts 
Used by: Product_definition Product_definition Baseline Product_version Product_group 
Supports ICOMS: product assembly structure
Definition:
A Product_definition is a collection of information gathered for some purpose and usually representing or describing a Product_version. The information is taken to be relevant in one or more application domains and for one or more life cycle stages.
EXAMPLE 1   The design of the SS Titanic and the as-built description of the SS Titanic can be represented as two instances of Product_definition.
PLCSConceptModel: Class: Product_group
On diagrams: Top-level concepts 
Used by: Product_group Project 
Supports ICOMS: affected itemclassified element or relationshipidentified elementproduct needing support
Definition:
A Product_group is an identification of a set of Products (usually Parts), Product_groups, Product_versions or Product_individuals that have been grouped together.
EXAMPLE    All the aircraft in a squadron. All the aircraft of the same type operated by a given country's Air Force. All the variants of an aircraft that are going to be purchased under a contract.
NOTE    A Product_group may contain a mix of different items, such as all the vehicles located at a specific base which may include vehicles from several manufacturers.
PLCSConceptModel: Class: Product_individual
On diagrams: Top-level concepts 
Realized Interfaces:  
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: affected itemclassified element or relationshipidentified elementproduct needing support
Definition:
A Product_individual is a type of Product that identifies an individual artefact that has been made or is planned to be made. It is a collector of data common to all revisions of the Product_individual.
NOTE 2   Where physical products are being represented, the Product_individual represents the physical or planned physical realization of a product.
NOTE 3   It is likely, but not essential, that the artefact, was or will be made according to a design. The product design will be represented by a Part.
NOTE 4   Many physical products may be produced from a given design. A single Part may lead to many Product_individuals.
EXAMPLE 2   The design of a personal computer is represented by a Product. The personal computer with a serial number on a person's desk is represented by a Product_individual and an associated revision represented by Realized_product.
EXAMPLE 3   The personal computer that has been ordered, allocated a serial number for manufacturing planning, but not yet manufactured, is represented by a Product_individual and an associated revision represented by Planned_product.
EXAMPLE 4   HMS Daring is the first of a new class of ships known as Type 45 Destroyers.
PLCSConceptModel: Class: Product_individual_version
On diagrams: Top-level concepts 
Supertypes: Product_version 
All Supertype Blocks: Product_version 
Subtypes: Planned_product  Realized_product 
Used by: State Observation Activity_planned Activity_planned Trigger State_definition Activity_actual Activity_actual Activity Activity 
Supports ICOMS:
Definition:

A Product_individual_version identifies a version of an individual product.

NOTE    Versioning schemes for individual (built) products vary according to business area and organization. A Baseline in one business will be treated as a new version in another.
EXAMPLE 1   The car on my drive is represented by a Product_individual. The current configuration status of the car can be represented by a Realized_product related to the Product_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 Realized_product.
PLCSConceptModel: Class: Product_version
On diagrams: Top-level concepts 
Subtypes: Product_individual_version 
Used by: Product Baseline Product_version Product_group 
Supports ICOMS:
Definition:
A Product_version is a revision of a Product.
NOTE    The set of all instances of Product_version of the same Product represents the version history of the product. Each Product_version may have many Product_definitions associated with it.
PLCSConceptModel: Class: Project
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS:
Definition:
A Project is an identified program of work. It may be associated with a specific Product_group or Product.
PLCSConceptModel: Class: Property
On diagrams: Top-level concepts 
Supports ICOMS: life or usage parameterpredicted downtimequantified support metricsupport characteristicsupport prediction
Definition:
A Property is the record of an attribute or characteristic that is applicable to something.
NOTE    A property may specify the intended value or the actual value or some person/organization's best estimate. The value may apply for all time or at moment in time. Additional information is needed to distinguish between these cases.
EXAMPLE    Example properties of a part are "mass", "surface finish", "mean-time between failure", colour, "cost when purchased singly". Example property of a Task is "mean elapsed time to perform".
PLCSConceptModel: Class: Realized_product
On diagrams: Top-level concepts 
Supertypes: Product_individual_version 
All Supertype Blocks: Product_individual_version  Product_version 
Supports ICOMS:
Definition:
A Realized_Product is a type of Product_individual_version that identifies a revision of an individual artefact that has been made. A product whose properties can only be known by observation or by derivation from observations.
NOTE 1   Where physical products are being represented, the Realized_product represents the physical product - something one can touch (ignoring any health and safety issues that may apply if you do). The properties of a Realized_Product can only be known by observation or by derivation from observations.
NOTE 2   The artefact may have been made according to a version of a product design ( Product_version).
NOTE 3   The artefact may have been planned and represented by Planned_product.
PLCSConceptModel: Class: Representation
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
A Representation is a collection of data that represents something of interest.
EXAMPLE    A part may be represented as a CAD model in its preliminary or final design, as an analysis model, as a physical mock-up and as a graphic or photographic image.
NOTE    Compatible representations will usually share a common context. In CAD models this implies the same or a related coordinate system is used. For property values, this implies similar units and similar measuring or calculation methods have been used.
PLCSConceptModel: Class: Requirement
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Verification_and_Validation 
Supports ICOMS: agreed support needallocated support requirementsassessment resultscommissioning objectivecommissioning programme logiccommissioning task metricselicited support needexternal factor *information collection requirementrequest for support itemrequirement for product structure view *support engineering objectivessupport opportunity objectivessupport policy *support solution requirement
Definition:
A Requirement is a type of Product that is used to uniquely identify a requirement.
NOTE 1   The term "requirement" is used here in the sense that term is used in systems engineering and similar industrial domains.
NOTE 2   There may be many versions of a requirement. There may also be more than one domain-specific view of a given version.
EXAMPLE    A requirement may be identified as "NOx emissions requirement", and uniquely identified as "Req2".
NOTE 3   Systems engineering tools and organizations may use differing identification mechanisms. Multiple identifiers may be assigned to a requirement.
PLCSConceptModel: Class: Resource
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Activity 
Supports ICOMS: assured support solutioninformation technology service or infrastructureintended resource holdingslocal support environmentpredicted resource consumptionrequired resourcesresource item descriptionresource recommendationssupport elementsupport infrastructuresupport location capabilitytask resource modeltask resources
Definition:
A Resource is something that is held, used and managed in order to meet a requirement stemming from another item. The role of a Resource is determined by classification.
EXAMPLE 1   Resources include infrastructure, energy, trained people and parts (either for use as tools, test equipment or for installation into an item being supported. "Facility", "Test equipment", "Supervisor" are examples of roles of a resource.
EXAMPLE    A part that is held in readiness for use as a replacement (commonly referred to as a "spare part") is a Resource.
PLCSConceptModel: Class: Risk
On diagrams: Top-level concepts 
Supports ICOMS: change riskexternal factor *
Definition:
A Risk specifies is the potential for realization of unwanted negative consequences of an event.
NOTE 1   ISO/IEC GUIDE 73:2002 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 2   A risk can also have a possible positive outcome. In such cases it is often referred to as an opportunity or reward.
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.
EXAMPLE 1   'Line shutdown' is an example of Risk in the context of a manufacturing system's reliability.
EXAMPLE 2   'Transportation jam-up', 'customer anger', 'collateral damage', and 'greater susceptibility to interruption of supply during crises' are all examples of Risk.
EXAMPLE 3   'Privacy' and 'security' are examples of Risk for the telecommunications industry.
EXAMPLE 5   Timing concerns such as 'premature rejection' and 'premature commitment' are other examples of Risk.
PLCSConceptModel: Class: Scheme
On diagrams: Top-level concepts 
Supertypes: Activity_method 
All Supertype Blocks: Activity_method  Product 
Supports ICOMS: assured support solutionchange development planchange planconfiguration management plan *development planidentified solutionimpact on related changesimplementation planinformation management planinformation release plannecessary taskoperating scheduleother taskplan for validationpotential solutionquantified solutionrelevant support driverrequired structuresrequired tasksselected commissioning tasksolution definition reportsupport driversupport engineering schedulesupport opportunitysupport plansupport plan optionsupport predictionsupport schedulesupport solution definition
Definition:
A Scheme is a type of Activity_method. 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.
NOTE    A Scheme may be classified as a Plan or Schedule, and it may be further classified into specific types of Plans or Schedules.
EXAMPLE    Acquisition plan, Maintenance plan, Resource schedule are examples of schemes.
PLCSConceptModel: Class: Skill
On diagrams: Top-level concepts 
Supports ICOMS:
Definition:
A Skill is a level of expertise, aptitude and ability appropriate for a specific job.
PLCSConceptModel: Class: Slot
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS:
Definition:
A Slot is a type of Product that represents the position in which a part is or can be attached to a parent product.
EXAMPLE    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.
PLCSConceptModel: Class: State
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Subtypes: State_observed  State_definition 
Used by: Product_individual_version Activity_planned Activity_planned Trigger Activity_actual Activity_actual Activity 
Supports ICOMS: individual product statepredicted product state and usageproduct integrity exceptionstatus of change taskunresolved support driverwork status
Definition:
A State is the mode of being in which something does or could exist or existed for a period of time.
NOTE 1   A state's existence can be just a state that an object is currently in, a predicted state that an object will eventually be in, or an observed state that an object has been in.
NOTE 2   The period of existence may be an instant or longer.
EXAMPLE 1   Main Engine No. 1 is in "operation".
EXAMPLE 2   When Generator No. 2 surpasses 5,000 service hours, it will enter "maintenance" mode.
EXAMPLE 3   The portable computer's power supply was attached after it displayed a "low-battery" warning.
PLCSConceptModel: Class: State_definition
On diagrams: Top-level concepts 
Supertypes: State 
All Supertype Blocks: State  Product 
Used by: Product_individual_version State_observed 
Supports ICOMS:
Definition:
A State_definition is a mode of being. In formal systems, a State_definition is the definition of a situation during which some (usually implicit) invariant condition holds.
PLCSConceptModel: Class: State_observed
On diagrams: Top-level concepts 
Supertypes: State 
All Supertype Blocks: State  Product 
Used by: Observation 
Supports ICOMS: commissioning feedbackfeedbackoperator feedback *performance reportproduct historyproduct related feedbackproduct statusproduct status recordrecorded issuerelated informationrelevant support driverresource feedbacksafety or support critical issuesupport driversupport element status recordsupport feedbacktask related feedback
Definition:
A State_observed is a type of State. It is an individual or realized State that is observed.
PLCSConceptModel: Class: System
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS: information technology service or infrastructure
Definition:
A System is a combination of interacting elements organized to achieve one or more stated purposes.
NOTE    A system may be a conceptual solution to a collection of requirements or it may be a realized system. The concept system is any thing - matter, energy, organisation 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.
EXAMPLE    The fuel, lighting, steering and braking systems on a vehicle. In some cases the complete vehicle may also be designated as a system.
PLCSConceptModel: Class: System_breakdown
On diagrams: Top-level concepts 
Supertypes: Breakdown 
All Supertype Blocks: Breakdown  Product 
Supports ICOMS:
Definition:
A System_breakdown is a type of Breakdown that identifies a partitioning of a system into a set of related systems and sub-systems. Each system or sub-systems may be broken down further as required.
EXAMPLE    A system breakdown provides a decomposition of an aircraft in terms of high-level mechanisms such as fuel system or flight control system - which might, in the second case, further decompose into low-level systems such as autopilot system and instrument landing system.
PLCSConceptModel: Class: Task
On diagrams: Top-level concepts 
Supertypes: Activity_method 
All Supertype Blocks: Activity_method  Product 
Supports ICOMS: PIF task setassured support solutionauthorized taskchange development taskchecklistcommissioning taskconsequential taskidentified solutioninformation management rules *information need *information updatelife cycle directive *necessary taskother taskpotential solutionpotential taskquantified solutionrequired structuresrequired tasksrequirement directiveselected commissioning tasksolution definition reportsupport information rules *support solution definitiontask applicabilitytask descriptiontask logictask proceduretask to determine product statetask to product relationshiptask to scheduletriggered task
Definition:
A Task is a specification of how some work is performed. The task method may be implemented using people, machines or a combination
EXAMPLE    The instructions for how to remove and replace a sub-assembly. The instructions for carrying out a pre-flight inspection.
PLCSConceptModel: Class: Trigger
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Activity 
Supports ICOMS: support characteristictask trigger
Definition:
A Trigger is the condition or conditions or other event that imply the requirement to undertake an activity.
EXAMPLE    Reaching a certain odometer reading is the trigger for a vehicle service. Undergoing a refused take-off is the trigger for an inspection of a plane's braking system. Reaching a certain age is the trigger for replacement of a part.
PLCSConceptModel: Class: Verification_and_Validation
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Supports ICOMS:
Definition:
A Validation is a subjective assertion that an item is "fit for purpose". The assertion is back up by evidence.
NOTE    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. An item may pass validation even though some requirements fail verification.
EXAMPLE    The sea trials undertaken on a new ship are a form of validation.
A Verification is an objective assertion that a claim that a requirement is satisfied by a particular item is .
NOTE    Verification is commonly understood to mean "Have we built the system right?". Verification ensures that the specified requirements have been met. Verification often uses the methods of Test, Analysis, Inspection, Demonstration, and Similarity.
NOTE    Just because an item is verified does not ensure that it meets all stakeholder needs or expectations. Some needs as specified in requirements are of an un-testable nature.
EXAMPLE    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.
PLCSConceptModel: Class: Work_order
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Activity_planned Activity_actual Activity 
Supports ICOMS: change directivechange ordercosted changeidentified solutionissue requiring change actionrecommended changevalid need for change
Definition:
A Work_order is an authoritative instrument which provides directions to achieve the specified results.
NOTE    A Work_order may be the authorization for one or more activities to be performed.
PLCSConceptModel: Class: Work_request
On diagrams: Top-level concepts 
Supertypes: Product 
All Supertype Blocks: Product 
Used by: Work_order 
Supports ICOMS: change directiveclassified solutioncommissioning task requestdocumented problemevaluated support improvement opportunityfeedback on support needsinadequate sourceinformation collection requirementissueissue requiring change actionmaintenance needneed for revised solutionneeded informationobjective change requestpotential solutionprogramme change requirementrationalization proposalrecorded issuerejected issuerejected request for changerelevant support driverrequest for assessment of financial impactrequest for effectivity impact assessmentrequest for identifierrequest for impact report relating to issuerequest for investigationrequest for other actionrequest for requirement clarificationrequest for schedule revisionrequest for solution development and impact assessmentrequest for support concept changerequest for support itemrequest for task evolutionrequest for task procedurerequest for updaterequest to embedrequest to identify and prioritize changerequest to life cycle ownerrequest to redefine problemrequired tasksrequirement feedbackrequirement to designsafety or support critical issuesuggestion for improvementsupport characteristic clarification requestsupport driversupport improvement opportunitysupport issuesupport metric clarification requestsupport review resultunresolved support conflictunresolved support driver
Definition:
A Work_request is the solicitation for some work to be done.
NOTE    These requests may not be acted upon depending on the authorization granted to the request or its associated Work_order.
PLCSConceptModel: Class: Zonal_breakdown
On diagrams: Top-level concepts 
Supertypes: Breakdown 
All Supertype Blocks: Breakdown  Product 
Supports ICOMS:
Definition:
A Zonal_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of related zones or spatial elements. Each zone may be broken down further as required.
EXAMPLE    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'. Such a breakdown can be used as the basis for inspection tasks.
PLCSConceptModel: Interface:
On diagrams: Top-level concepts 
Interface realized by: Product  Product_individual 
Used by: Product_group 
Supports ICOMS:
PLCSConceptModel: Interface: resource_item
On diagrams: Top-level concepts 
Used by: Approval Resource 
Supports ICOMS:
Definitions only
Full display