Download presentation
Presentation is loading. Please wait.
Published byHidde Bauwens Modified over 5 years ago
1
The Application of Systems Engineering to the UTM Problem Space
2
Agenda Background and Objectives for this Workshop
Operational Analysis Operational Use Cases System Modelling Functional Analysis
3
Bio Info – Mike Meakin Certified as a Combat Systems Engineer in the Royal Canadian Navy. Systems Engineer within the unmanned systems field for more than twenty years. Led development for the control station software for the US Army Shadow 200 and Hunter UAVs. Served on the STANAG 4586 committee, developing the NATO UAV Interoperability standard and served as Vice Chair of the NIAG SG-157 effort, defining the architecture for a multi-domain control station for all unmanned systems. Served on the Canadian Air Regulations Advisory Committee that developed the recommended regulatory requirements for operation of UAVs within Canadian airspace. Taught courses on systems engineering and its application to unmanned systems development in Singapore, Australia, Europe and Canada. Currently the Vice Chair of the INCOSE Canada national chapter for systems engineering and is employed by Kongsberg Geospatial as Technical Solutions Engineer.
4
References Systems Engineering References
IEEE 15288:2015 Systems and software engineering - System life cycle processes INCOSE Systems Engineering Book of Knowledge, v. 2.0, 1 June 2019 UTM References “Unmanned Aircraft System (UAS) Traffic Management (UTM) Concept of Operations”, v1.0, FAA document, May 2018 “UAS Traffic Management Architecture”, version 1.0, Global UTM Association, April 2017 “Unmanned Aircraft System Traffic Management (UTM) Concept of Operations”, Kopardekar et al, AIAA Aviation Proceedings, June 2016
5
Workshop Objectives What we are NOT trying to achieve…
We are not trying to specify a UTM solution We are not trying to advocate a specific modelling approach -MBSE itself is still evolving within the SE community We are not trying to advocate a specific modelling tool What we ARE trying to achieve… We are trying to introduce general SE tools and techniques as applied to the UTM problem We are trying to introduce specific MBSE techniques as applied to the UTM problem We are trying to illustrate the advantages of these tools and techniques to UTM development
6
Operational Analysis What is Systems Engineering? What is a use case?
Operational Use Cases for UTM Starting a System Model
7
What is Systems Engineering?
Systems Engineering is fundamentally the engineering discipline that deals with the management of technical complexity An SE’s technical knowledge is typically broad more than deep The “product” delivered by SE is smooth, low risk integration Standard V-model of development Iterative and recursive This workshop only concentrates on the LHS of the V-model
8
What is Operational Analysis?
9
What is Operational Analysis?
Primary sources of problems…
10
What is Operational Analysis?
Primary sources of problems…
11
What is Operational Analysis?
Primary sources of problems…
12
What is a Use Case? Term “use case” is often misapplied
It is not just for operator interactions, it is also used to capture and define system to system interactions It is not the same as a software level “user story” (though well constructed use cases can often have their individual flows pulled apart into user stories) Despite word “use”, it applies at every level of design, not just operational i.e. there are Operational use cases, System use cases, Sub-system use cases, etc.
13
What is a Use Case? (cont’d)
Properties of use cases Normal Flow- this is how the system is expected to be used 80% of the time Alternative Flows- anywhere in the Normal Flow where a decision is made or a condition assumed, there must be a flow describing what happens when that condition is not true Exception Flows- any failures under which the system is still expected to operate must have a flow that indicates how the operations are maintained and to what degree Malicious Flows- any points within the Normal Flow where there is potential for malicious action, there must be a flow that describes how the system is expected to respond Their primary value is edge case identification Engineers are typically pretty good at solving the primary operations problem; projects fail due to not identifying and understanding the edge cases which- while less common- are still critical for operational success
14
Top Level View (OV-1) To get started, it can be useful to draw a very high level context diagram that shows how the target system relates to external actors This should include what information is provided by these actors to the system and what information is expected by these actors from the system In the parlance of the DoD Architectural Framework (DODAF), this is an Operational View- 1
15
Example Use Case Template
16
Operational Use Cases for UTM
Start with list of expected use cases (typically no more than about twenty) List of expected UTM Operational Use Cases UTM Operations (Routine) UTM Flight Plan Authorization UTM Training UTM Operational Development UTM Operations (Emergency) UTM Operations (Hostile) UTM System Maintenance As more use cases develop, often need to iterate back into previously developed use cases as well
17
UTM Routine Operations- Normal Flow
18
UTM Routine Operations- Alternate Flow
19
UTM Routine Operations- Exception Flow
20
UTM Routine Operations- Malicious Flow
21
Development of Interface Exchange Requirements (IERs)
Information Exchange Requirements (IERs) can be identified and defined to a degree appropriate to the view As we proceed to lower levels of design, we can expand these IERs, adding detail for a more complete understanding of the interactions
22
Operational Use Case View
The relationships between the use cases and the external actors can be useful to understand and verify with the end user
23
Use Case to Sequence Diagrams
The use cases are structured to support easy conversion to sequence diagrams Provides a bridge between operator- readable format and engineering artefacts
24
Functional Design Description of System Modelling/ MBSE
Developing Interface Requirements Building from Use Cases to Functional Architecture
25
Moving Towards a System Architecture
26
Description of System Modelling
Key characteristics of a System Model: Entities and relationships definition of a system model Searchable Traceable Globally Modifiable Creation of views Only model as far as is useful requires engineering judgement
27
Description of System Modelling
28
Description of System Modelling
This is not the model
29
Description of System Modelling
This is the model
30
Functional View- UTM Routine Operations
31
Refinement of Interface Exchange Requirements (IERs)
At the next stage down, we can start to flesh out what the higher level IERs really convey These items are also specifically conveyed to the relevant functional elements, not just the over-all system Information Items may be conveyed to multiple functional items Different information elements may be required by different functional elements
32
Relationships Between Information Items
Relationships can be defined between Information Items as well In this manner, an Interface Definition Document and/ or an Interface Control Document can be explicitly developed through the design process Most tools support the generation of more traditional documentation directly from the model
33
Functional View- UTM Operational Training
34
Functional View- UTM Operations & Training
Each view isolates a limited amount of complexity But views can then be combined to incrementally build up the complexity of the over-all system With each incremental build, we can review the model for: Consistency Completeness Coherence
35
Functional View- UTM Operational Development
36
Functional View- UTM Operations, Training & Development
Each use case solution integrates with and builds upon the previous set of solutions Complexity is slowly built up in a manner that maintains comprehensibility and supports deconstruction, as needed, but also reveals the combinatory complexity of the system as a whole in a manner suitable for end to end review
37
Functional View- UTM Flight Plan Authorization
38
Functional View- UTM System
39
UTM System- Our Starting Point…
40
Summary & Conclusions Started with high level operational view to ID external stakeholders to system Developed Operational Use Cases to identify and capture major interactions with the system Defined top level IERs to bound information exchanges with external actors Used use cases to draft a functional architecture for each of the operational use cases Refined the information exchanges between functional elements Combined the functional architectures to define an over- all system functional architecture of the system
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.