PDF to ppt same as the old one.

powerpoint presentation and need support to help me learn.

Requirements: 000
www.cranfield.ac.ukMSc in Systems Engineering.Module 02: Problem Analysis and System Definition – PASD
2MSc in Systems EngineeringModule 02: Problem Analysis and System Definition – PASDRick AdcockR.D.Adcock@Cranfield.ac.ukUnit 2 – Model Based System Definition (System Functions)Unit 2.2 Model Based System Functions Example Part 3aAim: Further Develop the E-MBSE Methodology•System Functions – Modelling the SoI solution options identify System boundary and required Functions•Apply to the module case study•Define and review SoI System Requirements
3System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))System Requirements respond to Concept Definition and are related to solution definition and architecture, and play a role in solution integration and acceptance. They are also used across the project to describe the SoI.System Requirements Primary Outcome (using the SEBoK definition) as:1.Define System Requirements for an identified SoI or (or SoI System Element), expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc. that will be necessary.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of systemarchitectureanddesignactivities.3.Form the basis of systemintegrationandverificationactivities.4.Act as reference forvalidationand stakeholder acceptance.5.Provide a means of communication between the various technical staff that interact throughout the project•Elicitation of stakeholder requirements starts in Concept Definition, and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.•Note, although defined as a single SR outcome above, SoI and SoI Elements requirements have different focus and inputs, in particular related to the link to Architecture. Hence, this should be seen to two closely related but different outcomes.
Analyse and Manage RequirementsRealise SolutionSoIOptionStakeholderRequirementsSystemRequirementsRequirementsManagementDefine System SolutionSystemRequirementsLogicalArchitectureSystemArchitectureAnalyseAlternativesDesignIntegration &VerificationDeploy CapabilityValidation &TransitionDeployment, Sustainment. Upgrade, DisposalEnterprise Context•Explores Enterprise Business/Mission Needs related to Capability Context•Propose candidate SoI contexts•Supported by Enterprise Modelling/StrategySystem of Interest Context•Analyse Requirements and Synthesis Solutions for each identified SoI … •… and related levels of SoI Elements•Used to realise Elements and Integrate SoI•Used to Deploy and Use CapabilityApply as needed for levels of SoI ElementShared** Systems Requirements are both analysed and defined as part of solution synthesis, and managed as part of requirements breakdownOperate Successful EnterpriseEnterpriseStrategyBusiness/MissionAnalysisFutureConceptE-MBSE MethodologySystem Functions
System EngineerIn-ServiceDefineConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilityProgramme ArchtectMission AnalysisUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerSystems EngineerRequirements ManagementBusinessAnalystCustomerProblemSystem EngineerProject ArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersAnalyseStakeholderRequirementsAnalyseSystemRequirementsAnalyseLogicalArchitectureSynthesisPhysicalArchitectureDefineMission AnalysisConductEnterpriseModellingDefineEnterpriseStrategyDefineSoIOptionAnalyseAlternativesManageRequirements<><><><><><><><><><><><><><><><><><>Systems EngineerRequirements EngineerElementDesignIntegrate/VerifyElementsTransition/ValidateSOI<>SustainModifyDispose<><><><><><><><>uc E-MBSE Methodology – System Functions
Project SE Engineer:System ArchitectPropose, synthesis & select between solution optionsSE (Arch.) & ModellingRolesRequirements ManagementEnsure coherent & Traceable RequirementsSE (Reqs) & ManagementDependabilitySpecialistEnsure solution is Dependable*Speciality knowledgeSystemsEngineersProgramme Architect:Mission AnalysisModel Mission & Stakeholder NeedsSE (MA) & ModellingProject SE Engineer:Verification & IntegrationEnsure solution can be built and testedSE (I&V) & modellingProject SE Engineer:In ServiceEnsure solution can be installed, used and evolvedSE ( Validation) & domainDesignerDesign specific technology elementsDomain knowledgeBusiness AnalysisModel Business contextModelling skillsOther DisciplinesMarketingWork with customers to win businessCommercial & technicalHRAcquire & Develop skillsSpecialist KnowledgeFinanceManage cost and budgetsCommercial skillsProgrammeManagementInitiate & run Programmesto deliver Enterprise OutcomesManagement & SystemsProjectManagementPlan and Control Projects to deliver OutputsManagement & SystemsProblemStakeholderHas needs related to a problem contextMay be non technicalEnterprise OwnerDefine Enterprise StrategyNon technicalStakeholdersEnd UserUse/support a solutionSpecific skillsCustomerProblemSets cost/time for selected problemProject OwnerSolution StakeholderHas needs related to a solution typeMay be non technicalCustomer AcceptanceSets time/cost & rules for solution acceptanceSolution Owner<>RoleSkills/knowledgeRequirements EngineerModel SoIcontext & define requirementsSE (Reqs) & Modellingbdd SE Enterprise Roles and Skills System Functions
Mission/Business AnalysisAnalyseStakeholder& NeedsRequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureDefine EnterpriseStrategyIdentify System ElementsAnalyseAlternativesEnterprise PlanningConcept DefinitionSystem DefinitionSystem RealisationEnterprise ModellingSystem DeploymentDefine ConceptVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, Disposalad E-MBSE Detailed Viewpoints System Functions (SoI level SR)Manage RequirementsSoI SystemsRequirements*Define SoI Option
8The SEBoK defines 11SR Process Activitiesbased directly on ISO/IEC/EII 15288.1.Analyzing the stakeholder requirements to check completeness of expected services andoperational scenarios, conditions, operational modes, and constraints.2.Defining the system requirements and theirrationale.3.Classifying the system requirements using suggested classifications.4.Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.5.Establishing the upward traceability with the stakeholder needs and requirements.6.Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy.7.Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.8.Validating the content and relevance of each system requirement against the set of stakeholder requirements.9.Identifying potentialrisks(or threats and hazards) that could be generated by the system requirements.10.Synthesizing, recording, and managing the system requirements and potential associated risks.11.Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))
9SF Viewpoint Modelling Process Summary1.Define one or more SoI Solution Option: SF-View 3a •A brief text description of each Option, SF View 3a, based on the Future Concept (SN-View 4 and 5) and will include an outline description and ontology for each option. We may use the MA technology survey and existing system architecture views to help shape the options towards future needs.2.Define a SoI context and relationships for each selected or proposed option: SF-View 1•This context is based on the relationships to the SoI defined in SN-View 5, considering only those relationships relevant to the SoI option are included•We can support the context (SF-View 1a) with a detailed option description and option related Ontology (View 1b)3.Model specific behaviour for each selected or proposed Option as needed: SF-View 2•For each SF View 1 we can create Static Behaviour (SF View 2a) and dynamic behaviour (SN View 2a) for the Option•These might be created from the SN View 2 views, or re drawn using solution modelling approaches. Might make use of SF views for previous solution, or be based on generic solution views.4.Expand aspects of SoI structure and behaviour as needed, SF-View 2. •These views use diagrams relevant to aspects of the SoI, e.g. People, Data, States, Timing and Sequence, etc.•These detailed behaviour views are used to review and enhance System Functions and can be re used as part of the solution architecture5.Review or select SoI Solution Options: SF-View 3b •If we have multiple options we can assess them against a set of criteria (based on stakeholder needs defined in SN-View 4) and perform a multi criteria selection. SF-View 3b provides a way to document this. To support this down selection, we can create model views to describe each option, using SF Views 1 and some of the SF View 2, in sufficient detail to support the selection. 6.Define System Functions: SF-View 4 •If an option has been selected for further modelling, we must complete the SF View 2 modelling to allow for System Functions elicitation•Initial functions (View 4a) come directly from the SF-View 2 activities and interfaces, reviewed and completed iteratively with the View 2 modelling•Functions are reviewed and expanded by detailed models, this includes a mapping of functions to Stakeholder Needs (View 4b)
SF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI ConceptExisting Architecture& legacy SF View if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function Viewpoint (Version 1)SF – View 1 Selected OptionMA View 5b SoI A Operation ConceptElement 1 Changes…Element 2 Ideas…Concerns …SN View 5c Ontology•Term X means ….SF View 1b Option DescriptionsSF View 1c Option OntologiesSF 4a/b FunctionsSoI Element 11.1 Function x1 on v…1.2 Function x2 with w …SoI Element 22.1 Function x3 for y …2.2 Function x4 to z … Overall SoI3 Comply with Standard ASN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views,SF-View 2c Detailed Ontology, e.g. Data, PeopleSF-View 2d Detailed Behaviour e.g. State, Sequence SF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Replace Element 2Option 2•Option A plus•Implement X in E1Option 3•Option 2 plus•Reduce Impact of YEtc.SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions Viewpoint
11System Function Viewpoint – ViewsPurpose•Define the Boundary and required interactions of each SoISolution Option:•Define or expand one of more SoI Solution Options, including down select of alternatives •Feedback on the Stakeholder NeedsViews•SF-View 1a SoI Selected Option Context•SF-View 1b SoI Selected Option Description/Ontology•SF-View 3a SoI Proposed SoI Options (each proposed options can be describe using View 1) •SF-View 3b SoI Proposed SoI Option Selection Traceability•Purpose, define System Function for each SoI Option:•Input to System Requirements•Provide an input to the Logical Architecture processes•Views•SF-View 2a SoI Solution Option: Required Static Behaviour•SF-View 2b SoI Solution Option: Required Dynamic Behaviour•SF-View 2c SoI Solution Option: detailed SoI ontology (e.g. data or people)•SF-View 2d SoI Solution Option: additional dynamic behaviour (e.g. state or sequence)•SF-View 4a: SoI Solution Option Statement of System Functions (or Activities)•SF-View 4b: SoI Solution Option System Requirements•SF-View 4c: SoI Solution Option Requirementto Stakeholder Requirement Mapping (or Need to Function)
SF View 1 Selected SoI Option StructureSF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Evolve existing Element 2Option 2•Option A plus•Implement X in E1Option 3•Option 2 plus•Reduce Impact of YEtc.SN View 5b SoI A Operation ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SF View 1b Option Descriptions•Option A selected, expanded description …..SF View 1b Option Ontologies•Option A specific ontology definitions and terms …..RS1RS2RS3SoI Option SF View 1a Selected SoI Option ContextSF View 3 Proposed SoI Options and Selection(used as needed to explore possible Options)SN View 5c Ontology•Term X means ….•Term Y means …SN View 1 Initiating SoI Concept StructureSF-View 3b SoI OptionsService 3SH1SN View 5a Expanded SoI ConceptSH2Capability 1SoI AElement 2Service 1Service 2SoI A Element 1
SF View 4b/c System RequirementsFunctions mapped to SoI relevant Stakeholder Need/ReqSF View 2a SoI Option Static BehaviourRS3SoI 1Use Case 1.1Use Case 1.2Use Case 1.3RS1RS2Use Case 1.2<>SH 1Ser 2SH 2Ser1:SoISN View 2b ConceptLevel 1 Dynamic BehaviourSH 1SH2S3SoIUse Case 1Use Case 2Use Case 3SN View 2a ConceptLevel 1 Static BehaviourSF 4a FunctionsSoI Element 11.1 Function x1 on v…1.2 Function x2 with w …SoI Element 22.1 Function x3 for y …2.2 Function x4 to z … Overall SoI3 Comply with Standard ASN View 3a & 3b, scenario specific behaviour available if neededSN View 2 Initiating SoI Concept BehaviourSF View 2 Selected SoI Option BehaviourSN View 4 Initiating Concept NeedsSF View 4 Selected SoI Option RequirementsFor each Selected Option Define Behaviour and Function (based on associated Concept, Behaviour and Needs)Service 3SH1SN View 5a Expanded SoI ConceptSH2Capability 1SoI AElement 2Service 1Service 2SoI A Element 1RS1RS2RS3SoI Option AE1E2SF View 1a Selected SoI Option ContextSF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Replace Element 2•Etc.SN View 5b SoI A Future ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SF View 2b SoI Option Dynamic BehaviourRS3RS2RS1SoISoI E1SoI E2Data
14Emergency Medical Example Part 3 – System Functions
15Case Study Part 2CONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAmbulance Update ProjectCONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAdvanced Mobile Medical Treatment ProjectExample Part 0Starts hereExample Part 1 And 2aStarts hereExample Part 0Ambulance Upgrade ViewsExample Part 3Mobile Treatment SoI ViewsExample Part 3Starts here
Systems Engineering Life Cycle and Processes (Further modified from SEBoK V2.0)Mission Analysis & Stakeholder RequirementsSystem Architecture& System DesignIntegration & VerificationSystem ImplementationTransition & ValidationUse, Support, Upgrade, DisposalActivityCONCEPTPRODUCTIONUTILISATIONRETIREMENTPRE CONCEPTSystem Requirements& Logical ArchitectureINITIALDEVELOPMENTFULLDEVELOPMENTStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewTRTRTRTRTRTRTRDetailed Technical Reviews (TR) as neededStage Reviews support Project DecisionsStage Review
17SF Viewpoint Modelling Process Summary1.Define one or more SoI Solution Option: SF-View 3a •A brief text description of each Option, SF View 3a, based on the Future Concept (SN-View 4 and 5) and will include an outline description and ontology for each option. We may use the MA technology survey and existing system architecture views to help shape the options towards future needs.2.Define a SoI context and relationships for each selected or proposed option: SF-View 1•This context is based on the relationships to the SoI defined in SN-View 5, considering only those relationships relevant to the SoI option are included•We can support the context (SF-View 1a) with a detailed option description and option related Ontology (View 1b)3.Model specific behaviour for each selected or proposed Option as needed: SF-View 2•For each SF View 1 we can create Static Behaviour (SF View 2a) and dynamic behaviour (SN View 2a) for the Option•These might be created from the SN View 2 views, or re drawn using solution modelling approaches. Might make use of SF views for previous solution, or be based on generic solution views.4.Expand aspects of SoI structure and behaviour as needed, SF-View 2. •These views use diagrams relevant to aspects of the SoI, e.g. People, Data, States, Timing and Sequence, etc.•These detailed behaviour views are used to review and enhance System Functions and can be re used as part of the solution architecture5.Review or select SoI Solution Options: SF-View 3b •If we have multiple options we can assess them against a set of criteria (based on stakeholder needs defined in SN-View 4) and perform a multi criteria selection. SF-View 3b provides a way to document this. To support this down selection, we can create model views to describe each option, using SF Views 1 and some of the SF View 2, in sufficient detail to support the selection. 6.Define System Functions: SF-View 4 •If an option has been selected for further modelling, we must complete the SF View 2 modelling to allow for System Functions elicitation•Initial functions (View 4a) come directly from the SF-View 2 activities and interfaces, reviewed and completed iteratively with the View 2 modelling•Functions are reviewed and expanded by detailed models, this includes a mapping of functions to Stakeholder Needs (View 4b)
18System Function Viewpoint – ViewsPurpose•Define the Boundary and required interactions of each SoISolution Option:•Define or expand one of more SoI Solution Options, including down select of alternatives •Feedback on the Stakeholder NeedsViews•SF-View 1a SoI Selected Option Context•SF-View 1b SoI Selected Option Description/Ontology•SF-View 3a SoI Proposed SoI Options (each proposed options can be describe using View 1) •SF-View 3b SoI Proposed SoI Option Selection Traceability•Purpose, define System Function for each SoI Option:•Input to System Requirements•Provide an input to the Logical Architecture processes•Views•SF-View 2a SoI Solution Option: Required Static Behaviour•SF-View 2b SoI Solution Option: Required Dynamic Behaviour•SF-View 2c SoI Solution Option: detailed SoI ontology (e.g. data or people)•SF-View 2d SoI Solution Option: additional dynamic behaviour (e.g. state or sequence)•SF-View 4a: SoI Solution Option Statement of System Functions (or Activities)•SF-View 4b: SoI Solution Option Function to Stakeholder Need Mapping
SF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI ConceptExisting Architecture& legacy SF View if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function Viewpoint (Version 1)SF – View 1 Selected OptionMA View 5b SoI A Operation ConceptElement 1 Changes…Element 2 Ideas…Concerns …SN View 5c Ontology•Term X means ….SF View 1b Option DescriptionsSF View 1c Option OntologiesSF 4a/b FunctionsSoI Element 11.1 Function x1 on v…1.2 Function x2 with w …SoI Element 22.1 Function x3 for y …2.2 Function x4 to z … Overall SoI3 Comply with Standard ASN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views,SF-View 2c Detailed Ontology, e.g. Data, PeopleSF-View 2d Detailed Behaviour e.g. State, Sequence SF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Replace Element 2Option 2•Option A plus•Implement X in E1Option 3•Option 2 plus•Reduce Impact of YEtc.SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions Viewpoint
20System Function Viewpoint – ViewsPurpose•Define the Boundary and required interactions of each SoISolution Option:•Define or expand one of more SoI Solution Options, including down select of alternatives •Feedback on the Stakeholder NeedsViews•SF-View 1a SoI Selected Option Context•SF-View 1b SoI Selected Option Description/Ontology•SF-View 3a SoI Proposed SoI Options (each proposed options can be describe using View 1) •SF-View 3b SoI Proposed SoI Option Selection Traceability•Purpose, define System Function for each SoI Option:•Input to System Requirements•Provide an input to the Logical Architecture processes•Views•SF-View 2a SoI Solution Option: Required Static Behaviour•SF-View 2b SoI Solution Option: Required Dynamic Behaviour•SF-View 2c SoI Solution Option: detailed SoI ontology (e.g. data or people)•SF-View 2d SoI Solution Option: additional dynamic behaviour (e.g. state or sequence)•SF-View 4a: SoI Solution Option Statement of System Functions (or Activities)•SF-View 4b: SoI Solution Option System Requirements•SF-View 4c: SoI Solution Option Requirementto Stakeholder Requirement Mapping (or Need to Function)
SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions ViewpointSF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI Conceptlegacy Views if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function ViewpointSF – View 1 Selected OptionSN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views ,e.g. Data, People, State, Sequence SN-View 2a Static ConceptSN-View 2b Dynamic ConceptSF-View 1a Option n SoI ContextSF-View 3b Option SelectionSN-View 4b StakeholdersSN-View 4a NeedsSF-View 2a Static Option SF-View 2b Dynamic OptionSF-View 4a and 4 b System Function & Mapping to NeedsSN View 5a SoISN View 5b Description
22SoI Option Context•Purpose•Define the Boundary and required interactions of each SoISolution Option:•Define one of more SoI Solution Options for the selected SoI Concept•Feedback on the Stakeholder Needs•Starting point for SoISystem Definition•Views•SN-View 5a SoI Expanded Concept, 5b Ontology and 5c Concept Definition (defined in the SN Viewpoint)••SF-View 1a SoI Selected Option Context•SF-View 1b SoI Selected Option Description/Ontology•SF-View 3a SoI Proposed SoI Options (each proposed options can be describe using View 1) •SF-View 3b SoI Proposed SoI Option Selection Traceability
TreatmentPlatformMedicalResponseSupportResponseControl RoomShare status & plansIncidentPatientRecoverGain AccessEmergency treatmentRecoveryControlMobileTreatmentMedical Response CentrePatient InfotransportProvideIncident InfoRecoveryCrewPatient DetailsEmergency MedicalResponseTreatmentControlRecoveryPlatformA&ETreatmentHospitalTreatmentProvide StatusHospitalHospitalAdminMobileMedical ActorIncidentControlLocationControlControlIncidentGather InfoIncidentEmergencyServicessupportGeneralPublicReport incidentReportIncidentControlStores & Maintain.Mobile TreatmentMedical RecoveryMay be linkedMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.SN-View 5a Improve Mobile Monitoring & Treatment (IMMT) ConceptExpanded Capability Context – valid for scenarios defined in SN Views 2e<> Mobile TreatmentConcept:•Share Monitoring•Extended Mobile Treatment•Consider Remote Treatment•Improve Data Link<> A&E Emergency TreatmentConcept:•Share Treatment Plan•Support Mobile Treatment•Conduct Remote Treatment•Improve Data LinkShared patient data
•The IMMT will provide the following, responding to the detailed Stakeholder Needs (Requirements?)•Patient Assessment:•Expand the sharing of Mobile patient data between Ambulance and A&E•Propose new A&E Assessment and Planning activities using mobile data•Add data link between Ambulance and A&E to enable sharing•Consider how to distribute Assessment between Ambulance and A&E•Patient Treatment:•Propose new mobile treatment in the Ambulance, using live assessment•Propose new A&E treatment in the Ambulance, using live assessment•Explore the addition of Remote treatment from A&E into the Ambulance, using data link•While consider the impact of the following:•Must continue to provide medical support to Recovery•The impact of all changes on Ambulance Support must be identified and managed•The impact on crew and other staff training must be identified and managed•Consider the challenges of the changing urban population and incident typesSN-View 5b: Improve Mobile Monitoring & Treatment SoI Expanded Concept Description (based on SN-View 1b)
•Routine Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling (e.g. transport of old or ill people to therapy or treatment, pregnancy check-up, etc.)•Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Emergency Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling in response Medical Incident•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents•Emergency Treatment: All patient treatment conducted by A&E staff•Patient Assessment: Gathering patient information and assessing their medical condition and treatment options•Mobile Assessment: Early Patient Assessment in the Ambulance, sufficient to support on-board treatment and to provide an starting point for A&E Assessment•Mobile Treatment: All patient treatment conducted in the Ambulance during patient recovery, this is an extension of Emergency Treatment constrained by available mobile resources. •Stabilisation: medical aid conducted by Ambulance staff, sufficient to allow safe transport (assessed against patient risk if not moved), for both routine and emergency recovery. This is a sub set of the more general mobile treatment, focus on improving survival during transport.•Remote Treatment: All patient treatment conducted in the ambulance using direct support or remote intervention from medical staff based in other locations, such as in A&E or other parts of the hospital.•Data Link: some mechanism by which useful data (including medical data) can be shared more fully between Ambulance and A&E. May be real time or periodic, could be voice, data, video, etc. as needed.SN-View 5b: Improve Mobile Monitoring & Treatment SoI ConceptExpanded Concept Ontology (based on SN-View 1c)
SF View 3a SoI Options Early Treatment Concept: These are the Options from the last Ambulance update projectThe following Mobile Assessment & Treatment (MA&T) Solution Options all satisfy at least some of the Needs for the Early Treatment Concept•MA&T Solution Option 1•Add Early Patient Assessment into the Ambulance•Add basic patient Stabilisation into the Ambulance to improve Recovery•Share the Assessment Data with A&E when Recovery complete (no live data link)•This should improve performance of the existing Emergency Treatment (no new treatments added)•MA&T Solution Option 2•Add Early Patient Assessment into the Ambulance•Add basic patient Stabilisation into the Ambulance to improve Recovery •Share the Assessment Data with A&E during Recovery using a live data link•Add additional A&E Treatment Options enabled by advanced Assessment Data•MA&T Solution Option 3•Add Early Patient Assessment into the Ambulance•Add basic patient Stabilisation into the Ambulance to improve Recovery •Share the Assessment Data with A&E during Recovery using a live data link•Add patient Treatment into the Ambulance to improve Emergency Treatment •Add additional A&E Treatment Options enabled by advanced Assessment Data and early treatment in the Ambulance •In Part 0 of the example we selected Option 1 only to take forward for development
The following Advanced Mobile & Remote Treatment (AMRT) Solution Options all satisfy at least some of the Needs for the IMMT Concept•Solution Option 1: include for continuity with previous iteration•Improve current option 1 with technology refresh•AMRT Solution Option 2 – modified Option•Keep or expand Early Patient Assessment into the Ambulance•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance to improve Emergency Treatment •Expand A&E Treatment Options enabled by advanced Assessment Data and early treatment in the Ambulance •AMRT Solution Option 3 – New Option•Keep or expand Early Patient Assessment into the Ambulance•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment •Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment •AMRT Solution Option 4– New Option•Create a Modular Early Assessment module, which can be integrated onto the Ambulance (or other mobility platforms)•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment•Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment •AMRT Solution Option 5– New Option•Create a new Mobile Treatment Platform to combine early treatment and shared assessment•Share Assessment Data and shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment•Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment SF-View 3a: Improve Mobile Monitoring & Treatment ConceptCandidate SoI solution Options for the IMMT Concept
The following Improved Mobile & Remote Treatment (AMRT) Solution Options all satisfy at least some of the Needs for the IMMT Concept•Solution Option 1: include for continuity with previous iteration•Improve current option 1 with technology refresh•AMRT Solution Option 2 – modified Option•Keep or expand Early Patient Assessment into the Ambulance•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance to improve Emergency Treatment •Expand A&E Treatment Options enabled by advanced Assessment Data and early treatment in the Ambulance •AMRT Solution Option 3 – New Option•Keep or expand Early Patient Assessment into the Ambulance•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment •Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment •AMRT Solution Option 4– New Option•Create a Modular Early Assessment module, which can be integrated onto the Ambulance (or other mobility platforms)•Share Assessment Data and Conduct shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment•Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment •AMRT Solution Option 5– New Option•Create a new Mobile Treatment Platform to combine early treatment and shared assessment•Share Assessment Data and shared Assessment with A&E during Recovery using a live data link•Keep of expand Mobile Treatment in the Ambulance and in A&E Treatment enabled by shared Assessment•Add Remote Treatment into A&E and the Ambulance to improve Emergency Treatment SF-View 3a: Improve Mobile Monitoring & Treatment ConceptCandidate SoI solution Options for the IMMT ConceptIn our example we will take option 4 and apply the SF Viewpoints to it.We can do this to better express the option, initiate a study or initiate a full developmentIn a real project we might well:•Have feasibility studies to expand Options 2, 3 and 4 to allow us to better choose between them•We would need to assess the business case for this in the real world•Run a research or technology demonstrator project to reduce the risks of Option 5 before considering it in a future iterationTrade study approaches and cost estimation are covered later in the course
29Concepts vs Options (as used in out E-MBSE Ontology)•An SoI Concept is a candidate Need or Opportunity related to the existing Capability and Stakeholder, e.g. Improve Early Treatment.•E.g. We need a completely new service, we wish to modify a service in a defined way, we need to modify a service and we have identified the elements of that service we think will be affected•The level of detail and degree to which the Concept includes suggestions for areas of solution depends on the type of Problem Situation and level of potential SoI (needs careful Systems Thinking!)•An SoI Solution Option is a proposed solution, identifying changes and additions to the SoI and its interfaces to related systems•Initial Options should be high level and independent of detailed solution choices (guided by the scope of the Concept). The first set of options may simply restate or focus on parts of the Concept •In practice we may identify Options first and then combine these into an overarching Concept to identify Scenarios and Needs, using this as the baseline to explore the Options•Option will get more detailed as we iterate between System Requirements and Architecture•Remember, the System Requirements Viewpoint may be defined by one or more Solution Providers, in response to a Concept and Needs defined by the Customer
SF View 1 Selected SoI Option StructureSF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Replace Element 2Option 2•Option A plus•Implement X in E1Option 3•Option 2 plus•Reduce Impact of YEtc.MA View 5b SoI A Operation ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SF View 1b Option Descriptions•Option A selected, expanded description …..SF View 1b Option Ontologies•Option A specific ontology definitions and terms …..RS1RS2RS3SoI Option AE1E2SF View 1a Selected SoI Option ContextSF View 3 Proposed SoI Options and Selection(used as needed to explore possible Options)SN View 5c Ontology•Term X means ….•Term Y means …SN View 1 Initiating SoI Concept StructureSF-View 3b SoI OptionsService 3SH1SN View 5a Expanded SoI ConceptSH2Capability 1SoI AElement 2Service 1Service 2SoI A Element 1
IBD SF-View 1a AMRT Option SoI ContextSF-View 1a: Advanced Mobile and Remote Treatment (AMRT) Option (4) – SoI ContextAdvanced Mobile & Remote Treatment Option SoI<>Incident Control<>Hospital Admin<>Ambulance Recovery<>Ambulance Control& SupportPatient DetailsSite AccessUpdatesPatient StatusAdmission RequestTreatment Plan updatesReports<>PatientPatient recordsPlan FeedbackExpert InputPatient InterfacePatient dataTreatmentEquipmentRemote TreatmentRecovered Patient<>AmbulanceMedicalCrewLocate PatientStabiliseSite Access<>A&EAssessment & TreatmentUpdates<>Modular MobileAssessment &TreatmentPatient dataTreatment Plan<>Hospital A&EPlanning & TreatmentPatient AssessmentTreatment PlanRemote TreatmentGuidance
•In this example we will begin with a solution Option based around option 4 above.•Create a Modular Early Assessment module, which can be integrated onto the Ambulance (or other mobility platforms)•Data sharing functionality will be provide for both the vehicle and A&E, to allow sharing of patient monitoring, and treatment plans.•The available mobile treatment in the current ambulance will be extended, to respond to the gap identified in the stakeholder needs. This may include the sharing of expert advice from A&E•Mobile Treatment will integrated into a modular solution compatible with the current ambulance, but with the potential to be integrated into other platforms•Existing A&E functions form a baseline for the new system (any changes to the existing A&E must improve its overall performance and work within existing hospital interfaces)•The possibility of Remote Treatment will be explored. This may require additional skills for the crew and additional onboard equipment. It might also place additional needs on the data sharing•All changes must fit into existing Ambulance Control and Support and wider Hospital interfaces with minimum changes.SF-View 1b: Advanced Mobile and Remote Treatment (AMRT) Option (4) – Option Description
•Routine Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling (e.g. transport of old or ill people to therapy or treatment, pregnancy check-up, etc.)•Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Emergency Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling in response Medical Incident•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents•Emergency Treatment: All patient treatment conducted by A&E staff•Shared Assessment: Gathering patient information and assessing their medical condition and treatment options from A&E•Mobile Assessment: Early Patient Assessment in the Ambulance, sufficient to support on-board treatment and to provide an starting point for A&E Assessment•Mobile Treatment: All patient treatment conducted in the Ambulance during patient recovery, this is an extension of Emergency Treatment constrained by available mobile resources. •Stabilisation: medical aid conducted by Ambulance staff, sufficient to allow safe transport (assessed against patient risk if not moved), for both routine and emergency recovery. This is a sub set of the more general mobile treatment, focus on improving survival during transport.•Remote Treatment: All patient treatment conducted in the ambulance using direct support or remote intervention from medical staff based in other locations, such as in A&E or other parts of the hospital.•Data Link: some mechanism by which useful data (including medical data) can be shared more fully between Ambulance and A&E. May be real time or periodic, could be voice, data, video, etc. as needed.SF-View 1b: Advanced Mobile and Remote Treatment (AMRT) Option (4) – Option Ontology
We cover Trade Studies and Formal System Analysis Activities in a later ModuleA simple matrix based multi criteria assessment method can be applied to any complex choiceCriteria are the most important aspect of any selection processHere we have used five of the Key Stakeholder Needs from the SN ViewpointWe would use detail Stakeholder Needs in a real projectOther criteria like Through Life costs, safety, etc., can be addedThere are many scoring methods, some of which we cover later.We have used a simple 1, 2 or 3 for each criteria. We have also added a weighting factor to allow some criteria to have more impact.Scores can come from individual stakeholders or key clients; might be supported by re visit of Scenario Views (SN 3)Comments allow clarification or justification of the scoresThe final score should guide the next decisions, but other factors and risks must be consideredIn our case we will explore Option 4 in more detail, but can simplify to Option 3 or extend to Option 5 if needed.
SF-View 3b: Improve Mobile Monitoring & Treatment ConceptCandidate SoI solution Options Selection TraceabilityDiscussion:Option 3 provides some improvement in key mission need at low risk (quick fix)Option 4 provides good improvement for medium risks (is this enough?)Option 5 offer max improvement but significant risk (can this be reduced?)We would also need an estimate of through life costs to make final selection
SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions ViewpointSF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI Conceptlegacy Views if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function ViewpointSF – View 1 Selected OptionSN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views ,e.g. Data, People, State, Sequence SN-View 2a Static ConceptSN-View 2b Dynamic ConceptSF-View 1a Option n SoI ContextSF-View 3b Option SelectionSN-View 4b StakeholdersSN-View 4a NeedsSF-View 2a Static Option SF-View 2b Dynamic OptionSF-View 4a and 4 b System Function & Mapping to NeedsSN View 5a SoISN View 5b Description
37SoI Solution Option Behaviour•Purpose, define the Boundary and required interactions of each SoI Solution Option:•Feedback on the Stakeholder Needs•Define or expand one of more SoI Solution Options, including down select of alternatives •Views•MA-View 7: Technology Forecast & SN_View 2: SoI Concept Behaviour (define in Stakeholder Needs Viewpoint), plus any legacy System Architecture Views•SF-View 2a SoI Solution Option: Required Static Behaviour•SF-View 2b SoI Solution Option: Required Dynamic Behaviour•SF-View 2c SoI Solution Option: detailed SoI ontology (e.g. data or people)•SF-View 2d SoI Solution Option: additional dynamic behaviour (e.g. state or sequence)
Originating ConceptRe draw for the SoI OptionBehaviour for previous SoI OptionExpand for the new SoI OptionWe could use either of these for the next stepDepends on the type of life cycle
ControlRecoverySupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentMobilitySupportResponseControl<>Emergency TreatmentRecoveryResponseControlIncident<>PublicReportuc SN View 2a (IMMT) Level 1AdmitPatientHospitalAdminTransportPatient<><>A&EMobile TreatmentMobile TreatmentResponse<><><>SN-View 2a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 1– – valid for scenarios defined in SN Views 2eMeet Interaction Standards and RulesExternalAuthorities<><>
ControlRecoverySupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentResponseControl<>UpdatedEmergency TreatmentControlIncident<>PublicReportuc SN View 2a (IMMT) Level 1AdmitPatientHospitalAdminTransportPatient<><>A&EAdvancedMobile TreatmentMobile TreatmentModule<><><>Meet Interaction Standards and RulesExternalAuthorities<><>AmbulanceSupportAmbulancevehicleSF-View 2a: Advanced Mobile and Remote Treatment (AMRT) Option 4 SoI Required Static BehaviourInterface toPlatform<>
IncidentControlA&EPublic/EmergencyServicesMobile Medical ResponseSystemRecovery ResponseSystemResponseControlReport IncidentIncident Planning ResponseReportSecure PatientTransport PatientUnload PatientLocate PatientMonitorPatientAssess PatientA&E TreatmentHospitalReleasePatientAdmitPatientIncidentReportResponseSupportPrepareVehiclesPlan TreatmentMobileTreatmentProvide Clearance & AccessDeployMedical ResponseDeployRecovery ResponsePlanResponseLocate PatientNavigate toIncidentNavigate toIncidentRe SupplyVehiclesEnsureSafe/SecureLocationSN View 2b IMMT Concept Level Emergency Treatment & Recovery Move PatientMonitorPatientRequestRecoveryStabilise PatientRemotelyControlledTreatmentEnsure Compliance & trainingFirst AidSN-View 2b: Improved Mobile Monitoring & Treatment (IMMT) Concept Dynamic Behaviour Level 1––– valid for scenarios defined in SN Views 2e
ad: Mobile Assessment and Treatment – Option 1A&E TreatmentAmbulance TreatmentSoI ElementAmbulanceRecoveryAmbulanceControlResponseReportAssess PatientA&E TreatmentHospitalReleasePatientAdmitPatientAmbulanceSupportPrepareVehiclesPlan TreatmentPlanResponseRe SupplyVehiclesMove PatientLocate PatientNavigate toIncidentAssessPatientTransport PatientUnload PatientStabilise PatientInitial PatientAssessmentReportDeployResponsePatientMobilePatientResponseA&EPatientResponseTreatment CompleteTreatmentPlanPatientAssessmentPatientDataAssessInterfaceAssessDataTreatmentActionMobility Assess &TreatmentA&E Assessment& TreatmentSF View 2b – Mobile Assess & Treatment SoI (MA&T) – SoI Behaviour Existing SolutionPatientHandoverStabiliseAction
A&E Assessment& TreatmentMobility Assess &Treatmentad: Advanced Mobile Assessment and Treatment – Option 5AdvancedA&E TreatmentAmbulance TreatmentSoI ElementAmbulanceRecoveryAmbulanceControlResponseReportAssessMobile PatientHospitalReleasePatientAdmitPatientAmbulanceSupportPrepareVehiclesPlanResponseRe SupplyVehiclesMove PatientLocate PatientNavigate toIncidentTransport PatientUnload PatientTreat MobilePatientDeployResponsePatientMobilePatientResponseA&EPatientResponseTreatment CompletePatientAssessmentPatientDataAssessInterfaceAssessDataTreatmentActionTreatmentActionAdvancedPatientAssessment& PlanningAdvancedA&E TreatmentProvideInterfaceConnect viaInterfaceSF-View 2b: Advanced Mobile and Remote Treatment (AMRT) Option 4 SoI Required Dynamic Behaviour – Version 1
ad: AMRT Option Dynamic BehaviourA&E Treatment(including updated SoI Elements)Modular Mobile Medical SoI ElementAmbulanceRecoveryResponse/ControlResponseReportMonitor & Assess MobilePatientAdvancedPatientAssessmentConductA&E TreatmentHospitalReleasePatientAdmitPatientResponseSupportPrepareVehiclesPlan TreatmentPlanResponsePlanRe SupplyVehiclesRemoteTreatmentMobileTreatmentMove PatientLocate PatientNavigate toIncidentMonitorPatientTransport PatientUnload PatientStabilise PatientPatientDataRemote ActionsDeployResponsePatientMobilePatientResponseA&EPatientResponseTreatment CompleteA&ETreatmentPlanPatientDataPatientDataPatientDataPatientInterfaceMonitorDataTreatmentActionMonitorInterfaceMonitorDataTreatmentActionMobility AssessmentA&E TreatmentA&E Assessment& PlanningSharedTreatment PlanPrepare TreatmentSF-View 2b Advanced Mobile & Remote Treatment SoI (AMRT) – SoI Behaviour Solution Option 4 version 2Treatment CompleteApplyComms & InteractionStandardsData Sharing in orange will required additional Data LinkMobility TreatmentProvideInterfaceConnect viaInterface
<>MobileIBD SF-View 1a AMRT Option SoI ContextSF-View 1a: Advanced Mobile and Remote Treatment (AMRT) Option (4) – SoI Context Version 2Advanced Mobile & Remote Treatment Option SoI<>Incident Control<>Hospital A&ETreatment<>Ambulance Recovery<>Ambulance Control& SupportPatient DetailsSite AccessUpdatesReports<>A&EAdvancedShared Assessment<>MobileMonitoring<>PatientPatient InterfacePatient dataA&E TreatmentEquipmentPatient dataRemote TreatmentGuidanceRecovered Patient<>AmbulanceExistingMedicalCrewStable PatientStabiliseSite Access<>MobileTreatmentMobile TreatmentTreatment Plan<>Data LinkProvides al secure live data sharing<>Hospital A&ETreatment Planning<>A&EPrepare TreatmentRemoteTreatmentPatient AssessmentTreatment Plan<>ModularInterface
ConductEmergencyTreatmentAssessA&EPatientPatientsPublicA&E SustainmentProvideUpdatesConductMobileTreatment<>ConductRemoteTreatment<>AdmitPatientTransferPatient<>HospitalAdminControlTreatmentResponsePrepare/SustainAssetsAmbulanceControlAmbulanceSupportAmbulanceVehicleA&EInfrastructureEstablish AppropriatecommunicationGovt.CommsStandard<><>Conduct AppropriateInteractionsHospitalTraining<>A&EDoctorA&EAdminEnsureCompatibility<>ReleasePatient<>DeployMedicalResponse<><><>Emergency Treatment Service (with AMRT)uc SF View 2a AMRT Option – Level 2 BehaviourAssessMobilePatient<><>Share Real-TimeAssessmentAmbulanceData Link<>MobileStabiliseModularMobileTreatmentSF-View 2a: Advanced Mobile and Remote Treatment (AMRT) Option 4 SoI Required Static Behaviour – Version 2PrepareEmergencyTreatment<>PlanAllTreatment<><><>
47Iterations of the System Functions Views•We have defined two versions of the System Function Views 1 and 2, which define the SoI Option Structure and Behaviour•The first version was based on the Future Concept candidate elements, as they apply to the selected SoI Option, •e.g. two high level elements for the mobile and hospital based elements•The second version added extra elements, based on initial modelling of the option and the logical architecture for the current Ambulance.•Reflection on Ver 2•This expanded detail makes sense if we use the previous ambulance architecture to help derive it•It will allow use to define more detailed SR•But, is it valid and what assumptions is it making?

SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions ViewpointSF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI Conceptlegacy Views if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function ViewpointSF – View 1 Selected OptionSN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views ,e.g. Data, People, State, Sequence SN-View 2a Static ConceptSN-View 2b Dynamic ConceptSF-View 1a Option n SoI ContextSF-View 3b Option SelectionSN-View 4b StakeholdersSN-View 4a NeedsSF-View 2a Static Option SF-View 2b Dynamic OptionSF-View 4a and 4 b System Function & Mapping to NeedsSN View 5a SoISN View 5b Description
50SoI Solution Option Functions•Purpose, define System Function for each SoI Option:•Input to System Requirements•Provide an input to the Logical Architecture processes•Views•SN-View 4 SoI Concept: Stakeholder Needs (defined in the Stakeholder Needs Viewpoint)•SF-View 2a SoI Solution Option: Required Static and Dynamic Behaviour•SF-View 4a: SoI Solution Option Statement of System Functions (or Activities)•SF-View 4b: SoI Solution Option Function to Stakeholder Need Mapping
Initial SoI Functions1.Assess Mobile patients condition2.Stabilise for any patient movement3.Share mobile assessment4.Provide mobile treatment5.Support remote treatment6.Integrate with vehicle7.Assess patient at hospital8.Plan Treatment9.Prepare Treatment10.Conduct remote treatment11.Conduct full treatment once recovered12.Access patient records13.Release once treatment complete14.Admit to hospital if needed
SF-View 4a: AMRT SoI Solution OptionStatement of System Functions (or Activities)
Incident Report•Incident Ref•Status•Location•Type of incident•Patient Details; •Injuries?•Site Secure? Risks?Patient Details•Name•Gender•UK National?•Medical Issues?Patient Allocation•Incident Ref•Vehicle Assigned•Crew AssignedResponse Report•Incident Ref•Final Mission Status•Issues raised?Patient Status•Location•Current Treatment•Urgent Issues?•PrognosisDetailed Monitoring Data•Monitoring Summary•ECG•Heart Monitor•Live ScansGeneral Monitoring Data•Blood Pressure•Heart Rate•TemperatureTreatment Plan•Patient ID•Test Results•Plan Overview•Current Treatment Tasks•Tasks Assignments•Issues and CommentsPatient Record•Patient ID•Medical History•Special concerns•Ongoing treatmentsMobile Plan•Patient ID•Plan Overview•Mobile Treatment Tasks•Issues and CommentsMinimum Data•Bleeding•Breathing issues•Visible Injuries•Pulse rate•Live PicturesSF-View 2c: AMRT SoI Option 4: Patient Data ontologyPackage: Incident DataReferencesRefPackage: Mobile Treatment PlanusesincludesprovidessummarisesPackage: Response ReportPackage: A&E Treatment Plancreatesusesusesuses
MobileTreatmentMonitoredPotentialPatientPatientA&E Patient[deceased]Issue detectedHealthysuccessDeceasedPatientcheckedRecoveryRemoteTreatmentsuccess[deceased][recovered]recoverRemoteneeded[deceased]involvedclearedIncident overarrive[deceased][released/admitted]SF-View 2d: AMRT SoI Option 4: State – Patient Experience
SF-View 4a: AMRT SoI Solution Option 4Statement of System Functions (or Activities) version 2
SF-View 4a: AMRT SoI Solution Option 4Statement of System Functions (or Activities)
SN-View 4b: Improved Mobile Monitoring & Treatment (IMMT) SoI Concept Stakeholders Detailed Needs and measure of Effectiveness (MoE)
SF-View 4b: AMRT SoI Solution Option 4Statement of System Functions mapping to Needs
59Text based Views in the MBSE Model•In the final part of this example we have created some simple textual statements of Function and Need. In a later unit we will describe a process to turn these into textual Statements of Requirement.•In our expanded view of modelling:•A View is a perspective on the System Context which takes a particular abstraction. Each view is focused an one aspect of the system being modelled. •If we wish to create Orthogonal Views then a views should only consider one abstraction of the system, and an aspect of the system should be introduced in only one view which is reused as needed•A Diagram is a way to represent a view, and so we should chose a diagram that matches the view, e.g. a view showing an aspect of structure or relationships should use a static structural diagram such as a Block Diagram.•For single statements of function or need views, a text sentence is a very good “diagram”. A sentence with a defined format is especially good. If we want to add additional attributes to each statement a tabular diagram works well. By labelling each text item in the view with a unique ID we can also chow traceability as a column in the table.•We have used text based views in other parts of the model, e.g. ontology, but also represented the same view using a BDD diagram. This encapsulates the same text items, but uses blocks, attributes and relationships to add to the view. These diagrams work well if we have an underlying structure between the text elements.
60Explain SySML Requirements Diagram•The SySML Requirements Diagram is a block diagram based view in which •the block represent requirements statements, to which we can add attributes•We can show hierarchical structure between requirements and traceability between sets of requirements•We can also map requirements statements to other model elements, such as Use Cases •If we are using a good SySML tool to support the model we should be able to export Requirements Blocks and relationships to create one or more Textual Requirements documents as an output from the model.•Although the standard stereotype of these blocks is <>, we can generalise this to Needs or Functions and then use these to derive Stakeholder and System Requirements•Hence we can use the SySML Requirements Diagram as one way to represent the single textual statements of Need and Function. These can then be used to create Requirements views.
<< Element>>Mobile Medical Vehicle Functions<>1.1 Deployed to the Patients Location (must fit into ambulance, future platforms?)<>1.2 Locate the patient at the incident (liaise with Incident Control)<>1.3 Stabilize the patient to move to the treatment platform<>1.4 Support the Mobile Medical Element <>1.5 Be Integrated into the Ambulance Staff Training, Sustainment and Maintenance System<< SoI>>Mobile Medical Treatment Functions<< Element>>Mobile Medical Delivery Functions<>2.1 Monitor the patient’s medical condition provide data in accordance with SF-View 2c<>2.2 Share monitoring with A&E<>2.3 Perform identified Mobile Medical tasks as identified in the treatment planAttributesMoP: In time T1 …SHN: SHN1Comment: plan details in ….<>2.4 Provide mobile support for the Remote Medical tasks (desirable)SF-View 4a: AMRT SoI Solution Option 4Statement of System Functions<>1.5.1 Be part of Ambulance Staff Training Parts 1 and 2<>1.5.2 Integrate into the Ambulance Maintenance Plan
SF-View 4b: AMRT SoI Solution Option 4Statement of System Functions mapping to Needs<< Element>>Mobile Medical Delivery Functions<>2.1 Monitor the patient’s medical condition provide data in accordance with SF-View 2c<>2.2 Share monitoring with A&E<>2.3 Perform identified Mobile Medical tasks as identified in the treatment plan<>2.4 Provide mobile support for the Remote Medical tasks (desirable)<< SoI>>Mobile Medical Treatment Functions<< Stakeholder>>Hospital Emergency Medical<>2.1 Needs Patient to be provided with all necessary emergency treatment to maximisesurvival<>2.2 Needs appropriate mobile treatment to enhance effectiveness of emergency treatment<>2.4 Needs Patient to be Stabilisedfor all transport<< SoI>>Mobile Medical Treatment Needs<>2.3 May need additional remote treatment to enhance effectiveness of emergency treatmentTraces toTraces toTraces toTraces to
SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions ViewpointSF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI Conceptlegacy Views if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function ViewpointSF – View 1 Selected OptionSN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views ,e.g. Data, People, State, Sequence SN-View 2a Static ConceptSN-View 2b Dynamic ConceptSF-View 1a Option n SoI ContextSF-View 3b Option SelectionSN-View 4b StakeholdersSN-View 4a NeedsSF-View 2a Static Option SF-View 2b Dynamic OptionSF-View 4a and 4 b System Function & Mapping to NeedsSN View 5a SoISN View 5b Description
64Case Study Discussion•The Views used to support the System Functions all focused on one or more solution options, which provide enough detail to allow proper scoping of the SoI but avoid constraining solution choices.•Selected Architecture views have been used to help scope the SoI. These are either views of an in service or legacy system structure, or describe a potential future concepts which we wish to explore. We will discuss how these views are created in the next unit.•We have used the views to define a set of System Functions, which we will use to support the definition of System Requirements. As part of the process we will need to create some SoI Measures of Performance views.•In the example we have shown two extremes of the requirements process:•A constrained bottom up solution concept, which must fit into and enhance the current solution architecture•An innovative top down solution concept, which will challenge how the related services are currently delivered. This second option works best if it can also propose new ways to do recovery and mobility.•In many real projects we would use a mixture of these two approaches.
65SF Viewpoint Modelling Process Summary1.Define one or more SoI Solution Option: SF-View 3a •A brief text description of each Option, SF View 3a, based on the Future Concept (SN-View 4 and 5) and will include an outline description and ontology for each option. We may use the MA technology survey and existing system architecture views to help shape the options towards future needs.2.Define a SoI context and relationships for each selected or proposed option: SF-View 1•This context is based on the relationships to the SoI defined in SN-View 5, considering only those relationships relevant to the SoI option are included•We can support the context (SF-View 1a) with a detailed option description and option related Ontology (View 1b)3.Model specific behaviour for each selected or proposed Option as needed: SF-View 2•For each SF View 1 we can create Static Behaviour (SF View 2a) and dynamic behaviour (SN View 2a) for the Option•These might be created from the SN View 2 views, or re drawn using solution modelling approaches. Might make use of SF views for previous solution, or be based on generic solution views.4.Expand aspects of SoI structure and behaviour as needed, SF-View 2. •These views use diagrams relevant to aspects of the SoI, e.g. People, Data, States, Timing and Sequence, etc.•These detailed behaviour views are used to review and enhance System Functions and can be re used as part of the solution architecture5.Review or select SoI Solution Options: SF-View 3b •If we have multiple options we can assess them against a set of criteria (based on stakeholder needs defined in SN-View 4) and perform a multi criteria selection. SF-View 3b provides a way to document this. To support this down selection, we can create model views to describe each option, using SF Views 1 and some of the SF View 2, in sufficient detail to support the selection. 6.Define System Functions: SF-View 4 •If an option has been selected for further modelling, we must complete the SF View 2 modelling to allow for System Functions elicitation•Initial functions (View 4a) come directly from the SF-View 2 activities and interfaces, reviewed and completed iteratively with the View 2 modelling•Functions are reviewed and expanded by detailed models, this includes a mapping of functions to Stakeholder Needs (View 4b)
SoI System Function ViewpointSN – Future ConceptSystem Functions ViewpointSystem Option Viewpoint(see also Logical Architecture)Concept – Stakeholder Needs/RequirementsA&E Stakeholder Needs:1.Increased probability of Patient survival in full range of Incidents2.Advanced Information Patient to plan treatment earlier in all incidents3.Better chance of patient surviving recovery in all incidents4.Consider starting treatment in Ambulance?Ambulance Stakeholder Needs:5.Any changes MUST NOT reduce current Vehicle efficiency6.Changes work with and where possible extend current Recovery7.Understand impact of changes on Support and TrainingOther Stakeholder Considerations8.Fit within Hospital rules and budgets9.Understand impact on Patient experience10.Understand Impact on Incident Control MA&T SoI Option – Systems Functions/Requirements1 Mobile Patient Monitoring and Assessment1.1 The AMRT mobile element shall collect monitoring data with A&E for all patients with an overall accuracy of A1 while located in the ambulance vehicle locations1.2 The AMRT mobile element shall share monitoring data with A&E for all patients with a transmission performance of A2 from all ambulance vehicle locations1.3 The AMRT A&E element shall provide patient assessment for all patients to enable correct treatment in Y% of patients during the whole operation (starting when patient is located)1.4 The AMRT A&E element shall provide treatment planning for all patients to enable correct treatment in Y% of patients during the whole operation (starting when patient is located)2 Mobile and Remote Treatment2.1 The AMRT mobile element shall provide mobile treatment for all patients to improve overall patient survivability by X1% within the ambulance vehicle within the ambulance vehicle2.2 The AMRT mobile element shall enable remote treatment controlled from A&E for all patients covering to improve overall patient survivability by X% within the ambulance vehicle2.3 The AMRT A&E element shall provide remote treatment control for all patients to improve overall patient survivability by X2% during the patient recovery3 Infrastructure and Support3.1 The AMRT mobile element shall interface with the ambulance vehicle infrastructure, crew and support in all agreed scenarios3.2 The AMRT A&E element shall interface with the A&E infrastructure, crew and support in all agreed scenarios(traceability)(Model proposed SoI Option))
Model Current Capability as related servicesModel Candidate SoIModel a single ConceptModel SH Needs & Concept SoIModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsCurrent Capability Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•(Future Capability Model, Soft Problem Models, Technology Road Map)•Validated* Models of current Capability•Initial Boundary of Concept, candidate SoI•How Concepts fits into bigger planStage Outputs•Scenario based concept modelling and Needs•Agreed Scenario baseline*•Expanded Concept & Stakeholder RequirementsRequirements Engineering& ManagementCapability AuditStakeholder NeedsArchitecture of in service systems*Note, we need to baseline the agreed scenarios that define the problem scope for the next project stage.We might have more than one new project looking at the conceptScenarios and Needs also used in Validation and Verification.Concept Technical ReviewPreConcept Stage Review
Legacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•(Future Capability Model, Soft Problem Models, Technology Road Map)•Validated* Models of current Capability, Initial Boundary of Concept, candidate SoI, How Concepts fits into bigger planStage Outputs•Scenario based concept modelling and Needs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements•(Integration & Verification Strategy)•(Validation & Support Issues) Initial Exploration, to support Outputs•Early feasible Options & Functions (legacy option Architectures)•Draft SoI System RequirementsModel Current Capability as related servicesConcept Candidate SoI Model a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction Architecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsConcept Stage ReviewRequirements Engineering& ManagementCapability AuditStakeholder NeedsConcept Technical Review
Legacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•Scenario based concept modelling and Needs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements, technology policies and roadmap•Early feasible Options & Functions, (legacy option Architectures) •Draft SoI System Requirements •(Integration & Verification Strategy), (Validation & Support Issues)Stage Outputs•Selected Solution Option and Technology Plan•Option SoI Structure and Behaviour (related SoI Logical Architecture)•SoI Functions and RequirementsModel Current Capability as related servicesModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction Architecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsInitial DevelopmentTech ReviewRequirements Engineering& ManagementCapability AuditStakeholder NeedsConcept Candidate SoI Concept Stage ReviewSoI Logical Element & CriteriaArchitecture of in service systemsSystem Architecture
Propose and select OptionFor the SoI Option Context, define SoI RequirementsDefine ConceptDocument NeedsPropose OptionsModel selected OptionDefine Top Level SoI RequirementsTechnology PlanConsider top level SoI ElementsAgreed Concept Definition(for selected Option)Defines the SoI Option Boundary, Relationships and Functions
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc in Systems EngineeringSpecialising in DefenceProblem Analysis and System Definition
2MSc in Systems Engineering Specialising in DefenceUnit 1: Early Life Cycle Unit 1.3: Concept Definition – MBSE MethodologyAim: Review the Concept Definition processes from the EM module, using the MBSE Methodology ontology•Case Study Part 1 Mission Analysis•Case Study Part 2a Stakeholder Needs (Part 2b will add the Requirements Views)Problem Analysis and System Definition – PASDRick AdcockR.D.Adcock@Cranfield.ac.uk
Operate Successful EnterpriseAnalyse and Manage RequirementsRealise SolutionEnterpriseStrategyBusiness/MissionAnalysisSoIContextStakeholderRequirementsSystemRequirementsRequirementsManagementDefine System SolutionSystemRequirementsLogicalArchitectureSystemArchitectureAnalyseAlternativesDesignIntegration &VerificationDeploy CapabilityValidation &TransitionDeployment, Sustainment. Upgrade, DisposalEnterprise Context•Explores Enterprise Business/Mission Needs related to Capability Context•Propose candidate SoI contexts•Supported by Enterprise Modelling/StrategySystem of Interest Context•Analyse Requirements and Synthesis Solutions for each identified SoI … •… and related levels of System Elements•Used to realise system elements/SoI•Used to Deploy and Use CapabilityApply as needed for levels of System ElementShared** Systems Requirements are both analysed and defined as part of solution synthesis, and managed as part of requirements breakdownE-MBSE MethodologyStakeholder Needs
System EngineerIn-ServiceDefine SoIConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilityProgramme ArchtectMission AnalysisUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerSystems EngineerRequirements ManagementBusinessAnalystCustomerProblemSystem EngineerArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersAnalyseStakeholderRequirementsAnalyseSystemRequirementsAnalyseLogicalArchitectureSynthesisPhysicalArchitectureDefineMission AnalysisConductEnterpriseModellingDefineEnterpriseStrategyDefineSoIContextAnalyseAlternativesManageRequirements<><><><><><><><><><><><><><><><><><>Systems EngineerRequirements EngineerElementDesignIntegrate/VerifyElementsTransition/ValidateSOI<>SustainModifyDispose<><><><><><><><>uc E-MBSE Methodology – Mission Analysis
System EngineerIn-ServiceDefine SoIConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilityProgramme ArchitectMission AnalysisUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerSystems EngineerRequirements ManagementBusinessAnalystCustomerProblemSystem EngineerArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersAnalyseStakeholderRequirementsAnalyseSystemRequirementsAnalyseLogicalArchitectureSynthesisPhysicalArchitectureDefineMission AnalysisConductEnterpriseModellingDefineEnterpriseStrategyDefineSoIContextAnalyseAlternativesManageRequirements<><><><><><><><><><><><><><><><><><>Systems EngineerRequirements EngineerElementDesignIntegrate/VerifyElementsTransition/ValidateSOI<>SustainModifyDispose<><><><><><><><>uc E-MBSE Methodology – Stakeholder Needs
6Case Study Part 0•One of the challenges of describing a recursive process is where to start!•The Mission Analysis and Stakeholder Needs processes consider a new Gap or Opportunity but do so based on analysis of existing solutions.•So, we need some understanding of Requirements and Architecture to do them•We have created a simplified set of view from the PREVIOUS AMBULANCE PROJECT, to illustrate the early life cycle MBSE modelling.•In the taught module we will explore a NEW MOBILE MEDICAL PROJECT to describe the application of MBSE in more detail•To try and make this clear, we will use a grey background for views from the previous project and a white background for the views created in the new project•In this example we do not use the formal MBSE labels, although you can see how some of the views shown could be included in the MBSE ViewpointsCONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAmbulance Update ProjectCONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTMobile Medical Treatment ProjectExample Part 0Starts hereExample Part 1Starts hereExample Part 0Ambulance Upgrade ViewsExample Part 1Mobile Treatment Views
7Case Study Part 1CONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAmbulance Update ProjectCONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAdvanced Mobile Medical Treatment ProjectExample Part 0Starts hereExample Part 1 And 2aStarts hereExample Part 0Ambulance Upgrade ViewsExample Part 1Mobile Treatment Views
ENT-Views 3Enterprise ModelsENT-Views 1Enterprise OrganisationMA-View 1, 2 (for each Capability grouping)Enterprise Capability ContextEnterprise Strategy ViewpointCapability/Service Context ViewpointMBSE Overview 1 – Enterprise ViewpointENT-Views 2Enterprise Vision & Goals
9ENT View 2a Enterprise Vision and Goals•Urban Health Care Enterprise Vision:•Provide world class health care for a major urban population centre, within national health targets and budgets.•Remember, an Enterprise may be Public (e.g. Health or Defence), Voluntary (e.g. Charity or Community Project) or Commercial. While this changes the funding source, business model, stakeholders, etc. they all face similar systems challenges.•Enterprise Goals: top level, time and constraint independent outcomes e.g.1.Delivery all medical outcomes, including urgent treatment, long term care and elective treatments2.Meet all Emergency Needs, both for treatment and recovery, working with other emergency services3.Support urgent public health response, includes vaccination and health passports4.Provide responsive community health and wellbeing support and education5.Maintain all current and develop future facilities, people, information systems and other resources to enable these goals6.Conduct world class medical research and teaching in support of these goalsThese goals will provide the top level motivation to define Enterprise level Capabilities and may also map to the top level organisational structure, with Business Units responsible for key Goals
ENT View 1a Enterprise Organisation – Business Units, Capability & ServiceFacilities & People ManagementBusiness UnitsEmergency Medicine and Recovery – Business UnitMedical Treatment, Research and Community WellbeingBusiness UnitsAccident & Emergency (A&E) Treatment CapabilityMobile Emergency TreatmentServiceA&E Emergency TreatmentServiceEmergency Medical Recovery CapabilityEmergency Medical RecoveryServiceMedical Transport & Recovery Sustainment ServiceUrgent TreatmentLong Term TreatmentPublic Health ResponseMedical ResearchCommunity OutreachCommunity TransportRecruitment & TrainingFacilities MaintenanceResource ManagementTransport Sustainment Note, these other BU will also be expanded to the same detail (not included)
•Emergency Medical Recovery Capability:•Contribute to a Civil Authority goal to ensure all needs to recover and transport people to appropriate emergency medical treatment, are met•by providing an Emergency Medical Recovery Service to meet national and local response targets (measure?)•Within available civic budget, individual/national health coverage and other spending•Closely integrated with the Emergency Treatment and Medical Emergency Recovery & Transport Operation and Sustainment Services; operating with Incident Response, Emergency Medicine, Civil and Private infrastructure, Security Services, etc.•and supporting Community Medical Transport, Staff Training and General Hospital Infrastructure and Sustainment ServicesENT View 1b Emergency Medicine and Recovery Business UnitCapability Goals and Relationships
•Accident & Emergency (A&E) Treatment Capability:•Contribute to a Civil Authority goal to ensure all needs for Emergency Treatment, are met•by providing an Emergency Treatment Service to meet national and local wait times and treatment effectiveness targets•Within available civic budget, individual/national health coverage and other spending•Closely integrated into the Urgent Treatment and Long Term Care Services, and with the Medical Emergency Recovery and Operation and Sustainment Service; •and supporting Staff Training and General Hospital Infrastructure and Sustainment ServicesENT View 1b Emergency Medicine and Recovery Business UnitCapability Goals and Relationships
•Emergency Treatment•Assess injuries, stabilise patients and identify treatment needs •Allowing patients to transferred to Medical Treatment or released•Dealing with the injuries arising from all Urban Incident types; within allocated budget •Such that the best number of patients can get the best possible chance of successful long term treatment if needed, of are safely released•Emergency Medical Recovery:•Locate and recover casualties, providing necessary medical treatment to sustain the patient•Allowing casualties to transferred to Emergency Treatment•Dealing with all Urban Incident types and terrains; working with police and security; within allocated budget •Such that casualties can get the best possible chance of successful emergency treatment•Medical Transport and Recovery Sustainment•Sustain all equipment and support needed for emergency recovery and community medical transport•Allowing those services to be cost effectively and efficiently delivered •Dealing with mechanical, electrical, software and human resources; working with appropriate external services, within allocated budget •Such that the medical transport and recovery services can achieve their purposeENT View 1b Emergency Medicine and Recovery Business UnitService Definitions & Objectives
•Community Medical Transport:•Locate and transport patients, providing necessary medical treatment to support the patient journey•Allowing patients to transported to medical Treatment•Dealing with all patient illness types and urban terrains; working with community services; within allocated budget •Such that patients can get timely transport to support their medical treatment•Urgent and Long Term Treatment:•Immediate treatment such a surgery, intensive care, etc.•And longer term patient care•Etc.•Staff Recruitment and Training•Ensuring the necessary staff are recruited and trained•Both local and collective training …•Etc.•General Hospital Infrastructure and Sustainment Services•Sustaining hospital building, equipment, etc.•Purchasing, storage and distribution of necessary resources,•Etc.ENT View 1b Other services (simplified view)
15Graphical Context and Problem Framing•We can use Graphical, Conceptual or “Rich” Diagrams as part of a model to define a current environment, describe existing relationships or focus in on symptoms, gaps or opportunities.•They all help to identify a real-world context as related systems:•Rich simply means using graphical or free form diagramming to describe elements, relationships and environment.•Conceptual systems boundaries describe a “system to …”, a way to describe current relationships or behaviours. •Not necessarily mapped to designed or managed systems with that role. Can be fully conceptual e.g. “customer systems” or relate to a high-level service e.g. power management.•How do we use these?•A Graphical Context uses these diagrams to describe current environment and behaviours, not necessarily focused on any single conceptual systems or issue (Not a Rich Picture)•A Rich Picture must include stakeholder perspectives or concerns and is created as part of a “Soft Modelling” activity with stakeholders. The terms was originally defined by Checkland, but has been used by others.•A Conceptual Diagram (or Conceptual Model) describes conceptual systems related to a specific area of concern. Idealised view of “what stakeholders need”, comparing this to current reality helps to frame problems or opportunities.
Operate in Urban EnvironmentDeal with Accidents and EmergenciesDeal with Long term Heath IssuesIncludes whole populationMedical Research and TechnologyInterface withEmergencyServicesRecruit and Train StaffMaintain Facilities and EquipmentSecure Public & Private FundsDeal with Public HealthEmergenciesInterface withBusiness & Public SpacesAvailable staffSalarycompetitionResearchfundingResearchpriorityWork hoursHealth risksPopulationtrendsPopulationtrendsShort termVs long termIncident accessIncident controlsafetyTestingpassportsEnvironment challengesfundingPopulationTrendsvaccinationIncident controlsafetyHealthimpactEmergencyresourcesENT View 3b Enterprise ModelsHigh level outcomes and challenges/oppourtunities
Emergency Medical Ambulance RecoveryA System to stabilise and recover patients until safely in A&EMedical Recovery Control & Sustainment SystemA System to ensure medical Recovery assets (Ambulances) are available and control their use(Emergency?) Incident SystemA System to respond to incidents, rescue, secure site and call for recovery (e.g. person calling on a phone, building response staff, police or emergency services)Accident & Emergency (A&E) SystemA System to treat patients involved in emergency and other incidents and transfer to Hospital treatmentHospital SystemA System to provide medical treatment and long term careIncident location SystemsThe public, commercial or private system in which an incident occurs(includes patient)ENT View 3b Emergency Medicine and RecoveryHigh Level (Purposeful Activity) Systems
18Emergency Medical Example Part 1a – Mission Analysis
19Mission/Business Analysis – Process Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288)•Mission/Business Analysis begins an iteration of the life cycle of a potential (Engineered) SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise.•Mission Analysis primary Outcomes1.Takes the (enterprise) capability gap and defines problem/opportunity (future concepts) in a manner that provides a common understanding (between stakeholders, acquirers and potential suppliers)a)define the problem space, b)identify the stakeholders, c)develop preliminary operational concepts, d)distinguish environmental conditions and constraints that bound the solution space. •Mission Analysis may be used to support Enterprise Management, modelling current capability and exploring future concepts.•If this leads to one or more new projects, the outcomes of Mission Analysis directly support the through life outcomes of Stakeholder Needs
20Mission Analysis – Summary •The aim of the Pre Concept Life Cycle stage is to:•Explore potential Gaps and Opportunities, ideally as part of a Capability Management approach within an Enterprise.•Pre Concept is a way to define “the stage before we have a formal life cycle”, it represents the work we do at a Programme level to identify possible projects.•The SE Mission/Business Analysis Process•Has its main focus in these early stages, exploring current and likely future capability to support strategic thinking.•Once a possible future concept has been identified, it can be more fully explored using MA and the related Stakeholder Needs process.•We have considered two related approaches to MA•Focused mainly on incremental improvements to current capability.•Guided by a more strategic Future Concept and related technology research•Who will do this?•Business Analysts/SE Consultant working in or for the Enterprise•Capability owner/customer within the Enterprise•System Engineering working in an Acquisition organisation Systems Engineer working in a Future Concept unit in a supplier organisation
21Mission Analysis Process ActivitiesSEBoKB&MA defines 8 top level Process Activities which form the basis of our Modelling Process. A shortened summary of those activities is given below.1.Review and understand the enterprise mission, vision, and Concept of Operations.2.Identify and define any gaps and opportunities related to future evolution of the strategy:•Examine the current state to identify any problems or opportunities; the political, economic, social, technological, environmental, and legal (PESTAL) factors, plus cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users’ dissatisfaction, etc. •Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, withoutfocusing on a solution.3.Examine and evaluate the solution space:•Identify the main stakeholders, high level operational scenarios.•Identify candidate SoIsolution concepts, that span the potential solution space, consider existing or new product/service/enterprise changes .4.Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. 5.Define basic operational concept or market strategy, and/or business models.•Consider current operations and enrich needs, expectations, scenarios, and constraints.•Validate the mission of any potential SoIin the context of any proposed market strategy or business model.6.Evaluate the set of alternatives and select the best alternative.7.Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.8.Define preliminary deployment, support, preliminary retirement concepts
22MA Viewpoint Modelling Process Summary1.Establish the Enterprise Context: ENT-Views 1 & 2. •This should be based on published enterprise strategy documents.•Or as an output of Enterprise Modelling, e.g. SSM or other business models: ENT-View 3.2.For each Capability, or group of closely related capabilities, define a Capability Context: MA-View 1.•Describes related Service/Product Systems and Operational Ontology•Can be updated at the end of each project to show evolving Capability3.Model Capability Behaviour: MA-View 2•Static (2a) and Dynamic behaviour (2b)•Can also be updated to include top level behaviour provided by new systems4.Define detailed Enterprise Objectives: MA-View 4•Can be used to define Capability Requirements?5.Identify potential Capability Gaps or Opportunities (including technology forecast): MA-View 3•May make use of Enterprise Modelling (ENT-View 3) if available6.Establish proposed SoI related Problem Contexts: MA-View 5•May be done in response to an identified operational problem•Or as part of a regular Capability Audit process
23Mission Analysis Views•Purpose define the system and logical system elements used (or needed) to provide the capability•Capture structure of the service that deliver current Capability•Identify detailed solution views of current solutions that relate to this•Views•MA-View 1a: Current/Future Capability Services•MA-View 1b: Capability Ontology•Other aspects of high level logical structure can be added if needed, e.g.•MA-View 1c: Capability Logical Data (not shown in example)•MA-View 1d: Capability Logical People•Related solution Logical Architecture Views: solution overview, logical structure and behaviours•Purpose explore Gaps and Opportunities in that Capability•Define related static and dynamic behaviour of the service that deliver current Capability•Define high level Business Objectives/Needs•Explore Enterprise issues or opportunities and identify one or more future concepts•Views•MA-View 2a: Capability Conceptual Static Behaviour •MA-View 2b: Capability Conceptual Dynamic Behaviour•MA-View 2c: Capability Scenarios•MA-View 3a: possible areas of conflict or issue•MA-View 3c: Future Technology Planning•MA-View 3c: Future Operational Concepts•MA-View 3d: Gaps and Opportunities•MA-View 4: Capability level Objectives (Business Requirements)•MA-View 5a: Candidate Future Concept(s)•MA-View 5b: Candidate Future Concept Description
MA-Views 2Capability Conceptual BehaviourMA-View 1 (for each Capability grouping)Capability Conceptual SolutionsMA-Views 3Enterprise Capability Gaps and OpportunitiesCapability/Service Context ViewpointCandidate SoI Concept ViewpointMBSE Overview 2 – Mission Analysis ViewpointMA View 7d Gaps and Opportunities•Service 1 out of data•New operational environment for Service 2 (Objective 1.1)•Need to improve performance of Service 3 (Objective 1.2)•New technology could be used to explore Service 4? (Objective 2)MA View 1b Ontology•Stakeholder 1 …•Stakeholder 2•Service 1 …•Service 2 …•Service 3 …•Etc.MA View 1c Additional Structure, e.g. People, Environment, DataEnterprise Strategy ViewpointENT-Views 3Enterprise ModelsMA View 8b SoI A Operation Concept•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on supportMA-View 5 (for each Capability grouping)Capability Focused Candidate SoI ConceptsMA-Views 4Capability ObjectivesMA 4 Goals & Objectives1.Best at …1.By sustaining S1 …2.By Replacing S22.Great at …1.By Improving S3 …..3.Good at …1.By Integrating with …4.Supported by ..1.Researching X …ETC.
Service 3SH1MA View 1 – Current Capability ContextSH2Capability 1Service 1Service 2MA View 2b Current Capability Dynamic BehaviourService 1SH 2Service 2SH 1•Strategy•World Class Enterprise to …•In Environment …•Competing with …•Goals1.Best at …2.Great at …3.Good at …4.Supported by …ENT View 2 Enterprise StrategyENT View 3 Enterprise Models (Business Unit 1) Goals & Objectives1.Best at …1.By sustaining S1 …2.By Replacing S22.Great at …1.By Improving S3 …..3.Good at …1.By Integrating with …4.Supported by ..1.Researching X …ETC.MA View 4 Goals and ObjectivesSH 1SH2Sys 1Capability 1Use Case 1Use Case 2Use Case 3MA View 2a Current Capability Static BehaviourThese Views support the current Capability Concept of Operations (ConOps)Business Unit 2Business Unit 3Business Unit 4Business Unit 1Capability 1Capability 2Capability 3ENT View 1 Current Organisation
MA View 3a/b Enterprise Needs Need?MA View 3c Technology RoadmapsMA View 3d Gaps and Opportunities•Service 1 out of dat3•New operational environment for Service 2 (Objective 1.1)•Need to improve performance of Service 3 (Objective 1.2)•New technology could be used to explore Service 4? (Objective 2)•ETC.SH1MA View 5a – Candidate Future Concept(s) SH2Cap 1Service 1Service 2SoI AService 3SoI BSoI BSoI CMA View 5b Future Concept Description (for each)•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on support•ETC.These Views support proposed Future Capability Concept of Operations (Future ConOps)
27Simple Block Definition Diagram•A Block Diagram is used to model system Structure•A Block is any system entity, at any level of detail or abstraction. •E.g. A person, technology, product, service, capability, organisation, etc.•Blocks can be labelled with a type to clarify to level of detail, e.g. Capability, Service, Service Element, Interface (stub to show interface to larger service), Actor•Two structural relationships:•Aggregation: One Block contains or is made up of other Blocks•Composition: a Block can contain another Block at some times•Shading or colours can be used to show hierarchy here.•Other Relationships: all other relationships are labelled•Can show shared goals, influence, constraints, control, information sharing, physical interfaces, etc.•Have direction and label, mostly high level and 2 way for this high level examples•Get more specific and detailed later•What we have shown here is a simplified version of the Block Diagram, we will introduce more detailed SySML BD notations and uses later.
(SoI Element)ManageSnack Info(SoI Elements)Customer Interface(Resource Element)Snacks(SoI Elements)SupplierInterface(Service Element)Maintenance(Related Service)Banking(Human Actor)Customer(Related Service) VenueResources(Environment)Venue Type, e.g.School, Shop, cinema(Service Element)SnackSupplierSimple Block Diagram(System of Interest Context View)Display & SelectSuppliesPayProcessSupplySupportInfoHousesVending System of InterestVending Support Service(Related Service)Supply ChainPayment Support Service(Service Element)Security InterfacesOperating Environment(Service Element)Payment Interfaces(SoI Element)PaymentUses & updatesdefinesUsesmanages(Resource Element)Snacks(SoI Element)Snack Selection(SoI Element)Snack DispensingPart ofAggregationOne Block contains or is made up of other BlocksCompositionOne Block may include, or sometimes contains, other BlocksRelationshipAny link, interaction of influence between BlocksThis relationship may apply to ALL Blocks inside the BlockBlock TypeBlockCompositionOne Block may include, or sometimes contains, other BlocksAggregationOne Block contains or is made up of other Blocks(multi-level breakdown)CompositionOne Block may include, or sometimes contains, other Blocks
29System Behaviour Diagrams•A Use Case (UC) Diagram is a SySML Diagram type used to model Static Behaviour•Context shows what the UC relates to•A Use Case is a high-level Behaviour of the context, e.g. what it can do or how it is used by others•External Actor or Related Systems are linked to each UC, very simple “Uses or is involved in” relationship. •Use Cases are not directly linked, but can be expanded or related:•Uses: One UC makes use of another•Includes: One UC contains or controls another•Extends: One UC is a special case or extension of another•Note, external relationship inherited, e.g. no need to link Patient to Admit Patient, this is inherited from link to Recover Patient•An Activity Diagram (AD) is a SySML Diagram used to model Dynamic Behaviour•Used to model one or more specific Use Cases (all UC in our first example)•Activity is a thing the context does to enable a UC, can be high level behaviour or detailed function depending on Context•Has a single start, and one or more ends, Activates link to or initiate other Activities. Flow can be sequential or parallel, can include loops and decision points.•“Swim Lanes” show Blocks allocated to Activities•Requirements Diagram allows single statements of Requirement, linked to behaviour and structure views at each level of detail•All Blocks on these diagrams should be defined on a Block Diagram
DisplaySnackCustomerSelectSnackPay forSnackHealthy Snack Vending (HSV)uc Vending Context: SoI Behaviour ViewBankProvideSnackProvideLocationSnackSuppliersSupply SnacksVenueVending MachineUsesAn enabling or supporting shared caseExtendsAdditional part of the main case<>DeclinePayment<>Credit CheckProvide SnackInfo<>IncludesA sub case, to clarify relationshipsSnackProducer<>Actor or StakeholderRelated SystemBlockUse CaseContextShared Behaviour (Uses) RelationshipPurchaser
ad HSV Context Dynamic Behaviour View – Display, Select and Dispense Use CasesVenueCustomerDisplay Available SnacksDisplayPriceSelect SnacksDispenseSnacksTakeSnacksHSVSupplierBankTakePaymentNo PurchasepurchaseHouseHSVMMake PaymentProcessPaymentProvide Snacks InfoAssess SnackAvailabilityEnd hereActivityStart hereEnd hereOr hereActivity SequenceParallel ActivesActivity LoopDispose ofWasteAllocation of Activity to Block“Swim Lanes”
<>Display Snacks<>Purchase Snack<>Provide Snack<>Offer Healthy Snacks for Vending<>Display Snacks InfoThe System Shall display snack information including price and ingredients…<>Display Snacks VisualThe System shall display an image of each snack, real or virtual<>Display Snacks AvailabilityThe System shall indicate if each snack is currently available<>Confirm choiceThe System Shall be given an order summary and confirm<>Choose SnackThe System allow customers to choose up to n snacks<>PaymentThe System shall ensure payment is complete before vend<>Report FaultThe System Shall allow customer to report fault if no vend<>Dispense SnackThe System dispense a snack once purchase complete<>Re supplyThe System shall assess snack level and request re-supply

