Business overview

This section provides a business level overview of this capability.

This capability provides the necessary information to represent breakdown structures, e.g. to enable the delivery of assured product and support information (APSI) from the Original Equipment Manufacturer (OEM) (for example, Ship Builder , weapon system developer, bicycle manufacturer), to the owner, operator or maintainer who is required to support the product when in service.

Depending upon the specific product, various views of the product will be required to enable the identification of the various systems, functions, or physical parts, together with identifying zones within the product or a combination of these (hybrid view).

With the identification of these aspects, the usual operations of the product might then be supported, for example, regular maintenance, condition based maintenance, usage reporting, failure reporting, part changes, function changes, replacements and the upkeep to both the product and the product information can be enabled. These views are documented as various types of product breakdowns.

The AP239 PLCS approach to product breakdown comprises the following;

1. the identification of a product or product_as_individual (i.e. what is the product being broken down);
2. the identification of the type of breakdown selected for the product or product_as_individual (i.e. the type of breakdown);
3. the identification of the elements that comprise a breakdown (i.e. the constituents of the breakdown);
4. the identification of parent-child relationships between breakdown elements (i.e. the breakdown structure);
5. the (optional) identification of relationships between elements in different breakdowns (i.e. the breakdown element relationships).

Basic structure

A breakdown is always related to a design or a real product, of which it is a breakdown. It is identified and versioned as an object in its own rights. It has a number of constituents (breakdown_elements), often structured hierarchically, that makes up the breakdown structure.

Figure 1 —  A sample breakdown of an individual bike, showing the breakdown and some of its constituents (physical_elements).

A constituent is valid in the context of a breakdown, i.e. there is always a context breakdown for a breakdown_element as part of its definition (which is different to a traditional assembly structure, e.g. bill-of-materials, where each part exists in its own rights, whether or not it is used in an assembly). It is possible to relate a breakdown_element to breakdown_elements in other breakdowns, but a specific breakdown_element will always only be part of one product breakdown.

Figure 2 —  Sample relationships between breakdowns.

Each breakdown_element may or may not relate to any number of designs (assembly structures) of which one should be used to realize the constituent.

Figure 3 —  A sample breakdown of a designed bike. Constituents may relate back to design, indicating what realizes the breakdown_element.

Types of breakdowns

The AP239 PLCS schema defines the following types of product breakdowns.

• Functional breakdown
• System breakdown
• Physical breakdown
• Zonal breakdown
• Hybrid breakdown (a mix of the above).

Other types of breakdowns may be defined and used through the definition of reference data.

NOTE    A Work Breakdown Structure is not a breakdown of a product, but of activities and tasks, and should therefore not use the Breakdown structure as described here. See instead C062: representing_scheme.

Information model overview

This section provides an overview of the information model that supports this capability.

A breakdown is a partitioning of a product into a set of related elements to support engineering, analysis and other activities that may be performed in relation to the product. These breakdowns are explicit, parent-child views that comprise the product elements.

Breakdowns are complementary to the assembly structure and bill of materials views that are the primary focus for manufacturing (realization) of a product (see the C003: representing_assembly_structure capability for details). Breakdowns may be of designs or realized individual products. For any product, more than one breakdown may exist to support various different activities.

Figure 4 captures the essential areas for representing a breakdown.

Figure 4 —  Abstract View of the Breakdown Structure Model

NOTE    The use of colour here is to attempt to group the entities at various levels in the model. Those in light-green represent entities that represent the product under consideration. Those in light-red represent intermediate concepts between the product and it's elements (the Breakdown itself). Those entities in shades of blue represent the numerous elements of the product. Those in light-yellow indicate where relationships are used to link the concepts of the different levels. These colours are used elsewhere as an aid-memoire in navigating the model.

The basic schema, shown in Figure 5 provides the following entities:

• Breakdown - to provide the information constant to all versions, e.g. name, identifier and type of the breakdown.
• Breakdown_version - to provide the information that may change between versions, such as constituents.
• Breakdown_of - to identify the product which is broken down using the breakdown
   
• Breakdown_element - provides information for a constituent in the breakdown
• Breakdown_element_version - provides information of the version of the constituent
• Breakdown_element_definition - provides the definition of the version of the constituent, such as properties.
• Breakdown_element_usage - provides a hierarchical structure for breakdown elements
• Breakdown_context - relates each constiuent breakdown_element to a specific version of the breakdown.
   
• Breakdown_element_realization- relates a breakdown constituent to a product that realizes it, e.g. a part assembly or a breakdown element in another breakdown.

Figure 5 —  Express-G model of entities for general breakdown structures.

A breakdown is represented through a Breakdown (that specifies the representation of various breakdowns of products), or through one of it's subtypes, such as; System_breakdown (for the representation of various breakdowns of a systems), Functional_breakdown (for the representation of various functional breakdowns of products), Physical_breakdown (for the representation of various physical breakdowns of products), Zone_breakdown (for the representation of various zonal breakdowns of products), or through a Hybrid_breakdown (for the representation of various hybrid breakdowns of products). The entities for specific types of breakdowns are shown in Figure 6.

Figure 6 —  Express-G model of entities for breakdown subtypes.

