U. J o h n Tan i k P h .D. Apri l 2 014 SOF.docx

U. J o h n Tan i k
P h .D.
Apri l 2 014
SOFT WARE/SYSTEMS
ENGINEERING DESIGN PROCESS
C Y B E R - P H Y S I C A L S Y S T E M S A P P L I C AT I
O N S U T I L I Z I N G
B I G DATA A N D T H E S E M A N T I C W E B
- m o d e l
n d g r a d u a t e w o r k )

t r i x
g e ( S W E B O K )
- I E E E 8 3 0
- I E E E 1 0 1 6
- I E E E 1 0 5 8
g e ( U M L )
- p h y s i c a l s y s t e m s
o n

e b
S S )
2
OVERVIEW
Assistant Professor of Software/Systems Engineering
award to Dept for ABET
Accreditation success in curriculum development
-physical Sys tems book published
nts panelist for NSF
Management
l l S p a c e F l i g h t C e n t e r )
Automated Design Sys tems book published

from Bell labs
UA B )
p)
and Process Science Conference
i d e n t i a l S c h o l a r s h i p )
3
ACADEMIC BACKGROUND
ay
4
NASA OUTREACH
STEM TEACHING AND R&D

5
V-MODEL DESIGN PROCESS
Validation: Make sure specifications meet customer need
Verification: Make sure system meets engineering specifications
An overall design process is needed for hardware and software
engineering co-design traceability
6
A FAMOUS CARTOON (NEED FOR V&V)
7
V-MODEL DESIGN PROCESS
FOR STUDENT TEAMS
Fig. 1 V-model
for systems engineering
Fig. 3 V-model
for software engineering
Fig. 2 V-model
Showing parallel flow

An industrial approach to design is needed for student teams.
V-model approach to design is an excellent overview for
students
interested in following a structured methodology to product
development
and innovation.
http://memnorthwestern.wordpress.com/2012/09/25/systems-
thinking-in-the-mem-program/
http://www.ops.fhwa.dot.gov/publications/fhwahop13013/ch2.ht
m
http://en.wikipedia.org/wiki/V-Model_(software_development)

http://www.ops.fhwa.dot.gov/publications/fhwahop13013/ch2.ht
m
8
DESIGN PROCESS
GENERAL PHASES
A logical way to divide the design process is to divide
work into phases that students follow during R&D
- s c al e So f t ware / s y s E n g i n e e ri n g wi t h
1 + te ams
– Software Life Cycle
Processes", is a
standard that establishes a common framework for software life
cycle

process.
- s i ze So f t war e / s y s E n g i n e e ri n g wi t h 1
te am
Process) is a
popular iterative and incremental sof tware development process
framework (Refined Unified Process called Rational Unified
Process)
9
SOFT WARE ENGINEERING
STANDARDS AND SCOPING
Standards and scoping are needed to systematize
and manage the engineering process
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
10
IEEE 1 2207 LIFE -CYCLE
FOR LARGE SCALE SYSTEMS
High-level view for large-scale system

development is helpful.
Student project teams may utilize RUP for
practical work applications in class, for
startups, or for medium-size companies, but
they should also be exposed to industry
standards like IEEE 12207 to understand
their work product in context of major
corporate or government goals.
http://www.teachengineering.org/view_lesson.php?url=collectio
n/uno_/l
essons/uno_curiosity/uno_curiosity_lesson01.xml
n/uno_/lessons/uno_curiosity/uno_curiosity_lesson01.xml
11
RATIONAL UNIFIED PROCESS (RUP)
RUP is a manageable design life-cycle methodology for students

project teams.
Inception phase
- IEEE 830 Software requirements specification (SRS)
Elaboration phase
- IEEE 1016 Software Design Description (SDD)
Construction phase
- IEEE 1058 Project Management Plan (PMP)
Transition phase
- Deployment
http://www.ibm.com/developerworks/library/ws-soa-term2/
n/uno
_/lessons/uno_curiosity/uno_curiosity_lesson01.xml

12
RUP AND IEEE 1 2207 COMPARED
● Green:
The RUP provides in-depth coverage of this area.
● Yellow:
The RUP provides some coverage,
● Red:
The RUP does not provide anything significant in this area,
beyond very general elements such as reviews, principles,
and some techniques.
http://www.ibm.com/developerworks/rational/library/content/Ra
tio
nalEdge/aug02/ISORUPAug02.pdf
Comparison

RUP and IEEE 12207 are compatible.
A developer can use RUP and still meet the
criteria specified in IEEE 12207. The IEEE 12207
is more of a framework for software process
providing guidance on what activities must be
performed and what artifacts must be generated.
RUP is also this, but more. RUP is also a software
development process framework telling a
developer what to do, but it also comes with a
standard implementation that tells a developer
how to do it.
tionalEdge/aug02/ISORUPAug02.pdf
tionalEdge/aug02/ISORUPAug02.pdf
I n ord e r to d e s i gn a s y s te m i nvol v ing h ard ware and s
of t ware , a
formal and s y s te mat ic d e s ign t h e or y s i mp lifies t h
e ap p roac h for
l arg e - s cale s y s tems.

- A x i omat ic De s i g n T h e or y
- Developed at MIT with support tools available in industr y
(Dr. Suh)
- Provides a methodology of axioms to reduce design risk at the
inception stage (information/independence axiom)
- Determines optimal assignment of design parameters to
functional
requirements for hardware/software co -design
13
AXIOMATIC DESIGN PROCESS
OVERVIEW
d s o f t w a r e d e s i g n c o n s i d e r a t i o n s i s n e e d
e d .
specifying the customer needs,
expectations, design specifications

etc.
whic h will satisfy ever y
item of the customer domain;
r actual
designed components whic h
satisfy the functional requirements; and
ac hieve the design
parameter s.
14
AXIOMATIC DESIGN PROCESS
FOR HARDWARE/SOFT WARE CO -DESIGN
http://www.axiomaticdesign.com/technology/ADSChapter5.html
Functional Domain Physical Domain
FR

FR1 FR2 FR3
FR11 FR12 FR21
FR4
FR22 FR23 FR41 FR42
FR421 FR422 FR423
Step 1
DP
DP1 DP2 DP3
DP11 DP12 DP21
DP4
DP22 DP23 DP41 DP42
DP421 DP422 DP423
Step
2
Step 3
Step 4
Step 5
St
ep

6
Step 7
15
HIERARCHICAL DECOMPOSITION
A method to breakdown FR and fulfill them with DP is needed.
Customer domain is realized in physical domain by Design
Parameters (DP).
SRS and SDD were populated this way in student project work.
16
DESIGN MATRIX
Design Matrix trade-off analysis and reconfiguration
(FR/DP decomposition)
A layout to easily see the mapping between FR and DP is
needed for traceability purposes.
17
DESIGN STRUCTURE MATRIX

System interactions analyzed with Design
Structure Matrix (DSM)
Once a design
matrix is completed,
a method to analyze
the interactions
between DP is
helpful for design
improvement.
Color-coded
component
interactions
(e.g. information,
temperature,
mechanical
exchange)
Risk assessment
made based on

