Cyber Physical systems & IOT1

Rama

60b844_93c9218fe6e549da9e8f661ead2d3060.pdf

Home >Computer Science homework help >Cyber Physical systems & IOT1

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

 A c a d e m i c B a c k g r o u n d  N A S A o u t r e a c h

 E n g i n e e r i n g V - m o d e l  V e r i f i c a t i o n a n d V a l i d a t i o n ( V & V )

 S T E M s t u d e n t p r o j e c t s ( s e n i o r d e s i g n a n d g r a d u a t e w o r k )

 D e s i g n p h a s e s , s t a n d a r d s , s c o p i n g  I E E E 1 2 2 0 7

 R a t i o n a l U n i f i e d P r o c e s s ( R U P )

 A x i o m a t i c D e s i g n P r o c e s s  D e s i g n M a t r i x

 D e p e n d e n c y S t r u c t u r e M a t r i x ( D S M )

 Q u a l i t y F u n c t i o n D e p l o y m e n t ( Q F D )

 S o f t w a r e E n g i n e e r i n g B o d y o f K n o w l e d g e ( S W E B O K )  S R S - I E E E 8 3 0

 S D D - I E E E 1 0 1 6

 P M P - I E E E 1 0 5 8

 A r c h i t e c t u r e a n d d e t a i l e d d e s i g n  A p p l i c a t i o n / I n f o r m a t i o n / S y s t e m s / O O

 U n i f i e d M o d e l i n g L a n g u a g e ( U M L )

 C o s t e s t i m a t i o n

 I n d u s t r i a l I n t e r n e t  C y b e r - p h y s i c a l s y s t e m s

 B i g D a t a

 S e m a n t i c W e b

 A p p l i c a t i o n s  C P S d e s i g n a u t o m a t i o n

 P 4 m e d i c i n e C P S , B i g D a t a , S e m a n t i c W e b

 C l i n i c a l d e c i s i o n s u p p o r t s y s t e m s ( C D S S )

OVERVIEW

 P u r d u e U n i v e r s i t y Fo r t Wa y n e ( I P F W )  Assistant Professor of Software/Systems Engineering

 Information Analytics and Visualization Center of Excellence award to Dept for ABET Accreditation success in curriculum development

 Applied Cyber-physical Sys tems book published

 CPS grants panelist for NSF

 Published CPS design automation in Journal of Innovation Management

 UA B / N A S A Fe l l o w s h i p Tr a i n i n g ( M a r s h a l l S p a c e F l i g h t C e n t e r )  Ph.D. Computer Engineering

 Architecting Automated Design Sys tems book published  Dr. Grimes, advising on Dissertation, has over 70 patents from Bell labs

 U n i v e r s i t y o f A l a b a m a a t B i r m i n g h a m ( UA B )  M.S.E.E. Electrical Engineering (Kauf fman Scholarship)

 Systems/Enterprise Engineering awards/conferences  Dr. Kozmetsky (IC2 Institute) advising at Society for Design and Process Science Conference

 U n i v e r s i t y o f Tex a s a t A u s t i n / S M U ( P r e s i d e n t i a l S c h o l a r s h i p )  B.S.E.E. Electrical Engineering

 Alcatel Networks internships (Network Simulation Center)

ACADEMIC BACKGROUND

 Forme r N A SA Fe l low d eveloping ST E M ou t re ac h tod ay

NASA OUTREACH

STEM TEACHING AND R&D

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

A FAMOUS CARTOON (NEED FOR V&V)

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.htm

http://en.wikipedia.org/wiki/V-Model_(software_development)

http://memnorthwestern.wordpress.com/2012/09/25/systems-thinking-in-the-mem-program/

http://www.ops.fhwa.dot.gov/publications/fhwahop13013/ch2.htm

http://en.wikipedia.org/wiki/V-Model_(software_development)

DESIGN PROCESS

GENERAL PHASES

A logical way to divide the design process is to divide

work into phases that students follow during R&D

 L arg e - 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

 IEEE 12207

 "Standard for Information Technology – Software Life Cycle Processes", is a standard that establishes a common framework for software life cycle process.

 M i d - 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

 The Unified Sof tware Development Process (Unified Process) is a popular iterative and incremental sof tware development process framework (Refined Unified Process called Rational Unified Process)

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

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=collection/uno_/l

essons/uno_curiosity/uno_curiosity_lesson01.xml

http://www.teachengineering.org/view_lesson.php?url=collection/uno_/lessons/uno_curiosity/uno_curiosity_lesson01.xml

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/ http://www.teachengineering.org/view_lesson.php?url=collection/uno

