systems engineering for professional engineers

Systems Engineering

For

Professional Engineers

Stanley N. Hack, D.Sc., PE

November 12, 2012

Copyright © 2012. ConsulTech Engineering, PLLC. All rights reserved. 2

PRESENTATION GOALS

• Define Systems Engineering.

• Explain why stakeholders require Systems

Engineering to be an integral part of the

engineering process.

• Provide an understanding of why Systems

Engineering is an important component of all

engineering work.

• Clarify who performs the Systems Engineering

tasks.

• Illustrate the Systems Engineering Process.


PRESENTATION SCOPE

• Overview of Systems Engineering:

o Systems Engineering definition.

o Systems Engineering stakeholders.

o Systems Engineering goals.

o Definition of Systems Engineer.

• Deeper dive into the Systems Engineering

Process using simple examples:

o My barn.

o Indy car.


SYSTEMS ENGINEERING DEFINITION

Systems Engineering is a structured process that incorporates a

multidisciplinary team to develop systems from concept

development through their entire life cycle. Systems Engineering

considers the business and the technical needs of all stakeholders

to result in quality, useful, and sustainable products.

• International Council on Systems Engineering (INCOSE), 1999

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

• IEEE Standard for Application and Management of the Systems

Engineering Process, 1994

An interdisciplinary, collaborative approach that derives, evolves, and verifies a life-cycle balanced system solution which satisfies customer expectation and meets public acceptability.








• MIL-STD-499A, Engineering Management, 1974

A logical sequence of activities and decisions that transforms an operational need into a description of system performance parameters and preferred system configuration.

• MIL-STD-499B, Engineering Management, 1994

An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life-cycle balanced set of system people, products, and process solutions that satisfy customer needs.








• The Engineering Design of Systems, Dennis M. Buede, 2000

The objective of Systems Engineering is to provide a system that accomplishes the primary objectives set by the stakeholders, including those objectives associated with the creation, production, and disposal of a system.

• A Practical Guide to SysML, Friedenthal, Moore, and Steiner, 2012

Systems Engineering is a multidisciplinary approach to develop balanced system solutions in response to diverse stakeholder needs. Systems Engineering includes the application of both management and technical processes to achieve this balance and mitigate risks that can impact the success of the project.


IMPORTANT DEFINITIONS

System An integrated composite of elements (components, subsystems, modules,

people, and processes) that interact with one another and with their

collective external environment to provide a capability that achieves a set of

common objectives via the accomplishment of a set of tasks.

System of Systems A collection of task-oriented or dedicated systems that pool their resources

and capabilities together to create a new, more complex system which

offers more functionality and performance than simply the sum of the

constituent systems. System members of a System of Systems interact

with one another via interfaces that are external to each system member.

Decomposition A process of dividing components, processes, and problems into an

inclusive hierarchical set of simpler components, processes, and problems.

Model Any incomplete representation of reality. A model is an abstraction

constrained by fidelity and performance.


A SHORT HISTORY OF SE

• Concepts of Systems Engineering have been traced back to the

early 1900’s at Bell Labs.

• The term Systems Engineering dates to the early 1940’s at Bell

Labs.

• The RAND Corporation was founded in 1946 by the US Air

Force. It created Systems Analysis, which is an important

aspect of today’s Systems Engineering.

• Systems Engineering as we know it today was first taught at

MIT in 1950.

• The US Department of Defense entered the world of Systems

Engineering in the late 1940s with the initial development of

missiles and missile-defense systems.

• Formation of the International Council on Systems Engineering

(INCOSE) in 1990.

Sources: 1) The Engineering Design of Systems, Models, and Methods, Dennis M. Buede, 2000

2) www.incose.org


SE STAKEHOLDERS

• Customer Stakeholders

o Executives

o Users

o Maintainers

• External Stakeholders

o Inspectors

o Neighbors

o Government

o Vendors

o Prime Contractor

o Subcontractors

• Internal Stakeholders

o Executives

o Engineering Disciplines

o Architects

o Manufacturing

o Quality Assurance

o Sustainment and Support

o Training


SYSTEMS ENGINEERING GOALS

The Systems Engineering Process must answer the following:

• What is to be engineered (designed / developed / built / studied / analyzed /

modified …)?

• How will the engineering be performed?

• Who is to perform the engineering tasks?

• When will the engineering tasks be performed?

• What is the cost of the engineering?

• When is the engineering finished? How do we know this?

Systems Engineering tasks are often integrated into the tasks of the lead

engineer or project manager. These tasks can be performed informally or

in a highly documented formal fashion resulting in a large quantity of

artifacts (documents). The required formality of the Systems Engineering

Process is directly dependent upon the level of a project’s complexity. The

design and construction of a pole barn (our example) requires no Systems

Engineering as an independent activity. The design and construction of a

nuclear power plant requires an extremely high level of formality in its

System Engineering Process.


Most engineers have performed at least some aspects of Systems

Engineering as integral parts of their design and development activities.