TRF multipliers
p l e te , m o d u l e i n te r a c t i o n s
w e r e v i s u a l i z e d by A c c l a r o to o l .
18
MODULE INTERACTIONS
Module Interactions derived from matrix
19
DESIGN RANGE
VS SYSTEM RANGE
http://www.axiomaticdesign.com/technology/axiomatic.asp
http://phys.org/news/2012-07-matrix-analysis-product-simple-
square.html
Design range vs system range (DP) System range (DP) shifting
with temperature

Axiomatic design provides a mathematical approach to
determining how well
the component system range fits a certain functional
requirement.
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
20

TOOL SCREENSHOT S FOR DESIGN SUPPORT
https://www.palisade.com/decisiontools_suite/6/WhatsNew.asp
http://www.dfss-software.com/dfss_features_qfd.asp
21
SOFT WARE ENGINEERING BODY OF
KNOWLEDGE (SWEBOK)
Any time a project is developed in R&D, it is important to have
a common terminology and
understanding of a profession, such as software engineering.
1 . So f t war e Re q ui re me n t s
2 . So f twar e De s i gn
3 . So f t war e Co n s t ruc t i o n
4 . So f t war e Te s t i n g
5 . So f t war e M ai n te n an c e
6 . So f t war e Co n fi g urat i o n M an ag e m e n t

7 . So f twar e En gi n e e ri n g M an age m e n t
8 . So f t war e E n g i n e e ri n g P ro c e s s
9 . So f t war e E n g i n e e ri n g M o de l s an d M et h o ds
1 0 . So f t war e Q ual i t y
1 1 . So f t war e E n g i n e e ri n g P ro fe s s i o n al P rac t
i c e
1 2 . So f twar e En gi n e e ri n g Ec o n o mi c s
1 3 . Co mput i n g Fo un dat i o n s
1 4 . M at h e mat i c al Fo un dat i o n s
1 5 . E n g i n e e ri n g Fo un dat i o n s
22
SWEBOK KNOWLEDGE AREAS (KA 1 -15)
http://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK
_Guide#SWEBOK_Guide_Version_3
23
KA -1 SOFT WARE REQUIREMENTS

Software Requirements
The Software Requirements KA is concerned with the
elicitation, negotiation, analysis, specification, and validation
of software requirements. It is widely
acknowledged within the software industry that software
engineering projects are critically vulnerable when these
activities are performed poorly.
Software requirements express the needs and constraints placed
on a software product that contribute to the solution of some
real-world problems.
Student team project focus: IEEE 830 Software Requirements
Specification (SRS)
elicitation
and
analysis
24
S O F T WA R E R E Q U I R E M E N T S S P E C I F I C AT
I O N ( S R S )
I E E E 8 3 0 D O C U M E N TAT I O N ( K A - 1 )
http://www.dfss-software.com/dfss_features_qfd.asp
QFD and customer needs analysis yields performance
considerations e.g.

- FR
- NFR
25
HOUSE OF QUALIT Y (KA -1)
https://www.palisade.com/decisiontools_suite/6/WhatsNew.asp
QFD was
utilized during
requirements
elicitation to
produce a
House of
Quality.
KA -2 SOFT WARE DESIGN
Software Design
Design is defined as both the process of defining the
architecture, components, interfaces, and other characteristics
of a system or component and the

result of [that] process (IEEE 1991). The Software Design KA
covers the design process and the resulting product. The
software design process is the
software engineering life cycle activity in which software
requirements are analyzed in order to produce a description of
the software’s internal
structure and its behavior that will serve as the basis for its
construction. A software design (the result) must describe th e
software architecture - that
is, how software is decomposed and organized into components
and the interfaces between those components. It must also
describe the components
at a level of detail that enables their construction.
Student team project focus: IEEE 1016 Software Design
Description (SDD)
26
SWEBOK
provides
formal
definitions of
the
architecture,

components,
and
interfaces of
a system
S O F T WA R E D E S I G N D E S C R I P T I O N ( S D D )
I E E E - 1016 D O C U M E N TAT I O N ( K A - 2 )
The SDD-IEEE 1016 provides
many views of the design
including analytic results found
in the design matrix and DSM.
UML Diagrams are also
provided here in our projects.
square.html
Fig. 4 Design Matrix trade-off analysis

(FR/DP decomposition)
Fig. 1 Design range vs system range (DP)
Fig. 3 Module Interactions derived from matrix
Fig. 2 System interactions analyzed with Design
Structure Matrix (DSM)
27
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html
square.html

square.html
square.html
APPLICATION/FUNCTIONAL
ARCHITECTURE VIEW (KA -2)
Visio was used to
map technology –
independent
functional
requirements to
SRS v1
http://visualstudiogallery.msdn.microsoft.com/237f823c-45b4-
4f1f-b9e2-607fe66eaae7
28
INFORMATION/ANALY TIC

FR/DP Design trade-off analysis DP/DP Component interaction
analysis
29
laro DFSS tool scopes large system
-scale
system
SYSTEMS/MODULAR
30 We used the systems architecture view to verify that the
system has met all the functional and nonfunctional
requirements.
s of t ware
Di ag rams

d e fi ned
h ard ware
Di ag rams
d e fi ned
OBJECT ORIENTED/STRUCTURAL
http://bulldozer00.com/uml-and-sysml/ 31
KA -7 SOFT WARE ENGINEERING
MANAGEMENT
Software Engineering Management
Software engineering management involves planning,
coordinating, measuring, reporting, and controlling a project or
program to ensure
that development and maintenance of the software is systematic,
disciplined, and quantified. The Software Engineering
Management KA

covers initiation and scope definition (determining and
negotiating requirements, feasibility analysis, and review and
revision of
requirements); software project planning (process planning,
estimation of effort, cost, and schedule, resource allocation, risk
analysis,
planning for quality); software project enactment (measuring,
reporting, and controlling; acquisition and supplier contract
management);
product acceptance; review and analysis of project performance;
project closure; and software management tools.
Student team project focus: IEEE 1058 Project Management
Plan (PMP)
32
VERSION CONTROL
AND COST ESTIMATION (KA -7 )
http://www.dtbusiness.com/index-1.html
33 Institute for Human-Machine Cognition (IHMC)

Concept maps with IHMC
P R O J E C T M A N AG E M E N T P L A N ( P M P )
I E E E - 10 5 8 D O C U M E N TAT I O N ( K A - 7 )
Basecamp tool for virtual collaboration Gantt Chart for project
management
34
1 . So f t war e Re q ui re me n t s
2 . So f twar e De s i gn
3 . So f t war e Co n s t ruc t i o n
4 . So f t war e Te s t i n g
5 . So f t war e M ai n te n an c e
6 . So f t war e Co n fi g urat i o n M an ag e m e n t
7 . So f twar e En gi n e e ri n g M an age m e n t
8 . So f t war e E n g i n e e ri n g P ro c e s s
9 . So f t war e E n g i n e e ri n g M o de l s an d M et h o ds
1 0 . So f t war e Q ual i t y

