Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations

© 2012 Systems and Proposal Engineering Company. All Rights Reserved

1

Lifecycle Modeling on the Cloud:An Approach to Simplified, Rapid Development, Operations, and Support

Steven H. Dam, Ph.D., ESEPPresident, SPEC [email protected]

May 14, 2012


Overview

What is Cloud Computing? Cloud Computing Implications for Systems Engineering Lifecycle Modeling Language Overview Suggested LML Processes LML Tool Needs Use of LML for Architecture Use of LML for Systems Design Use of LML for Software Development Use of LML in Test and Evaluation Use of LML in Operations and Support Summary

2


3

What is Cloud Computing?Hint: It’s not just a website


4

What is cloud computing?

• Definition from NIST: – Cloud computing is a model for enabling

convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models

From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012


5

Five Essential Characteristics• On-demand self-service. A consumer can unilaterally provision computing capabilities,

such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.

• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

• Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

• Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.



6

Three Service Models

• Software as a Service (SaaS): The end user system

• Platform as a Service (PaaS): Tools and services to create a SaaS Application

• Infrastructure as a Service (IaaS): Full control of the software stack and services

SaaS (Saleforce.com, Google Docs, Microsoft Office

365)

PaaS (Google App Engine, Microsoft Azure, Oracle Public

Cloud, Red Hat OpenShift)

IaaS (Amazon EC2, Red Hat CloudForms, Terremark)


7

Four Deployment Models

• Private cloud– Operated solely for an

organization – May be managed by the

organization or a third party

• Community cloud – Shared by several

organizations – Managed by the

organizations or a third party

• Public cloud– Available to the general

public or a large industry group

– Owned by an organization selling cloud services

• Hybrid cloud– composition of two or more

clouds that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability


8

Hardware

App AppAppApp

Normal Server Deployment

1) Two applications running under normal conditions

2) One application’s demand increased3) Server crashed, both applications down


9

Hardware HardwareHardware

Hardware VirtualizationHardware Virtualization

App AppAppApp

Virtualized Server Deployment

1) Two applications running under normal conditions

2) One application’s demand increased4) Application’s demand increased5) Application’s demand decreased6) Hardware server crashes,virtualization continues

3) Added third server, extended virtual server


10

Hardware Hardware Hardware

Hardware Virtualization Layer

Box

0(C

ontr

olle

r)

App App App App

Net

Disk

Cloud Virtualized Servers


11

“Cloud-First” Policy“The Federal Government’s current Information Technology (IT) environment is characterized by low asset utilization, a fragmented demand for resources, duplicative systems, environments which are difficult to manage, and long procurement lead times. These inefficiencies negatively impact the Federal Government’s ability to serve the American public.”

“Cloud computing has the potential to play a major part in addressing these inefficiencies and improving government service delivery. The cloud computing model can significantly help agencies grappling with the need to provide highly reliable, innovative services quickly despite resource constraints.”


12


13


13 14

Security must be addressed at each layer



14 15



15

USG Approach to Cloud Authorization – Risk Based

See http://www.gsa.gov/portal/category/102371

FedRAMP provides a means to ensure government use of the cloud is secure and minimizes costs to cloud providers

IOC – June 2012

http://www.gsa.gov/portal/category/102371


16

How Secure is the Cloud?

• We are using Google App Engine for SaaS application development: – Proven Reliability: Google App Engine is one

of the most secure enterprise services in the world

– Multiple layers of physical and virtual security

– Safer than most internal networks: With multiple layers of firewalls, sandboxed code, and software protection Google App Engine is more secure than most company networks


17

Advantages

• Reduce the total number of independent servers

• Individual applications are secured from one another (“Sandboxed”)

• Servers stored at secure locations• Only accessible on the secure network• Inexpensive• Scalable


18

Disadvantages• Scalability means “no-SQL” out of the box

– SQL Databases are designed for single servers or small clusters

– Caching data in memory becomes more important as it is inefficient (and expensive) for applications to read the database for common queries

– Requires understanding use cases ahead of time

• Software development cost is typically higher– Bleeding edge technology (changing everyday)– Requires significant new code – cannot just port

old code


19

Cloud Computing Bottom-Line• Enhances scalability• Enhances capability for large

collaborations on design and development throughout the lifecycle

• Upside: We can design more complex systems

• Downside: We will have to manage more complex systems development


Cloud Computing Implications for Systems Engineering

20

