How long is a piece of string? Quantifiable aspects of Architecture Frameworks. Matthew Hause: PTC Lars-Olof Kihlström: Syntell AB

Transcription

1 How long is a piece of string? Quantifiable aspects of Architecture Frameworks Matthew Hause: PTC Lars-Olof Kihlström: Syntell AB

2 Presenters Matthew Hause: PTC GTM Solutions Specialist, Fellow at PTC Co-Chair UPDM Group at OMG Member of SysML development team OMG Architecture Board Member Consultant, trainer, mentor of MBSE and Enterprise Architecture Lars-Olof Kihlström: Syntell AB Principal consultant at Syntell Member of the UPDM group since its inception Project manager for the MODAF re-engineering work that resulted in MODEM Member of the NAF revision syndicate (while it existed), responsible for NAF 3.0 and 3. on behalf of the Swedish Armed Forces Member of the IDEAS group (while it existed) on behalf of the Swedish Armed Forces Primarily engaged as mentor, coach and developer concerning model based system engineering and enterprise architecture 2

3 Quantifiable aspects of MBSE and enterprise architecture Model-Based Systems Engineering (MBSE) means that communication of system requirements can be improved with models rather than relying on just words. The Systems Modeling Language (SysML) was developed by INCOSE and the Object Management Group (OMG) to enable MBSE. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. Systems engineers have been trying to get more out of their models by making them executable to answer questions or obtain results. The greatest concentration of work on executable models has concentrated on behavioral execution using code generation. This can also be done in modeling languages based on UML such as SysML and versions of the Unified Profile for DoDAF and MODAF (UPDM). 3

4 Is behavioral aspects all that is important? Behavioural aspects could be only a small part of the overall system requirements. Requirements can be non-functional, performance, structural, domain, cost, user interface, organizational, safety, interoperability and so forth. Rather than just considering models as execution of behavior, it is important to look at a model as a means of getting at quantitative and qualitative analysis results as well as behavioural ones. In order to fully grasp how different types of elements operate in different scenarios, it is important to take a look at aspects of use, performance, cost etc. from an overall point of view. Significant benefits can be realized by making use of architecture frameworks as a means of exploring these issues and tie the lessons learned from this into a direct MBSE development. In order to fully make use of quantifiable aspects a clear appreciation of what is meant is required. 4

5 UPDM version UML profile based MODAF v NAF v3.0. DoDAF.5 There was a bit of SysML in MODAF and the implementation of UPDM could choose between a pure UML or UML and SysML approach. UPDM contained both a profile as well as a domain meta-model that explained the meaning of the elements in the profile. 5

6 UPDM version 2 UML profile based MODAF v NAF v3. 2. IDEAS based DoDAF 2.02 There was still a bit of SysML in MODAF and the implementation of UPDM could choose between a pure UML or UML and SysML approach. UPDM contained both a profile as well as a domain meta-model that explained the meaning of the elements in the profile. 6

7 UPDM version 3 UML profile based MODAF v MODEM DMM 3.0 IDEAS based NAF v4.0 DoDAF 2.02 change DNDAF Other influences 7

8 Framework developments UPDM RFP requirement: The UPDM V3.0 domain metamodel shall be derived from MODEM and DM2, both of which are based upon the International Defence Enterprise Architecture Specification Foundation [IDEAS]. Mandatory requirements (excerpt): Provide Domain Metamodel (Abstract Syntax and Constraints) derived from MODEM and DM2 An Architecture Framework Profile Using SysML Enable the Expression Of Business Process Models Use of SysML Requirements Elements and Diagrams Use of SysML Parametrics Elements and Diagrams Mapped to Measurements Traceability Matrix to Supported Frameworks Non mandatory features (excerpt): UML Profile for NIEM Information Exchange Packaging Policy Vocabulary (IEPPV) Viewpoints in Support of SoS Life Cycle Processes and Analyses Support for Additional Viewpoints beyond those defined in DoDAF, MODAF/ MODEM, NAF, and the Security Viewpoint from DNDAF. Human Systems Integration (HSI) 8

