Knowledge-Based Analysis and Design (KBAD): An Approach to Rapid Systems Engineering for the Lifecycle
1. Systems and Proposal Engineering Company
“A methodology for rapid, cost-
effective system engineering
and architecture development”
Knowledge-Based Analysis and
Design (KBAD): An Approach to
Rapid Systems Engineering for the
Lifecycle
2. Overview of presentation
• Why yet another “methodology?”
• What is KBAD?
• What theory underlies KBAD?
• What kind of tools work with KBAD?
• What process does KBAD implement?
• What kind of people do we need to execute
KBAD?
• How do we move from drawing pictures to
building a knowledgebase?
2
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
3. Why Yet Another Methodology?
• We have the DoD Architecture Framework …
– But DoDAF isn’t a methodology, its just a description of
necessary products
• We have UML …
– But UML is only a software engineering technique. You
have to come up with the process and tools for
implementing it
• We now have SysML …
– But SySML is just another technique and still needs more
definition to create complete, executable designs
• What’s missing?
– A complete, coherent technique, process, and tool set
that results in a knowledge base that can be used for full
lifecycle decision making
3
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
4. Knowledge-Based Analysis and
Design
• KBAD combines system engineering and program
management disciplines to enable the development
of a knowledgebase that can enable cost-effective
decision making
• KBAD spans the acquisition lifecycle enabling
support for design, development, integration, test,
operations and sustainment
• KBAD focuses on using a variety of techniques and
tools, brought together in a common database using
special software to migrate data between tools
4
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
5. Knowledge-Based Analysis and
Design
5
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
• The KBAD process links the technique and tools together in an
executable, cost-effective way to support decision making at
all levels
• KBAD reduces costs and increases speed of delivery by
simplifying the data captured and focusing on the analyses
needed for design.
• The result: a knowledge-base for decision making.
6. What makes up KBAD?
• Technique
– Modified Model-Based System Engineering (MBSE)
• Process
– SPEC Innovations’ Middle-Out Process for Architecture
Development and System Engineering
• Tools
– A variety of COTS tools tailored to the MBSE modifications
and special needs of DoDAF
• People
– Trained, experienced professionals who bring a wealth of
different backgrounds and knowledge in architecture,
system engineering, modeling & simulation, physics,
computer science, test & evaluation, operations & support
6
KBAD was
developed over
the past 15 years
and brings
lessons learned
from those years
of experience.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
7. The technique: refined MBSE
• Various forms of model-based system engineering
have been developed
• SPEC Innovations uses the one developed by TRW in
the late 1960s, which has been successfully used
since then
• SPEC Innovations has refined this technique by
simplifying the information collected (entities,
relationships and attributes) and adding a number of
key elements missing from the original development
• In addition, we are looking at the necessary logical
constructs and simplifying them
7
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
8. AND
3.1.1
Produce Collision and
Crash Avoidance Data
System Function
3.1.2
Carry-out Safety
Analysis
System Function
3.1.3
Process Vehicle
On-board Data
System Function
AND
collision_data
Digital
safety_data
Digital
vehicle_action_
requests
Digital
position_
warnings
Digital
emergency_
vehicle_priority
Digital
intersection_
collision_
avoidance_data
Digital
safety_
warnings
Digital
vehicle_and_
driver_safety_
status
Digitalfbv-vehicle_
data
Digital
vehicle_
location_for_
probe_data
Digital
roadway_and_
obsticle_data
Digital
fov-safety_
msg_data_
from_other_v...
Digital
tag_numbers
Digital
vehicle_status_
data
Digital
vehicle_traffic_
probe_data
Digital
tov-safety_
msg_data_to_
other_vehicles
Digital
Date:
Thursday, February 07, 2008
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
MBSE Models
8
1. Logical architecture
(behavior) model
• Functional sequencing
• Data flow and size
• Resource model
• Evolution in time
2. Physical architecture
(asset) model
• Interface definition
(bandwidth and latency)
• Actions allocated to
Assets
• Data allocated to
interfaces
VS-MCVS Interface
RS-MCVS Interface
83
Maintenance and
Construction Vehicle
System
20
Vehicle
System
13
Roadway Subsystem
Subsystem
Date:
Friday, February 08, 2008
Author:
Administrator
Number: Name:
MCVS Subsystem
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
9. Models are based on language
9
Language
Elements
English
Equivalent
KBAD Schema Example
Element • Statement
• Action
• Asset
• ...
Noun
Relationship • Statement is the basis of an Action
• An Action is performed by an Asset
• ...
Verb
Attribute • Description
• Type (e.g., Operational Activity is a type of
Action
• ...
Adjective
Attribute of
Relationship
• amount of Resource consumed by an Action
• acquire available (hold partial) Resource for
Action
• ...
Adverb
• Graphic Views: Behavior, Hierarchies, Physical
Block
Graphics/D
rawings
Structure Enables
Executability
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
10. We modified Vitech’s schema
10
KBAD Element CORE Elements Rationale
Action Function/Operational Activity Provide overall class for actions
Artifact Document Recognized not just documents
Asset Component/Operational Element Provide overall class for assets
Characteristic type of Requirement Way to capture metrics and other
characteristics of an element
Cost attribute of Component Broadens capture of costs
Input/Output Item/Operational Information Clearer name
Issue Issue Same
Link Link/Needline Provide overall class for transmission
Location none Captures geolocation information
Risk Risk Same
Statement type of Requirement Clearer name
Time attribute of Function Broadens capture of times
The goal was to simplify and clarify the language.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
11. We related all the KBAD schema elements
11
Reduced number of elements from 21* to 12, while adding time, location and cost
*CORE’s DoDAF schema
Action Cost Characteristic Artifact Asset Input/Output Link Statement Issue Risk Time Location
CORE
Equivalent
DoDAF Equivalent
Action decomposed by incurs specified by documented by
performed by
utilizes
inputs
outputs
triggered by
- based on generates resolves occurs located at Function
Operational Activity/
System Function
Cost incurred by decomposed by specified by documented by incurred by incurred by incurred by based on generates incurred by occurs located at New N/A
Characteristic specifies specifies decomposed by documented by specifies specifies specifies based on generates causes occurs located at New N/A
Artifact documents documents documents decomposed by documents documents documents source of generates causes occurs located at Document N/A
Asset
performs
utilized by
incurs specified by documented by decomposed by - connected by based on generates causes occurs located at Component
Operational Node/
System Node
Input/Output
input to
output from
triggers
incurs specified by documented by - decomposed by transferred by based on generates causes occurs located at Item
Operational
Information/Data
Link - incurs specified by documented by connects transfers decomposed by based on generates causes occurs located at Link Needline/Interface
Statement basis of basis of basis of stated in basis of basis of basis of decomposed by generates causes occurs located at Requirement N/A
Issue generated by generated by generated by documented by generated by generated by generated by generated by decomposed by causes occurs located at Issue N/A
Risk
caused by
resolved by
incurs caused by documented by caused by caused by caused by caused by caused by decomposed by occurs located at Risk N/A
Time occurred by occurred by occurred by occurred by occurred by occurred by occurred by occurred by occurred by occurred by decomposed by located at New N/A
Location locates locates locates locates locates locates locates locates locates locates occurs decomposed by New N/A
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
12. A key attribute – type
• We added a “type” attribute to all classes
• Each “type” attribute contains different
designators for the parent class
• Examples:
– Assets can have types that include:
• Operational Node, System, Component, Resource,
Subsystem, System of Systems, Component, …
– Actions can have types that include:
• Operational Activity, System Function, Task, Mission, …
• You can expand these lists to characterize
anything in that class
• When we display the element, we use the type
12
Using the type
attribute we reduce
the complexity and
ease changes
in perspective from
requirements
to implementation.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
13. Benefits of the KBAD Schema
• Reducing the number of primary data elements
means less complexity for analysts to deal with
– Less complexity enables quicker capture and
presentation of the information for analysis and
decision making
• Covers programmatic, as well as technical,
elements of information
– Enables the trade off between cost, schedule and
performance necessary for good design and decision
making
• Eliminates overlap between similar data
elements
– Reduces potential for duplication of information which
cuts the time and cost of data gathering
13
The result is a more
cost-effective means for
describing an
architecture or system
design.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
14. MBSE Describes Behavior
• Typical data/activity modeling
only works in the data
dimension (e.g. IDEF0 or Data
Flow Diagrams)
• For simple systems with
sequential flow, this is
sufficient
• However, for more complex
systems, which all architecture
are, it can be very misleading
• We need to be able to predict
how system will behave
14
“3”-Dimensions of
Behavior Analysis
FunctionalSequencing
Time
Data Flow
Architecture
Behavior
Architecture
Behavior
The missing dimensions:
resources, physical sizes of
data and interfaces
OV-5
SV-4
OV-6
SV-10
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
15. Why is sequencing important?
• In software the mantra is: data, data, data
– Why? Because a tremendous amount of software
programming has to do with input/output, hence the need
to understand the data very well
– The functional sequencing for individual software modules is
relatively simple and many algorithms exist for complex
methods (e.g., sorting algorithms)
• In architecture development (or system engineering or
business process modeling …) sequencing is actually more
important than the data
– We want to know how the data affects the functional
sequencing – we call these triggers
– We want to control the behavior to avoid having significant
failures
– We also need sequencing for the human side
15
Hence the real
answer is we
need both if we
are to develop
systems and
services with
predictable
behavior.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
17. Simplified KBAD Constructs
SEQUENTIAL
CONCURRENT (And)
DECISION POINT (Exclusive OR)
REPLICATE
Action A Action B
+
/Action A
(Decision Point)
Action B
Action C
Path1
Path 2
Action A
Action B
LOOP (or Iterate)
Action B
Action A
Range
with coordination
for n Instances of
Action A
Action A Action C
(Exit Criteria)
Action C
(Synch Point)
Action A
Action A(1)
Range
Action A(2)
Action A(n)
Range
1 to n (iterate)
Until r < z (loop)
18. AND
3.1.1
Produce Collision and
Crash Avoidance Data
System Function
3.1.2
Carry-out Safety
Analysis
System Function
3.1.3
Process Vehicle
On-board Data
System Function
AND
Date:
Thursday, February 07, 2...
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
One diagram gives many products
18
position_warnings
vehicle_action_
requests
safety_warnings
vehicle_and_
driver_safety_
status
tov-safety_msg_
data_to_other_
vehicles
vehicle_status_
data
vehicle_traffic_...
emergency_
vehicle_priority
intersection_
collision_
avoidance_data
3.1.1
Produce Collision and
Crash Avoidance Data
collision_data
3.1.2
Carry-out Safety
Analysis
safety_data
fbv-vehicle_data
fov-safety_msg_
data_from_othe...
roadway_and_...
tag_numbers
vehicle_location...
3.1.3
Process Vehicle
On-board Data
Date:
Thursday, February 07, 2008
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
3.1
Monitor Vehicle Status
Operational Activity
3.1.1
Produce Collision and
Crash Avoidance Data
System Function
3.1.2
Carry-out Safety
Analysis
System Function
3.1.3
Process Vehicle
On-board Data
System Function
Date:
Thursday, February 07, 2008
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
IDEF0:
lacks
constructs
N2 Chart:
lacks
constructs
Hierarchy: only
parent to child
FFBD:
lacks
dataText
EFFBD:
complete and
executable
OV-6c;
SV-10c
OV-5; SV-4
AND
3.1.1
Produce Collision and
Crash Avoidance Data
System Function
3.1.2
Carry-out Safety
Analysis
System Function
3.1.3
Process Vehicle
On-board Data
System Function
AND
collision_data
Digital
safety_data
Digital
vehicle_action_
requests
Digital
position_
warnings
Digital
emergency_
vehicle_priority
Digital
intersection_
collision_
avoidance_data
Digital
safety_
warnings
Digital
vehicle_and_
driver_safety_
status
Digitalfbv-vehicle_
data
Digital
vehicle_
location_for_
probe_data
Digital
roadway_and_
obsticle_data
Digital
fov-safety_
msg_data_
from_other_v...
Digital
tag_numbers
Digital
vehicle_status_
data
Digital
vehicle_traffic_
probe_data
Digital
tov-safety_
msg_data_to_
other_vehicles
Digital
Date:
Thursday, February 07, 2008
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
vehicle_traffic_probe_data
vehicle_status_data
vehicle_location_for_probe_data
vehicle_and_driver_safety_status
vehicle_action_requests
tov-safety_msg_data_to_other_vehicles
tag_numbers
safety_warnings
safety_data
roadway_and_obsticle_data
position_warningsintersection_collision_avoidance_data
fov-safety_msg_data_from_other_vehicles
fbv-vehicle_data
emergency_vehicle_priority
collision_data
3.1.1
Produce Collision
and Crash
Avoidance Data
3.1.2
Carry-out Safety
Analysis
3.1.3
Process Vehicle
On-board Data
Date:
Thursday, February 07, 2008
Author:
Administrator
Number:
3.1
Name:
Monitor Vehicle Status
OV-5; SV-4
19. MBSE also diagrams the physical
elements
19
Physical Hierarchy
Physical Block
Diagram
VS-MCVS Interface
RS-MCVS Interface
83
Maintenance and
Construction Vehicle
System
20
Vehicle
System
13
Roadway Subsystem
Subsystem
Date:
Friday, February 08, 2008
Author:
Administrator
Number: Name:
MCVS Subsystem
MCVS Subsystem
Subsystem
13
Roadway Subsystem
Subsystem
20
Vehicle
System
83
Maintenance and
Construction Vehicle
System
Date:
Friday, February 08, 2008
Author:
Administrator
Number: Name:
MCVS Subsystem
OV-2; SV-1; SV-2
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
20. Traceability is a key to success
documents documents documents documents documents
allocated to causes causes results in results in results in results in
Public Roads
July/August 2007
White Paper
A
Automated ITS
Project
Program
Automated Intelligent
Transportation
System Context
Architecture
Loss of Privacy
Other
Potential Resistance
by Organizations
Other
PR.1
Need for protected,
dedicated lanes?
S.1
Single car enters
roadway
Operational Activity
PR.2
Driver acceptance?
S.6
Single car traveling
sudden obstacle
Operational Activity
PR.3
Vehicle and highway
systems that operate
at a higher level of
reliability and perfo...
S.14
Worst case scenario
Operational Activity
PR.4
Increased liability for
manufacturers and
owner/ operators of
automated systems?
Proposed Liability
Legislation
Policy
PR
S
ch
S.
M
in
O
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
20
21. 21
Current tools support the technique and process
Software Design
Tools
(e.g. Rational Suite)
Test & Evaluation
Tools (e.g. M&S)
Operations &
Support Tools
(e.g. BPEL)
Requirements
Analysis Tools
(e.g. DOORS)
Functional
Analysis Tools
(e.g. Rational System
Architect)
Program
Management Tools
(e.g. MS Project)
Hardware Design
Tools (e.g. CAD)
Most Programs
Require Tools in
All These
Domains, but …
… they do not
interoperate
well together. SPEC Innovations’ KBAD methodology uses
CORE and MD Workbench to provide the
underlying tool interoperability.
CORE®
MD Workbench
PowerPoint
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
22. Tools used: CORE
• CORE's system engineering
tools maintain an integrated
design repository that provides
traceability between
requirements, functional
models and system design
elements
• CORE's database schema may
be modified to customize the
tool to support customer needs
and facilitate tool integration
• Executable diagrams
• Special schemas and reports
• Powerful scripting language for
your own report generation
22
www.vitechcorp.com
Version 7.0 released with new SysML
representations.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
23. Tools used: MD Workbench
Eclipse-based IDE for code generation
and model transformation, devoted to
implementing MDA/MDE strategies. It
provides:
– code generation (via text template
engine and optionally Java)
– model manipulation through
dedicated languages
– (imperative rules, declarative ATL
modules to support QVT
transformations, Java)
– model and metamodel management,
including UML support
– customizable model connectors (XMI
1.0 to 2.1, XML, Hibernate, COM, etc.)
23
http://www.mdworkbench.com
A great way to move data
between different tools.
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
24. Tools used: MS PowerPoint
Voice Request
to SL Assistant
SL Assistant Calls Non SL
Assistant
Pages Non SL
Informing a SL is
Calling
Accepts Call from SL
over non secure line
Non SL Assistant
receives call from
SL Assistant
Hello Mr.
President
25. SPEC Innovations processes – full
lifecycle
25
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
Design&Analysis
Integration&Verification
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
26. Design and analysis phase
26
Architecture
Development
System
Design
Hardware/Software
Acquisition
Integration
and Test
Operational
T&E and
Transition
Future
Operations and
Support
Demolition
and
Disposal
Program
Management
Current
Operations and
Support
Design&Analysis
Requirements
Analysis
Functional
Analysis and
Allocation
Synthesis
System Analysis
and Control
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
27. SPEC Innovations’ middle-out process
27
Requirements
Analysis
Functional
Analysis and
Allocation
Synthesis
System Analysis
and Control
Bottom
Up
Top Down
M
iddle Out
Best Use:
“Classical SE”
Best Use: Reverse
Engineering (As-Is)
Best Use:
Architecture
Development
(To-Be)
Adapted from EIA-632
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
28. Middle-out timeline with products
28
15. Conduct Trade-off Analyses
1. Capture and Analyze Related Documents
4. Capture Constraints
3. Identify Existing/Planned Systems
2. Identify Assumptions
8. Derive System Elements
10. Prepare Interface Diagrams
14. Provide Options
12. Perform Dynamic Analysis
13. Develop Operational Demonstration Master Plan
16. Generate Operational and System Architecture Graphics, Briefings and Reports
Requirements Analysis
Functional Analysis
Synthesis
System Analysis
and Control
The middle-out
approach has
been proven on
a variety of
projects.
AV-1
AV-2
OV-1
OV-2
OV-3
OV-4
OV-5
OV-6
OV-7
9. Allocate Functions to System Elements
SV-1
SV-2
SV-3
SV-4
SV-5SV-6
SV-7
SV-8 SV-9
SV-10
SV-11
Time
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
StdV-1 StdV-2
AV-1
Draft DIV-2
DIV-3
DIV-1 CV-1
CV-2
CV-3
CV-4
CV-5
CV-6
CV-7
PV-2
PV-3
PV-1
29. People Considerations
• Large teams make organization and focus on a
vision very difficult
• 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
29
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
30. How Do We Move from Drawing Pictures
to Building a Knowledgebase?
• Apply a proven, model-based technique that
results in executable diagrams
• Use a process that implements the technique
• Use industrial-strength system engineering tools
• Make sure the personnel who use the
methodology have the proper knowledge, skills
and abilities to implement the approach
30
@2010 Systems and Proposal Engineering
Company. All Rights Reserved.
Senior Leader Requests a Non-Secure Line to Call a Non SL.
SL sends a voice request to personal assistant to call a Non SL.
Personal assistant sets up a non secure line to Non SL assistant.
Non SL assistant receives call from SL assistant.
Non SL assistant pages SL about non –secure call from SL.
Non SL replies to assistant to accept call.
Non SL and SL talk over non-secure line.
SL sends voice request to personal assistant to contact Non SL via non secure line.
SL personal assistant contacts Non SL assistant over non secure line.
Non SL assistant receives non secure call from SL personal assistant.
Non SL assistant pages Non SL about non-secure call from SL.
Non SL replies to accept call and is connected to SL via non-secure line.
SE is involved throughout the life cycle
These plates indicate a review or gate that must be passed before you move to the next phase. Design reviews down the left side. Tests and reviews up the right.
An event driven example - A document is not ready until just before the review. Should you delay the review?
At the TRR, the system is certified that it does what it’s supposed to do.
The Pre-ship review or functional config audit
ORR is the final review before the customer/user receives it.
The customer is involved in the final set of reviews.