Complexity of the problem can not be masked by the complexity of the systems engineering


21

Cloud Computing Implications for Systems Engineering

• Larger, more complex systems development implies:– A need for larger, distributed teams– A need for a clear concise way to

express the system design (clear, logically consistent semantics)

– New tools to enable collaboration across the entire lifecycle

Complexity has been identified by many as a critical problem facing system engineers


22

Complexity • With the growth of the Internet and daily changes in IT, systems have become more complex and change more rapid than ever before

• Cloud computing gives us new tools to deal with these larger systems

• Systems engineering methods have not kept up with these changes

• SE has been relegated to the beginning of the lifecycle

From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011


23

How Does SE Typically Respond to Complexity?

• Focus on “architecture”• More complex languages• More complex procedures• More layers of abstraction

– “Systems of Systems”– “Family of Systems”– “Portfolio Management”

• Need more time and money!


24

More Money Is a Problem

• Calls for doing more with less continue

• Need for lower labor and tool costs essential for acceptance of SE across the lifecycle


How can we simplify things enable “quicker/ cheaper”? Let’s start with the language we use


25

State of Current “Languages”• In the past decade, the Unified Modeling

Language (UML) and now the profile Systems Modeling Language (SySML) have dominated the discussion

• Why?– Perception that software is “the problem”– Hence need for an “object” approach

• SysML was designed to relate systems thinking to software development, thus improving communication between systems engineers (SE) and software developers


26

Why Objects Are Not the Answer• Although SysML may improve the communication

of design between SEs and the software developers it does not communicate well to anyone else– No other discipline in the lifecycle uses object oriented

design and analysis extensively– Users in particular have little interest/acceptance of

this technique– Software developers who have adopted Agile

programming techniques want functional requirements (and resent SEs trying to write software)

– Many software languages are hybrid object and functional


Popular Software LanguagesPosition

Mar 2012Position

Mar 2011Programming

LanguageRatings

Mar 2012Delta

Mar 2011Functional/

Object/Hybrid

1 1 Java 17.110% -2.60% Object

2 2 C 17.087% +1.82% Functional

3 4 C# 8.244% +1.03% Hybrid

4 3 C++ 8.047% -0.71% Hybrid

5 8 Objective-C 7.737% +4.22% Object

6 5 PHP 5.555% -1.01% Hybrid

7 7 (Visual) Basic 4.369% -0.34% Hybrid

8 10 JavaScript 3.386% +1.52% Functional

9 6 Python 3.291% -2.45% Hybrid

10 9 Perl 2.703% +0.73% Hybrid

27

Trend to hybrid functional and object

From http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html accessed 4/6/2012

http://www.tiobe.com/content/paperinfo/tpci/Java.html

http://www.tiobe.com/content/paperinfo/tpci/C.html

http://www.tiobe.com/content/paperinfo/tpci/C_.html

http://www.tiobe.com/content/paperinfo/tpci/C__.html

http://www.tiobe.com/content/paperinfo/tpci/Objective-C.html

http://www.tiobe.com/content/paperinfo/tpci/PHP.html

http://www.tiobe.com/content/paperinfo/tpci/(Visual)_Basic.html

http://www.tiobe.com/content/paperinfo/tpci/JavaScript.html

http://www.tiobe.com/content/paperinfo/tpci/Python.html

http://www.tiobe.com/content/paperinfo/tpci/Perl.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html


28

So What Do We Do?

• Recognize that our primary job as SEs is to communicate between all stakeholders in the lifecycle

• Be prepared to translate between all the disciplines

• Reduce complexity in our language to facilitate communication


29

What We Did

• In preparing for the cloud computing world of SE we:– Researched the variety of languages (ontologies)

in common use (DM2, SysML, BPMN, IDEF, SREM, etc.)

– Researched the variety of representations (FFBDs, N2, Behavior Diagrams, Class Diagrams, Electrical Engineering Diagrams, etc.)

– Took the best of each of these languages and representations and distilled them down to the essential elements, relationships, attributes, and diagramsThe result: Lifecycle Modeling Language


LIFECYCLE MODELING LANGUAGE (LML) OVERVIEW

30

A language to simplify system design description for the cloud


31

The Lifecycle

Architecture Development

System Design

Hardware/Software Acquisition

Integration and Test

Operational T&E and Transition

Future Operations and Maintenance

Demolition and Disposal

Program Management

Current Operations and Maintenance