_/lessons/uno_curiosity/uno_curiosity_lesson01.xml

http://www.ibm.com/developerworks/library/ws-soa-term2/

http://www.teachengineering.org/view_lesson.php?url=collection/uno_/lessons/uno_curiosity/uno_curiosity_lesson01.xml

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/Ratio

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.

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/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

AXIOMATIC DESIGN PROCESS

OVERVIEW

 A s y s t e m f o r s i m u l t a n e o u s h a r d w a r e a n 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 .

 F o u r d o m a i n s a r e p r o v i d e d i n A D :

 C ustomer D o m ain: specifying the customer needs, expectations, design specifications

etc.

 Func tional D o main: specifying the functional requirements whic h will satisfy ever y

item of the customer domain;

 Phy sical D o m ain: whic h specifies the physical, or actual designed components whic h

satisfy the functional requirements; and

 Pro cess D o main: whic h allocates the processes required to ac hieve the design

parameter s.

AXIOMATIC DESIGN PROCESS

FOR HARDWARE/SOFT WARE CO -DESIGN

http://www.axiomaticdesign.com/technology/ADSChapter5.html

Functional Domain Physical Domain

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

Step 7

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.

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.

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

 O n c e t h e D e s i g n M a t r i x a n d D S M i s c o m 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 .

MODULE INTERACTIONS

Module Interactions derived from matrix

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.

http://www.axiomaticdesign.com/technology/axiomatic.asp

http://phys.org/news/2012-07-matrix-analysis-product-simple-square.html

TOOL SCREENSHOT S FOR DESIGN SUPPORT

https://www.palisade.com/decisiontools_suite/6/WhatsNew.asp http://www.dfss-software.com/dfss_features_qfd.asp

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

SWEBOK KNOWLEDGE AREAS (KA 1 -15)

http://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#SWEBOK_Guide_Version_3

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

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

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)

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.

http://www.axiomaticdesign.com/technology/axiomatic.asp

http://phys.org/news/2012-07-matrix-analysis-product-simple-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)

http://www.axiomaticdesign.com/technology/axiomatic.asp

http://phys.org/news/2012-07-matrix-analysis-product-simple-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

ARCHITECTURE VIEW (KA -2)

FR/DP Design trade-off analysis DP/DP Component interaction analysis

 M od u le i nte ract ions d e fi ned

 Acclaro DFSS tool scopes large system

 Define subsystem modules for concentrated teamwork

 Theoretical modules provides context for scoped system

 Defines how teams can integrate modules to build large -scale system

SYSTEMS/MODULAR

ARCHITECTURE VIEW (KA -2)

30 We used the systems architecture view to verify that the system has met all the functional and nonfunctional requirements.

 C l as s and

s of t ware

Di ag rams

d e fi ned

 Bl oc k and

h ard ware

Di ag rams

d e fi ned

OBJECT ORIENTED/STRUCTURAL

ARCHITECTURE VIEW (KA -2)

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)

 Ve r s ion c ont rol c ap abili ty wi t h d i s t ribu ted te ams

 C os t e s t i mat ion

 COCOMO methodology

 NASA cost handbook

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

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)

http://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#SWEBOK_Guide_Version_3

Project teams reviewed the standards

found in all the other areas to make

sure system was built to industry

specifications.

http://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#SWEBOK_Guide_Version_3

DESIGN PRINCIPLES AS FOUNDATION

FOR APPLICATIONS

Software/systems engineering of complex systems

(Industrial Internet Applications include CPS and Big Data/Semantic Web)

 Industrial Internet Consortium (IIC) was formed March 27, 2014

 Goal to improve integration of the physical and digital worlds

 AT&T, CISCO, GE, IBM, INTEL founding members

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%20internet/Industrial_Internet.pdf

INDUSTRIAL INTERNET

IMPACT ($32.3 TRILLION)

Focus on healthcare applications: $1.7 trillion file:///C:/Users/Owner/Desktop/Research%202014/Industrial%20internet/Industrial_Internet.pdf

 T h e c onve rgenc e t rans formi ng me d ic ine

 Current reactive mode, which is focused on treating disease

 Preventive mode, which is focused on maintaining health

 Predictive

 Preventative

 Personalized

 Par ticipator y

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

 Bi g Dat a - me d ic al

 Soon a virtual data cloud

of billions of health-

relevant data points will

surround each

individual.

 P 4 M e d ic ine

 Process complex data

 Optimize wellness

 Minimize disease for