AmbulanceVehicleAmbulanceSupportRecoveryControl RoomA&ETreatmentIncidentLocationHospitalTreatmentStores & MaintainsPrepares for useShare status & plansIncidentPatientRecoverGain AccessControlIncidentEmergency treatmentProvide StatusAmbulanceControlMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.Ambulance DepotIncidentHospitalAmbulancePatient InfoEmergencyServicescoordinatestransportGeneralPublicReport incidentAmbulanceRecoveryCrewHospitalAdminTreatmentPatient DetailsEmergency MedicalRecoveryControlRecoveryInvolved in IncidentInvolved in IncidentIncidentControlAmbulanceMedicalCrewMobileStabilisePatient ReportMA-View 1a: Emergency Medicine and Recovery CapabilityConceptual Solutions (based on currently deploy solution views)
•Routine Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling (e.g. transport of old or ill people to therapy or treatment, pregnancy check-up, etc.)•Emergency Treatment: All patient treatment conducted by A&E staff•Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Emergency Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling in response Medical Incident•Stabilisation: medical aid conducted by Ambulance staff, sufficient to allow safe transport (assessed against patient risk if not moved), for both routine and emergency recovery•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents•Other terms, e.g. Incident Control, Ambulance Control and Support would also be defined MA-View 1b: Emergency Medical RecoveryCapability Ontology
Inside VehicleModular InterfaceInside A&EMonitor & AssessAll PatientsTreat RecoveredPatientsMonitorStabiliseAssess/ReportAdminRecordsRecoveryRecoveryHandoverAssessmentMA-View 1b: Emergency Medicine and Recovery CapabilityConceptual Solutions (Graphical Overview)

ControlRecoverySupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentAmbulanceSupportRecoveryControl<>Emergency TreatmentAmbulancevehicleControlIncident<>PublicReportuc Emergency Medical Recovery CapabilityAmb. RecoveryCrewAdmitPatientHospitalAdminTransportPatient<><>A&EMobile StabiliseAmbulanceMedical<>HandoverPatient<><>MA-View 2a: Emergency Medical Recovery & TreatmentConceptual Solution Behaviour (based on currently deploy solution views)
IncidentControlPublic/EmergencyServicesReport IncidentIncident Planning DeployResponseResponseReportSecure PatientTransport PatientUnload PatientMove PatientLocate PatientMonitorMobile PatientAssess PatientStabilise PatientEmergency TreatmentHospitalReleasePatientAssessResourcesAdmitPatientIncidentReportProvide StatusPrepareVehiclesNavigate toIncidentad: Emergency Recovery and TreatmentProvideAccessRe SupplyVehiclesAmbulanceVehicleAmbulanceControlAmbulanceSupportAmbulanceRecovery CrewEnsureSafeAccessHand OverPatientA&E TreatmentAmbulance MedicalCrewMA-View 2b: Emergency Medical Recovery & TreatmentConceptual Solution behaviour (based on currently deploy solution views)MonitorMobile Patient
DepartmentAmbulanceHospitalA&EPeopleCharacteristicsSocial GroupOther NeedsMedical CrewStabilisation TrainingOther medical skills?Recovery CrewVehicle Operations& Recovery Training.A&E MedicalStaffA&E Team RoleEmergency Medicine TrainingAdmin StaffEmployeesRoleQualificationsExperiencePatientPersonal detailsInjury detailsBDD [Package] Current PeopleAmbulanceDepotSupport StaffEng. QualificationVehicle ExperienceControllersTeam RoleControl TrainingAmbulance or emergency experiencePublicPersonal DetailsMedical StaffCurrent RoleMedical SpecialismMedical ExperienceMA-View 1c: Emergency Medicine and RecoveryConceptual Solutions People and Roles (based on currently deploy solution views)
MA-View 2c: Emergency Medical Recovery & TreatmentCapability Operational ScenariosThese scenarios can be applied to the exploration of new behaviour in any part of the capabilityWe will use them in more detailed modelling to explore candidate future concepts
42Exploring Gaps and Opportunities•The Mission Analysis Views created so far can be either:•A baseline view of the current Enterprise, linking Strategy an Goals to current Capability delivery.•Or a more top down model of what we wish to Enterprise be able to do in the future•The second could be the starting point for a top down Enterprise design or redesign (more later) •The first allows us to either respond to issues raised operations (why do Ambulances fail to meet response time?) or to periodically review/audit current areas of the business (how well is Medical Recovery meeting its Objectives and Goals?) •This exploration of the current and future delivery of capability, and the formulation of plans to respond to it, is a Enterprise wider activity is which SE has a role. The MA Views we have created can be used to support this (and are in some industries).•We will show some simple views to help capture Gaps and Opportunities and relate them to the MA for our case study to complete the first part of our MBSE method.
CompareFair TradeEthical LabourMin PackagingRe cycle wasteCarbon NeutralGreen EnergyEthical LabourMinority FriendlyAbility FriendlyMin Env. ImpactEthical PartnersNutritionCalories/SugarVegan/Gluten Free Easy to use

