System Engineering

#

EM.413 System Engineering meeting Eric Rebentisch

→

#

Systems in the service industry

→

#

Attributes of a system

→

#

Intagible

→

#

non physical

→

#

Heterogenous

→

#

sociotechnical factors mean delivery and experience will vary

→

#

Inseparable

→

#

value provided at time of interaction

→

#

Perishable

→

#

value does not exist unless produced

→

#

Key system concepts

→

#

co creation of value between offeror and beneficiary

→

#

time and place dependent

→

#

->

→

#

to what degree is MIX a service?

→

#

Product-service systems as a gradient

→

#

many systems are part product, part service

→

#

->

→

#

from peer who worked at Planet labs

→

#

planet labs reframed the problem of building a satellite into serving the data from a satellite

→

#

when you think in the solution neutral space, you can see opportunities to reframe products as services

→

#

Design of services

→

#

what response are you aiming for

→

#

Disneyland is a service

→

#

digital twin

→

#

types

→

#

digital twin

→

#

data travels between digital and physical automatically

→

#

digital shadow

→

#

data flows automatically from physical to digital, manual in inverse direction

→

#

digital model

→

#

manual data flow in both directions

→

#

examples

→

#

google maps

→

#

digital twin?

→

#

uses traffic data

→

#

->

→

#

value seems to be determined by how the flow of data is organized from physical to digital

→

#

System Engineering

→

#

EM.411 meeting Eric Rebentisch System Engineering

→

#

I tend to ignore the note granular, complicated, step by step processes that professors outlines

→

#

For better or worse

→

#

eg

→

#

The “V” model of system engineering

→

#

Is all cost actually cost in human well-being ?

→

#

Verification, validation, integration, testing

→

#

Verification vs validation

→

#

Verification

→

#

Meeting requirements

→

#

Validation

→

#

Satisfying customer needs

→

#

Integration

→

#

Put the parts together to make sure things work together

→

#

Includes the expected operating environment

→

#

eg

→

#

Autonomous vehicles testers on public streets

→

#

Integration readiness level

→

#

How easy is it to integrate things

→

#

A stepping stone to System Readiness Level

→

#

Now what the heck is system readiness level? So

→

#

Seems important

→

#

The story of F35 software development

→

#

The kind of thing I think I could help do

→

#

Went from extreme slow iteration cycles to much more rapid testing

→

#

This seems like the process could be quite different for first time, one off systems vs repeated builds

→

#

We’re really talking about first delivery, QA is different (if probably a subset)

→

#

The core idea is cost of change goes up over time

→

#

Testing

→

#

Functional or non functional

→

#

Models

→

#

The cost pressure is to do model based engineering and simulation

→

#

Models need maintenance and testing as well

→

#

Thinking about the technological change 11.325

→

#

Are technologies and systems isomorphic ?

→

#

Maybe technologies are a type of system

→

#

Both seem to be defined by fulfilling a function

→

#

All this essentially means we need to build a system to deliver the system

→

#

This level of detail seems excessive for such abstract out flexible guidelines

→

#

I’m guessing this is mostly about exposure to different options for processes

→

#

I guess I oscillate between thinking about building the product vs building the process that delivers the product at scale

→

#

Both are systems that need to be built

→

#

Similarly

→

#

We seem to be talking about a system that needs to be built to deliver another system

→

#

A system to deliver a system

→

#

isomorphism ->

→

#

System Engineering

→

#

A system to design a system

→

#

isomorphism ->

→

#

System Architecture

→

#

A system to build the systems to design and deliver a system

→

#

isomorphism ->

→

#

Process management

→

#

EM.413 System Engineering meeting Eric Rebentisch

→

#

sociotechnical systems

→

#

Integration practices

→

#

How to change an organization

→

#

Similar to the System Engineering V

→

#

System Engineering

→

#

Conversation with context

→

#

System Design/EM.412 meeting Eric Rebentisch System Engineering

→

#

Modeling uncertainty

→

#

EM.413 System Engineering Eric Rebentisch meeting

→

#

John Thomas presenting on system safety and security

→

#

Single loop vs double loop learning

→

#

Single Loop

→

#

What happened?

→

#

What did we do?

→

#

->

→

#

Two mistakes can appear different though the same methodology led to both