each individual.

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.

 P r e s e n t r e s e a r c h f o c u s

 UAB (AT&T/Ericsson) –Industrial Internet Roadmap development with AT&T

 Jerr y Higgs collaboration, Sr. New Product Development Engineer, AT&T Foundr y Palo Alto, California, United States

 Complex systems design/cyber —physical systems/Big Data/Semantic Web

 UAB (Healthcare engineering/informatics)

 P4 medicine/CDSS

 SDPS (STEM projects)

 Exploring Wolfram capability

 Fu t u r e r e s e a r c h f o c u s

 Project-based explorator y research with undergrad students

 Applied research with grad students (Wolfram products)

 Government grants (NSF/NASA/NIH/?)

 Industr y sponsorship (AT&T, Intel, GE, Ericsson, etc)

 Academic collaboration (MIT, Purdue, UAB, UT - Austin, etc)

 International collaboration (Germany, Japan, Brazil, etc)

 Start-up venture suppor t for students (Innovation triangle – Academia/Research/Community)

 STEM/NASA outreach/SDPS

EXPLORING CYBER -PHYSICAL SYSTEMS AND

BIG DATA APPLICATIONS OF SEMANTIC WEB

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.

WOLFRAM

SYSTEM MODELER

MODELING/SIMULATION

After designing a system, it is important to be able to model and simulation its function.

WOLFRAM

DISCOVERY PLATFORM

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

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

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

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

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

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

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

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

M a

p p

e d

t o

R e

a l- w

o rl d

n e

e d

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

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 )

Research focus is to develop an architecture framework to automate the design process.

 A I D F d i v i d e d i n t o t h r e e f u n c t i o n a l b l o c k s

 B l o c k 1 ( K n o w l e d g e A s s i m i l a t i o n E n g i n e )

 G a t h e r s g l o b a l k n o w l e d g e

 B l o c k 2 ( K n o w l e d g e C o r r e l a t i o n E n g i n e )

 P r o c e s s e s a s s i m i l a t e d k n o w l e d g e

 B l o c k 3 ( K n o w l e d g e J u s t i f i c a t i o n E n g i n e )

 O u t p u t s p r o c e s s e d k n o w l e d g 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

Design

Validation

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

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

)

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

DMS

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

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

IA-1

IA-2

IA-3

...

I-TN

AI-1

Ai-2

AI-3

...

AI-N

AI/KBE

D-1

D-2

D-3

...

D-N

Disciplinary

De-1

De-2

De-3

...

De-N

V-1

V-2

V-3

...

V-N

Design

Validation

Globally Distributed

Domain Experts (DE)

G lo

ba l K

no w

le dg

e R

ep os

ito ry

o n

W W

WORLDUSER

W eb

S er

vi ce

Semantic

Web

Domain Expert Environment

Centralized Knowledge Assimilation Unit

