Chapter 4

Conceptual System
Design
Instructor: Dr. PHAN THỊ MAI HÀ

09 / 2021
 Conceptual system design
❑ Identifying and translating a problem or deficiency into a definition of need
for a system → provide a preferred solution;
❑ Accomplishing advanced system planning and architecting in response to
the identified need;
❑ Developing system operational requirements – functions accomplish its
intended purpose(s) or mission(s);
❑ Conducting exploratory studies leading to the definition of a technical
approach for system design;
❑ Proposing a maintenance concept for the sustaining support of the system
throughout its planned life cycle;
❑ Identifying and prioritizing technical performance measures (TPMs) and
related criteria for design;
❑ Accomplishing a system-level functional analysis and allocating
requirements to various subsystems and components;
❑ Performing systems analysis and producing trade-off studies;
SE – C4: Conceptual system design 2
 Conceptual system design

SE – C4: Conceptual system design 3

 Conceptual system design
4.1 Problem definition and need identification
4.2 Advanced systems planning and architecting
4.3. System design and feasibility analysis
4.4. System operational requirements
4.5 System maintenance and support
4.6. Technical performance measures
4.7 Functional analysis and allocation
4.8 System trade-off analysis
4. 9. System specification
4.10. Concept design review – validation
4.11 Risk analysis
SE – C4: Conceptual system design 4
1. Problem definition and need identification

Problem definition:
A comprehensive statement of the problem should be
presented in specific qualitative and quantitative terms and
in enough detail to justify progressing to the next step;
defining a “real” problem and its importance
Need identification
need for a specific system capability;
need analysis: describe the customer requirements in a
functional manner to avoid a premature commitment to a
specific design concept or configuration → define “WHAT”
SE – C4: Conceptual system design 5
2. Advanced systems planning and architecting

program management plan (PMP):

guides the development of requirements for implementation of a
systems engineering program and the preparation of a systems
engineering management plan (SEMP)
system-level architecture
development of system operational requirements,
determination of a functional architecture,
proposing alternative technical concepts,
performing feasibility analysis of proposed concepts,
selecting a maintenance and support approach;
→ System specification (type A)
SE – C4: Conceptual system design 6
 2. Advanced systems planning and architecting

SE – C4: Conceptual system design 7

2. Advanced systems planning and architecting

SE – C4: Conceptual system design 8

 3. System design and feasibility analysis

justified the need for a new system

identify various system level design approaches or alternatives
that could be pursued in response to the need;
evaluate the feasible approaches to find the most desirable in
terms of performance, effectiveness, maintenance and sustaining
support, and life-cycle economic criteria; and
recommend a preferred course of action

SE – C4: Conceptual system design 9

 4. System operational requirements

Some questions may be asked:

What are the anticipated types and quantities of equipment,
software, personnel, facilities, information, and so on, required,
and where are they to be located?
How is the system to be utilized, and for how long?
What is the anticipated environment at each operational site
(user location)?
What are the expected interoperability requirements (i.e.,
interfaces with other “operating” systems in the area)?
How is the system to be supported, by whom, and for how long?

SE – C4: Conceptual system design 10

4. System operational requirements

Defining System Operational Requirements:

