OKL4 HYPERVISOR SOFTWARE DEVELOPMENT KIT PLUGIN By

OKL4 Hypervisor Software Development Kit Plugin

Item Type text; Electronic Thesis

Authors Wolfe, Ryan Joseph

Publisher The University of Arizona.

Rights Copyright © is held by the author. Digital access to this material is made possible by the University Libraries, University of Arizona. Further transmission, reproduction or presentation (such as public display or performance) of protected items is prohibited except with permission of the author.

Download date 25/09/2021 15:58:26

Item License http://rightsstatements.org/vocab/InC/1.0/

Link to Item http://hdl.handle.net/10150/632646

OKL4 HYPERVISOR SOFTWARE DEVELOPMENT KIT PLUGIN

RYAN JOSEPH WOLFE

______

A Thesis Submitted to The Honors College

In Partial Fulfillment of the Bachelors degree With Honors in

Electrical and Computer Engineering

THE UNIVERSITY OF ARIZONA

M A Y 2 0 1 9

Approved by:

______

Professor Gary Redford UA ENGR 498 Coordinator

ABSTRACT

The General Dynamics Open Kernel Labs (OKL4) Hypervisor group had the problem of designing a program that will enable users of the OKL4 hypervisor to easily create a hypervisor system. The current method of creating a system was tedious, requiring extensive knowledge of the OKL4 software development kit (SDK) and hard coding Extensible Markup Language (XML) files. To solve this problem, an Eclipse plugin was designed and developed that consolidates, automates, and error-proofs the process of creating an OKL4 hypervisor system. Primarily coded in Java, the developed plugin met all the requirements laid out by General Dynamics. A set of living documents: Technical Data Package (TDP), System Requirements Document (SRD), Software Design Document (SDD), and Acceptance Test Procedure (ATP), were all created to track the functionality and results of the plugin. On top of these documents, the plugin was upkept and version controlled within a GitLab repository, which also contains a comprehensive wiki on how to run and further develop the Eclipse plugin.

ROLES & RESPONSIBILITIES

Daniel Flores – Contributed to documentation.

Xianjun Li – No notable contribution.

Victor Reyes – Contributed to documentation and software development namely XML parsing and writing.

Ryan Wolfe – Team Lead, responsible for assigning tasks to other group members, contributing to and reviewing documentation, communicating with sponsor, and a large portion of software design and development including creating the initial Eclipse wizard, plugin functionalities, and project management.

Kinsleigh Wong – Contributed to documentation, internal organization and communication, and software development namely dynamic VM configuration for the wizard. Table of Contents:

1.0 Scope 1

2.0 System Block Diagram 1

3.0 Technical Data Package 2

4.0 Acceptance Test Procedure 2

5.0 Models / Analysis 2

6.0 Acceptance Test Results 3

7.0 Final Budget 5

8.0 Lessons Learned 5

Appendix 7

A1.0 Introduction 10 A2.0 System Description 10 A3.0 System Architecture and Requirements Traceability 12 A3.1 System Architecture 12 A3.2 File Parser subsystem 12 A3.3 Error Checker subsystem 13 A3.4 Project Management subsystem 13 A3.5 Graphical User Interface subsystem 13 A3.6 System Requirements Decomposition 13 A4.0 Drawings 14 A5.0 Schematics 15 A6.0 System Requirement Document 16 A7.0 Software Design Document 25 A7.1.0 Scope 27 A7.2.0 Referenced Documents 27 A7.3.0 CSCI-wide design decisions 27 A7.4.0 CSCI architectural design 29 A7.5.0 CSCI detailed design 31 A7.6.0 Requirement traceability 37 A7.7.0 Notes 38 A8.0 ATP 39 A5.0 Demonstration Verification 45 A9.0 Models 47

i 1.0 Scope This project meets General Dynamic’s need for a more end-user friendly interface to the Open Kernel Labs 4(OKL4) hypervisor. The proposed design is an Eclipse plug-in that allows the user to configure an OKL4 hypervisor system via a Graphical User Interface (GUI) and produce a bootable image. Major features for the plug-in include the ability to pick and choose configuration options based on a set of valid configurations, requiring real-time error detection. Furthermore, the plug-in provides a project management workspace for OKL4 hypervisor users, allowing them to create new projects, customize previous projects, and import and export. The design developed to meet General Dynamic’s requirements allows for a portable and scalable product. The following sections of the final report will detail the design choices and modules made to complete this project. The ATP will document how the test requirements will be verified.

2.0 System Block Diagram

The system is an Eclipse plug-in within Eclipse. The interfaces are between the user, the plug-in, and Eclipse. The user starts by opening up the plugin using Eclipse. The GUI submodule takes in user input such as where the OKL4 SDK directory is located. With this information, the File Parser submodule parses the boards directory and xml schema. Then the GUI populates its list of

1 available user-defined options. As the user enters in their options, the Error Checking submodule does real-time error checking to make sure the user enters valid data. When the user completes customizing their hypervisor system, the XML writer produces a System xml file and the OK Weaver program is run. From these the user receives a bootable image file and the System xml file which can be manually edited.