AirportHospitalMallFireSchoolMallOfficeBlockAmbulanceStationOfficeBlockRiverVenueUrban LocationOutside Urban LocationParkIncident Response HQPoliceA&EMotorwayRescueVehiclesRiver walkCommercial airspaceCarparkResidentialMA-View 3a: Emergency Medicine and Recovery Stakeholders, conflict, issue or opportunities(Based on ENT View 3d if it exists)Public Building (PB):•Building Owners•Workers•Maint, Cleaning•Public•Unions•InspectorsPB +ParentsTeachersChildrenHome OwnersBanksResidentsVisitorsTrafficTraffic:•Driver•Passenger•Pedestrian•Police•Local Auth.PB +SecurityCommercialPB +PerformersVendorsPB +DoctorsPatientsAdminPoliceFireLegislationStakeholdersVehicle AccessOlder residentsNon English speakersVehicle AccessUn accompaniedChildrenVehicle AccessCrowdsSecurityAccessTrafficRush hourCrowdsAlcohol/drugsStaff/ResourcesSecurityCommunicationOld & New technologyOld & New technologySecurityThreatsIssues
AmbulanceVehicleAmbulanceSupportRecoveryControl RoomA&ETreatmentIncidentLocationHospitalTreatmentStores & MaintainsPrepares for useShare status & plansIncidentPatientRecoverGain AccessControlIncidentEmergency treatmentProvide StatusAmbulanceControlMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.Ambulance DepotIncidentHospitalAmbulancePatient InfoEmergencyServicescoordinatestransportGeneralPublicReport incidentAmbulanceRecoveryCrewHospitalAdminTreatmentPatient DetailsEmergency MedicalRecoveryControlRecoveryInvolved in IncidentInvolved in IncidentIncidentControlAmbulanceMedicalCrewMobileStabilisePatient ReportVehicle AccessOlder residentsNon English speakersChildrenVehicle AccessSecurityAccessTrafficRush hourCrowdsAlcohol/drugsStaff/ResourcesSecurityCommunicationOld & New technologyOld & New technologySecurityThreatsStaff/ResourcesOld & New technologyTrafficRush hourMA-View 3a: Emergency Medicine and Recovery Stakeholders, conflict, issue or opportunities(mapped to on MA-View 1a)
Recovery TechnologiesMedical TechnologiesMedical PlatformsNetwork CommunicationsTechnologiesMA-View 3b: Emergency Medicine and RecoveryFuture Technology Planning•An Enterprise might have its own technology expertise, or it might employ consultants, academics, etc. to do technology scanning for it•At this stage we are interested in likely areas of advancement and how mature they are.•From this the organisations can plan how and when to investigate the use of such technologies and feed that into its capability assessments•The Enterprise may actively be involved in its own Research and Development, or funding research in academia or elsewhere.•In that case this technology planning will also feed into an R&D planning and investment process•For our example we have simply identified some likely areas of innovation (very simple Google search!)
Hospital NetworkA&ERecoveryRemoteTreatment& AdviceRecoveryFullRemoteTreatRecoveryRecoveryTreatTreatRecoveryRecoveryRecoveryRecoveryRapid MedicalResponseRapid MedicalResponse & RecoveryRapid MedicalRecoveryRobot RecoveryAmbulanceMobileA&ERecovery ControlSystem•Assess Incident Need & Asset Status•Plan each response•Deploy and coordinate response•Synchronise across incidents•Record and summaries all responseAdhoc Mission Critical Communications NetworkRecoveryTreatRobot RecoveryRapid MedicalResponseRemote TreatmentMA-View 3c: Emergency Medicine and RecoveryFuture Operational Concept
StaticHousing, power, interfaces for equipment, on building, public spaces, people, etc..Assisted MobilityShort range high access, assists in moving people or things, e.g. powered sled or robotRapid Human MobilityMedium range, moves people rapidly and safely, e.g. helicopter or droneRapid Light MobilityLong range medium access, moves things rapidly and safely, e.g. bike, drone, small vehicleHeavy MobilityLong range, low access. moves people and things more slowly e.g. large vehicle, container.MonitorGather patient data and transmit. Portable, Wearable“Normal” TreatmentMedical equipment to stabilise, keep alive manage pain, etc.Remote TreatmentMedical equipment to provide treatment normally done in A&E“Normal” RecoverSystems to secure, move and recover patient once stabilised.“Direct” RecoverSystems to secure & move patient without any treatmentIncidentControlResponsePlanningAssetControlResponseControlOperated by: Patient, Crew, PublicUsing: Human operators, , Autonomous agents, Remote controlOperated by: A&E, Para Medic, PublicUsing Human operators, Autonomous agents, Remote controlResponse ControlGeneral MobilityDeployed RecoveryDeployed TreatmentBespoke4G Comms5GCommsAd-HocMobileCommsEmergencyTreatmentEmergencyAssessment &PlanningHospital Admin and InfrastructureFixed TreatmentSharedAssessmentDeployed MonitoringHospitalFacilitiesMA View 3b Future Emergency Recovery and Treatment Technology Roadmap
•Deployed Recovery•A suit of assets to support patient rescue, immobilisation, lift, move etc.•Direct Recover: Systems to secure & move patient without any treatment•Normal Recover: Systems to secure, move and recover patient once stabilised.•Shared Assessment•An integrated service to provide assessment and planning for ALL treatment•Embedded assessment provided at the point of treatment and limited by mobility solution•Centralised Assessment, based in a fixed location sharing data and plans over integrated comms.•Emergency Treatment•Manage and deliver all aspects of treatment, including deployed, remote and A&E based•Emergency Treatment, perform necessary treatments from a fix of heavy mobility deployed medical facility to fully treat or prepare from hospital treatment•Remote Treatment: Medical equipment to provide treatment normally done in A&E•Deployed Treatment•A suit of assets to support patient first aid, life support, emergency treatment, etc.•“Normal” Treatment: Medical equipment to stabilise, keep alive manage pain, etc.•Expanded Treatment: use additional medical equipment to provide emergency treatment from the mobile platform •Enable Remote Treatment: provide the mobile assets needed to enable remote treatmentMA View 3b Future Emergency Recovery and Treatment CapabilityTechnology Roadmap Description•Integrated Communication•Provide a secure and integrated communications service which will enable Control, Shared Assessment and Remote Treatment•Consider available mobile comms, fixed networks, adhoc networks, bespoke solutions, etc.•Provide General Mobility•A suit of platforms to provide mobility for recovery and treatment•Rapid Human Mobility: Medium range, moves people rapidly and safely, e.g. helicopter or drone•Assisted Mobility: Short range high access, assists in moving people or things, e.g. powered sled or robot•Static: Housing, power, interfaces for equipment, on building, public spaces, people•Rapid Light Mobility: Long range medium access, moves things rapidly and safely, e.g. bike, drone, small vehicle•Heavy Mobility: Long range, low access. moves people and things more slowly e.g. large vehicle, container.•Response Control & Support•An integrated service to coordinate all emergency treatment or recovery elements •Embedded control provided at the point of response and limited by mobility solution•Centralised control, based in a fixed location sharing data and plans over integrated comms.
•Vehicle mobility and access: vehicles are relatively modern but cannot access some spaces (e.g. Mall, Park, Venue). Other modes of transport exist which could expand the range and coverage, but issues of interoperability need to be considered•People and Culture:a much more diverse population, with many more non English speakers, a high proportion of older people, street crime in some residential areas. Particular issues of dealing with children around the school or of alcohol or drugs at the venue.•Command and Control:Many more incidents arising from a wide range of users, more public health and community uses to be balanced with urgent operations. Growing need to coordinate with security and emergency service to deal with bio hazards, bomb treats,•Treatment:when this current solution was developed medical equipment was limited in size and skill needed, hence mostly simple equipment in vehicle and more complex in A&E; this may no longer be true. Modern communications and display equipment also allows for on board monitoring to be linked back to A&E; and for live video link to medical staffMA-View 3d: Emergency Medicine and RecoveryGaps and Opportunities
•Goal 1: Meet all Emergency Needs, both for treatment and recovery, working with other emergency services•Objective 1: Recover patients, in all situations within national target time•Obj 1.1: Stabilise patients for transport…•Obj 1.2: Monitor patients while mobile ….•Obj 1.3: Transport patients to A&E ….•Obj 1.4: Control recovery and liaise with incident …•Objective 2: Treat patients, with all emergency conditions to achieve national survival probability•Obj 2.1: Admit to patient to A&E•Obj 2.2: Monitor patient (includes mobile data if available)•Obj 2.3: Assess patient and plan treatment (as soon as data available)•Obj 2.4: Provide emergency treatment once recovered•Obj 2.5: Admit to Hospital•Obj 2.6: Provide Update to patients or others …•Goal 4: Maintain and Protect all current and develop future facilities, people, information systems and other resources to enable these goals•Objective 3: Maintain Recovery Assets and People ….•Objective 4: Maintain A&E Assets and People ….MA View 4 Emergency Medicine and Business/Capability Objectives & Requirements
Model Views of Current CapabilityBased on existing service solutionsModel Views of Current CapabilityBased on abstract service solutions(aligned with future technology strategy)
AmbulanceVehicleAmbulanceSupportRecoveryControl RoomA&ETreatmentIncidentLocationHospitalTreatmentStores & MaintainsPrepares for useShare status & plansIncidentPatientRecoverGain AccessControlIncidentEmergency treatmentProvide StatusAmbulanceControlMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.Ambulance DepotIncidentHospitalAmbulancePatient InfoEmergencyServicescoordinatestransportGeneralPublicAmbulanceRecoveryCrewHospitalAdminTreatmentPatient DetailsEmergency MedicalRecoveryControlRecoveryInvolved in IncidentInvolved in IncidentAmbulanceMedicalCrewMobileStabilisePatient ReportAgile Responseand RecoverImprove IncidentInformation and ControlImprove VehicleSupportImprove MobileTreatmentIncidentControlMA-View 5a: Emergency Medicine and RecoveryCandidate Future ConceptsReport incident
MedicalResponseSupportResponseControl RoomShare status & plansIncidentPatientRecoverEmergency treatmentMobileTreatmentMedical Response CentrePatient InfotransportProvideIncident InfoRecoveryCrewPatient DetailsEmergency MedicalResponseA&ETreatmentHospitalTreatmentProvide StatusHospitalHospitalAdminMobileMedical CrewReportIncidentControlStores & Maintain.Mobility Service MedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.TreatmentControlIncidentLocationControlIncidentIncidentEmergencyServicescoordinatesGeneralPublicReport incidentInvolved in IncidentInvolved in IncidentPatientAssessmentAssessmentGain AccessMobilityPlatformsIncidentControlRecoveryControlAgile Responseand RecoverImprove IncidentInformation and ControlImprove VehicleSupportImprove MobileTreatmentMobilityControlMedical Recovery ServiceMobile Treatment ServiceMA-View 5a: Emergency Medicine and RecoveryCandidate Future Concepts (Based on MA View 3c Future Operational Concept)
•For this exercise we will look at a SoI related to proposed improvements in the A&E Emergency Treatment and Mobile Treatments. The other gaps could be described in a similar way.•Current Ambulance vehicles and on board medical systems, working with A&E cannot achieve the required patient survival rate across the full set of required missions.•The has been identified as a mixture of:•The treatments available inside the ambulance is limited, early treatment can have a significant effect on overall survival. The concept will consider additional on board treatment, supported by new equipment if needed•The flow of information from Ambulance to A&E is very limited, this delays the ability of A&E emergence treatment to begin planning and delivering treatment. The concept will consider better sharing on information with A&E•A number of opportunities are offered by new communications, monitoring and treatment technologies support this.•With modern technology high speed and secure data links are feasible, although they may have limitations in built up urban areas.•A number of small items of medical monitoring equipment are available and may be able to be used within a mobile vehicle•There are potential technologies to allow treatment to be overseen or directly provided at a distance. This is less mature and should be considered as an option at this stage.•Solutions are not limited to existing Ambulance or A&E systems, but these systems will remain in use and could be modified if needed. A high level Logical Architecture view of the current treatment solutions is provided.•Note, we would create a MA-View 5b for each SoI Concept identified at this stage and use each to initiate a formal Project life cycle and associated Stakeholder Needs and Requirements process.MA-View 5b: Improve Mobile Monitoring & Treatment Service SoICandidate Future Concept Description
•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents •Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Treatment: All patient treatment conducted within or by A&E staff•Mobile Treatment: an extension of Emergency Treatment conducted in the Ambulance by Ambulance medical staff; includes stabilising the patient to enable treatment•Stabilisation: an extension of Mobile Treatment to provide sufficient medical aid to allow safe transport (assessed against patient risk if not moved)•Emergency Medical Recovery: transport, stabilisation or special patient handling in response Medical Incident•Emergency Medical Mobility: platform able to carry mobile treatment and/or recovery to the incident location and support both as neededMA-View 5c: Future Emergency Medicine and Recovery – Improve Mobile Treatment ConceptCapability level Candidate SoI Ontology
58Case Study Discussion•In our Case Study we have started with an existing organisation, providing services to support a publicly funded health care enterprise.•How extensive the Problem Exploration part of this activity is one of the challenges of Mission Analysis. •Do we look at the current organisation and at our experience of how it works to identify Gaps?•Should we use a more formal Soft Systems Approach, bringing in real Stakeholders and exploring underlying issues or hidden concerns?•How wider should we look at possible future technologies, inside our own organisation, across the industry, into other domains, or should we be developing our own innovative technologies?•This might be done in response to problems emerging in the enterprise (we are not meeting our recovery time targets) or it might be used to support periodic capability audits.•Note, to illustrate the views we have done one pass of MA and identified candidate concepts to use in Stakeholder Needs. In reality these two processes are done iteratively, and we might need at least one iteration of the SN process to get to a detailed set of concepts.
MA-Views 2Capability Conceptual BehaviourMA-View 1 (for each Capability grouping)Capability Conceptual SolutionsMA-Views 3Enterprise Capability Gaps and OpportunitiesCapability/Service Context ViewpointCandidate SoI Concept ViewpointMBSE Overview 2 – Mission Analysis ViewpointEnterprise Strategy ViewpointENT-Views 3Enterprise ModelsMA-View 5 (for each Capability grouping)Capability Focused Candidate SoI ConceptsMA-Views 4Capability Objectives
60Stakeholder Requirements – Outcomes(SEBoK Part 3)•Stakeholder needs and requirementsuse enterprise-level life cycle concepts (see Business or Mission Analysisfor details) as guidance, stakeholders are led through a structured process to elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts). •Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.•Stakeholder requirements (and associated Mission Analysis):•Form the basis ofsystem requirementsactivities.•Form the basis of systemvalidationand stakeholder acceptance .•Act as a reference forintegrationandverificationactivities.•Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.
61Needs and RequirementsSEBoK: Cycle of Needs (Faisandier 2012).Permission granted by Sinergy’Com. All other rights are reserved by the copyright owner.
62Stakeholder Needs – Summary •The aim of the Concept Life Cycle stage is to:•Focus on and expand an identified Gaps or Opportunities, identified by the Enterprise.•Concept is the first formal SE life cycle stage – “should the organisation invest in new solution options to deliver this concept”•The SE Stakeholder Needs and Requirements (SNR) Process•Has its focus in these early stages, related to MA.•SNR can be conducted to feedback to the MA and strategy; or it can define the requirements the feed into System Definition.•The SNR Process•Combines Soft and Hard views to explore a Gap in context and begin to identify where any solution will fit•May be focused on a specific evolution of existing services•Or may consider the potential needs for a target future concept•Who will do this?•Stakeholder representative working in or for the Enterprise, who have some SE training; or supported by external consultants•System Engineering working in an Acquisition organisation Systems Engineer working in a Future Concept unit in a supplier organisation
63Stakeholder Needs and Requirements – Activities•The SEBoKdefines 9 level SNR Process Activities Links based directly on ISO/IEC/EII 15288. A shortened summary of those activities is given below.1.Identify the stakeholders or classes of stakeholders across the life cycle.2.Elicit, capture, or consolidate the stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.3.Refine the Operational Concept (OpsCon) and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).4.Prioritize the stakeholder needs.5.Transform the prioritized and retained stakeholder needs into stakeholder requirements.6.Verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in the System Requirements article.7.Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing rationale (glossary) for the existence of the requirement.8.Identify potential risks (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see Risk Management).9.Synthesize, record, and manage the stakeholder requirements and potential associated risks.”
64SN Viewpoint Modelling Process Summary1.Establish the Future Concept Structure: SN-View 1 •This is based on the MA-View 5, and will include an outline Operational Concept (Op Con) and ontology.•At this stage we can re consider the Op Con this context is based on, and propose one or more abstractions of this if appropriate. We may use the MA technology survey and existing system architecture views to help shape this expanded concept towards future needs.2.Define a number of Operational Scenarios, relevant to the selected concept: SN-View 3e.•We have defined general scenarios based on combinations of environment and mission, and then more detailed vignettes or user stories. •Select a sub set of these scenarios to explore the stakeholder needs and wider behaviour, based on project scope and risk.3.Model scenario specific behaviour, expanding the equivalent MA Views: SN-View 3•L1 and L2 Static behaviour (3a); Dynamic behaviour (3b); Stakeholder operational concept and issues OpCon (3c, 3d); 4.Review and combine these views for each set of allocated scenarios to create multi scenario views, SN-View 2. •Define a set of allocated Operational Scenarios, relevant to the selected concept: SN-View 2e •For the allocated scenarios, created combined scenario views based on the associated View 3 views of each scenario, L1 and L2 Static behaviour (2a); Dynamic behaviour (2b); Stakeholder operational concept and issues OpCon (2c, 2d); 5.Define Stakeholder needs for each set of allocated scenarios: SN-View 4. •These define needs from stakeholders who use or place constraints on the future concepts, to support service level outcomes6.Define an expanded SoI OP Con and ontology for each set of allocated scenarios : SN-View 5•These are used, along with the detailed views and related needs, to directly to initiate a SoI Project
65Stakeholder Needs Viewpoint•Purpose•Define the context of a proposed Service SoI Future Concept:•Feedback on the Mission Analysis•Define the SoI and Con Op baseline for the Stakeholder Needs analysis•Views•SN-View 1a: Future Capability Concept & Candidate SoI•SN-View 1b: Future Concept Definition/Ontology•SN-View 2 Concept: Selected Scenario Behaviour•SN-View 3 Concept: Specific Scenario Behaviour•SN-View 4a Concept: Stakeholder and Key Needs•SN-View 4b Concept: Stakeholder Detailed Needs and Measures of Effectiveness (MoE)•SN-View 4b Concept: Stakeholder Requirements•SN-View 5a Concept Extended Context•SN-View 5b Concept Extended Definition/Ontology•SN-View 2 SoI Concept: Scenario Behaviour (for each scenario)•SN-View 2a Concept Scenario Static Behaviour (modified from MA-View 5a)•SN-View 2b Concept Scenario Dynamic Behaviour (modified from MA-View 5b)•SN-View 2c Concept Operational Activities Behaviour•SN-View 2d Concept Stakeholder Stories/issue•SN-View 2e Concept Operational Scenario Allocation•SN-View 3 Concept Scenario Behaviour (for each scenario)•SN-View 3a Concept Static Behaviour Scenario n (modified from MA-View 5a)•SN-View 3b Concept Dynamic Behaviour Scenario n (modified from MA-View 5b)•SN-View 3c Concept Operational Activities Scenario n•SN-View 3d Concept Stakeholder Stories/issue Scenario n•SN-View 3e Concept Operational Scenario n Description
SN-Views 5: Extended SoI Context, Concept Description, OntologySN-Views 1: SoI Context, Concept Description, OntologyFuture Concept ViewpointSN-Views 4 Stakeholder Needs & RequirementsConcept Stakeholder Needs ViewpointMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourConcept Scenario & Behaviour ViewpointMA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 3 Scenario Specific Static & Dynamic Behaviour (Stakeholder Needs Elicitation)MA View 8b SoI A Operation Concept•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on supportMA View 5b SoI A Operation ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SN View 5c Ontology•Term X means ….•Term Y means …MA View 1b SoI A Operation ConceptRequired•Replace S1Optional•Consider S2?Concerns•Consider impact on support
SN View 3 – Scenario Modelling (These views are created for each identified scenario)SN View 3e Scenario DescriptionsSH 1Ser 2SH 2Ser1:SoISN View 3b Scenario A Dynamic BehaviourSN View 3c Scenario A Operational ConceptNeed?SH 1ActionsQuestions?SH 2ActionsQuestions?SN View 3d Scenario A Stakeholder IssuesNeed?SH 1 IssuesLegalIssuesCulturalIssuesSH 1SH2S3SoIUse Case 1Use Case 2Use Case 3SN View 3a Scenario A Level 1 Static BehaviourS3Ser 1Use Case 1.1Use Case 1.2Use Case 1.3SoI IssuesSN View 3a Scenario A Level n Detailed Static BehaviourS1S2Use Case 1.2>SoI IssuesScenario A•Environment and Related Systems•Normal Operation•Extended Operation•Exceptional Operation•Through life issuesService 3SH1SN View 1a Initial SoI ConceptSH2Capability 1Service 1Service 2SoI AMA View 1b SoI A Operation ConceptRequired•Replace S1Optional•Consider S2?Concerns•Consider impact on supportSN View 1– Future Concept
SN Views 2– Scenario Modelling & Allocation(Combining structure and behaviour from the allocated scenario set)SN View 4b/c Stakeholder RequirementsService 3SH1SN View 1a Initial SoI ConceptSH2Capability 1Service 1Service 2SoI AService 3SH1SN View 5a Expanded SoI ConceptSH2Capability 1SoI AElement 2Service 1Service 2SoI A Element 2SH 1Ser 2SH 2Ser1:SoISN View 2b SoI Concept Dynamic BehaviourSH 1SH2S3SoIUse Case 1Use Case 2Use Case 3SN View 2a SoI ConceptLevel 1 Static BehaviourSer 3SH1SN View 4a Key NeedsSH2Cap 1SoI ElementSer 1Ser 2SoI Element 2SH 1NeedSH 2NeedLegalNeedS3Ser 1Use Case 1.1Use Case 1.2Use Case 1.3SoI IssuesSN View 2a SoI ConceptLevel n Detailed Static BehaviourS1S2Use Case 1.2>SoI IssuesMA View 5b SoI A Operation ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SN View 5c Ontology•Term X means ….•Term Y means …MA View 1b SoI A Operation ConceptRequired•Replace S1Optional•Consider S2?Concerns•Consider impact on supportSN Views 4 – Stakeholder Needs & RequirementsSN Views 1 and 5 – Future ConceptSN View 2e Scenario AllocationThese Views support proposed Future Service SoI Operation Concept (Future OpsCon)
69Emergency Medical Example Part 1b – Stakeholder Needs
SN-Views 5: Extended Concept Description, OntologySN-Views 1: Concept Structure, Description, OntologySN-Views 4 Stakeholder NeedsMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourSN-View 3 Static & Dynamic Behaviour(Scenario Specific)MA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 4b StakeholdersSN-View 4a NeedsFuture Concept ViewpointConcept Stakeholder Needs ViewpointConcept Scenario & Behaviour Viewpoint
SN-View 1a Improve Mobile Monitoring & Treatment (IMMT)Future Concept and candidate SoI Version 2 based on generalised operational conceptTreatmentPlatformMedicalResponseSupportResponseControl RoomShare status & plansIncidentPatientRecoverGain AccessEmergency treatmentRecoveryControlMobileTreatmentMedical Response CentrePatient InfotransportProvideIncident InfoRecoveryCrewPatient DetailsEmergency MedicalResponseTreatmentControlRecoveryPlatformA&ETreatmentHospitalTreatmentProvide StatusHospitalHospitalAdminRemote Monitor& TreatmentMobileMedical ActorIncidentControlLocationControlControlIncidentGather InfoIncidentEmergencyServicessupportGeneralPublicReport incidentReportIncidentControlStores & Maintain.Mobile TreatmentMedical RecoveryMay be linkedMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.
•Based on the IMMT Concept, but generalise to define mobile treatment independent of current Ambulance•Required improvements:•Add additional data sharing between Mobile Treatment and A&E•Expand the sharing of Mobile patient data with A&E•Review the mobile treatment offered in the Ambulance•Desired improvements•How can the A&E Assessment and Planning activities be improved using mobile data•How can the Mobile Treatment be supported from A&E•How can A&E Treatment be improved making use of new Assessment and Planning•Opportunities•Mobile Treatment Platform could be provided by Ambulance, or by a different platform?•Consider further data sharing expansions to allow exploration of Remote Treatment technologies•Concerns•Must continue to provide medical support to Recovery•The impact of all changes on Support must be identified and managed•The impact on crew and other staff training must be identified and managed•Consider the challenges of the changing urban population and incident typesSN-View 1b: Improve Mobile Monitoring & TreatmentConcept Description (taken directly from MA-View 5b)
•Routine Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling (e.g. transport of old or ill people to therapy or treatment, pregnancy check-up, etc.)•Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Emergency Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling in response Medical Incident•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents•Emergency Treatment: All patient treatment conducted by A&E staff•Patient Assessment: Gathering patient information and assessing their medical condition and treatment options•Mobile Assessment: Early Patient Assessment in the Ambulance, sufficient to support on-board treatment and to provide an starting point for A&E Assessment•Mobile Treatment: All patient treatment conducted in the Ambulance during patient recovery, this is an extension of Emergency Treatment constrained by available mobile resources. •Stabilisation: medical aid conducted by Ambulance staff, sufficient to allow safe transport (assessed against patient risk if not moved), for both routine and emergency recovery. This is a sub set of the more general mobile treatment, focus on improving SN-View 1b IMMT SoI Concept Ontology (based on MA-View 5b: Emergency Medical Recovery)
SN-Views 5: Extended Concept Description, OntologySN-Views 1: Concept Structure, Description, OntologySN-Views 4 Stakeholder NeedsMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourSN-View 3 Static & Dynamic Behaviour(Scenario Specific)MA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 4b StakeholdersSN-View 4a NeedsFuture Concept ViewpointConcept Stakeholder Needs ViewpointConcept Scenario & Behaviour Viewpoint
75SoI Concept Scenarios & Behaviour Viewpoint•Purpose•Define the mission behaviour related to a proposed SoI problem context:•Feedback on the Mission Analysis•Explore scenario specific SoI related behaviour in the capability context•Views•MA-View 5: Current Capability Behaviour•SN-View 3 SoI Concept Scenario Behaviour (for each scenario)•SN-View 3a SoI Concept Static Behaviour Scenario n (modified from MA-View 5a)•SN-View 3b SoI Concept Dynamic Behaviour Scenario n (modified from MA-View 5b)•SN-View 3c SoI Concept Operational Activities Scenario n•SN-View 3d SoI Concept Stakeholder Stories/issue Scenario n•SN-View 3e SoI Concept Operational Scenario n Description•SN-View 2a-e SoI Concept Allocated Behaviour
SN-View 3e: : IMMT Concept Operational Scenarios Definition (based on capability level scenarios MA-View 2c)
77Identification of Needs and Stakeholder Engagement•To help identify how we want a future concept to operate and what value it will provide to the stakeholder, we need to use the model views to walk through the operational concept.•This can include:•Extracting operational steps from current documentation•Observing current operations or talk through scenarios with the stakeholders•Identify the additional activities we need from the future concept•Consider any wider issues or constraints on these activities•We can use this to expand our MA views to describe the Future Concept in more detail•Identify Stakeholders•Current Ambulance Crews•A&E Emergency Doctors•Hospital Administration•Patients•Emergency Services•Building Operators•Regulators•Others?•Stakeholder (or User) Stories are one way to capture activities and Needs. They can be very detailed or general, capture by observation or discussion, supported by the SN model views
SN-View: Improved Mobile Monitoring & Treatment (IMMT) Concept How the future concept contributes to Emergency Recovery Service in Scenario 3.1
SN-View 3e: IMMT Concept Operational Scenarios Definition – Scenario 3.1Scenario 3.1: Urban Road Incident•Recover a max of 2 casualties injured in a road accident•Accident location within “Down Town” area•Mobile Incident Control set up by police, who then coordinate any recovery response needed•Normal conditions:•Day time with benign weather conditions; moderate traffic•Incident secured and made safe by rescue teams•Injuries serious, but can be stabilised for transport•Extended Conditions:•Night time, severe weather, heavy traffic•Incident stable but with some risks, possible moderate security treats•Injuries very serious, emergency treatment needed on site•Exceptional Conditions:•“Natural Disaster” or civil emergency•Serious security risk
ControlRecoverySupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentAmbulanceSupportRecoveryControl<>Emergency TreatmentAmbulancevehicleControlIncident<>PublicReportuc Emergency Medical Recovery CapabilityAmb. RecoveryCrewAdmitPatientHospitalAdminTransportPatient<><>A&EMobile StabiliseAmbulanceMedical<>HandoverPatient<><>MA-View 2a: Emergency Medical Recovery & TreatmentConceptual Solution Behaviour (based on currently deploy solution views)
ControlResponseSupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentMobilitySupportResponseControl<>Emergency TreatmentRecoveryResponseControlIncident<>PublicReportuc SN View 3a (IMMT) Level 1AdmitPatientHospitalAdminTransportPatient<><>A&EMobile TreatmentMobile Medical Response<><><>SN-View 3a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 1 – contribution to Capability in Scenario 3.1
We will still need to travel to the incident and get safe access to the patientThe current ambulance monitoring and basic treatment will be a good starting pointWith more equipment and skills we can provide other early treatmentSharing this in real time with A&E?Do we call for recovery if it is needed? What happens it we can complete treatment?If we had knowledge of the mobile treatment we could begin to plan our treatmentCould our plan also be used to guide the mobile medics?Could we do more than just share plans with them?Who calls us in?We will still need the patent stabilised for transport?Make sure any new equipment, on whatever vehicle, can be supportedWill we be driving any new platforms?If we need new A&E facilities, they need to be supportedWill A&E doctors be needed to crew the mobile treatment vehicles?SN-View 3d: Improved Mobile Monitoring & Treatment (IMMT) Concept Stakeholder Stories/issues – Emergency Treatment and Recovery in Scenario 3.1
IncidentControlPublic/EmergencyServicesReport IncidentIncident Planning DeployResponseResponseReportSecure PatientTransport PatientUnload PatientMove PatientLocate PatientMonitorMobile PatientAssess PatientStabilise PatientEmergency TreatmentHospitalReleasePatientAssessResourcesAdmitPatientIncidentReportProvide StatusPrepareVehiclesNavigate toIncidentad: Emergency Recovery and TreatmentProvideAccessRe SupplyVehiclesAmbulanceVehicleAmbulanceControlAmbulanceSupportAmbulanceRecovery CrewEnsureSafeAccessHand OverPatientA&E TreatmentAmbulance MedicalCrewMA-View 2b: Emergency Medical Recovery & TreatmentConceptual Solution behaviour (based on currently deploy solution views)MonitorMobile Patient
IncidentControlA&EPublic/EmergencyServicesMobile Medical ResponseSystemRecovery ResponseSystemResponseControlReport IncidentIncident Planning ResponseReportSecure PatientTransport PatientUnload PatientLocate PatientMonitorMobilePatientAssess PatientA&E TreatmentHospitalReleasePatientAdmitPatientIncidentReportResponseSupportPrepareVehiclesPlan TreatmentMobileTreatmentProvide Clearance & AccessDeployMedical ResponseDeployRecovery ResponsePlanResponseLocate PatientNavigate toIncidentNavigate toIncidentRe SupplyVehiclesSN View 3b IMMT Concept Level Emergency Treatment & Recovery Move PatientMonitorPatientStabilise PatientSN-View 3b: Improved Mobile Monitoring & Treatment (IMMT) Concept Dynamic Behaviour Level 1– SoI contribution to Emergency Treatment and Recovery scenario 3.1
1.Control Incidenta)Incident reportedb)Incident control establishedc)Response requestedd)Provide safe access to incident2.Manage Responsea)Assess Response needsb)Allocate Recovery/Treatmentc)Control deploymentd)Request site access3.Prepare mobility assetsa)Allocate Recovery Equipmentb)Allocate Medical Equipmentc)Allocate crew4.Recovery Mobilitya)Deploy to incidentb)Secure patient for transportc)Transport to A&E5.Dismounted Mobilitya)Locate patientb)Secure for movec)Load/Unload Patientd)Move patient to A&E6.Treatment Mobilitya)Deploy to incidentb)Secure patient for Treatmentc)Request Recoveryd)Handover to Recovery7.Mobile Treatmenta)Assess patient condition (mobile)b)Stabilise for transportc)Monitor and Report patient Status (mobile)d)Perform Mobile Treatmente)Enable Remote Treatment8.A&E Treatmenta)Hand over to A&Eb)Assess and monitor patient conditionc)Plan Treatmentd)Conduct Remote Treatmente)Conduct TreatmentSN-View 3c: Improved Mobile Monitoring & Treatment (IMMT) Concept Operational Activities Scenario 3.1 – contribution to Emergency Treatment and Recovery
AirportHospitalMallFireSchoolMallOfficeBlockAmbulanceStationOfficeBlockRiverVenueUrban LocationOutside Urban LocationParkIncident Response HQPoliceA&eFreewayRescueVehiclesRiver walkCommercial airspaceCarpark1a Incident Reported1b Incident control established1c Recovery requested1d Provide safe access to incident2a Response assessment2b Allocate Response2c Control deployment3a Allocate Recovery Equipment3b Allocate Medical Equipment3c Allocate crew6a Deploy Treatment to incident6b Secure for Treatment6c Call for recovery4a Deploy Recovery to incident7a Assess mobile condition7c Monitor & Report Status7d Perform Mobile Treatment7e Enable Remote Treatment5b Stabilise for transport4b Secure patient for transport6d Handover to Recovery4c Transport to A&E5c Un-Load Patient5d Move to A&E2d Request site access5a Locate Patient7b stabilise for transport5b Secure for Move5c Load Patient8a Hand over to A&E8b Assess and Monitor patient condition8c Plan Treatment8d Conduct Remote Treatment8e Conduct A&E 3.1SN-View 3c: Improved Mobile Monitoring & Treatment (IMMT) Concept Graphical Operational Activities
AirportHospitalMallFireSchoolMallOfficeBlockAmbulanceStationOfficeBlockRiverVenueUrban LocationOutside Urban LocationParkIncident Response HQPoliceA&eFreewayRescueVehiclesRiver walkCommercial airspaceCarpark1a Incident Reported1b Incident control established1c Recovery requested1d Provide safe access to incident2a Response assessment2b Allocate Response2c Control deployment3a Allocate Recovery Equipment3b Allocate Medical Equipment3c Allocate crew6a Deploy Treatment to incident6b Secure for Treatment6c Call for recovery4a Deploy Recovery to incident7a Assess mobile condition7c Monitor & Report Status7d Perform Mobile Treatment7e Enable Remote Treatment5b Stabilise for transport4b Secure patient for transport6d Handover to Recovery4c Transport to A&E5c Un-Load Patient5d Move to A&E2d Request site access5a Locate Patient7b stabilise for transport5b Secure for Move5c Load Patient8a Hand over to A&E8b Assess and Monitor patient condition8c Plan Treatment8d Conduct Remote Treatment8e Conduct A&E 3.1SN-View 3d: Improved Mobile Monitoring & Treatment (IMMT) Concept Stakeholder Stories/issues – Emergency Treatment and Recovery in Scenario 3.1Each colour represents a different Stakeholder dialogueWhen an accident happens someone calls the policeEmergency Services respond and set up overall controlThe Incident Control can call for an Ambulance if neededWe assess the medical need and dispatch an AmbulanceWill need to consider new Medical equipment on-boardWe may need help from emergency service to recover the patientAt what point can treatment start?Once we arrive, we need to stabilise the patient and move to the ambulanceWe can start to monitor and assess in the vehicleWill need to share this with A&EA&E staff begin to assess and plan when we get the data reportThis will now start as soon as the Ambulance start to send dataCan we share our Plans with the Ambulance and help them provide treatment?Will need to Plan and deliver out new Mobile TreatmentHow will A&E help with this?A&E take over treatment once the patient arrivesIf we have staff involved as soon as the assessment start we can offer Remote supportWhat extra support do Medical Crew need?How do we keep them safe?What if we complete the treatment or patient dies?We are controlling a Medical Response, not just a recovery
IncidentControlA&EPublic/EmergencyServicesMobile Medical ResponseSystemRecovery ResponseSystemResponseControlReport IncidentIncident Planning ResponseReportSecure PatientTransport PatientUnload PatientLocate PatientMonitorPatientAssess PatientA&E TreatmentHospitalReleasePatientAdmitPatientIncidentReportResponseSupportPrepareVehiclesPlan TreatmentMobileTreatmentProvide Clearance & AccessDeployMedical ResponseDeployRecovery ResponsePlanResponseLocate PatientNavigate toIncidentNavigate toIncidentRe SupplyVehiclesSN View 3b IMMT Concept Level Emergency Treatment & Recovery Move PatientMonitorPatientRequestRecoveryStabilise PatientRemotelyControlledTreatmentSN-View 3b: Improved Mobile Monitoring & Treatment (IMMT) Concept Dynamic Behaviour Level 1 – contribution to Emergency Treatment and Recovery scenario 3.1
RecoverPatientControlRecovery ResponsePrepareAssetsTransportPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Recovery Service Scenario 3.1RecoveryPlatform<><>MobileStabilise<>DismountedPatientTransport<>Amb.RecoveryCrewA&EEnsure SafeAccess<>MobilitySupportRecoveryControlMobileTreatmentSN-View 3a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2– SoI contribution to Emergency Recovery Service in Scenario 3.1uc SN View 3a IMMT Concept Scenario 3.1 – Level 2 Emergency Recovery ServiceCall forRecovery<>
EmergencyTreatmentAssessPatientPatientsPublicEmergency Treatment Service Scenario 3.1A&E SustainmentAssessMobilePatientProvideUpdatesA&EAdminMobileStabilise<><>AdmitPatientTransferPatient<>HospitalAdminControlMedicalResponsePrepare/SustainAssetsResponseControlMobilitySupportTreatment Platform<><>MobileTreatment<>A&EMobileTreatmentShare Real-TimeAssessment<>SN-View 3a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2– Scenario 3.1 (Version 2 – Extended Stakeholder discussions)uc SN View 2a IMMT Concept Scenario 3.1 Level 2 Emergency Treatment Service (V2)RemoteTreatment<>Call forRecovery<><>
AirportHospitalMallFireSchoolMallOfficeBlockAmbulanceStationOfficeBlockRiverVenueUrban LocationOutside Urban LocationParkIncident Response HQPoliceA&EMotorwayRescueVehiclesRiver walkCommercial airspaceCarparkResidentialMA-View 3a: Emergency Medicine and Recovery Stakeholders, conflict, issue or opportunities(Based on ENT View 3d if it exists)Public Building (PB):•Building Owners•Workers•Maint, Cleaning•Public•Unions•InspectorsPB +ParentsTeachersChildrenHome OwnersBanksResidentsVisitorsTrafficTraffic:•Driver•Passenger•Pedestrian•Police•Local Auth.PB +SecurityCommercialPB +PerformersVendorsPB +DoctorsPatientsAdminPoliceFireLegislationStakeholdersVehicle AccessOlder residentsNon English speakersVehicle AccessUn accompaniedChildrenVehicle AccessCrowdsSecurityAccessTrafficRush hourCrowdsAlcohol/drugsStaff/ResourcesSecurityCommunicationOld & New technologyOld & New technologySecurityThreatsIssues
AirportHospitalMallFireSchoolMallOfficeBlockAmbulanceStationOfficeBlockRiverVenueUrban LocationOutside Urban LocationParkIncident Response HQPoliceA&eFreewayRescueVehiclesRiver walkCommercial airspaceCarpark3.1SN-View 3d: Improved Mobile Monitoring & Treatment (IMMT) SoI Concept Stakeholder Stories/Issues contribution to Emergency Treatment and Recovery in Scenario 3.1Traffic delays AmbulanceDo we have enough vehicles and equipment?What about support and training?Is the patient conscious to consent to treatment?Female patients or children?Language and other cultural issues?Skills of current or future crew?Data Bandwidth and security?Skills of current or future Staff?Not all patients survive!
EmergencyTreatmentAssessPatientPatientsPublicEmergency Treatment Service Scenario 3.1A&E SustainmentAssessMobilePatientProvideUpdatesA&EAdminMobileStabilise<><>AdmitPatientTransferPatient<>HospitalAdminControlMedicalResponsePrepare/SustainAssetsResponseControlMobilitySupportTreatment Platform<><>Delay in patient data reduces A&E effectivenessMobileTreatment<>A&EMobileTreatmentCould extend treatments available in A&E with more time to preparePatients with life threatening internal injury, loss of consciousness or heart functionMay not survive recoveryShare Real-TimeAssessment<>Data Link bandwidth and securitySN-View 3a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2– Scenario 3.1 (Version 2 – Extended Stakeholder discussions)uc SN View aa IMMT Concept Scenario 3.1 Level 2 Emergency Treatment Service (V2)RemoteTreatment<>Call forRecovery<><>
RecoverPatientControlRecovery ResponsePrepareAssetsTransportPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Recovery Service Scenario 3.1RecoveryPlatform<><>MobileStabilise<>DismountedPatientTransport<>Amb.RecoveryCrewA&EEnsure SafeAccess<>MobilitySupportRecoveryControlEmergency services to ensure crew safetyConsider needs for patient handlingStill need to stabilise for transportMobileTreatmentSN-View 3a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2– SoI contribution to Emergency Recovery Service in Scenario 3.1uc SN View 3a IMMT Concept Scenario 3.1 – Level 2 Emergency Recovery ServiceCall forRecovery<>
95Considering Other Scenarios•In the above example we looked at a specific “User Story” for Scenario 3.1•We can do the same thing for other version of 3.1, and for the other scenarios•What would this add:•Additional external relationships, or variants of those already defined.•Additional behaviour, or extensions of that already defined•The more scenarios we do, the less new things emerge. But, we may identify critical information needed to ensure project success!•How many scenarios do we consider:•This depends on Project Scope and Purpose, how much time do you have? what risks can you take? etc.•This question might be related to the type of project life cycle, e.g. sequential or iterative. •Agile life cycles are based on selecting which scenario to consider in the next sprint.There are process control modelling techniques (e.g. Taguchi methods or growth curves) to optimise this kind of activity on the basis of added value and diminishing return.e.g. how long since last new thing found, how critical is it to find them all and thus how many more should I try?
SN-View 2e: : IMMT Concept Operational Scenarios Allocation (based on capability level scenarios MA-View 5c)
97Additional Scenario analysis – which Scenarios to consider?•1.3 Heart attack in Public Space; Peanut allergic reaction in Public Space•1.4 Head injury in Private Home; Child berth complications in Private Home•1.5 Chest wound in secure Private Building; Heart attack in Private Building•1.7 Crushed legs in Concert Venue; Broken arm in School•3.3 Fire burns in Public Space; Fire smoke inhalation in Public Space•3.4 Fire smoke inhalation in Shopping Mall; Fire burns in Private Home•3.5 Building Collapse in Private Building; Building Collapse in Private Building•3.7 Building Collapse in Concert Venue; Building Collapse in Concert Venue•4.2 Gun Shot wounds on Residential Road•4.3 Bomb Blast in Public Space; Bomb Blast in Public Space•4.5 Bomb Blast in Private Building•4.7 Gun Shot wounds at Concert Venue
98Additional Scenario analysis – Things we might find•Access and Security issues:•Access to private building•Access to secure locations, need for security cleared staff or escorts?•Access to small or difficult to reach locations•Patient and General Public Issues•First aid provided by First Responder, handover to response•Wider range of medical conditions, not all possible with mobile crew•Language, Gender, Age, or other cultural concerns when communicating with or treating people•Access to patient information, allergies, existing conditions, medication, etc.•Patient physical characteristics, size, weight, ability, etc.•Complex incidents and locations•Technology compatibility•ETC.
99Other Life Cycle Issues•The primary outcomes of MA and SNR in the Concept stage is to identify and define a future Gap or Opportunity, as basis for SoI Options•As part of a life cycle approach, there are other questions we should ask, based on the view created so far:•Baselines of technology options and roadmaps, including any enterprise technology strategy•Identify risks and resources for integration and verification, plan for any big issues•Other possible issues such as supply chain strategy, training or recruitment, etc. Do we fit into current enabling services or need to change them?•Capability dimensions, such as MoD LoD are useful for raising such issues.•The full decisions about technology, risk, supply chain, value proposition, etc. is made later in the life cycle. But we begin thinking about it here.
SN-Views 5: Extended Concept Description, OntologySN-Views 1: Concept Structure, Description, OntologySN-Views 4 Stakeholder NeedsMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourSN-View 3 Static & Dynamic Behaviour(Scenario Specific)MA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 4b StakeholdersSN-View 4a NeedsFuture Concept ViewpointConcept Stakeholder Needs ViewpointConcept Scenario & Behaviour Viewpoint
101SoI Concept Scenarios & Behaviour Viewpoint•Purpose•Define the mission behaviour related to a proposed SoI problem context:•Feedback on the Mission Analysis•Explore scenario specific SoI related behaviour in the capability context•Views•MA-View 5: Current Capability Behaviour•SN-View 2 SoI Concept: Scenario Behaviour (for each scenario)•SN-View 2a SoI Concept Scenario Static Behaviour (modified from MA-View 5a)•SN-View 2b SoI Concept Scenario Dynamic Behaviour (modified from MA-View 5b)•SN-View 2c SoI Concept Operational Activities Behaviour•SN-View 2d SoI Concept Stakeholder Stories/issue•SN-View 2e SoI Concept Operational Scenario Allocation•SN-View 3a-d SoI Concept: Combined Scenario Behaviour