Whenever a Breakdown is referred to in this capability, it implicitly refers to any of it's subtypes mentioned above, unless stated otherwise.
The section "Additional Usage Guidance" describes more about the use of the different subtypes, entities and any related constraints.

There are a number of aspects to note about the functionality of this model. Firstly, for any product design or individual, there may be more than one type of breakdown. The second is that each breakdown may have more than one element as a constituent. Thirdly, the various in-built types of breakdowns made explicit by the model (i.e. functional, physical, zone and system), may reflect the various life cycle stages applicable to many products, so those defined later in the life cycle will not necessarily be present early on. The model thus, provides the means to represent the product at various phases of the life cycle. This can then be exploited during subsequent phases where for example, physical elements may eventually realize the elements defined during the functional design phase. Similarly, the physical elements may be realized by the assembly. Thus, since each breakdown may become a structure (tree-like), they may present orthogonal views on the same part or individual. One way to visualise this is as many product trees inter-connecting at various points across a network. However, they all have their own root according to the breakdown defined.

NOTE    It is not expected, nor to be assumed that every node in one breakdown will correspond with that of one of more nodes in other breakdowns or assembly definitions. Indeed, the structuring of the information may well be different and should be expected to be so.

Representing a Breakdown Structure

The representation of a breakdown structure have been divided in sevaral steps, and uses the general entity Breakdown (not its subtypes) to illustrate a breakdown of access spaces on an aircraft wing.

NOTE    One could argue that the breakdown of the access spaces is a Physical_breakdown, or a Zone_breakdown, but the focus here is to provide an understanding of the general structures of any breakdown, and the "correct type of breakdown" for this particular example is not important. In fact, this actually highlights the potential difficulties one might have in deciding what type of breakdown to use.

Representation and identification of the breakdown

The first step is to determine the type of breakdown and to relate this to an identified product.

The different breakdown types were highlighted earlier and are individually described in Additional Usage Guidance below. The types have been made explicit by the model to enable the easy distinction between them. However, it is neither possible nor sensible to explicitly define all possible types of breakdowns. When a breakdown is required which does not fit into the one of the subtypes (or specializations of them using external reference data), then the generic breakdown entity should be used.

For example, a breakdown of Logistically Significant Items (LSI) could be a general breakdown. Thus, the LSI breakdown of a car may consist of brake pads, air filter, fuel filter, tyres, tubes, gearbox, exhaust etc., which may be different from, and orthogonal to, a parts decomposition or other breakdown views. Alternatively, there could be an "LSI" subtype of a physical breakdown (for example), which may highlight certain, but not all, of the physical items.

A Breakdown is also a Product (see Figure 5 for an overview of the schema) and, thus, has identification and at least one version (Breakdown_version). The representation of the identification is described in the capability C001: assigning_identifiers. The type of breakdown should always, for all breakdowns, be identified through the use of external reference data.

NOTE    This means that e.g. the subtype System_breakdown should have reference data 'System_breakdown" (or one of its subclasses defined in reference data) assigned to it.

Each version of a Breakdown (Breakdown_version) is related to the product (Product_view_definition) that is the subject of the breakdown through the Breakdown_of entity. This enables the versioning of products to be mirrored in the versions of a breakdown, if required.

NOTE    The entity product is abstract which means that one of it's subtypes must be used. Guidance on how to identify and represent products are given in capabilities C002: representing_parts (for designed parts), C045: representing_product_as_individual (for individual, real products), and in C003: representing_assembly_structure (for assemblies of both).

The instantiation diagram below show the use of Breakdown, Breakdown_version and Breakdown_of entities for the breakdown representation, and identification of the Part using the example of an aircraft wing.

NOTE    All attributes of entities Breakdown, Breakdown_version, and Breakdown_of should be set to 'IGNORE', and are not used.

Figure 7 —  Representation and Identification of the Breakdown

NOTE    The Breakdown entity instance provides the type of Breakdown selected to represent the view being provided, by assignment of external reference data.

NOTE    The Breakdown_of entity instance may be identified through the usual manner of identification_assignment.

Representation and identification of the breakdown constituents

The second step is to represent and identify the consituents of the breakdown, i.e. the associated breakdown elements (see Figure 5 for an Express-G overview).

A breakdown constituent is represented by a Breakdown_element (a subtype of Product) identifying the constituent, at least one Breakdown_element_version that provides information regarding different versions of the constituent, and one (or more) Breakdown_element_definition defining each version, e.g. with properties assigned etc.

Each element is related to the breakdown through an instance of Breakdown_context. This is a relationship between a Breakdown_version and a Breakdown_element_definition and provides the ability to collect each element associated with a specific context (such as a functional design).

NOTE    Different types of breakdowns have different types of elements and the model constrains these to be of a like-kind (with certain exceptions) as will be shown later. The different types of breakdown also have their own context.

A Breakdown_element may appear in one or more breakdowns, through multiple Breakdown_context entity instances.

Consider an aircraft wing and the various access points to fuel, drainage, wiring and pnuematics. Some of the access spaces are shown in the tree structure below.

Figure 8 —  Hypothetical Wing Breakdown in terms of Access Spaces

NOTE    The letters "AS" denote Access Space