9 Quantifiable aspects? IDEAS and MODEM is based on the mathematical concept of sets. 9

10 An example of a categorical property and measure 0

11 The SAR distress scenario

12 E3 Capability Dependencies (CV-4/ StV-4) Required Capability CV-4 [Capability] SAR «Capability» Search And Rescue Owning Capability DSM : Distress Signal Monitoring Inf : Inform Capability dependencies provide context for capability phases and resource deployment SC2 : SAR C2 MIC2 : Military C2 Capability Dependency Srch : Search Asst : Assistance Rec : Recovery 2

13 MODEM Capability Dependencies 3

14 Lp Actual Project (PV-2/ AcV-2) PV-3 [Architectural Description] Actual Projects «Project» SAR Manual Project I : Development startdate :00:00 enddate :00:00 responsibleresource «Organization» Department Of Transport : Government Department «Project» SAR Manual Project II : Development startdate :00:00 «ProjectSequence» enddate :00:00 responsibleresource «Organization» Department Of Transport : Government Department «Project» SAR Automation Project : Development startdate :00:00 enddate :00:00 responsibleresource «Organization» Department Of Transport : Government Department Actual Project «IncrementMilestone» MRU v INC enddate :00:00 resource «System» Maritime Rescue Unit v «DeployedMilestone» MRU v UK DEP enddate :00:00 resource «System» Maritime Rescue Unit v usedby «Organization» Maritime & Coastguard Agency «Organization» Volunteer Rescue Organization «DeployedMilestone» MRU v EU DEP enddate :00:00 resource «System» Maritime Rescue Unit v usedby «Organization» Coastguard «NoLongerUsedMilestone» MRU v NLU enddate :00:00 resource «System» Maritime Rescue Unit v nolongerusedby «Organization» Maritime & Coastguard Agency «Organization» Volunteer Rescue Organization «Organization» Coastguard «RetirementMilestone» MRU v OOS enddate :00:00 resource «System» Maritime Rescue Unit v «IncrementMilestone» MRU v2 INC enddate :00:00 resource «System» Maritime Rescue Unit v2 «DeployedMilestone» MRU v2 DEP enddate :00:00 resource «System» Maritime Rescue Unit v2 usedby «Organization» Maritime & Coastguard Agency «Organization» Volunteer Rescue Organization «Organization» Coastguard «NoLongerUsedMilestone» MRU v2 NLU enddate :00:00 resource «System» Maritime Rescue Unit v2 nolongerusedby «Organization» Maritime & Coastguard Agency «Organization» Volunteer Rescue Organization «Organization» Coastguard «RetirementMilestone» MRU v2 OOS enddate :00:00 resource «System» Maritime Rescue Unit v2 themevalues Equipment = Complete Training = Complete Concepts & Doctrine = Not Applicable Personnel = Complete Information = Complete Organization = Complete Infrastructure = Not Applicable Logistics = Complete Interoperability = Not Applicable «MilestoneSequence» «IncrementMilestone» ARU Beta Unit INC : Development Milestone enddate :00:00 resource «System» Automated Rescue Unit v «DeployedMilestone» ARU INC : Development Milestone enddate :00:00 resource «System» Automated Rescue Unit v «RetirementMilestone» ARU OOS : Development Milestone enddate :00:00 resource «System» Automated Rescue Unit v themevalues Equipment = Complete Training = Complete Concepts & Doctrine = Not Applicable Personnel = Complete Information = Complete Organization = Complete Infrastructure = Not Applicable Logistics = Complete Interoperability = Not Applicable Milestone Dependency Actual Milestone Definition of projects, subprojects, milestones and dependencies 4