ControlRecoveryResponsePrepareAssetsTransportPatientPatientsPolice/Security/Emergency ServicesPublicReportIncidentIncidentControlRecovery Platform<><>MobileStabiliseDismountedPatientRecovery<>RecoveryCrewA&EEnsure Safe & SecureAccess<>MobilitySupportResponseControlEstablish AppropriatecommunicationGovt.CommsStandard<><>LocationAccess/SecurityDeployrecoveryResponse<>Move to SafeLocationFirstResponderFirstAid<><><><>SN-View 2a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2–contribution to Emergency Recovery Service in Allocated ScenariosEmergency Recovery Serviceuc SN View 2a IMMT Concept– Level 2 Emergency Recovery ServiceMobileTreatmentConduct AppropriateInteractionsHospitalTraining<>
EmergencyTreatmentAssessPatientPatientsPublicA&E SustainmentProvideUpdatesMobileTreatment<>RemoteTreatment<>AdmitPatientTransferPatient<>HospitalAdminControlTreatmentResponsePrepare/SustainAssetsRecoveryControlMobilitySupportTreatmentPlatformA&EInfrastructureEstablish AppropriatecommunicationGovt.CommsStandard<><>Conduct AppropriateInteractionsHospitalTraining<>A&EDoctorA&EAdminManageSupplies<>ReleasePatient<>DeployMedicalResponse<><><>SN-View 2a Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 2–contribution to Emergency Treatment Service in Allocated ScenariosEmergency Treatment Serviceuc SN View 2a IMMT Concept– Level 2 Emergency Treatment ServiceAssessMobilePatient<><>Share Real-TimeAssessment<>MobileStabiliseMobileTreatmentMedial consumablesSupply Chain
IncidentControlA&EPublic/EmergencyServicesMobile Medical ResponseSystemRecovery ResponseSystemResponseControlReport IncidentIncident Planning ResponseReportSecure PatientTransport PatientUnload PatientLocate PatientMonitorPatientAssess PatientA&E TreatmentHospitalReleasePatientAdmitPatientIncidentReportResponseSupportPrepareVehiclesPlan TreatmentMobileTreatmentProvide Clearance & AccessDeployMedical ResponseDeployRecovery ResponsePlanResponseLocate PatientNavigate toIncidentNavigate toIncidentRe SupplyVehiclesEnsureSafe/SecureLocationSN View 2b IMMT Concept Level Emergency Treatment & Recovery Move PatientMonitorPatientRequestRecoveryStabilise PatientRemotelyControlledTreatmentEnsure Compliance & trainingFirst AidSN-View 2b: Improved Mobile Monitoring & Treatment (IMMT) Concept Dynamic Behaviour Level 1–contribution to Emergency Treatment and Recovery allocated scenarios
ControlRecoverySupportAssetsRecoverPatientPatientsPolice/Emergency ServicesPublicReportIncidentIncidentControlEmergency Medical Recovery & TreatmentMobilitySupportResponseControl<>Emergency TreatmentRecoveryResponseControlIncident<>PublicReportuc SN View 2a (IMMT) Level 1AdmitPatientHospitalAdminTransportPatient<><>A&EMobile TreatmentMobile TreatmentResponse<><><>SN-View 2a: Improved Mobile Monitoring & Treatment (IMMT) Concept Static Behaviour Level 1– contribution to Capability in Allocated ScenariosMeet Interaction Standards and RulesExternalAuthorities<><>
SN-Views 5: Extended Concept Description, OntologySN-Views 1: Concept Structure, Description, OntologySN-Views 4 Stakeholder NeedsMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourSN-View 3 Static & Dynamic Behaviour(Scenario Specific)MA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 4b StakeholdersSN-View 4a NeedsFuture Concept ViewpointConcept Stakeholder Needs ViewpointConcept Scenario & Behaviour Viewpoint
108SoI Stakeholder Needs•Purpose•Define the Stakeholder Needs related to a proposed SoI problem context:•Feedback on the Mission Analysis•Basis for the definition of Stakeholder Requirements•SN Views•SN-View 4a SoI Concept: Stakeholder and Key Needs•SN-View 4b SoI Concept: Stakeholder Detailed Needs and Measures of Effectiveness (MoE)•SN-View 5a SoI Concept Extended Context•SN-View 5b SoI Concept Extended Definition/Ontology
AmbulanceVehicleAmbulanceSupportRecoveryControl RoomA&EAssessment & TreatmentIncidentLocationHospitalTreatmentStores & MaintainsPrepares for useShare status & plansIncidentPatientRecoverGain AccessControlIncidentEmergency treatmentProvide StatusAmbulanceControlMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.Ambulance DepotIncidentHospitalAmbulancePatient InfoEmergencyServicescoordinatestransportGeneralPublicAmbulanceRecoveryCrewHospitalAdminTreatmentPatient DetailsEmergency MedicalRecoveryControlRecoveryInvolved in IncidentInvolved in IncidentAmbulanceMedicalMobileTreatmentPatient Data Treatment SupportIncidentControlReport incidentSN-View 4a: Improved Mobile Monitoring & Treatment (IMMT) Concept Stakeholders and Key NeedsHospital Emergency Medical Stakeholder1 Improve Survivability of emergency patientsIncident Control Stakeholder(Public, Police, Fire, Private Building, etc.)7 Report all Incidents and get appropriate medical responsePatient Stakeholder3 Appropriate handling and communicationsRecovery Stakeholder4 Sustain Existing Recovery ServicesMedical Response Control/Support Stakeholder6 Continue to Control and Support any new ResponseOther Medical Stakeholders5 Consider Staff Training, Infrastructure, regulators, etc.Other Incident Stakeholders8 Consider impact of new SoI on Bystanders, roads, regulations, infrastructure, etc.Regulatory Stakeholders9 Comply with Comms spectrum, Govt. Standards, etc.Mobile Medical Stakeholder2 Improve Mobile Treatment to support Survivability

SN-View 4b: Improved Mobile Monitoring & Treatment (IMMT) SoI Concept Stakeholders Detailed Needs and MoE
SN-View 4b: Improved Mobile Monitoring & Treatment (IMMT) SoI Concept Stakeholders Detailed Needs and MoE
<> HospitalNeeds essential:Patientsrecovered from all defined incidents: X2% recovery timePatientsnone urgent transport from all defined situations: X3% transport timePatientwith all defined medical conditionsto be stabilized: X1% survival probabilityPatientsto be admitted to hospital care: S1 admittance standardsPatientwith all defined medical conditionsemergency treatment: X1% survival probabilityPatientwith all defined medical conditionsmobileemergency treatment: X1% survival probabilityPatientsto have mobile treatment and release recorded following S1 admittance standardsNeeds optionalPatientwith all defined medical conditionsto receive remoteemergency treatment: X1% survival probabilityConditionsIncidents include road accidents, must deal with range of handling issues, e.g. language, disability, culture, etc.Medical conditions may range from injury and bleeding, to life threatening internal injury, to loss of consciousness or heart function, chemical burns or inhalation, explosive or crush injuries, allergic reactions, etc.<> PatientNeeds essential:handled in a way which does not cause additional harm: MoE TBD?treated in a way which is appropriate to all social and cultural needs (TBD)provided with necessary information an:, MoE TBD?<> Incident LocationNeeds essential:Needs to call for medical Response as neededNeeds response to move to the exact incident locationNeeds to be able to ensure response crew safety at the incident location Needs to be able to ensure response crew have appropriate security access to locations…<> Emergency Response ControlNeeds essential:Needs information to control, response<> Emergency Response SupportNeeds essential:Needs new solutions to fit into support service<> EnvironmentalNeeds essential:Regulations: fit into relevant standardsRoads: fit into emergency vehicle regulationsStakeholders<>Mobile & A&ETreatmentHave needs related toSN-View 4b: Improved Mobile Monitoring & Treatment (IMMT) SoI Concept Stakeholders Detailed Needs and MoE
TreatmentPlatformMedicalResponseSupportResponseControl RoomShare status & plansIncidentPatientRecoverGain AccessEmergency treatmentRecoveryControlMobileTreatmentMedical Response CentrePatient InfotransportProvideIncident InfoRecoveryCrewPatient DetailsEmergency MedicalResponseTreatmentControlRecoveryPlatformA&ETreatmentHospitalTreatmentProvide StatusHospitalHospitalAdminMobileMedical ActorIncidentControlLocationControlControlIncidentGather InfoIncidentEmergencyServicessupportGeneralPublicReport incidentReportIncidentControlStores & Maintain.Mobile TreatmentMedical RecoveryMay be linkedMedicalStaffDept. ofHealthSocietyAvailabilityTrainingEtc.LanguagePhysicalGenderEtc.BudgetsPolicyFixed CommsnetworksRoadsExistingBuildingsBandwidthAvailabilityRulesLawsCongestionEtc.LocationSecurityAccessEtc.SN-View 5a Improve Mobile Monitoring & Treatment (IMMT) ConceptExpanded Capability Context –based on outcomes of the scenario modelling (expands on SN-View 1a)<> Mobile TreatmentConcept:•Share Monitoring•Extended Mobile Treatment•Consider Remote Treatment•Improve Data Link<> A&E Emergency TreatmentConcept:•Share Treatment Plan•Support Mobile Treatment•Manage Medical Supplies•Conduct Remote Treatment•Improve Data LinkShared patient dataHospitalSuppliesSupply ChainCompanies
•The IMMT will provide the following, responding to the detailed Stakeholder Needs (Requirements?)•Patient Assessment:•Expand the sharing of Mobile patient data between Ambulance and A&E•Propose new A&E Assessment and Planning activities using mobile data•Add data link between Ambulance and A&E to enable sharing•Consider how to distribute Assessment between Ambulance and A&E•Patient Treatment:•Propose new mobile treatment in the Ambulance, using live assessment•Propose new A&E treatment in the Ambulance, using live assessment•Explore the addition of Remote treatment from A&E into the Ambulance, using data link•While consider the impact of the following:•Must continue to provide medical support to Recovery•The impact of all changes on Ambulance Support must be identified and managed•The impact on crew and other staff training must be identified and managed•Consider the challenges of the changing urban population and incident typesSN-View 5b: Improve Mobile Monitoring & Treatment SoI Expanded Concept Description (based on SN-View 1b)
•Routine Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling (e.g. transport of old or ill people to therapy or treatment, pregnancy check-up, etc.)•Medical Incident: a medical condition requiring Emergency Treatment.•Urgent: patient in immediate danger of serious long term impairment or loss of life (Heart Attack, major fall, loss of limb, pregnancy with complications, etc.)•Minor: patient in discomfort and with loss of functions, but no immediate danger (broken arm, minor fall, minor wound, pregnancy, etc.)•Emergency Incident: an incident or other circumstance involving people which requires rescue and recovery and could lead to medical incidents (traffic accident, fire, workplace accident)•Emergency Medical Recovery: need for transport which could require monitoring, stabilisation or special patient handling in response Medical Incident•Major Event: social or public event at which emergency or medical incidents could occur (sporting event, concert, protest march, etc.)•Security Incident: event or incident with additional security implications, which could include emergency incidents•Emergency Treatment: All patient treatment conducted by A&E staff•Patient Assessment: Gathering patient information and assessing their medical condition and treatment options•Mobile Assessment: Early Patient Assessment in the Ambulance, sufficient to support on-board treatment and to provide an starting point for A&E Assessment•Mobile Treatment: All patient treatment conducted in the Ambulance during patient recovery, this is an extension of Emergency Treatment constrained by available mobile resources. •Stabilisation: medical aid conducted by Ambulance staff, sufficient to allow safe transport (assessed against patient risk if not moved), for both routine and emergency recovery. This is a sub set of the more general mobile treatment, focus on improving survival during transport.•Remote Treatment: All patient treatment conducted in the ambulance using direct support or remote intervention from medical staff based in other locations, such as in A&E or other parts of the hospital.•Data Link: some mechanism by which useful data (including medical data) can be shared more fully between Ambulance and A&E. May be real time or periodic, could be voice, data, video, etc. as needed.SN-View 5b: Improve Mobile Monitoring & Treatment SoI ConceptExpanded Concept Ontology (based on SN-View 1c)
SN-Views 5: Extended Concept Description, OntologySN-Views 1: Concept Structure, Description, OntologySN-Views 4 Stakeholder NeedsMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourSN-View 3 Static & Dynamic Behaviour(Scenario Specific)MA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 4b StakeholdersSN-View 4a NeedsFuture Concept ViewpointConcept Stakeholder Needs ViewpointConcept Scenario & Behaviour Viewpoint
118Case Study Discussion•There is some confusion in SE literature about the nature and role of Stakeholder Needs (and the Requirements we might create from them). A few clarifications:•Stakeholder Needs are a View captured as part of our MBSE model, they can be used to create Requirements and this will be discussed later. The focus on needs first allows us to model a full range of views, not all of which might lead to requirements.•In OOSEM “Mission Requirements” are capture for the identified problem context. In complex situations a SoI may have multiple missions, and possibly conflicting needs. In E-MBSE we model a number of operational scenarios to understand this. Combining the needs across scenarios is part of the Requirements process.•Stakeholder needs are solution independent statements which help to bound a problem, but they define a problem around an initial SoI context. In an Enterprise we may be focused on a number of such problems at the same time and this also needs to be covered.•This is partly because traditional SE starts from a specific problem statement, which already comes with an implicit SoI. •If we are exploring Capability and Service delivery within an Enterprise we should have a documented set of scenario views and needs associated with the current organisation. Hence, this process should involve the review and extension of views and stakeholder needs. In the rare case that we are considering a totally new way to deliver Capability we might have to create these views from scratch.•The bounding of the SoI and identification of the Stakeholder Needs related to it is as far as we can go with considering potential Solution Concepts
119EnterpriseStrategic ModellingMission AnalysisStakeholder Needs & RequirementsFeedbackTo complete and validateFeeds intoFeeds intoWhenWhoTo support Enterprise Strategy/Planning•As an Enterprise Planning reference•To support Capability Audit•To support Programme definition and review•To support any MA•To support Project Concept Stage (would need to create some MA views)Business ModellerEnterprise Architect(external consultant)Business ModellerEnterprise ArchitectRequirements ManagerProgramme Manager(Programme SE)Requirements ManagerProject ManagerProject SESE Consultant
Initial/SelectedStructure/ContextConcept/SoI Expanded Requirements/BehaviourConcept/SoIExpanded StructureInitial/SelectedBehaviourAnalysis/OptionsMA View 1Current Capability StructureMA View 2Current CapabilityBehaviourMA View 3Gaps & OpportunitiesAnalysisMA View 4Objectives/RequirementsMA View 5Future CapabilityConceptsSN View 1Future Concept Initial ContextSN View 2Future ConceptInitial BehaviourSN View 3Future ConceptScenario AnalysisSN View 4Stakeholder Needs &RequirementsSN View 5Expanded FutureConcept StructureENT View 1Enterprise BU StructureENT View 2EnterpriseMission & GoalsENT View 3Business AnalysisModelsENT View 4PortfolioPlans?ENT View 5EnterpriseRoadmap?EnterpriseStrategyCapabilityMissionAnalysisStakeholder Needs& Requirements
www.cranfield.ac.ukMSc in Systems EngineeringSpecialising in DefenceProblem Analysis and System Definition
2MSc in Systems Engineering Specialising in DefenceProblem Analysis and System Definition – PASDRick AdcockR.D.Adcock@Cranfield.ac.ukUnit 1 Early Life Cycle and MBSEUnit 1.2 MBSE MethodologyAim: Introduce the course MBSE Methodology•Review MBSE methodologies, based on Pre-Reading Part 1•Define MSc course E-MBSE methodology
3Intended Learning Outcomes•On successful completion of this module a student should be able to:1.Evaluate the application of Model Based Systems Engineering (MBSE) Concept Definition and Systems Definition life cycle processes to complex problems2.Create Mission Analysis models using scenario based modelling, to explore enterprise needs3.Create logical system architecture views to describe one or more whole system solution concepts4.Plan and apply Requirements Management processes to create and review Stakeholder Requirements5.Plan a through life approach, including consideration of dependable system issues and whole life cost
4Future Systems Engineering will be:(INCOSE Vision 2035 – Summary)
5What is Model Based Systems Engineering (MBSE)? •As we have discussed, models are an essential part of any Systems Thinking, and so all SE is based on models.•What is Model Based SE, and is it more than this?•“Model-based systems engineering (MBSE) is the formalized application of modelingto support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” (INCOSE, 2007) •“Model-based systems engineering is an approach to realizing successful systems that is driven by a model that comprises a coherent and consistent set of views that reflect multiple viewpoints of the system.” (Holt & Perry, 2014)
6Moving from Documents to Shared Models
Life CycleProcessWhy we need to model: within a life cycleSystemModelViewNotationDiagramrepresents1..*1..*1..*1visualiseis consistentwithIs consistentwith1..*1..*What we model?How we model?Is Enabledby1Viewpoint1..*applies to1..*1..*Isperceivedfrom111..*SoIContextLife CycleStageContribute toCompletion ofLife CycleDefines scope of1..n1..n1..*1Creates and usesDefineProcessActivitiesProcessOutcomes1..*1..*How we model?Contributeto1..*1..*
Life CycleProcessWhy we need to model: within a life cycleSystemModelViewNotationDiagramrepresents1..*1..*1..*1visualiseis consistentwithIs consistentwith1..*1..*What we model?How we model?Is Enabledby1Viewpoint1..*applies to1..*1..*Isperceivedfrom111..*SoIContextLife CycleStageContribute toCompletion ofLife CycleDefines scope of1..n1..n1..*1Creates and usesDefineProcessActivitiesProcessOutcomes1..*1..*How we model?Contributeto1..*1..*An evolving System Model, related to the identification and development of a System of Interest, defines the scope of and key information needed in each life cycle stage
Life CycleProcessWhy we need to model: within a life cycleSystemModelViewNotationDiagramrepresents1..*1..*1..*1visualiseis consistentwithIs consistentwith1..*1..*What we model?How we model?Is Enabledby1Viewpoint1..*applies to1..*1..*Isperceivedfrom111..*SoIContextLife CycleStageContribute toCompletion ofLife CycleDefines scope of1..n1..n1..*1Creates and usesDefineProcessActivitiesProcessOutcomes1..*1..*How we model?Contributeto1..*1..*Life Cycle Processes manage, create and use the knowledge in the evolving System Model•Process Outcomes define what we need to know (as a set of Viewpoints)•Process Activities define how the knowledge is created and used
Life CycleProcessWhy we need to model: within a life cycleSystemModelViewNotationDiagramrepresents1..*1..*1..*1visualiseis consistentwithIs consistentwith1..*1..*What we model?How we model?Is Enabledby1Viewpoint1..*applies to1..*1..*Isperceivedfrom111..*SoIContextLife CycleStageContribute toCompletion ofLife CycleDefines scope of1..n1..n1..*1Creates and usesDefineProcessActivitiesProcessOutcomes1..*1..*How we model?Contributeto1..*1..*An evolving System Model is made up of related View, organised into Viewpoints•A View defines one thing we need to know or share about the SoI Context•In a well structure Model, knowledge is defined once (on its master View) and then used, reference or commented on many times•A View may be represented using a selected Diagram.•Diagrams may be created for a View, or selected from a standardised Notation
11•All three of the views shown are representing the overall SoI Context•Defining its boundary and relationships•They are drawn using three different Diagrams•The SoI is highlighted on an SSM Conceptual model•SoI context is proposed by stakeholders using a simple block diagram•It is more formally represented as a black box in a SySML BDD•These might be drawn by different people as part of a modelling activity•Or by the same team to show to different stakeholdersOne View – Three Diagrams
12•The three views shown represent different aspects of the same system•The initial SoI Black Box Context•A more detailed SoI Breakdown•Related shared data•They are drawn using the same Diagram•They all use the Blocks and Relationships abstraction•The first two are related, but drawn by different people to support solution decisions•None of them should be labelled as a Block Diagram – but as View X drawn using a BD•The BD abstract support aspects of Systems Thinking (holism, hierarchy) and is part of a shared SE languageOne Diagram – Three Views
13•The three views shown represent different aspects of the same system•The initial SoI Black Box Context•The static SoI behaviours•How those SoI Behaviour are related•They are drawn using different Diagrams, from a single Notation•These views and how we build them up are part of our Modelling Method•The built-in diagrams and diagram relationships in SySML support this process•We will show how this “meta process” support a SE life cycle•The SySML notation provide diagrams created to help communicate via a shared SE languageThree Views – One Model, same Notation
Life CycleProcessWhy we need to model: within a life cycleSystemModelViewNotationDiagramrepresents1..*1..*1..*1visualiseis consistentwithIs consistentwith1..*1..*What we model?How we model?Is Enabledby1Viewpoint1..*applies to1..*1..*Isperceivedfrom111..*SoIContextLife CycleStageContribute toCompletion ofLife CycleDefines scope of1..n1..n1..*1Creates and usesDefineProcessActivitiesProcessOutcomes1..*1..*How we model?Contributeto1..*1..*1 In SE a Life Cycle defines a number of modelling purposes2 Life Cycle Stages set the purpose related to the SoI and its related context3 Life Cycle Process define the work we do to achieve the purpose.Hence the ways we use and create the model6 We need View to support the outputs of each SE Life Cycle ProcessesThese should align with the knowledge shared across the life cycle7 We need Diagrams to support all the views needed across a life cycleThese can be collected and standardised into NotationsSySML can provide a Framework notation, supported by other notations or diagrams5 Process Activities define things SE can do to contribute to an outcomeDefined by the use and creation of Model Views4 Process Outcome define what a process needs to achieve over a life cycleDefine by SoI Viewpoints, and related Views
15MBSE Ontology – Adding Methodology•While the SE process activities can be used to define a set of modelling tasks, the link is not always clear. •In this iteration of the ontology, we have added a Methodology, to link Outcomes and Activities to a Modelling Process. •This process considers one or more Viewpoints on the SoI •It uses this to identify specific Views to be used and created to contribute to an Outcome. •Finally, we can include an Ontology in the Methodology to define the concepts and terminology used.•We will take this as our top-level definition of what a Model Based (MBSE) or Model Centric (MCSE) Systems Engineering Methodology should cover. •Remembering one the main difference is that in MCSE we create models focused on a Process or specific Process Outcomes, and in MBSE we have a single coherent model covering all Process Outcomes across the life cycle.
System ModelViewNotationDiagramvisualise1..*1..*1..*1..*11..nis consistent with1is consistent with1..*ViewpointOntologyMethodologydefined in1..*1Creates & uses1..*ModellingProcess1..*identifies1..*1..*1..*1..*What we modelHow we define the modelHow we use the modelLife CycleStagesLife CycleProcessesProcessesActivitiesProcessesOutcomesContribute toProvide information1Why we need to model: within a life cycleLife Cycle1..*1..*1..ntailorsdefinesLife CyclePlanLife Cycle(SoI) Contextabstracts1..*1..nenacted by1..*1..*1..*enables1..*
System ModelViewNotationDiagramvisualise1..*1..*1..*1..*11..nis consistent with1is consistent with1..*ViewpointOntologyMethodologydefined in1..*1Creates & uses1..*ModellingProcess1..*identifies1..*1..*1..*1..*What we modelHow we define the modelHow we use the modelLife CycleStagesLife CycleProcessesProcessesActivitiesProcessesOutcomesContribute toProvide information1Why we need to model: within a life cycleLife Cycle1..*1..*1..ntailorsdefinesLife CyclePlanLife Cycle(SoI) Contextabstracts1..*1..nenacted by1..*1..*1..*enables1..*1 In SE a Life Cycle defines a number of modelling purposes2 Life Cycle Stages set the purpose related to the SoI and its related contextDefined in a Life Cycle plan tailored to Project scope3 Life Cycle Process define the work we do to achieve the purpose.Hence the ways we use and create the modelProcess Outcome define the information needed at each stageProcess Activities define what do to create it, through a modelling process4 An evolving System Model can be used to describe the SoI across the life cycleThis may be Model Centric models related to defined OutcomesOr a single Model Based model11 A methodology may recommend or mandate the use of one or more Notations, e.g. SySML can provide a Framework notation, supported by other notations or diagrams7 A Methodology link the Outcomes and Activities to the modelling9 Viewpoints provide a focus on a coherent set of related Views, relevant to a Process OutcomeInclude translation of knowledge between Viewpoints8 Modelling Process links Activities to the creation and use of Model Views, organised around each Viewpoint10 An Ontology defines the terminology and shared concepts relevant to a particular Methodology5 We need View to support the outputs of each SE Life Cycle ProcessesThese should align with the knowledge shared across the life cycleThrough a set of life cycle related Viewpoints6 Appropriate Diagrams can be used to document the Views
18SE MSc Life Cycle Process Ontology•Methodology “defines how we apply system models to support process outcomes and activities. Must include a Modelling Process” •Modelling Process “a set of modelling tasks, related to the use, expansion or creation of defined model views, to support process activities”•Methodology may also include:•Viewpoint definitions “a specific set of named model views, associated with one or more methodologies”•Modelling Ontology “defines the shared concepts, terminology and definitions used within a modelling methodology itself”•Notations “a specific notation, created from or closely linked to the methodology”•System Model “representation of a system, for an agreed purpose. Made up of a set of coherent Views”•Abstraction “to abstract means to focus on certain characteristics of a thing, reducing or ignoring other. Typical system abstractions include structure, behaviour, state, data, temporal, safety, security, risk, etc.”•Ontology “the shared concepts and language used by any group of people with a relationship or common task. May be cultural, social, technical organisation, professional, etc. Used in modelling to identify the different ontologies the exist among those involved in a modelling purpose.”•Model View “a single representation of some or all or a system, generally taking a defined abstraction, which forms part of a model”•Ontology View “a particular model view which describes one or more ontologies relevant to a model, to help clarify the meaning of other views”•View Coherence “the extent to which views as related and consistent with each other. Both in their content and configuration history!•Viewpoint (model) “defines a sub set of views related to a particular life cycle perspective, Closely associated with Viewpoint (life cycle). The views in a viewpoint directly support process outcomes”•Diagram “one of a number of abstract graphical or textual ways to represent model views. A diagram will generally be based on a particular abstraction, associated with a number of required views”•Notation “a set of coherent diagrams created to support aspects of system modelling. A notation may be defined in a formal specification and will include symbology (rules on graphical or textual elements used to create each diagram) and Syntax (rules on how symbols are combined and how diagrams can be connected or combined)”
19MBSE Methods•The well-known MBSE methods are•IBM Harmony for Systems Engineering•Vitech Model-Based Systems Engineering Methodology •NASA Jet Propulsion Lab State Analysis•Dori Object Process Methodology•Weilkiens Systems Modelling Process•INCOSE Object Oriented Systems Engineering Method
20Object-Oriented Systems Engineering Method•OOSEM is an attempt to integrate traditional systems engineering process models with object-oriented techniques typically used in the software engineering community. •INCOSE (2011) states that OOSEM defines notation and concepts that:1.Support capture, analysis and understanding of complex systems specifications and design2.Improve integration between systems, software, hardware, test, and other engineering disciplines3.Facilitate system, element, and component level reuse and design evolution •Like IBM’s Harmony for Systems Engineering, OOSEM mimics the traditional systems engineering VeeModel. (INCOSE 2015)
21History of Object-Oriented Systems Engineering•Object-orientedtechniques have been used for many years to successfully develop software-intensive system elements.•Systems engineers became interested in using OO tools & techniques, including modeling, to improve the analysis, requirements engineering, architecting, and design of software-intensive systems.•Initial OOSEM incorporated OO concepts and adapted UML v1.3 notation, to enhance the capture of system requirements, and architecture and design information, and facilitate communication between system, software, and other engineering disciplines.•Later, it became clear that the systems engineering community needed some kind of standardised, domain-independent capability for modeling complex systems, especially the growing number of software-intensive systems.•In 2007, OMG released the Systems Modeling Language (SysML) specification, borrowing and extending many of the OO concepts, elements, relationships, and diagrams found in UML.Pafford, M. E. (2016)
22UML and SysML Diagrams for OOSEMPafford, M. E. (2016)
23A Common Language for the Shared Systems Model •Ontology, •a science of study of language and meaning•A specific model showing the concepts, language and meaning used within a specific community or domain•Common Ontology•We do not want to/cannot define a single ontology across all applications of SE•So we need to be able to describe and share different ontologies with others•This is true within SE, with other disciplines and in technology domain and organizations.•To begin to share ontologies and to have a starting point for shared models we must•Defined using a common ‘spoken’ modelling language •And applicable to all relevant ‘domain-specific’ ontology models
24The System StructureFor a SoIFor groups of behaviourRepeat for detailedSystem ElementsBFCEBCEADSoIThe System Static BehaviourThe System Dynamic BehaviourParametricP = X + 2YG = A * BF = P – GRequirements1.1 ……………1.2 ……………1.3 ……………Block Definition DiagramInternal Block DiagramPackage DiagramParametric DiagramUse Case DiagramRequirement DiagramActivity DiagramState DiagramSequence DiagramFDEFSoIUse Case 1Use Case 2Use Case 3The SySML Modelling LanguageOntologySySML is our “Spoken Language” for MBSE
25Notional Interrelationships Between MBSE, UML, SysML and OOSEMPafford, M. E. (2016)
26OOSEM approach•OOSEM approach combines traditional systems engineering approaches with object oriented techniques and the application of the SysML. •Its development activities are consistent with typical systems engineering “V” process that can be recursively and iteratively applied at each level of the system hierarchy. •OOSEM represents a top-down model-based approach that uses SysMLto support the specification, analysis, design, and verification of systems. •The method applies a combination of modeling techniques including causal analysis, enterprise analysis, scenario analysis, black box system specification, logical decomposition, partitioning analysis, node distribution analysis, and performance analysis and trade studies to deal with a wide array of system concerns. (Friedenthal, 2007)
27Specify and Design System using OOSEM•The following activities are defined in OOSEM;•Analyse Stakeholder Needs•Define System Requirements•Define Logical Architecture•Synthesize Candidate Allocated Architectures•Optimize and Evaluate Alternatives•Manage Requirements Traceability•Validate and Verify System
28OOSEM•Lecturer Initial Observation•OOSEM was the driving force behind SySML and SySML makes more sense when used in a method like this•OO is in general a good approach to SE, but we need to be careful to extend it beyond the software intensive system application•OOSEM has a very good grounding in SE standards and practices:•It is mostly mapped to pre 2015 SE, which means it does not include a Mission Analysis process•Its approach generally fits well with product systems and is less easy to scale to a wider service perspective•It is also better suited to evolving an existing system rather than developing innovative new solutions•OOSEM can be seen as a genuinely Model Based Approach, although it can be used in a Model Centric way if needed•More on all of these initial observations later.