1 1 . So f t war e E n g i n e e ri n g P ro fe s s i o n al P rac t
i c e
1 2 . So f twar e En gi n e e ri n g Ec o n o mi c s
1 3 . Co mput i n g Fo un dat i o n s
1 4 . M at h e mat i c al Fo un dat i o n s
1 5 . E n g i n e e ri n g Fo un dat i o n s
SWEBOK KNOWLEDGE AREAS (KA 1 -15)
35
Project teams reviewed the standards
found in all the other areas to make
sure system was built to industry
specifications.
36
DESIGN PRINCIPLES AS FOUNDATION
FOR APPLICATIONS

Software/systems engineering of complex systems
(Industrial Internet Applications include CPS and Big
Data/Semantic Web)
2014
37
INDUSTRIAL INTERNET APPLICATIONS
C O N V E R G E N C E O F C P S A N D B I G D ATA
file:///C:/Users/Owner/Desktop/Research%202014/Industrial%2
0internet/Industrial_Internet.pdf
38
INDUSTRIAL INTERNET
IMPACT ($32.3 TRILLION)
Focus on healthcare applications: $1.7 trillion
file:///C:/Users/Owner/Desktop/Research%202014/Industrial%2
0internet/Industrial_Internet.pdf

ode, which is focused on maintaining health
39
P4 MEDICINE
A P P LY I N G I N D U S T R I A L I N T E R N E T T O S
Y S T E M S B I O LO GY
- me d ic al
of billions of health-
relevant data points will
surround each
individual.

each individual.
40
CPS/BIG DATA/SEMANTIC WEB
IN P4 MEDICINE
http://www.nature.com/news/medicine-gets-up-close-and-
personal-1.14702
CPS bio-sensors and bio-samples provided for Big Data
analytics and Semantic Web development.
&T/Ericsson) –Industrial Internet Roadmap
development with AT&T
Engineer, AT&T Foundr y
Palo Alto, California, United States
—physical systems/Big
Data/Semantic Web

-based explorator y research with undergrad students
d research with grad students (Wolfram products)
- Austin,
etc)
apan, Brazil, etc)
-up venture suppor t for students (Innovation triangle –
Academia/Research/Community)
EXPLORING CYBER -PHYSICAL SYSTEMS AND
BIG DATA APPLICATIONS OF SEMANTIC WEB

42
WOLFRAM
CONNECTED DEVICES PROJECT
This will enable development of CPS and Big Data analytics
with CDSS
that utilize biosensors selected from 2000 devices and 300
companies.
43
WOLFRAM
SYSTEM MODELER
MODELING/SIMULATION
After designing a system, it is important to be able to model and
simulation its function.
44
WOLFRAM
DISCOVERY PLATFORM

45
SEMANTIC WEB
DATA LAYERS (EXAMPLE)
http://semanticweb.com/semantic-web-impact-on-enterprise-
software-part-2_b707
ARCHITECTING AUTOMATED DESIGN SY STEMS
BOOK PUBLISHED 2006
46
My first foray into
CPS and
Semantic Web
while working on
my PhD with
NASA Fellowship.
APPLIED CYBER -PHY SICAL SY STEMS
BOOK PUBLISHED 2014

47
AIDF introduced in 2006 leading to CPSDAF in 2014
Marketing and Business Capture
Gathering real-world Informal requirements
Program Office Support/Systems Integration
Managing tracking, quality, configuration, risk, schedules,
performance, data, integration
Project Management
Planning, initiating, monitoring, controlling, closing technical
effort,
Requirements & Architecture
Development
Define system level
architecture requirements
addressing real-world needs
Product Design &
Development
Detailed design

coding, testing
Systems Integration
& Test
Integrate, verify,
validate system
Deployment &
Transition
Plan, train, demonstrate,
and transition system
Operations &
Maintenance
Provided continuous
tech support
SYSTEM DEVELOPMENT TIME-TABLE
From project inception to completion
S
Y
S
T

E
M
D
E
V
E
L
O
P
M
E
N
T
F
L
O
W
F
ro
m
r
e
a
l-

w
o
rl
d
n
e
e
d
t
o
d
e
p
lo
y
m
e
n
t
Real-world need
Deployment
Project inception Project Completion
based on Tufts' Systems Engineering Process Model effective

September 1, 2003
(INCOSE G2SEBOK 3.40 handbook http://g2sebok.incose.org/)
Systems Engineering Product Lifecycle Model
Iteration
AIDF research leading to CPSDAF
Tufts’ Systems Engineering Process Model [INCOSE
G2SEBOK 3.40, 2003]
48
The focus of my
initial research
was on
architecture
development that
utilized Semantic
Web.
Architecture
Framework
FR/DP Design Matrix

for configured KBE SoS
P
a
re
n
t
L
e
v
e
l
F
u
n
c
ti
o
n
a
l
R
e
q
u

ir
e
m
e
n
ts
(
F
R
)
L
e
a
f-
le
v
e
l
F
u
n
c
ti
o

n
a
l
R
e
q
u
ir
e
m
e
n
ts
(
F
R
)
Parent Level
Design Parameters (DP)
Leaf-level
Design Parameter (DP)
Requirements Implementation
Based on configured FR/DP design matrix

A
g
e
n
t N
e
tw
o
rk
e
d
In
te
g
ra
tio
n
P
ro
c
e
s
s

Validated Architecting Process for KBE SoS
with Axiomatic Design for Six Sigma IDOV methodology
F
u
n
c
ti
o
n
a
l
R
e
q
u
ir
e
m
e
n
ts
M
a

p
p
e
d
t
o
R
e
a
l-
w
o
rl
d
n
e
e
d
s
Design parameters
Verified by IDOV methodology
Q
u
a

li
ty
f
u
n
c
ti
o
n
D
e
p
lo
y
m
e
n
t
(I
S
O
) F
a
ilu

re
M
o
d
e
a
n
d
E
ffe
c
ts
A
n
a
ly
s
is
A
x
io
m
a
ti

c
D
e
s
ig
n
D
e
s
ig
n
S
tru
c
tu
re
M
a
trix
Axiomatic Design
Real-world needs
based on ISO/IEC 9126
DFSS DFSS

Hierarchical
Decomposition
H
ie
ra
rc
h
ic
a
l
D
e
c
o
m
p
o
s
itio
n
FR maps to OO Method Coding
Large-scale Software Engineering Process
For KBE SoS Development

Modular integration with networked intelligent agents
based on object-oriented design methodology
Architected KBE SoS Deployment
with GAURDS Validation Framework
Scope of Thesis
Architecture-driven software engineering
for KBE System-of-Systems (SoS)
Output
KBE SoS
A R C H I T E C T U R E F R A M E W O R K T O C O N F I
G U R E K N O W L E D G E
B A S E D E N G I N E E R I N G ( K B E ) S Y S T E M O F
S Y S T E M S ( S O S )
49
Research focus is to develop an architecture framework to
automate the design process.
c k s
n e )