3.0 Technical Data Package The Technical Data Package(TDP) is a document that describes the design choices made in this project and how these choices verify the requirements. It contains a Top-Level Assembly Drawing, the System Requirements Document(SRD), a Software Description Document(SDD), and the Acceptance Test Procedure(ATP). The ATP will be summarised in the next section. The TDP itself can be found in the appendix.

4.0 Acceptance Test Procedure The Acceptance Test Procedure(ATP) documents the equipment and procedures needed to verify the project’s test system requirements. See the appendix for the complete document.

5.0 Models / Analysis The following is a summary of the models done for the project. The complete models can be found in the appendix.

OKL4 Hypervisor Model Summary Name Ref Tool Inputs Outputs Error Checking 4.1.3 Microsoft Word ● User entered ● Error Model Drawing #100,410 configurations message EDM 2.0 ● .rng files FPM 1.0

User Interaction 4.1.2 Microsoft Word ● Configuration ● Bootable file Model Drawing #100,420 options ● system xml FPM 2.0 file

File parser model Drawing #100,430 Microsoft Word ● Board .xml files ● Configuration FPM 1.0 ● Example .xml files options ● xml schema

2 Project Drawing #100,440 Microsoft Word ● User selection ● Create new Management model 4.1.1 ● File system project PMU 1.0 ● Open existing PMU 2.0 project ● Save project ● Create project from example xml

6.0 Acceptance Test Results Test requirement 4.4.1 Configuration Retrieval Speed has been tested and passed. The limit is less than 2 seconds and the measured value was 0.248 seconds.

Test requirement 4.4.1 was tested by running the Timer.java class to measure the time it took for the selected Machine xml file (imx6ul.xml) to be parsed. It then shows the results on the console.

The respective data sheet is shown below: OKL4 Hypervisor SDK Acceptance Test Data Sheet

Referenced ATP Paragraph Number: 2.1 - System shall supply user with configuration options in under two seconds.

Analysis Referenced: N/A Name of Test: OKL4 error notification speed tests Results (Pass/Fail): Pass Date of Test: 2/10/19

Recording of Test Measurement: Requirement: T = 0.248 seconds < 2 seconds

Computations: None needed

Signatures:

Tester _____Victor Reyes______

Customer ______Angel Diaz______

3 Test requirement 4.4.2 Error Notification Speed has been tested and passed. The limit is less than 2 seconds and the measured value was .018 seconds.

Test requirement 4.4.2 was tested by running the Timer.java class to measure the time it took to detect erroneous configuration attempts, with the largest time being recorded. It then shows the results on the console.

The respective data sheet is shown below: OKL4 Hypervisor SDK Error Notification Speed Test Data Sheet

Referenced ATP Paragraph Number: 2.2 - System design portion shall be interactive and notify users of errors in under two seconds.

Analysis Referenced: N/A Name of Test: OKL4 error notification speed tests Results (Pass/Fail): Pass Date of Test: 5/5/19

Recording of Test Measurement: Requirement: T = .018 seconds < 2 seconds

Computations: None needed

Signatures:

Tester _____Kinsleigh Wong______

Customer ______Angel Diaz______

7.0 Final Budget Category Item Sourcing Cost

Output Files Freescale Mouser $850 MCIMX6UL-EVKB Single Board Computer (5)

Output Files 8 GB SD Card (3) Amazon $16

Team UA Polos (10) University of Arizona $200 Pictures

Design Day Design Day Presentation FedEx $50 Materials (Poster)

Total Cost $1216

Total Budget $4000

Margin $2884 (72.1%)

8.0 Lessons Learned The major lessons learned throughout the senior design process would be the importance of communication, the importance of making and keeping to a detailed schedule, as well as the importance of producing detailed documentation. Communication was a major issue the first half of the semester, due to the app chosen for communication and our unfamiliarity with each other. The app GroupMe was the initial communication method chosen, which proved to be a subpar decision. Since the project primarily focuses on developing software, most of our time will be spent in front of a computer. Unfortunately, the online desktop version of GroupMe is very clunky and unorganized, and as such, the GroupMe was rarely used. By making communication difficult, people naturally shy

5 away from it, which drops productivity dramatically since nobody feels inclined to put in work if they think nobody else is working. This manifested itself in how we treated the project the first semester, with the latter half of the semester ending with flames for presentations like Critical Design Review, so the decision was made to switch to Slack. Slack allows us to communicate in different channels, allowing for significantly better organization. Private communication between two people is allowed as well. Slack was an app built and used by software developers, and the second half of the semester significant progress was made on the project due to this change in communication. For example, whenever code was in development and a significant push was made to the GitLab repository, Slack provided an easy way to both share certain blocks of code along as discussing what changes were made. Our sponsor also became significantly easier to contact as well, since Slack was what they used at their workplace. Also, as we got more comfortable with each other, we started communicating better and understanding the capabilities of the team member, and allocated our resources to fit these constraints. A well made schedule, which came in the form of a monthly milestone list for our team, helps keep everybody accountable regarding the project, since the schedule outlines what should be in progress and when they should have finished certain components. Coupled with good git practices, it allows team members to work independently on their own tasks, knowing that they will come together and integrate their work with the other team members near the end of a deadline. The monthly milestone list provided straightforward deliverables that partitioned the project into manageable monthly goals, and success of the project was contingent on meeting these goals. The biggest mistakes that the team made throughout the project timeline would have to be with documentation. The team constantly put documentation on the back burner over working on the project, causing the documentation to be subpar. This course helped teach us that trackable documentation is indeed important in the workplace and should not be overlooked. Ultimately, documentation in the form of a GitLab wiki would have to be delivered to General Dynamics anyway, so putting in more effort into the documentation not only helps our grade, but lessens the workload needed for the final stretch of the semester since the documentation created in class can be cannibalized for the GitLab wiki.