(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

Perspectives of the AIDF With Hierarchical Decomposition

50 CPS design automation framework is a useful

guide to development of CPS applications.

 A c a d e m i c B a c k g r o u n d  N A S A o u t r e a c h

 E n g i n e e r i n g V - m o d e l  V e r i f i c a t i o n a n d V a l i d a t i o n ( V & V )

 S T E M s t u d e n t p r o j e c t s ( s e n i o r d e s i g n a n d g r a d u a t e w o r k )

 D e s i g n p h a s e s , s t a n d a r d s , s c o p i n g  I E E E 1 2 2 0 7

 R a t i o n a l U n i f i e d P r o c e s s ( R U P )

 A x i o m a t i c D e s i g n P r o c e s s  D e s i g n M a t r i x

 D e p e n d e n c y S t r u c t u r e M a t r i x ( D S M )

 Q u a l i t y F u n c t i o n D e p l o y m e n t ( Q F D )

 S o f t w a r e E n g i n e e r i n g B o d y o f K n o w l e d g e ( S W E B O K )  S R S - I E E E 8 3 0

 S D D - I E E E 1 0 1 6

 P M P - I E E E 1 0 5 8

 A r c h i t e c t u r e a n d d e t a i l e d d e s i g n  A p p l i c a t i o n / I n f o r m a t i o n / S y s t e m s / O O

 U n i f i e d M o d e l i n g L a n g u a g e ( U M L )

 C o s t e s t i m a t i o n

 I n d u s t r i a l I n t e r n e t  C y b e r - p h y s i c a l s y s t e m s

 B i g D a t a

 S e m a n t i c W e b

 A p p l i c a t i o n s  C P S d e s i g n a u t o m a t i o n

 P 4 m e d i c i n e C P S , B i g D a t a , S e m a n t i c W e b

 C l i n i c a l d e c i s i o n s u p p o r t s y s t e m s ( C D S S )

OVERVIEW REVISITED

THANK YOU – QUESTIONS?

EXTRA SLIDES

 A p p lied re s e arc h re l ated to h e al th care

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

http://www.springer.com/public+health/book/978-1-85233-978-4

http://www.barnesandnoble.com/w/clinical-decision-support-systems-eta-s-

berner/1101309314?ean=9780387985756

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

http://www.springer.com/public+health/book/978-1-85233-978-4

http://www.barnesandnoble.com/w/clinical-decision-support-systems-eta-s-berner/1101309314?ean=9780387985756

UML/SYSML COMPARISON

 E s t abl ished OO arc h i tec t ure s t ru c t ure wi t h c l as s 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

 OO Be h av ior d i agrams d e fi ned for s of t ware /hardware

OBJECT ORIENTED DIAGRAMS

DETAILED DESIGN SPECS

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

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 )

 1 . C o v e r p a g e a n d T a b l e o f C o n t e n t s ( i 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 )

 2 . B r i e f P r o j e c t P r o p o s a l & R e s e a r c h

 3 . 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

 4 . V i s i o n d o c u m e n t

 5 . A r c h i t e c t u r e ( a l l t y p e s i n S D D d o c u m e n t )

 a . A p p l i c a t i o n a r c h i t e c t u r e

 b . I n f o r m a t i o n a r c h i t e c t u r e

 c . S y s t e m a r c h i t e c t u r e

 d . U M L a r c h i t e c t u r e ( s t r u c t u r e d i a g r a m s w i t h b e h a v i o r d i a g r a m s )

 6 . S R S w i t h 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 )

 7 . A x i o m a t i c d e s i g n t o o l s c r e e n s h o t s f o r a n y f e a t u r e s u s e d

 a . D e s i g n M a t r i x - F R / D P

 b . D S M - D P / D P

 c . F M E A

 d . Q F D

 8 . P r o g r e s s r e p o r t s ( i n M S W o r d , t a b l e 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 )

 9 . S W E B O K t e c h n i c a l r e v i e w s K A - 1 t h r u 1 1

 1 0 . P M P ( I E E E 1 0 5 8 f o r m a t )

 1 1 . G a n t t c h a r t ( c o m p r e h e n s i v e )

 1 2 . A l l s l i d e s

 1 3 . S D D ( I E E E 1 0 1 6 f o r m a t )

 1 4 . I n d i 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 )

 1 5 . U M L ( i n t h e S D D d o c u m e n t )

 1 6 . A p p e n d i x ( A n y t h i n g e l s e s t a t e d i n y 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 )

 1 7 . K e y R e f e r e n c e s , i n a n y c o n v e n i e n t f o r m a t

 1 8 . A c k n o w l e d g e m e n t s ( o p t i o n a l )

 1 9 . C o n c l u s i o n

 2 0 . F u t u r e w o r k 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

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

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

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

 K A - 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  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 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 .

 K A - 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  T h e 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 K 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 ) .

 K A - 1 3 C o m p u t i n g F o u n d a t i o n s  T h e C o m p u t i n g F o u n d a t i o n s K A c o v e 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 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 .

 K A - 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  T h e M a t h e m a t i c a l F o u n d a t i o n s K A c o v e 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 .

 K A - 1 5 E n g i n e e r i n g F o u n d a t i o n s  T h e E n g i n e e r i n g F o u n d a t i o n s K A c o v e 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 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

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

NASA COST ESTIMATION

Handbook for Software Cost Estimation – JPL

 Samp le l i s t of c os t mu l t iplier s

DEVELOPMENT EFFORT MULTIPLIERS

COST ESTIMATION UNCERTAINT Y

OVER TIME

2 x

4 x

0.5 x

0.2 5 x

Feasibility Requirem ents Design Code Delivery

 A te mperat ure - 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

 E xample F R/ DP s p e c ific at ion

FR/DP SPECIFICATION (EXAMPLE)

 E s t abl ished OO arc h i tec t ure s t ru c t ure wi t h c l as s 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

 OO Be h av ior d i agrams d e fi ned for s of t ware /hardware

OBJECT ORIENTED DIAGRAMS

DETAILED DESIGN SPECS

OO DIAGRAM

CLASSIFICATION (KA -2 SAMPLE)

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

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

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

TOOL CONFIGURATION

CAPABILIT Y (KA -7 SAMPLE)

Acclaro Design for Six Sigma for reconfiguration

 E xample of OO b l u e - print s af te r OO anal y s is

 Structural diagrams (Class, Component, etc.)

 Behavior diagrams (Activity, State Machine, Sequence, Interaction,

etc.)

DETAILED DESIGN

RESULTS (KA -2 SAMPLE)

UML (software specs) SysML (Hardware specs)

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

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.

