Student: Adrian Marsh
Faculty Advisors: John Baras and Mark Austin.
Date: September 2002 -- May 2003.

TABLE OF CONTENTS

1. Project Description
   Purpose : Setup problem.
   Topics : Scope and objectives; field examples of the combat marking system; brief initial requirements; project framework and focus.

2. Goals, Scenarios, and Use Cases
   Purpose : Create system requirements.
   Topics : Goals and scenarios; system actors and roles; system boundary; initial use cases and activity diagrams; temporal relationship of use cases.

3. Generation of Requirements from Use Cases
   Purpose : Create system-level requirements.
   Topics : Use cases to requirements traceability.

4. High-Level Models of System Behavior and System Structure
   Purpose : Create simplified models of behavior and structure.
   Topics : Combat marking system components; models of system behavior; models of system structure.

5. High-Level System Design
   Purpose : Create models of the high-level system design.
   Topics : Mapping high-level system behavior onto elements of the system structure; use case to component traceability.

6. Hand-Control Unit Design
   Purpose : Create framework for detailed hand-control unit design
   Topics : Refining the system requirements; refining the system structure.

7. From System Requirements to Specifications
   Purpose : Create pathway from low-level requirements to quantitative specifications.
   Topics : Generating system specifications from system requirements; component specifications. from component specifications to design options.

8. From Specifications to Commercial Design Options
   Purpose : Select commercial design options that satisfy specifications.
   Topics : Design alternatives for LCD; design alternatives for CPU; design alternatives for keypad.

9. Tradeoff Analysis for Hand Control Unit Design
   Purpose : Trade-off analysis of components for Hand Control Unit Design.
   Topics : Gathering the data; decision metrics; constraints; problem formulation; running CPLEX; Pareto plot analysis; system optimization; component configuration recommendation.

10. System Test, Verification and Validation
    Purpose : Develop procedures of system test, verification and validation.
    Topics : Test plan.....

11. Icons, References, and Web Resources
    

Scope and Objectives

The purpose of this project is to design a system, mountable to existing and future military combat vehicles, that will mark a lane through a minefield without exposing soldiers to direct and indirect fire.

In the first half of this study, initial high-abstraction requirements are determined. From these requirements the system is modeled through the use of use-case scenarios to refine requirements. From the refined requirements high-level system structure and behavior diagrams were constructed to represent the system.

The second half of this report focuses in on the detailed design and trade-off analysis of the "hand control unit." We refine the initial requirements, turn the requirements into specifications, and conduct a trade-off analysis to optimize components of the system design.

The Problem

Currently there is no mechanical means of marking a breach lane through an enemy minefield.

Figure 1 shows the situation where a minefield has been breached, but isn't marked.

Figure 1. Schematic of a minefield that has been breached, but isn't marked.

To avoid soldier casualties due to mine strike, we need a mechanism for marking the breach lane through a minefield. Presently, this marking process is entirely manual.

Discussion. The lack of such a system forces soldiers to exit their combat vehicle to mark a breach lane causing the following:

• Exposure of soldiers to direct and indirect fire while marking the lane
• Reducing the effectiveness of the marking
• Adding time to an already time consuming mission.

Furthermore, failure to effectively mark a breach lane greatly increases the likely-hood of follow on forces to run into the minefield and additional, unnecessary casualties.

The Solution

Develop a combat marking system, deployable from within a vehicle, which will successfully mark a breach lane.

The proposed marking system will allow breaching and marking to occur simultaneously, without soldier exposure to direct fire. See Figure 2.

Figure 2. Schematic of the Combat Marking System

Figure 3 shows operation after the breached lane has been marked.

Figure 3. Operation of the breached marking lane.

Components in the Combat Marking System

Figure 4. Components in the Combat Marking System

Field Examples

The adjacent diagram shows combat engineers marking a breach lane at the Combined Maneuver Training Center,

Figure 5. Field Implementation of the Breach Lane Markup

Initial Requirements: Brief

Brief list of initial planning requirements used to guide goal and scenario development and determine system optimization.

1. System
   Able to mount on variety of tracked and wheeled equipment
   Simple to use and install
   Withstand wide variety of environmental conditions