6 Appendix

IDL Drawing number Name

100,000 Top-Level Assembly Drawing

100,100 SRD

100,200 SDD

100,300 ATP

100,400 System Models

100,410 Error Checking

100,420 User Interaction

100,430 File Parser

100,440 Project Management

OKL4 Hypervisor Software Development Kit Project 18052 TDP Report

Prepared by: Daniel Flores, Xiangjun Li, Victor Reyes, Ryan Wolfe, Kinsleigh Wong

Prepared for: General Dynamics Mission Systems

8 Table of Contents:

1.0 Introduction 8

2.0 System Description 8

3.0 System Architecture and Requirements Traceability 10 3.1 System Architecture 10 3.2 File Parser subsystem 10 3.3 Error Checker subsystem 10 3.4 Project Management subsystem 11 3.5 Graphical User Interface subsystem 11 3.6 System Requirements Decomposition 11

4.0 Drawings 12

5.0 Schematics 12

6.0 System Requirement Document 14

7.0 Software Design Document 23 7.1.0 Scope 25 7.2.0 Referenced Documents 25 7.3.0 CSCI-wide design decisions 25 7.4.0 CSCI architectural design 27 7.5.0 CSCI detailed design 29 7.6.0 Requirement traceability 35 7.7.0 Notes 36

8.0 ATP 37 5.0 Demonstration Verification 43

9.0 Models 45

9 1.0 Introduction This report addresses General Dynamic’s need for a more intuitive way to use the Open Kernel Labs 4 (OKL4) hypervisor. Currently, users of the OKL4 hypervisor must manually edit large xml files and use a command line to receive their boot image. This is intimidating to those unfamiliar with advanced computer knowledge, so our team of engineers have proposed a solution to facilitate this process in the form of an OKL4 Hypervisor Software Development Kit (SDK). Our design will produce an installable Eclipse package (version Photon) that will include the OKL4 SDK Plugin, allowing users of the OKL4 Hypervisor to design their system via the Graphical User Interface (GUI) and have the ability to produce a bootable image. This will prevent the user from having to become too familiar with the system xml files that currently define a valid hypervisor system.

The next couple sections detail our system design at the system and subsystem levels. In section 2.0, the system block diagram shown depicts the subassemblies at the highest level. In section 3.0, the lower-level components of the subassemblies are shown. The system requirements are decomposed from system level to subassembly level, either by allocating or dividing between multiple subassemblies, deriving from an analysis, or as a direct flow down from the specific system requirement. Test documentation, analysis, and models are provided to demonstrate that this design has the ability to meet these system requirements.

The rest of the sections make up the technical data package (TDP), which contains the overall system design and test instructions. To show how the design will be built, software design documents are shown in this section. Instructions are provided as acceptance test procedures for system requirement verification of the design. Appropriate data sheets are provided when pertinent.

2.0 System Description The package is a user interface software module that brings together various files, directories, and tool-chains to present the user with options when creating an OKL4 system. Of importance is the fact that since not all customers receive the same SDK version and that the parameters are defined by the inputs of which each user may or may not have, the number of parameters presented will be dynamic and ostensibly unknown. During initial set-up, the Eclipse plugin will require the user to direct it to the locations with the following directories/programs: boards, xml schema, examples, OK executable (Weaver), compiled Linux kernels, root file systems, Linux device trees, and Linux tool chains for cross compiling. These directories, files, and programs will provide the options that the user may use to create a functioning OKL4 system. Once the user has configured their system, the package will complete the creation of the system along with a boot image and a valid system xml file.

The package is composed of 4 sub-systems: the file parser, the GUI, the error checker, and the output file compiler. The package is designed to be run on Ubuntu 16.04 as well Eclipse Proton. The user is responsible for obtaining all of the required directories and programs listed above. When selecting the various configuration options, there will be real time error checking to make sure that the system is functionable. If there is an error the user will be notified of it by an error message. The package will keep track of physical memory when defining memory for each VM. It will look at the physical memory of the selected board to determine if there is an error or not. It will also keep track and warn the user of overlapping physical pools.

3.0 System Architecture and Requirements Traceability

3.1 System Architecture

3.2 File Parser subsystem The file parser subsystem is composed of the system xml file, a boards xml file, an examples directory, OK executable (Weaver), compiled Linux kernels, root file systems, Linux device trees, and Linux tool chains. The system xml is what defines the system at the file level and where the user configurations will be stored in. The board xml will contain the specific parameters for the board that is selected. The examples directory will contain pre-defined system xml files that can be used for convenience. Linux kernels, device trees, root file systems and tool chains are used to provide the user with options.

12 3.3 Error Checker subsystem The error checker subsystem provides real time error checking of physical memory limits and physical overlapping. It consists of a configuration option file.