Very large development efforts, such as developing an airliner or

designing a nuclear power plant, depend on Systems Engineering as

an independent discipline to manage the program technically. There is

something for all engineers to learn by understanding the Systems

Engineering Process.

• Informal Systems Engineering

o Often performed by engineering team members who support multiple

technical tasks.

o Results in artifacts (documents) that are integrated into the project’s

documentation package.

• Formal Systems Engineering

o Often performed by a team of engineers who are dedicated to the

Systems Engineering tasks.

o Results in a large number of dedicated artifacts (documents).

o Provides a means of tracing requirements throughout all aspects of a

system’s life-cycle.

THE SYSTEMS ENGINEER


SYSTEMS ENGINEERING PROCESS

To understand the Systems Engineering Process via

an example, let’s build a barn and consider designing

an Indy car.

• First, we will look at the components of the Systems Engineering

Process.

• Second, we will apply each of the process components to building

the barn.

• Show limited examples applying the Systems Engineering

Process to the design of an Indy car.



“V” Model

From: K. Forsberg and H. Mooz, The relationship of systems engineering to the project cycle, Engineering Management Journal, 4(3), 36-43, 1992


“SIMILAR” Process • State the Problem

• Investigate Alternatives

• Model the System

• Integrate

• Launch

• Asses Performance

• Re-Evaluate

The significance of the SIMILAR Process

is the incorporation of re-evaluation

feedback loops at every step. Note that

the feedback loops encompass the

present step and all previous steps. This

use of constantly re-evaluating introduces

concepts of the Agile Development

Paradigm into the Systems Engineering

Process.


A. T. Bahill and B. Gissing, Re-evaluating systems engineering concepts using systems thinking, IEEE

Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews, 28 (4), 516-527, 1998


Apply tailored process to each of

the Life Cycle Functions

From: Systems Engineering Fundamentals, Defense Acquisition University Press, 2001


“V” Model

“SIMILAR” Process


US Government acquisitions depend on Technical Management (SE),

Business Management, and Contract Management.

ENGINEERING PROGRAM PROCESS

US Government

Technical

Reviews and

Artifacts (software system

development)


STAKEHOLDER REQUIREMENTS

Stakeholder

Requirements

BARN

• Requirements:

o Shall be of sufficient size to hold three

automobiles and include a workshop.

o Shall have sufficient height to house an

automobile lift.

o Shall provide entry/exit access for three

automobiles.

o Shall meet all codes.

o Shall support applicable snow loads.

o Shall be attractive.

• Constraints:

o Budget.

o Location.

INDY CAR

• Requirements:

o Shall meet all formula requirements.

o Shall have top speed of 230+ mph.

o Shall have a forward acceleration of 1.0 G.

o Shall brake with a deceleration of 3.0 G.

o Shall have a lateral acceleration of 4.0 G.

o Shall consume no more than 1.75 liters/km

of fuel at maximum speed.

• Constraints:

o Budget.

o Laws of physics!


System

Requirements

SYSTEM REQUIREMENTS

• Stakeholder:

o Shall be of sufficient size to hold three

automobiles and include a workshop.

o Location.

o Shall have sufficient height to house

an automobile lift.

o Shall provide entry/exit access for

three automobiles.

o Shall meet all codes.

o Shall support applicable snow loads.

o Shall be attractive.

o Budget.

BARN

• System Requirements:

o Size and layout.

o Height.

o Building, foundation, and

roof type.

o Materials.

System requirements are derived from stakeholder

requirements and constraints, or they are added to fill voids.


System

Requirements

SYSTEM REQUIREMENTS

TRADE STUDIES and ANALYSES

Trade Trade Space

Building Type • Post and beam (Pole Barn)

• Stick-built on footers

• Stick-built on piers

Roof Structure • Beam and rafters

• Truss

Roof Type and Pitch • Gable – 12/6, 12/4 (12/6)

• Hipped – 12/6, 12/4

• Lean-To

Siding Material • Wood – board and bat, plywood (T1-11)

• Vinyl

• Steel

Roof Material • Shingles

• Steel


SYSTEM ARCHITECTURE

Architecture • System Design

• Topology

• Behavior

• Interfaces

• Component Definitions

System Design and Architecture


VERIFICATION AND VALIDATION PLAN

Verification and

Validation Plans

Verification – Did you build what you planned to build?

– Does the system meet the System Requirements?

Validation – Does the system do what it is supposed to do?

– Does the system meet the Stakeholder Requirements?

Test Plan – The Verification and Validation Test Plan is often

considered to be the most important document

developed within the Systems Engineering Process. It

defines when the project is finished.


Verification and

Validation Plans

VERIFICATION AND VALIDATION PLAN

Indy Car Validation Plan • The following tests shall be made during

test run at racing speeds of at least 10 laps

on a 2.5 mile oval track:

o Top speed shall be measured at the end

of the straight-a-ways using a Model xxx

speed radar and shall exceed 230 mph.