Desig

n &

Analysis

Inte

gra

tion

& V

eri

fica

tion


32

Lifecycle Modeling Language (LML)

• LML combines the logical constructs with an ontology to capture information– SysML – mainly constructs – limited ontology– DoDAF Metamodel 2.0 (DM2) ontology only

• LML simplifies both the “constructs” and ontology to make them more complete, yet easier to use

• Goal: A language that works across the full lifecycle


33

LML Ontology* Overview

• Taxonomy**: – 12 primary element classes– Many types of each element class

• Action (types = Function, Activity, Task, etc.)

• Relationships: almost all classes related to each other and themselves with consistent words– Asset performs Action/Action performed by

Asset– Hierarchies: decomposed by/decomposes– Peer-to-Peer: related to/relates

*Ontology = Taxonomy + relationships among terms and concepts** Taxonomy = Collection of standardized, defined terms or concepts


34

LML Taxonomy Simplifies and Enhances the Semantic Schema Elements• Technical

– Action– Artifact– Asset

• Resource

– Characteristic• Measure

– Input/Output– Link– Statement

• Requirement

• Programmatic/Technical– Cost– Decision– Location

• Physical, Orbital, Virtual

– Risk– Time


LML Sequencing

Action A Action BAction A

Action B

Action C

Condition 1

Condition 2

Action A

Action B

LOOP

Action A

Action C

Range

Range (e.g.) 1 to n (iterate)

Until r < z (loop)

PARALLEL

SEQUENTIAL

SELECTION

SY

NC

OR

Action C (Exit Criteria)L

OO

P

35

No constructs – only special types of Actions – ones that enable the modeling of command and control/ information assurance to capture the critical decisions in your model

Coordinated by Asset C


36

OR

LML Action Diagram Captures Behavior

Which path?

Action in ParallelAction

Start End

Trigger

SY

NCInput/Output 2

Synchronize Information

1.2

1.3

1.7

Action1.1 Optional Action 2 in

Loop

1.6

External Input

External Output

Input/Output 3L

OO

P

Exit Criteria

1.5

Optional Action 11.4

Input/Output 1


37

LML Physical Block Diagram*

Sensor Systems Operator

P.5.2.1

Asset (Human)

I.1.3 Operator-Sensor Platform InterfaceSensor Platform

P.5.2.2

Asset (System)

connected with/connects

Sensor System Memory

R.5.2.2.1

Asset (Resource)

used by/uses• capacity (10 Mbits/sec)• Latency (100 millisec)

• maximum quantity (6 Gbytes)• minimum quantity (10 Kbytes)

*Note: Work in progress


LML Combined Physical Behavior Diagram* Enables Instances and Clones

38

Sensor Systems Operator

P.5.2.1

Asset (Human)

I.1.3 Operator-Sensor Platform Interface

connected with/connects

Sensor Platform A(2)

P.5.2.2

Asset (System)

Asset (Resource)


P.5.2.2

Asset (System)

Asset (Resource)


P.5.2.2

Asset (System)

Asset (Resource) Clon

es p

rovi

de m

ultip

le in

stan

ces

of

an A

sset

for u

se in

sim

ulati

on

A.3.1

Action (System Function)

A.3.2

Sense Targets

A.3.1

Action (System Function)

A.3.1

Deploy Sensor

input to/input from

input to/input from

Deploy Command

*Note: Work in progress


39

LML Translation• Two types of mapping for tailoring:

– Map names of classes to enable other “schema” models to be used

– Map symbols used (e.g., change from LML Logic to Electrical Engineering symbols)

– Enable diagram translations (e.g., Action Diagram to IDEF 0)

LML Symbol

Electrical Engineering

BPMN …

AN

D

LML Class DM2 SysML …

Action Activity Activity

Asset Performer Actor


40

Other Diagrams

• Physical Block Diagrams– With option for icon

substitution

• Interface Diagrams– N2 (Assets or Actions)

• Hierarchy Diagrams– Automatically color coded

by class

• Time Diagrams– Gantt Charts– Timeline Diagram

• Location Diagrams– Maps for Earth– Orbital charts

• Risk Chart– Standard

risk/opportunity chart

• Organization Charts– Showing lines of

communication, as well as lines of authority

• Pie/Bar/Line Charts– For cost and

performance

• Combined Physical and Functional Diagram (?)


41 CHARACTERISTIC TIMELOCATION

