SEM Fall 2010

Chapter 3

System Design Requirements

Sahar Idrees

3.1 Development of Design Requirements and Design-to Criteria• System design requirements evolve from the activities

in the conceptual design phase(definition of operational reqts, maintenance concept, TPMs etc).

• As these are defined for any system, its necessary to define & allocate the appropriate design-to criteria.

• Question: what specific qualitative & quantitative design-to criteria should be applied to the elements of system e.g. equipment, software, human elements, facilities, support infrastructure etc.

• These reqts and design-to criteria may be defined through a combination of statements which must be included in the applicable specification.

3.1 Development of Design Requirements and Design-to Criteria• Challenge from systems engg perspective:

to integrate and view these reqts in the context of the whole.

• Although each reqt may be addressed individually, there may be some conflicting issues that need to be resolved in the context of overall system.

• Identify reqts and how they apply to forward and reverse flow processes, which in turn may lead to the development of lower level and supporting reqts.

• This process is somewhat iterative and may be accomplished in several steps.

3.2 Development of Specifications

•Specifications cover the technical reqts of design

•Planning documentation includes all management reqts necessary to fulfill objectives.

•Scope and depth of this documentation depend upon nature, size and complexity of system.

•The extent to which the new design is feasible versus the selection of an off-the-shelf capability dictates the amount of documentation necessary.

•Amount of documentation depends upon the complexity of the system.

Classification of Specification

1. System Specification(Type A) includes:• the technical, performance, operational and

support characteristic for the system as an entity.

• Allocation of reqts to functional areas• Definition of functional interfaces• Covers the info from feasibilty analysis,

operational reqts, maintenance concept & functional analysis.

Classification of Specification2. Development Specification(Type B)• Includes technical reqts for any item below

system level where research & development are accomplished.

• This may cover an equipment item, assembly, comp program etc.

• Each specification may include performance, effectiveness and support characteristics that are required in evolving the design from system level and down.

3. Product Specification(Type C)• Includes technical reqts for any item below top

system level that is currently in the inventory and can be produced off the shelf.

• May cover standard system components, spare parts, tools, computer programs etc.

Classification of Specification

4. Process Specification(Type D)• Includes technical reqts that cover a service

performed on any component of the system(e.g. machining, bending,welding etc).

5. Material Specification(Type E)• Includes technical reqts that pertain to raw

material, mixtures (e.g. paints, chemicals compounds), and/or semi-fabricated materials(e.g. electrical cable, piping etc) that are used in the fabrication of a product.

Timing of Preparation of Specifications

• System Specifications: Prepared during conceptual design phase.

• Development and Product Specifications:Prepared during: preliminary design phase and are based on the results of “make or buy” decisions.

• Process and Material Specifications:Prepared during detail design and development phase and are oriented to production and/or construction acivities.

Precedence Problem of Specifications

• In large scale systems with many component suppliers, many specs will be generated & applied at different points in time.

• This results in conflicts, as well as the question that which spec takes precedence in the event of conflict.

• To solve this precedence problem, a documentation tree should be prepared showing the hierarchy of specs.

• A good comprehensive system specification must be developed first and then it is supplemented with the generation of good development, product, process &/or material soecs as reqd.

3.3. Integration of System Design Activities

• Large scale systems generally involve numerous engineering disciplines.

• These subsystems from different disciplines need to be addressed and treated individually as well as integrated into the system as a whole.

Case Study: Commercial Aircraft System• Aeronautical Engineers determine performance

reqts and design the overall airframe structure.• Electrical Engineers design the aircraft power

distribution system.• Electronic Engineers develop electronic

subsystems e.g. radar, navigation, communication equipment.

• Mechanical Engineers are involved in the areas of mechanical structures, linkages, hydraulics etc.

3.3. Integration of System Design Activities

• Metallurgists select materials for aircraft structure.• Reliability and maintainability engineers work with

Mct, MTBF, MLH/OH and system logistic support.• Human Factors engineers work with man-machine

functions, cock-pit & cabin layout & control panels.• Systems engineers are concerned with overall

development of airplane as a system and ensuring the proper integration of subsystems.

• Industrial engineers are directly involved in the production of aircraft itself and its components.

• Test engineers evaluate the system to ensure conformity with consumer reqts.

• Other disciplines are employed on a task-to-task basis.

3.4. Selected Design Engineering Disciplines

3.4.1 Software Engineering• Deals with the process of bringing software into being• Software is NOT a system in itself, but a major

element of a system• Software must be treated on an INTEGRATED basis

along with the other elements• Software constitutes a major portion(50-80%) in the

makeup of many systems so a lot of activity in this area (for e.g models like waterfall model, spiral model, vee model etc.)

• Main objective of the models is to develop a process that will facilitate the design and development of software.

