Why Use SysML? Eric A. Barnhart

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!

It’s all about the… communication!

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…

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

SysML Relationship To UML For more info… www.sysml.org 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

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

Our typical form of communications The dreaded “block diagram”

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

A little better?

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

Better yet

Even Better with Full Context

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

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.

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

“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

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.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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)

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

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