2. Lane Marking Material
   Visible at night
   Usable on variety of terrain including urban
   Withstand battlefield conditions

3. Program
   Testing
   Training support program
   Reference Material production (user manuals)
   Parts input in system concurrent with fielding
   Maintenance Support

Project Framework and Focus

The overall program responsibilities from a high level of abstraction are depicted in the following Use Case diagram.

Figure 6. High-Level Abstraction for the CMS Program

The remainder of this case study will focus on the "System Use" aspect of this diagram to focus on the system design rather than life-of development and fielding cycle.

Goals and Scenarios

Goal 1. System is mountable on variety of equipment

• Scenario 1.1: Mountable on tracked and wheeled
• Scenario 1.2: Mountable by a vehicle crew of 2 personnel
• Scenario 1.3: System does not interfere with vehicle operation

Goal 2. System marks minefield lane

• Scenario 2.1 Crew checks status of system and deploys system while inside the vehicle
• Scenario 2.2: System deploys markers to identify lane
• Scenario 2.3: Marks at 10-meter intervals

Goal 3. System must withstand combat conditions

• Scenario 3.1: Redundant power capabilities
• Scenario 3.2: Work through in all environments
  • Desert
  • Woodland
  • Arctic
  • Urban
• Scenario 3.3: Withstand Artillery strike within 25 M

Goal 4. Marking system must be visible to friendly personnel

• Scenario 4.1: Visible at night
  • While using NVG
  • While using Thermal
• Scenario 4.2: Visible in tall foliage
• Scenario 4.3: Visible from a vehicle
• Scenario 4.4: Visible from a range of 200M (on flat ground)

Goal 5. Fielding must include support package (High-level abstraction requirement)

• Scenario 5.1: User Training team, Training Aids, Training manuals
• Scenario 5.2: Maintenance Training Team
  • Maintenance manuals
• Scenario 5.3: Repair parts availability

System Actors and Roles

System Boundary

In this initial design the System Boundary is defined as the dispenser, control unit, mount and markers. In future designs these would be broken down again focusing on each and using the related components as actors for further clarification of requirements and system development.

1. System and users: The marking system boundary is the system, the markers and the mount. The interfaces with actors are inputs from the crew and mounting to the vehicle.

2. System and Environment: The marking system boundary is defined by how the system reacts and performs in under varying weather, terrain and combat conditions.

3. System controls/adjustment: The system must allow for user inputs in marking distance, additionally, it will receive power from the vehicle.

Initial Use Case Diagram

Initial USE CASE diagram for the Combat Marking System depicts the actors and their interaction with the systems.

Figure 7. Initial Use Case Diagram for the CMS System

Use Case Text and Activity Diagrams

Use Case 1. Mounting Bracket

• Description: A mounting bracket fits to combat vehicle
  Primary Actors: Crew, Vehicle
  Pre-Conditions: Given a Mounting Bracket and a vehicle
  Flow of Events:
  1. Mounting bracket secures to track
  2. Mounting bracket ties into vehicle power source
  3. Mounting bracket secures to wheeled vehicle
  4. Mounting bracket ties into vehicle power source
  Alternate Flow of Events: None
  Assumptions:
  1. Some permanent modification of the vehicle will be required
  2. Mounting Bracket will become a permanent part of the vehicle

Figure 8. Activity Diagram for Mounting and Installation

• New Requirements
  1. Universal mounting bracket
  2. Vehicle type specific power harnesses

Use Case 2. Mounting

• Description: System is mountable on combat vehicles
  Primary Actors: Crew, Vehicle
  Pre-conditions: Vehicle and crew available.
  Flow of Events:
  1. Crew picks up CMS
  2. Crew secures to mounting system
  Post-condition: CMS ready for use on vehicle
  Alternative Flow of Events:
  
  1. Crew cannot pick up system
  2. System does not mount
  Assumptions:
  1. Mounting system fits (M1, M2, M60, M113, and FMTV)
  2. Mounting system installed on vehicle ahead of time
  3. Mounting system does not interfere with vehicular functions

• New Requirements
  1. Systems light enough to be picked up and mounted by two personnel < 100 LB
  2. Dispenser must connect to mounting system
  3. CMS Dispenser does not interfere with vehicular functions