3.4 Project Management subsystem The project management subsystem provides an interface for the user to save their current project, as well as load from a previously created user project or an example project. It consists of a drop-down file menu including all relevant actions.

3.5 Graphical User Interface subsystem This subsystem brings together the data retrieved by the fire parser and presents it to the user so that they may configure their OKL4 system. The GUI will let the user know of errors that the Error Checker has encountered in their selected options. The GUI will call the OK Weaver when the user has finished their configuration.

3.6 System Requirements Decomposition System Requirements allocated to the package can be flowed further or allocated to its subassemblies. All requirements will be verified at the system level, but the further flow down shows which subassemblies are responsible for fulfilling each requirement.The table below shows the flowdown of requirements to sub assembly level.

Subassembly V Error Detection Project Management System Requirements M File Parser VM Module VM Unit VM 1.0 Direct 4.1.1 File System T flow T 1.0 Direct flow T 4.1.2 Graphical User Interface (GUI) D 2.0 Direct flow D 2.0 Allocated, 1.0 Allocated, 4.1.3 Error Detection D 800 ms D 1000 ms D 4.2.1 Operating System I 3.0 Direct flow I 4.2.2 Development Environment I 4.0 Direct flow I 4.2.3 Programming 3.0 Direct Language I flow I 2.0 Direct flow I 5.0 Direct flow I

13 3.0 Direct 4.3.1 Java I flow I 2.0 Direct flow I 5.0 Direct flow I 4.3.2 Development Environment I 4.0 Direct flow I 2.0 Allocated, 1.0 Allocated, 4.3.3 Error Checking D 800 ms D 1000 ms D 3.0 4.4.1 Configuration Allocated, 6.0 Allocated, 900 Retrieval Speed T 900 ms T ms T 4.0 4.4.2 Error Notification Allocated, 3.0 Allocated, 400 7.0 Allocated, 300 Speed T 200 ms T ms T ms T 4.4.3 Output file boots on test board D 8.0 Direct flow D 4.4.4 Executable D 9.0 Direct flow D

4.0 Drawings IDL Drawing number Name

100,000 Top-Level Assembly Drawing

100,100 SRD

100,200 SDD

100,300 ATP

100,400 System Models

100,410 Error Checking

100,420 User Interaction

100,430 File Parser

100,440 Project Management

5.0 Schematics 5.1 Top level system assembly

6.0 System Requirement Document

OKL4 Hypervisor Software Development Kit Project 18052 System Requirements Document

Prepared by: Daniel Flores, Xiangjun Li, Victor Reyes, Ryan Wolfe, Kinsleigh Wong

Prepared for: General Dynamics Mission Systems

Revision History

16 Revision Description Date

Rev- Initial Release 10/1/2018

Rev-A Updated verification methods 10/11/2018

Rev-B Updated requirements 4.4.3 and 1/29/19 5.5.3 to reflect final dev boards

ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 1 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

Table of Contents:

1.0 Introduction and Scope: 1

2.0 Applicable and Other Referenced Documents: 1

3.0 Definitions, Acronyms, and Abbreviations: 1

4.0 Requirements: 1-2

5.0 Verification Requirements: 3

6.0 System Requirement Verification Matrix: 4

18 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 2 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

1.0 Introduction and Scope

This document contains the system requirements for an Eclipse plugin that improves the usability of the existing General Dynamics Open Kernel Labs 4 (OKL4) Hypervisor by providing a graphical user interface (GUI) application for system configuration. This plugin will reduce the time required for customers to get the hypervisor up and running by streamlining the boot image production process as well as an Extensible Markup Language (XML) file that enables further customization if need be.

2.0 Applicable and Other Referenced Documents No external documents referenced.

3.0 Definitions, Acronyms, and Abbreviations OKL4 - Open Kernel Labs 4 GUI - Graphical User Interface SDK - Software Development Kit XML - Extensible Markup Language IDE - Integrated Development Environment RAM - Random Access Memory

19 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 3 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

4.0 Requirements System Block Diagram:

20 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 4 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

4.1 Interface Requirements 4.1.1 File System: System shall access the Open Kernel Labs 4 (OKL4) Software Development Kit (SDK). 4.1.2 Graphical User Interface (GUI): The system shall allow for a user to create an OKL4 project and enter desired configurations. 4.1.3 Error Detection: The system shall detect errors with user entered configurations.

4.2 Environmental Requirements 4.2.1 Operating System: System shall operate in Ubuntu version 16.04. 4.2.2 Development Environment: System shall be developed, tested, and ran on Eclipse Integrated Development Environment (IDE). 4.2.3 Programming Language: System shall be developed using Java programming language.

4.3 Customer Constraints 4.3.1 Java: The system shall be written in Java programming language. 4.3.2 Development Environment: System shall be developed using Eclipse IDE 4.3.3 Error Checking: System shall report configuration conflicts during configuration process in under two seconds.

4.4 Performance Requirements 4.4.1 Configuration Retrieval Speed: System shall supply user with configuration options in under two seconds. 4.4.2 Error Notification Speed: System design portion shall be interactive and notify users of errors in under two seconds. 4.4.3 Output file boots on test board: System shall output valid XML file and system image binary which boots on the IMX6 Development board. 4.4.4 Executable: Building project shall output a valid XML system file and a binary executable image.

21 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 5 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