Mission definition – system
Performance & physical parameters - critical system performance
parameters; How are they related to the mission scenario(s)?
Operational deployment or distribution/build
Operational life cycle (horizon)
Utilization requirements (#/day, %/capacity…)
Effectiveness factors: cost, availability, MTBM, failure rate, logistic
support effectiveness,..
Environmental factors

SE – C4: Conceptual system design 11

 4. System operational requirements

Illustrating System Operational Requirements:

Illustration 1: River Crossing Problem
Illustration 2: Aircraft System
Illustration 3: Communication System
Illustration 4: Commercial Airlines Upgrade
Illustration 5: Community Hospital
Illustration 6: Lemon powder system
Illustration 7: Information system

SE – C4: Conceptual system design 12

 5. System maintenance and support

Maintenance and support concept:

Definition of reliability, maintainability, human factors and safety,
constructability and producibility, supportability, sustainability,
disposability, and related requirements for design
requirements for corrective and/or preventive maintenance at any
time and throughout the system life cycle
the levels of maintenance, functions to be performed at each level,
responsibilities for the accomplishment of these functions, design
criteria pertaining to the various elements of support (spares,..)

SE – C4: Conceptual system design 13

 5. System maintenance and support

SE – C4: Conceptual system design 14

 5. System maintenance and support

Maintenance and support concept include:

Leve of maintenance: organizational, intermediate, and
manufacturer/depot/supplier
Repair policies: nonrepairable, partially repairable, or fully
repairable
Organizational responsibilities: customer, the producer (or
supplier), a third party, or a combination thereof
Maintenance support elements: supply support, test and support
equipment, personnel and training,…
Effectiveness requirements: support capability
Environment: impact of external factors, as temperature, shock,…
SE – C4: Conceptual system design 15
 5. System maintenance and support

SE – C4: Conceptual system design 16

 5. System maintenance and support

SE – C4: Conceptual system design 17

 6. Technical performance measures

The measures value:

Technical performance measures (TPMs): quantitative values
(estimated, predicted, and/or measured) that describe system
performance → attributes and/or characteristics that are inherent
within the design.
Design-dependent parameters (DDPs): quantified and are the
bases for the determination of TPMs.

SE – C4: Conceptual system design 18

 6. Technical performance measures

TPM identification and evolution:

TPMs: quantitative factors as reliability MTBF, maintainability
MTBM, logistics response time, information processing time,
facility utilization rate, … from system operational requirements
and the maintenance and support concept
traceability of requirements

SE – C4: Conceptual system design 19

6. Technical performance measures

Relative importance
Technical Performance Quantitative Requirement Current "benchmark"
(customer desires)
Measure (“Metric”) (competing systems)
(%)
Process time (days) 30 days (maximum) 45 days (system M) 10
Velocity (mph) 100 mph (minimum) 115 mph (system B) 32
Availability
98.5% (minimum) 98.9% (system H) 21
(operational)
10 feet long 9 feet long
6 feet wide 8 feet wide
Size (feet) 17
4 feed high 4 feed high
(maximum) (system M)
Less than 1% error rate
Human factors 2% per year (system B) 5
per year
Weight (pounds) 600 pounds (maximum) 650 pounds (system H) 6
Maintainability(MTB
300 miles(minimum) 275 miles(system H) 9
M)
SE – C4: Conceptual system design 20
 6. Technical performance measures

Quality function deployment:

House of Quality (HOQ): ensure that the “voice of the customer”
is reflected in the ultimate design. Matrix “WHAT-HOW”
Each customer attribute is then satisfied by a technical solution

SE – C4: Conceptual system design 21

7. Functional analysis and allocation

Functional analysis:
functional description of the system: action to achieve
objective
process of translating system requirements into detailed
design criteria and the subsequent identification of the
resources required for system operation and support →
system architecture: requirement and structure

SE – C4: Conceptual system design 22

7. Functional analysis and allocation

Functional flow block diagram

SE – C4: Conceptual system design 23

7. Functional analysis and allocation

SE – C4: Conceptual system design 24

7. Functional analysis and allocation

SE – C4: Conceptual system design 25

7. Functional analysis and allocation

SE – C4: Conceptual system design 26

 7. Functional analysis and allocation

Functional allocation
System elements may be grouped by geographical location,
a common environment, or by similar types of items
Individual system packages should be as independent as
possible with a minimum of “interaction effects” with other
packages
Individual system packages should be as independent as
possible with a minimum of “interaction effects” with other
packages
An objective is to pursue an open-architecture
SE – C4: Conceptual system design 27
 7. Functional analysis and allocation

❑ Functional View ❑ Physical View

❑ Described in terms of functions ❑ Described in terms of physical objects
(hardware, software, etc.)
❑ Input Control Commands ❑ Ethernet Interface
❑ Control Radar ❑ Control Processor
❑ Transmit Radar Signals ❑ Transmitter
❑ Receive Radar Signals ❑ High Power Amplifier
❑ Process received radar signal ❑ Receiver
❑ Output Targets ❑ Signal Processor
❑ Manage Power ❑ Target Processor
❑ Detect Faults ❑ Antenna

SE – C4: Conceptual system design 28

System Requirement Operation R. Performance R. Iĩmplementation Validation

Những yêu cầu vận hành

Functional to Physical Mapping
❑ Physical objects perform functions
❑ Hardware component
❑ Software component
❑ Basic Rule
❑ A function must at some level, only be performed by one
physical item
❑ If a function crosses physical items, divide it up into two
functions and establish an interface between them if needed

SE – C4: Conceptual system design 29

 7. Functional analysis and allocation

Decomposition
❑ Process of breaking down high level items into smaller components
❑ Key uses in Systems Engineering
❑ Decompose Requirements:

❑ Create lower level elements within the system:

System → Subsystem →Components → Subcomponent → Part
❑ Decompose Functions:
Create sub-functions that can implemented in a single physical item

SE – C4: Conceptual system design 30

 7. Functional analysis and allocation

SE – C4: Conceptual system design 31

 7. Functional analysis and allocation

Decomposing a Requirement
❑ Decide on a logical subdivision (system → subsystem)
❑ Assign each lower level item some or all of the responsibility to meet
the higher level requirement
❑ Example: Top level requirement – “The widget shall weigh less than
500 lbs.”

SE – C4: Conceptual system design 32

 7. Functional analysis and allocation

Decomposing a Requirement
❑ Some performance requirement allocations can have many interactions
❑ These provide opportunities for design trades

❑ Example: The vehicle shall have a top speed of at least 150 mph
❑ Engine power
❑ Body shape
❑ Power train
❑ Overall weight
❑ Wheels/tires
❑ Steering
❑ Fuel

SE – C4: Conceptual system design 33

 8. System trade-off analyses

Trade-off analyses
define the problem and identify the design criteria or
measures against which the various alternatives will be
evaluated (i.e., the applicable TPMs),
Select the appropriate evaluation techniques,
Select/develop a model to facilitate the evaluation process,
acquire the necessary input data,
evaluate each of the candidates under consideration,
perform a sensitivity analysis to identify potential areas of
risk, and finally recommend a preferred approach.
SE – C4: Conceptual system design 34
 9. System specification – Type A

All level of specification

System – Type A Fig 27 (page 96)
Development – Type B
Product – Type C
Process – Type D
Material – Type E
Understand the scope of the system & sub system to be designed
Requirements
System functions
System interfaces
Other constraints
SE – C4: Conceptual system design 35
10. Conceptual design review – validation

Validation
informal day-to-day project coordination and data/
documentation review and the formal design review -
Design information is released and reviewed for compliance
with the basic system-equipment requirements
If the requirements are satisfied, the design is approved as is.
If not, recommendations for corrective action are initiated and
discussed as part of the formal design review.

SE – C4: Conceptual system design 36

11. Risk analysis

Definition
“Risk a measure of the potential inability to achieve overall
program objectives within defined cost, schedule, and
technical constraints”
“possibility of loss or injury”
Risk is a core competency in Systems Engineering
A risk is expressed as an “IF….THEN” statement
IF the new power amplifier we are designing does not put out enough power,
THEN the radar performance will not meet its range requirement.
IF the test aircraft is not available when the program is ready for flight testing,
THEN the test program be delayed until a suitable replacement can be acquired.
SE – C4: Conceptual system design 37
11. Risk analysis

Systems Engineer - key person to manage risk

Understands the technical breadth of the project
Requirements
Technical approach

Is close to the program manager

Cost, schedule considerations
Access to make decisions

Three components:
An event that might occur
A probability that the event will occur
A consequence resulting from the occurrence of the event
SE – C4: Conceptual system design 38
11. Risk analysis

Type of risk
Technical
Critical technology development fails to meet expectations
Failure to meet a requirement – design error, software bug
A component failure occurs (e.g., in the prototype)
Needed assets are not available

Programmatic
Critical personnel leave the project or are not available when needed
Other project that your project depends on does not provide a
suitable product when it is needed
Loss of funding/budget

SE – C4: Conceptual system design 39

Probability assessment
❑ Experience with the part/vendor/technology/developer staff
❑ Failure rates
❑ New or proven? (new startup part supplier, proven part, etc.)
❑ Number of dependencies
❑ Interfaces
❑ Suppliers
❑ Weather, time windows for lab/test-range access, etc.
❑ Margin
❑ Easy to meet requirement?
❑ Is there excess “X” (time, power, budget, space, etc.) available

SE – C4: Conceptual system design 40

Consequence assessment
❑ Effects of the consequences depends on the situation
❑ Low-Medium-High consequence assessment will usually be defined by
the specific project
❑ Technical
❑ Priority of requirement
❑ Pass/Fail requirement vs. level of performance
❑ Special considerations: safety, catastrophic project failure
❑ Example: What value is assigned to a consequence of harm/death?
❑ Cost
❑ Increase in cost vs. total cost of the project
❑ Schedule
❑ Delay in schedule vs. total time of the project
❑ Critical milestones (major event or for completing project)
SE – C4: Conceptual system design 41
Risk management
1) Identify the Risks
2) Assign probabilities and consequences
3) Rank the risks in order of importance
4) Determine candidate risk mitigations
5) Select and implement risk mitigations
6) Monitor progress….does the risk go down over time?
7) start again……

