PLCS Statement of Technical Requirements. Technical Requirements Product Life Cycle Support. Configuration Management, страница 19

A typical relationship in the chain is the one between a caused_function and a causing_function meaning that the first is affected by a status change of the second. In a wider sense, each function may be controlled by a behavioral interface or ‘control-port’ which affects its state.

Some of the data requirements for product functional design are the followings:

7.  a product_functional_design relates to one or many product_concept(s) and to zero, one or more product_requirement. This implies that a product_functional_design instance may exist without a product requirement, but will always be related to at least one product_concept;

8.  a product_functional_design is realized by zero, one, or more product_physical_design;

9.  a product_functional_design is uniquely identified by the combination of the designing organization identification and by the identifier assigned by that organization;

10.  a product_functional_design may be controlled by zero or one organization at a given point in time in one or more control methods;

11.  control methods should be defined. Authority for approval is an example of control methods.

12.  a product_functional_design may be categorized. A class of product_functional_design may in turn be organized in a class hierarchy;

13.  agreed classes of product_functional_design should be defined;

14.  a product_functional_design may relate to another product_functional_design;

15.  the rationale for the relationship between two product_functional_design(s) shall be defined (e.g. a functional breakdown);

16.  a mechanism to trace function execution sequence (causal_chain) should be provided[14];

17.  a function may be associated with zero, one or many control_port(s);

18.  a function can not be activated unless all control_port objects associated with the function are enabled.

19.  whether a control_port is enabled is decided by the value and type of its attributes;

20.  a product_functional_design has multiple representations in various formats such as plain text, structured text (SGML, HTML, XML), drawings, video, audio or external documents.

The diagram in the figure 7 covers most of the above requirements:

Figure 7 – product_functional_design high level model

5.5.2  Product Physical Design

Product physical design is an abstraction of product_instance or the design of a product_instance. It may be used to represent the design throughout the design phase, from the initial design through detailed design including variations in the design that may meet different requirements or different functionality.

The subject of product_physical_design is the identification, the classification and representation of designs and the relationships between them.

This relationship may define a product design in term of its product structure as a set of constituent product designs.

A product_physical_design has a number of relationships with other views of product (see figure 5).

Some detailed information requirements are the following:

21.  each product_physical_design is identified in the context of an organization. This implies that the same product_physical_design may have multiple identifications for different organizations.

22.  different types of product reports should be possible by using the product_physical_design. These reports should be able to describe the product structure to many levels of details[15]. Level of details may address, for instance, the degree of decomposition ( e.g. single level or multi level) and the type of decomposition (e.g. exploded, flattened, indented … etc);

23.  Bill of Material, Part List, Illustrated Part Catalogue Structures are example of product reports;

24.  a product_physical_design is characterized by zero, one or more properties;