Use Case 3. Crew prepares CMS for operation

• Description: Runs system function check
  Primary Actors: Vehicle, Crew
  Pre-conditions: CMS system mounted, crew inside vehicle.
  Flow of Events:
  1. Crew powers system
  2. Crew initiates function check
  3. Crew receives function check information
  Post-condition: CMS functional and ready for operation
  Alternative Flow of events:
  1. Vehicular power line unavailable
  2. Vehicular function check displays fault/deficiency
  3. Crew rectifies problem or requests maintenance support
  Assumptions: None
  

Figure 9. Activity Diagram for Mounting and Preparing for Operation

• New Requirements
  1. Vehicular and internal emergency power source
  2. Method of communicating from inside vehicle to system
  3. System function check mechanism

Use Case 4. Loading

• Description: Load with breach markers
  Primary Actors: Crew, Vehicle, and Markers
  Pre-conditions: System is mounted and function checked.
  Flow of Events:
  1. Crew loads markers into CMS
  2. Crew conducts final function check
  3. System provides number and status of markers loaded
  Post-condition: CMS is loaded with lane markers
  Alternative Flow of Events:
  1. Marker doesn't load
  2. Final functions check assesses problem
  3. System fails to provide number and status of markers loaded
  Assumption: Markers provided separately from the system
  

Figure 10. Activity Diagram for Loading Dispenser

• New Requirements
  1. System interfaces/senses presence of markers
  2. System provides feedback on status of markers to operator
  3. System markers able to reload

Use Case 5. Marking lane

• Description: CMS marks a breach lane
  Primary Actors: Crew, Vehicle
  Pre-conditions: CMS loaded and mounted, crew inside vehicle.
  Flow of Events:
  1. Crew chooses lane marking dispersion
  2. Crew utilizes a controller to initiate lane marking
  3. CMS dispenses lane markers
  4. Crew chooses to stop lane marking dispensing
  Post-condition: Lane markers in place.
  Alternative Flow of Events:
  1. Crew fails to choose dispersion
  2. System defaults to old setting
  3. Crew initiates lane marking unintentionally **
  Assumption: None.
  

• New Requirements
  1. System provides a dispersion setting
  2. System has a safety feature to prevent unintended dispersion
  3. System has a start and stop mechanism

Use Case 6. CMS survivable

• Description: CMS system deployable worldwide
  Primary Actors: Terrain, Combat Effects
  Pre-conditions: System mounted on vehicle
  Flow of events:
  1. System operates in desert conditions w/ > 125 deg F temperature
  2. System operates in arctic conditions of –50 deg F temperature
  3. System can function during regular and freezing precipitation
  4. System can be immersed in water and still function
  5. System withstands 155 mm artillery round strike within 25m
  Post-condition: System operational
  Alternative Flow of Events: System fails any of above operating states
  

Figure 11. Activity Diagram for Lane Marking and CMS Survivability (Use Cases 5-6)

• New Requirements
  1. System electronics/mechanics withstand heat > 150 deg F temperature
  2. System electronics/mechanics withstand cold of –100 deg F
  3. System has built in heat/thaw function to remove frozen water/snow.
  4. System is water proof
  5. System has enough armor to withstand an artillery strike within 25M

Use Case 7. Marking system is visible

• Description: Marking system can be seen by follow on vehicle crews
  Primary Actors: Follow on forces, Terrain
  Pre-conditions: The lane marking system is dispensed
  Flow of Events:
  1. The follow on force can visually identify the lane marker
  2. The follow on force uses the lane marker to guide them safely through the minefield
  3. The marking material is clearly visible to follow on forces
  Post-condition: Follow on force passes through the minefield
  Alternative Flow of Events:
  1. Follow on force cannot visually identify the marker
  2. Follow on Force does not use the lane marker to guide through minefield
  3. Follow on Force delayed at minefield

• New Requirements
  1. Add upgrade package for GPS and signal additions to marking system to pass Breach information to follow on forces

Use Case 8. Marking system is survivable/visible