15 Lp Project Detail (PV-2/ AcV-2) Project :00: :00:00 «Project» SAR Manual Project I : Development startdate enddate Resource Resource Used By responsibleresource «Organization» Department Of Transport : Government Department «DeployedMilestone» MRU v UK DEP enddate :00:00 resource «System» Maritime Rescue Unit v usedby «Organization» Maritime & Coastguard Agency «Organization» Volunteer Rescue Organization themevalues Equipment = Complete Training = In Test Concepts & Doctrine = In Progress Personnel = Complete Information = In Progress Organization = Complete Infrastructure = Complete Logistics = Not Applicable Interoperability = In Progress Organization/ Person Responsible Theme Statuses Milestone 5

16 Lp Themes 6

17 Lp Project Timelines Project Timeline Milestone Dependency Milestone Dashboard view provides project status at a glance: generated from model 7

18 AV-3 Measurements Definitions AV-3 [Architectural Description] Measurements (Class) Measurements Definition of metrics for reuse throughout the architecture. «MeasurementSet» «valuetype» Standard SAR Measurements «Measure» areacoverage : Coverage «Measure» findtime : Elapsed Time «Measure» persistence : Elapsed Time «Measure» searchcoverage : Coverage «Measure» weatherconditions : Weather Conditions Measurement Set Measurement Sub-Type «MeasurementSet» «valuetype» Maritime SAR Measurements «MeasurementSet» «valuetype» Land SAR Measurements «Measure» seaconditions : Sea State «Measure» terrain : Terrain Type 8

19 AV-3 Actual Measurements Specific metric values AV-3 [Architectural Description] Measurements (Actual) «ActualMeasurementSet» {intention = Estimate} Initial Values : Maritime SAR Measurements seaconditions : Sea State = Sea State 6 areacoverage : Coverage = 500 findtime : Elapsed Time = <8 hours persistence : Elapsed Time = >5 hours searchcoverage : Coverage = 400 weatherconditions : Weather Conditions = Heavy Rain «ActualMeasurementSet» {intention = Required} Required Values : Maritime SAR Measurements seaconditions : Sea State = Sea State 8 areacoverage : Coverage = 600 findtime : Elapsed Time = <5 hours persistence : Elapsed Time = >20 hours searchcoverage : Coverage = 500 weatherconditions : Weather Conditions = Stormy Actual Measurement «ActualMeasurementSet» {intention = Result} Final Values : Maritime SAR Measurements seaconditions : Sea State = Sea State 8 areacoverage : Coverage = 650 findtime : Elapsed Time = <4 hours persistence : Elapsed Time = >20 hours searchcoverage : Coverage = 550 weatherconditions : Weather Conditions = Stormy Estimate «ActualMeasurementSet» {intention = Estimate} UPDM : Standard SAR Measurements intention areacoverage : Coverage = 0 findtime : Elapsed Time = 20 persistence : Elapsed Time = 50 searchcoverage : Coverage = 60 weatherconditions : Weather Conditions = 70 Measurement Values 9

20 Ep Capability Phasing (Fragment) (CV-3/ StV-3) Timeline Capability Gap Capabilities Coverage Summarizes how and when capabilities will be realized as well as metrics. Identifies capability gaps. Capability Metrics Realizing Resource 20

21 Showing cost vs. time vs. capability (2) Pres 2

22 System Configuration Trade-Off Analysis bdd [Package] System Structure [Airborne System Structural Breakdown] Data Radio Ground Radio UAV Airborne Systems Owned System UAV Airborne Elements Simple UAV GPS Receiver values Mass : kg =. Power : W = 2 Sensors values Mass : kg = 0.5 Power : W = 0.2 Battery Power Supply values Mass : kg = 3.0 GPS 20 Sensors Power Supply Airframe Propulsion System Airframe values Mass : kg = 20 Propulsion System values Mass : kg = 22 Power : W = 0 Flight Control Hardware Flight Control Hardware values Mass : kg = Power : W = 22 Subsystem Value Properties Data Radio values Mass : kg =. Power : W =.0 Digital Data Radio Camera Digital Camera values Mass : kg =. Power : W =.0 Antenna Antenna Type values Mass : kg = 2.0 Power : W = 25 Onboard Computer Onboard Computer values Mass : kg = 0.75 Tranceiver Terminal Tranceiver Type values Mass : kg = 0.6 Power : W = 22 airsw Airborne Software 22

