1. Why Use SysML?
Eric A. Barnhart

2. Systems Engineering Communications!
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
Time Delay!

3. It’s all about the…
communication!

4. Communications and Learning
Verbal-Linguistic
Sharing words, writings, documents
Why are we stuck here?
Logical-Mathematical
Equations, drawings, MatLab models
Engineering discipline
Visual-Spatial
Pictures, charts, drawings
Approximately 30% of people!
Other methods too…

5. What is SysML? SysML is a graphical language
SysML is a method for communications
SysML emphasizes the SE domain
SysML is NOT a specific tool or methodology
Main Entry:
lan·guage       
Pronunciation:
\ˈlaŋ-gwij, -wij\
Function:
noun
1 … (2): a systematic means of communicating ideas or feelings by the use of conventionalized signs, sounds, gestures, or marks having understood meanings (3): … (4): … (5): a formal system of signs and symbols (as FORTRAN or a calculus in logic) including rules for the formation and transformation of admissible expressions

6. SysML Relationship To UML
For more info…
SysML
UML 2.0
Common Diagrams: Activity, Block Definition (UML2::Class), Internal Block (UML2::Composite Structure), Package, Sequence, State Machine, Use Case
New Diagrams: Parametric Constraint, Requirement

7. SysML Trivia SysML is a UML profile
Inherits the mature UML notation
Inherits UML “bloat”
Compatible with UML
SysML is SE domain specific, UML is general purpose
SysML abandons some of the software-centric aspects of UML

8. Our typical form of communications
The dreaded “block diagram”

9. Simplified Block Diagram
Track Target
Report Position
Order of operation?
Simulation
Federation
Relationship?
RT Clock
Executive
Interface?
What does a block diagram mean?????

10. A little better?

11. Try This Syntax A component A frame to group things
Ports – controlled points of interface
(with optional direction)
An Interface entity - Required
An Interface entity - Supplied

12. Better yet

13. Even Better with Full Context

14. Compare and Contrast
Block diagram with random or inconsistent meaning to symbols
Component diagram with well-defined syntax and grammar

15. Communications
The engineer must use a consistent, well-defined, and well-understood language to communicate the requirements and design to other engineers, otherwise the product will founder, fail, or be a disaster.
For the systems engineer, that language is currently SysML.

16. Ένα πρόβλημα με καλη σαφήνεια είναι μισό λυμένω
Axiom
Ένα πρόβλημα με καλη σαφήνεια είναι μισό λυμένω
Translations courtesy Haratini E. Andre

17. “A problem well-defined is half solved.”
Communicating Well
In order to communicate you must speak a common language
You must share the problem definition
Across cultures
Across space
Across TIME
“A problem well-defined is half solved.”
Lou Cohen

18. Matching the Language to the Problem
Verbal-linguistic methods for system definition
Writing specs, ICDs, SRSs, etc.
Logical-mathematical methods for system definition
Models, MatLab files
Visual-spatial methods for system definition
Pictures
Drawings
Charts }
Models too!
SysML is a suitable language, iff you model your system. If you don’t, then it won’t work.

19. Όλα είναι ελληνικά σε μένα
Is there a problem?
You have to speak the modeling language, otherwise…
Όλα είναι ελληνικά σε μένα
(It’s all Greek to me)
Translations courtesy Haratini E. Andre

20. INCOSE Orlando Presents:
Prerequisites
You must be able to use the language
You must model your system as a standard practice
“Speak” the language
Learn UML, SysML
Practice, practice, practice
Your boss must recognize the language
Never leave your boss in the dark
Never make your boss look stupid
Your boss must understand WHY you speak the language
Your customers (internal and external) must understand the language and the models
INCOSE Orlando Presents:
SysML Tutorial, June 8th
By Sandy Friedenthal
Lockheed Martin

21. The models they depict have enormous value to the SE process
Why model?
Model
depiction
information
System
describes 1+ 1
By themselves, drawings can have dubious value
Drawing
Define
Requirements
Design System
Implement
Integrate
The models they depict have enormous value to the SE process
Requirements
Model

22. Got Models? – Operational Concepts
Do you do analyze operational concepts?
Sample Use Case Diagram
Copilot /
Gunner
Track Target
<<extends>>
Scan by Pattern
<<extends>>
<<extends>>
<<extends>>
Autotrack Image
Select Track Mode
Drive Turret Manually

23. Got Models? - Requirements
Do you model requirements and their relationships?
Sample Requirements Diagram

24. Got Models? – Functional Decomposition
Do you do functional decomposition? (DoDAF SV-4)
Sample Activity Diagram