5.0 Verification Requirements 5.1 Interface Requirements 5.1.1 File System: Access to the OKL4 file system shall be verified via test by attempting to access files and printing out their contents. 5.1.2 Graphical User Interface (GUI): The GUI shall be verified by inspection, interacting with the GUI to show that all desired functionality is present. 5.1.3 Error Detection: The system error detection interface shall be verified by demonstration, showing the memory bounds and attempting to provision past those bounds.

5.2 Environmental Requirements 5.2.1 Operating System: The working operating system shall be verified through inspection, checking the OS-release document for a Linux operating system. 5.2.2 Development Environment: The development environment shall be verified by inspection, checking that an Eclipse project for the plugin exists. 5.2.3 Programming Language: The programming language shall be verified by inspection, checking relevant files for the Java extension name.

5.3 Customer Constraints 5.3.1 Java: The programming language shall be verified by inspection, checking relevant files for the Java extension name. 5.3.2 Development Environment: The development environment shall be verified by inspection, checking that an Eclipse project for the plugin exist. 5.3.3 Error Checking: The system error correction shall be verified by demonstration, showing the memory bounds and attempting to provision past those bounds.

5.4 Performance Requirements 5.4.1 Configuration Retrieval Speed: The system’s configuration retrieval speed shall be verified via test by using unit testing with Java timer methods.

22 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 6 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

5.4.2 Error Notification Speed: The system’s error detection and resulting notification speed shall be verified by test using Java timer methods. 5.4.3 Output file boots on test board: The output files’ ability to be booted on a test board shall be verified by demonstration through successful launch of the bootloader on the IMX6 Development board. 5.4.4 Executable: The outputted executable files shall be verified by demonstration, with an executable being output after configuration.

23 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 System Requirements Document General Dynamics 7 of 7 Drawing Rev B 29JAN2019 OKL4 SDK 100,100 plugin

6.0 System Requirement Verification Matrix Verification

Verification Method System Requirement Verification Matrix T A D I 4.1 Interface Requirements - - - - 4.1.1 File System Interface: X 4.1.2 GUI Interface: X 4.1.3 Error Detection: X 4.2 Environmental Requirements - - - - 4.2.1 Operating System is Linux: X 4.2.2 Development Environment Eclipse: X 4.2.3 Programming Language Java: X

4.3 Customer Constraints - - - - 4.3.1 Programming Language Java: X 4.3.2 Development Environment Eclipse: X 4.3.3 Error-Checking X 4.4. Performance Requirements - - - - 4.4.1 Configuration Retrieval Speed: X 4.4.2 Error Notification Speed: X 4.4.3 Output File Boots on Test Board: X 4.4.4 Executable X

24 7.0 Software Design Document

OKL4 Hypervisor Software Development Kit Project 18052 Software Design Document

Prepared by: Daniel Flores, Xiangjun Li, Victor Reyes, Ryan Wolfe, Kinsleigh Wong

Prepared for: General Dynamics Mission Systems

Revision History

Revision Description Date

Rev-A Initial Release 01/15/2019

ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 1 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.1.0 Scope 7.1.1 The OKL4 SDK plugin SDD gives the design of the software CSCI for the project. It describes the software modules required to create a bootable image from xml schema. The modules are the XML parser, the Graphical User Interface (GUI), Error checker, and Output file compiler CSC’s.

7.2.0 Referenced Documents Not applicable.

7.3.0 CSCI-wide design decisions 7.3.0.1 The CSCI shall be built to work and be tested on an NXP / Freescale MCIMX6UL-EVK8 development board. This board was chosen for ease of development, cost considerations, and known compatibility with the OKL4 hypervisor SDK. 7.3.0.2 The CSCI shall accept as inputs the following files, directories, and programs: boards, xml schema, examples, OK executable (Weaver), compiled Linux kernels, root file systems, Linux device trees, and Linux tool chains for cross compiling. The main interface will be between the user and the CSCI, through the GUI. 7.3.0.3 The outputs shall be a valid system XML file that will be run through the OKL4 Weaver and a boot image file. 7.3.0.4 The CSCI will be run in the Photon version of Eclipse and will be packaged with the Eclipse plugin. The system will be using the SWT graphical library to provide the resources and functions for the user-interface. For maintainability, the CSCI will be documented with a wiki detailing software usage and specific implementation details. 7.3.0.5 The CSCI will monitor both physical and virtual memory pools for overlap errors and notify the user in real time. 7.3.0.6 Using the File Menu, the user will be able to either create a new project or open an existing one. Example system, parsed from the examples directory, shall be shown, so that the user may select one as a template for a new project.

ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 2 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.3.0.7 When creating a new project, an initial setup wizard will be displayed that will ask the use to point the package towards the locations of the input directories, files, and programs. The user shall be able to select the locations on their hard disk by clicking a browse button and using the native file manager. 7.3.0.8 There should not be any security or privacy concerns, as internet access is not necessary for the operation of the plugin. 7.3.0.9 Output data files will appear in XML format while input data files will be in there respective file formats.

28 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 3 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.4.0 CSCI architectural design 7.4.1 Table 1 shows the modules used in the CSCI, and their relationships with each other and outside systems. Libraries will be used when it is deemed necessary or convenient.

Table 1: OKL4 Hypervisor CSC properties