l o b a l k n o w l e d g e
)
n e )
CYBER -PHYSICAL SYSTEM
DESIGN AUTOMATION FRAMEWORK
Centralized Knowledge Assimilation Unit
(CKAU) Blackboard
Semantic Web
Services
Design Environment
Current User Project Input Global Knowledge Input
AI KB
Domain

KB
Design
KB
Validation
KB
Project
Database
Designer Environment
AIDF
Task GUI
Analytic Task Method (ATM) Synthetic Task Method (STM)
CL ASM DI MO PR DE MOD PL SC AST
TRIZ
DSM
MLH
FTA
RBD
FMEA

ETP
QFD
TRF
OPT
ADT
F
u
n
ct
io
n
al
L
ay
er
D
es
ig
n
M
o
d
u

le
L
ay
er
DRS
PLS
FLS
NNS
ARS
GAS
CTS
CBR
A
ID
F
G
lo
ba
l D
is
tr

ib
ut
ed
G
U
I
D
ata T
ransfer B
us (D
T
B
)
K
no
w
le
dg
e
T
ra
ns
fe

r
B
us
(
K
T
B
)
Knowledge Assimilation Engine (KAE)
Knowledge Correlation Engine (KCE)
Knowledge Justification Engine (KJE)
K
no
w
le
dg
e
A
llo
ca
tio
n
B

us
(
K
A
B
)
K
no
w
le
dg
e
V
al
id
at
io
n
U
ni
t (
K
V
U

)
D
ata V
alidation U
nit (D
V
U
)
MO
D
ata A
llocation B
us (D
A
B
)
CommonKADS Task Determination Unit (CTDU)
Analytic Subtask 1,2,3...N Synthetic Subtask 1,2,3...N
AI Design Task Manager (ADTM)
I-Agents
User Task

Management
Authentication
AI Design Engine Block (ADEB)
Design Engine Block AI Engine Block
M1D
M2D
M3D
M4D
M5D
M6D
M7D
M8D
M9D
M10D
M11D
M1A
M2A
M3A

M4A
M5A
M6A
M7A
M8A
M9A
A
I M
o
d
u
le
L
ay
er
DMS
MO
MO
MO
MO MOController

ModelView
Justifiable Recommendations
AIDF Visualization GUI
In
p
u
t
P
h
as
e
U
se
r
T
as
ks
I-T1
I-T2
I-T3
I-T4

I-T5
I-T6
I-T7
I-T8
I-T9
I-T10
I-T11
...
I-TN
P
ro
ce
ss
in
g
P
h
as
e
U
se

r
T
as
ks
P-T1
P-T2
P-T3
P-T4
P-T5
P-T6
P-T7
P-T8
P-T9
P-T10
P-T11
P-T12
O
u
tp

u
t
P
h
as
e
U
se
r
T
as
ks
O-T1
O-T2
...
O-TN
P-T13
P-T14
P-T15
P-T16
P-T17

P-T18
...
P-TN
S1 Active
S2 Active
N/D
S3 Active
S2/S3 Active
S1/S2/S3
S1/S2 ActiveLegend
U
se
r-
A
ID
F
In
te
rf
ac
e
–

M
o
d
el
V
ie
w
C
o
n
tr
o
lle
r
(M
V
C
)
Artificial Intelligence Design Framework
(AIDF) Architecture Model
A
ID
F

-G
lo
b
e
In
te
rf
ac
e
–
B
ac
ke
n
d
S
em
an
ti
c
W
eb
S
er

vi
ce
s
IA-1
IA-2
IA-3
...
I-TN
AI-1
Ai-2
AI-3
...
AI-N
AI/KBE
DE
D-1
D-2
D-3
...

D-N
Disciplinary
DE
De-1
De-2
De-3
...
De-N
V-1
V-2
V-3
...
V-N
Design
DE
Validation
DE
Globally Distributed

Domain Experts (DE)
G
lo
ba
l K
no
w
le
dg
e
R
ep
os
ito
ry
o
n
W
W
W
WORLDUSER
W
eb

S
er
vi
ce
s
Semantic
Web
Domain Expert Environment
(CKAU) Correlation Engine
Modular expansion capability
Framework
Level
Block
Level
Engine
Level
Module

Level
Element
Level
D
ri
ll
in
g
d
o
w
n
t
o
e
le
m
e
n
t
le
v
e

l
Perspectives of the AIDF
With Hierarchical Decomposition
50
CPS design automation framework is a useful
guide to development of CPS applications.
- m o d e l
e s i g n a
n d g r a d u a t e w o r k )
e s i g n M a t r i x
g e ( S W E B O K )
S R S - I E E E 8 3 0

- I E E E 1 0 1 6
- I E E E 1 0 5 8
g L a n g u a g e ( U M L )
- p h y s i c a l s y s t e m s
u t o m a t i o n
e b
S S )
51
OVERVIEW REVISITED

THANK YOU – QUESTIONS?
52
EXTRA SLIDES
53
i nformat ic s/ engineering top i c s s uc h as C DSS, ST E M,
N A SA
Di g i t al A s t ronaut p roj e ct
H E A LT H C A R E I N FO R M AT I C S L I T E R AT U R
E FO R C D S S
http://www.docstoc.com/docs/86256876/NASA-and-the-Future-
of-Medical-Informatics
http://www.springer.com/public+health/book/978-0-387-33914-
6
4
http://www.barnesandnoble.com/w/clinical-decision-support-
systems-eta-s-

berner/1101309314?ean=9780387985756
54
6
6

6
6
6
6
6
6
6
4
4
4
4
4
4
4
4
4
systems-eta-s-berner/1101309314?ean=9780387985756

UML/SYSML COMPARISON
55
and
c omp one nt d i agrams p rovi d es b as i s for d et ailed OO d
e s i gn

e fi ned for s of t ware
/hardware
OBJECT ORIENTED DIAGRAMS
DETAILED DESIGN SPECS
56
UNIFIED MODELING LANGUAGE (UML)
Fig. 1 UML/SysML design patterns Fig. 2 UML/SysML
evolution history
Fig. 3 UML structure and behaviour diagrams
57
Knowledge Intensive Task
Analytic Task Synthetic Task
Classification
Assessment
Diagnosis
Monitoring
Prediction
Design

Modeling
Planning
Scheduling
Assignment
C O M M O N K A D S S TA N DA R D I Z E D
TA S K S FO R K B E S O S
Common Knowledge Acquisition and Design Support (KADS)
standard for intelligent systems
http://www.commonkads.uva.nl/frameset-commonkads.html
58
F I N A L P R O J E C T S U B M I S S I O N
F O R A S O F T WA R E / SY S T E M S P R O J E C T
B A S E D O N S Y L L A B U S D E V E L O P E D AT P U
R D U E F W
M i n i m u m R e q u i r e d D e l i v e r a b l e s l i s t b a s e
d o n m y s o f t w a r e e n g i n e e r i n g s y l l a b u s ( T
e a m B i n d e r a n d C D )