25. Got Models? – States & Modes
Do you analyze states/modes? (DoDAF SV10b)
Sample State Diagram
POWER APPLIED [ powerIsStable]
SELF TEST FAILED / STORE FAILURE DATA
TEMP REACHES OPT / ASSERT READY
ENABLE CMD RCVD
OPTIONS SET CMD(  )
[ options enabled ] / SET OPTION
OFF COMMAND RCVD / STORE DATA
TEMP FAULT
EXECUTE COMMAND[ safety confirmed ]
DISABLE CMD RCVD
Off Mode
Warmup Mode
Failure Mode
Standby Mode
Ready Mode
Fire Mode
EXECUTION COMPLETED
entry: emit 3 pulses
entry: Assert Not Ready

26. Got Models? – Event Traces
Do you trace events? (DoDAF SV-10c)
Sample Sequence Diagram
<<device>>
Keypad
<<device>>
AlphaNumericDisplay
<<device>>
ScrewActuator
<<device>>
ChangeDispenser
<<device>>
M.A.U
Credit
Chute
EnterLocation
DisplayMessage( code )
BuyProduct( selection )
GetPrice( selection )
CompareToPrice
DisplayMessage( error )
-end-
DispenseProduct( selection )
Turn
AcceptFunds
CalculateChange
DispenseAmount
resetAmount

27. Got Models? - Deployment
Do you deploy components onto processors?
Sample Deployment Diagram
(borrowed from UML)

28. Got Models? - Parametrics
Do you create parametric models?
Sample Parametrics Diagrams

29. SysML Drawing Summary SYSML DIAGRAM PURPOSE UML ANALOG
Activity diagram
Show system behavior as control and data flows. Useful for functional analysis. Compare Extended Functional Flow Block diagrams (EFFBDs), already commonly used among systems engineers. 
Block Definition diagram
Show system structure as components along with their properties, operations and relationships. Useful for system analysis and design.
Class diagram
Internal Block diagram
Show the internal structures of components, including their parts and connectors. Useful for system analysis and design.
Composite Structure diagram
Package diagram
Show how a model is organized into packages, views and viewpoints. Useful for model management.
Parametric diagram
Show parametric constraints between structural elements. Useful for performance and quantitative analysis.
N/A
Requirement diagram
Show system requirements and their relationships with other elements. Useful for requirements engineering.

30. SysML Drawing Summary - cont.
Sequence diagram
Show system behavior as interactions between system components. Useful for system analysis and design.
State Machine diagram
Show system behavior as sequences of states that a component or interaction experience in response to events. Useful for system design and simulation/code generation.
Use Case diagram
Show system functional requirements as transactions that are meaningful to system users. Useful for specifying functional requirements. (Note potential overlap with Requirement diagrams.)
Allocation tables*
*dynamically derived tables, not really a diagram type
Show various kinds of allocations (e.g., requirement allocation, functional allocation, structural allocation). Useful for  facilitating automated verification and validation (V&V) and gap analysis.
N/A
UML 2.0 Component, Communications, Object, Deployment, Interaction and
Timing diagrams have not been included in SysML

31. Leaving SysML at Home Don’t bother with SysML if..
your process is centered on writing nothing but textual specifications
you don’t model your systems
your management won’t read SysML diagrams
your customer won’t read SysML
all you want to do is say you’re using it

32. Bringing SysML to Work Selling SysML to systems engineers
Preaching to the Choir

33. Bringing SysML to S/W Engineers
Selling points
They’re probably already using UML
“now we can communicate better”

34. Bringing SysML to Management
Selling Points
Better communications
Reduced errors
“Easy to learn”
Break them in slowly
Interface to S/W
Improved integration
Solid, proven technology
Customers are asking for it
Competitors are using it
DON’T ask for a $20K tool up front
Use SysML manually first, buy the tool later
Some managers just don’t get it

35. EE’s generally won’t care
Bringing SysML to EEs
Chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken
EE’s generally won’t care
(neither will ME’s)

36. Getting Started – One Idea
Use the language any way you can
Visio, PowerPoint, etc.
Insinuate the language into existing work products
Drawings start appearing in specs
Control the document = control the drawing inside it
Do the analysis as part of the effort to write the CDRL
Make the managers want it
Buy the tool after SysML is part of your process

37. Why SysML? Standardized communications Improve life-cycle management
- across space
- across time
Improve life-cycle management
Capture the artifacts of systems engineering
Eliminate dreaded Block Diagrams