• Description: Marking system is survivable through breaching operation
  Primary Actors: Terrain, Combat Effects, Follow on forces
  Flow of Events:
  1. The marking system withstands wind speeds up to 50kph
  2. The marking system withstands 155mm artillery strike within 25m of marker
  3. The marking system withstands rain and snowfall
  4. Marking system is visible during night and smoke conditions
  Post-condition: Marking system remains visible
  Alternate Flow of Events: Marking system fails any of above conditions
  

• New Requirements
  1. System weather resistant
  2. System visible through NVG and thermal sites
  3. System withstands fragmentation within 25m

Temporal Relationship Among Use Cases

The adjacent figure shows the use cases organized temporally -- first we mount the marking system, then we prepare for operation ... and so forth.

Figure 12. Temporal Relationship Among Use Cases

Use Case to Requirements Traceability

The following chart identifies the requirements and the Use Cases that each requirement is associated with. Additionally, it depicts the scenario number and requirement number. The requirement number will be used in additional diagrams to depict the location or function that achieves each requirement.

System Structure

The system structure of the Combat Breaching system is depicted in the class diagram below.

Figure 13. Class Diagram depicting System Structure

Of note this diagram depicts two choices for the hand control unit either the cable unit or the radio remote unit. Additionally, the requirements in chart 2 are depicted on the diagram in red, to assist in the traceability of the requirements.

Objects and Attributes

System Behavior

Figure 14. Finite State Machine for Combat Marking System Behavior

The simplified diagram above depicts the system behavior at a high level of abstraction. An additional look of the system is in

Figure 15. Sequence Diagram depicting System Firing Behavior

Again the red letter-number combination shows the requirements in the system and how they trace through system behavior. The model above depicts the behavior of the system during the firing sequence.

PERFORMANCE ATTRIBUTES

Mapping System Behavior onto the System Structure

Figure 16. System Behavior Mapped onto System Structure for Firing System

The red arrows and lines indicate the mapping of the system behavior onto the system structure.

Figure 17. Power Behavior Mapped onto System Structure

Use Case to Component Traceability

Table 5 traces the use case and requirements to the sub-component that will meet the requirement.

The remainder of this report deals exclusively with design of the Hand Control Unit (HCU). We will detail the process of selecting commercially made components to meet the project specifications.

Refining System Requirements

Close examination of the requirements identified in ENSE 621 demonstrated a need for refinement. The initial requirements outlined were based on a high level abstraction and were not suitable for component level design. Additionally, the initial requirements did not include Attributes and Functions in the requirement list, which are essential to determining component design. Finally, the initial requirement numbering system needed to be updated to facilitate refined traceability needs.

The initial requirements were updated in the subsequent design of the system. Attributes and Functions were assigned to each object in the requirements list, additional requirements were added to support a lower level of abstraction, and the requirement numbering system was updated.

Refining the System Structure

The initial system structure diagram was at a high level of abstraction and did not sufficiently include Attributes and Functions needed for design. The updated class diagram (see Figure 18 below) includes additional components and the Attributes and Functions derived from the new requirements.

Figure 18. Updated Combat Marking System Structure

Focusing on the HCU, the class diagram is modified to present the components of interest: the LCD display, the keyboard and the processing unit. See Figure 19.

Figure 19. Hand Control Unit System Structure

Additionally, the subsystem behavior is used in examining the hand control unit in detail.

System Behavior

For the "hand control unit" design, we assume that the system-level behavior diagram is adequate.

Figure 20 depicts the behavior of the selected system in conducting a systems functions check. This will assist us in optimizing the sub-component interaction.