n c l u d i n g C o n c e p t m a p i n H T M L & C m a p t o
o l s f o r m a t )
P e r s o n a l s k i l l s / i n t e r e s t s s h e e t s
m e n t )
b . I n f o r m a t i o n a r c h i t e c t u r e
m s w i t h b e h a v i o r d i a g r a m s )
t o p - l e v e l F R l i s t f r o m A p p
A r c h ( I E E E 8 3 0 f o r m a t )
o r a n y f e a t u r e s u s e d
- F R / D P
- D P / D P

f o r m a t , w e e k l y f r o m e a c h m e m b e r )
e v i e w s K A - 1 t h r
u 1 1
v i d u a l w o r k ( e . g . E x a m s I & I I ,
H W , e t c )
o u r P M P d e l i v e r a b l e s t a b l e , e . g . f e a s i b i l
i t y )
o r m a t
59
KA - 8 SOFT WARE ENGINEERING

PROCESS
Software Engineering Process
The Software Engineering KA is concerned with definition,
implementation, assessment, measurement, management, and
improvement of
software life cycle processes. Topics covered include process
implementation and change (process infrastructure, models for
process
implementation and change, and software process management);
process definition (software life cycle models and processes,
notations for
process definition, process adaptation, and process automation);
process assessment models and methods; measurement (process
measurement, products measurement, measurement techniques,
and quality of measurement results); and software process tools.
Student team project focus: Axiomatic Design and RUP
60
KA -9 SOFT WARE ENGINEERING TOOLS AND
METHODS
Software Engineering Methods
The Software Engineering Methods KA addresses methods that
encompass multiple life cycle stages; methods specific to

particul ar life
cycle stages are covered by other KAs. Topics covered include
modeling (principles and properties of software engineering
mod els; syntax
vs. semantics vs. invariants; preconditions, post-conditions, and
invariants); types of models (information, structural, and
behavioral
models); analysis (analyzing for correctness, completeness,
consistency, quality and interactions; traceability; and tradeoff
analysis); and
software development methods (heuristic methods, formal
methods, prototyping methods, and agile methods).
Student team project focus: Acclaro, RUP, COMET, Virtual
Collaboration tools
61
KA -10 SOFT WARE QUALIT Y
Software Quality
Software quality is a pervasive software life cycle concern that
is addressed in many of the SWEBOK V3 KAs. In addition, the
Software Quality KA
includes fundamentals of software quality (software engineering
cultures, software quality characteristics, the value and cost of
software quality,

and software quality improvement); software quality
management processes (software quality assurance, verification
and validation, reviews and
audits); and practical considerations (defect characterization,
software quality measurement, and software quality tools).
Student team project focus: Risk mitigation with House of
Quality: QFD, FMEA, PRA, etc
62
Knowl e dge A re as C h arac terizing t h e p rofe ss ional p
rac t i ce and
E d u c at ional Re qu i rement s of Sof t ware E ng i neering
- 1 1 S o f t w a r e E n g i n e e r i n g P r o f e s s i o
n a l P r a c t i c e
c t i c e i s c o n c e r n e d w i t h t h e k n o w l e d g e , s
k i l l s , a n d a t t i t u d e s t h a t s o f t w a r e e n g i n e
e r s
m u s t p o s s e s s t o p r a c t i c e s o f t w a r e e n g i n e
e r i n g i n a p r o f e s s i o n a l , r e s p o n s i b l e , a n d
e t h i c a l m a n n e r . T h e S o f t w a r e E n g i n e e r i n
g
P r o f e s s i o n a l P r a c t i c e K A c o v e r s p r o f e s s
i o n a l i s m ( p r o f e s s i o n a l c o n d u c t , p r o f e s s i
o n a l s o c i e t i e s , s o f t w a r e e n g i n e e r i n g
s t a n d a r d s , e m p l o y m e n t c o n t r a c t s , a n d l e
g a l i s s u e s ) ; c o d e s o f e t h i c s ; g r o u p d y n a m

i c s ( w o r k i n g i n t e a m s , c o g n i t i v e p r o b l e m
c o m p l e x i t y , i n t e r a c t i n g w i t h s t a k e h o l d e
r s , d e a l i n g w i t h u n c e r t a i n t y a n d a m b i g u i
t y , d e a l i n g w i t h m u l t i c u l t u r a l e n v i r o n m e
n t s ) ;
a n d c o m m u n i c a t i o n s k i l l s .
- 1 2 S o f t w a r e E n g i n e e r i n g E c o n o m i c
s
A i s c o n c e r n e d w i t h m a k i n g d e c i s i o n s w i t
h i n t h e b u s i n e s s c o n t e x t t o a l i g n t e c h n i c
a l
d e c i s i o n s w i t h t h e b u s i n e s s g o a l s o f a n o
r g a n i z a t i o n . T o p i c s c o v e r e d i n c l u d e f u n
d a m e n t a l s o f s o f t w a r e e n g i n e e r i n g
e c o n o m i c s ( p r o p o s a l s , c a s h f l o w , t h e t i m
e - v a l u e o f m o n e y , p l a n n i n g h o r i z o n s , i n f
l a t i o n , d e p r e c i a t i o n , r e p l a c e m e n t a n d
r e t i r e m e n t d e c i s i o n s ) ; n o t f o r - p r o f i t d e c
i s i o n - m a k i n g ( c o s t - b e n e f i t a n a l y s i s , o p t
i m i z a t i o n a n a l y s i s ) ; e s t i m a t i o n , e c o n o m
i c
r i s k a n d u n c e r t a i n t y ( e s t i m a t i o n t e c h n i q
u e s , d e c i s i o n s u n d e r r i s k a n d u n c e r t a i n t
y ) ; a n d m u l t i p l e a t t r i b u t e d e c i s i o n m a k i
n g
( v a l u e a n d m e a s u r e m e n t s c a l e s , c o m p e n s
a t o r y a n d n o n - c o m p e n s a t o r y t e c h n i q u e s )
.
- 1 3 C o m p u t i n g F o u n d a t i o n s
u n d a m e n t a l t o p i c s t h a t p r o v i d e t h e c o m p
u t i n g b a c k g r o u n d n e c e s s a r y f o r t h e p r a c t

i c e
o f s o f t w a r e e n g i n e e r i n g . T o p i c s c o v e r e d
i n c l u d e p r o b l e m s o l v i n g t e c h n i q u e s , a b s
t r a c t i o n , a l g o r i t h m s a n d c o m p l e x i t y ,
p r o g r a m m i n g f u n d a m e n t a l s , t h e b a s i c s o f
p a r a l l e l a n d d i s t r i b u t e d c o m p u t i n g , c o m
p u t e r o r g a n i z a t i o n , o p e r a t i n g s y s t e m s ,
a n d n e t w o r k c o m m u n i c a t i o n .
- 1 4 M a t h e m a t i c a l F o u n d a t i o n s
r s f u n d a m e n t a l t o p i c s t h a t p r o v i d e t h e m
a t h e m a t i c a l b a c k g r o u n d n e c e s s a r y f o r t h
e
p r a c t i c e o f s o f t w a r e e n g i n e e r i n g . T o p i c s
c o v e r e d i n c l u d e s e t s , r e l a t i o n s , a n d f u n c
t i o n s ; b a s i c p r o p o s i t i o n a l a n d p r e d i c a t e
l o g i c ; p r o o f t e c h n i q u e s ; g r a p h s a n d t r e e s
; d i s c r e t e p r o b a b i l i t y ; g r a m m a r s a n d f i n i
t e s t a t e m a c h i n e s ; a n d n u m b e r t h e o r y .
- 1 5 E n g i n e e r i n g F o u n d a t i o n s
s f u n d a m e n t a l t o p i c s t h a t p r o v i d e t h e e n g
i n e e r i n g b a c k g r o u n d n e c e s s a r y f o r t h e
p r a c t i c e o f s o f t w a r e e n g i n e e r i n g . T o p i c s
c o v e r e d i n c l u d e e m p i r i c a l m e t h o d s a n d e
x p e r i m e n t a l t e c h n i q u e s ; s t a t i s t i c a l
a n a l y s i s ; m e a s u r e m e n t s a n d m e t r i c s ; e n g
i n e e r i n g d e s i g n ; s i m u l a t i o n a n d m o d e l i n
g ; a n d r o o t c a u s e a n a l y s i s .

KA -11 THROUGH KA 15 ADDED IN 2014
63
RELATED DISCIPLINES OF SOFT WARE
ENGINEERING
Related Disciplines
The SWEBOK also contains a chapter on related disciplines.
The related disciplines are those that share a
boundary, and often a common intersection, with software
engineering. The SWEBOK V3 does not
characterize the knowledge of the related disciplines but, rather,
indicates how those disciplines interact with
the software engineering discipline. The related disciplines
include
Student team project focus: Domain-specific research and
STEM skills development
64

NASA COST ESTIMATION
Handbook for Software Cost Estimation – JPL
65
DEVELOPMENT EFFORT MULTIPLIERS
66
COST ESTIMATION UNCERTAINT Y
OVER TIME
x
2 x
4 x
0.5 x
0.2 5 x
Feasibility Requirem ents Design Code Delivery
67

- dependent s y s te m c an h ave vari able s
y s te m
rang e for t h e s ame f unc t i onal re qui rement
SYSTEM RANGE SHIFTING
OVER DESIGN RANGE
68
FR/DP SPECIFICATION (EXAMPLE)
69
and
c omp one nt d i agrams p rovi d es b as i s for d et ailed OO d
e s i gn
/hardware
OBJECT ORIENTED DIAGRAMS

DETAILED DESIGN SPECS
70
OO DIAGRAM
CLASSIFICATION (KA -2 SAMPLE)
71
72
FR/DP OO DESIGN
KA -3 SOFT WARE CONSTRUCTION
Software Construction
Software construction refers to the detailed creation of working
software through a combination of detailed design, coding, unit
testing, integration
testing, debugging, and verification. The Software Construction
KA includes topics related to the development of software
programs that will satisfy their
requirements and design constraints. This KA covers software
construction fundamentals; managing software construction;
construction technologies;

practical considerations; and software construction tools.
Student team project focus: Unified Modeling Language
structured coding
73
KA -5 SOFT WARE MAINTENANCE
Software Maintenance
Software maintenance involves enhancing existing capabilities,
adapting software to operate in new and modified operating
environments, and correcting defects. These categories are
referred to as perfective, adaptive, and corrective software
maint enance.
The Software Maintenance KA includes fundamentals of
software maintenance (nature of and need for maintenance,
categories of
maintenance, maintenance costs); key issues in software
maintenance (technical issues, management issues, maintenance
cost
estimation, measurement of software maintenance); the
maintenance process; software maintenance techniques
(program
comprehension, re-engineering, reverse engineering,
refactoring, software retirement); disaster recovery techniques,
and software

maintenance tools.
Student team project focus: Version control with concept map
tools by IHMC
74
KA -6 SOFT WARE CONFIGURATION
MANAGEMENT
Software Configuration Management
The configuration of a system is the functional and/or physical
characteristics of hardware, firmware, software, or a
combination of these. It can also be
considered as a collection of specific versions of hardware,
firmware, or software items combined according to specific
build procedures to serve a
particular purpose. Software configuration management (SCM)
is thus the discipline of identifying the configuration of a
system at distinct points in time
for the purposes of systematically controlling changes to the
configuration, as well as maintaining the integrity and
traceability of the configuration
throughout the software life cycle. The Software Configuration
Management KA covers management of the SCM process;
software configuration

identification, control, status accounting, auditing; software
release management and delivery; and software configuration
management tools.
Student team project focus: Architecture module configuration
75
TOOL CONFIGURATION
CAPABILIT Y (KA -7 SAMPLE)
Acclaro Design for Six Sigma for reconfiguration
76
- print s af te r OO anal y s is
r diagrams (Activity, State Machine, Sequence,
Interaction,
etc.)
DETAILED DESIGN
RESULTS (KA -2 SAMPLE)
UML (software specs) SysML (Hardware specs)
77

KA -4 SOFT WARE TESTING
Software Testing
Testing is an activity performed to evaluate product quality and
to improve it by identifying defects. Software testing involves
dynamic
verification of the behavior of a program against expected
behavior on a finite set of test cases. These test cases are selec
ted from the
(usually very large) execution domain. The Software Testing
KA includes the fundamentals of software testing; testing
techniques; human-
computer user interface testing and evaluation; test-related
measures; and practical considerations.
Student team project focus: Verification & Validation
78
79
P4 MEDICINE
P4 Medicine will improve the quality of care delivered to
patients through
better diagnoses and targeted therapies. These advances

facilitate new
forms of active participation by patients and consumers in the
collection
of personal health data that will accelerate discovery science.
Soon a virtual data cloud of billions of health-relevant data
points will
surround each individual. Through P4 Medicine, we will be able
to reduce
this complex data to simple hypotheses about how to optimize
wellness
and minimize disease for each individual.
80
WOLFRAM
PRODUCTS & SERVICES

81
WOLFRAM
SOFT WARE ENGINEERING
82
WOLFRAM
SOFT WARE ENGINEERING - EDGE
83
WOLFRAM
SOFT WARE ENGINEERING - KEY CAPABILITIES
84
WOLFRAM
SOFT WARE ENGINEERING - COMPARISON
85

WOLFRAM
DISCOVERY PLATFORM
86
WOLFRAM
CLOUD
87
WOLFRAM
WORKBENCH
88
WOLFRAM
DATA SCIENCE
89
WOLFRAM
DATA SCIENCE – KEY CAPABILITIES

90
WOLFRAM
FINANCE PLATFORM
91
WOLFRAM
SYSTEM MODELER
MODELING/SIMULATION
92
WOLFRAM
SYSTEM MODELER
ANALYSIS/DESIGN
93

WOLFRAM
INTERFACE DEVELOPMENT
94
WOLFRAM
WEB DEVELOPMENT
95
WOLFRAM
WEB DEVELOPMENT – KEY CAPABILITIES
96
WOLFRAM
DATA FRAMEWORK
97
WOLFRAM
BIOINFORMATICS

98
WOLFRAM
BIOINFORMATICS - EDGE
99
WOLFRAM
BIOINFORMATICS - COMPARISON
100
WOLFRAM
BIOINFORMATICS – KEY CAPABILITIES
101
WOLFRAM

UNIVERSAL DEPLOYMENT SYSTEM
102
WOLFRAM
KNOWLEDGE-BASE
103
WOLFRAM
KNOWLEDGE BASE (HEALTH & MEDICINE)
104
WOLFRAM
CLOUD (MACHINE LEARNING)
105
WOLFRAM
ELECTRICAL ENGINEERING

106
WOLFRAM
ELECTRICAL ENGINEERING –
KEY CAPABILITIES
107
WOLFRAM
MEDICAL IMAGING
108
WOLFRAM
TECHNOLOGY STACK
109
WOLFRAM
WEB-MATHEMATICA
110

WOLFRAM
CONNECTED DEVICES PROJECT
C y b e r Op e rat ion T h eatre s y s te m
- phy sic al s y s te ms p or t al
111
STUDENT PROJECT SAMPLES
112
WEB 1 .0 – 4.0
http://blog.law.cornell.edu/voxpop/category/semantic-web-and-
law/
113

SEMANTIC WEB
HEALTH CARE AND LIFE SCIENCES
http://www.w3.org/blog/hcls/
114
SEMANTIC WEB
CONCEPT MAP (EXAMPLE)
115
WEB 1 .0 – 4.0
http://blog.law.cornell.edu/voxpop/category/semantic-web-and-
law/
116
SEMANTIC WEB
DATA LAYERS (EXAMPLE)
http://semanticweb.com/semantic-web-impact-on-enterprise-
software-part-2_b707

117
SEMANTIC WEB
WEB STANDARDS PROGRESS
http://www.mkbergman.com/426/the-shaky-semantics-of-the-
semantic-web/
118
SEMANTIC WEB
TECHNOLOGIES
http://afterglowlee.blogspot.com/2011/07/want-semantic-web-
linked-data-job.html
119
SEMANTIC WEB
STACK
http://www.cse.wustl.edu/~jain/cse570-
13/ftp/semantic/index.html
120

UNIFIED MEDICAL LANGUAGE SYSTEM
(UMLS)
121
COMET DESIGN ENVIRONMENT
http://www.eda.org/rassp/documents/newsletter/html/96sep/new
s_8.html
122
COMET SYSTEM LEVEL DESIGN TOOL
http://www.embedded.com/design/virtual-
prototyping/4024966/How-virtual-prototypes-aid-SoC-
hardware-design
123
VIRTUAL PROTOT YPES
COMPARISON
http://www.embedded.com/design/virtual-
prototyping/4024966/How-virtual-prototypes-aid-SoC-
hardware-design
Sequential design process Parallel design process

124
COMET METHODOLOGY
125
(CKAU) Blackboard
Semantic Web
Services
Design Environment
AI KB
Domain
KB
Design
KB
Validation
KB

Project
Database
Designer Environment
AIDF
Task GUI
TRIZ
DSM
MLH
FTA
RBD
FMEA
ETP
QFD
TRF
OPT
ADT

F
u
n
ct
io
n
al
L
ay
er
D
es
ig
n
M
o
d
u
le
L
ay
er
DRS

PLS
FLS
NNS
ARS
GAS
CTS
CBR
A
ID
F
G
lo
ba
l D
is
tr
ib
ut
ed
G
U
I

D
ata T
ransfer B
us (D
T
B
)
K
no
w
le
dg
e
T
ra
ns
fe
r
B
us
(
K
T

B
)
K
no
w
le
dg
e
A
llo
ca
tio
n
B
us
(
K
A
B
)

K
no
w
le
dg
e
V
al
id
at
io
n
U
ni
t (
K
V
U
)
D
ata V
alidation U
nit (D

V
U
)
MO
D
ata A
llocation B
us (D
A
B
)
I-Agents
User Task
Management
Authentication

M1D
M2D
M3D
M4D
M5D
M6D
M7D
M8D
M9D
M10D
M11D
M1A
M2A
M3A
M4A
M5A
M6A
M7A

M8A
M9A
A
I M
o
d
u
le
L
ay
er
DMS
MO
MO
MO
MO MOController
ModelView
In
p

u
t
P
h
as
e
U
se
r
T
as
ks
I-T1
I-T2
I-T3
I-T4
I-T5
I-T6
I-T7
I-T8

I-T9
I-T10
I-T11
...
I-TN
P
ro
ce
ss
in
g
P
h
as
e
U
se
r
T
as
ks
P-T1

P-T2
P-T3
P-T4
P-T5
P-T6
P-T7
P-T8
P-T9
P-T10
P-T11
P-T12
O
u
tp
u
t
P
h
as
e

U
se
r
T
as
ks
O-T1
O-T2
...
O-TN
P-T13
P-T14
P-T15
P-T16
P-T17
P-T18
...
P-TN
S1 Active
S2 Active

N/D
S3 Active
S2/S3 Active
S1/S2/S3
S1/S2 ActiveLegend
U
se
r-
A
ID
F
In
te
rf
ac
e
–
M
o
d
el
V
ie

w
C
o
n
tr
o
lle
r
(M
V
C
)
Artificial Intelligence Design Framework
(AIDF) Architecture Model
A
ID
F
-G
lo
b
e
In
te

rf
ac
e
–
B
ac
ke
n
d
S
em
an
ti
c
W
eb
S
er
vi
ce
s
IA-1
IA-2

IA-3
...
I-TN
AI-1
Ai-2
AI-3
...
AI-N
AI/KBE
DE
D-1
D-2
D-3
...
D-N
Disciplinary
DE
De-1

De-2
De-3
...
De-N
V-1
V-2
V-3
...
V-N
Design
DE
Validation
DE
Globally Distributed
Domain Experts (DE)
G
lo
ba
l K

no
w
le
dg
e
R
ep
os
ito
ry
o
n
W
W
W
WORLDUSER
W
eb
S
er
vi
ce
s

Semantic
Web
Domain Expert Environment
A R T I F I C I A L I N T E L L I G E N C E D E S I G N F R
A M E WO R K
( A I D F )
AIDF is an architecture framework that configures
KBE/SOS that utilize CPS, Cloud, and Big Data
Book based on my dissertation was published on this
topic called Architecting Automated Design Systems
h # 3 . E s t a b l i s h a c o m p r e h e n s i v
e
a r c h i t e c t u r e f r a m e w o r k t h a t c o n f i g u r e s a

n y
n u m b e r o f d o m a i n - s p e c i f i c K B E s y s t e m s
f o r
C P S f o c u s i n g o n h e a l t h i n f o r m a t i c s . E a c
h o f
t h e s e m e d i c a l K B E s y s t e m s c a n p r o v i d e
a u t o m a t e d d e s i g n s u p p o r t f o r a d o m a i n -
s p e c i f i c H e a l t h Q u e s t C D S S a d d r e s s i n g t
h e
n e e d s f o r e a c h s p e c i a l i z e d a r e a o f m e d i c i
n e .
- p h y s i c a l
t i c s

- s p e c i f i c
- a g n o s t i c
125
INPUT BLOCK 1 (KAE)
(CKAU) Blackboard
Semantic Web
Services
AI KB
Domain
KB
Design
KB
Validation

KB
Project
Database
AIDF
Task GUI
D
a
ta
T
ra
n
s
fe
r B
u
s
(D
T
B
)
K
n

o
w
le
d
g
e
T
ra
n
s
fe
r
B
u
s
(
K
T
B
)
K
n

o
w
le
d
g
e
A
ll
o
c
a
ti
o
n
B
u
s
(
K
A
B
)
K
n
o

w
le
d
g
e
V
a
li
d
a
ti
o
n
U
n
it
(
K
V
U
)
D
a
ta
V

a
lid
a
tio
n
U
n
it (D
V
U
)
MO
D
a
ta
A
llo
c
a
tio
n
B
u

s
(D
A
B
)
I-Agents
User Task
Management
Authentication
MO
I-T1
I-T2
I-T3
I-T4
I-T5
I-T6
I-T7
I-T8
I-T9

I-T10
I-T11
...
I-TN
IA-1
IA-2
IA-3
...
I-TN
Framework Detail
M O D U L A R I N T E R AC T I O N S I N P R O C E S S I
N G B LO C K AT
C O M P O N E N T L E V E L ( KC E )
Block (KAE)
Block (KJE)
Dual Engine Block Operation
of Architecture Framework (AIDF)

Element
Design Engine block Inference Engine block
(9 modules)
Module
Dual Engine Block
Block (KCE)
Element
Module
(11 modules)
Interlacing
Interaction
D
a
ta
F
lo
w
D
a

ta
F
lo
w
D
a
ta
F
lo
w
D
a
ta
F
lo
w
Data Flow
From Web
Services

Data Flow
From Web
Services
Data Flow
From Web
Services
Data Flow
From User
Data Flow
From Domain
Experts
KBE SoS Reliability Engineering
Recommendations Output
Based on AIDF design matrix requirements
configured for case study (per stage)
D
a
ta

F
lo
w
127
OUTPUT BLOCK 3 (KJE)
MO MOController
ModelView
http://robotics.case.edu/ICRA2010/MedicalCyberPhysicalSyste
ms.html
Framework Detail
Thus the AIDF configures a KBE/SOS with module
combinations that are capable
of supporting the design process for a variety of Cyber-physical
systems
Exploring CPS that are CDSS platforms with biosensors and

access to Big Data via
Cloud Services and Semantic Web.
128
PROCESSING BLOCK 2 (KCE)
TRIZ
DSM
MLH
FTA
RBD
FMEA
ETP
QFD
TRF
OPT
ADT
F

u
n
c
ti
o
n
a
l
L
a
y
e
r
D
e
s
ig
n
M
o
d
u
le
L

a
y
e
r
DRS
PLS
FLS
NNS
ARS
GAS
CTS
CBR
M1D

M2D
M3D
M4D
M5D
M6D
M7D
M8D
M9D
M10D
M11D
M1A
M2A
M3A
M4A
M5A
M6A
M7A
M8A

M9A
A
I
M
o
d
u
le
L
a
y
e
r
DMS
MO MO
Knowledge Correlation Engine (KAE)
Framework Detail

129
V—MODEL DESIGN PROCESS ADAPTED TO
STEM STUDENT TEAMS
http://www.gcoe-s4design.keio.ac.jp/en/education/index.html
Students can use the v-model as a
foundational approach to design
applications by forming teams
Fig. 1 V-model for interdisciplinary approach
Fig. 2 V-model for axiomatic design of systems
130
- p h y s i c a l s y s t e m ( C P S ) i s e s s e n
t i a l l y a n e m b e d d e d s y s t e m t i g h t l y c o u p l e
d t o t h e I n t e r n e t a n d o t h e r
n e t w o r k e d s y s t e m s h a v i n g m a n y a p p l i c a t
i o n a r e a s . A C P S i s a s y s t e m o f c o l l a b o r a t

i n g c o m p u t a t i o n a l
e l e m e n t s c o n t r o l l i n g p h y s i c a l e n t i t i e s .
T o d a y , a p r e - c u r s o r g e n e r a t i o n o f c y b e r -
p h y s i c a l s y s t e m s c a n b e
f o u n d i n a r e a s a s d i v e r s e a s a e r o s p a c e , a
u t o m o t i v e , c h e m i c a l p r o c e s s e s , c i v i l i n f
r a s t r u c t u r e , e n e r g y ,
h e a l t h c a r e , m a n u f a c t u r i n g , t r a n s p o r t a t i
o n , e n t e r t a i n m e n t , a n d c o n s u m e r a p p l i a n
c e s . T h i s g e n e r a t i o n i s
o f t e n r e f e r r e d t o a s e m b e d d e d s y s t e m s . I
n e m b e d d e d s y s t e m s t h e e m p h a s i s t e n d s t
o b e m o r e o n t h e
c o m p u t a t i o n a l e l e m e n t s , a n d l e s s o n a n i
n t e n s e l i n k b e t w e e n t h e c o m p u t a t i o n a l a n
d p h y s i c a l e l e m e n t s ( ) .
C Y B E R - P H Y S I C A L S Y S T E M S ( C P S ) / E M B
E D D E D S Y S T E M S
C O N C E P T M A P O F T O P I C S
http://en.wikipedia.org/wiki/Cyber-physical_system
http://cyberphysicalsystems.org/(Berkeley)
131
http://en.wikipedia.org/wiki/Embedded_system

http://cyberphysicalsystems.org/(Berkeley)
ENG1021 Critical (Rhetorical) Analysis of Article or
Documentary: Outline
I. Introduction (Overview)
· Title
· Author or documentarian
· Intended audience
· Composer’s purpose or motivation
· Context in which the piece was written / created
II. Body (Analysis)
· Supporting Details / Content
· Transitions
· Organization
· Word Choice
· Visual rhetoric (if applicable)
· Ethos (Ethical Appeal)

· Logos (Logical Appeal – logical fallacies?)
· Pathos (Emotional Appeal)
· Conclusion
III. Conclusion
· Analyze overall efficacy (ability to influence the audience) of
the article or documentary

U. J o h n Tan i k P h .D. Apri l 2 014 SOF.docx

Recommandé

Recommandé

Contenu connexe

Similaire à U. J o h n Tan i k P h .D. Apri l 2 014 SOF.docx

Similaire à U. J o h n Tan i k P h .D. Apri l 2 014 SOF.docx (20)

Plus de ouldparis

Plus de ouldparis (20)

Dernier

Dernier (20)

U. J o h n Tan i k P h .D. Apri l 2 014 SOF.docx