LOCATION TIMECHARACTER ISTIC STATEMENT

LINK RISK STATEMENT

LINK RISK

causesmitigates

referenced byresolves

based ontakes

occurs

located atdefines protocol

forreferenced by

causesmitigatesresolves

based on occurs

causesincurred bymitigatesresolves

based onincurred by

occurs


ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION

ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION

referenced by

decomposed by decomposes

related torelates

referenced by

captured byconsumed by

performsproduced by

references

decomposed bydecomposesorbited by

orbitsrelated to

relates

causesreferenced by

resolvesreferenced by

incursreferenced by

referenced byspecified by

specifiesreferencesspecifies

ACTION

ARTIFACT

ASSET

CHARACTER-ISTIC

COST

INPUT/ OUTPUT

DECISION

LINK

LOCATION

ISSUE

LINK

LOCATION

RISK

ARTIFACT

ASSET

CHARACTERISTIC

COST

INPUT/ OUTPUT

RISK

STATEMENT

TIME


related torelates

references

capturesconsumes

performed byproduces

specified by

located at

STATEMENT

TIME

ACTIONincursgeneratesreceives

causesresolves

-

specified by incurs -causes

resolvesresponds to

connected by

occursbased on

referenced bysource of

located atcauses

mitigatesresolves

transferred by located at

specifies

decomposed bydecomposes

related torelates

incursspecifies

causesmitigatesresolvesspecifies

based onspecifies

specifies occurs

specifiescauses

resolvesspecifies

specifieslocated atspecifies

incurred bycauses

incurred byresolves

incurred by located atincurred byincurred byreferences

incurred byincurred byspecified by


related torelates

caused byresolved by

responded by

caused byresolved byspecified by

caused byincurs

resolved by

transferscauses

resolves

generated byreceived by

references - specified by incurs


related torelates

causesresolves

locates locates locateslocates

specified bylocates

based on occurs

caused bycauses

mitigatesresolved by

resolves


occurs

-defined protocol by

referencesconnected to specified by incurs


caused bycauses


related torelates

resolved by


located at


based ondelayed by

occurs


caused byreferences

resolved by

occurs

caused bymitigated by

referencesresolved by

caused bymitigated byresolved by

caused bymitigated byresolved byspecified by

caused byincurs

mitigated byresolved by

caused bycauses


related torelates

resolved by


relates

locates locates locates


related torelates

basis ofincurs


caused bycauses

mitigated byresolved by

resolves


located atmitigated by


related torelates

located at

locatesmitigates

based onlocates



related torelates

relates


taken by occurred by

occurred by occurred byspecified by occurred by

occurred by

basis ofcauses

resolvesbasis of

basis oflocated at

occurred by occurred bydelays

occurred byoccurred by related to related to


related torelates

basis ofbasis of

referencessourced by

basis ofbasis of

specified by

LML Relationships Provide Linkage Needed Between the Classes

• decomposed by/decomposes

• orbited by/orbits• related to/relates


42

Reducing Complexity by Association

ResourcesPictureOtherProgrammaticAction

Name

Number

Description

Select Icon

Icon

Type

Key Relationships

Inputs (receives/triggers)

Outputs (generates)

Statement (based on)

Children (decomposed by)

Asset (performed by)

Parents (decomposes)

trigger?YesNo

Duration (takes)


43

ResourcesPictureOtherAction Programmatic

Name

NumberRelations for Risk Analysis

List of Issues or Risks or None

causes: Issue or Risk

List of Issues or Risks or None

resolves: Issue or Risk

List of Risks or None

mitigates: Risk

List of Costs or None

incurs: Cost

List of Locations or None

located at: Location

List of Times or None

occurs: Time (TimeFrame or PointInTime)

Map It



44

ResourcesPictureProgrammaticAction Other

Name

Number List of Artifacts or None

references: Artifact

Peer-to-Peer Relationships

List of Actions or None

related to: Action

List of Actions or None

relates: Action

Context

Context

List of Characteristics or None

specified by: Characteristic



45

ResourcesPictureOtherAction Programmatic

Name

Number

List of Resources or None

captures: Resource (Asset subclass)


consumed by: Resource (Asset subclass)


produces: Resource (Asset subclass)

Relations for Resource Modeling

Amount



46

LML Summary• LML provides the fundamental foundation for a

tool to support SE in the cloud• LML contains the basic technical and

programmatic classes needed for the lifecycle• LML defines the Action Diagram to enable better