The example (continuing from that previous), attempts to create a breakdown of such spaces which might be considered logistically significant for maintenance support. It groups together the access spaces into a specific set of breakdown elements. These may or may not have also been defined in other breakdowns or assembly structures. The constituents defined below only represent the access spaces, but not the relations between them.

NOTE    The figure below do not show all breakdown_elements in the above example, it focuses on the tank access spaces. It also do not cover all details for all breakdown_elements due to limited space. The top-most breakdown_element is however complete. All attributes of Breakdown_element, Breakdown_element_version, Breakdown_element_definition, and Breakdown_context should be set to 'IGNORE', and are not used.

Figure 9 —  Instantiation diagram showing the relationships between Breakdown and some relevant constituents

NOTE    The elements, versions and their definitions can be likened to identifying the nodes in a tree structure - but not the structure itself (the relations between the nodes). This is a matter for the following step.

NOTE    The Breakdown_element_definitions may each define a separate view_definition_context where there is significant information to distinguish one definition from another. However, where there is commonality, one view_definition_context may be shared by several definitions. Additional contexts may be defined to further distinguish between such groupings through the additional_contexts attribute of the Breakdown_element_definition.

Representation and identification of the breakdown structure

The third step is to represent and identify parent - child relationships between the breakdown constituents to provide the structure of the breakdown (see Figure 5 for an Express-G overview).

The relationships between different Breakdown_element_definitions are provided by entity Breakdown_element_usage.

NOTE    The Breakdown_element_usage entity may be the subject of configuration management. This is achieved through the Item_usage_effectivity entity, which is further described within the capability C006: assigning_effectivity. Thus, a breakdown and it's elements may be associated with a type of effectivity.

A Breakdown_element_usage identifies the parent-child relationship between a pair of Breakdown_element_definition instances in the context of the relevant breakdown. The complete breakdown hierarchy consists of a tree of Breakdown_element_usage instances.

Hence, each Breakdown_element_usage relates Breakdown_element_definitions, Breakdown_element_versions and ultimately, Breakdown_elements together.

NOTE    Just as there are different types of breakdown elements for the subtypes of Breakdown, there are different subtypes of Breakdown_element_usages as well, and the model constrains these to be of a like-kind (with certain exceptions) as will be shown later.

The simplified instantiation diagram below covers a number of the parent - child relationships depicted in the initial hierarchy earlier in the section. The Breakdown_element_usage instances are here depicted in yellow colour, and the breakdown_elements have been placed in a hierarchical fashion to illustrate the structure.

NOTE    All attributes of Breakdown_element_usage should be set to '/IGNORE', and are not used. Realtionships to the Breakdown context have been omitted here, as well as relationships to View_definition_context. Entity instances are incomplete regarding identification and naming in favour of simplicity.

Figure 10 —  Simplified instantiation diagram showing the structure between breakdown_elements, using instances of Breakdown_element_usage

NOTE    Each Breakdown_element_usage may be uniquely identified using the identification_assignment mechanism, which means that each parent-child relation is identifiable.

Representation of the Breakdown Realization relationship

An optional fourth step is to identify and represent relationships between other breakdowns and their constituents.

This supports the requirement to trace the assured product and support information through the various product structure representations (or views of the product) that may be generated during the life cycle of the product. This would therefore, allow the same part to be traced (for example) from a functional breakdown definition through a physical breakdown, to an assembly view. Other breakdown views such as zone, system or even hybrids may then also be realized by referencing the others already defined.

There is no set order to which must be provided, except to say that most manufacturers' product development moves from functional design to physical design, and thence from design to assembly. Thus, realizations of functional breakdowns (such as a physical breakdown or assembly structure) may not be possible at the early stages of product development

It is also possible that breakdowns for support and maintenance for after product delivery may be realized by structures defined during the earlier stages of design. Hence, maintenance breakdown views may be realized by aspects across functional, physical, zonal, system, hybrid breakdowns including assembly structures.

The requirement to identify the relationship between a breakdown_item and a product_item, is is achieved through a Breakdown_element_realization.

A Breakdown_element_realization is a type of Product_definition_element_relationship that identifies a relationship between a breakdown_item and a relevant product_item, that realizes that element definition or usage.

A breakdown_item may be either a Breakdown_element_definition or a Breakdown_element_usage.

A product_item may be either a type of Product_view_definition, or a type of View_definition_usage.

Types of Product_view_definition include; Part, Breakdown, Slot, Interface_specification, Interface_connector, and Requirement views.

NOTE    The model thus, allows a breakdown element in one breakdown to be the realization of another. For example, a node in a physical_breakdown may well represent the realization of a node in a functional_breakdown. That is, a physical element pump may realize the 'provide fuel to engine' element in a functional breakdown for a ship.

As an example, consider a bicycle where multiple breakdowns have been created from initial design to manufacturing. Figure 11 shows a functional element "Provide illumination" being realized by a system element "Lighting system". This system, in turn, contains a sub-system called "illumination system", which is realized as a physical element "Lights". It contains two elements, and the "Head light" may be realized by any of three different parts from different manufacturers, here said to have been '"validated", i.e. approved for use in the bicycle.