30References •Hoffman, Hans-Peter. 2011. Model-Based Systems Engineering with Rational Rhapsody and Rational Harmony for Systems Engineering, Release 3.1.2. Somers, NY: IBM Corporation.•Wagner, David A., Matthew B. Bennett, Robert Karban, Nicolas Rouquette, Steven Jenkins, Michel Ingham. 2012. “An Ontology for State Analysis: Formalizing the Mapping to SysML.” In 2012 IEEE Aerospace Conference, 1–16, Piscataway, NJ: IEEE•INCOSE (2015) INCOSE Handbook v4. www.INCOSE.org•Pafford, M. E. (2016) Object-Oriented Systems Engineering (OOSE), the Object Oriented Systems Engineering Method (OOSEM), and the INCOSE OOSEM Working Group (OOSEMWG) Presentation •Sanford Friedenthal, Alan Moore and Rick Steiner (2014) A Practical Guide to SysML. Third Edition. Elsevier inc.This book is mainly about SysML, but Chapter 17 applies OOSEM to a Residential Security System case study•Friedenthal, S., Izumi, L. and Meilich, A. (2007), 9.2.2 Object‐Oriented Systems Engineering Method (OOSEM) applied to Joint Force Projection (JFP), a Lockheed Martin Integrating Concept (LMIC). INCOSE International Symposium, 17: 1471-1491. doi:10.1002/j.2334-5837.2007.tb02961.x
31Current usage of MBSE Methods•It is worth noting that the original OOSEM method was the catalyst for the development of SySML.While the SySMLnotation has been widely used across SE, the associated method is still sparsely used.•This is typical of the current maturity of MBSE.Many practitioners are using SySMLto support their current ways of doing SE.Many of them use isolated single views as models to support specific SE outputs.•This can be described as Model Enable.At best these practitioners are creating small sets of coherent views and using these as the output of an SE activity.This is moving towards Model Centric.As discussed above, many of the emerging methods, in particular from the tool vendors, support this MCSE approach.•Methods like OOSEM present a first attempt at the truly MBSE approach.•This can be difficult to deploy within existing life cycle structures, which is why the method lags behind the notation and tools.In this module we will use a methodology based broadly on OOSEM, and on the early SE life cycle activities discussed in this module.•This approach could be used in a MCSE way and still add real values to SE practice and is likely to be what you will see in your current organisations.It can also be used in a fully MBSE way, and we would like you to understand this to prepare you for likely future evolutions of SE.
32What is Model Based Systems Engineering (MBSE)? •As we have discussed, models are an essential part of any Systems Thinking, and so all SE is based on models.•What is Model Based SE, and is it more than this?•“Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” (INCOSE, 2007) •“Model-based systems engineering is an approach to realizing successful systems that is driven by a model that comprises a coherent and consistent set of views that reflect multiple viewpoints of the system.” (Holt & Perry, 2014)
33MBSE Evolution – StagesDiagram originates with Prof John Holt Scarecrow Consulting Copyright © 2018This diagram is used in Don’t Panic! – The Absolute Beginner’s Guide to Model-Based Systems Engineering. Available at INCOSEUK.org33Stage 1:Document-basedStage 2:Document-centricStage 3:Model-enhancedStage 4:Model-centricStage 5:Model-based
34Model Centric vs Model Based Model Centric SE (current BEST Practice) •Based on the idea of a Modelcontaining all the info needed for a purpose; made up of a set of Viewsdescribed with Diagrams•Focus of the model is at the SE Process Outcomeslevel •The model views are Coherentand Orthogonalwithin the process area •Needs translationbetween process models•Individuals, Teams and Organisationsmust define and use shared the model (Ontology, Views, Notation) within the Process •As much use of coherent models as possible within current SE practices Model Based SE (Future SE Transformation)•Based on the idea of a Modelcontaining all the info needed for a purpose; made up of a set of Viewsdescribed with Diagrams•Focus of the model is at the overall SE Life Cyclestageoutcomes level •The model views are Coherentand Orthogonalacross the life cycle •Translationbetween processes is part of the model •Individuals, Teams and Organisationsmust use the model (Ontology, Views, Notation) created and owned by the Project •Maximumuse of a coherent model can only be achieved by TransformingSE practices
35Achieving MBSESEUsingModelsMBSESingle modelCovering all of SEUsed across a project teamBased on a defined MethodologyMCSEModels coveringSE Process OutcomesUsed within process teamsPartially shared with other teamsInformal Methodology managedBy each teamThings needs to move towards MBSE•Full Life Cycle coverage•Use of standards Notations•Formal shared methodologies•Full model sharing•Cross team model definitions•Project level methodologies•Formally educated Systems EngineersMCSE xMCSE y
36Extended MBSE Methodology (E-MBSE)•Aims of the OOSEM Methodology:•Follow an Object Oriented (OO) approach to SE, in a Model Based way (single model combining coherent and orthogonal Views)•Aligned with SE and Software Engineering best practice (circa early 2000’s)•Individual SE Projects deliver value to identified stakeholders, loosely aligned with Enterprise•SE begins with the capture of defined Stakeholder Needs around an identified SoI•Based around a coherent and shared modelling notation (SySML V1.0)•Aims of E-MBSE Methodology•Build on OOSEM and MBSE approaches described above•Align with current SE best practice (e.g. SEBoK & ISO 15288:2015)•Include Mission Analysis and changes to Stakeholder Needs •Clearer distinction between System Architecture and System Design•Align SE with a top down Enterprise need and Programmes of related SoI focused Projects•Model structured around SySML, with other modelling notations and diagrams as needed (in particular inclusion of Soft Systems Views in early life cycle)•The E in E-MBSE also stands for Education, this is a methodology designed to be used to teach SE at a Masters level. It would need other things to be suitable for industrial use.
SystemsEngineeringMBSEMethodologySystemsEngineersProjectModelSE ToolsEnterprise StakeholdersOthersDisciplinesProblemFocusedSolutionFocusedBusinessFocusedManagementDesignSpecialist(Dependability)
uc SE Enterprise ContextManageFinanceEnterpriseManagementControlProgrammes & ProjectsMBSEMethodologyFinanceWinBusinessInitiate & PlanProjectsSE EnterpriseHRManageRiskManageInformationManageSkillsManageOrganisationProjectManagementSystemsEngineeringProgrammeManagement<><><><><><><><>
39EnterpriseManagementPlan & Sustain Organisation & BusinessDesignDevelop & Integrate Products & ServicesOperationsCreate, Sustainand execute CapabilitySystems Engineering Systems Disciplines
uc SE Enterprise ContextManageFinanceEnterpriseManagementControlProgrammes & ProjectsMBSEMethodologyFinanceWinBusinessInitiate & PlanProjectsSE EnterpriseHRManageRiskManageInformationManageSkillsManageOrganisationProjectManagementSystemsEngineeringProgrammeManagement<><><><><><><><>

System EngineerIn-Serviceuc MBSE Methodology – Overall Viewpoints Define SoIConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilitySystems EngineerProgramme ArchitectUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerBusinessAnalystCustomerProblemSystem EngineerProject ArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersConductEnterpriseModellingDefineEnterpriseStrategy<><>Systems EngineerRequirements Engineer
Operate Successful EnterpriseAnalyse and Manage RequirementsRealise SolutionEnterpriseStrategyBusiness/MissionAnalysisSoIContextStakeholderRequirementsSystemRequirementsRequirementsManagementDefine System SolutionSystemRequirementsLogicalArchitectureSystemArchitectureAnalyseAlternativesDesignIntegration &VerificationDeploy CapabilityValidation &TransitionDeployment, Sustainment. Upgrade, DisposalEnterprise Context•Explores Enterprise Business/Mission Needs related to Capability Context•Propose candidate SoI contexts•Supported by Enterprise Modelling/StrategySystem of Interest Context•Analyse Requirements and Synthesis Solutions for each identified SoI … •… and related levels of SoI Elements•Used to realise Elements and Integrate SoI•Used to Deploy and Use CapabilityApply as needed for levels of SoI ElementShared** Systems Requirements are both analysed and defined as part of solution synthesis, and managed as part of requirements breakdownE-MBSE Methodology
System EngineerIn-Serviceuc MBSE Methodology – Overall Viewpoints & Process Outcomes Define SoIConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilitySystems EngineerProgramme ArchitectUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerSystems EngineerRequirements ManagementBusinessAnalystCustomerProblemSystem EngineerProject ArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersAnalyseStakeholderRequirementsAnalyseSystemRequirementsAnalyseLogicalArchitectureSynthesisPhysicalArchitectureDefineMission AnalysisConductEnterpriseModellingDefineEnterpriseStrategyDefineSoIContextAnalyseAlternativesManageRequirements<><><><><><><><><><><><><><><><><><>Systems EngineerRequirements EngineerElementDesignIntegrate/VerifyElementsTransition/ValidateSOI<>SustainModifyDispose<><><><><><><><>
BDD SE Enterprise Roles and SkillsProject SE Engineer:System ArchitectPropose, synthesis & select between solution optionsSE (Arch.) & ModellingRolesRequirements ManagementEnsure coherent & Traceable RequirementsSE (Reqs) & ManagementDependabilitySpecialistEnsure solution is Dependable*Speciality knowledgeSystemsEngineersProgramme Architect:Mission AnalysisModel Mission & Stakeholder NeedsSE (MA) & ModellingProject SE Engineer:Verification & IntegrationEnsure solution can be built and testedSE (I&V) & modellingProject SE Engineer:In ServiceEnsure solution can be installed, used and evolvedSE ( Validation) & domainDesignerDesign specific technology elementsDomain knowledgeBusiness AnalysisModel Business contextModelling skillsOther DisciplinesMarketingWork with customers to win businessCommercial & technicalHRAcquire & Develop skillsSpecialist KnowledgeFinanceManage cost and budgetsCommercial skillsProgrammeManagementInitiate & run Programmesto deliver Enterprise OutcomesManagement & SystemsProjectManagementPlan and Control Projects to deliver OutputsManagement & SystemsProblemStakeholderHas needs related to a problem contextMay be non technicalEnterprise OwnerDefine Enterprise StrategyNon technicalStakeholdersEnd UserUse/support a solutionSpecific skillsCustomerProblemSets cost/time for selected problemProject OwnerSolution StakeholderHas needs related to a solution typeMay be non technicalCustomer AcceptanceSets time/cost & rules for solution acceptanceSolution Owner<>RoleSkills/knowledgeRequirements EngineerModel SoIcontext & define requirementsSE (Reqs) & Modelling
Mission/Business AnalysisAnalyseStakeholderNeeds &RequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureIdentify System ElementsAnalyseAlternativesConcept DefinitionSystem Definition
Mission/Business AnalysisAnalyseStakeholderNeeds &RequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureIdentify System ElementsAnalyseAlternativesVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, DisposalConcept DefinitionSystem DefinitionSystem RealisationSystem Deployment
48E-MBSE Viewpoints•E-MBSE viewpoints0. MBSE Overview –overview of the whole methodology, showing the 6 views below1.Enterprise Viewpoint2.Mission Analysis Viewpoints3.Stakeholder Needs Viewpoints4.System Function Viewpoints5.Logical Architecture Viewpoints6.Physical Architecture Viewpoints•We have used examples of each view as applied to the module Emergency Medical Recovery case study. These will be created over the module and summarised at the end.
49Extended MBSE Methodology (E-MBSE)•Aims of E-MBSE Methodology•Build on OOSEM and MBSE approaches described above•Align with current SE best practice (e.g. SEBoK & ISO 15288:2015)•Model structured around SySML, with other modelling notations and diagrams as needed (in particular inclusion of Soft Systems Views in early life cycle)•The E in E-MBSE also stands for Education, this is a methodology designed to be used to teach SE at a Masters level. It would need other things to be suitable for industrial use.•Initial Reflections•We will expand on the Ontology, Viewpoints and Views of each part of this methodology in more detail over the rest of this module.•This methodology is largely early life cycle focused (as is OOSEM) with views created to be used for V&V, Support and Modification, etc. We will consider how we might expand these and other aspects of SE to be more model based in later modules. This will include greater integration of Dependability Modelling.•This way of defining SE implies a multi skilled SE community, with their own specialist skills built upon a core of shared systems thinking and modelling skills (see next slide)•This is a truly Model Based approach, but it can be used in Model Centric ways to enhance current SE practice. This will be discussed within the module and across the course.
50MBSE Ontology – Adding Enterprise Planning•The previous version of this ontology covered the use of models to support the System Definition, based on an agreed SoI Option.•This can include aspects of Mission Analysis And Stakeholder Needs, but till need some kind of initial SoI to get started.•In this expanded version we have added Enterprise Planning, to explore gaps and opportunities within the Enterprise. Support by Mission Analysis and Stakeholder Needs.•Once a Future Concept and candidate SoI have been identified, we can use this to plan the early stages of a formal SE life cycle.•Note Mission Analysis and Stakeholder Needs are included as SE Life Cycle processes. But can also be used as part of a Systems Thinking approach to the Enterprise.
System ModelViewNotationDiagramvisualise1..*1..*1..*1..*11..nis consistent with1is consistent with1..*ViewpointOntologyMethodologydefined in1..*1Creates & uses1..*ModellingProcess1..*identifies1..*1..*1..*1..*What we modelHow we use the modelLife CycleStagesLife CycleProcessesProcessesActivitiesProcessesOutcomesContribute toProvide information1Why we need to model: within a life cycleLife Cycle1..*1..*1..ntailorsdefinesLife CyclePlanLife Cycle(SoI) Contextabstracts1..*1..nenacted by1..*1..*1..*enables1..*How we define the modelCapabilityConceptMissionAnalysisEnterprise Planningbased onbased ondefinesWhy we need to model: to initiate a life cycleStakeholderNeedssupportsSupported byabstracts1..*1..*
System ModelViewNotationDiagramvisualise1..*1..*1..*1..*11..nis consistent with1is consistent with1..*ViewpointOntologyMethodologydefined in1..*1Creates & uses1..*ModellingProcess1..*identifies1..*1..*1..*1..*What we modelHow we use the modelLife CycleStagesLife CycleProcessesProcessesActivitiesProcessesOutcomesContribute toProvide information1Why we need to model: within a life cycleLife Cycle1..*1..*1..ntailorsdefinesLife CyclePlanLife Cycle(SoI) Contextabstracts1..*1..nenacted by1..*1..*1..*enables1..*How we define the modelCapabilityConceptMissionAnalysisEnterprise Planningbased onbased ondefinesWhy we need to model: to initiate a life cycleStakeholderNeedssupportsSupported byabstracts1..*1..*1 In SE a Life Cycle defines a number of modelling purposes2 Life Cycle Stages set the purpose related to the SoI and its related contextDefined in a Life Cycle plan tailored to Project scope3 Life Cycle Process define the work we do to achieve the purpose.Hence the ways we use and create the model4 An evolving System Model can be used to describe the SoI across the life cycleThis may be Model Centric models related to defined OutcomesOr a single Model Based model11 A methodology may recommend or mandate the use of one or more Notations, e.g. 7 A Methodology link the Outcomes and Activities to the modelling9 Viewpoints provide a focus on a coherent set of related Views, relevant to a Process OutcomeInclude translation of knowledge between Viewpoints8 Modelling Process links Activities to the creation and use of Model Views, organised around each Viewpoint10 An Ontology defines the terminology and shared concepts relevant to a particular Methodology5 We need View to support the outputs of each SE Life Cycle ProcessesThese should align with the knowledge shared across the life cycleThrough a set of life cycle related Viewpoints6 Appropriate Diagrams can be used to document the Views12 Models of Capability are used to identify future needs and initiate a life cycle13 Mission Analysis and Stakeholder needs SE Process support the Enterprise in identifying a Need3a Process Outcome define the information needed at each stage3b Process Activities define what do to create it, through a modelling process
Mission/Business AnalysisAnalyseStakeholderNeeds &RequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureDefine EnterpriseStrategyIdentify System ElementsAnalyseAlternativesVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, DisposalEnterprise PlanningConcept DefinitionSystem DefinitionSystem RealisationManage RequirementsEnterprise ModellingSystem DeploymentDefine SoI OptionManage RequirementsDefine SoI Concept
Mission/Business AnalysisAnalyseStakeholderNeeds &RequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureDefine EnterpriseStrategyIdentify System ElementsAnalyseAlternativesEnterprise PlanningConcept DefinitionSystem DefinitionSystem RealisationEnterprise ModellingSystem DeploymentDefine SoI ContextManage RequirementsVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, DisposalDefine SoI OptionDefine SoI Concept
Operate Successful EnterpriseAnalyse and Manage RequirementsRealise SolutionEnterpriseStrategyBusiness/MissionAnalysisSoIContextStakeholderRequirementsSystemRequirementsRequirementsManagementDefine System SolutionSystemRequirementsLogicalArchitectureSystemArchitectureAnalyseAlternativesDesignIntegration &VerificationDeploy CapabilityValidation &TransitionDeployment, Sustainment. Upgrade, DisposalEnterprise Context•Explores Enterprise Business/Mission Needs related to Capability Context•Propose candidate SoI contexts•Supported by Enterprise Modelling/StrategySystem of Interest Context•Analyse Requirements and Synthesis Solutions for each identified SoI … •… and related levels of System Elements•Used to realise system elements/SoI•Used to Deploy and Use CapabilityApply as needed for levels of System ElementShared** Systems Requirements are both analysed and defined as part of solution synthesis, and managed as part of requirements breakdownE-MBSE Methodology
56Soft and Hard Model Views•In our MBSE methodology we will consider:•A Hard model view to be any view that describes an agreed system context. This might be current capability, future concept or a SoI option.•A Soft model view is used to consider stakeholder specific perspectives on a system viewpoint, e.g. enterprise issues, stakeholder stories, etc.•The hard views will be modelled using SySML, or other useful model views. In general these views consider:•Structure Views•Static Behaviour Views•Dynamic Behaviour Views•Soft views will consider stakeholder perspectives on behaviour, wider issues and concerns, etc. relative to identified levels of hard view.•Some comment views•Traditionally soft views are used to discuss real world situations, exploring subjective perspectives and increasing understanding to change the situation. This sometimes identifies the need for a socio technical change. •Hard views are used to agreed the context of the change and then deliver it, with soft issues often used as an input to this.•We will also use soft views to explore specific stakeholder perspectives to lower levels of the SoI description. While this is discussed by some authors •it is an extension of how most problem modelling practitioners see the role of soft modelling •and an addition to how most system development uses soft models.
Initial/SelectedStructure/ContextConcept/SoI Expanded Requirements/BehaviourConcept/SoIExpanded StructureInitial/SelectedBehaviourAnalysis/OptionsSystem Function& RequirementsMA View 1Current Capability StructureMA View 2Current CapabilityBehaviourMA View 3Gaps & OpportunitiesAnalysisMA View 4Objectives/RequirementsMA View 5Future CapabilityConceptsSN View 1Future Concept Initial ContextSN View 2Future ConceptInitial BehaviourSN View 3Future ConceptScenario AnalysisSN View 4Stakeholder Needs &RequirementsSN View 5Expanded FutureConcept StructureENT View 1Enterprise BU StructureENT View 2EnterpriseMission & GoalsENT View 3Business AnalysisModelsENT View 4PortfolioPlans?ENT View 5EnterpriseRoadmap?EnterpriseStrategyCapabilityMissionAnalysisStakeholder Needs& RequirementsSF View 1SoI Option ContextSF View 2SoI OptionBehaviourSF View 3SoI Option Definition & SelectionSF View 4SoI Functions/RequirementsNot usedSA View 1Architecture ElementStructure IdentificationSA View 2Architecture ElementBehaviour IdentificationSA View 3SoI ArchitecturePartitioning Criteria SA View 4SoI ArchitectureBehaviour OverviewSA View 5SoI ArchitectureStructure & AllocationSystemArchitectureLA View 1Logical Element Initial StructureLA View 2Logical ElementInitial BehaviourLA View 3Logical ElementBreakdownLA View 4Logical ElementExpanded BehaviourLA View 5Logical ElementExpanded BehaviourLogicalArchitecture SynthesisPA View 1Physical Element Initial StructurePA View 2Physical ElementInitial BehaviourPA View 3Physical ElementSolution OptionsPA View 4Physical ElementExpanded BehaviourPA View 5Logical ElementExpanded StructurePhysicalArchitecture Synthesis