WOLFRAM

PRODUCTS & SERVICES

WOLFRAM

SOFT WARE ENGINEERING

WOLFRAM

SOFT WARE ENGINEERING - EDGE

WOLFRAM

SOFT WARE ENGINEERING - KEY CAPABILITIES

WOLFRAM

SOFT WARE ENGINEERING - COMPARISON

WOLFRAM

DISCOVERY PLATFORM

WOLFRAM

CLOUD

WOLFRAM

WORKBENCH

WOLFRAM

DATA SCIENCE

WOLFRAM

DATA SCIENCE – KEY CAPABILITIES

WOLFRAM

FINANCE PLATFORM

WOLFRAM

SYSTEM MODELER

MODELING/SIMULATION

WOLFRAM

SYSTEM MODELER

ANALYSIS/DESIGN

WOLFRAM

INTERFACE DEVELOPMENT

WOLFRAM

WEB DEVELOPMENT

WOLFRAM

WEB DEVELOPMENT – KEY CAPABILITIES

WOLFRAM

DATA FRAMEWORK

WOLFRAM

BIOINFORMATICS

WOLFRAM

BIOINFORMATICS - EDGE

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

 H e al t h M oni tor s y s te m

 C y b e r Op e rat ion T h eatre s y s te m

 Te l edoc s y s te m

 Doc mate s y s te m

 C M S d e s ign

 Rob ot i c s / Cyb er - phy sic al s y s te ms p or t al

 A r t i fic ial k i d ney re s e arc h

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/news_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

Centralized Knowledge Assimilation Unit

(CKAU) Blackboard

Semantic Web

Services

Design Environment

Current User Project Input Global Knowledge Input

AI KB

Domain

Design

Validation

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

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

)

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

DMS

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

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

IA-1

IA-2

IA-3

...

I-TN

AI-1

Ai-2

AI-3

...

AI-N

AI/KBE

D-1

D-2

D-3

...

D-N

Disciplinary

De-1

De-2

De-3

...

De-N

V-1

V-2

V-3

...

V-N

Design

Validation

Globally Distributed

Domain Experts (DE)

G lo

ba l K

no w

le dg

e R

ep os

ito ry

o n

W W

WORLDUSER

W eb

S er

vi ce

Semantic

Web

Domain Expert Environment

Centralized Knowledge Assimilation Unit

(CKAU) Correlation Engine

Modular expansion capability

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

 A p p r o a c 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 .

 B e n e f i t s f o r # 3 a r e :

 C y b e r - p h y s i c a l

 C l o u d v i r t u a l i z a t i o n

 B i g D a t a

 L o g i s t i c s

 M o d u l a r

 S c a l a b l e

 R e c o n f i g u r a b l e

 S t a n d a r d i z e d

 D o m a i n - s p e c i f i c

 S p e c i a l i z e d

 A d a p t a b l e

 T e c h - a g n o s t i c

 I n n o v a t i v e 125

INPUT BLOCK 1 (KAE)

Centralized Knowledge Assimilation Unit

(CKAU) Blackboard

Semantic Web

Services

Current User Project Input Global Knowledge Input

AI KB

Domain

Design

Validation

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 )

Knowledge Assimilation Engine (KAE)

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

)

D a

ta A

llo c a

tio n

B u

s (D

A B

)

I-Agents

User Task

Management

Authentication

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

Knowledge Assimilation Engine (KAE)

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

F lo

D a

F lo

D a

F lo

D a

F lo

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

F lo

127

OUTPUT BLOCK 3 (KJE)

Knowledge Justification Engine (KJE)

MO MOController

ModelView

Justifiable Recommendations

AIDF Visualization GUI

http://robotics.case.edu/ICRA2010/MedicalCyberPhysicalSystems.html

Knowledge Justification Engine (KJE)

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)

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 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

DRS

PLS

FLS

NNS

ARS

GAS

CTS

CBR

Knowledge Correlation Engine (KCE)

CommonKADS Task Determination Unit (CTDU)

Analytic Subtask 1,2,3...N Synthetic Subtask 1,2,3...N

AI Design Task Manager (ADTM)

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 a

y e

DMS

MO MO

Centralized Knowledge Assimilation Unit

(CKAU) Correlation Engine

Modular expansion capability

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

http://www.axiomaticdesign.com/technology/ADSChapter5.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

http://www.gcoe-s4design.keio.ac.jp/en/education/index.html

http://www.axiomaticdesign.com/technology/ADSChapter5.html

 A c y b e r - 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://en.wikipedia.org/wiki/Cyber-physical_system

http://cyberphysicalsystems.org/(Berkeley)