JTRS Visual Modeling Studio

Senior Project Presentation Monday, May 12

Introductions

  Project Sponsor  Mr. Charles Linn – Harris RF Communications Faculty Advisors   Dr. James Vallino Prof. Stephanie Ludi       The A-Team Garrett Wampole Ben Litchfield Jason Gilman Jason Offord David Bryant

Agenda

     Introduction to JTRS  What is it and how does it work?

Overview of JVMS   Where it fits in Features overview Development Process    Team organization Risks Support tools Technologies Product Demonstration

Introduction to JTRS

 Joint Tactical Radio System (JTRS)  Department of Defense initiative designed to meet diverse communications needs of warfighters through software programmable radio technology  Goals   Provide a consistent family of software programmable radios designed around the Software Communications Architecture (SCA) Eliminate communications and logistical problems associated with ‘stovepipe’ legacy systems

Introduction to JTRS

 Problems with existing radio systems  Monolithic code packages  System must be re-written for each device  Allocation determined in advance   Everything is known

a-priori

Leads to designs that are too specific  Closed interfaces  No provision for extensibility  Static architecture  Nothing changes

Introduction to JTRS

 Advantages of JTRS software-defined radios     Separation of concerns  Radio platform (hardware) and application software are described separately  Functionality is represented through interactions between components Consistent distribution and delivery mechanism  Application packages can be loaded, installed, and configured at runtime Applications have component-based design  Promotes reusability Standardized set of interfaces  Allows application to examine the runtime environment dynamically  Allows components to express dependencies and relationships

Introduction to JTRS

  Software Communications Architecture (SCA)  SCA provides a framework that governs the structure and operation of JTRS Domain Profile    Platform capabilities, application components, their interconnections and dependencies are described by the Domain Profile JTRS system components examine the Domain Profile when loading an application to determine how it must be launched Domain Profiles are comprised of a set of XML files whose format is specified by the SCA

Introduction to JTRS

  Domain Profiles can be large  A typical waveform can require thousands of lines of XML Profiles are hard to conceptualize  The SCA’s description of an application does not necessarily map to how a designer would think of it  The SCA does not make an attempt to define a readable format  Creating and maintaining Domain Profiles by hand is expensive, time-consuming, and error prone…

JVMS Overview

 JTRS Visual Modeling Studio (JVMS)  Allows designers to graphically model Domain Profiles and generate the corresponding XML  Projects can be saved to an interchangeable format and loaded later  Relationships between components are represented visually  Models can be validated against definable criteria, designers are guided to where errors exist

JVMS Overview

 Model Features  Components are separated into ‘views’   Platform View – represents the radio hardware platform Application View – represents application software  Each has two sub-views   Component  Components and their attributes are defined here Assembly  Holds component instantiations, allows components to be connected together

JVMS Overview

 Relationship Features  Connections between components are created on the assembly view  Created and represented graphically  Some relationships have attributes of their own that can be modified

JVMS Overview

 Validation Features  Flexible architecture for adding new ‘business’ rules that can’t be expressed using a DTD  Designers can validate a single component for internal integrity or an entire application  When validation fails, designers are told where errors exist

Development Process

 Senior Project  Non-negotiable deadline  Team members with diverse schedules  Healthy amount of domain knowledge to absorb  New technologies

Development Process

 Organize the team  Assign clearly defined roles and responsibilities      Team Leader  Customer liaison, run meetings, keep everyone on track Development Leader  Research technologies, organize and run development effort Testing Manager  Create test plans, run test scripts, report issues Support Manager  Maintain project artifacts Planning Manager  Determine schedule, keep team informed of time commitments and progress

Development Process

 Set schedules  Weekly (sometimes bi-weekly) team meeting  Circulate agenda, and make materials available a day in advance  Weekly conference calls with sponsor  Three development phases   Conduct product release after each phase Validate release with sponsor and factor input into next phase

Development Process

  Identify Risks  Recognized risks in project plan   Categorized by likelihood Developed mitigation plan for each risk Example   Team member have limited experience with selected technology  Priority – high  Probability – medium Mitigation Plan  Assign a team member to research the technology thoroughly and become the expert for the rest of the team

Development Process

 Set goals    Prioritize requirements according to schedule and sponsor’s preference Product Goals    Complete high and medium priority requirements Complete low priority requirements as time permits Deliver quality product (< 2 bugs / K LOC) Process Goals   Create test plan before implementation starts Review all artifacts at least once  Keep stakeholders well informed of progress

Development Process

  Create support tools   Wanted an easy way to distribute information to team members and sponsor Provide a central repository for information Kelut  Set of web-based process support tools   Features     Discussion Forums Requirements Management Test Case Repository Issue Tracking jtrs.kelut.org

Development Process

 Metrics  Hours  1164 planned  Size  20,000 lines planned  Requirements  104  28 Uses Cases  Issues  76 opened (927 actual) (27,897 actual) (97% implemented) (24 implemented) (95% resolved)

Technologies

 JVMS makes use of .NET

 Microsoft .NET Platform  Describes a general framework which can be targeted by a specific platform and language  C# provides the language flexibility of Java  Windows Forms architecture provides a rich set of controls and libraries  Interop provides access to native operating system

Product Demonstration

 Tasks  Create a JVMS project  Define platform and application components  Create assemblies from component instances  Validate project  Generate SCA XML

JVMS For more information on: JVMS JTRS Harris Kelut jtrs.kelut.org

jtrs.army.mil

www.harris.com

www.kelut.org