SE – C4: Conceptual system design 42

Risk management

SE – C4: Conceptual system design 43

Reduce risk by reducing probability
❑ Develop an alternate backup design
❑ Consider relief of requirements
❑ Scale back on high risk requirements in development

❑ Prototype – do testing and get feedback early

❑ Perform analysis and testing of critical design items
❑ Add special oversight to high risk subsystems/components
❑ Perform additional technical and management reviews
❑ Plan ahead – arrange for needed resources early
❑ Parts (especially long lead parts), staffing, vendors

SE – C4: Conceptual system design 44

Reduce risk by reducing consequences
❑ Be prepared to relieve requirements if necessary
❑ Close user involvement, prioritized requirements
❑ Develop project plans that allows for recovery of failures
❑ Include time/resources for second iteration of design

❑ Incremental design approach

❑ Plan to address high risk issues early

❑ Plan a management reserve of schedule and budget

❑ Choose flexible design approaches
❑ Standards, commodity components

SE – C4: Conceptual system design 45

Risk analysis in conceptual design
❑ One of the criteria that is evaluated for each concept is risk
❑ Identify are the sources of risk (technical, programmatic)
❑ Perhaps there is something that can be done to manage the risk
❑ Helps to assess the likelihood the project will fail
❑ Sponsors do not want to end up with a failed project
❑ What happens if a candidate solution is considered to be
“Higher” risk?
❑ Likely will have a larger uncertainty factor added to the cost/
schedule estimate to account for the uncertainty
❑ Development plan may include additional investigation efforts or
experiments to provide confidence the concept will succeed
❑ Add decision points in the schedule to continue or stop depending
on the experimental results
SE – C4: Conceptual system design 46
Risk analysis in conceptual design
❑ Risk is considered as a criteria in comparing alternatives
❑ A concept may be rejected as a viable concept purely on the basis of
risk
❑ Depends on the customer’s risk tolerance

❑ Risk tolerance often depends on the urgency of the need and number
of available concepts that can provide a solution

SE – C4: Conceptual system design 47