CSC Relationship Purpose Planned Libraries Resource

Error Checks user input to GUI for Prevent user 50kb none Checking errors. Outputs errors to GUI, to configuration errors. notify user. Passes error-free XML to File Output compiler.

File Inputs examples directory and Parse files in order to 50kb JAXB Parser XML schema. Outputs parsed display options to user. XML data to GUI.

GUI Input is parsed XML data from Display configuration 100kb Eclipse File parser. Output is options. PDE, SWT configuration options to the user. Passes customized configurations to Output file compiler.

Output Input is configuration options Output XML file for 50kb none file from GUI. Output is an XML file Weaver. compiler that is ready to edit or produce a bootable image.

29 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 4 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.4.2 Concept of Execution 7.4.2.1 The CSC relies heavily on the GUI and its ability to bring together inputs from the user and the file system while also displaying error messages. The general flow of data is as follows: The user will first create a new project from the File Menu and then direct the program to the required inputs (OKL4 SDK, examples, boards, etc). Then the File Parser will parse all XML files line-by-line and store the data into runtime Java objects. The GUI will rely on these Java objects to determine the available configurations to show the user as they depend entirely on the board chosen in the start up wizard. The user will make changes to the system XML by the GUI and the error checker will check for overlap errors in virtual and physical memory pools. Once a valid system xml is configured the Output File Compiler will call the Weaver program and produce a boot image. The system XML will also be made available as a separate file.

30 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 5 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.4.3 Interface Design 7.4.3.1 Figure 1 shows the interaction between the CSCs and their interfaces for the CSCI

Figure 1: Interaction between CSCs

7.5.0 CSCI detailed design Module design decisions such as algorithms, language, procedural commands, and logic are given for the CSC’s below.

7.5.1 File Parser CSC - The File Parser CSC is based on the JAXB library which is a part of Java 6. The CSC will allow provide the interface between the GUI and the file system (XML schema, examples directory). JAXB utilizes object serialization in the Java programming language to provide the basis for file system parsing. Specifically JAXB

31 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 6 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

provides functions for reading data files from the file system and writing to data files. These functions are defined below in Table 2:

Table 2: File Parse CSC functions

Function Input Output Description

Parse() XML file and JAXB-Content Allows an XML file to be annotated Java class instantiated Java object unmarshalled and instantiated into an object.

Write() Annotated Java XML file Using predefined object annotations, an object can be marshalled to allow it to be written to an XML file with proper formatting.

7.5.1.1 The algorithms for parsing is shown below (using foods.xml as an example):

public static void parse() throws JAXBException, IOException { try (FileInputStream file = new FileInputStream("./foods.xml")) { JAXBContext jaxbContext = JAXBContext.newInstance(Foods.class); Unmarshaller um = jaxbContext.createUnmarshaller(); Foods foods = (Foods) um.unmarshal(file); } }}

The parse function first opens up an input stream of the desires XML file. Then it creates a new instance of JAXBContext using the pre-annotated Java class. Next a Unmarshaller object is instantiated. Finally the desired object itself (object foods of class Foods) is unmarshalled/parsed from the XML file, by the Unmarshaller object. The object can then be manipulated by the other CSCs.

7.5.1.2 The algorithm for writing is shown below.

32 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 7 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

public static void write(Foods foods) throws IOException, JAXBException { try (FileOutputStream file = new FileOutputStream("foods.xml")) { JAXBContext jaxbContext = JAXBContext.newInstance(Food.class); Marshaller ma = jaxbContext.createMarshaller(); ma.marshal(foods, file); }}

The write function takes in an annotated Java object (in this case foods of class Foods). Then an output stream is opened of the XML file. Next a Marshaller object is instantiated. Finally the object is marshalled or written to the XML file. The file can then be opened in an editor or parsed by the parse() function.

Annotation of Java classes consists of setting the root element, the fields, and elements. This is done with @XmlRootElement(namespace = "namespace"), @XmlType(propOrder = { "field2", "field1",.. }), and @XmlElement(name = "newName") respectively. Note that @XmlType is optional as it defines a desired order that the fields are written in.

7.5.2 GUI CSC - The GUI CSC is meant to streamline and simplify the process of configuring and deploying the OKL4 Hypervisor. It consists of a main menu screen containing preliminary options such as project save destination and board selection. Additionally it contains a file menu which gives the user access to project management options such as saving and importing projects. After this stage the user is directed to a configuration wizard where they will select advanced VM options like memory configuration.

33 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 8 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.5.2.1 Figure 2 below shows a sample main menu screen.

Figure 2: Sample Main Menu Screen

34 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 9 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.5.2.2 Figure 3 below shows a sample project configuration wizard.

Figure 3: Sample Project Configuration Wizard

35 ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 10 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

Of importance is that the project configuration wizard can accommodate virtually any number of parameters needed to configure the system to the user’s need. Configurations that take up more screen space than allocated can be reached by a scrollbar. This is default behavior when using the SWT library.

7.5.3 Error Checker CSC - The Error Checker CSC handles errors the user may make when configuring a new system. Errors handled are overlap issues from virtual and physical memory and issues related to hardware limitations (choosing more cores than physically available).

7.5.3.1 Error checking will be implemented with if-else constructs and standard Java String objects.

7.5.3.2 The functions of Error Checker CSC are defined below:

Table 3: Error Checker CSC functions

Function Input Output Description

Evaluate input User input from GUI Determination of error, Evaluates user input for determination of valid overlap issues and system XML hardware restrictions.

Error Found User input from GUI Error message Error messages sent will be descriptive, but concise. Each message will be determined by the type of error.

Log Error Output from Error Detailed error Generates a log which Found function information keeps track of errors for the current project.

ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 11 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

7.5.3 Output File Compiler CSC - The Output File Compiler CSC calls the Weaver program to compile a boot image. This is done to abstract the process of calling the program into a button press.

7.5.3.1 The functions of the Output File Compiler CSC are defined below:

Table 3: Output File Compiler CSC functions

Function Input Output Description

Call Weaver System XML Boot image Compiles system XML into boot image

7.6.0 Requirement traceability 7.6.0.1 System Requirements allocated to the CSCI can be flowed further or allocated to its subassemblies. All requirements will be verified at the system level, but the further flow down shows which subassemblies are responsible for fulfilling each requirement.The table below shows the flowdown of requirements to sub assembly level.

ENGR 498A OKL4 Hypervisor Software Development Kit Project Project 18052 Software Design Document General Dynamics 12 of 12 Document Rev A 15JAN2019 OKL4 SDK 100100 plugin

Table 4: CSC Verification Matrix

Subassembly V Error Detection Project Management System Requirements M File Parser VM Module VM Unit VM 4.1.1 File System T 1.0 Direct flow T 1.0 Direct flow T 4.1.2 Graphical User Interface (GUI) D 2.0 Direct flow D 2.0 Allocated, 1.0 Allocated, 1000 4.1.3 Error Detection D 800 ms D ms D 4.2.1 Operating System I 3.0 Direct flow I 4.2.2 Development Environment I 4.0 Direct flow I 4.2.3 Programming Language I 3.0 Direct flow I 2.0 Direct flow I 5.0 Direct flow I 4.3.1 Java I 3.0 Direct flow I 2.0 Direct flow I 5.0 Direct flow I 4.3.2 Development Environment I 4.0 Direct flow I 2.0 Allocated, 1.0 Allocated, 1000 4.3.3 Error Checking D 800 ms D ms D 4.4.1 Configuration Retrieval 3.0 Allocated, Speed T 900 ms T 6.0 Allocated, 900 ms T 4.4.2 Error Notification 4.0 Allocated, 3.0 Allocated, 400 Speed T 200 ms T ms T 7.0 Allocated, 300 ms T 4.4.3 Output file boots on test board D 8.0 Direct flow D 4.4.4 Executable D 9.0 Direct flow D 7.7.0 Notes Not applicable.

38 8.0 ATP

OKL4 Hypervisor Software Development Kit Project 18052 Acceptance Test Procedure

Prepared by: Daniel Flores, Xiangjun Li, Victor Reyes, Ryan Wolfe, Kinsleigh Wong

Prepared for: General Dynamics Mission Systems

39 Revision History

Revision Description Date

Rev-A Initial Release 03/19/2019

40 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 1 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

Table of Contents 1.0 Introduction 1.1 Purpose 1.2 Scope 2.0 Requirements Summary 3.0 Test Plans 3.1 Testing Approach 3.2 Test Procedures 3.3 Roles And Responsibilities 3.4 Test Configuration 3.5 Required Test Equipment 4.0 Test Case Functional Groups 4.1 Identification Of Tests 4.2 Test Cases 5.0 Demonstration Verification

1.0 Introduction 1.1 Purpose The purpose of the Acceptance Test Procedure (ATP) is to document how the test system requirements will be verified.

1.2 Scope This procedure outlines the performance test for the configuration retrieval and error notification process. The test verifies that the amount of time the configuration retrieval and error notification process takes is less than two seconds.

2.0 Requirements Summary This ATP verifies by test the SRD requirements 4.4.1 and 4.4.2 from SRD rev-B. The requirements to be tested are shown in Table 1 below, with reference and measured values.

41 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 2 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

Table 1: System Requirement Verification

Requirement Method Limit/ Measured/ Pass/ Reference Ref Value Fail

4.4 Performance Requirements - - - -

4.4.1 Configuration Retrieval Speed: System shall supply T < 2s .248 s Pass user with configuration options in under two seconds.

4.4.2 Error Notification Speed: System design portion T < 2s .018 s Pass shall be interactive and notify users of errors in under two seconds.

3.0 Test Plans 3.1 Testing Approach Tests will be performed at the component, subassembly, and system levels. Functionality will be tested according to the test cases defined in the test plan. Both tests will be completed by April 9 - 11.

A limit value of 2 seconds was deemed reasonably real-time by both the team and our sponsor’s experience with GUIs. Anything longer would make the GUI feel sluggish and frustrate the user.

3.2 Test Procedures a) Write programs consisting of series of JUnit test cases (assertions) which will check against requirements with multiple sets of predefined inputs. b) Open Eclipse integrated development environment. c) Select OKL4 Hypervisor Plugin project via project manager d) Select test program. e) Run test program as a JUnit test case. f) Run time statistics for that test will be displayed in JUnit perspective in Eclipse.

42 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 3 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