o Maximum lateral acceleration shall be

recorded by a Model xxx accelerometer

and shall exceed 4.0 G.

• The following tests shall be made during

threshold braking from a speed of at least

150 mph:

o Maximum braking deceleration shall be

recorded by a Model xxx accelerometer

and shall exceed 3.0 G.

Indy Car Verification Plan • Engine horsepower shall be measured

using a Model xxx dynamometer and

shall exceed xx HP.

• Suspension travel at the front wheels

shall be measured using a Model xxx

caliper and shall be in the range of xx

to xx cm.

• Turning radius of a full circle traveled

under steering lock in both directions

shall be measured with a Model xx tape

measure and not exceed xx m.

• Front wing area shall be measured with

a Model xx tape measure and shall not

exceed xx cm2.


COMPONENT REQUIREMENTS

Component and

Module

Requirements

BARN

• Posts – material, strength

• Beams – material, strength

• Rafters – material, strength

• Trusses – size and pitch

• Siding – material, color

• Roofing – material, color

• Overhead Doors – material, color

• Entry Doors – material, color

• Windows – type, size, material, color

• Soffit – material, color

• Fascia – material, color

• Trim – material, color

Note: All components are commercial

off-the-shelf (COTS)

INDY CAR

• Chassis

• Suspension

• Brakes

• Body

• Engine

• Transmission

• Controls

• Maintenance

Note: Most components are custom built for

this application. Their requirements are

derived from the system requirements

and are derived through considerable

analyses and trade studies.


COMPONENT DESIGN

Component and

Module Design

• Specify commercial off-the-shelf (COTS) and purpose-built components.

• Design purpose-built components.

• Design modules and subsystems (interconnected collections of components).

• Barn Example

o Specify poles based on loading.

o Design nail-laminated poles.


COMPONENT UNIT TEST PLANS

Component and Module Test Plan

Unit Test Plan for Each Component, Module, Subsystem

• Develop test procedure

• Specify test fixtures

• Specify test stimulation inputs

o Specify source of inputs

o Develop models to provide input stimulation

• Specify expected outputs

o Specify output sinks (data recorders, etc.)

o Develop models to predict expected outputs


BUILD AND ASSEMBLE COMPONENTS

Component and

Module Build and

Assemble

BARN

• Posts

• Overhead Door

• Entry Doors

• Windows

INDY CAR

• Chassis

• Suspension

• Brakes

• Body

• Engine

• Transmission

• Controls

• Jack System

• Monitoring Computer

• Telemetry System


Component and

Module Unit Test

UNIT TEST

BARN

• Posts – by inspection

• Overhead Door

o Inspection

o Range of motion

o Spring tension

• Entry Doors

o Inspection

o Range of motion

• Windows – by inspection

INDY CAR

• Formula Rules

o Inspection

o Dimensions

o Weights

o Specifications

• Chassis

o Dimensions

o Flex

• Engine – dynamometer testing

o Specs (HP, max RPM, etc.)

o Endurance

o Size and weight

• Etc.


SYSTEM INTEGRATION

System

Integration

• Barn – build it

• Indy Car

o Assemble car

o Connect all interfaces

System Integration is the assembly phase of building a system. For

complex systems, such as a commercial aircraft, this is often the first

opportunity to verify that all unit tested components fit as architected.

For a commercial aircraft, System Integration is the building out of the

air frame with the system components such as engines, wiring

harnesses, hydraulic lines, control systems, seats, …


VERIFICATION AND VALIDATION

System

Verification and

Validation

Verification – Perform formal Verification Test Plan.

– Did you build what you planned to build?

– Does the system meet the System Requirements?

Validation – Perform formal Validation Test Plan.

– Does the system do what it is supposed to do?

– Does the system meet the Stakeholder Requirements?


Operational Tests

OPERATIONAL TESTS

Operational tests are sometimes included in the

Systems Engineering Process. Often, they occur

after Stakeholder Acceptance. The are generally in

situ evaluations of systems in their operational

environments. Faults uncovered during operational

tests are generally corrected under warranty.


STAKEHOLDER ACCEPTANCE

Stakeholder

Acceptance

Stakeholder acceptance is a contractual event. A well

executed System Engineering Process results in the artifacts

necessary to satisfy the technical aspects of a contractual

obligation. In other words, the System Engineering Process

answers the question: When is the engineering finished?

$$


SUMMARY

• All engineers perform Systems Engineering tasks at some

level of formality.

• The level of formality of the Systems Engineering Project is

directly related to the size and complexity of the project.

• Regardless of the formality level taken, the Systems

Engineering Process must answer the following:

o What is to be engineered (designed / developed / built / studied /

analyzed / modified …)?

o How will the engineering be performed?

o Who is to perform the engineering tasks?

o When will the engineering tasks be performed?

o What is the cost of the engineering?

o When is the engineering finished? How do we know this?


QUESTIONS?

?

systems engineering for professional engineers

Documents