Figure 11 —  Breakdown element realization across breakdowns, and to validated parts

NOTE    There is no restriction as to how many or how few breakdown structures are created for a given product, this must be a business decision. The given example is probably a bit over-worked.

Model Characterization

This section specifies how the information model can be further characterized by the assignment of additional information such as dates, approvals and people or organizations.

The following characterizations may apply.

Characterization: Classification of Breakdown and Breakdown Elements

All instances of Breakdown and Breakdown_element and their subtypes must be classified as to what type of breakdown and breakdown_element it is.

An instance of Breakdown must be classifed by a subclass of "Breakdown" (urn:plcs:rdl:std:Breakdown).
An instance of Breakdown_element must be classifed by a subclass of "Breakdown element" (urn:plcs:rdl:std:Breakdown element).

Thus, an instance of Functional_breakdown must be classifed as "Functional breakdown" (urn:plcs:rdl:std:Functional breakdown) or one of its subclasses.
An instance of Functional_element must be classifed as "Functional element" (urn:plcs:rdl:std:Functional element) or one of its subclasses.
An instance of Physical_breakdown must be classifed as "Physical breakdown" (urn:plcs:rdl:std:Physical breakdown) or one of its subclasses.
An instance of Physical_element must be classifed as "Physical element" (urn:plcs:rdl:std:Physical element) or one of its subclasses.
An instance of System_breakdown must be classifed as "System breakdown" (urn:plcs:rdl:std:System breakdown) or one of its subclasses.
An instance of System_element must be classifed as "System element" (urn:plcs:rdl:std:System element) or one of its subclasses.
An instance of Zone_breakdown must be classifed as "Zone breakdown" (urn:plcs:rdl:std:Zone breakdown) or one of its subclasses.
An instance of Zone_element must be classifed as "Zone element" (urn:plcs:rdl:std:Zone element) or one of its subclasses.
An instance of Hybrid_breakdown (if used) must be classifed as "Hybrid breakdown" (urn:plcs:rdl:std:Hybrid breakdown) or one of its subclasses.

Classification is assigned using external reference data, and is described in Capability C010: assigning_reference_data.

Characterization: Classification of relations (Optional)

Instances of Breakdown_of, Breakdown_element_realization, and In_zone, and instances of Breakdown_context and Breakdown_element_usage and their subtypes, may be classifed using external reference data (see Capability C010: assigning_reference_data).

This is particularly useful when many different types of breakdowns are defined for one product, or when several type of relationships e.g. between elements are needed.

Characterization: Assignment of classification codes (Optional)

All instances of Breakdown_element and its subtypes may be given a classification code, e.g. an LCN-number (a number according to a Logistics Control Number system).

The assignment of codes is described in Capability C093: assigning_codes.

Characterization: Assignment of additional identifiers (Optional)

Any entity for breakdowns except Breakdown_of and In_zone may be given additional identifiers. Identifiers are assigned in a given role, such as "Owner of" (urn:plcs:rdl:std:Owner of), or "Creator of" (urn:plcs:rdl:std:Creator of), and the identifier is considered unique within the context of the given Organization (see further Capability C001: assigning_identifiers).

This is very useful when organizations want to use their specific identifier, or when ithe identifier may change over time. Since a name in PLCS is an identification, it is also very useful when a product requires both an identification code and a name. Both the identification code and the name is assigned using the same mechanisms.

Characterization: Assigning Descriptors (Optional)

A Descriptor (a descriptive text string) can be assigned to any entity for breakdowns except Breakdown_of and In_zone. It is always classified as "Description" (urn:plcs:rdl:std:Description).

The assignment of descriptors is described in the capability C095: assigning_descriptor.

Characterization: Assigning Documents (Optional)

