| DEX (D001):— product_breakdown_for_support |
The AP239 Application Activity Model (AAM) is an IDEF0 representation of the business activities that assist understanding of the scope and information requirements defined in AP239. The model is presented as a set of figures and a set of definitions of the activities and their associated information flows.
This DEX will support a subset of the activities and information flows. These are highlighted in yellow in the subsequent figures.
Activities and information flows that are out of scope of AP239 are marked with an asterisk.
The following terms are used in the application activity model.
action to provide unambiguous identification of all elements, and versions, of the product or support system to which reference needs to be made, identification of interfaces between elements, the necessary assembly, and other breakdowns structures, required to manage the product through life and definition of the information to be held for each type of product and support system element
This activity occurs throughout the product life cycle and is the basis of management of configuration change and configuration status accounting of a product and all constituent configuration items. The purposes and benefits of this activity include:
request to provide identification for new elements of the product or support system element
NOTE Requests may arise from new product concepts, developing breakdowns of existing products, or from changes.
specification of the information that shall be developed and maintained within the APSI for any PIF or support system element or class of elements
integrated set of classified elements and interfaces, product structure views and relationships between product structure views required to provide life cycle support
The PIF structure comprises:
identification of the group of actual or potential operational products and related items that require support during their life cycle
The PIF scope can include:
any information about the product in focus and related support elements that is required by participants in life cycle support
This information may include:
action to manage the information related to a PIF
NOTE This activity corresponds to configuration and data management and the major output is APSI, which encompasses the entire configuration and support data. A subset of the APSI is the configuration status record. The dynamic nature of the configuration and data management activity, and its importance within the operation of a consistent configuration management process throughout the product life cycle requires a formal approval process to attain APSI status. All configuration documentation (requirements and design documentation) and associated operational information (operating procedures, parts catalogues, and so on) that comprise the configuration status record must be formally managed and approved. In essence, approve, release and record is a process that makes configuration and support documentation available for use, subjects it to configuration change management and maintains the assured status of the APSI.
set of assured and related information used to develop and deliver support for a product in focus, including feedback from using and supporting the product over its life cycle
NOTE Related information includes records of the history of the usage or support of realized products, design and support analysis results and reasons why decisions were taken. Such information includes design and failure analysis records, logistic support analyses, running hours, environment descriptions, operating profiles; test results, records of maintenance activities, resources used, and faults found plus any other content deemed relevant to life cycle support.
The following additional terms are used in the application activity model.
action to provide both unambiguous identification and classification of all elements forming part of the PIF and its support system to which reference needs to be made, including interfaces and other relationships between such elements to which configuration management shall apply
NOTE Classification of elements and interfaces can be used to assist in defining information needs.
element of the PIF or its support system and that has been identified and assigned to one or more classes of element, plus any relationships between elements needing to be tracked for support purposes
NOTE Unambiguous identification includes the assignment of a name (for use by humans) and an alphanumeric identifier (for use within computers) that are unique within a context. The context for a name or identifier is the organization that provides the name and identification. Elements can have more than one name and identifier assigned by different organizations. The classification of an element can include a class that helps identify the APSI that is required for this element type. Relationships can include any of those specified by the information model of this part of ISO 10303.
action to develop the required views of each relevant product, in the form of assembly structures or breakdowns built from classified elements and to establish necessary relationships between the different views to provide navigation between views
NOTE The managed set of product views (the PIF structure) provides unambiguous identification of the PIF for support management purposes and a key mechanism for navigating and managing the effectivity of all related information, including that specified by the information need providing the product definition and support solution.
The following additional terms are used in the application activity model.
action to establish the necessary breakdown views of the PIF by defining parent-child relationships between related elements
NOTE This part of ISO 10303 provides a generic mechanism for representing product assemblies or product breakdowns from any required perspective. A product assembly structure is usually developed by the engineering design process. This is used to define the parts and versions that make up the product and to develop a bill of material for product manufacture. Life cycle support activities will usually require the establishment of other product breakdown views. These views can include a decomposition of product functions from the operator or maintainer perspective and, in some cases, a zonal description of the product to assist maintenance planning. Each breakdown will contain similar classified elements, linked together in a hierarchical fashion.
action to establish necessary links between different product breakdown views, reflecting relationships of interest
Potential relationships include:
set of product assembly or breakdown views that the life cycle owner requires to establish and maintain the PIF
set of product structure views and breakdowns that the life cycle owner has chosen to establish and maintain for the life of the PIF
integrated set of classified elements and interfaces, product structure views and relationships between product structure views required to provide life cycle support
The PIF structure comprises:
any information about the product in focus and related support elements that is required by participants in life cycle support
This information may include:
The activity model decomposes Develop structure views into a lower level of detail as shown below.
The following terms are used in the application activity model.
action to develop a system breakdown that is for the PIF scope and can act as a collector for product and support requirements
Requirements may be allocated to any assembly or breakdown type. Elements in a system breakdown can be:
action to develop physical breakdowns. Physical breakdowns may be of designs or realized individual physical products. For any product, more than one physical breakdown may exist to support various different engineering activities.
NOTE An aircraft wing might be described as comprising an upper surface and a lower surface. This description may be orthogonal to a parts description.
action to develop a functional breakdown that is for the PIF scope and can act as a collector for product and support requirements and for other information relating to functional aspects of the PIF
NOTE Every element within a functional breakdown is a function. Design engineers can derive a functional breakdown from the systems breakdown and use it for managing related functional requirements and as an input to fault, hazard or failure analyses. Support engineers can use the same functional breakdown, or a modification of it, to identify functions that require support and to structure information on potential faults and symptoms.
action to develop zonal breakdowns, these may be of designs or realized individual products. For any product, more than one zonal breakdown may exist to support various different engineering activities.
NOTE A zonal breakdown could cover the following -
EXAMPLE The zonal breakdown element 'engine room' might be realized by set of steel partitions.
action to develop hybrid breakdowns, these may be of designs or realized individual products. For any product, more than one hybrid breakdown may exist to support various different engineering activities.
NOTE A 'heating function' might include 'pipe elements' and pump 'elements' in a hybrid decomposition.
hierarchical decomposition that identifies a partitioning of a product into a set of related elements so as to form explicit, assembly - component views that comprise the system elements.
NOTE 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 example, further decompose into low-level systems such as autopilot system and instrument landing system.
hierarchical decomposition of the functions of a product
NOTE The functional breakdown elements can require support.
hierarchical decomposition of the physical elements within a product that are significant from a support viewpoint
NOTE The physical breakdown can be derived from, and related to, the product assembly structure.
hierarchical decomposition that identifies a partitioning of a product into a set of related zonal elements so as to form explicit, parent-child zonal views that comprise the product elements. The product elements maybe any type of product_view_definition which may be identified by the zone within which they reside.
NOTE A zonal breakdown provides a means of identifying the 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'. Each zone can be used to identify the items located within.
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. The hybrid breakdown consists of a mixture of system, physical, functional or zonal elements. There are no separate hybrid elements.
NOTE a product breakdown in which a 'climate control' function has a decomposition that comprises a 'heating function' and a 'cooling function' and in which the 'heating function' has a decomposition that comprises a 'heating element' and a 'heat distribution system' would be an example of a 'hybrid breakdown'.
This DEX enables the exchange of information about a product design (structure) for the purpose of supporting that product throughout life. It's primary purpose is to develop the elements used to describe the Product In Focus (PIF). This managed set of product views (the PIF Structure) provides unambiguous identification of the PIF for support management purposes and a key mechanism for navigating and managing the effectivity of all related information.
The PIF is used to create the support solutions which includes; defining the life and usage profile of the product and it's parts (see Dex D002: fault_states), the analysis of tasks required to be performed (see Dex D003: task_set), and the generation of a logical plan for support (see Dex D005: maintenance_plan).
The support solution is put in place (commissioned) for when the product first enters service. From this point on, information is collected and feedback is provided to the support facility (see Dex D007: operational_feedback).
If maintenance is required, then a package of work is defined (see Dex D004: work_package_definition).
Once the work is authorized and carried out, a report is produced to indicate when the work was completed together with any documentation required for the item repaired (see Dex D009: work_package_report).
This DEX provides a generic mechanism for representing product assemblies or product breakdowns from any required perspective. A product assembly is usually developed by the engineering design process. This is used to define the parts and versions that make up the product and to develop a bill of material for product manufacture. Life cycle support activities will usually require the establishment of other product breakdowns views. These views can include a decomposition of product functions from the operator or maintainer perspective and, in some cases, a zonal description of the product to assist maintenance planning. Each breakdown will contain similar classified elements, linked together in a hierarchical fashion.
The following sections outline the main products that are handled by this Dex;
An assembly definition can consist of a range of different types of definitions, for subtly different purposes. The following types of assembly definitions are possible when using this Dex;
Assembly definitions may also be used to exchange sub-assembly information from sub-contractor to contractor.
Breakdown defintions also vary in use and type. The following types of definitions are possible when using this Dex;
Breakdowns are aligned with the assembly such that an item within a breakdown may be located within an assembly.
Document definitions also vary in use and type. The following types of definitions are possible when using this Dex;
Documents supporting the assembly or breakdown views can be assigned to parts in the structure or to the entire product.