ENT-Views 3Enterprise ModelsENT-Views 1Enterprise OrganisationMA-View 1, 2 (for each Capability grouping)Enterprise Capability ContextEnterprise Strategy ViewpointCapability/Service Context ViewpointMBSE Overview 1 – Enterprise ViewpointENT-Views 2Enterprise Vision & Goals
MA-Views 2Capability Conceptual BehaviourMA-View 1 (for each Capability grouping)Capability Conceptual SolutionsMA-Views 3Enterprise Capability Gaps and OpportunitiesCapability/Service Context ViewpointCandidate SoI Concept ViewpointMBSE Overview 2 – Mission Analysis ViewpointMA View 7d Gaps and Opportunities•Service 1 out of data•New operational environment for Service 2 (Objective 1.1)•Need to improve performance of Service 3 (Objective 1.2)•New technology could be used to explore Service 4? (Objective 2)MA View 1b Ontology•Stakeholder 1 …•Stakeholder 2•Service 1 …•Service 2 …•Service 3 …•Etc.MA View 1c Additional Structure, e.g. People, Environment, DataEnterprise Strategy ViewpointENT-Views 3Enterprise ModelsMA View 8b SoI A Operation Concept•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on supportMA-View 5 (for each Capability grouping)Capability Focused Candidate SoI ConceptsMA-Views 4Capability ObjectivesMA 4 Goals & Objectives1.Best at …1.By sustaining S1 …2.By Replacing S22.Great at …1.By Improving S3 …..3.Good at …1.By Integrating with …4.Supported by ..1.Researching X …ETC.
SN-Views 5: Extended SoI Context, Concept Description, OntologySN-Views 1: SoI Context, Concept Description, OntologyFuture Concept ViewpointSN-Views 4 Stakeholder NeedsConcept Stakeholder Needs ViewpointMA -Views 5, Candidate ConceptsSN-View 2 Allocated Static & Dynamic BehaviourConcept Scenario & Behaviour ViewpointMA View 3 Gaps & Opportunities MBSE Overview 3 – Stakeholder Needs ViewpointLegacy ArchitectureViewsSN-View 3 Scenario Specific Static & Dynamic Behaviour (Stakeholder Needs Elicitation)MA View 8b SoI A Operation Concept•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on supportMA View 5b SoI A Operation ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……SN View 5c Ontology•Term X means ….•Term Y means …MA View 1b SoI A Operation ConceptRequired•Replace S1Optional•Consider S2?Concerns•Consider impact on support
SF –View 4 SoI Functions and MappingSN-Views 5 Expanded SoI ConceptExisting Architecture& legacy SF View if availableSF-View 3 Proposed Options & Selection SN-View 2 Concept BehaviourMBSE Overview 4 – System Function ViewpointSF – View 1 Selected OptionMA View 5b SoI A Operation ConceptElement 1 Changes…Element 2 Ideas…Concerns …SN View 5c Ontology•Term X means ….SF View 1b Option DescriptionsSF View 1c Option OntologiesSF 4a FunctionsSoI Element 11.1 Function x1 on v…1.2 Function x2 with w …SoI Element 22.1 Function x3 for y …2.2 Function x4 to z … Overall SoI3 Comply with Standard ASN –View 4 SoI Stakeholder NeedsFor Selected Options: SF -View 2SoI Required Behaviour & PerformanceAdditional detailed Views,SF-View 2c Detailed Ontology, e.g. Data, PeopleSF-View 2d Detailed Behaviour e.g. State, Sequence SF-View 3a SoI OptionsOption 1 (Selected)•Design new Element 1•Replace Element 2Option 2•Option A plus•Implement X in E1Option 3•Option 2 plus•Reduce Impact of YEtc.SoI Solution Option ViewpointSoI Option Behaviour ViewpointSoI Option Functions Viewpoint
ElementArchitecture Context ViewpointLA -View 1 & 2 Element* Structure & BehaviourDefine next Architecture Element of InterestMBSE Overview 5 –Logical Architecture Viewpoints SF-Views Element Structure, Behaviour & FunctionsSA Views 1a and 2a & 2bOriginating SoI (Logical) Architecture(based on SA 4 and 5 Version n)LA -Views 4 & 5 Element Logical Structure & Behaviour expansion*First level of Element is whole SoI ContextSF-View 3a SoI Option•Design new Element 1•Replace Element 2•Etc.Element Logical Architecture Breakdown ViewpointSoISystem Architecture ViewpointArch Views 3a Partitioning Criteria•Keep x together•Modularise y•Distribute zLA-View 3 Element Logical Elements, Partitioning CriteriaSA Views 5a and 4a, 4bNew SoI (Logical) ArchitectureVersion n+1
Element of Interest (EoI)Architecture Context ViewpointSA -View 1 & 2 Element Structure & BehaviourRepeat for selected Architecture ElementsMBSE Overview 6 –System Architecture ViewpointsPA-View 1, 2, 3, 4 & 5 Element Physical Structure, Options & BehaviourEoI Physical Architecture Synthesis ViewpointSoI OptionSystem Architecture ViewpointLA-Views 1, 2, 3, 4 & 5 Logical Element Breakdown Structure & Behaviour (if needed to support PA)SA –View 4, 5 SoI System Architecture Structure, Behaviour and Overview Version n+1(SoI Hardware, Software, Data, etc. allocations)SA Views 3, 4, 5Originating SoI Architecture Version nElement level SF-Views Updated MA ViewsPlanned Future Capability BaselineSA Version 1 defined by SF and LA Viewpoints
65Extended MBSE Methodology (E-MBSE)•Aims of E-MBSE Methodology•Build on OOSEM and MBSE approaches, structured around SySML, with other modelling notations and diagrams as needed (in particular inclusion of Soft Systems Views in early life cycle)•The E in E-MBSE also stands for Education, this is a methodology designed to be used to teach SE at a Masters level. It would need other things added to it to be suitable for industrial use.•Summary•This methodology is largely early life cycle focused (as is OOSEM) with views created to be used for V&V, Support and Modification, etc. •A Methodology based on Process, Viewpoints and Views of each part of Concept and System Definition.•Will be expanded for each SE Process over the course •This way of defining SE implies a multi skilled SE community, with their own specialist skills built upon a core of shared systems thinking and modelling skills (see next slide)•This is a truly Model Based approach, but it can be used in Model Centric ways to enhance current SE practice. This will be discussed within the module and across the course.
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc in Systems EngineeringSpecialising in DefenceProblem Analysis and System Definition
2MSc in Systems Engineering Specialising in DefenceProblem Analysis and System Definition – PASDRick AdcockR.D.Adcock@Cranfield.ac.ukUnit 2 – Model Based System DefinitionUnit 2.1 System Function/Requirements Aim: Further Develop the E-MBSE Methodology•System Functions – Modelling the SoI solution options identify System boundary and required Functions•Apply to the module case study•Define and review SoI System Requirements
3Intended Learning Outcomes•On successful completion of this module a student should be able to:1.Evaluate the application of Model Based Systems Engineering (MBSE) Concept Definition and Systems Definition life cycle processes to complex problems2.Create Mission Analysis models using scenario based modelling, to explore enterprise needs3.Create logical system architecture views to describe one or more whole system solution concepts4.Plan and apply Requirements Management processes to create and review Stakeholder Requirements5.Plan a through life approach, including consideration of dependable system issues and whole life cost
Systems Engineering Life Cycle and Processes (Further modified from SEBoK V2.0)Mission Analysis & Stakeholder RequirementsSystem Architecture& System DesignIntegration & VerificationSystem ImplementationTransition & ValidationUse, Support, Upgrade, DisposalActivityCONCEPTPRODUCTIONUTILISATIONRETIREMENTPRE CONCEPTSystem Requirements& Logical ArchitectureINITIALDEVELOPMENTFULLDEVELOPMENTStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewTRTRTRTRTRTRTRDetailed Technical Reviews (TR) as neededStage Reviews support Project DecisionsStage Review
5Stakeholder Needs & Requirements – Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))•Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.•Stakeholder needs and requirementshas two primary Outcomes, related to needs and requirements in a Concept life cycle stage1.Using enterprise-level life cycle concepts (see Business or Mission Analysis for details) as guidance, stakeholders are led through a structured process to elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts).2.Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.•Plus a number of through life issues Outcomes achieved across a systems engineering Life Cycle:3.Form the basis ofsystem requirementsactivities.4.Form the basis of systemvalidationand stakeholder acceptance .5.Act as a reference forintegrationandverificationactivities.6.Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.•The shared outputs of the process include relevant Mission Analysis outputs.
6Stakeholder Needs and Requirements – Activities•The SEBoKdefines 9 level SNR Process Activities Links based directly on ISO/IEC/EII 15288. A shortened summary of those activities is given below.1.Identify the stakeholders or classes of stakeholders across the life cycle.2.Elicit, capture, or consolidate the stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.3.Refine the Operational Concept (OpsCon) and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).4.Prioritize the stakeholder needs.5.Transform the prioritized and retained stakeholder needs into stakeholder requirements.6.Verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in the System Requirements article.7.Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing rationale (glossary) for the existence of the requirement.8.Identify potential risks (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see Risk Management).9.Synthesize, record, and manage the stakeholder requirements and potential associated risks.”
7System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))System Requirements respond to Concept Definition and are related to solution definition and architecture, and play a role in solution integration and acceptance. They are also used across the project to describe the SoI.System Requirements Primary Outcome (using the SEBoK definition) as:1.Define System Requirements for an identified SoI or (or SoI System Element), expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc. that will be necessary.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of systemarchitectureanddesignactivities.3.Form the basis of systemintegrationandverificationactivities.4.Act as reference forvalidationand stakeholder acceptance.5.Provide a means of communication between the various technical staff that interact throughout the project•Elicitation of stakeholder requirements starts in Concept Definition, and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.•Note, although defined as a single SR outcome above, SoI and SoI Elements requirements have different focus and inputs, in particular related to the link to Architecture. Hence, this should be seen to two closely related but different outcomes.
8The SEBoK defines 11SR Process Activitiesbased directly on ISO/IEC/EII 15288.1.Analyzing the stakeholder requirements to check completeness of expected services andoperational scenarios, conditions, operational modes, and constraints.2.Defining the system requirements and theirrationale.3.Classifying the system requirements using suggested classifications.4.Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.5.Establishing the upward traceability with the stakeholder needs and requirements.6.Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy.7.Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.8.Validating the content and relevance of each system requirement against the set of stakeholder requirements.9.Identifying potentialrisks(or threats and hazards) that could be generated by the system requirements.10.Synthesizing, recording, and managing the system requirements and potential associated risks.11.Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))
9INCOSE Guide to Writing Requirements (GTWR 2019)•Requirements and Requirements writing is one SE related topic for which there is a wealth of literature.•Because Requirements are seen as both a technical product, a management product and used as part of many commercial agreements, they are very well covered.•In 2015 INCOSE publish a Guide to Writing Requirements. While this is not the only source on this subject, it reflects a consensus SE on the subject, consistent with outputs like the INCOSE Vision 2035.•We will use the 2019 and 2022 versions of this document extensively across this lecture.
10Why do we need text-based Requirements?•The INCOSE Guide (page 8) includes a discussion of this question. It identifies a number of model centric ways to capture needs and requirements, such as use cases diagrams. The case made in the guide is that:•All model views are useful to elicit or describe the information associated with requirements.•But only single, well formatted statements of Requirements have the full rigour needed to fulfil all the purpose we use them for.•It states the following benefits (expanded in the guide):•Communication, many of the people who use requirements cannot (or at least will not) use models instead, text is still the only universal language. Even the best models need textual descriptions•Power of expression, the models tend to focus on needs or functions but are not so powerful for non function requirements or physical constraints, etc.•Accessibility, you cannot expect stakeholder, managers, etc. to be able to read diagrams•Attributes, being able to add explicit values to expand or clarify each statement is very powerful•Formal agreements, one use of requirements is as a formal agreements to supply. How do you contract to a model views?•Verification and Validation, another primary related use is as the basis for V and V. Again, how to identify what evidence is need to prove you have implemented a system to meet the model?•Some of this feels like an argument for Requirements in some form, others for text-based ones. A quick internet search finds many voices in favour of the power of well structure, single text-based statements of requirements, with associated measure and other attributes•Some advocate for model-to-model communication and agreement, with a well integrated flexible team based approach. If the whole team is sharing a model, do we need formal requirements? Outside of this narrow case, requirements, more especially text ones, are still a valuable part of SE.
11Some important Requirements Theory•Some more terminology from the INCOSE Guide:•Entity, defines the level of abstraction and boundary to which a concept applies. An element or component within the SoI breakdown.•A Concept is an expression using words and or diagrams of how an entity (e.g. any level of a system breakdown) will help to resolve a gap or opportunity. E.g. If the entity could allow all patients to be treated as soon as possible more of them would survive•A Need is the formal transformation of a concept in to an agreed to expectation that the entity will do something or have some property to help fulfil the Concept. E.g. To do that one thing the entity should do is get to the patient as soon as possible•A Requirement is the formal transformation of a Need, or parent requirement, into an agreed to obligation to do something or have some value. E.g. The entity will be expected to reach all patients within X minutes of the incident being reported.•So Concepts express the how we want to improve the situation (or capability). Needs express our desired to do things to make that happen. Requirements express an agreement to deliver at least some part of the Needs. Once we have transformed the needs into requirements, we can further transform the requirements into more detailed requirements.•Needs can be less well structured and aspirational. Requirements must be achievable, measured, agreed and able to be demonstrated.
12INCOSE Guide 2019 – Levels of Need and Requirement•Requirements start in the Enterprise and are needed to support the SE process Outcomes.•We can separate Concepts, Needs and Requirements, and use all three to fully explore problems and solutions.•State Concepts to document decisions, starting with an initial concept related to enterprise goals•Capturing Needs to explore what is needed to fulfil the concept, without formal commitment to provide it•Transforming that to Requirement to document each problem clarification of solution design decision.•Make decisions about the next level of Concept, based on the Needs, and use this to repeat the process•In the ontology of this guide•Concepts apply at all levels. A problem concepts defines a gap to be closed, or opportunity to be explored. Solution concepts define a proposed or agreed expansion of the solution definition.•Needs apply at all levels. A problem need is one statement to full describe a concept. A system need is one statement to full define a solution.•Needs respond to higher level needs; at each level Requirements clarify an agreed and measurable Needs. •A single Need may be transform to a number of Related Requirements to define an agreement to supply a particular solution. We may have parallel sets of requirements for the same Need.•This diagram and the idea of levels of Need and Requirements related to an evolving Concept are not part of the 2022 Requirements Guide
SEBoK v2.0: INCOSE Guide to writing requirements 2019.
14INCOSE Guide to Needs and Requirements (2022)•The original INCOSE Guide to Requirements did not include a detailed Requirements Process, but focused on how to write good textual Requirements Statements.•But did include the idea of levels of Need and Requirements from Business Needs and Concepts to SoI and SoI Elements.•In 2022, this was split into two document•A Guide to Writing Requirements, keeping most of the “how to write” knowledge, but removing the layered diagram•A Guide to Needs and Requirements, adding a model centric process for Needs, but a very traditional “textual Requirements Transformation” process for System Requirements.
15•The current Needs and Requirements Guide provided by INCOSE defines its focus as shown:•Needs relate to the “Problem Context and Stakeholder•Design Input Requirements to the overall SoI level Systems Requirements•This guide encapsulates a very traditions Requirements Development and Management approach•How well integrated is this with a Model Based perspective on SE?INCOSE Guide to Needs and Requirements (2022)
16INCOSE Guide to Needs and Requirements (2022)
17•The Guide describes a model centric way to capture Needs, using model views closely related to OOSEM (although no direct link is made•Using the models and related scenarios, single statements of Need are defined•Example of Needs for the Home Brew Coffee example•Key Needs :Obtain high quality Home Brew Coffee•The stakeholders and consumers need the home coffee maker to be safe (comply with a standard).•The stakeholders and consumers need the coffee maker to operate using standard home electrical power at the region where this product will be sold.•The consumers need to be able to remotely program the coffee maker.•The consumers need the coffee maker to make other types of beverages.•Note, does not use these to define Stakeholder RequirementsINCOSE Guide to Needs and Requirements (2022)
18INCOSE Guide to Needs and Requirements (2022)•The definition of System Requirements is very much a “Requirements Transformation” process.•E.g. each textual statement of Need to transformed into one of more Statements of Requirement (SoR)•Each SoR defines a single SoI function or outputs, with associated measures of performance.•The SoR are completed and used to create one or more Requirement Specifications by considering traceabilitym interfacesm attributes and verification planning•There is no Modelling defined for this, and no discussion of where the SoI comes from!
19INCOSE Guide to Needs and Requirements (2022)
20INCOSE Guide to Needs and Requirements (2022)•The Guide includes a discussion of Verification and Validation, as it relates to requirements:•Verification is the formal testing that SoI and its elements meet the Requirements•Product Verification – did we build the SoI as designed•Design Verification – did we design the SoI to its requirements?•System Verification – did we deliver the system we intended to?•Validation is an assessment of how well our SoI satisfies the Needs and “solves the problem•Requirements Validation, are we asking for the right solution?•Design Validation, can we design that solution?•System Validation, did what we delivered solve the problem?•Note, while some Acceptance demonstrations against Needs are possible, we do not test to validate, we review, predict, assess and audit the SoI over its life. Links back to Mission Analysis and iterative problem solving
21INCOSE Guide to Needs and Requirements•The ideas in the INCOSE Guide 2022 reflect some maturing of Requirements Theory and its relationship with MBSE Methodologies. •In this guide:•A Concept defines emerging Problem/Solution•Needs are defined, related to the Concept•Requirements are then defined (not necessarily one to one) from each Need, following GtWR guidance.•The guide says Concepts can be text or defined using model views, creating a link to MBSE. •But, System Requirements are still largely defined by expansion of the textual statements of Need•The original diagram showing levels of Concept, Need and Requirements from Business to SoI and SoI Element is not included in the 2022 versions of the INCOSE Guides!•The 2022 guides include some of the newer thinking on Model Centric Needs, but do not extend this to System Requirements.
22Object Oriented SE Methodology (OOSEM)•The INCOSE OOSEM is an MBE approach which we have used to help define E-MBSE•It includes •an Analyse Stakeholder Needs Process•and a Systems Requirements Process•The definitions of OOSEM and example used below are taken from A Practical Guide to SysML, Third Edition: The Systems Modeling Language”; Friedenthal, Moore, Steiner; 2015; Ch17; MK/OMG Press
23Analyse Stakeholder Needs•Characterises the as-is system•Describes the limitations•Describes potential improvements areas•Specifies mission requirements that the to-be system must support •Requirements review
As Is Enterprise ContextMission RequirementsTo Be Context(identify SoI and overall changes)OOSEM Stakeholder Needs Analysis (Viewpoint)Measures of EffectivenessSystem Requirements AnalysisUsed to supportSRA ProcessRoot Cause AnalysisEnterprise Use Cases
As Is Enterprise ContextMission RequirementsTo Be Context(identify SoI and overall changes)OOSEM Stakeholder Needs Analysis (Viewpoint)Measures of EffectivenessSystem Requirements AnalysisUsed to supportSRA ProcessRoot Cause AnalysisEnterprise Use CasesAs Is Enterprise ContextRoot Cause Analysis
As Is Enterprise ContextMission RequirementsTo Be Context(identify SoI and overall changes)OOSEM Stakeholder Needs Analysis (Viewpoint)Measures of EffectivenessSystem Requirements AnalysisUsed to supportSRA ProcessRoot Cause AnalysisEnterprise Use CasesMission RequirementsEnterprise Use Cases
To Be Context(identify SoI and overall changes)As Is Enterprise ContextMission RequirementsOOSEM Stakeholder Needs Analysis (Viewpoint)Measures of EffectivenessSystem Requirements AnalysisUsed to supportSRA ProcessRoot Cause AnalysisEnterprise Use CasesTo Be Context(identify SoI and overall changes)
28OOSEM Stakeholder Needs Analysis•The OOSEM takes the following approach to defining Stakeholder Needs and Requirements•Define a specific “Problem Context” in the current (or future) Enterprise•Consider the Root Causes of a current problem situation (then iteratively)•Define the Mission Requirements and Measures of Effectiveness to reduce the problem•Model the Behaviour needed to reduce the problem (also used later in the model)•Define the “Candidate System of Interest Context” to change the current (or create a future) Enterprise•Discussion•This is a good implementation of pre 2015 SE standards, which effectively start with a problem rooted in a de facto SoI (e.g. OOSEM example starts with Home Security Enterprise)•The simple Root Cause diagram could be expanded more fully into Enterprise Models. Note, OOSEM was created before the 2015 addition of Mission Analysis to the SE Process Standards•There is a lack of explicit Stakeholder Engagement•In E-MBSE we take this starting point and•Begin with a wider Enterprise view and exploration of problems/candidate SoI•Discuss how this might be linked to a wider view of Strategic Planning•Take a wider view of SoI Mission (scenario) modelling and Stakeholder Engagement•Link this into a more formal Requirements Management process.
29Object Oriented SE Methodology (OOSEM)•The INCOSE OOSEM is an MBE approach which we have used to help define E-MBSE•It includes •an Analyse Stakeholder Needs Process•and a Systems Requirements Process•The definitions of OOSEM and example used below are taken from A Practical Guide to SysML, Third Edition: The Systems Modeling Language”; Friedenthal, Moore, Steiner; 2015; Ch17; MK/OMG Press
30Analyse System Requirements•Specifies the system requirements in terms of its input and output responses •and other black box characteristics needed to support mission requirements •Complete by modelling extended, state machine behaviour•Includes a review activity 30
MoE(From SN Analysis)State ModelsRefine the ScenariosSoI ScenariosAdd MoP and ConstraintsBlack Box ContextBlack Box RequirementsOOSEM System Requirements Analysis (Viewpoint)Enterprise Use Cases (From SN Analysis)Design ConstraintsTo be Enterprise(from SN Analysis)
MoE(From SN Analysis)State ModelsRefine the ScenariosSoI ScenariosAdd MoP and ConstraintsBlack Box ContextBlack Box RequirementsOOSEM System Requirements Analysis (Viewpoint)Enterprise Use Cases (From SN Analysis)Design ConstraintsTo be Enterprise(from SN Analysis)SoI Scenario (this is a different level of detail to the operational scenario used in SN)Enterprise Use Cases (from SN)Drawn using AD combined with Internal Block Diagram (IBD) syntax
MoE(From SN Analysis)State ModelsRefine the ScenariosSoI ScenariosAdd MoP and ConstraintsBlack Box ContextBlack Box RequirementsOOSEM System Requirements Analysis (Viewpoint)Enterprise Use Cases (From SN Analysis)Design ConstraintsTo be Enterprise(from SN Analysis)Mission RequirementsMeasures of EffectivenessUsed to supportSRA ProcessEnterprise Use CasesTo Be Context(identify SoI and overall changes defined in SN)SoI (Black Box)ContextDrawn using Internal Block Diagram (IBD) syntax
MoE(From SN Analysis)State ModelsRefine the ScenariosSoI ScenariosAdd MoP and ConstraintsBlack Box ContextBlack Box RequirementsOOSEM System Requirements Analysis (Viewpoint)Enterprise Use Cases (From SN Analysis)Design ConstraintsTo be Enterprise(from SN Analysis)SoI (Black Box)RequirementsState Modelused to complete the requirementsSoI (Black Box)Performance MeasuresSoI (Black Box)Constraints
35OOSEM System Requirements Analysis•The OOSEM takes the following approach to defining System Requirements•Define SoI Scenarios, based around the Enterprise Use Cases from the SNR step•Define a Black Box SoI context to identify interfaces•Define Black Box Requirements and Design Constraints (using MoE from SNR)•Create State Machine models to review and expand the requirements•Discussion•This is again good implementation of pre 2015 SE standards, focused on modelling the detailed behaviour of a “low level” SoI•It expands on the standard activities, which see System Requirements as “derived from each Stakeholder Requirement” to add an explicit model-centric dimension•In E-MBSE we will•Add in a more explicit consideration of SoI Options right from the start of the process•Take a broader views of detailed behaviours and constraints modelling, based on SHR level scenarios•(Create a generic process that applies to levels of system, working with the architecture process)•Link this into a more formal Requirements Management process.
36Requirements Theory (INCOSE Guide 2022)•The ideas in the INCOSE Guide 2022 reflect some maturing of Requirements Theory and its relationship with MBSE Methodologies. •In this guide:•Stakeholder Needs are defined, related to a Model of a System Concept•System Requirements are then defined (not necessarily one to one) from each Need, following GtWR guidance.•System Requirements are defined by expansion of the textual statements of Need•In OOSEM:•Stakeholder Needs and Requirements and SoI Systems Requirements are defined based on Model Views. •Can be captured textually, or as part of a model view•No rigorous Requirements review or documentation process, but could use INCOSE GtWR or similar •An we combine the best parts of these two perspectives?
37Why do we need text based Requirements?•The INCOSE Guide seems to be fighting for the value of text-based requirements, and only covers those in its guidance. It does not consider the idea of text statements alongside other views within a model. •In this module we consider a Model Based approach in which:•A large amount of the information needed to perform SE can be created and shared as model views•It is the collection of related views that make the model and provide the value•There are many Diagrams that can be used, and selecting the best Diagram for each view is part of the approach.•As part of this we have used text, either free form of in a set format, as a kind of diagram. Text is well suited to some kinds of View, and we consider it a diagram type.•Hence, in this module and more widely on the MSc we assert that:•Requirements, in some form, are a valuable model view and essential for the conduct of SE. Their uses include:•Defining Problems or Opportunity Concepts and describing Solution Options•Encouraging abstract thinking by focusing on what not how, at a given level of abstraction•Providing a basis for agreements and a baseline for collecting evidence•Communicating to a wide range of stakeholders, many of whom are none technical•Some modelling diagrams are useful to enable to identification and documentation of Requirements, Either directly or as an input to their documentation.•Diagrams on their own are currently insufficient to fulfil all of the roles that requirements play across SE. Both due to the current ability of all stakeholders to learn them, and more importantly to the value of structured text for some outcomes.•It is not an either or choice. Text requirements alongside other model views is the best way to achieve all or the outcomes related to Requirements.
System of Interest RequirementsStakeholder RequirementsElement A RequirementsElement C RequirementsConcept, Needs, ExpectationsShared Element C RequirementsLegacy Element A RequirementsRelated SoI RequirementsRelatedStakeholder RequirementsLegacy SoI RequirementsLegacyStakeholder RequirementsLegacy Concept, Needs, ExpectationsRelated Concept, Needs, ExpectationsElement B RequirementsSystem Component Y RequirementsSystem Component Z RequirementsSystem Component W RequirementsSystem Component X RequirementsSystem Component U RequirementsSystem Component V RequirementsSoI ArchitectureElement A ArchitectureElement B ArchitectureElement C ArchitectureSoI OptionContextExternal Problem (Enterprise) Gaps or OpportunitiesCapability ConceptExternal Solution Project ContextHow the SoI Project is related to other solutions and their projects(both previous projects and new projects)External Solution SelectionProject decides on the SoI Option
39System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))System Requirements respond to Concept Definition and are related to solution definition and architecture, and play a role in solution integration and acceptance. They are also used across the project to describe the SoI.System Requirements Primary Outcome (using the SEBoK definition) as:1.Define System Requirements for an identified SoI or (or SoI System Element), expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc. that will be necessary.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of systemarchitectureanddesignactivities.3.Form the basis of systemintegrationandverificationactivities.4.Act as reference forvalidationand stakeholder acceptance.5.Provide a means of communication between the various technical staff that interact throughout the project•Elicitation of stakeholder requirements starts in Concept Definition, and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.•Note, although defined as a single SR outcome above, SoI and SoI Elements requirements have different focus and inputs, in particular related to the link to Architecture. Hence, this should be seen to two closely related but different outcomes.
Concept Definition and System DefinitionSEBoK Part 3: Introduction to Lifecycle Processes/Applying Life Cycle ProcessesFigure 5. Recursion of Processes on Layers (Faisandier 2012). Permission Granted by Sinergy’Com. All other rights are reserved by the copyright owner.SoI elementor component
Mission AnalysisStakeholder Needs &RequirementsSoI SystemRequirementsLogical SoI System ArchitectureConcept DefinitionSoI OptionSystem DefinitionSoI Element SystemRequirementsLogicalElement ArchitecturePhysicalElementArchitectureSoI ElementSystem DefinitionSelect an ElementContext, Behaviour and RequirementsUpdate SoI Structure, Behaviour and Requirements with Element expansionsPropose SoI Options as high level requirements and architecture for each Capability Concept•Start with Black Box SoI•Propose SoI options and top level SoI Elements•Considering and validate the candidate SoI elements from the Concept Definition as one of the optionsRequirement Traceability & ValidationValidate ConceptUpdate MA views ofCurrent CapabilityExpand logically orphysicallyRepeat for allLevels of Element/ComponentEnterpriseManagementDesign & BuildIV&VPhysicalSoIArchitecture
Analyse and Manage RequirementsRealise SolutionSoIOptionStakeholderRequirementsSystemRequirementsRequirementsManagementDefine System SolutionSystemRequirementsLogicalArchitectureSystemArchitectureAnalyseAlternativesDesignIntegration &VerificationDeploy CapabilityValidation &TransitionDeployment, Sustainment. Upgrade, DisposalEnterprise Context•Explores Enterprise Business/Mission Needs related to Capability Context•Propose candidate SoI contexts•Supported by Enterprise Modelling/StrategySystem of Interest Context•Analyse Requirements and Synthesis Solutions for each identified SoI … •… and related levels of SoI Elements•Used to realise Elements and Integrate SoI•Used to Deploy and Use CapabilityApply as needed for levels of SoI ElementShared** Systems Requirements are both analysed and defined as part of solution synthesis, and managed as part of requirements breakdownE-MBSE MethodologyOperate Successful EnterpriseEnterpriseStrategyBusiness/MissionAnalysisFutureConcept
43Incose Guide 2019 vs E-MBSE (and OOSEM)•One point of difference:•The INCOSE Requirements guide uses Needs at each level, Stakeholder Needs, System Need, Element Need•In the E-MBSE Methodology we have used •Stakeholder Needs for the Problem space •And System Functions for the solution space (read System Need as System Function)•We do this because •the SE Stakeholder Needs and Requirements process, stressing that Needs are solution independent•While System Requirements process talks about Functions and Properties to fulfil the Need, with functions describing levels of solution choice.•The 2019 guide uses Concepts at each level: Business concepts, Stakeholder Concepts, System Concepts •We use Problem Concepts, as a propose or conceptual way to provide value•And Solution Options, a suggested may to implement that value•We think this language better aligns with the SE process language, but we fully agreed with the underlying principles that the INCOSE Guide proposes.•In the E-MBSE methodology (based on OOSEM)•We use System Option (not System Concept) : for an agreed level of solution choice•We use System Functions (System Need) : for an agreed statement of solution action to implement that choice
System EngineerIn-Serviceuc MBSE Methodology – Overall Viewpoints & Process Outcomes DefineConceptEnterpriseOwnerRealise SoISolutionDeploy & UseCapabilitySystems EngineerProgramme ArchitectUnderstand Enterprise NeedsDefine SoI SolutionMBSE MethodologyProblemStakeholderEnd User/MaintainerSystems EngineerRequirements ManagementBusinessAnalystCustomerProblemSystem EngineerProject ArchitectCustomerAcceptanceSystem EngineerIntegration & verificationDependabilitySpecialistDesignerSolutionStakeholdersAnalyseStakeholderRequirementsAnalyseSystemRequirementsAnalyseLogicalArchitectureSynthesisPhysicalArchitectureDefineMission AnalysisConductEnterpriseModellingDefineEnterpriseStrategyDefineSoIOptionAnalyseAlternativesManageRequirements<><><><><><><><><><><><><><><><><><>Systems EngineerRequirements EngineerElementDesignIntegrate/VerifyElementsTransition/ValidateSOI<>SustainModifyDispose<><><><><><><><>
BDD SE Enterprise Roles and SkillsProject SE Engineer:System ArchitectPropose, synthesis & select between solution optionsSE (Arch.) & ModellingRolesRequirements ManagementEnsure coherent & Traceable RequirementsSE (Reqs) & ManagementDependabilitySpecialistEnsure solution is Dependable*Speciality knowledgeSystemsEngineersProgramme Architect:Mission AnalysisModel Mission & Stakeholder NeedsSE (MA) & ModellingProject SE Engineer:Verification & IntegrationEnsure solution can be built and testedSE (I&V) & modellingProject SE Engineer:In ServiceEnsure solution can be installed, used and evolvedSE ( Validation) & domainDesignerDesign specific technology elementsDomain knowledgeBusiness AnalysisModel Business contextModelling skillsOther DisciplinesMarketingWork with customers to win businessCommercial & technicalHRAcquire & Develop skillsSpecialist KnowledgeFinanceManage cost and budgetsCommercial skillsProgrammeManagementInitiate & run Programmesto deliver Enterprise OutcomesManagement & SystemsProjectManagementPlan and Control Projects to deliver OutputsManagement & SystemsProblemStakeholderHas needs related to a problem contextMay be non technicalEnterprise OwnerDefine Enterprise StrategyNon technicalStakeholdersEnd UserUse/support a solutionSpecific skillsCustomerProblemSets cost/time for selected problemProject OwnerSolution StakeholderHas needs related to a solution typeMay be non technicalCustomer AcceptanceSets time/cost & rules for solution acceptanceSolution Owner<>RoleSkills/knowledgeRequirements EngineerModel SoIcontext & define requirementsSE (Reqs) & Modelling
Mission/Business AnalysisAnalyseStakeholderNeeds &RequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureDefine EnterpriseStrategyIdentify System ElementsAnalyseAlternativesEnterprise PlanningConcept DefinitionSystem DefinitionSystem RealisationEnterprise ModellingSystem DeploymentDefine SoI ContextManage RequirementsVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, DisposalDefine SoI OptionDefine Concept
Mission/Business AnalysisAnalyseStakeholder& NeedsRequirementsAnalyse SystemsRequirementsAnalyse LogicalArchitectureSynthesis PhysicalArchitectureDefine EnterpriseStrategyIdentify System ElementsAnalyseAlternativesEnterprise PlanningConcept DefinitionSystem DefinitionSystem RealisationEnterprise ModellingSystem DeploymentDefine ConceptVerification & IntegrationValidation & TransitionSystemDesignDeployment, Sustainment. Upgrade, DisposalManage RequirementsSoI SystemsRequirements*Define SoI Option
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc in Systems EngineeringSpecialising in DefenceProblem Analysis and System Definition
2MSc in Systems Engineering Specialising in DefenceUnit 1 Early Life Cycle and MBSEUnit 1.1 Early Life Cycle DiscussionAim: Define and discuss Early Life Cycle SE•Review early life cycle foundations, based on Pre Reading Part 1Problem Analysis and System Definition – PASDRick AdcockR.D.Adcock@Cranfield.ac.uk
3Intended Learning Outcomes•On successful completion of this module a student should be able to:1.Evaluate the application of Model Based Systems Engineering (MBSE) Concept Definition and Systems Definition life cycle processes to complex problems2.Create Mission Analysis models using scenario based modelling, to explore enterprise needs3.Create logical system architecture views to describe one or more whole system solution concepts4.Plan and apply Requirements Management processes to create and review Stakeholder Requirements5.Plan a through life approach, including consideration of dependable system issues and whole life cost
4Mission Analysis & Stakeholder RequirementsSystem Architecture& System DesignIntegration & VerificationSystem ImplementationTransition & ValidationUse, Support, Upgrade, DisposalActivityCONCEPTPRODUCTIONUTILISATIONRETIREMENTSystem Requirements & Logical ArchitectureDEVELOPMENTThough Life Management & ReviewSystems Engineering Life Cycle and Processes (modified from SEBoK to reflect new ISO 15288)PRE-CONCEPTExplore relatedConcepts, identify “Candidate SoI Concept”Using a System Thinking & Systems ModelsEM ModuleProblem Analysis & System Definition (PASD)System Design & Realisation (SDR)
5Pre Reading Discussion•Part 3: “Systems Engineering and Management”.•Generic Life Cycle Model•Applying Life Cycle Processes.•Life Cycle Processes in the Enterprise.•Introduction to Life Cycle Processes.•You should also be familiar with the two top level Concept Definition articles below•Concept Definition. •Business or Mission Analysis.•Stakeholder Needs and Requirements.•The new SEBoK reading is in the System Definition section. We will return to these detailed articles over the rest of the module:•System Definition.•System Requirements.•System Architecture.•Logical Architecture Model Development.•Between them these articles describe how levels of Requirement and Architecture are applied to a hierarchy of system levels related to a particular System of Interest. This is the main focus of SE in the early life cycle.•The INCOSE Handbook also has chapters on these topics, these cover some similar definitions but include wider discussions and are worth a read. All of these articles are based on SE fundamental ideas from the ISO/IEEE 15288 SE Life Cycle Processes Standard
6
7These diagrams provide the fundamental concepts that will shape how we apply SE within a life cycleBut, they come from different authors who have used their own language and perspectivesWe will Critically Evaluate them and use this to build an ontology for early SE to be used across the MSc
System and Life CycleSEBoK Part 3: Introduction to Lifecycle ProcessesFigure 1. Generic Systems Engineering Paradigm. (SEBoK Original)
9System and Life Cycle•System and Kinds of System•In the ISSE module we discussed Systems Thinking and the fundamental idea that “a System is a collection of related parts, those part can also be Systems”•In SE literature people often label Systems with an extra name, e.g. System of Interest or System Elements. These ARE ALL Systems in the ST sense, with the extra label being used to apply this fundamental idea to engineering.•In this first diagram the following distinctions are made:•An Engineered System of interest (SoI) has a Life Cycle. We can take this as the definition of SoI “a (Soci Technical or Engineered) System which is the focus of a Life Cycle”•In this diagram an SoI is made of other SoI and then of System Elements. The different SoI Life Cycles may need to share information of outputs.•While this concept is true, it is not the only way for life cycles to be linked. Also, this diagram uses different terms to a similar diagram shown later. To clarify this, we need to look at the other diagrams.
How to define a System of Interest (SoI)SEBoK Part 3: Introduction to Lifecycle Processes/Applying Life Cycle ProcessesFigure 4. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012). Permission Granted by Sinergy’Com. All other rights are reserved by the copyright owner.
11How to define a System of Interest (SoI) – SEBoK definition•In this second diagram SoI is defined slightly differently:•The SoI is broken down into Systems.•In the article it says a System is a major part of the SoI which needs to be further broken down, e.g. A Flight Control System.•Systems may contain other Systems, or System Elements•A System Element is a part of a System (or the SoI) that does not need to be further expanded, by the SE processes, •e.g. Pilot Interface needs to be designed, but not Systems Engineered any further•In this diagram, the SoI does not include any lower level SoI. In the first it did?Note, we could call these Sub-Systems, but the modern standards stay away from this wording
Commercial Aircraft(SoI)Flight ControlSystemCateringSystemPilot InterfaceSystem ElementControl SoftwareSystem ElementControl ActuatorsSystem ElementControl FlapsSystem ElementFood StorageSystem ElementFood OrderingSystemFood DeliverySystemPaymentSystem ElementPlanningSystem ElementAircraft StorageSystem ElementAircraft LoadingSystem ElementTransportSystem ElementSimple example, using the SEBoK part 3 terminology
13How to define a System of Interest (SoI) – SEBoK definition•How do the two diagram compare? In the second •A SoI defines the Life Cycle deliverable, •the Systems in the top-level breakdown will set the scope of SE work •but DO NOT HAVE THEIR OWN LIFE CYCLE. •This is the definition of SoI used elsewhere, and the one we start from in the MSc•But, there are some things we will change from the SEBoK diagram:•Using the word System in the breakdown is confusing, we will use SoI Elements and System Components•SoI Elements may be new for this project, •Or may be reused or modified from previous projects•Generally, an SoI Element is not considered an SoI, but rather a major element in the SoI life cycle work breakdown. Labelling any of these types of Systems as A System just leads to confusion when we try to apply basic ST“SoI Element” is more fully “SoI System Elements”, but we often drop the implied System
System of Interest (SoI)SoI Element(existing)SoI Element(new)System ComponentSystem ComponentSystem ComponentSystem ComponentSystem ComponentSoI ElementSoI Element (shared SoI)System ComponentSystem ComponentSystem ComponentSystem ComponentSystem ComponentSoI which is the primary deliverable of a ProjectNew SoI System Element to be further System Engineered within an SoI ProjectSystem Component with a design life cycle or from previous SoI life cycleShared SoI System Element which is also the SoI in a related projectExisting SoI System Element to be reused, or modified, from previous Project(Could also be shared with other SoI)This breakdown is indicative only.SoI can break into as many levels of Element and Component as needed
15How to define a System of Interest (SoI) – SEBoK definition•Foundational ontology used on the MSc:•SoI Element is not generally considered an SoI, but rather a major element in the SoI life cycle work breakdown. •It may be allocated to a developer and be subject to a supply contract as part of the SoI Life Cycle deliverable.•But we do allow an SoI Element to have its own delivery life cycle in some cases, see next slide•When is a SoI Element also an SoI?•If we decide to develop one of the elements of an SoI as a shared solution (or Service) that is part of the solution for more than one SoI. Then that generic solution is both an SoI in its own Project, and an Element of the other SoI Projects•E.g. we fund a project to create a generic Food Delivery SoI, to be used by Catering Elements of Aircraft, Passenger Ships, Trains, etc.•This Food Delivery Service has its own customers and funding, but is also part of the Aircraft solution•Flight Control is more complex than Food Delivery, and has a project team, requirements, design, testing, etc. But it only exists within the Aircraft Project, and so is not an SoI Note, in example above Propulsion is an existing (off the shelf) element, broken-down into the Engine and an Engine Interface. This allows easier integration into the new aircraft.
Commercial Aircraft(SoI)Flight ControlNew ElementCateringElementPilot InterfaceComponentControl SoftwareComponentControl ActuatorsComponentControl FlapsComponentFood StorageComponentFood OrderingElementGeneric Transport Food DeliveryShared SoIPaymentComponentPlanningComponentAircraft StorageComponentAircraft LoadingComponentTransportComponentPropulsionExisting ElementEngine InterfaceComponentEngineComponent
17SoI, Requirements and Architecture•This third SEBoK diagram is based on the SoI breakdown in the second. We will use that terminology to explain the diagram•This diagram says:•A SoI and its related top-level Requirements are identified in response to Stakeholder Requirements, which are based on Concepts and Needs•The first level of SoI Architecture defines the top level SoI Systems and expands their requirements.•The detailed SoI Architecture continues this expansion, until all Systems are expanded into Elements and associated Requirements.•This means Architecture and Requirements are closely link. But a top-level set of System Requirements comes first.This is a very good set of concepts, ignoring the terminology used.But, assumes the Elements are all newly defined for this SoI, which may not be trueAlso, where does the SoI breakdown come from?
SoI, Requirements and ArchitectureSEBoK Part 3: System DefinitionFigure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012). Permission granted by Sinergy’Com. All other rights are reserved by the copyright owner.
19SoI, Requirements and Architecture – Part 1•We will use these ideas, but further clarify them, using the terms SoI, SoI Element and System Component.•This diagram adds the following ideas:•Stakeholder Needs relate to a Future Capability Concept “the need or desire to change how Capability is provided or add new Capability”. •This is itself the outcome of Gaps or Opportunities defined by an Enterprise•SoI System Requirements relate to an SoI Option “the proposed boundary and scope of a high-level solution, which can deliver some of the Future Concept”•In general, a Programme/Project will identify several Options and work with the Stakeholders to select the one(s) to take forwardBased on the SEBoK ideas, but using clearer ST related language Using SoI Element and System Component.
20SoI, Requirements and Architecture – Part 2•A SoI Architecture may contain:•Elements (or Components) created by a previous project, which are also part of the new solution•New Elements defined and created specifically for this SoI Option, or modified from existing Elements•New Elements defined, created and integrated into the SoI, which are being developed as a shared SoI used across several solution Options•An SoI project needs to share System Definition (Requirements, Architectures, plans, risks, etc.) with any related Programmes/Projects.•It also needs access to the System Definition from previous Projects if possible. •Or needs to create its own versions or these legacy definitions, to integrate related Elements.•In an Iterative or Agile life cycle, the System Definition from previous iterations is a key cross programme resource.Based on the SEBoK ideas, but using clearer ST related languageThis can be related to the idea of related SoI life cycles in the first SEBoK diagram
System of Interest RequirementsStakeholder RequirementsElement A RequirementsElement C RequirementsConcept, Needs, ExpectationsShared Element C RequirementsLegacy Element A RequirementsRelated SoI RequirementsRelatedStakeholder RequirementsLegacy SoI RequirementsLegacyStakeholder RequirementsLegacy Concept, Needs, ExpectationsRelated Concept, Needs, ExpectationsElement B RequirementsSystem Component Y RequirementsSystem Component Z RequirementsSystem Component W RequirementsSystem Component X RequirementsSystem Component U RequirementsSystem Component V RequirementsSoI ArchitectureElement A ArchitectureElement B ArchitectureElement C ArchitectureSoI OptionContextExternal Problem (Enterprise) Gaps or OpportunitiesCapability ConceptExternal Solution Project ContextHow the SoI Project is related to other solutions and their projects(both previous projects and new projects)External Solution SelectionProject decides on the SoI Option
22SEBoK Part 3: INCOSE Guide to writing requirements 2014.
23Service SystemsProduct & EnablingSystemsAcquire & Sustainto meet current and futureservice needsAre audited againstCapabilityGoalsEquipmentSupportInfrastructureInformationPeopleTrainingOrganisationOperationModified from Capability Engineering – an Analysis of Perspectives (Henshaw et al, 2001)EnterpriseGoalsTheEnterpriseTheOrganisationPoliticalEconomicSocialTechnologicalLegalEnvironmentalServicesCapabilityOrchestratesHasContributes toIs made up ofIs realised throughAre composed fromIncludeProvideDeliversCreateBuild/OwnAre measured byAre defined byAffectEnvironmentProvide value in anCreate effect in
24Discussion•Using a simple example, related to an every day Capability:•Give an example of a Future Capability Concept•Give two examples of SoI Solution Options•Give examples of some of the SoI Elements that one of your Options might break down into?•Can you think of one example of an SoI Element being taken from an existing SoI and e used?•Can you think of a case in which one of these Elements might also be treated as an SoI in its own project?
25SoI, Requirements and Architecture•This Fourth SEBoK diagram is based on the previous ones. We will use our preferred terminology to explain the diagram.•This diagram says:•Concept Definition includes Mission Analysis (MA) and Stakeholder Needs and Requirements (SNR). •System Definition includes System Requirements (SR), Logical (LA) and Physical (PA) Architecture•How is this applied•Concept Definition comes first and is related to early SoI exploration. SNR and SR are applied Iteratively to a define and select between SoI Options•System Definition is applied Recursively to fully define the SoI Architecture (to Component Level), •This means Architecture and Requirements are closely link at each level of expansion, including repeated consideration of Stakeholder Requirements. •Overall SoI System Requirements come first and respond to Stakeholder Needs; •Detailed SoI Element System Requirements are derived from the architecture expansion, but traced back to SR and SNR at higher levels•This process applies until we reach a Component level and transition to Design, Build and Integration. We have made one small change to this, to align with the preferred MSC terminology of Element and Component
Concept Definition and System DefinitionSEBoK Part 3: Introduction to Lifecycle Processes/Applying Life Cycle ProcessesFigure 5. Recursion of Processes on Layers (Faisandier 2012). Permission Granted by Sinergy’Com. All other rights are reserved by the copyright owner.SoI elementor component
27SE MSc Life Cycle Process Ontology 1•“a System is a collection of related parts, those part can also be Systems” Note, this is the basic Systems Thinking definition, all of the system types below are versions of this.•Future Capability Concept “the need or desire to change how Capability is provided, or add new Capability”. This is itself the outcome of Gaps or Opportunities defined by an Enterprise•SoI Solution Option “the proposed boundary and scope of a high level solution, which can deliver some of the Future Concept”•System of interest (SoI) “a (Soci Technical or Engineered) System which is the focus of a Life Cycle”•SoI Elements “expansion of a SoI. defines a logical element which requires further de composition. Major focus of the SoI life cycle”•System Components “expansion of SoI or SoI element. Defines part an of the SoI which needs no further breakdown within SE processes. Can be input to a design activity, or re use of existing component from another solution”•SoI Context “defines the boundary and external relationships of a SoI. Includes the SoI, SoI elements (if needed), related external systems and a shared environment”.•Life Cycle “a representation of the full life of an engineered System of Interest”•Life Cycle Stage “a sub division of a life cycle. Defines a purpose within the larger life cycle.•Life Cycle Process “one of the set of SE outcomes and activities used to complete a life cycle. Takes a particular Viewpoint on the life cycle”•Viewpoint (life cycle) “ a perspective on an SE life cycle, associated with a general problem exploration, solution and realisation, deployment and sustainment approach”•Process Outcome “a specific goal to be achieved across one or more Life Cycle Stages”•Process Activity “a set of detailed technical or managerial tasks preconformed from the viewpoint of a process, to contribute to the outcomes over the life cycle”
28SE MSc Life Cycle Process Ontology 2•System Model “representation of a system, for an agreed purpose. Made up of a set of coherent Views”•Abstraction “to abstract means to focus on certain characteristics of a thing, reducing or ignoring other. Typical system abstractions include structure, behaviour, state, data, temporal, safety, security, risk, etc.”•Ontology “the shared concepts and language used by any group of people with a relationship or common task. May be cultural, social, technical organisation, professional, etc. Used in modelling to identify the different ontologies the exist among those involved in a modelling purpose.”•Model View “a single representation of some or all or a system, generally taking a defined abstraction, which forms part of a model”•Ontology View “a particular model view which describes one or more ontologies relevant to a model, to help clarify the meaning of other views”•View Coherence “the extent to which views as related and consistent with each other. Both in their content and configuration history!•Viewpoint (model) “defines a sub set of views related to a particular life cycle perspective, Closely associated with Viewpoint (life cycle). The views in a viewpoint directly support process outcomes”•Diagram “one of a number of abstract graphical or textual ways to represent model views. A diagram will generally be based on a particular abstraction, associated with a number of required views”•Notation “a set of coherent diagrams created to support aspects of system modelling. A notation may be defined in a formal specification and will include symbology (rules on graphical or textual elements used to create each diagram) and Syntax (rules on how symbols are combined and how diagrams can be connected or combined)”•
29Case Study Part 0 – Discussion•One of the challenges of describing a recursive process is where to start!•The Mission Analysis and Stakeholder Needs processes consider a new Gap or Opportunity, but does so based on analysis of existing solutions.•So, we need some understanding of Requirements and Architecture to explain MA and SNR.•We have created a simplified set of view from the PREVIOUS AMBULANCE PROJECT, to illustrate the early life cycle MBSE modelling.•In the taught module we will explore a NEW MOBILE MEDICAL PROJECT to describe the application of MBSE in more detail•To try and make this clear, we will use a grey background for views from the previous project and a white background for the views created in the new project•In this example we do not use the formal MBSE labels, although you can see how some of the views shown could be included in the MBSE Viewpoints•The following discussion is based on this example, covered in detail in the Pre Reading MBSE Case Study Part 0.CONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTAmbulance Update ProjectCONCEPTPRODUCTIONUTILISATIONRETIREMENTDEVELOPMENTMobile Medical Treatment ProjectExample Part 0Starts hereExample Part 1Starts hereExample Part 0Ambulance Upgrade ViewsExample Part 1-3Mobile Treatment Views
Systems Engineering Life Cycle and Processes (Further modified from SEBoK V2.0)Mission Analysis & Stakeholder RequirementsSystem Architecture& System DesignIntegration & VerificationSystem ImplementationTransition & ValidationUse, Support, Upgrade, DisposalActivityCONCEPTPRODUCTIONUTILISATIONRETIREMENTPRE CONCEPTSystem Requirements& Logical ArchitectureINITIALDEVELOPMENTFULLDEVELOPMENTStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewStage ReviewTRTRTRTRTRTRTRDetailed Technical Reviews (TR) as neededStage Reviews support Project DecisionsStage Review
31Mission/Business Analysis – Process Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288)•Mission/Business Analysis begins an iteration of the life cycle of a potential (Engineered) SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise.•Mission Analysis primary Outcomes1.Takes the (enterprise) capability gap and defines problem/opportunity (future concepts) in a manner that provides a common understanding (between stakeholders, acquirers and potential suppliers)a)define the problem space, b)identify the stakeholders, c)develop preliminary operational concepts, d)distinguish environmental conditions and constraints that bound the solution space. •Mission Analysis may be used to support Enterprise Management, modelling current capability ad exploring future concepts.•If this leads to one or more new projects, the outcomes of Mission Analysis directly support the through life outcomes of Stakeholder Needs
Current CapabilityFor each Capability ConceptCapability Gaps & Opportunities
Service 3SH1Current Capability ContextSH2Capability 1Service 1Service 2Current Capability Dynamic BehaviourService 1SH 2Service 2SH 1•Vision•World Class Enterprise to …•In Environment …•Competing with …•Goals1.Best at …2.Great at …3.Good at …4.Supported by …Enterprise StrategyEnterprise Models (Business Unit 1) Goals & Objectives1.Best at …1.By sustaining S1 …2.By Replacing S22.Great at …1.By Improving S3 …..3.Good at …1.By Integrating with …4.Supported by ..1.Researching X …ETC.Goals and ObjectivesSH 1SH2Sys 1Capability 1Use Case 1Use Case 2Use Case 3Current Capability Static BehaviourThese Views support the current Capability Concept of Operations (ConOps)Business Unit 2Business Unit 3Business Unit 4Business Unit 1Capability 1Capability 2Capability 3Current Organisation
Detailed Capability Needs modelling Need?Technology RoadmapsGaps and Opportunities•Service 1 out of dat3•New operational environment for Service 2 (Objective 1.1)•Need to improve performance of Service 3 (Objective 1.2)•New technology could be used to explore Service 4? (Objective 2)•ETC.SH1Future Capability Operational ConceptsSH2Cap 1Service 1Service 2SoI AService 3SoI BSoI BSoI CFuture Operation Concepts•Replace Element of Service 1•Change interface to Service 2•Consider Technology X?•Consider impact on support•ETC.
35Stakeholder Needs & Requirements – Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))•Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.•Stakeholder needs and requirementshas two primary Outcomes, related to needs and requirements in a Concept life cycle stage1.Using enterprise-level life cycle concepts (see Business or Mission Analysis for details) as guidance, stakeholders are led through a structured process to elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts).2.Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.•Plus a number of through life issues Outcomes achieved across a systems engineering Life Cycle:3.Form the basis ofsystem requirementsactivities.4.Form the basis of systemvalidationand stakeholder acceptance .5.Act as a reference forintegrationandverificationactivities.6.Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.•The shared outputs of the process include relevant Mission Analysis outputs.
MA Future Concept(& Candidate SoI)Operational ScenarioStakeholder NeedsA&E Stakeholder Needs:1.Increased probability of Patient survival in full range of Incidents2.Advanced Information Patient to plan treatment earlier in all incidents3.Better chance of patient surviving recovery in all incidents4.Consider starting treatment in Ambulance?Ambulance Stakeholder Needs:1.Any changes MUST NOT reduce current Vehicle efficiency2.Changes work with and where possible extend current Recovery3.Understand impact of changes on Support and TrainingOther Stakeholder Considerations1.Fit within Hospital rules and budgets2.Understand impact on Patient experience3.Understand Impact on Incident Control Stakeholder NeedsWe may create at least two Scenario Viewpoints:•One or more modelling groups of scenarios•A second with combine selected scenario Views to create needsShould also bring in soft issues or technology opportunities if they have been considered
Stakeholder Needs – Scenario ModellingStakeholder NeedsNeeds mapped back to SoI IssuesAssociated with SoI ConceptSys 3SH1Future Capability ConceptSH2Cap 1Sys 1Sys 2 Potential SoISys 3SH1Expanded Concept & SoISH2Cap 1SoI ElementSys 1Sys 2SoI ElementSH 1Sys 3SH 2SoIAdditional Behaviours & IssuesAdditional Dynamic BehaviourStakeholder Activities/StoriesNeed?Activity 1Activity 2Activity 3Select ScenariosConcept (for identified scenarios)•Create Element 1•Modify Element 2•Consider X•Impact of Y•Etc.S3Ser 2Use Case 1.1Use Case 1.2Use Case 1.3SoI IssuesS1S2Use Case 1.2>SoI Issues
Model Current Capability as related servicesModel Candidate SoIModel a single ConceptModel SH Needs & Concept SoIModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsCurrent Capability Baseline•Previous Concepts and Needs•Previous SoI Options and ArchitectureInputs•Enterprise Goals and Organisation•Enterprise Soft Problem Models, Technology Road Map•Possible areas of concern or regular capability Audit goals•Current Capability Operational ConceptsStage Outputs•Validated* Models of current Capability•Related Future Concepts•Initial Boundary of Concept, candidate SoI•How Concepts fits into bigger plan, including technology policies and roadmaps that might influence solution optionsCapability Audit(Stakeholder Needs?)Architecture of in service systems*Note, we need to baseline and validate current capability views to start from.If the Enterprise has these views as part of its MBSE library, this is easyIf not we may need to created themPreConcept Stage Review
Model Current Capability as related servicesModel Candidate SoIModel a single ConceptModel SH Needs & Concept SoIModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsCurrent Capability Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•(Future Capability Model, Soft Problem Models, Technology Road Map)•Validated* Models of current Capability•Initial Boundary of Concept, candidate SoI•How Concepts fits into bigger planStage Outputs•Scenario based concept modelling and Needs•Agreed Scenario baseline*•Expanded Concept & Stakeholder RequirementsRequirements Engineering& ManagementCapability AuditStakeholder NeedsArchitecture of in service systems*Note, we need to baseline the agreed scenarios that define the problem scope for the next project stage.We might have more than one new project looking at the conceptScenarios and Needs also used in Validation and Verification.Concept Technical ReviewPreConcept Stage Review
Detailed Concept, Stakeholder NeedsAgree ConceptDocument NeedsStill earlyBegin to firm up where the SoI will fit into current solutionsPropose ConceptConsider Needs(Options Roadmap)
41System Requirements Through Life Outcomes(SEBoK Part 3 – based on ISO/IEEE 15288))System Requirements respond to Concept Definition and are related to solution definition and architecture, and play a role in solution integration and acceptance. They are also used across the project to describe the SoI.System Requirements Primary Outcome (using the SEBoK definition) as:1.Define System Requirements for an identified SoI or (or SoI System Element), expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc. that will be necessary.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of systemarchitectureanddesignactivities.3.Form the basis of systemintegrationandverificationactivities.4.Act as reference forvalidationand stakeholder acceptance.5.Provide a means of communication between the various technical staff that interact throughout the project•Elicitation of stakeholder requirements starts in Concept Definition and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.•Note, although defined as a single SR outcome above, SoI and SoI Elements requirements have different focus and inputs, in particular related to the link to Architecture. Hence, this should be seen to two closely related but different outcomes.
SoI System Requirements ViewpointOperational Scenario ViewpointRequirements ViewpointSystem Functions ViewpointConcept – Stakeholder Needs/RequirementsA&E Stakeholder Needs:1.Increased probability of Patient survival in full range of Incidents2.Advanced Information Patient to plan treatment earlier in all incidents3.Better chance of patient surviving recovery in all incidents4.Consider starting treatment in Ambulance?Ambulance Stakeholder Needs:1.Any changes MUST NOT reduce current Vehicle efficiency2.Changes work with and where possible extend current Recovery3.Understand impact of changes on Support and TrainingOther Stakeholder Considerations1.Fit within Hospital rules and budgets2.Understand impact on Patient experience3.Understand Impact on Incident Control MA&T SoI Option – Systems Functions/RequirementsMobile Assessment:1.Establish assessment interface with patient2.Gather Assessment data from patient3.Perform Patient Assessment4.Share Patient Assessment Stabilise Patient:1.Review patient Assessment2.Stabilise Patient for Recovery1.Create Stabilise Plan?2.Perform Stabilise Actions?3.Identify Urgent Needs to Ambulance?Patient Handover:1.Create Handover Report2.Identify Patient details (e.g. Name, gender)3.Create Initial Assessment Report4.Handover PatientOther Functions or Constraints, e.g. integrate with Ambulance Infrastructure, etc.
System FunctionsFunctions mapped to SoI relevant Stakeholder NeedsSoI Option Static BehaviourRS3SoIUse Case 1Use Case 3Use Case 4RS1RS2Use Case 2>>SH 1Ser 3SH 2SoIDynamic BehaviourFunctionsSoI Element 11.1 Function x1 on v…1.2 Function x2 with w …SoI Element 22.1 Function x3 for y …2.2 Function x4 to z … Overall SoI3 Comply with Standard ARequired SoI Concept BehaviourSelected SoI Option BehaviourSoI Concept NeedsSelected SoI Option FunctionsRS3RS2RS1SoISoI E1SoI E2DataSoI Option Dynamic BehaviourFor each Selected Option Define Behaviour and Function (based on associated Concept, Behaviour and Needs)Service 3SH1Expanded SoI ConceptSH2Capability 1SoI AElement 2Service 1Service 2SoI A Element 1RS1RS2RS3SoI Option AE1E2Selected SoI Option ContextSoI OptionsOption X•Design new Element 1•Replace Element 2SoI A Future ConceptElement 1•Replace S1•Upgrade S3Element 2•Consider S2Concerns•Impact on Support•Impact of ……S3Ser 2Use Case 1.1Use Case 1.2Use Case 1.3SoI IssuesS1S2Use Case 1.2>SoI IssuesStatic Behaviour
Legacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•(Future Capability Model, Soft Problem Models, Technology Road Map)•Validated* Models of current Capability, Initial Boundary of Concept, candidate SoI, How Concepts fits into bigger planStage Outputs•Scenario based concept modelling and Needs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements•(Integration & Verification Strategy)•(Validation & Support Issues) Initial Exploration, to support Outputs•Early feasible Options & Functions•Draft SoI System RequirementsModel Current Capability as related servicesConcept Candidate SoI Model a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction Architecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsConcept Stage ReviewRequirements Engineering& ManagementCapability AuditStakeholder NeedsConcept Technical Review
Legacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•Scenario based concept modelling and Needs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements, technology policies and roadmap•Early feasible Options & Functions, Draft SoI System Requirements •(Integration & Verification Strategy), (Validation & Support Issues) Stage Outputs•Selected Solution Option and Technology Plan•Option SoI Structure and Behaviour•SoI Functions and RequirementsModel Current Capability as related servicesModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction Architecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsInitial DevelopmentTech ReviewRequirements Engineering& ManagementCapability AuditStakeholder NeedsConcept Candidate SoI Concept Stage Review
Propose and select OptionFor the SoI Option Context, define SoI RequirementsAgreed Concept Definition(for selected Option)Defines the SoI Option Boundary, Relationships and FunctionsDefine ConceptDocument NeedsPropose OptionsModel selected OptionDefine Top Level SoI RequirementsTechnology PlanConsider top level SoI Elements
47Logical System Architecture Process Outcomes•System Architecture defines a high level system solution, in response to System Requirements and associated Stakeholder Requirements, for a specific SoI Option, System Architecture Process Primary Outcome (expanding the SEBoK definition) as:1.The (main goal) of system architecture activities is to define a comprehensive solution based on principles, concepts, and properties logically related and consistent with each other.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of In Service Support, Maintenance, Up-Grades and Disposal3.Provide a baseline of current capability for future Concept Definition and System Definition4.Provide a means of communication between the various technical staff that interact throughout the project•The creation of Logical Architecture Views supports all of these outcomes. •Logical views are a critical step in the translation from requirements to solution, and hence begin the system architecture process, to complete outcomes 1 and 2. •Logical views define an abstract, high-level model of the SoI over the life cycle and remain as an overview of the completed solution once it enters operational use, and hence are of particular value for outcomes 3 and 4. •This suggests that we should identify, document and maintain the logical views as a useful output, even after we have developed a full system architecture using them.•Logical Architecture Views can be used to support detailed Operational Concepts (OpsCon) and related life cycle concepts for Acquisition, Deployment, Support, and Retirement within Definition life cycle stages.
SoI Logical Architecture/Requirements ViewpointSoI Functions/Requirements ViewpointsLogical Architecture ViewpointElement Functions/Requirements ViewpointMA&T SoI level Systems FunctionsMobile Assessment:1.Gather Assessment data from patient2.Perform Patient AssessmentStabilise Patient:1.Review patient Assessment2.Stabilise Patient for RecoveryETC. MA&T Mobile Assessment Element FunctionsMobile Monitor:1.Connect Monitor Element to patient2.Gather patient Monitoring Data3.Create Handover ReportETC.
Model Current Capability as related servicesModel Future ConceptsModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction SoI Logical Element & CriteriaArchitecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsSystem ArchitectureModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsRequirements Engineering& ManagementCapability AuditStakeholder NeedsDesign & Integration(V&V, Support, etc.) Elements BreakdownInitial DevelopmentPhase ReviewInitial DevelopmentTech ReviewLegacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements, technology policies and roadmap•Early feasible Options & Functions, Draft SoI System Requirements •(Integration & Verification Strategy), (Validation & Support Issues) Stage Outputs•Selected Solution Option and Technology Plan•Option SoI Structure and Behaviour•SoI Functions and Requirements•Initial SoI Logical Architecture•Element level Requirements (as needed)•Planned Future Capability •(Integration & Verification Plans)•(Validation & Support Strategy)
214ElementsInterfaceApplicationEnablingLogical Arch Elementspartitioning Criteria (related to SoI Option)SoI Architecture Level 0 (based on Requirements View)RS3RS2RS1SoISoI Arch Behaviour (based on Requirements View)SoI E1SoI E2RS1RS2RS3SoIE1E2SoI Level 1 Logical Arch StructureSoI Level 1 Logical Arch Behaviour3RS3RS1SoIE1.2E2.1RE1E1.1E1E2RS2-E1RS1RS3SoIE1.2E1.1E1RE1E2.1E2RE1 = Related ElementUsed from existing systemRS2RS2-E1
Element E1.1 ContextE1.1 Logical Arch Structure ExpansionE1.1 Logical Arch Behaviour ExpansionE1.1.2E1E1.1.1RS2RS2-E1RS3E2.1E1.2EoI 1.1E2E1E1.2E2 & RS1E1.1.1RS3R2-E1E1.1.2EoI 1.1Element E1.1 Required BehaviourE1E1.2E2 & RS1E1.1RS3R2-E1RS3SoIE1.2EoI 1.1E1E2.1E2RS2RS2-E1E1.1.2E1.1.1ElementsInterfaceApplicationEnablingLogical ElementsEoI partitioning Criteria from SoI OptionEoI 1.1 System FunctionsFunctions mapped back to EoI BehaviourAssociated with SoI Functions
E1.1 Logical Arch Structure ExpansionE1.1.2E1E1.1.1RS2RS2-E1RS3E2.1E1.2EoI 1.1E2SoI Level 3 Logical Arch Structure v2RS1RS3SoIE1.2E1RE1E2.1E2RE1 = Related ElementUsed from existing systemRS2RS2-E1E1.1.1E1.1.2EoI 1.1RS1RS3SoIE1.2E1.1E1RE1E2.1E2RE1 = Related ElementUsed from existing systemRS2RS2-E1SoI Logical Arch Structure v1Sys 3SH1Planned Capability changesSH2Cap 1News ElementSys 1Sys 2Updated Element
For selected OptionComplete SoI RequirementsDefine top level SoIAgree top level SoI ElementsSelected OptionSoI/Element RequirementsLogical ArchitectureTechnology candidatesAgreed SoI Requirements and OptionDefines the SoI Option ArchitectureScope solution trades
54Physical System Architecture Process Outcomes•System Architecture defines a high level system solution, in response to System Requirements and associated Stakeholder Requirements, for a specific SoI Option, System Architecture Process Primary Outcome (expanding the SEBoK definition) as:1.The (main goal) of system architecture activities is to define a comprehensive solution based on principles, concepts, and properties logically related and consistent with each other.•Through life Outcomes achieved across a systems engineering Life Cycle:2.Form the basis of In Service Support, Maintenance, Up-Grades and Disposal3.Provide a baseline of current capability for future Concept Definition and System Definition4.Provide a means of communication between the various technical staff that interact throughout the project •The expansion of Logical Architecture Views and addition of Physical Views completes all of these outcomes. •We discussed above how Logical Architecture Views can support all these outcomes. While this is true, Logical views are of particular value for outcomes 3 and 4. •The creation of Physical Architecture Views to complete a System Architecture fully satisfy outcomes 1 and 2 above. The added levels of detail in the PA may also add value to outcomes 3 and 4.•Physical Architecture Views as part of a full System Architecture can be used to support detailed Operational Concepts (OpsCon) and related life cycle concepts for Acquisition, Deployment, Support, and Retirement within Definition life cycle stages.
SoI System Architecture ViewpointLogical Element Architecture ViewpointPhysical Element Architecture ViewpointSystem Architecture/Capability ViewpointMA&T Mobile Assessment Element FunctionsMobile Monitor:1.Connect Monitor Element to patient2.Gather patient Monitoring Data3.Create Handover ReportETC.
E1.1 Physical Arch BehaviourPhysical Arch solutionsApply and Expand partitioning criteria as needed, to generate solution alternativesE1.2E1.1RoleDataSWHWE2RS3E1.1SWHWRoleE1.1 Physical Arch Structure ExpansionRS2HWE1.2DataDataE2.1E2E1.1 Logical Arch Structure ExpansionE1.1.2E1.1.1ElementsInterfaceApplicationEnablingLogical Arch ElementsEoI partitioning Criteria from SoI OptionE1.1 Logical Arch BehaviourE1.1.2E1E1.1.1RS2RS2-E1RS3E2.1E1.2EoI 1.1E2RS3R2-E1E1E1.2E2 & RS1E1.1.1RS3R2-E1E1.1.2EoI 1.1
SoI Level 1 Logical System Architecture RS1RS3SoIE1.2SWHumanE1.1RS2HWDataSWHWDataActorElement solutions tradesApply and Expand partitioning criteria as needed, to generate solution alternativesSoI System Architecture (version n) – expand physical detailsExpanded Logical Structure & Reqs ViewsE1.1.2E1E1.1.1RS2RS2-E1RS3E2.1E1.2E1.1E2RS3E1.1SWHWRoleExpanded Physical Arch StructureRS2HWE1.2DataDataE2.1E2RS1RS3SoIE1.2E1.1E1RE1E2.1E2RE1 = Related ElementUsed from existing systemRS2RS2-E1E2E1The System Architecture evolves as we expand each element and add it into the overview
RS1RS3SoIE1.22.1RE1E1.1RS2HW.Data 2SW 1HW 1Data 1Role 1SoI System Architecture FinalData 3Role 2ProceduresBuildingSW 3SW 2ServerRole 3SW 3ServerSW 2SW 1Data 2OfficeData 3Role 2ProceduresRole 3BuildingHW 1Role 1Data 1Hardware Design PackageSoftware Design packageTeam & procedures Design PackageOfficeRole 1Maint.Maint..When all SoI elements have been fully expanded into components the Arch is completeWe can then create a number of design packages, to form the input to DesignThis is done iteratively
Model Current Capability as related servicesModel Future ConceptsModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction SoI Logical Element & CriteriaArchitecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsSystem ArchitectureModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsRequirements Engineering& ManagementCapability AuditStakeholder NeedsDesign & Integration(V&V, Support, etc.) SoI Physical Elements & TradesCombine into System ArchitectureFull DevelopmentTech ReviewLegacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements, technology policies and roadmap•Selected Solution Option and Technology Plan, Option SoI Structure and Behaviour, SoI Functions and Requirements•Initial SoI Logical Architecture•Element level Requirements (as needed)•Planned Future Capability Stage Initial Outputs•Expanded SoI Logical Architecture Views•Element level Requirements•Physical Element breakdown and technology trade options
Model Current Capability as related servicesModel Future ConceptsModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction SoI Logical Element & CriteriaArchitecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsSystem ArchitectureModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsRequirements Engineering& ManagementCapability AuditStakeholder NeedsDesign & Integration(V&V, Support, etc.) SoI Physical Elements & TradesCombine into System ArchitectureFull DevelopmentStage ReviewFull DevelopmentTech ReviewLegacy Baseline•Previous Concepts•Previous SoI Options and ArchitectureNew Inputs•Agreed Scenario baseline, Expanded Concept & Stakeholder Requirements, technology policies and roadmap•Selected Solution Option and Technology Plan, Option SoI Structure and Behaviour, SoI Functions and Requirements•Initial SoI Logical Architecture•Element level Requirements (as needed)•Planned Future Capability Stage Initial Outputs•Expanded SoI Logical Architecture Views•Element level Requirements•Physical Element breakdown and technology trade options•Physical Element breakdown•Allocated Design Packages•Baseline Future Capability•(Integration & Verification Schedule)•(Validation & Support Plans)
For selected OptionComplete SoI RequirementsDefine Element RequirementsSE level Solution DecisionComplete SoI Elements, Agreed InterfacesDefine SoI Elements and ComponentsDefine Physical Components and InterfacesInitiate detailed design and integrationComplete SoI ArchitectureBaseline for next Concept Definition
Model Current Capability as related servicesModel Future ConceptsModel a single ConceptModel SH Needs & Concept SoIOptions & Project SoISoIFunction SoI Logical Element & CriteriaArchitecture of in service systemsModelViewModel ViewUsed to ExploreModel Future Capability ConceptsSoft Problem & Technology ModelsMission AnalysisStakeholder NeedsSystem FunctionsSystem ArchitectureModelViewModel ViewBased onIf availableModelViewModel ViewBased onModelViewModel ViewUses/CreatesModel Enterprise Strategy & GoalsRequirements Engineering& ManagementCapability AuditStakeholder NeedsDesign & Integration(V&V, Support, etc.) SoI Physical Elements & TradesCombine into System ArchitectureFull DevelopmentStage ReviewFull DevelopmentTech ReviewInitial DevelopmentPhase ReviewInitial DevelopmentTech ReviewConcept Stage ReviewConcept Technical ReviewPreConcept Stage Review
Concept Definition and System DefinitionSEBoK Part 3: Introduction to Lifecycle Processes/Applying Life Cycle ProcessesFigure 5. Recursion of Processes on Layers (Faisandier 2012). Permission Granted by Sinergy’Com. All other rights are reserved by the copyright owner.SoI elementor component
www.cranfield.ac.ukT: +44 (0)1793 785810

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *