MODULE 4 SYSTEM ENGINEERING PROCESS

4.1 Introduction The systems engineering process is inherent within the overall system life cycle, with particular emphasis in the design and development phase. Objective of the module is to describe the systems engineering process and those activities within the process that relate to and has an impact on logistics and design for supportability. The system engineering process includes definition of problem and identification of a customer need, conductance of feasibility analysis, development of system operational requirements and maintenance concept, identification and prioritization of technical performance measures, functional analysis, requirements allocation etc. Although the process is directed more at the early stages of system design and development, maintaining cognizance of the activities throughout the production, operational use, and system maintenance and support phases is essential for an understanding of the consequences of earlier decisions and establishment of benchmarks for the future. In other words, feedback loop is critical and an integral part of the systems engineering process. 4.2 Definition of Problem and Needs analysis

The system engineering process generally commences with the identification of a want or desire for something and is based on perceived deficiency. To ensure a good start, a statement of the problem should be presented in specific quantitative and qualitative terms, in enough detail to justify progressing to the next step. It is important that the problem reflects a true customer requirement, particularly in todays environment where resources are limited. Given the problem definition, a needs analysis must be performed with the objective to translate a broadly defined want into a more specific system requirement. The questions are: What is required of the system in functional terms? What functions must the system perform? What are the primary and secondary functions? What must be done to alleviate the stated deficiency? When must this be accomplished? Etc Accomplishing the needs analysis can be best realized through the concurrent engineering approach. The objective is to ensure that proper communication exists between all the parties involved. The voice of the customer must be heard and the system developer must respond accordingly. 4.3 System Feasibility Analysis The system feasibility analysis is performed with the objective of evaluating the different technological approaches that may be considered in responding to the specific functional
1

requirements. In the consideration of different ddesign approaches, alternative technological applications must be investigated. E.g. in the design of a communication system, should one use fiber optics technology, cellular, or the conventional hard-wired approach? It is necessary to: Identify various design approaches that can be pursued to meet requirements Evaluate the most likely candidates in terms of performance, effectiveness, logistics requirements, life cycle economic criteria and Recommend a preferred approach

The objective is to select an overall technical approach, and not to select specific components. Results of the feasibility analysis will have a significant impact not only on the operational characteristics of the system but on the production & maintenance support requirements as well. The selection or application of a given technology has reliability and maintainability implications, may affect the requirements for spare parts and test equipment, may impact manufacturing methods, and will obviously affect life-cycle costs. 4.4 System Operational Requirements

Once the need and technical approach has been identified, it is necessary to translate that need into anticipated operational requirements. Answers to the following questions leads to the definition of system operating requirements, the maintenance and support concept for the system, and the identification of specific design guidelines. i.e. What are the anticipated quantities of equipment, software and personnel required, and where are they to be located? How is the system to be utilized, and for long? How is the system to be supported and by whom? What is the anticipated environment at each operational (user) site? Information included in the operational concept are: 1. Mission definition- What the system is to accomplish and how it will accomplish its objectives. 2. Performance and physical parameters Definition of the operating characteristics or functions of the system (e.g. size, capacity, range accuracy etc.). These parameters must be able to accomplish mission scenarios. 3. Operational deployment or distribution - Identification of the quantity of equipment, software, personnel, facilities etc, and the geographical location, transport and logistics requirements.
2

4. Operational life cycle Anticipated time that the system will be in operational use. Who will be operating the system and for what period of time? 5. Utilisation requirements Anticipated usage of the system and its elements. e.g. hours of operation per day 6. Effectiveness factors System requirements specified as figures of merit such as

cost/system effectiveness, operational availability, dependability, MTBM, failure rate, MDT etc 7. Environment Definition of the environment the system is expected to operate. (e.g. temperature, humidity ). This should also cover all transportation, handling and storage modes. Example of System Operational Requirements An aircraft system is to be procured and distributed in multiple quantities throughout the world. The anticipated geographical locations, estimated quantities per location, and average system utilization times are shown below. Geographical operational area America Middle East Europe South Africa Total 1 2 3 10 12 12 12 46 4 20 12 24 24 80 Year Number 5 40 12 24 24 6 60 24 24 24 7 60 24 24 24 8 60 24 24 24 9 35 24 24 24 10 35 24 24 24 107 Total Systems 310 156 180 180 826