3.3 Roles And Responsibilities Test participants will be any available team member. The team member who performs the test is responsible for accurate recording of the results.

3.4 Test Configuration

Modules will be tested using the JUnit4 testing framework. This means that for each module that needs to be tested, a separate class will be written that contains JUnit assertions and requires. Assertions are written for any feature or requirement that the module must pass without errors. To run the tests, the class in compiled and ran. Eclipse will then show which and how many tests have failed/passed.

3.5 Required Test Equipment

Description Version/Model Number Accuracy

Computer n/a n/a

Eclipse IDE Photon n/a

See drawing number 100,000 in the TDP for the minimum specifications of the computer.

4.0 Test Case Functional Groups 4.1 Identification of Tests 1. Pass speed and usability performance requirements Test Cases: a. Configuration Retrieval Speed: System shall supply user with configuration options in under two seconds. b. Error Notification Speed: System design portion shall be interactive and notify users of errors in under two seconds.

ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 4 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

4.2 Test Cases OKL4 Hypervisor SDK Acceptance Test Data Sheet

Referenced ATP Paragraph Number: 2.1 - System shall supply user with configuration options in under two seconds.

Analysis Referenced: N/A Name of Test: OKL4 configuration retrieval speed tests Results (Pass/Fail): Date of Test:

Recording of Test Measurement: Requirement: T = < 2 seconds

Computations: None needed

Signatures:

Tester ______

Customer ______

ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 5 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

OKL4 Hypervisor SDK Acceptance Test Data Sheet

Referenced ATP Paragraph Number: 2.2 - System design portion shall be interactive and notify users of errors in under two seconds.

Analysis Referenced: N/A Name of Test: OKL4 error notification speed tests Results (Pass/Fail): Date of Test:

Recording of Test Measurement: Requirement: T = < 2 seconds

Signatures:

Tester ______

Customer ______

5.0 Demonstration Verification The following SRD requirements will be verified by demonstration following the given steps: 4.1.3 Error Detection 1. Run application. 2. Create a new OKL4 project either from the examples directory or from scratch. 3. Deliberately assign more virtual memory than physically available. 4. Visually determine if the error was reported. 4.3.3 Error Checking 1. Run application. 2. Create new OKL4 project with an invalid xml source.

45 3. Demonstrate that error message is generated. ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Acceptance Test Procedure General Dynamics 6 of 6 Drawing Rev A 19MAR2019 OKL4 SDK 100,300 plugin

4.4.3 Output file boots on test board 1. Run application. 2. Create a new (valid) OKL4 project either from the examples directory or from scratch. 3. Visually determine that there are no error messages preventing a valid system XML file from compiling. 4. Generate boot image by pressing ‘Generate’ button on the last page of the setup wizard. 5. Locate generated boot image and place into microSD card. Plug the microSD card into the development board and boot the image. 4.4.4 Executable 1. Run application. 2. Create new (valid) OKL4 project either from the examples directory or from scratch. 3. Generate executable from setup wizard. 4. Run executable on the development board to demonstrate functionality.

9.0 Models

OKL4 Hypervisor Software Development Kit Project 18052 Models

Prepared by: Daniel Flores, Xiangjun Li, Victor Reyes, Ryan Wolfe, Kinsleigh Wong

Prepared for: General Dynamics Mission Systems

Revision History

Revision Description Date

Rev-A Initial Release 03/26/2019

ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Models General Dynamics 1 of 4 Drawing Rev A 26MAR2019 OKL4 SDK 100,400 plugin

Table of Contents 1.0 Introduction 2.0 Models 2.1 Error Checking Model #100,410 2.2 User Interaction Model #100,420 2.3 File Parser Model #100,430 2.4 Project Management Model #100,440

1.0 Introduction The purpose of the Models document is to show the functionality of each of the project’s submodules in diagram form.

2.0 Models 2.1 Error Checking Model (Drawing #100,410)

The error checking model gives a high-level view of the verification of system requirement 4.4.2 Error Notification Speed. Messages are sent between the GUI and error checking modules, to determine when to display an error message on the GUI.

49 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Models General Dynamics 2 of 4 Drawing Rev A 26MAR2019 OKL4 SDK 100,400 plugin

2.2 User Interaction Model (Drawing #100,420)

The user interaction model gives a simplified view of how the user will interact with interact with the plugin. The GUI is run straight from the Eclipse IDE and user configurations are inputted by the users.

50 ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Models General Dynamics 3 of 4 Drawing Rev A 26MAR2019 OKL4 SDK 100,400 plugin

2.3 File Parser Model (Drawing #100,430)

The file parser model shows the interaction between the user’s file system, the file parser, and the options shown in the GUI. All available user options are taken from the OKL4 SDK, depending on the user selected board. The file parsing must be completed in under 2 seconds in order to meet requirement 4.4.1.

ENGR498A OKL4 Hypervisor Software Development Kit Project Project 18052 Models General Dynamics 4 of 4 Drawing Rev A 26MAR2019 OKL4 SDK 100,400 plugin

2.4 Project Management Model (Drawing #100,440)

The project management model shows an example how the user is able to view, further customize, and import created projects. This model is showing how the plugin is packaged within Eclipse, and OKL4 projects are able to be seen and run from the Eclipse Workspace.