• Despite the availability of the guidance related models many software developers view software processes as unduly rigid and they try to work independently which results in problems downstream.

Software Development Cycle1.Software Planning• A comprehensive description of all the software

reqts should be included in the software plan.• It should be prepared early in the life cycle & at the

time when software reqts are first identified.• Software plan must be fully integrated with SEMP

(System Engineering Management Plan).2. Requirements Analysis• A complete definition of system reqts (operational,

maintenance, TPMs, functional analysis allocation) plus functional block diagrams, performance factors, design criteria etc.

• There must be complete traceability of reqts hierarchically.

• Design reqts should address attributes e.g. availability, maintainability, portability, usability, testability etc.

Software Development Cycle

3. Software Design• Software hierarchical structure is developed in

prelim design to establish basic relationships among functional elements.

• Info/data flow diagrams are developed further.• In detailed design:▫ FFBDs are broken down into detailed flow charts▫ reqts for program design language and design

tools are identified.• Key Issue: Thoroughly document the design

and the complete the evolvement of design from one configuration to the next if changes are needed.

Software Development Cycle4. Software Coding• Involves writing of programs using structured

code, format, documentation, debugging etc.• While integrating different software packages

together code compatibility must be ensured.5. Software Test and Evaluation• Verification is done to ensure that each

component is working and fulfills its purpose.• It constitutes a step-by-step approach of testing

one program followed by the next and so on.• It is initially iterative during prelim and detailed

design.• Later, software may be verified as part of the

overall system test and evaluation process.

Software Development Cycle

6. Software Maintenance• Software maintenance may be broken down

into following categories: • Corrective: fixing problems resulting from a

failure.• Preventive: taking measures beforehand to

avoid problems.• Perfective/adaptive: upgrading the system and

incorporation of improvements in the design. Care must be taken so that this does not introduce more problems in the system.

Reliability Engineering• Reliability— the probability that a system or

product will perform in a satisfactory manner for a given period of time when used under specified operating conditions.

Key Factors in the Definition:1.Probability Factor – the number of times that one

can expect an event to occur in a total number of trials (e.g. a probability of 95% means that on an average a system will perform properly 95 out of 100 times)

2.Satisfactory performance – the system’s ability to perform its mission (A combination of qualitative and quantitative factors define the functions that the system is to accomplish (presented in context of System Specification))

Reliability Engineering3. Time – a measure against which the degree of

performance is rated. Examples of time related measures include:

▫ Mean time between failure (MTBF)▫ Mean time to failure (MTTF)▫ Mean cycles between failure (MCBF)▫ Failure rate (λ)

4. Specified Operating Conditions – refer to the environment in which the system will operate e.g. temperature cycling, humidity, sand and dust etc.Such operating conditions’ considerations are important not just when the system is operating but also during accomplishment of maintenance activities like transportation, handling, and storage modes

Reliability Engineering•Reliability can be defined in terms of some

specific mission scenario as:“The probability that a system will perform a

designated mission in a satisfactory manner”.•This definition may imply the accomplishment

of maintenance activities as long as these don’t interfere with the successful completion of mission.

•The basic reliability function R(t) may be defined as: R(t) = 1-F(t)

where F(t) represents the failure probability distribution, i.e. the probability that the syystem will fail by time t.

•Poisson distribution is generally used in prediction. It is expressed as:

P(x,t) = (λt)xe- λt

x!• It means that if the average failure rate λ is known,

then it possible to calculate the probability P(x,t) of observing 0,1,2,3,.. N number of failures when item is operating for designated amount of time t. Thus Poisson approximation may be broken down into:

1= e- λt + (λt) e- λt + (λt)2e- λt + (λt)3e- λt + …. + (λt)ne-

λt

2! 3! n!

• In addressing the reliability objective, the first term of Poisson is of significance.

•This term, representing the “exponential distribution” is the basis for specifying, predicting and later, measuring the reliability of a system.

R = e- λt = e-t/M

Where M is the MTBF. e.g. if an item has a constant failure rate, the

reliability of that item at its mean life is approx 0.37, there is a 37% chance that item ll survive its mean life without failure.

•Failure rate: constitutes the number of failures occurring during a specified interval of time.

λ = number of failures total operating hours•Kinds of Failures:

▫Primary/catastrophic failures: ▫Secondary Failures:

Types of relationship between system components:•Consult fig.3.10 of text book (pg 147)

Consider a series network:•Reliability (probability of success) is

product of probabilities of individual components:

Rs = (RA)(RB)(RC)•If system operation is to be related to a

specific time period: Rs = (e- λ

At )(e- λ

Bt )(e- λ

Ct )

Rs = e-( λA

+λB

+λC

)t

Consider a parallel network:•Reliability expression is for two

component parallel network:Rs = RA+RB - (RA RB)

•Reliability expression is for three component parallel network:

Rs = 1 – (1 - RA)(1 - RB )(1 - RC)•When all three components are identical:

Rs = 1 – (1 - R)3

•For a system with n components: Rs = 1 – (1 - R)n

Incorporating Redundancy•Incorporating redundancy in design helps

improve system reliability.•Redundancy can be applied in design at

different hierarchical indenture levels in the system.

•Parallel functional capabilities at subsystem level ensure that the system ll continue to operate even if one path fails to function properly.

•Redundancy can also be incorporated at the detailed piece – part level to improve the reliability pf critical functions(especially in areas where accomplishment of maintenance is not feasible).[p

Evaluating the feasibility of Redundancy•Application of redundancy to design is a key area

for evaluation.•Redundancy per say does not improve reliability &

on the other hand costs go up because incorporation of new components takes extra space.

•Questions:▫ Is redundancy really required in terms of criticality

relative to accomplishment of mission?▫At what level should redundancy be incorporated?▫What type of redundancy should be considered? (active

or standby)▫Should maintainability provisions be considered?▫Are there any alternative methods for improving

reliability?

Descriptions of a few reliability tasks1. Reliability program plan• Reliability program represents a separate effort but its

program should be integrated with SEMP.• Reliability activities need to be closely integrated with

maintainability and logistic support.

2. Reliability Modeling• This task depends upon the development of a good

reliability block diagram.• This block diagram should evolve from and support the

functional analysis and functional flow block diagrams.• It is used for analysis & prediction, results of which are

used in maintainability, human factors, logistics & safety analysis.

Descriptions of a few reliability tasks3. Failure mode, effect and criticality

analysis (FMECA)• It is a design tool for determining cause-&-effect

relationships , identifying weak links & is useful in diagnostic routines for maintainability.

• Also reqd for supportability analysis(SA) relative to identification of corrective & preventive maintenance reqts.

• Outputs from FMECA are useful in other reliability tasks like RCM, FTA etc, & hazard analysis from system safety program.

• FMECA is a critical activity that must be accomplished in a timely fashion and be integrated with other system activities.

Descriptions of a few reliability tasks4. Fault Tree Analysis(FTA)• Is a deductive approach involving the graphical enumeration & analysis of

different ways in which a system fault can occur plus its probability of occurrence.

• A separate fault tree may be developed for every critical failure mode or undesired top-level event.

• Attention is focused on top level event & its 1st tier causes, each of which is then examined for its causes and so on.

• FTA is narrower in focus than FMECA.

5. Reliability Centered Maintenance (RCM)• evaluates a system in terms of life cycle:

to determine the best overall preventive maintenance program. Which is cost effective Is based on reliability info derived from FMECA

6. Failure Reporting, Analysis and Corrective-action system

Descriptions of a few reliability tasks6. Failure Reporting, analysis &

corrective-action system• Addresses recommendations for corrective action

for catastrophic failures.• Overall task objective relates to system engg

feedback & control loop.• Although its important to respond to short term

needs, providing long-term memory through good reporting & documentation is of greater significance.

• This task should be tied with system engg reporting, feedback & control process.

3.4.3 Maintainability Engineering• Maintainability is the inherent characteristic of a

system that pertains to the ease, accuracy, safety & economy in the performance of the maintenance actions.

• It is the ability of an item to be maintained, whereas maintenance constitutes actions taken to restore an item to a specified operating condition .

• Maintainability is a design parameter whereas maintenance is a result of the design.

• Maintainability can be measured in a combination of maintenance times, personnel labor hours, maintenance frequency factors, maintenance cost & related logistic support factors. There is no single measure that ll address all issues.

Categories of Maintenance

1. Corrective Maintenance• The unscheduled actions initiated as a result of

failure(or a perceived failure), that are necessary to restore a system to the reqd level of performance.

• May include troubleshooting, disassembly, repair, remove & replace, reassembly etc.

1. Preventive Maintenance• The scheduled actions necessary to retain a system

at a specified level of performance.• May include periodic inspections, servicing,

calibration, condition monitoring etc.

The aspect of timeThe most commonly used measure of maintainability is

the aspect of time.

1. Up-timepertains to elapsed time applicable to the

system when in operational use, or when in a standby or ready state awaiting for use.

1. Down-timerefers to the total elapsed time required, when the system is not operational, to accomplish corrective maintenance &/or preventive maintenance

Total Maintenance Downtime (MDT)1. Active Maintenance Time (M)

That portion of downtime when corrective &/or preventive maintenance activities are being acccomplished.

M` = (λ)(M`ct) + (fpt)(M`pt) λ + fpt

2. Logistics Delay Time(LDT)That portion of downtime when the system is not operational because of the delays associated with the support capability, e.g. waiting for a spare part, waiting for the availability of test equipment, waiting for the use of a special facility.

3.4.3 Maintainability Engineering3. Administrative Delay Time (ADT)

That portion of downtime when the necessary maintenance is delayed for reasons of an administrative nature; e.g. the unavailability of personnel because of other priorities, organizational constraints, labor strikes etc.

Time To Repair Distributions1. The Normal Distribution

Applies to relatively simple and common maintenance actions where times are fixed with very little variation.

2. The Exponential DistributionApplies to maintenance actions involving part substitution methods of fault isolation in large systems that result in a constant failure rate.

3. The Log-Normal DistributionApplies to most maintenance actions involving detailed tasks with unequal frequency and time durations.

Tasks in Maintainability Engineering1. Maintainability Program Plan• Should be developed in conjunction with reliability PP &

SEMP.• Organizational interfaces, I/O reqts, schedules etc must be

integrated with reliability program reqts & must be directly supportive of SE activities.

• Maintainability activities must be closely integrated with human factors & logistic support functions.

1. Maintainability Modeling• Depends upon the completion of functional-level diagrams.• These should evolve directly from & support the FFBD.• Objective: to illustrate system packaging concepts,

diagnostic capabilities, items repaired or replaced for maintenance etc.

• Results of this task are used in maintenance task analysis(MTA) & supportability analysis & must be provided in a timely fashion.

Tasks in Maintainability Engineering3. Failure mode, effect & criticality analysis(FMECA)• used to aid the development of system packaging schemes

& diagnostic routines.• Used in determining critical preventive maintenance reqts.• Should be closely integrated with reliability & logistics

activities.4. Maintainability Analysis• Includes the accomplishment of many different design-

related studies dealing with system packaging concepts, levels of diagnostics , levels of repairs etc.

• Must be accomplished in conjunction with FMECA & maintainability modeling & coordinated with logistic support analysis(LSA) reqts.

• LSA also requires a level-of-repair analysis & life cycle cost analysis in fulfilling the reqts related to the design for supportibiliy.

Tasks in Maintainability Engineering5. Maintenance Task Analysis incl detailed analysis to:a) Access a given configuration relative to degree of

incorporation of maintainability characteristics in design & compliance with initially specified reqts.

b) Determine the maintenance & logistic support resources reqd to support the system throughout its entire life-cycle.

• Must be accomplished in the preliminary & detailed design phases utilizing available data as a source of info &/or by the review of an existing item using checklists as an aid.

• MTA may be conducted on a COTS item in the event that the maintenance resource reqts have not already been identified.

• This task should be closely coordinated with human factors activities & logistics activities.

Tasks in Maintainability Engineering6. Level of repair analysis (LORA):• Includes an evaluation various system components

to determine whether it is economically feasible to repair and item or discard it in the event of failure.

• If repair is needed, should it be repaired at the intermediate level or depot level?

• LORA may be performed initially, to provide guidelines for packaging, diagnostics & so on, & later in the evaluation of a given design configuration to determine maintenance resource reqts.

• Should be performed in conjunction with MTA & a part of logistic support analysis effort.

Tasks in Maintainability Engineering7. Maintainability demonstration:• Usually performed as part of type2 testing & should

be defined in context of total system test & evaluation effort.

• Objective: to simulate different maintenance task sequences record associated maintenance times & verify the adequacy of the resources reqd to support the demonstrated maintenance activities.

• The results from this activity should not only determine whether maintainability reqts have been met, but should also help to determine whether the supportability objectives have been met in response to logistics support reqts.

3.4.5 Human Factors Engineering• For a system to be complete, the human beings and

the interfaces between humans and different elements of the system need to be addressed.

• The reqts for humans stem from functional analysis, alongwith the reqts for hardware, software etc.

• Different operational & maintenance functions are organized into jobs, tasks etc.

• Subsequent analysis combine and organize different activities & tasks performed by humans based on skill level, performance, assigned workstations etc.

• This in turn leads to the definition of training programs and training support etc.

• As the design progresses, interfaces among hardware, software & human factors should be wel defined/integrated.

Considerations in designing a system for humans1. Anthropometric Factors• Anthropometry deals with the measurement of

dimensions & physical characteristics of human body.

• When establishing basic design requirements for humans, these should be kept in consideration.

• Both “structural” dimensions(when body is static) & “functional” dimensions(when body is in physical activity) should be considered.

• Although average values may be used, the design of work-spaces etc must consider possible variations of both male and female workers.

Considerations in designing a system for humans2. Human Sensory Factors• In design of workstations/consoles the engineer

must be cognizant of human beings’ sensory capabilities.

• Examples:▫ Placement of equipment like panel displays, controls

etc should be such as to facilitate the human capability of seeing.

▫ Designer should consider the human capacity for hearing in terms of frequency and intensity so as to design work areas with acoustics that minimize noise.

3. Physiological factors• Important to consider the effects of environmental

stress on human body.

Considerations in designing a system for humans• Stress is any external activity that acts on an

individual with a degrading impact.▫ Examples: extreme temperatures, high humidity, high

levels of noise, large amount of radiation or toxic materials,

▫ These factors negatively impact humans including, physical fatigue, slower motor response and mental processes.

• Strain may have an impact on one or more of human biological functions(e.g. circulatory system, nervous system, respiratory system etc.

▫ Measures of strain include blood pressure, pulse rae and oxygen consumption.

▫ These factors of strain caused by external stress impact the human performance.

Considerations in designing a system for humans4. Psychological Factors• Relates to the factors that pertain to the human mind:

emotions, traits, attitudes, behavioral responses.• Even with all the other conditions being perfect, lack

of motivation, initiative, dependability, communication skills etc lower the effectiveness and efficiency of personnel.

• The above mentioned characteristics are based on needs of the individual, which, in turn, is a function of system design & organizational development within which he performs.

• Too complicated tasks=> individual gets frustrated, develops a poor attitude & makes more errors.

• To simple & easy tasks=> little challenge, boredom prevails & errors ll occur.

Some Tasks in Human Factors Engg• Human Factors Program Plan

▫ First step in this process.▫ Should be developed in conjunction with reliability PP,

maintainability PP & SEMP so that activities in each phase are mutually supportive.

• Functional Analysis▫ Purpose is to identify functions involving human-

machine interface.▫ This step should evolve directly from and must support

system functional analysis and & functional flow diagrams.

Some Tasks in Human Factors Engg• Detailed Operator Task Analysis

▫ Includes expansion of major system functions into jobs, duties , tasks & so on.

▫ This leads to the definition of operator and maintenance personnel reqts in terms of quantity & skill level, which in turn governs the subsequent development of the training program.

▫ Close coordination must be established with reliability, maintainability & logistics program capabilities.

• Operational Sequence Diagrams▫ Operational Sequence Diagrams (OSD) are developed to

show various sequences of activity involving human machine interface.

▫ Through a symbolic representation, different actions are shown that lead to the identification of specific design reqts.

▫ OSD should evolve from FFBD.

Some Tasks in Human Factors Engg• Personnel test & Evaluation

▫ Purpose: to demonstrate selected human activity sequences to verify operating/maintenance procedures and the compatibility between the human machine.

▫ Demonstrations are conducted using computer simulations, physical mock-ups,

▫ Type 2 testing using pre-production prototype equipment may be employed.

▫ Such tests should not only allow for the evaluation of critical human-machine interfaces but should also provide reliability information pertaining to operator functions, maintainability data, verification & validation of information in formal/ technical procedures, verification of the adequacy of training program for operator & maintenance personnel etc.

3.4.5 Safety Engineering• Safety is a system design characteristic.• Certain materials or processes can be

dangerous to people and or environment, e.g. toxic substances produced, dangerous processes etc.

• Concerns in design deal with two kinds of safety: personal safety and equipment safety.

• Three basic tasks:1. System Safety Program plan: should be in

conjunction with reliability program plan, maintainability PP, human factors PP, & SEMP.

Many activities in each of the plans are mutually supportive and require integration in terms of i/p-o/p programs, schedules etc.

3.4.5 Safety Engineering2. Fault Tree Analysis:• an on-going top-down analytical process

based on deductive analysis and boolean methods for determining system events that cause undesirable events & hazards.

• Events are ranked in order of influence in causing hazards.

• Fault-tree logic diagrams are developed starting at top event & proceeding downwards thru successive levels of causation steps predicting the next.

• Closely related to reliability and maintainability in diagnostics.

3.4.5 Safety Engineering3. Hazard Analysis• Objective is to evaluate the design and

determine possible events that result in hazards at system level.

• By simulating possible failures, critical activity etc at component level, one can identify possible hazards with anticipated frequency , severity & criticality.

• This leads to recommendations for design change.

• This task is closely related to reliability FMECA & human factors safety analysis.

3.4.6 Security Engineering• Design for security is a new found

area of emphasis now. It emphasizes the design of a system to preclude faults/ failures that may cause destruction of system or any part thereof, resulting in damage of material, facilities or life.

• Objective: to prevent an individual or group of individuals from intentionally sabotaging a system for one reason or another.

Considerations in design for security• In designing for security it is necessary to

address the issue of intent, i.e. characteristics should be incorporated in the system to prevent one or more individuals from intentionally inducing faults that ll destroy the system, harm the personnel and or society & environment.

• In response, system should consider the following:

1. Incorporation of external security alarm: that ll detect the presence of unauthorized personnel & hence prevent any “outsider” from operating/maintaining/ changing the system.

Considerations in design for security2. Incorporation of a “condition based

monitoring” capability: that enables one to check the system on continuing basis using sensors, readout devices, inspection methods etc & any diagnostic methods that lead to the detection/correction of any problem.

• An objective is to initially determine that the system is in satisfactory condition and to provide the necessary subsequent controls that ll ensure that this condition ll continue to exist.

3. Incorporation of a built-in capability (mechanism) to detect & initiate an alarm when a problem is detected & prevent a chain of failure reactions that may lead to system damage/destruction.

Considerations in design for securityIn essence the designer must address such issues as1. Preventing un-authorized personnel from gaining

access to the system.2. Being able to initially determine the condition of

the system and the follow-on monitoring of its components at all times & being able to control the processing of these components as they progress through the forward and reverse flow of activities.

3. Being able to detect & subsequently prevent failures.

3.4.7 Manufacturing and Production EngineeringRole of manufacturing/production may take

several forms:1. One-of-a-kind system entity

there is an obvious strong interface between design activity and follow on construction of a system, which, in turn, is based on the recommended design configuration.

2. Mass produced itemshere one needs to:

▫ design the product for producibility▫ Design the manufacturing/production

capability to be both efficient and effective in producing that product.

Design for Producibility“Producibility” is a measure of the relative ease & economy

of producing an item.Major objectives:• Quantity & variety of items should be minimized.

Standard items with easily available suppliers should be used.

• Materials for construction should be standard and available in desired quantity at the appropriate time, Peculiar shapes requiring excessive machining should be avoided.

• Design configuration should allow for easy assembly & dis-assembly of system elements.

• The design should be simple enough so that it can be produced by more than one suppliers using conventional processes. It should be compatible with computer aided design(CAD) and computer aided manufacturing (CAM).

Latest goals in manufacturing• Agile manufacturing: to develop a capability that

can react quickly in producing a wide variety of high quality products, with changing configurations in a short period of time, & provide customer satisfaction.

• Lean production: emphasizes the elimination of waste in utilization of resources, personnel & time.

• Improvement in functions of the supply chain.• Development of Electronic Commerce (EC)

methods that have enabled the integration and rapid processing of information and data packages supporting key business operations.

• In addition to above, we need to address life cycle issues related to maintenance and support as well in addition to operational activities.

3.4.8. Logistics & Supportability EnggResources1. Manpower and Personnel• includes all personnel reqd in installation, checkout,

operation, handling & sustaining maintenance of the system.

• Maintenance personnel considerations cover all levels of maintenance, operation of test equipment, operation of facilities etc.

2. Training, Training Equipment & Devices• Includes initial training of all operator &

maintenance personnel plus “replenishment” training for replacement personnel.

• Training equipment, simulators, mock-ups, data, manuals, facilities, devices etc for training are all included in this.

3.4.8. Logistics & Supportability Engg3. Supply Support• Includes all spares(units, assemblies, models etc), repair

parts, consumables, special supplies & related inventories needed to support prime equipment, software, test & support equip, transportation & handling equip & facilities.

• Provisioning documentation, procurement functions, warehousing & personnel associated with acquisition & maintenance of spare/repair part inventories at all support locations are included.

4. Test and Support Equipment• Includes all tools, special condition monitoring,

diagnostic, calibration, servicing and handling equipment etc.

• Both standard(existing & already in inventory) and peculiar(newly developed) items must be covered.

3.4.8. Logistics & Supportability Engg5. Packaging, handling, storage & transportation• Includes all special provisions, materials,

containers(reusable & disposable) & supplies necessary for packaging, preservation, storage, handling &/or transportation of prime equipment, , spare & repair parts, personnel, technical data & mobile facilities.

• Covers the initial distribution of products & transportation of personnel & materials for maintenance purposes.

6. Facilities• Includes all special facilities needed for system operation

& performance of maintenance functions at each level.• Physical plant, real estate, portable building, housing for

personnel, intermediate maintenance shops, calibration labs.

• Capital equipment & utilities(heat, power, energy reqts, environmental controls) are generally included.

3.4.8. Logistics & Supportability Engg7. Technical Data• Includes system installation & checkout procedures,

operating & maintenance instructions, inspection & calibration procedures, overhaul procedures, modification instructions, facilities info, drawings & specs & associated databases for system operations & maintenance.

• Info processing reqts (networks & equipment) are also included in this category.

8. Computer Resources• Includes all software, computer equipment, tapes/disks,

databases & accessories necessary in performance of system maintenance functions at each level .

• This covers condition monitoring & maintenance diagnostics aids.

Key Activities1. Integrated Logistic Support Plans(ILSP)• It is usually initiated during conceptual design phase

& updated during prelim design phase.• Covers all planning activities, design activities,

procurement and acquisition activities & sustaining support activities.

• It includes a description of logistics concepts, research results and acquisition strategy, logistics organization, supply requirements and organizational interfaces etc.

• Basically ILSP must cover all applicable logistics and related activities identified by forward and reverse flows.

• ILSP must tie directly into SEMP, esp. in regard to tasks dealing with logistics engg.

Key Activities2. Logistics Engineering• Starts with definition of specific design-to

requirements evolving from system operational reqts., maintenance concepts and identification and prioritization of TPMs

• These reqts. are furthur delineated through functional analysis & reqts. Allocation process

• Furthurmore there are reqts. Related to day-to-day design participation process including initial design-to criteria, trade-off analysis, supportability analysis, review of supplier activities, formal design reviews, test and validation activities etc.

• In essence this area must be represented and included as a member of design team and be involved in ongoing desig activities

Key Activities3. Performance Based Logistics and

Associated Design-To Requirements•QFD analysis approach helps in

identification and prioritization of quant. Design-to goals

•If all the objectives described in this text are supposed to be ultimately realized, specific design-to requirements must be applied to all the elements of the system, not only those involved in accomplishing a given mission scenario

Key Activities4. Supportability Analysis• An ongoing iterative analytical process (included

within overall system analysis activity) with the basic objective of initially influencing design & subsequently determining logistics support resource requirements based on design config.

• Basically SA does the following:a) Aids in estab. of PBL metrics and supportability

reqts. during conceptual design through evaluation of sys. operational reqts., alt. tech. applications & alt. logistics & maintenance support concepts. These reqts lead to design criteria establishment for logistics & maintenance support infrastructure & are included in appropriate specs.

Key Activitiesb) Aids in evaluation of alt. sys., equip/software, design

config. This includes ongoing process of synthesis, analysis and design optimization, involving trade-off studies to arrive at a recomm arroach for supportability

c) Aids in eval of a design config to determine logistics support resource reqts. which include personnel quantities, skill levels, training, spare/repair parts, test and support equip, packaging and transportation, facilities, maintenance software and data. MTA constitutes database for determining these reqts.

d) Aids in ultimate measurement & eval of an operating system in users environment. Field data are collected, analysed & utilized to update SA which was based on design data. Objective is to determine true effectiveness of the sys, logistics & mainten support infrastructures etc. & to provide appropriate feedback and recommendations

Key Activities5. Sustaining System Support• After establishing a system design config a series of logistics

activities need to be performed (selection of suppliers, procurement of materials and services, movement of items through the production process, transportation & distrib of products to the consumers’ operational sites)

• Even after delivery to the ultimate user, some customer service reqts may be needed in form of training & assistance in the performance of operational and maintenance tasks

• In essence, some activities are necessary for the sustaining maintenance and support of the system throughout its planned life cycle

• The system engg role is that of assessment (data collection, analysis, and feedback) and verification that the system is in compliance with the initially specified requirements. The ultimate objective is to ensure complete customer satisfaction

3.4.9 Disposability Engineering• System retirement & disposal activities are

included in reverse flow of activities.• Components may be retired because:

▫ They get obsolete due to technology upgrade.▫ Space reduction in inventory due to changes in

mission requirements.▫ Failures happen and resultant faulty equipment

needs to be repaired/disposed of.In each of these cases there are logistics

requirements(reverse logistics) and expenditures of maintenance and support resources.

3.4.10 Quality Engineering• Quality: meeting or exceeding the reqts, needs,

expectations of the consumer.• Motivation for quality: survival in a highly

competitive environment of suppliers.• In past, quality control(QC) r quality assurance(QA)

programs were used to ensure quality.• Recently, the concept of total quality management

(TQM) has evolved.▫ Total Quality Management: total integrated

management approach that addresses system/product quality during all phases of life-cycle and at each level in the overall system hierarchical structure.

▫ It provides before-the-fact orientation to quality.▫ It is a unification mechanism that ;links human

capabilities to engineering, production and support qualities.

Characteristics of TQM• Total customer satisfaction is primary objective

instead of minimization of effort. Customer orientation is important vs what can I get away with.

• Iterative practice of “continuous improvement” is emphasized. Objective is to seek improvement on a day-to-day basis as opposed to last minute efforts to meet standards.

• An individual understanding of processes, effects of variation, application of process control methods is reqd so as to ensure the productivity of individual employees for continuous improvement.

• TQM emphasizes a total organizational approach involving every group in organization. Individual employees must be motivated from within to meet quality objectives.

Design for Quality• In design for quality, the projected life cycles

must be considered in total.• A system in conceived, designed, produced,

utilized and supported throughout its planned life cycle.

• In initial design, consideration must be given to:a) Design of the process that ll be utilized to produce

the system.b) Design of the support configuration that ll provide

ongoing maintenance.• Interactions among the aforementioned areas are

numerous & hence they need to be viewed on integrated basis.

Activities in regard to System EnggQuality Planning• Development of a TQM plan must be accomplished

during conceptual design phase and updated during prelim and detailed design.

• Inherent all the quality engg activities includinga)Determination of engg design reqts using a QFD,

“house of quality or an equivalent approach.b)Evaluation & design of manufacturing & assembly

processes in response to design technology decisions.c)Participation in the evaluation & selection of system

components and supplies sourcesd)Preparation of product, process & material specs as

reqd. e)Participation in on-site supplier reviews.f) Participation in formal design reviews.

Activities in regard to System EnggQuality in Design• Emphasis is on design simplicity,flexibility,standardization

etc • There are concerns for variability, whereby a reduction in

variation of dimensions for specific component designs or tolerances in process designs, will give overall improvement.

• Taguchi’s general approach to “robust design”: a design insensitive to variations normally encountered in the production & or operational use.

• More robust design => less support reqts => lower life cycle cost & higher degree of effectiveness.

• Overall design improvement requires a combination of careful component evaluation and selection, use of statistical process control methods & experimental testing procedures on a continuous basis.

Environmental Engineering•“environment”: refers to numerous external factors that

must be dealt with during he system design & development process.

•“design for environment”: in addition technical & economic factors, one must deal with the ecological,, political & social considerations as well.

•The system being developed should be compatible with, acceptable in and ultimately must exist within its desired environments.

• It is a requirement in the spectrum of system engineering that the system must be:

socially acceptable Compatible with political structure Technically & economically feasible Will not cause degradation to environment

Particular Concerns•Of particular interest are ecological considerations.•Ecology: pertains to the inter-relationships among the

individuals & their environment.• Some problems that are particularly harming the

ecological balance are:▫Air pollution▫Water Pollution▫Noise Pollution▫Radiation▫Solid Waste

3.4.12. Value/cost Engg• Apart from the technical factors (performance, reliability,

maintainability, human factors, supportability, and quality), economic factors play an equally important role and a proper balance between the two must be attained

• These factors are combined to give a measure of effectiveness. For example:▫Effectiveness FOM = (Performance x Availability) / Life-cycle

cost▫Effectiveness FOM = System Capacity / (Revenues – Cost)▫Effectiveness FOM = Life-cycle cost / Facility Space▫Effectiveness FOM = Supportability / Life-cycle cost

•Life-cycle cost represents the total cost of all activities throughout the system life cycle (includes consideration of all

future costs associated with R&D, construction &/or production, distribution etc.)

3.4.12. Value/cost Engg• In addition costs are often related to functions

accomplished over long term as compared with the rather short term perspective conveyed through traditional accounting structure for most organizations. Following questions ensue:▫Total costs associated with each function should be known▫Functions constituting the high cost contributors over the long

term need to be known. High cost elements and high cost drivers need to be known

▫Cause and effect relationships and their criticalities as they relate to mission accomplishment need to be known

▫High risk areas/elements of the system should be known•Detailed info about above isn’t easily attained yet individual

design & management decisions are based on some smaller aspect of cost w/o assessing effects on total cost

3.4.12. Value/cost Engg• Although some decisions need to be made early, they should

be in the context of total life cycle cost (full cost visibility is essential to properly address risks in decision-making.

• LCC analysis needs to be performed throughout sys design, development, construction/production as well as operation. Certain steps need to be followed:▫First, describe the system in functional terms & construct a

FFBD.▫Next, develop a cost breakdown structure (CBS).

CBS includes all costs and appropriate visibility for determining costs of all functions, processes, and elements over time.

It allows for initial allocation of cost targets in a design-to cost application and for subsequent collection of costs.

Costs are estimated for each year, incl. inflationary & other factors. High cost contributors are noted, cause&effect relationships eval,

sensitivity analysis performed & feasible alt eval. & recommended.

3.4.12. Value/cost EnggPurposes of LCC Analysis• It is used in the eval. of design config. in early stages of

syss development• eval of COTS alternatives• seval of existing system configs to identify high-cost

contributors leading to recos for improvement.Timeline:• Cost targets may be estab initially in conceptual design

phase through development of TPMs.• Trade-off studies are done during prelim & detailed design

phase to support design & procurement decisions.• LCC analysis are conducted towards end of detailed design

& during construction & utilization phase.• Computer based models are used to facilitate the analysis

process

3.5 SOS integration & interoperability reqts•One of the most challenging areas is to deal with

external interfaces among ▫Your system and other systems within an SOS config▫Independent systems operating in the same environment

•This leads to design for interoperability. Important concerns are:▫The newly designed system should be able to operate

effectively and efficiently when deployed and utilized▫External effects of newly designed systems on other

systems inuser environment should be known▫The impact of these other external systems on the new

system should be known•A design objective is to preclude any negative impacts

from these external system capabilities