→

#

Double Loop

→

#

What happened?

→

#

What did we do?

→

#

Why did we do this?

→

#

Reliability Block Diagram

→

#

shows redundancies

→

#

used in Fault Tree Analysis

→

#

Systems Theoretic Process Analysis

→

#

Define purpose of analysis

→

#

Model of control structure

→

#

Identify unsafe control actions

→

#

Identify loss scenarios

→

#

EM.413 System Engineering meeting Eric Rebentisch

→

#

Afreen Siddiqi

→

#

On Optimization

→

#

in industry

→

#

Amazon, airlines, communication systems use critically use optimization models

→

#

“large scale” is between thousands and millions of variables

→

#

dodging local extrema to find the global extrema

→

#

linear vs non-linear problems

→

#

most interesting engineering problems are non-linear

→

#

simplex method

→

#

if you have a linear problem, the intersections of all your linear constraints is where the optimal solutions will exist

→

#

types

→

#

LP = linear programming, single objective

→

#

NLP = non linear programming, single objective

→

#

MOLP = multiple objective, linear programming

→

#

MONLP = multiple objective, non linear programming

→

#

Mean variance optimization

→

#

This is the direction System Engineering is heading

→

#

EM.413 Eric Rebentisch System Engineering meeting

→

#

Thinking about how changes propagate throughout the system

→

#

Change Propagation Index

→

#

Rule of thumb

→

#

Every milestone multiplies the cost of change by 10

→

#

EM.413 Eric Rebentisch System Engineering meeting

→

#

Complexity

→

#

Complexity correlates with cost

→

#

Typical measures

→

#

parts count

→

#

source lines of code or function calls

→

#

information content

→

#

->

→

#

should actually be Technical Simplicity

→

#

Mentions the difference between Technical Simplicity vs Interfacial Simplicity

→

#

Dimensions of complexity in system development

→

#

functional

→

#

->

→

#

Technical Simplicity

→

#

McCabe graph theoretic structure

→

#

Shannon Entropy

→

#

Gutman Graph Energy

→

#

structural

→

#

organizational

→

#

->

→

#

homomorphic forces between structural and organizational?

→

#

complex vs complicated

→

#

funny to hear both these brought up

→

#

I guess I would say complicated sounds like “someone added complexity, hence they complicated it”.

→

#

is there a difference between functional complexity and structural complexity?

→

#

We haven’t gotten this to a science yet

→

#

Complexity vs modularity as a tradespace

→

#

Modular Design

→

#

Topology

→

#

understand the role of System Architecture on overall complexity

→

#

EM.411 meeting Eric Rebentisch System Engineering

→

#

Model based engineering

→

#

Model-based systems engineering

→

#

Common frameworks

→

#

SysML

→

#

OPM

→

#

UML

→

#

Doors NG

→

#

Common tools

→

#

OPCloud

→

#

Matlab

→

#

Modelica

→

#

Microsoft visio

→

#

3D experience

→

#

Etc

→

#

Similar to Generative design

→

#

Airbus

→

#

Digital design manufacturing and simulation

→

#

Roller coaster tycoon seems like a pretty good system model

→

#

Or simulator

→

#

NASA JPL created a total integration environment

→

#

OpenMBEE

→

#

integrated things like

→

#

Github

→

#

Jira

→

#

Jupyter

→

#

Cameo simulation

→

#

Docker

→

#

Etc

→

#

Turn the systems engineering V into a Diamond

→

#

The real world V gets mirrored in a parallel digital pipeline

→

#

Are we modeling the product or the process?

→

#

Either, both

→

#

Model process to model a product…?

→

#

Often the process is the product

→

#

In software, the gradient between model and product is more blurry

→

#

Maybe that also makes it harder to justify modeling, it feels more productive to focus on the product directly

→

#

But the product is essentially a robust model

→

#

First do system engineering, then build a model

→

#

Musk’s Principles of System Design

→

#

Make requirements less dumb

→

#

Delete the part or process

→

#

Simplify or optimize the design

→

#

Modeling is when the place you document is the same as the place you think about and examine

→

#

“Documenting with style”

→

#

Model based enterprise

→

#

Digital twin

→

#

Digital thread

→

#

requirements are typically how engineers communicate

→

#

