Introduction to SysML af Finn Overgaard Hansen, AU


Published on

Præsentationen blev holdt ved InfinIT-konferencen SummIT 2013, der blev afholdt den 22. maj 2013 på Axelborg i København. Læs mere om konferencen her:

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to SysML af Finn Overgaard Hansen, AU

  1. 1. Intoduction to SysML– a modeling language for Systems EngineeringSummIT 2013,Axelborg 22. maj 2013Ingeniørdocent Finn Overgaard Hansen,foh@iha.dkDepartment of EngineeringAarhus UniversityVer. 22.5.2013
  2. 2. Slide 2AgendaSystems Engineering and SysMLWhat is SysML?New SysML concepts and diagrams1. SysML Requirements2. SysML Structure3. SysML Behaviour4. SysML ParametricPerspectives for SysML & Summary
  3. 3. Slide 3Model BasedSystems Engineering (MBSE)• From a document-based to a model-basedapproach• A model-based approach requires modelingconcepts and tools• MBSE: producing and controlling a coherentSystem Model• SysML is created to realize an MBSE approachbased on a System model of the wanted system• SysML is a modeling language not a SystemEngineering (SE) process
  4. 4. Slide 4What is SysML?• A graphical modeling language created inresponse to the UML for Systems EngineeringRFP developed by OMG and INCOSE.– a UML Profile that represents a subset of UML 2 withimportant extensions• Supports the specification, analysis, design,verification and validation of systems thatinclude hardware, software, data, personnel,procedures, and facilities• Supports model and data interchange via XMISysML is a Critical Enabler for Model Driven orModel Based Systems Engineering
  5. 5. Slide 5SysML Specification- History and Status• Nov. 1997: UML V1.1 launched by OMG• March 2003: The UML for Systems Engineering RFP(Request for Proposal) was developed jointly by OMG andINCOSE– The SysML specification was developed in responseto these requirements by the diverse group of toolvendors, end users, academia, and governmentrepresentatives• July 2005: UML V2.0• Sept. 2007: OMG SysML v.1.0• Nov. 2008: OMG SysML v1.1 (256 pages)• June 2012: OMG SysML v.1.3 ( 2012-06-01, 250 pages)
  6. 6. Slide 6System Model andHW/SW ComponentsSysMLUML
  7. 7. Slide 7Comparison of SysMLand UML
  8. 8. Slide 8SysML Diagram TaxonomySysMLDiagramBehaviorDiagramRequirementDiagramStructureDiagramBlockDefinitionDiagramInternalBlockDiagramPackageDiagramParametricDiagramUse CaseDiagramStateMachineDiagramSequenceDiagramActivityDiagramSame as UML 2.xModified from UML 2.xNew Diagram Type
  9. 9. Slide 9The 4 Pillars of SysML1:2: 3:4:
  10. 10. Slide 101. SysML Requirements• Requirement Diagram – a NEW diagram type• Graphical visualization of requirements– Functional– Non-functional• Requirements can graphical be related to:– Other requirements– Design elements– Test Cases• Standard stereotypes:– derive, satisfy, verify, refine, trace and copy– Used for requirement traceability
  11. 11. Slide 11Requirements Diagram (req) - Example
  12. 12. Slide 12Requirements Traceability - Example
  13. 13. Slide 132. SysML Structure• UMLs class concept is replaced with the Blockconcept• A Block connects to other blocks via Ports• Class diagrams are replaced with BlockDefinition Diagrams (bdd)• Each Block has an Internal Block Diagram(ibd) where the internal parts are connected viaports– a replacement for class composite diagrams• Ports can connect discrete as well ascontinuous flows of material or information
  14. 14. Slide 14Blocks are Basic Structural Elements
  15. 15. Slide 15Block Definition Diagram (bdd) - Example
  16. 16. Slide 16Internal Block Diagram (ibd) for anAutomobile DomainPort
  17. 17. Slide 17Block Definition Diagram (bdd) - Example
  18. 18. Slide 18Internal Block Diagram (ibd) - ExamplePartRunning the Vehicle Software
  19. 19. Slide 19Proxy Ports<>Ibd [Block] Camera [Nested flow]:Electronic Assembly:MPEG Converter:Image Processor:Video:MPEG4:Imagecamera i/o:CameraInterface:Light:Camera Module:Optical Assembly:Imaging Assembly:Light:Light:ImageProxy port«flow specification»Camera InterfaceflowPropertiesout digital video: MPEG4out analog video: Compositein control: Control Datain startup sig: Start Up
  20. 20. Slide 20Standard service based Ports (Full port)Monitoring StationCameraControl camera requestsgetCameraStatus(in cameraId: Integer, in cameraStatus: String)testCameras()panCamera(in strength: Integer)tiltCamera(in strength: Integer)operationsCamera Control«interface»ProvidedinterfaceRequired interface
  21. 21. Slide 213. SysML - Behavior• Activity diagrams are enhanced with newconcepts• Flows can be continuous and modelinformation as well as material flow• Control flows are introduced• SysML activities are based on token-flowsemantics related to Petri-Nets• Tokens corresponds to values of inputs, outputsand control• Activities can have pins (acting as a buffer)
  22. 22. Slide 22Activity Diagram (act) NotationFlows can be discrete, streaming or control
  23. 23. Slide 23Activity Diagram (act) - Exampleswimlanes
  24. 24. Slide 24Activity Diagram - decomposed:CollectImages:CaptureVideo:GenerateVideoOutputs«optional»current image{stream}captured image{stream}«optional»MPEG output{stream}«optional»Composite out{stream}act Operate Camera [Object Flow]Object flowvideo out{stream}input signal{stream}Have subdiagramsActivity parameternode
  25. 25. Slide 254. SysML Parametric• Parametric Diagram (par) – a NEW diagram type• Used to express constraints (equations) between valueproperties– Provides support for engineering analysis (e.g., performance,reliability)• Constraint block captures equations shown on a bdd– Expression language can be formal (e.g., MathML, OCL) or informal– A computational engine is defined by applicable analysis tool and notby SysML• Parametric diagrams represents the usage of theconstraints in an analysis context– Binding of constraint usage to value properties of blocks (e.g., vehicle massbound to F= m × a)• Parametric enable integration of engineering analysiswith design models
  26. 26. Slide 26BDD Parametric Constraint BlocksStereotype
  27. 27. Slide 27Parametric Diagram (par)- Example for a blockValue bindings
  28. 28. Slide 28Cross Connecting Model Elementsreq [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]Braking SubsystemSpecificationVehicle SystemSpecificationid=“102”text=”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”«requirement»StoppingDistanceid=”337"text=”Braking subsystemshall prevent wheel lockupunder all braking conditions.”«requirement»Anti-LockPerformance«deriveReqt»req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]Braking SubsystemSpecificationVehicle SystemSpecificationid=“102”text=”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”«requirement»StoppingDistanceSatisfiedBy«block»Anti-LockControllerid=”337"text=”Braking subsystemshall prevent wheel lockupunder all braking conditions.”«requirement»Anti-LockPerformance«deriveReqt»act PreventLockup [Activity Diagram]DetectLossOfTractionModulateBrakingForceTractionLoss:par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]:AccellerationEquation[F = ma]:VelocityEquation[a = dv/dt]:DistanceEquation[v = dx/dt]:BrakingForceEquation[f = (tf*bf)*(1-tl)]tf: bf:tl:f:F:ca:a:v:v:x:ibd [block] Anti-LockController[Internal Block Diagram]d1:TractionDetectorm1:BrakeModulatorc1:modulatorinterfaceStructure BehaviorRequirements Parametricsact PreventLockup [Swimlane Diagram]«allocate»:TractionDetector«allocate»:BrakeModulatorallocatedTo«connector»c1:modulatorInterfaceDetectLossOfTractionModulateBrakingForceTractionLoss:ibd [block] Anti-LockController[Internal Block Diagram]allocatedFrom«activity»DetectLosOfTractiond1:TractionDetectorallocatedFrom«activity»ModulateBrakingForcem1:BrakeModulatorallocatedFrom«ObjectNode»TractionLoss:c1:modulatorInterfaceibd [block] Anti-LockController[Internal Block Diagram]allocatedFrom«activity»DetectLosOfTractiond1:TractionDetectorallocatedFrom«activity»ModulateBrakingForcem1:BrakeModulatorallocatedFrom«ObjectNode»TractionLoss:c1:modulatorInterfacesatisfies«requirement»Anti-LockPerformanceibd [block] Anti-LockController[Internal Block Diagram]allocatedFrom«activity»DetectLosOf Tractiond1:TractionDetectorvaluesDutyCycle: PercentageallocatedFrom«activity»ModulateBrakingForcem1:BrakeModulatorallocatedFrom«ObjectNode»TractionLoss:c1:modulatorInterfacesatisfies«requirement»Anti-LockPerformancepar [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]:AccellerationEquation[F = ma]:VelocityEquation[a = dv/dt]:DistanceEquation[v = dx/dt]:BrakingForceEquation[f = (tf*bf)*(1-tl)]tf: bf:tl:f:F:m:a:a:v:v:x:v.Position:v.Weight:v.chassis.tire.Friction:v.brake.abs.m1.DutyCycle:v.brake.rotor.BrakingForce:par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]:AccellerationEquation[F = ma]:VelocityEquation[a = dv/dt]:DistanceEquation[v = dx/dt]:BrakingForceEquation[f = (tf*bf)*(1-tl)]tf: bf:tl:f:F:m:a:a:v:v:x:v.Position:v.Weight:v.chassis.tire.Friction:v.brake.abs.m1.DutyCycle:v.brake.rotor.BrakingForce:req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]Braking SubsystemSpecificationVehicle SystemSpecificationVerifiedBy«interaction»MinimumStoppingDistanceid=“102”text=”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”«requirement»StoppingDistanceSatisfiedBy«block»Anti-LockControllerid=”337"text=”Braking subsystemshall prevent wheel lockupunder all braking conditions.”«requirement»Anti-LockPerformance«deriveReqt»satisfy
  29. 29. Slide 29Project activities using SysML• Capture and analyze black box system requirements– System Context & System Use Cases, Requirement Diagrams• Develop one ore more candidate system architectures– Block Definition & Internal Block Diagrams• Perform engineering trade-off analysis to evaluate andselect the optimal architecture– Parametric Diagrams• Specify component requirements and their traceability tosystem requirements– Requirement diagrams• Verify the system design by executing system-level testcases
  30. 30. Slide 30Perspectives for SysML• Enable a common modeling language andmodel across engineering disciplines• Enable traceability between disciplines• Enable different kinds of system analysis• Enable integration of discrete and continuousbased modeling tools• Critical enabler for Model Based SystemEngineering with tool support
  31. 31. Slide 31Summary• SysML a common modeling language for differentdisciplines e.g. Hardware, Software and Mechanics• New and important concepts for cross disciplinaryanalysis of system properties (e.g. parametric)• Blocks and ports as general modeling elements• Important enhancement to activity diagrams• Lot of support for traceability between models and modelelements• Must be supported by an appropriate SystemsEngineering (SE) process
  32. 32. Slide 32References• OMGs SysML homepage:• INCOSE organization:• Books:– ”A Practical Guide to SysML – The System Modeling Language”,Sanford Friedenthal, Allan Moore, Rick Steiner, Elsevier, 2008.– ”Systems Engineering with SysML/UML – Modeling, Analysis,Design”, Tim Weilkiens, Elsevier, 2007.