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 Specification
2. 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 Cycle
1. 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 Cycle
4. 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 Engineering
3. 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 tasks
1. 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 tasks
3. 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 tasks
4. 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
tasks
6. 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 time
The most commonly used measure of maintainability is the
aspect of time.

1. Up-time
pertains to elapsed time applicable to the system when in
operational use, or when in a standby or ready state
awaiting for use.

1. Down-time
refers 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 Engineering
3. 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 Distributions
1. The Normal Distribution
Applies to relatively simple and common maintenance
actions where times are fixed with very little variation.

2. The Exponential Distribution

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

3. The Log-Normal Distribution

Applies to most maintenance actions involving detailed
tasks with unequal frequency and time durations.
Tasks in Maintainability Engineering
1. 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 Engineering
3. 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 Engineering
5. 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 Engineering
6. 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 Engineering
7. 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
humans
1. 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
humans
2. 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
humans
4. 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 Engineering
2. 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 Engineering
3. 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 security
2. 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 security
In essence the designer must address such issues as
1. 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
Engineering
Role 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 items
here 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 Engg
Resources
1. 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 Engg
3. 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 Engg
5. 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 Engg
7. 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 Activities
1. 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 Activities
2. 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 Activities
3. 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 Activities
4. 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 Activities
b) 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 Activities
5. 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 Engg
Quality 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 including
a)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 sources
d)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 Engg
Quality 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 Engg
Purposes 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