definition of logic as functional requirements• LML uses Physical Diagram to provide for

abstraction, instances, and clones, thus simplifying physical models

• LML provides the “80% solution”– It can be extended to meet specific needs (e.g.

adding Question and Answer classes for a survey tool that feeds information into the modeling)


47

Break


48

SUGGESTED LML PROCESSESThe cloud will require us to be more disciplined


49

Processes are key to success on the cloud

• Cloud computing enables participation in design across the planet

• Hence, common processes are needed to enable different practitioners to contribute to the design in a coherent manner

• The following processes are offered as a starting point for such development


50

Requirements Analysis

Functional Analysis and Allocation

Synthesis

System Analysis and Control

Middle OutBest Use: Architecture Development (To-Be)

Systems Engineering During Design Phase

Bottom Up

Top DownBest Use: “Classical SE”

Best Use: Reverse Engineering (As-Is)

Adapted from EIA-632

Note: On the cloud the customer participate in the requirements development process and as such may want to focus on a scenario-based approach



51

Source Documents

External Interface Database

User Needs

Decompose Statements

Critical Issue?

Statement Verifiable?

Determine Options and Perform Trade Studies

See System Analysis and Control for details

Resolve Issues with Customer

YES

NO

Coordinate Changes to Make Statement Verifiable

NO

Review Statements and Risks with Customer

Update Knowledgebase

YES

Identify Risks and Plan Mitigation

Updated Requirements

Traceability Matrix

Preliminary Test Requirements

Standards Selected

Change Requests

Architecture Knowledgebase

Note: On the cloud the customer can have direct access to the design and provide comments directly


52

Key LML Elements for Requirements Analysis Process

• Artifact– Types: Briefing, Change Notice, Change Request,

Concept of Operations, Directive, Doctrine, Document, Guidance, Instruction, Interface Control Document, Policy, Procedure, Requirements Document, Trade Study, …

• Statement– Types: Acronym, Composite, Constraint, Definition,

Directive, Doctrine, Functional, Goal, Objective, Performance, Plan, Policy, Question, Requirement, Rule, Scope, Standard, Statement, Vision

• Risk• Issue



53


Develop/Revise Context Diagram



Review Model and Risks with Customer


Updated Architecture

Knowledgebase

Develop Series of Scenarios for Analysis

Create/Update System Behavior Model

Analyze Behavior Model Performance

Behavior Model•Control Flow•Data Flow (Activity Model)•Performance Criteria

Allocate Actions to Assets and Input/Outputs to Links


Knowledgebase

Detailed Operational

Concept

Operational Requirements

Document (ORD)

Note: On the cloud risks can be identified and mitigated quickly due to enhance visibility


54

Key LML Elements for Functional Analysis Process

• Action– Types: Activity, Capability, Function,

Mission, Operational Activity, Program, Service Orchestration, Simulation Workflow, Subprocess, System Function, Task, Training, Work Process, Workflow

• Input/Output– Types: Analog, Digital, Event, Mixed,

Physical, Product, Verbal

• Time: Duration


Synthesis

55


Identify Component Assets

Optional Assets?



Select New Assets in Coordination with Customer

YES

NO

Review Design and Risks with Customer


Technology Insertion

Recommend-ations

Allocate Assets


Knowledgebase

Functional Requirements

Document (FRD)Design Diagrams

See Functional Analysis and Control for details

Transition Plan

Link to programsProgrammatic

Roadmap

Note: On the cloud the customer and SEs can interact directly with hardware & software providers to synthesis solutions more rapidly


56

Key LML Elements for Synthesis Process • Asset

– Types: Architecture, Assembly, Component, Context, CSC, CSCI, CSU, Element, Environment, External System, Facility, Hardware, Human, HW Element, HWCI, Infrastructure, LRU, Materiel, Operational Element, Organization, Part, Performer, Personnel, Segment, Service, Software, Subassembly, Subsystem, System, System Instantiation, Test Equipment, Test Software, Unit

• Link– Types: Cable, Downlink, Human-in-the-Loop, Human

Machine Interface, Interface, Landline, Link, Needline, Network, Pipe, Relationship, RF - Satcom, RF - Terrestrial, Roadway, Service Interface, Uplink, Wireless

• Location• Cost• Characteristic


Systems Analysis and Control

57

Identify Technologies, Methods and Needs for Study

Recommend Changes and Prepare Reports