100 132 132 132 107

Average System Utilization: 4 hours per day, 365 days per year In terms of mission, each aircraft will be required to fly three different mission profiles. The aircraft shall meet system performance requirements in accordance with Specification 12345; operational availability shall be at least 90%; MDT shall not exceed 3 hours; shall be 30

mins or less; MLH/OH for the aircraft shall be10 or less and the cost per maintenance action at organizational level shall not exceed R80 000. The aircraft will incorporate a built-in test capability that will allow for fault isolation to the unit level with an 85% self test thoroughness. No special external support equipment will be allowed. Relative to the support infrastructure,

there will be an intermediate-level maintenance capability located at each operational base. Additionally, there will be two depot-level maintenance facilities. Thus from a logistics viewpoint, it is critical to define 1. Mission scenarios in order to identify operational sequences, stresses on the system, environmental requirements, system reliability and the frequency of anticipated maintenance. 2. Quantity of items and the geographical distribution in order to determine the magnitude of support and the location where logistics support will be required. 3. Operational life cycle in order to determine the duration of support and the basic requirements for replenishment. 4. Effectiveness factors in order to determine the frequency, level of support and the anticipated logistics support resources that will be required. 4.5 Maintenance and Support Concept

Normal tendency is of dealing primarily with elements of the system that relate directly to the performance of the mission i.e. prime equipment, operator personnel, software and associated data, while neglecting system maintenance and support. System support must be considered from the beginning and maintenance concept must be developed. Maintenance concept is a before-thefact series of statements on how the system is to be designed for supportability. It is developed during conceptual design and evolves from the definition of system operational requirements. Although there are some variations as a function of the nature and type of system, the maintenance concept generally includes the following information: 1. Levels of maintenance depending on the nature and mission of the system, there may be two, three or more levels of maintenance. Maintenance may be classified as organisational, intermediate maintenance, Depot/Supplier or manufacturers maintenance. Organizational maintenance is performed at the operational site and includes tasks performed by the using organization on its own equipment software and personnel. From maintenance standpoint, the least skilled personnel are assigned to this function. Intermediate maintenance tasks are performed by mobile, semi mobile and/or fixed specialized organizations. At this level, end items may be repaired by the removal and replacement of major modules, assemblies or parts. Maintenance personnel at this level are more skilled and better equipped than those at organizational level. Depot/Supplier or manufacturers maintenance constitutes the highest
4

type of maintenance and supports the accomplishment of tasks above and beyond the capabilities available at the intermediate level. The depot may be a specialized repair facility supporting a number of systems or equipments or may be the equipment manufacturers plant. Depot level maintenance include complete overhaul, calibration of equipment and performance of complex maintenance actions.
Criteria Organizational maintenance Intermediate maintenance Mobile or At the operational site Done where? or wherever the prime equipment is located. semi-mobile units Truck, van, portable shelter etc Done by whom? On whose equipment System/equipment operating personnel Using organizations equipment Fixed units Fixed field shop Depot, Supplier maintenance

Depot/supplies

Specialized repair activity or manufacturers plant Depot facility personnel, or manufacturers production personnel

Personnel assigned to mobile, semi-mobile or fixed units

Equipment owned by using organization Complicated factory adjustments, Complex equipment repairs and , overhaul and rebuild, Detailed calibration, Supply support, Overload from intermediate level of maintenance

Detailed inspection and Visual inspection, Operational checkout, Type of work accomplished Minor servicing, external adjustments, Replacement of some components system checkout, Major servicing, Major equipment repair, Complicated adjustments, Overload from organizational level of maintenance

2. Repair Policies Within the constraints placed by table in item 1, there may be a number of possible policies specifying the extent to which repair of a system component will be accomplished (if at all). A repair policy may dictate that an item should be designed to be non-repairable, partially repairable or fully repairable.

