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