Analyze Performance and Cost Effectiveness (Dynamic)

Assess Risk Probability and Consequence

Analyze Effectiveness, Use, O&M, Security, and Training Impacts

Updated Architecture Knowledgebase

Develop Metrics for Trades

Develop Risk Mitigation Approach

Trade Study Reports


Technology Insertion

Recommend-ations)

Note: On the cloud we will be able to accommodate large-scale simulations to perform the trade studies and verify performance


58

Key LML Elements for Systems Analysis and Control Process

• Characteristic– Types: Condition, Data Element,

Environmental, Functional, Performance, Physical, Scenario, Security, Verification Category

• Time: subclass Timeframe• Risk


59

LML TOOL NEEDSThe cloud will require new tools to make use of its potential for enhanced scalability and collaboration


60

LML Specification

• A complete specification and book are in development

• Considering standards bodies for promulgation (INCOSE?)

• May just make it an open “standard” allowing others to adapt and refine it


61

Tool for Vision for MBSE• Tool must be designed as a

MBSE tool using Lifecycle Modeling Language (LML)– All artifacts must be

produced from the tool using standard reports

• Tool must enable both seamless data flow and distributive, collaborative teams working on the same model

• Implies need for ability to scale “infinitely” on demand



62

Tool for Complexity• Tool must be designed for

use throughout the lifecycle, thus enabling end-to-end systems engineering– Legacy systems are a key

part of any modeling environment – LML has specific information classes for capturing designs at different times in one knowledgebase

• Tool must embed simulation, which enables real time simulations as well as the ability to scale “infinitely” to hundreds of server instances

• Tool must also reduce complexity by use of special input screens, which enhance configuration management as well



63

Tool for Multi-Decadal/Generation

• Tool must enable tracking of performance over time as Characteristics of the Assets

• Environments and conditions can also be captured as evolved over time and location (including orbital locations)

• Tool must evolve of the lifecycle of systems, but the data must be captured and reused throughout the lifecycle



64

Tool for Uses and Challenges • Tool needs to create a

CONOPS report based on scenario modeling

• Capture Issues and Decisions, as well as Cost for cost, schedule and performance tradeoffs

• TRL levels must be easily captured in the tool

• Software as a service provides inexpensive tool, while scalability enables fidelity level required; LML method enables rapid SE design and analysis

• Tool should automate what can be automated to reduce “wetware” requirements and enhance teaming



65

Tool for Uses and Challenges (continued)

• Tool should enable design down to detailed level (if desired), as well as V&V support

• Manufacturing enhanced by linking design to CAD/CAM systems (export design information as required)

• Use of XML files to import/export data from other design tools

• Design rationale, assumption and other programmatic information captured as part of Issues, Risk and other program-related elements of LML

• Standards should be captured and developed using the tool; enforcement by tailoring “personal trainer” version

• Operations data and obsolescence part of LML elements (Assets, Characteristics and Time)

• Use of a scenario-based approach enables better information capture from operators



66

Tool for Managing Complexity

• Tool in conjunction with a process should capture a reasonable number of scenarios for modeling and simulation, using a test matrix approach (move away from “peeling the onion”)

• Use “test matrix” approach to provide breadth of problem space, including failure modes, to capture the full functionality required

• Test must become even more dependent on simulation



67

Tool for Managing Complexity

• Tool should enable sharing of models, thus creating a “library” of component models

• Contributions should be made from academia (tool should be free access to academia) to this library

• Government sponsored research can also be made available to the NASA family via website



68

Key Tool Features Needed• Scalable Modeling• Scalable Discrete Event Simulation• Functional Behavior Diagrams• Physical Block Diagrams w/ Icons• Element Extractor/Automated Parsing• Splitting and Merging Requirements• Merge databases from other tools• Access to the web• Automated report writing• Enterprise data search• Customization• Collaboration• Configuration Management

No current tool meets all of these needs


69

Project Innovation

• SPEC is developing prototype software to test LML capabilities

• Working on using modern User Interface design to reduce remaining complexity (e.g. relationships)

• See SPEC Innovations booth for a demonstration


Why a new tool?Response to NASA’s Vision for MBSE

• SPEC’s prototype software is designed as a MBSE tool using Lifecycle Modeling Language (LML)– All artifacts can be produced

from the tool using standard reports (Java for speed) and JavaScript for specialty reports

• Cloud based (using Google App Engine PaaS) that enables both seamless data flow and distributive, collaborative teams working on the same model