Communication between organizations should be the flow of requirements

→

#

System engineer delivers system technical solution

→

#

System architecture delivers system concept and plan

→

#

Program manager delivers value to the system stakeholders

→

#

→

#

System Architecture vs System Engineering

→

#

Plenty of overlap in this course

→

#

EM.413 System Engineering meeting Eric Rebentisch

→

#

Lifecycle Costs

→

#

Tom Toner

→

#

Semiconductor machine

→

#

Mean Time Between Failures set as constraint

→

#

Cymer OnPulse

→

#

Sell a device but charge based on uptime

→

#

Data safety is sometimes a problem

→

#

Good margins for Cymer, customers liked the predictable pricing

→

#

Lifecycle Assessment

→

#

->

→

#

Started in the environmental movement to check environmental impact

→

#

Different time spans reflect different ROIs

→

#

SESAME model

→

#

Lifecycle Cost Analysis

→

#

Discussion on electric vehicles

→

#

https://www.theguardian.com/commentisfree/2023/jun/03/electric-vehicles-early-adopter-petrol-car-ev-environment-rowan-atkinson

→

#

Holistic approach requires thinking about transportation

→

#

public transportation more efficient in terms of space and energy

→

#

cost of maintaining roads

→

#

heavier

→

#

System Engineering with Eric Rebentisch

→

#

Selecting among design options

→

#

Matrices

→

#

Pugh concept selection matrix

→

#

Unweighted

→

#

Weighted matrix

→

#

Analytic hierarchy process

→

#

Maybe Fibonacci weighting would make sense

→

#

Trade study

→

#

Explores the solution space

→

#

Process

→

#

Study rules

→

#

Includes choosing evaluation criteria and their relative importance

→

#

This feels similar to setting up the matrices

→

#

Sample

→

#

Test

→

#

Could be back off the envelope, or a contractor deliverable

→

#

Tradespaces

→

#

Pareto front is essentially about ROI

→

#

Which is essentially about opportunity cost

→

#

Relationship of attribute to utility

→

#

Multi-Attribute Tradespace Exploration

→

#

Cost is often used to represent the combined attributes

→

#

Single attribute

→

#

Probably best to segment by highest connectivity and highest sensitivity architectural decisions

→

#

Feels like evaluation criteria for trade studies, attributes for tradespace and matrices are really the operative work. These different methods are essentially different ways of data visualization

→

#

Multiple stakeholders

→

#

Arrow’s impossibility theorem

→

#

In general there is no optimal solution to a problem where stakeholders have conflicting needs

→

#

Design vector

→

#

The vector representation of the Architectural Decisions

→

#

Made up of design variables

→

#

Design-value matrix

→

#

Attributes vs design variables

→

#

Are these 1-1?

→

#

No

→

#

EM.411 System Engineering Eric Rebentisch meeting

→

#

Transition to manufacturing

→

#

Tom Toner

→

#

Concept to launch process typically 3-5 years

→

#

Integrated Development Teams

→

#

Project organization structure

→

#

Design for X strategies

→

#

Design for manufacturing, sourcing, etc

→

#

Keeping head count minimal seems relevant to this problem

→

#

As with all organizational problems

→

#

Mythical man month

→

#

Designers should be the integrators

→

#

As opposed to the partners / suppliers handling any integration

→

#

System engineering vs supply chain management

→

#

Seems to be an extension of Product development process

→

#

Or he says sticking to pdp is the best bet

→

#

IP risk

→

#

Ideally, you outsource the high IP risk equipment and processes less

→

#

key role for the system engineer to make these decisions

→

#

What percent of your effort was for protecting IP?

→

#

collapsed:: true

For new tech, maybe 5%, up to 10%

→

#

Possible government could have a role in this

→

#

Is there some way to remove the need for companies to worry about protecting IP ?

→

#

Seems like this would require a strong intellectual property conception from government

→

#

At first right, this seems difficult and perhaps unproductive

→

#

Maybe some new social conception of property

→

#

Society owns everything?

→

#

Aren’t patents supposed to manage this? Why are they insufficient?

→

#

Maybe a new type of patent that is lower barrier but offers some protection

→

#

An org defines what they are doing, and has some gradually expiring right to make money of anyone doing something similar

→

#

This could even be cumulative