3. Organisational responsibilities The accomplishment of maintenance may be the responsibility of the customer, producer (or supplier), a third party or a combination thereof. 4. Maintenance support elements As part of the initial maintenance concept, criteria must be established relating to various elements of maintenance support. These elements include supply support (spares and repair parts, associated inventories), test and support equipment, personnel and training, transport and handling equipment, facilities, data and computer resources. 5. Effectiveness requirements - These constitute effectiveness factors associated with the support capability. In the supply support area, they may include a spare part demand rate. For test equipment, the length of queue while waiting for test, the test station process time and test equipment reliability are key factors. In transportation, transportation rates, times, reliability and costs are key. For personnel and training, one should be interested in personnel quantities and skill levels and training rates. 6. Environment Definition of the environment as it pertains to maintenance and support. This includes temperature, shock and vibration, noise, humidity etc as applicable to maintenance activities and related transportation, handling and storage functions. 4.6 Identification and Prioritization of Technical Performance Measures (TPMs)

Through the definition of operational requirements and maintenance concept of the system, specific performance related factors are identified and applied with the objective of ensuring that the system will be designed and developed such that it will satisfactorily accomplish its intended mission(s). TPMs refer to the critical performance measures or metrics for a system. A number of different metrics may be applicable in the identification of TPMs and priorities need to be established in order to determine the relative degree of importance in the event that design tradeoffs are necessary. e.g. in the design of a motor vehicle, is speed more important than size, or for a manufacturing plant, is product quantity more important than product quality. An excellent tool that can be used to establish and prioritize TPMs is a Quality Function Deployment (QFD) model. QFD constitutes a team approach to help ensure that the voice of the customer is reflected in the ultimate design. The purpose is to establish the necessary requirements and to translate those requirements into technical solutions. Customer requirements and preferences are defined and categorized as attributes, which are then weighted based on the degree of importance. QFD
6

process involves constructing one or more matrices, the first of which is called the House of Quality.

The basic structure is a table with "Whats" as the labels on the left and "Hows" across the top. The roof is a diagonal matrix of "Hows vs. Hows" and the body of the house is a matrix of "Whats vs. Hows". Both of these matrices are filled with indicators of whether the interaction of the specific item is a strong positive, a strong negative, or somewhere in between. Additional annexes on the right side and bottom hold the "Whys" (market research, etc.) and the "How Muches". Rankings based on the Whys and the correlations can be used to calculate priorities for the Hows. House of Quality analysis can also be cascaded, with "Hows" from one level becoming the "Whats" of a lower level; as this progresses the decisions get closer to the engineering/manufacturing details. 4.7 Functional Analysis

An essential element of early conceptual and preliminary design is the development of a functional description of the system to serve as a basis for the identification of the resources necessary for the system to accomplish its objectives. A function refers to a specific or discrete action (or a series of actions) that is necessary to achieve a given objective. e.g. a maintenance
7

action that is required to restore a system to operational use. Operational functions are described first and ten maintenance and support functions are identified. The objective is to specify the whats and not the hows, that is what has to be accomplished versus how it is done. FA is an iterative process of breaking requirements down from system level, to the subsystem, and as far down the hierarchical structure as necessary to identify input design criteria and/or constraints for the various elements of the system. In applying the principle of system engineering, one should not identify and purchase one piece of equipment or a module of software, or an element of logistic support without first having justified the need for such through functional analysis. In completing a functional analysis, one should take care to ensure that the required resources are properly identified for each function. 4.8 Requirements Definition and Allocation

Given the top-level definition of the system through FA, the next step is to break the system down into subsystems and lower level components by partitioning. The challenge is to identify and group closely related functions into packages, employing a common resource (e.g. equipment, software) to accomplish multiple functions to the extent possible. Common functions may be grouped through, for example: 1. System elements may be grouped by geographical location, a common environment, or similar types of equipment. 2. Individual system packages should be as independent as possible with a minimum of interaction effects with other packages.. A design objective is to be able to remove and replace a given package without having to remove and replace other packages in the process. 3. In breaking down a system into subsystems, select a configuration in which the communication between the subsystems is minimized. As a result of partitioning, a system may be broken down into subsystems as shown ahead:

System

Software

Facility

Equipment

Personnel

Data

Unit A

Unit B

Unit C

Assembly 1

Assembly 2

Assembly 3

The next step is to allocate the requirements specified for the system down to the level desired to provide a meaningful input to design. This step involves a top down distribution of TPMs so that specifications for unit level meet system-level requirements. e.g. After an acceptable reliability factor or has been established for the system. It must be allocated among various subsystems, units, and assemblies etc. The allocation commences with development of reliability block diagrams, with the intent to develop a reasonable approximation of those elements that must function for successful operation of the system. In addition to reliability, maintainability, logistic support requirements and economic factors must also be allocated. 4.9 System synthesis, analysis and design optimization

Synthesis refers to combining and structuring of components in such a way as to represent a feasible system configuration. Initially, synthesis is employed to develop preliminary concepts and to establish basic relationships among various components of the system. Later, when sufficient functional definition and decomposition have occurred, synthesis is used to further define the hows in response to the what requirements. The synthesis process usually leads to the definition of several possible alternative design approaches, which will be subject to further analysis, evaluation, refinement and optimization. Given a number of alternatives, the evaluation procedure progresses through the following steps:

1. Definition of analysis goals Includes clarification of objectives, identification of all possible alternative solutions to the problem at hand and a description of the analysis approach to be used. Generally those candidates that are clearly unattractive are eliminated, leaving only a few for evaluation. 2. Selection and weighting of evaluation parameters Criteria used in the evaluation process may vary depending on the stated problem, the system being evaluated and the depth and complexity of analysis. Parameters of significance include cost, effectiveness, performance, availability dependability etc. 3. Identification of data needs In the early stages of system development, available data are limited, thus the analyst must depend on the use of various estimating relationships, projections based on past experience covering similar system configurations and intuition. As system development proceeds, improved data are available through analyses and predictions. 4. Identification of evaluation techniques Given a specific problem, it is necessary to determine the analytic approach to be used and the techniques that can be applied to facilitate the problem solving process. Techniques may include Monte Carlo simulation in the prediction of random events downstream in the lifecycle, the use of linear programming in determining transportation resource requirements, use of queuing theory in determining production requirements etc. 5. Selection or development of a model - The next step requires combining various analytical techniques into the form of a model, or a series of models. A model, as a tool used in problem solving, aids in the development of a simplified representation of the real world as it applies to the problem being solved. The model should (a) represent the dynamics of the system configuration being evaluated; (b) highlight those factors that are most relevant to the problem at hand; (c) be comprehensive by including all relevant factors and be reliable in terms of repeatability of results; (d) be simple enough in structure so as to enable its timely implementation in problem solving; (e) be designed such that the analyst can evaluate the applicable system configuration as an entity, analyze different components of the system on an individual basis, and then integrate the results into the whole; 6. Generation of data and model application- With the identification of analytical techniques and the model selection task accomplished, the next step is to "verify" or -'test" the model to ensure that it is responsive to the analysis requirement. Does the model meet the stated
10