• Ability to scale “infinitely” on demand70


* MBSE=Model-Based Systems Engineering


What is SPEC’s Prototype Software?• A tool to capture design, operations and

support information using systems engineering principles

• Applies cloud computing technology to model-based systems engineering techniques and discrete event simulation

• Implements the lifecycle modeling language (LML) and enables translation to UML, SysML, DoDAF (DM2), and other languages

71


What are the system requirements?

• Operating system– Any (Windows XP/7, MAC OS X, Linux)

• Devices– Any (PC, Mac, iPad, Android Tablet)

• Software– Any modern web browser (Google

Chrome, IE 9+, Firefox 5+, Safari)

72


What Will SPEC’s Prototype Software Produce?• Specifications for detailed design (in the languages

of the design engineers)• Concepts of Operations (and Support)• Processes and Procedures for Operations and

Training• Test and Evaluation Master Plans• Early Simulation/Design Validation• End-to-End Design Management and Collaboration• Repository of Analyses from Any Tool• Traceability from Requirements to Functions to

Components to Test to Operations to Support to Disposal

73


Requirements

74

Requirements quality checks with definitions

Trace to assets

Trace to higher level requirements


Visual Representations

• Hierarchy charts• Traceability charts• Action Diagram (Functional)• Asset Diagram (Physical/Interface)• Geo-Location view (maps)• Gantt chart (via simulator)

75


Entity editor

76


Database view

77


Chat

78


Simulation result

79


Geo-Location

80


Hierarchy Chart

81


Action Diagram

82


SPEC’s Prototype Software Features and BenefitsFeatures Benefits

Chat/Real-time Notification Enables collaboration worldwide

Lifecycle Modeling Language (LML) schema and Web User Interface

Provides simplicity and ease of use with little or no training

Open feature requests with voting on priority by users

Supports transparency between users and developers

Google App Engine’s cloud computing capability

Can scale design to deal with very large projects that include millions of objects

Nimbus security layer with Google App Engine security layer and SSL

Provides secure

Automatic upgrades; no installation; runs on any computer or device (e.g., iPad)

Reduces IT support costs and trouble significantly

Monthly payment plan Buy what you need, when you need it

83


Next Steps

• We look forward to your thoughts and ideas on how to improve the tool– Online feedback available when

released

• As a Software as a Service (SaaS) tool, we will deliver the capability on a monthly basis, if desired, at a low cost

84


85

Break


USE OF LML FOR ARCHITECTURE DEVELOPMENT

86

Architecture development on the cloud may focus on a middle-out/scenario-based approach to speed up the system specification process


14. Provide Options

Architecture Development Process and Products

87

5. Develop the Operational Context Diagram

15. Conduct Trade-off Analyses

6. Develop Operational Scenarios

1. Capture and Analyze Related Artifacts

4. Capture Constraints

3. Identify Existing/Planned Systems

2. Identify Assumptions

7. Derive Functional Behavior

8. Derive Assets

10. Prepare Interface Diagrams

12. Perform Dynamic Analysis

11. Define Resources, Error Detection & Recovery

13. Develop Operational Demonstration Master Plan

16. Generate Operational and System Architecture Graphics, Briefings and Reports


Functional Analysis

Synthesis


This implementation of the middle-out approach has been proven on a variety of architecture projects

AV-1

AV-2

OV-1OV-2

OV-3

OV-4

OV-5

OV-6

9. Allocate Actions to AssetsSV-1

SV-2SV-3

SV-4

SV-5SV-6

SV-7

SV-8 SV-9

SV-10

StdV-1 StdV-2

AV-1Draft DIV-2

DIV-3

DIV-1 CV-1CV-2

CV-3

CV-4

CV-5CV-6

CV-7

PV-2PV-3

PV-1

CONOPS


88

Key Architecture Products

• DoDAF Diagrams• Concept of Operations (CONOPS)• Functional Specifications of Hardware and

Software• Early Design Validation Through Modeling

and Simulation• Test and Evaluation Plans (for T&E)• Processes and Procedures (for Operations

and Support, as well as inputs to training plans)


89

Key LML Elements and Use - ArchitectureElements Use

Action Scenario analysis

Asset High level for gap analysis

Cost High level cost estimates - lifecycle

Characteristic Key metrics for performance/acceptance

Input/Output Key data elements

Link Critical interfaces (between systems of systems)

