Enterprise Engineering Directorate (EE) DISA’s Transition to Model DISA’s Transition to Model Based Systems Engineering Based Systems Engineering (MBSE) (MBSE)
Enterprise Engineering Directorate (EE) DISA’s Transition to Model Based Systems Engineering (MBSE)
Dec 26, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Enterprise Engineering Directorate (EE)
DISA’s Transition to Model DISA’s Transition to Model Based Systems Engineering Based Systems Engineering
(MBSE)(MBSE)
2
AgendaAgenda
• Objective
• Improved practices
• Architecting processes
• Benefits of the approach
• DISA’s transition to Model Based Systems Engineering (MBSE)
ObjectiveObjective• Develop an integrated architecture for critical portions of
the GIG– Comprehensive
• Includes all essential capabilities
• Applies to all DoD Components
– Based on rigorous Systems Engineering principles• Such as those espoused by DoD 5000, INCOSE, etc.
• Traditional development practices have not produced the desired results for complex, large scale IT problems– Current artifacts do not routinely address critical analysis details
• Imprecise descriptions lead to different interpretations of the artifacts
– Focus is on generating artifacts rather than the underlying data• Improved techniques could provide input for better analysis
We Need to Understand How Systems WorkWe Need to Understand How Systems Work33
Improved PracticesImproved Practices• Adopt Model Based Systems Engineering (MBSE)
– Use the Object Management Group (OMG) Systems Modeling Language (SysML)
• Standards based, and therefore tool independent
• Derived from UML, a mature modeling language
• Executable (can generate code)
– Develop models that represent the capabilities• Use the models to simulate capabilities
• Store models in a single, common data structure
– Enhances our ability to use automation tools to generate standard artifacts from the common data source
• Consistent with DoDAF 2.0 architecture requirements
• Can lead to improved system specifications
– Industry is already moving in this direction
Can Reduce Cost & Improve PerformanceCan Reduce Cost & Improve Performance44
Requirements AnalysisAnalyze Missions and EnvironmentsIdentify Functional RequirementsDefine Performance & Design Constraint Requirements
Functional Analysis/AllocationDecompose to Lower-Level FunctionsAllocate Perf. Requirements to all Functional LevelsDefine/Refine Functional Interfaces (Internal/External)Define/Refine/Integrate Functional Architecture
Design/SynthesisTransform Architectures (Functional to Physical)Define Alternative System Concepts & System ElementsSelect Preferred Product and Process SolutionsDefine/Refine Physical Interfaces (Internal/External) Verify
Systems Engineering Process
Requirements Loop
Design Loop
VerificationLoop
InputNeeds/Req
Systems Analysis & ControlAlternatives Analysis
Tradeoff StudiesEffectiveness AnalysisInterface Management
Data ManagementCM
OutputDesign/Specs
Integrated Systems Management
Subsystem 1 Subsystem 2 Subsystem 3 Subsystem NProcess
Management
Project/Program Management
Risk Management
IA/Security Management
Change Management
Req. Change Management
Asset Management
Peer Review
Configuration Management
Quality Assurance
Integrated Systems and Software Engineering Process
Functional Architecture Definition
System Specification& Design
Integration, Testing Verification & Validation
Acceptance Testing, Certification &Accreditation
Requirements Analysis
Deployment, OperationTraining & Support
Systems Analysis & Control
- Concept Planning & Dev.- Trade-Off Studies - Market Research- Effectiveness Analyses- Interface Management- Data Management- Performance Measurement- Test & Deployment Planning
Subsystem Requirements Analysis
Functional Architecture Definition
System Specification& Design
Element Architecture
Test Planning
Software Acceptance Testing
Software Integrationand Testing
Procure, Develop & Integrate Subsystems
DISA Integrated Systems & Software Engineering Process
System Level
Subsystem Level
5
The Architecting ProcessThe Architecting Process• Derived from the acquisition process
(DoD 5000)• Early part of the Systems Engineering
(SE) Process– Involves decomposing the problem in
order to define a solution
• It is far more cost effective to address issues early in the SE process
Existing Architecting ProcessesExisting Architecting Processes
• Analysis framework is solid• Artifacts routinely lack specificity and are sometimes
ambiguous, which leads to various interpretations• Visualizing designs with this approach is labor intensive,
which makes it costly to update & synchronize artifacts6
Requirements AnalysisAnalyze Missions and EnvironmentsIdentify Functional RequirementsDefine Performance & Design Constraint Requirements
Functional Analysis/AllocationDecompose to Lower-Level FunctionsAllocate Perf. Requirements to all Functional LevelsDefine/Refine Functional Interfaces (Internal/External)Define/Refine/Integrate Functional Architecture
Design/SynthesisTransform Architectures (Functional to Physical)Define Alternative System Concepts & System ElementsSelect Preferred Product and Process SolutionsDefine/Refine Physical Interfaces (Internal/External) Verify
Output– Decision Database– System/Config Item Architecture– Specifications and Baselines
Document Based Systems Engineering Process (the old way)
Requirements Loop
Design Loop
VerificationLoop
Output Documents(loosely connected)Requirements DocumentConcept of Operations
Functional DecompositionFFBD/EFFBD, IDEF, DFD DiagramsProduct Breakdown Structure
Systems Decomp. DiagramsN2 ChartTest Plans
InputNeeds/Req
Output
Systems Analysis & ControlAlternatives Analysis
Tradeoff StudiesEffectiveness AnalysisInterface Management
Data ManagementCM
7
Architecting With Model Based Architecting With Model Based Systems Engineering (MBSE)Systems Engineering (MBSE)
• Uses the same architecting process
• Creates SysML models rather than developing documents
• Automation tools can be used to generate routine artifacts directly
• SysML provides 9 different types of diagrams to represent the architecture, which can be used to develop solutions• 4 behavioral• 4 Structural• 1 Cross-Cutting
Requirements AnalysisAnalyze Missions and EnvironmentsIdentify Functional RequirementsDefine Performance & Design Constraint Requirements
Functional Analysis/AllocationDecompose to Lower-Level FunctionsAllocate Perf. Requirements to all Functional LevelsDefine/Refine Functional Interfaces (Internal/External)Define/Refine/Integrate Functional Architecture
Design/SynthesisTransform Architectures (Functional to Physical)Define Alternative System Concepts & System ElementsSelect Preferred Product and Process SolutionsDefine/Refine Physical Interfaces (Internal/External) Verify
Systems Architecting and Engineering Process (model based)
Requirements Loop
Design LoopVerificationLoop
InputNeeds/Req
Ou
tpu
t
Block Definition Diagrams [BDD]
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Activity Diagrams [AD]
Sequence Diagrams [SD]
Use Cases [UC]
Requirements Diagrams [Req]
State Machine Diagrams [SMD]
Package Diagram [PKG]
SysML Diagrams
Structural Diagrams
Block Definition Diagram [BDD]
Internal Block Diagram[IBD]
Parametric Diagram[PD]
Behavioral Diagrams
Activity Diagram[AD]
Sequence Diagram[SD]
Use Case Diagram[UC]
Cross-Cutting Diagrams
State Machine Diagram [SMD]
Package Diagram[PKG]
Requirements Diagram [REQ]
Benefits of MBSEBenefits of MBSE• Models use common data sets
– Provides a consistent view of the architecture
– Can lead directly to system specifications & test plans
– Reduces systems integration and testing risks
– Promotes traceability– Makes it possible to identify gaps and
overlaps– Facilitates model reuse and integration
• Uses a standards based modeling language– Defines architectures that can be
simulated with standard tools– Models can be used with many
standards compliant automation tools• Automation tools are used to
generate artifacts– Less labor intensive to generate &
update
Structure
Behavior
Requirements
Parametric
Integrated Architectural Model
Block Definition Diagrams [BDD]
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Activity Diagrams [AD]
Sequence Diagrams [SD]
Use Cases [UC]
Requirements Diagrams [Req]
State Machine Diagrams [SMD]
Value Build
Allocate
Systems Analysis & Control (automated)
Outpu t
Package Diagram [PKG]
Verif
y
SatisfyInterface to M&S
Analysis Tools
(Opnet, XLS)
Test Planning
Integrated Systems Model
8
DISA’s Transition to MBSEDISA’s Transition to MBSE• Actions to date
– Training the Enterprise Engineering staff
– Updating our internal processes
– Developing a common data structure so that models representing individual capabilities can be integrated
– Developed a standard template with 9 standard SysML artifact types for documenting DISA capabilities
– Piloting the process by producing models & SysML artifacts for some select capabilities in the FY11 GIG Convergence Master Plan (GCMP)
• Planned actions– Transition remaining DISA program/project capabilities
– Update future versions of the GCMP with SysML artifacts
– Continue training DISA & DoD personnel
– Develop all new capabilities using MBSE9
SummarySummary
• Benefits of the MBSE approach– Models use common data sets
– Uses a standards based modeling language
– Automation tools are used to generate artifacts
• Expected result– Reduce technical documentation & lower cost
• We will be including some early piloting of this MBSE approach in the FY11 GCMP
10
www.disa.mil
Example of Architecture for Wireless CapabilitiesC
apab
ilitie
sS
ervi
ces Secure Mobile
Services for Smart Phones
Infr
astr
uctu
re
Application/Data Layer: Web Services, Content Repositories
DISN Core
Seamless and Secure Wireless Communication Services
Data
Connect to SIPRNET for Data Services
Cellular Networks
(GSM/CDMA)
Voice
Connect to DoD voice gateway for multilevel Secure Voice Service
Mobile Satellite Comm.
Extend DISN Services to tactical users via satellite
communications
Iridium
Mobile Wireless Comm.
Extend DISN Services to tactical users via wireless
communications
Wireless Extension
Handheld Wireless Devices
Access DISN Services via commercial cellular products w/ DoD security feature set
DISN Core
Does Not work under
water
Does Not work under
water
12
OV1 for SMS4SP
13
Trusted Users & Controlled Devices
DECC
Help Desk
Managed Service Provider
SIPRNETNIPRNET
Public Switched Network
SCIP HAIPE
Key IssuanceOver the Air
HAIPEINE
Apps Servers
Mail WEB Virus
Apps Servers
Mail WEB Virus
DATA Only
DataBase
Router
DATA Only
14
SAMPLE
15
SAMPLE
16SAMPLE
17
SAMPLE
GSM Example
101.02
Index
SAMPLE
GSM - UseCases Diagram
SAMPLE
GSM - Requirements Diagram
SAMPLE
Functional_Reqts_Allocation_and_Verification
SAMPLE
GSM_Domain - Block Definition Diagram
SAMPLE
GSM_Network - Block Definition Diagram
SAMPLE
BaseStationSubsystem - Internal Block Diagram
SAMPLE
GSM_Network – Internal Block Diagram
SAMPLE
Establish_Signalling_Connection
SAMPLE
Authenticate_User
SAMPLE
Location_Update
SAMPLE
Assign_Traffic_Channel
SAMPLE
MobileStation_BDD
SAMPLE
Voice_Uplink – Activity Diagram
SAMPLE
Mobile_Device_States
SAMPLE
GSM_Network_BDD
SAMPLE
GSM Network - Parametric Diagram
SAMPLE
BaseTransceiverStation – Parametric Diagram
SAMPLE
Instances
Instance01 Instance01[Package] bdd [ ]
areaCoverage = "1592500.0"bss = gSM_Network.bsscellphone = gSM_Network.cellphone[1]numberBaseTransceiverStations = "500.0"numberChannels = "15000.0"numberSubscribers = "900000.0"
«block»gSM_Network : GSM_Network
bts = gSM_Network.bss.bts[1]
«block»gSM_Network.bss : BaseStation_Subsystem
areaCell = "3185.0"channelsPerBaseStation = "30.0"frequenciesPerBaseStation = "3.0"range = "35.0"timeslotsPerFrequency = "10.0"
«block»gSM_Network.bss.bts[1] : BaseTransceiverStation
stdUsage = "1.0"
«block»gSM_Network.cellphone[1] : MobileDevice
Before Solution After SolutionSAMPLE
Package Diagram
SAMPLE
Related Documents
