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

·  personnel_with_skill: a reference to the needed skill subject and grade

·  material: it is a reference to part, subassemblies that play a role in the method_stage. This includes tools and support equipment;

·  time: optional definition of the expected time required to perform a method_stage. Time qualifiers may be mean time, maximum time, etc.

·  money: optional definition of the expected cost to perform a method_stage;

·  build in facilities in the existing product;

·  consumables (e.g. oil, water .. )

Having defined the entities task and base_stage, there is still the need to define how the base_stage(s) are assembled together to form a task.

Basically, a task may be seen as a linear flow or sequence of base_stage(s). In such simple instance, Task ‘A’ is made up of Step ‘1’ (the base_stage) followed by Step ‘2’ and so on.

More frequently, however, the flow of actions is not a plain linear sequence of base_stage(s). For example, the flow of actions (what to do next) may depend on the results of a test condition.

A flow control structure that is external both to task and to base_stage may be used to alter the flow of actions of a task. Use of a control structure would enable Interactive Electronic Technical Manual (ITEM) style functionality to be provided directly from the Product Life Cycle Support database. The constructs that should be supported by the control structure are the followings:

44.  base_stage_sequence: it is the list of base_stage(s) to be carried out in order;

45.  control_transfer: rather than referencing a base_stage, the control structure is allowed to call another base_stage_sequence or even another task. This means that tasks and sequences can be nested within each other;

46.  conditional_transfer: enables a choice between different routes depending on the result of a test condition. The choice could be between two alternatives (IF … ELSE … ENDIF) or between many (DO CASE .. CASE … ENDCASE);

47.  looping_method: enables one or more base_stage(s), base_stage_sequence(s) or task(s) to be repeated. There are three ways of controlling the numbers of repeats and these can be combined:

·  repeat_count: repeat a specified number of times (FOR … NEXT);

·  repeat_until: repeat until a test condition is met (DO UNTIL … ENDDO;

·  repeat_while: repeat while a test condition remains true (DO WHILE … ENDDO).

48.  concurrent_methods: gives a group of base_stage(s), base_stage_sequence(s) or task(s) to be carried out during the time it takes to do the longest.

Together these provide a capability not unlike a programming language so that tasks can be structured flexibly, and tracked and presented with IETM style functionality.

5.6  Product Instance

A product_instance is the physical realization, through the manufacturing process, of a product_physical_design. In this paragraph the term product_instance refers to a specific physical object (e.g. Helicopter with tail number 97-01).

Some detailed requirements for product_instance are the following:

49.  a product_instance is the physical realization of zero or one product_design. The relationship between product_instance and design is optional since it will not always be possible or necessary to establish this relationship;

50.  a product_instance is owned[26] by exactly one[27] organization at a given point in time. Ownership may change over time during the life-cycle. The capability to associate a date and time with an ownership change and to maintain history of ownership shall be provided;

51.  a product_instance is manufactured by one or more organizations;

52.  a product_instance is supplied (sold?) by one or more organizations

53.  the combination product_instance identification and the assigning organization identification will uniquely define the product_instance;