Documents can be assigned to Breakdown_element_definition and Breakdown_version and their subtypes. Documents are assigned in a given role, such as "Definition", "Specification", or "Description". The role of the assignment is represented by classifying the assignment by the use of reference data (see C010: assigning_reference_data. Suitable reference data classes may be defined in business specific external reference data

The assignment of documents is described in the capability C005: representing_documents.

Characterization: Assigning Properties to Breakdown Elements (Optional)

Properties may be assigned to instances of Breakdown_element_definition and its subtypes.

Since a Breakdown_element is a type of Product, properties are assigned as described in capability C076: assigning_product_properties, C079: representing_properties_numerically, and C080: representing_properties_textually.

Characterization: Assigning Date and Time (Optional)

Dates and Time can be assigned to any of the entities for breakdowns except Breakdown_of and In_zone. The date or time must be assigned in a given role, such as "Date actual creation" (urn:plcs:rdl:std:Date actual creation) or "Date planned release" (urn:plcs:rdl:std:Date planned release).

NOTE    Time is classified using the same reference data as Dates, i.e. an assigned time (a date plus hours, minutes and seconds) may be classified as "Date actual creation" (urn:plcs:rdl:std:Date actual creation).

The role of the assignment is represented by classifying the assignment by the use of reference data (see C010: assigning_reference_data). The full set of reference data for dates and time defined in DEXlib are:

• "Date actual creation" (urn:plcs:rdl:std:Date actual creation)
• "Date actual release" (urn:plcs:rdl:std:Date actual release)
• [Date_actual_for_discontinuation]
  Error RDL1: The class Date_actual_for_discontinuation does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• "Date planned creation" (urn:plcs:rdl:std:Date planned creation)
• "Date planned release" (urn:plcs:rdl:std:Date planned release)
• [Date_planned_for_discontinuation]
  Error RDL1: The class Date_planned_for_discontinuation does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  

NOTE    Dates are also assigned to approvals (see below), so when an approval is assigned to an item, there will be a date set for the approval. There is no need to assign a specific date as well.

NOTE    Further classes may be defined in business specific external reference data.

The assignment of date and time is described in the capability C036: assigning_date_time. Since Time is more accurate than a calendar date, the assignment of time is recommended.

Characterization: Assigning effectivity (Optional)

Effectivity may be assigned to instances of Breakdown_element_usage and Breakdown_element_realization and their subtypes, and also to instances of Breakdown_of. Thus, those entities may be the subject of configuration management., and a breakdown and it's elements may be associated with a type of effectivity.

NOTE    It is not possible to assign effectivity to instances of Breakdown_context. The context of breakdown elements is constant.

NOTE    It is also not possible to assign effectivity to instances of In_zone. This is an important difference between In_zone and Breakdown_element_usage.

The assignment of effectivity is described in Capability C006: assigning_effectivity.

Characterization: Assigning Approval Status (Optional)

An approval may be assigned to all entities of Breakdowns, except to Breakdown_context and Breakdown_of.

Approvals are always accompanied by an approval status, as defined in external reference data, and by a date or time for the approval, as well as the approving person or organization. Approvals and are assigned as described in capability C019: assigning_approvals.

Characterization: Assigning Location (Optional)

An instance of entities Breakdown, Breakdown_version, Breakdown_element, Breakdown_element_version, and Breakdown_element_definition, and all of their subtypes, may have a location assigned. This is particulary useful when considering a product where the location of an individual part is significant. By defining e.g. a Physical_element as being the individual part in a specific location, it is possible to manage each individual usage of the part.

The assignment of a location is described in capability C049: assigning_location.

Characterization: Assigning a Person or Organization (Optional)

A person or organization can be assigned to any of the entities for breakdowns except Breakdown_of. The person or organization must be assigned in a given role, such as "Owner of" (urn:plcs:rdl:std:Owner of) or "Creator of" (urn:plcs:rdl:std:Creator of). Further classes may be defined in business specific external reference data.

The assignment of a person in an organization is described in C016: representing_person_organization.
The assignment of an organization is described in C094: assigning_organization

For example, in the case where a Breakdown_element has an assigned Person_in_organization that is the owner of the Breakdown_element, the Organization_or_person_in_organization_assignment is classified as "Owner of" (urn:plcs:rdl:std:Owner of).

Additional Usage Guidance

Given the typing hierarchies presented above it is possible to provide an overview of each of the major types of representation offered.

Each type is constrained to associate like definitions, versions and elements together in the hierarchy generated. Hence a functional_breakdown will have for each functional_breakdown_version, functional_elements and functional_element_versions. A physical_breakdown will have for each physical_breakdown_version, physical_elements and physical_element_versions etc.. Each will also have functional_element_definitions, functional_element_usage_relationships and physical_element_definitions, physical_element_usage_relationships defined for them respectively. The same is true for the other basic types (system_element and zone_elements). The contraints in the model mean that the different definitions, versions and elements cannot be mixed - apart from one exception.

The exception to this are Hybrid_breakdowns which have hybrid_breakdown_versions, but do not have hybrid elements, element versions or element definitions. Instead these are combinations of two or more of the other four basic types, and hence are mixed - or "hybrid". These types of breakdowns are related to other breakdown types through an instance of hybrid_element_usage, a subtype of breakdown_element_usage.

Functional Breakdowns

A Functional_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of related functional elements so as to form explicit structural views that comprise the product's functional elements.

The schema entities that are specific to functional breakdowns are:

• Functional_breakdown - provides the information constant to all versions, e.g. name, identifier and type of the breakdown.
• Functional_breakdown_version - provides the information that may change between versions, such as constituents.
• Functional_breakdown_context - relates each constiuent functional_element to a specific version of the functional breakdown.
• Functional_element - provides information for a constituent in the functional breakdown
• Functional_element_version - provides information of the version of the constituent
• Functional_element_definition - provides the definition of the version of the constituent, such as properties.
• Functional_element_usage - provides a hierarchical structure for functional elements

See Figure 6 (and Figure 5) for an Express-G overview. A simplified instance diagram of a functional breakdown is shown below.

Figure 12 —  Sample instances of a Functional Breakdown

NOTE    No attributes, identifiers or classifications are shown in the figure, and there is no instance of Breakdown_element_realization present.

The functional breakdown "Bike functions" (a functional breakdown of the part "Bike") is shown in the figure with three constituents. The functional element "Provide directional control" is the parent of both "Steering control" and "Provide traction".

Physical Breakdowns

A Physical_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of related physical elements so as to form explicit, parent-child views that comprise the product's physical elements.

The schema entities that are specific to physical breakdowns are:

• Physical_breakdown - provides the information constant to all versions, e.g. name, identifier and type of the breakdown.
• Physical_breakdown_version - provides the information that may change between versions, such as constituents.
• Physical_breakdown_context - relates each constiuent physical_element to a specific version of the physical breakdown.
• Physical_element - provides information for a constituent in the physical breakdown
• Physical_element_version - provides information of the version of the constituent
• Physical_element_definition - provides the definition of the version of the constituent, such as properties.
• Physical_element_usage - provides a hierarchical structure for physical elements

See Figure 6 (and Figure 5) for an Express-G overview. A simplified instance diagram of a physical breakdown is shown below.

Figure 13 —  Sample instances of a Physical Breakdown

NOTE    No attributes, identifiers or classifications are shown in the figure, and there is no instance of Breakdown_element_realization present.

The physical breakdown "Bike support structure" (a physical breakdown of the part "Bike") is shown in the figure with three constituents. The physical element "Handlebars" is the parent of both "Handle bar grips" and "Front light structure".

System Breakdowns

A System_breakdown is a type of Breakdown that identifies a partitioning of a system into a set of related elements so as to form explicit, assembly - component views that comprise the system elements.

The schema entities that are specific to system breakdowns are:

• System_breakdown - provides the information constant to all versions, e.g. name, identifier and type of the breakdown.
• System_breakdown_version - provides the information that may change between versions, such as constituents.
• System_breakdown_context - relates each constiuent system_element to a specific version of the system breakdown.
• System_element - provides information for a constituent in the system breakdown
• System_element_version - provides information of the version of the constituent
• System_element_definition - provides the definition of the version of the constituent, such as properties.
• System_element_usage - provides a hierarchical structure for system elements

See Figure 6 (and Figure 5) for an Express-G overview. A simplified instance diagram of a system breakdown is shown below.

Figure 14 —  Sample instances of a System Breakdown

NOTE    No attributes, identifiers or classifications are shown in the figure, and there is no instance of Breakdown_element_realization present.

The system breakdown "Bike systems" (a system breakdown of the part "Bike") is shown in the figure with three constituents. The system element "Braking system" is the parent of both "Front braking system" and "Rear braking system".

Zonal Breakdowns

A Zone_breakdown is a type of Breakdown that identifies a partitioning of a product into a set of related zonal elements so as to form explicit, parent-child views that comprise the product's zone elements.

The schema entities that are specific to zonal breakdowns are:

• Zone_breakdown - provides the information constant to all versions, e.g. name, identifier and type of the breakdown.
• Zone_breakdown_version - provides the information that may change between versions, such as constituents.
• Zone_breakdown_context - relates each constiuent zonal_element to a specific version of the zonal breakdown.
• Zone_element - provides information for a constituent in the zonal breakdown
• Zone_element_version - provides information of the version of the constituent
• Zone_element_definition - provides the definition of the version of the constituent, such as properties.
• Zone_element_usage - provides a hierarchical structure for zone elements
• In_zone - provides a relationship to any product which is considered in the zone.

The last entity in the list above, the In_zone, provides a relationship between a Zone_element_definition and a in_zone_item that exists within the zone. An in_zone_item can be any type of Product_view_definition, such as; a Breakdown_element_definition, an Interface_connector_definition, an Interface_specification_definition, a Part_view_definition, a Requirement_view_definition, or an Attachment_slot_definition.

It is possible to define a zone (Zone_element_definition) that locates many items (Product_view_definition). For example, a ship's machinery compartment may contain many items. Such items may, or may not, be represented within other types of breakdowns or assemblies defined elsewhere. However, a separate instance of In_zone is required for each item (Product_view_definition) to be located within the same zone (Zone_element_definition).

An additional feature of the model is that it is also possible to define compartments within other compartments. This is normally achieved through Zone_element_usage used to create child - parent relationships between the various Zone_element_definitions. But in more complex structures, such as zone intersections, permeability, tightness (air/water/radiation) for example, it might be a good thing to combine this method with the usage of an In_zone to define exact relationships between Zone_element_definitions.

NOTE    An instance of In_zone may also be referenced by an approval_item select type. This enables approval functions to be carried out on the items located within a specific zone. This is typical of inspections carried out in the marine industry.

See Figure 6 (and Figure 5) for an Express-G overview. A simplified instance diagram of a zonal breakdown is shown below.

Figure 15 —  Sample instances of a Zone Breakdown

NOTE    No identifiers or classifications are shown in the figure, and there is no instance of Breakdown_element_realization present. Attributes are shown only for the In_zone entity instance.

The zonal breakdown "Ship deck and room breakdown" (a zone breakdown of the part "Ship") is shown in the figure with three constituents. The zone element "Deck 2" is the parent of both "Machine shop" and "Crews washroom". In the crews washroom (defined using the In_zone realtionship) there is a a "Washbasin" (a part) and a "Heating central" (a physical element). The contexts for the latter two is not shown in the figure.

Hybrid Breakdowns

A Hybrid_breakdown is a type of Breakdown that identifies a non-specific partitioning of a product into a set of related elements so as to form explicit, parent-child views that comprise the elements.

There is no added functionality of a Hybrid_breakdown, compared to the generic Breakdown, and therefore the use of Hybrid_breakdown, Hybrid_breakdown_version, Hybrid_breakdown_context, and Hybrid_element_usage is deprecated.
Use Breakdown, Breakdown_version, Breakdown_context, and Breakdown_element_usage instead.

Using Breakdowns for Baselining

Breakdowns are not primarily used for baselining (i.e. to freeze a structure at a point in time, e.g. between design and production), but breakdown structures may be baselined (as may assembly structures).

Through effectivity assigned to all relations, even between Breakdown_element_definitions and products (Product_view_definition) that realize the Breakdown_element, in combination with a strict approval policy for the Breakdown_versions, where the approval status reflects the intention of the baselining, it is possible to achieve frozen baselines of the breakdown and all of its constituents.

NOTE    Zonal breakdowns that make use of the In_zone entity cannot be baselined properly, since effectivity can not be applied.

NOTE    AP 239 cannot achive the full functionality of baselining, it can only record the imformation required for a software system to apply baselining functionality.

Capability templates

The following sections define a set of templates for the capability, where a template is a specification of a set of entities that need to be instantiated to represent a given set of information.

This section specifies the template representing_breakdown.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_breakdown

Figure 2 —  The graphical representation of the representing_breakdown template

Figure 3 —  Entities instantiated by representing_breakdown template

Figure 4 —  Instantiation of representing_breakdown template

This section specifies the template representing_breakdown_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_breakdown_element

Figure 2 —  The graphical representation of the representing_breakdown_element template

Figure 3 —  Entities instantiated by representing_breakdown_element template

Figure 4 —  Instantiation of representing_breakdown_element template

Figure 5 —  The graphical representation of the representing_breakdown_element characterizations

This section specifies the template representing_breakdown_structure.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_breakdown_structure

Figure 2 —  The graphical representation of the representing_breakdown_structure template

Figure 3 —  Entities instantiated by representing_breakdown_structure template

Figure 4 —  Instantiation of representing_breakdown_structure template

Figure 5 —  The graphical representation of the representing_breakdown_structure characterizations

This section specifies the template representing_breakdown_element_realization.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_breakdown_element_realization

Figure 2 —  The graphical representation of the representing_breakdown_element_realization template

Figure 3 —  Entities instantiated by representing_breakdown_element_realization template

          #1 = BREAKDOWN_ELEMENT_DEFINITION('/IGNORE','/IGNORE','/IGNORE',$,(),$);
          #2 = PART_VIEW_DEFINITION('/IGNORE','/IGNORE','/IGNORE',$,(),$);
          #3 = VIEW_DEFINITION_USAGE('/IGNORE','/IGNORE','/IGNORE',#1,#2);
          #5 = CLASSIFICATION_ASSIGNMENT(#6,(#3),'/IGNORE');
          #6 = EXTERNAL_CLASS('/NULL','Breakdown_element_realization','/IGNORE',#7);
          #7 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std','/IGNORE');
        

Figure 4 —  Instantiation of representing_breakdown_element_realization template

This section specifies the template referencing_breakdown_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

Figure 1 —  An EXPRESS-G representation of the Information model for referencing_breakdown_element

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

Figure 2 —  The graphical representation of the referencing_breakdown_element template

Figure 3 —  Entities instantiated by referencing_breakdown_element template

          #1 = TASK_METHOD($,$,$,$,());
          #2 = EXTERNAL_CLASS('/IGNORE','Safety_critical',$,#3);
          #3 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std',$);
          #4 = CLASSIFICATION_ASSIGNMENT(#2,(#1),'/IGNORE');
        

Figure 4 —  Instantiation of referencing_breakdown_element template

This section specifies the template representing_physical_breakdown.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_physical_breakdown

Figure 2 —  The graphical representation of the representing_physical_breakdown template

Figure 3 —  Entities instantiated by representing_physical_breakdown template

Figure 4 —  Entities instantiated by representing_physical_breakdown template

This section specifies the template representing_physical_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_physical_element

Figure 2 —  The graphical representation of the representing_physical_element template

Figure 3 —  Entities instantiated by representing_physical_element template

Figure 4 —  Instantiation of representing_physical_element template

Figure 5 —  Characterizations for representing_physical_element template

This section specifies the template representing_physical_structure.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_physical_structure

Figure 2 —  The graphical representation of the representing_physical_structure template

Figure 3 —  Entities instantiated by representing_physical_structure template

Figure 4 —  Instantiation of representing_physical_structure template

Figure 5 —  Characterizations for representing_physical_structure template

This section specifies the template representing_functional_breakdown.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_functional_breakdown

Figure 2 —  The graphical representation of the representing_functional_breakdown template

Figure 3 —  Entities instantiated by representing_functional_breakdown template

Figure 4 —  Instantiation of representing_functional_breakdown template

This section specifies the template representing_functional_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_functional_element

Figure 2 —  The graphical representation of the representing_functional_element template

Figure 3 —  Entities instantiated by representing_functional_element template

Figure 4 —  Instantiation of representing_functional_element template

This section specifies the template representing_functional_structure.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_functional_structure

Figure 2 —  The graphical representation of the representing_functional_structure template

Figure 3 —  Entities instantiated by representing_functional_structure template

Figure 4 —  Instantiation of representing_functional_structure template

This section specifies the template representing_system_breakdown.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_system_breakdown

Figure 2 —  The graphical representation of the representing_system_breakdown template

Figure 3 —  Entities instantiated by representing_system_breakdown template

Figure 4 —  Instantiation of representing_system_breakdown template

This section specifies the template representing_system_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_system_element

Figure 2 —  The graphical representation of the representing_system_element template

Figure 3 —  Entities instantiated by representing_system_element template

Figure 4 —  Instantiation of representing_system_element template

This section specifies the template representing_system_structure.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_system_structure

Figure 2 —  The graphical representation of the representing_system_structure template

Figure 3 —  Entities instantiated by representing_system_structure template

Figure 4 —  Instantiation of representing_system_structure template

This section specifies the template representing_zone_breakdown.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_zone_breakdown

Figure 2 —  The graphical representation of the representing_zone_breakdown template

Figure 3 —  Entities instantiated by representing_zone_breakdown template

Figure 4 —  Instantiation of representing_zone_breakdown template

Figure 5 —  Characterizations for representing_zone_breakdown template

This section specifies the template representing_zone_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_zone_element

Figure 2 —  The graphical representation of the representing_zone_element template

Figure 3 —  Entities instantiated by representing_zone_element template

Figure 4 —  Instantiation of representing_zone_element template

Figure 5 —  Characterizations for representing_zone_breakdown template

This section specifies the template representing_zone_structure.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for representing_zone_structure

Figure 2 —  The graphical representation of the representing_zone_structure template

Figure 3 —  Entities instantiated by representing_zone_structure template

Figure 4 —  Instantiation of representing_zone_structure template

Figure 5 —  Characterizations for representing_zone_breakdown template

This section specifies the template assigning_zone.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for assigning_zone

Figure 2 —  The graphical representation of the assigning_zone template

Figure 3 —  Entities instantiated by assigning_zone template

          #2 = PART_VIEW_DEFINITION('/IGNORE','/IGNORE','/IGNORE',#3,(),#4);
          #1 = IN_ZONE('/IGNORE','/IGNORE','/IGNORE',#2,#48);
          #48 = ZONE_ELEMENT_DEFINITION('/IGNORE','/IGNORE','/IGNORE',#49,(),#26);
        

Figure 4 —  Instantiation of assigning_zone template

This section specifies the template referencing_zone_element.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

Figure 1 —  An EXPRESS-G representation of the Information model for referencing_zone_element

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

Figure 2 —  The graphical representation of the referencing_zone_element template

Identification_assignment

-- Mark the Identification_assignment entity as
-- referable when this template is used by binding it to the reference
-- parameter id_assgn
%^id_assgn = Identification_assignment%

Error P8: the template referencing_zone_element does not have a parameter name [id].
Identification_assignment.identifier = @id
Identification_assignment.role = '/IGNORE'
Identification_assignment.description = '/NULL'

Error P4: the template referencing_zone_element does not have a parameter name [items].
Identification_assignment.items -> @items

-- provide the role of the identification by classifying the Identification_assignment
/assigning_reference_data(
    items=^id_assgn,
    class_name=@id_class_name,
    ecl_id=@id_ecl_id)/

Error t3: the template referencing_zone_element does not have a parameter name [id_class_name]. Parameters are: class_name items class_name ecl_id

Error t3: the template referencing_zone_element does not have a parameter name [id_ecl_id]. Parameters are: class_name items class_name ecl_id

-- assign an organization to the identifier and classify it as 'Owner_of'
/assigning_organization(
    items=^id_assgn,
    org_id=@org_id,
    org_id_class_name=@org_id_class_name,
    org_id_ecl_id=@org_id_ecl_id,
    org_assgn_class_name='Owner_of',
    org_assgn_ecl_id='http://www.plcsinc.org/plcs-proposed')/

Error t3: the template referencing_zone_element does not have a parameter name [org_id]. Parameters are: class_name items class_name ecl_id

Error t3: the template referencing_zone_element does not have a parameter name [org_id_class_name]. Parameters are: class_name items class_name ecl_id

Error t3: the template referencing_zone_element does not have a parameter name [org_id_ecl_id]. Parameters are: class_name items class_name ecl_id

Figure 3 —  Entities instantiated by referencing_zone_element template

          #1 = TASK_METHOD($,$,$,$,());
          #2 = EXTERNAL_CLASS('/IGNORE','Safety_critical',$,#3);
          #3 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std',$);
          #4 = CLASSIFICATION_ASSIGNMENT(#2,(#1),'/IGNORE');
        

Figure 4 —  Instantiation of referencing_zone_element template

Related capabilities

This capability "Representing a Breakdown Structure" is related to the following capabilities:

• C002: representing_parts
• C003: representing_assembly_structure
• C045: representing_product_as_individual

Dependent capabilities

This capability "Representing a Breakdown Structure" is dependent on the following capabilities:

• C001: assigning_identifiers
• C010: assigning_reference_data

Model reference data

The following classes of reference data are required for this capability:

© OASIS 2010 — All rights reserved