Risk Key schedule, cost, performance risks

Time - Timeframe Broad roadmap


90

• Add in slides on CONOPS report, ICD and other Nimbus SE report outputs


91

USE OF LML FOR SYSTEM DESIGN

The cloud will enable detailed designs together with the architecture analysis


92



Synthesis


Middle OutBest Use: Architecture Development (To-Be)

System Design Process

Bottom Up

Top DownBest Use: “Classical SE”

Best Use: Reverse Engineering (As-Is)

Adapted from EIA-632


93

Key Systems Design Products• System/Segment Specifications• Interface Control Documents• Detailed Integration and Test Plans


94

Key LML Elements and Use – System DesignElements Use

Action Functional analysis

Asset Design packaging

Cost Detailed cost estimates - lifecycle

Characteristic Specific metrics for performance/acceptance

Input/Output Data elements

Link Interfaces (between components)

Location Identifies differences due to location

Risk Schedule, cost, performance risks

Statement Key requirements

Time - Duration Key time dependences


95

USE OF LML FOR SOFTWARE DEVELOPMENT

Our cloud capability must include software developers as well


96

Support Object Analysis (if desired)

• Assets = Objects• Links = Relationships/Interfaces• Characteristics = Attributes• Actions = Methods

– Can include key logic algorithms


97

Otherwise – Support Functional Requirements Specification

• Actions• Input/Output• Packaging using Assets and Links


98

Key LML Elements and Use – Software DevelopmentElements Use

Action Functional requirements for methods

Asset Classes and/or packages

Characteristic Specific metrics for performance/acceptance

Input/Output Data elements

Link Interfaces (Inheritance between Classes)


99

Break


USE OF LML IN TEST AND EVALUATION

100

T&E on the cloud may occur early and often by starting with low fidelity simulations evolving to high fidelity simulations that may reduce the need for expensive testing


101

Coming Up the Vee

I&V Planning

Integration

Verification

Des

ign

Mon

itorin

g


Measure of Performance (MOP) View

102

Measure of Performance (MOP)

Type = MOPMOP 1.1

SystemType = System

System

MOP Test ResultType = MOP Occurrence

MOP 1.1 [System (SW1/HW1)]





System InstantiationType = System Instantiation

System (SW1/HW1)


System (SW2/HW2)


System (SW3/HW3)

instantiates /instantiated by


specifies /specified by

Characteristics

Assets

1:M

1:M

1:M



1:1 1:1 1:1

Measure of Effectiveness (MOE)

Type = MOEMOE 1

decomposed by /decomposes



1:1 1:1 1:1

System FunctionType = System Function

Function

tests /tested by

allocated to /performs

Actions

1:1

1:M


103

Key LML Elements and Use – Test and EvaluationElements Use

Action Test processes and procedures/ functional requirements for testing

Asset Test configurations

Cost Test costs

Characteristic (Technical Measurement subclass)

Specific metrics for performance/acceptance (MOEs, MOPs)

Input/Output Data elements for measurement

Link Interfaces (between components)

Statement Key requirements for testing


USE OF LML IN OPERATIONS AND SUPPORT

104

The cloud may enable our integration into the operational world more rapidly and transparently


105

LML Support Operations and Support Analyses

• Process Modeling• Simulation of Operations• Training Processes and Procedures• Operations Manuals• Logistics Analysis


106

Key LML Elements and Use – Operations and SupportElements Use

Action O&S processes and procedures

Asset Configurations

Cost O&S costs

Characteristic (Technical Measurement subclass)

Specific metrics for performance/acceptance (MOEs, MOPs)

Input/Output Data elements for decision making

Location Differences due to location


SUMMARY

107


108

People Considerations for SE on the Cloud

• Large teams make organization and focus on a vision very difficult– Need better ways to collaborate– Need process discipline, perhaps enforced by a tool

• You need people with a wide variety of skills and personalities– Someone with vision– Someone who can perform the detailed system

engineering– Someone who understands the domain– Someone familiar with the technique and tools– Someone who understands the process

• They need to be trained as a team – including the government personnel


109

SE on the Cloud Bottom-Line• The cloud provides a new capability to

deal with complex problems, but:– It requires new ways to communicate,

including a simplified language accessible to all stakeholders

– It requires discipline to ensure all designers have common standards enabled by processes

– It requires new tools that can take advantage of this new capability

• The cloud is in our near-term future … are you ready?