23 System configuration 23

24 System configuration 24

25 System Configuration Trade-Off Analysis 25

26 Parametrics Trade-Off Analysis Used to express constraints (equations) between value properties Provides support to engineering analysis e.g. performance, reliability, etc Constraint block captures equations Expression language can be formal e.g. MathML, OCL or informal Computational engine is defined by applicable analysis tool and not by SysML Parametric diagram represents the usage of the constraints in an analysis context Binding of constraint usage to value properties of blocks e.g. vehicle mass bound to F= m * a 26

27 SysML Parametrics Mean Response Time bdd [Package] Parametrics BDD for Mean Response Time Analysis Aircraft Values Context Boat and Yacht Values meanresponsetime : Hours rescuetime : Hours searchtime : Hours Aircraft helicopter values scanwidth : Miles speed : MilesPerHour yacht MeanResponseTimeAnalysis Boat values locationxy : Miles [2] speed : MilesPerHour values CommandCenter values signalresponsetime : Hours lifeboat command sea MarineEnvironment values conditions : Sea State totalarea : SquareMiles Command Center Values Environmental Values 27

28 SysML Parametrics Context par [block] MeanResponseTimeAnalysis_PAR command : CommandCenter meanresponsetime : Hours signalresponsetime : Hours Equation for calculating mean response times helicopter : Aircraft scanwidth : Miles speed : MilesPerHour width : Miles mst : MeanSearchTime constraints {t = area / 2 / speed / width} speed : MilesPerHour area : SquareMiles t : Hours searchtime : Hours t : Hours t2 : Hours t : Hours sea : MarineEnvironment trt : TotalResponseTime Property of System totalarea : SquareMiles area : SquareMiles seastate : Real constraints {t = t + t2 + t3} Value Property conditions : Sea State lifeboat : Boat speed : MilesPerHour mrt : MeanRescueTime constraints {t = 0.4 * pow(area,0.5) * pow(seastate,0.5) / speed} speed : MilesPerHour t : Hours rescuetime : Hours Parameter t3 : Hours Parametric Equation 28

29 SysML Parametrics Tradeoff Analysis Analysis0 : MeanResponseTimeAnalysis Initial values and ranges set by engineer. meanresponsetime : Hours searchtime : Hours rescuetime : Hours helicopter = RN_ASR_Helicopter lifeboat = RNLI_Lifeboat command = CommandCenter0 sea = Sea0 helicopter RN_ASR_Helicopter scanwidth : Miles = 0.25 speed : MilesPerHour =... command CommandCenter0 signalresponsetime : Hours = 0.5 Solution Values lifeboat RNLI_Lifeboat speed : MilesPerHour = 25.0 locationxy : Miles = 2.0, 5.0 sea Sea0 totalarea : SquareMiles = conditions : Sea State =

30 SysML Parametrics Solution Optimized solution provided by equation solver 30

31 L2 Operational Nodes (Performers) (OV-2) Context Operational nodes with needlines and flows Node Flow 3

32 L3 Operational Resource Flow Matrix (Fragment) (OV-3) Overlap Ov-2 Overlap Type DIV-2 Producing Performer OV-2 Producing Activity OV-5 Connection OV-2 Consuming Performer OV-2 Consuming Activity OV-5 Generated automatically from the architecture 32

33 Comms Metrics Definition and Instances 33

34 Messages with Added Metrics 34

35 Metrics 35

36 L2 Operational nodes 36

37 L2 Information flows 37

38 Conclusions The purpose of a model is to answer one or more questions Before you start, agree on the question Assessment criteria should be agreed prior to starting the model A well-documented process is essential for success Executable architectures should look at more than just behavior. Executing an architecture requires data (You can t execute a PowerPoint slide.) In order to ensure that the data is semantically correct a wash through an IDEAS based ontology is a good idea. 38

39 Questions, Comments, Discussion 39

40