→

#

Every new tech and process builds off of this history of IP and divided up revenue into a tree of technology history

→

#

Kind of like sampling songs that sample other songs

→

#

Everyone in the chains gets a piece of the pie

→

#

Interesting idea, give it a name

→

#

There should be a global graph of organizational processes and technologies

→

#

Every organization publishes their technologies and processes and references other technologies and processes

→

#

Revenue should flow up this tree of references, with some expiring function

→

#

This should take care of IP risk

→

#

Government may need to provide some processes for free

→

#

Andy Grove INTEL

→

#

Only the paranoid survive

→

#

The decisions here are similar to how software companies integrate as well

→

#

eg

→

#

White box vs black box sdks

→

#

Seems like everything needs to have a clear interface to lubricants this transition

→

#

Atomicizing to

→

#

protect IP risk,

→

#

simplify sourcing,

→

#

make redundant sourcing possible

→

#

Simplify integration

→

#

Teaching this detached from a specific context feels hard to really digest

→

#

Good that Tom Toner is presenting from his experience, at least

→

#

EM.411 meeting System Engineering

→

#

Eric Rebentisch

→

#

Is number of parts a good surrogate for complexity ?

→

#

What about size of team required?

→

#

Couldn’t parts be chunked groupings of more granular parts?

→

#

Iteration and recursion are inherent to System Engineering

→

#

progress from simple to detailed, approximate to precise, risky to acceptable

→

#

Feels like Agile development will follow naturally from this

→

#

The diagram looks like the workflows I built on jira

→

#

Maybe SDM should have a joint lecture from the professors to transition between the phases, might make for a very useful way to get aligned on how the different phases interface.

→

#

Product development process

→

#

→

#

Four “primary enterprise processes” for systems

→

#

Customer acquisition

→

#

Product development

→

#

Product realization (fulfillment, sales)

→

#

Customer support

→

#

Goals

→

#

Market fit

→

#

Business case

→

#

make money

→

#

Risk

→

#

balance

→

#

Resources

→

#

prioritize and allocate

→

#

Visibility

→

#

on status of development

→

#

Phases

→

#

Think about n+3 at the concept phase

→

#

Not today’s product, but the product three iterations out

→

#

Think about n+2 at the specify phase

→

#

Seems like Agile development sits in contrast to this

→

#

The difference between one-off vs iterative product development seems like it will determine how you want to hybridize between Product development process and Agile development

→

#

speaking specifically about more waterfall versions of Product development process I think

→

#

System engineering effort vs cost study by Eric Honour INCOSE

→

#

ROI maximizes when around ~15% of program costs are dedicated to system engineering

→

#

EM.411 meeting Eric Rebentisch System Engineering

→

#

Interface

→

#

Interface design

→

#

Speaking is an interface between two brains

→

#

Interfaces have Layers of abstraction

→

#

NPR radio -> listener

→

#

Human language

→

#

Satellite communication

→

#

Interfaces might also contain multiple sub-interfaces

→

#

Implies that systems are made up of sub-systems

→

#

Is a sub system different from a module ?

→

#

I suspect it’s only semantic

→

#

A system can be represented as a network

→

#

An interface is a connection in the network

→

#

Can show connections through a DSM

→

#

DSM

→

#

DSM of DSMs is a multi domain matrix

→

#

Really a data visualization tool

→

#

dsmweb.org

→

#

A fully populated DSM is a poorly designed system, I think

→

#

Sparsity

→

#

Off diagonal clusters represent connective modules between clusters / modules

→

#

What systems are not themselves interfaces ?

→

#

Again thinking of systems as a set of inputs and outputs

→

#

Common interfaces enable modularity

→

#

Modular Design

→

#

The spectrum of consumer modularity

→

#

Modular phone failed

→

#

Google project Ara phone

→

#

Too commoditized, operating too much at the margin of performance already

→

#

Framework Modular laptop

→

#

Might work? TBD

→

#

Modular desktop

→

#

Very standard

→

#

Modularity for consumers is different than modularity for producers

→

#

Internal API modularity can be about reducing maintenance or future iteration cost

→

#

Interfaces are handoffs

→

#

How does user experience plug in with all this talk of interfaces?

→

#

→

Search Results

System Engineering

↑ 19 References