Figure 20. Hand Control Unit System Behavior Diagram (for system's function check)

Hand Control Unit Requirements

Turning System Requirements into System Specifications

Once the system requirements were refined, system specifications were needed to set limits on the component design. The system specifications were comprised from the Attributes and Functions outlined in the system requirements. These govern the formulation of specifications by stating what the component must do (Functions) and also what characteristics they must have (Attributes).

The system specifications for this project were largely determined from analysis of similar systems already in existence.

Component Specifications for LCD

Flowdown from Scenarios and Requirements

• Scenario 2.1
  
• Requirements no = "f"
  The dispenser shall display information to the crew.

Specifications

Component Specifications for CPU

• Scenario 2.1
  
• Requirements no = "f"
  The dispenser shall display information to the crew.

Specifications

Component Specifications for Keypad

• Scenario 2.1
  
• Requirements no = "g"
  The system shall receive commands from crew and send to dispenser.

Specifications

Turning Specifications for HCU into Commercial Component Options

The HCU SPEC sheet quantifies the Attributes and Functions in the Requirement listing, and is used to determine commercially available products to comprise the HCU, display, keyboard and processor.

A search of vendor websites provided numerous component options to meet the needs of the Hand Control Unit (see Table 10). In order to optimize the system a Trade-Off Analysis is required to determine the proper mix of components.

Design Alternatives for LCD

Design Alternatives for CPU

Design Alternatives for Keypad

Gathering the Data

The first step in conducting trade-off analysis was to gather the vender's performance data for their components and place it into our specification database. This structure will provide the tools used to formulate performance equations.

Decision Metrics

Metrics are determined in order to optimize the system for the most important criteria. The selection of HCU sub-components will be evaluated using 3 metrics. These will be the foundation for the analysis; equations will be structured in order to do the following:

1. Maximizing Total System Life
2. Minimizing Total System Weight
3. Minimizing Total System Cost

Constraints

In addition to the metrics listed above, the sub-components will be evaluated based on additional performance constraints, selected to optimize the performance of the HCU. The constraints for the system are as follows:

1. The minimum sub-component life greater than or equal to 100,000 uses.
2. The LCD surface area greater than or equal to 10 in2.
3. The character height on the LCD greater than or equal to 5.2 mrad.
4. The processing memory of the CPU greater than or equal to 500 Mb.
5. The keypad width greater than or equal to 5 in.
6. The Total Power usage of the system less than or equal to 15 W.

Problem Formulation

Using the Vendor SPEC sheet, the metrics listed above and the constraints, linear equations are formulated to input into CPLEX, to optimize the system.

DESIGN VARIABLES

The design variables have the following interpretation:

1. Selection of the LCD is represented by the variables X

   X _i = 1 for only one value of i = 1,2,3. Otherwise, X _i = 0.

2. Selection of the CPU is represented by the variables Y

   Y _i = 1 for only one value of i = 1,2,3. Otherwise, Y _i = 0.

3. Selection of the keypad is represented by the variables Z

   Z _i = 1 for only one value of i = 1,2,3. Otherwise, Z _i = 0.

The mathematical equations based on the information is as follows:

DESIGN OPTIMIZATION

• METRIC 1:

  Maximize Component Life = 500 x ₁ + 750 x ₂ + 830 x ₃ + 100 y ₁ + 200 y ₂ + 160 y ₃ + 500 z ₁ + 100 z ₂ + 200 z ₃

SUBJECT TO:

• METRIC 2:

  Minimize Weight= 850 x ₁ + 750 x ₂ + 650 x ₃ + 300 y ₁ + 450 y ₂ + 250 y ₃ + 900 z ₁ + 750 z ₂ + 800 z ₃ <= K ₁

• METRIC 3:

  Minimize Cost = 380 x ₁ + 400 x ₂ + 450 x ₃ + 400 y ₁ + 420 y ₂ + 500 y ₃ + 450 z ₁ + 300 z ₂ + 500 z ₃ <= K ₂

CONSTRAINTS:

• System Life of LCD

  500 x ₁ + 750 x ₂ + 830 x ₃ >= 100

• System Life of CPU

  100 y ₁ + 200 y ₂ + 160 y ₃ >= 100 *

• System Life of KEYPAD

  500 z ₁ + 100 z ₂ + 200 z ₃ >= 100 *

• CONSTRAINT 2: LCD Surface Area

  11 x ₁ + 15 x ₂ + 18 x ₃ >= 10

• CONSTRAINT 3: Character Height

  5.5 x ₁ + 6.0 x ₂ + 6.5 x ₃ >= 500

• CONSTRAINT 4: Processor Mem:

  535 y ₁ + 576 y ₂ + 768 y ₃ >= 500

• CONSTRAINT 5: Keypad Width

  5.0 z ₁ + 5.5 z ₂ + 6.0 z ₃ >= 5.0

• CONSTRAINT 6: Power Usage

  3.8 x ₁ + 4.5 x₂ + 2.8 x ₃ + 5.6 y ₁ + 6.3 y₂ + 4.0 y ₃ + 2.0 z ₁ + 3.0 z₂ + 2.8 z ₃ <= 15

• CONSTRAINT 7: Selection of variable x

  x ₁ + x ₂ + x ₃ = 1

• CONSTRAINT 8: Selection of variable y

  y ₁ + y ₂ + y ₃ = 1

• CONSTRAINT 9: Selection of variable z

  z ₁ + z ₂ + z ₃ = 1

For the purpose of analysis, and in in order to produce better trade-off analysis results, product life was scaled from the hundred thousands to hundreds place.

Analysis Procedure

Each run of CPLEX maximizes the "so-called" system life (see editorial note below) while satisfying constraints for cost and weight controlled by the analysis variables K ₁ and K ₂.

The max/min range of permissible values can be obtained from the sum of attribute values in the table of design options. For example:

Min Possible Value of K ₁ =

    = min ( 850, 750, 650 ) + min ( 300, 450, 250 ) + min ( 900, 750, 800 ) 
    = 650 + 250 + 750 = 1650.

Max Possible Value of K ₁ =

    = max ( 850, 750, 650 ) + max ( 300, 450, 250 ) + max ( 900, 750, 800 ) 
    = 850 + 450 + 900 = 2200.

Now see the tables below.

Editorial Note

For mathematical convenience, the design objective of maximum component life has been represented:

• Component Life = 500 x ₁ + 750 x ₂ + 830 x ₃ + .....

But this formulation isn't quite right. The optimization of life in this case required determining the highest sub-component life, in order to maximize the total system life. This computation is difficult to represent as a linear equation, in essence it would have to pick the highest component life systems, then determine the lowest life of the total system (which is the weakest component) then optimize to find the longest lasting of the weakest system.

To conduct this optimization, the assumption was made to allow the sum the component lives to find the optimal system. From this data a spreadsheet was used to find the weakest sub-component of the system.

Figure 21. Procedure for dealing with the design objective "maximize system life."

The assumption was that the highest sum value of lives would include the best component solution. Since this is not completely reliable, constraints were added to the equation to further optimize life. See Figure 21 for a flowchart of these activities. The life constraint allowed the minimal acceptable life to be used as screening criteria.

Running CPLEX

Once the equations were determined, CPLEX was used to optimize the system. The variables K1 and K2 listed above were varied 12 times and run into CPLEX. CPLEX optimizes the solution and provides sub-component selections by allocating the number 1 by the optimal solution.

The results of the CPLEX runs are listed below (Table 2):

Graphical Summary Performance Metrics for Initial Designs

Figure 22. Summary of Performance Metrics for Initial Designs: (1) Cost versus weight; (2) life versus weight; (3) life versus cost.

Procedure for Pareto Analysis

Using the data in Table 2, graphs were created in order to identify Pareto, metric trade-off, points. Analysis of these points produced the first set of optimal solutions.

Figure 23. Example of Pareto Point Analysis

As indicated in Figure 21, the Pareto points are the points where no gain of one metric is achieved without the loss of another metric.

First Pareto Plot Analysis

Following the analysis of the first trade-off graph Pareto points the six of the optimization solutions were eliminated resulting the in the following solution set:

The following figure is a graphical summary of performance metrics for the six designs following the initial Pareto analysis.

Figure 24. Performance Metrics of Design Options remaining after the first round of Pareto Analysis

Second Pareto Plot Optimization

Using the results remaining from the first analysis (see Table 3), additional graphs were constructed to further analyze the solutions. The graphs are displayed in APPPENDIX H. Analysis of these graphs indicated a wide range of possible solutions; however, typical Pareto points were not selected from these results in their entirety.

Figure 25. Elimination of Design Options in Second Round of Pareto Analysis.

All of the points indicating life solutions of 100,000 uses were thrown out due to the availability of solutions ranging in the 160,000 to 200,000 life range. This was done due to the prioritization of the metrics with life being first, followed by weight, then cost (see APPENDIX I).

Following the second analysis, the possible solutions were reduced to the following:

System Optimization

Having narrowed the options to three remaining points, again graphs were constructed to assist in the final optimization of the system. We will now examine each remaining option in detail.

COMPONENT 1: OPTION 3 ANALYSIS

Analysis of Option 3 shows that its component combination maximizes system life with a value of 200,000 uses before failure. However, this combination also maximizes cost by bringing the total system cost to $2,000 per HCU. Additionally, this option maximizes the weight of the system at2000g. (See Figure 7).

Figure 26. Pareto Analysis for Design Option 3

SOLUTION 2: OPTION 6 COMPONENTS

Option 6 provides a relatively high value for life with 160,000 uses before failure. Of the three remaining options it is the lowest weight, weighing 50g less than the next closest option. However, it is the second highest costing option with a value of $1,600 per HCU system (see Figure 8).

Figure 27. Pareto Analysis of Option 6.

SOLUTION 3: OPTION 10 COMPONENTS

Option 10 offers a relatively long product life of 160,000 uses before failure. It does have the second highest weight, weighing 50g more than option 6. However, it is the lowest costing option, offering $160 savings per HCU when compared to it's closest competitor (see Figure 9).

Figure 28. Pareto Analysis of Option 10.

Component Configuration Recommendation

Final component selection requires quantifiable and subjective analysis of the trade-off data. The chart below summarizes the trade-off results (Table 5).

Points to note are as follows:

• Based on the data presented in Table 17, option 10 offers the optimum component configuration for the system. Although this option does not maximize component life, it does offer a life expectancy of 160,000 uses, which is acceptable when taking into account the extremely high cost and weight offered by the longest lasting configuration in option 3.
• Option 10 is not the lightest configuration, outweighing option 6 by 50g. This again is acceptable since the weight increase of 50g is relatively insignificant when considering cost gains.
• Option 10 is the least costly option saving $150.00 per unit, when compared to option 6, which offers only slight gains by decreasing weight.
• Option 10 offers an acceptable life expectancy, with moderate weight at a low cost, making it the optimal solution.

This selection results in the following commercial component selection (Table 6):

Figure 29. Schematic of Vendor Selection Results

System Test Plan

Insert material, Fall Semester 2003 ..... it's done, I have haven't had time to update the tutorial ... aghhh!

Icons

1. The adjacent figure shows icons for engineer vehicle, combat vehicle and mine.

References and Web Resources

1. Mark Austin: Lecture Notes for ENSE 621. Institute for Systems Research, University of Maryland, 2002.
2. John Baras, Lecture Notes ENSE 622, Institute for Systems Research, University of Maryland Spring 2003.
3. John Baras, Integrated Product and Process Design for Electromechanical Products, University of Maryland Institure for systems Research, 8 April, 1998.
4. Mingjia Dai, MP3 Player System Project Final Report, ENSE 623 Project, University of Maryland, 19 DEC, 2002 http://www.isr.umd.edu/Courses/ENSE622/index.html
5. FM 101-5. STAFF ORGANIZATION AND OPERATIONS. U.S. Army Publishing, MAY 1997.
6. Martin Fowler, Scott, Kendell, UML Distilled, Second Edition. Addison-Wesley- Longman, 2000.
7. Elizabeth Hull, Jackson, Ken, Dick, Jeremy, Requirements Engineering, Springer, London, 2002.
8. Adrian Marsh, Combat Marking System Design, ENSE 621 Project, University of Maryland, 19 DEC, 2002.
9. Vimal Mayank, Saraf, Deep, Modeling and Design of a Fast Food Restaurant, ENSE 623 Project, University of Maryland, 19 DEC, 2002 http://www.isr.umd.edu/Courses/ENSE622/index.html
10. Practical UML a Hands On Introduction for Developers. See www.togethersoft.com/services/practical_guides/umlonlinecourse/
11. Steve Sullivan & Ben Standish. "Inventory Tracking System." See www.geocities.com/sullivanss1/Requirements.htm
12. Lagakos V., "Case Study: Development of a Portable CD Player." See http://www.isr.umd.edu/austin/nsf-crcd/case-study-cd-player.html.

Developed by Adrian Marsh, Spring Semester 2003
Reformatted and slightly modified by Mark Austin, May 2003
Copyright © 2003, Adrian Marsh, John Baras and Mark Austin. All rights reserved.