objectives? Is it sensitive to the major parameters of the system configuration(s) being evaluated? A model can be evaluated through the selection of a known system entity, and the subsequent comparison of analysis results with historical experience. Input parameters may be varied to ensure that the model design characteristics are sensitive to these variations and will ultimately reflect an accurate output as a result. 7. Evaluation of design alternatives - Each of the alternatives being considered is then evaluated using the techniques and the model selected. The required data are collected from various sources such as existing data banks, predictions based on current design data, and/or gross projections using analogous and parametric estimating relationships. The required data, which may be taken from a wide variety of sources, must be applied in a consistent manner. The results are then evaluated in terms of the initially specified requirements for the system. Feasible alternatives are considered further. 8. Performance of sensitivity analysis - In the performance of an analysis, there may be a few key system parameters about which the analyst is uncertain because of inadequate data input, poor prediction procedures, "pushing" the state of the art, and so on. There are several questions that need to be addressed: How sensitive are the results of the analysis to possible variations of these uncertain input parameters? To what extent can certain input parameters be varied before the choice of alternatives shifts away from the initially selected approach? From experience, there are certain key input parameters in a life-cycle cost analysis, such as, the reliability MTBF and the maintainability ct, that are considered to be critical in determining system maintenance and support costs. With good historical field data being very limited, much dependence is placed on current prediction on and estimating methods. Thus, with the objective of minimizing the risks associated with making an incorrect decision, the analyst may wish to vary the input MTBF and ct factors over a designated range of values (or a distribution) to see what impact this variation has on the output results. 9. Identification of risk and uncertainty - The process of design evaluation leads to decisions having a significant impact on the future. The selection of evaluation criteria, the weighting of factors, the selection of the life-cycle period, the use of certain data sources and prediction methods, and the assumptions made in interpreting analysis results will obviously influence these decisions. Inherent within this process are the aspects of risk and uncertainty because the future is, of course, unknown. Although these terms are often used jointly, risk actually
11

implies the availability of discrete data in the form of a probability distribution around a certain parameter. Uncertainty implies a situation that maybe probabilistic in nature but one that is not supported by discrete data. Certain factors may be measurable in terms of risk or may be stated under conditions of uncertainty. The aspects of risk and uncertainty, as they apply to the system design and development process, must be integrated into a program risk management plan. 10. Recommendation of preferred approach - The final step in the evaluation process is the recommendation of a preferred alternative. The results of the analysis should be fully documented and made available to all applicable project design personnel. A statement of assumptions, a description of the evaluation procedure that was followed, a description of the various alternatives that were considered, and an identification of potential areas of risk and uncertainty should be included in this analysis report. 4.10 System Test and Evaluation

As the system design and development activity progresses, ongoing measurement and evaluation (or validation) efforts are necessary. In the true sense, a complete evaluation of the system, in terms of meeting the initially specified consumer requirements, cannot be accomplished until the system is produced and functioning in an operational environment; however, if problems occur and system modifications are necessary, performing them so far downstream in the life cycle may turn out to be quite costly. In essence, the earlier that problems are detected and corrected, the better off one is in terms of both incorporating the required changes and decreasing the costs thereof. When addressing the subject of evaluation, one's objective is to acquire a high degree of confidence, as early in the life cycle as possible, that the system will ultimately perform as intended. The realization of this objective, through the accomplishment of laboratory and field testing involving a physical replica of the system (or its components), can be quite expensive. The resources required for testing arc often quite extensive) and the necessary facilities, test equipment, personnel, and so on, may be difficult to schedule. Yet, we know that a certain amount of formal testing is required to properly verify that system requirements have been met. Conversely, with a more comprehensive analysis effort and the use of prototyping, it may be possible to verify certain design concepts during the early stages of preliminary and detail design. With the advent of three-dimensional databases and the application of simulation techniques, the
12

designer can now accomplish a great deal relative to the evaluation of system layouts, component relationships and interferences, human-machine interfaces, and so on. There are many functions that can now be accomplished with computerized simulation that formerly required a physical mockup of the system, a preproduction prototype model, or both. The availability of computer aided design (CAD), computer-aided manufacturing (CAM), computer-aided support (CAS) methods, and related technologies has made it possible to accomplish much in the area of system evaluation, relatively early in the system life cycle when changes can be incorporated with minimum cost. In determining the needs for test and evaluation, one commences with the initial specification of system requirements in conceptual design. As specific TPMs are established, it is necessary to determine the methods by which compliance with these factors will be verified. How will these TPMs be measured, and what resources are necessary to accomplish this? Response to this question may be in the form of using simulation and related analytical methods, using an engineering model for test and evaluation purposes, testing a production model, evaluating an operational configuration in the consumers environment, or using a combination of these. In essence, one needs to review the requirements for the system, determine the methods that can be used in the evaluation and the anticipated effectiveness of these methods, and develop a comprehensive plan for an overall integrated test and evaluation.

13