Wire Routing System

Wire Routing System (WRS) Systems Engineering Management Plan
_____________________________________________________________________________
~ 1 ~
Wire Routing System (WRS)
Systems Engineering
Management Plan
(SEMP)
5 October 2015

_____________________________________________________________________________
~ 2 ~
Document Control
Created
By:
Name: Title: Date:
Brian Davidson Project Manager 23-Sep-15
Theresa D’Amore Deputy Project Manager 23-Sep-15
Chad Vance Systems Engineer, Integration 23-Sep-15
Andrew Schuettpelz Systems Engineer, SME 23-Sep-15
Kyle Lopez Systems Engineer, IT 23-Sep-15
Sachin Mehta Systems Engineer, V&V 23-Sep-15
Reviewed By:
Name: Date:
2-Oct-15

_____________________________________________________________________________
~ 3 ~
Table of Contents
1
SEMP / Project Overview.................................................................................................. 7

1.1
Need Statement........................................................................................................... 7

1.2
Project Structure ......................................................................................................... 9

2
Business Case .................................................................................................................... 9

3
Requirements Development Process ............................................................................... 10

3.1
Customer Requirements............................................................................................ 10

3.2
Derived Requirements .............................................................................................. 12

3.3
Requirements Analysis and Prioritization ................................................................ 13

4
System Architectures....................................................................................................... 14

4.1
Functional Analysis .................................................................................................. 14

4.1.1
Functional Architecture Description.................................................................. 14

4.2
Concept Exploration................................................................................................. 14

4.3
Architecture & Design Specifications ...................................................................... 15

4.3.1
Technology Market Survey ............................................................................... 15

4.3.2
Physical Architecture......................................................................................... 17

4.3.3
Architecture Documentation.............................................................................. 18

4.3.4
Architecture Quality Attributes ......................................................................... 18

5
System Verification and Validation................................................................................. 18

6
Design Model................................................................................................................... 20

7
Project Summary ............................................................................................................. 22

7.1
Work Breakdown Structure...................................................................................... 22

Project Management WBS ................................................................................................ 22

Systems Engineering WBS................................................................................................ 23

Interface Systems WBS..................................................................................................... 23

Control System WBS......................................................................................................... 23

Mechanical System WBS .................................................................................................. 23

Management Reserve WBS............................................................................................... 23

Assembly and Test WBS................................................................................................... 23

Sustainment WBS.............................................................................................................. 23

7.2
Project Plan............................................................................................................... 24

7.3
Risk Management..................................................................................................... 24

8
Lifecycle Management Plan ............................................................................................ 24

8.1
Deployment Plan ...................................................................................................... 24

8.2
Support Plan.............................................................................................................. 24

8.3
Cost Estimates .......................................................................................................... 24

9
Appendices ...................................................................................................................... 25

9.1
Appendix I Requirements......................................................................................... 25

9.2
Appendix II Requirements Analysis......................................................................... 29

9.3
Appendix III Architecture......................................................................................... 31

9.4
Appendix IV V & V ................................................................................................. 33

9.5
Appendix V Market Research .................................................................................. 38

_____________________________________________________________________________
~ 4 ~
List of Tables
Table 4-1 First and second place technology options................................................................... 16

Table 4-2 Technology Compatibility Matrix................................................................................ 17

Table 4-3 Physical Architecture Alternatives............................................................................... 18

Table 9-1 Use and misuse case scenarios based upon the use case diagram................................ 25

Table 9-2 Complete list of WRS customer requirements............................................................. 27

Table 9-3 Complete list of WRS derived requirements................................................................ 27

Table 9-4 WRS evaluation criteria matrix.................................................................................... 29

Table 9-5 WRS requirements prioritization matrix ...................................................................... 30

Table 9-6 Four (4) Phase Test Plan............................................................................................... 33

Table 9-7 Review Gate Table ....................................................................................................... 34

Table 9-8 Validation Matrix ......................................................................................................... 35

Table 9-9 Compliance Matrix....................................................................................................... 36

Table 9-10 WRS Traceability....................................................................................................... 37

Table 9-11 Technology Impact Matrices...................................................................................... 38

Table 9-12 Technology Options ................................................................................................... 39

_____________________________________________________________________________
~ 5 ~
List of Figures
Figure 1.1- Wire Harness _______________________________________________________ 7

Figure 1.2 - Form Board ________________________________________________________ 7

Figure 1.3 Wire Harness Fabrication Process________________________________________ 8

Figure 1.4 Wire Routing System Model____________________________________________ 9

Figure 3.1
WRS
use
case
diagram_______________________________________________ 11

Figure 3.2 Use case for route wire _______________________________________________ 11

Figure 3.3
Derived
Requirements
traceability
back
to
Customer
Require______________ 13

Figure 4.1 Ranked Architecture Alternatives _______________________________________ 15

Figure 6.1 Hybrid Communication-Sequence Diagram _______________________________ 21

Figure 6.2 WRS boundary diagram ______________________________________________ 22

Figure 9.1 Affinity diagram of customer requirements _______________________________ 27

Figure 9.2 Functional Tree Diagram______________________________________________ 29

Figure 9.3 Interrelationship Digraph______________________________________________ 31

Figure 9.4 Hatley–Pirbhai modeling _____________________________________________ 32

Figure 9.5 Work Breakdown Structure____________________________________________ 40

_____________________________________________________________________________
~ 6 ~
List of Acronyms
AND Activity Network Diagram
COTS Commercial Off-the-Shelf
CR Customer Requirements
ConOps Concept of Operations
DRCM Design Requirements Compliance Matrix
EC Engineering Characteristics
EPA Environmental Protection Agency
FFBD Functional Flow Block Diagram
ICD Interface Control Document
ID Interrelationship Digraph
IEEE Institute of Electrical and Electronics Engineers
INCOSE International Council On Systems Engineering
IPD Integrated Product Team
MMA Morphological Matrix of Alternatives
MOE Measures of Effectiveness
MOP Measures of Performance
MOS Measures of Suitability
NESHAP National Emission Standards for Hazardous Air Pollutants
NFPA National Fire Protection Agency
OSHA Occupational Safety and Health Administration
PM Prioritization Matrix
QFD Quality Function Deployment
SEI Software Engineering Institute
SEMP Systems Engineering Management Plan
SEP Systems Engineering Process
SE Systems Engineering
SME Subject-Matter Expert
TCM Technology Compatibility Matrix
TIM Technology Impact Matrix
V&V Verification and Validation
WBS Work Breakdown Structure
WRS Wire Routing System

_____________________________________________________________________________
~ 7 ~
1 SEMP
/
Project
Overview

1.1 Need
Statement

The goal of this project is to provide a proof of concept technology demonstration of a
system for the accurate and repeatable routing of wire in 3D space, during wire harness
manufacturing. Current methods of wire routing rely on antiquated techniques that require
manufacturers to depend heavily on their fabricator’s attention to detail and personal motivation
to produce high-quality products. Manual wire routing is prone to defects, inconsistencies, and
unpredictable spans from initiation to completion. These elements add fabrication cost by
increasing difficulty when planning work, forecasting material usage, and predicting time to
completion. It is approximated that first pass quality defects increase harness costs by 6-12%A.
The cost of poor initial quality is then magnified when lost time is factored into the price of wire
harness fabrication. Therefore, harness manufacturers require a repeatable, accurate, and
affordable system for routing wire during wire harnesses fabrication.
Figure 1.1- Wire Harness
Image found at www.quickwireharness.com/
Figure 1.2 - Form Board
Image found at www.supremecable.com/
The Wire Routing System (WRS) will meet these industry needs through the use of
automation, which will reduce touch labor hours and routing error. Precision mechanics further
improve accuracy and repeatability. The use of automation for wire routing is unprecedented; it
will require acute attention to our customers’ priorities throughout the entire systems engineering
lifecycle. Aerospace and automotive harnesses manufacturers are the intended customers for the
WRS. Utilizing the priorities of our customer, this document will ensure the value of
repeatability, accuracy, ease of use, increased reliability, and the use of existing technologies is
emphasized throughout the decision making process.

_____________________________________________________________________________
~ 8 ~
Development of an unprecedented system leaves this project
vulnerable to increased levels of risk in the form of unknown-
unknowns and scope creep. In an effort to mitigate this, several key
assumptions were established from the inception of the WRS. The
WRS concept demonstrator will:
• Route a single wire at a time
• Cut wire to designed length
• Keep the final product in designed configuration until user is
ready for product removal
The wire harenss fabrication process was mapped to illustrate the
scope of the WRS and maintain project focus in. See Figure 1.3,
highlighted in green is the element of wire harness fabrication that is
the focus of this effort. Planned future development will incrementaly
expand the capabilities of the WRS and will incorporate other
elements of the fabrication process; this is discussed further in the
verification and validation section of this document.
Figure 1.3 Wire Harness Fabrication Process

_____________________________________________________________________________
~ 9 ~
Figure 1.4 Wire Routing System Model
The next steps in the team’s process involved the use of well-defined customer values,
narrow scope, and a disciplined systems engineering approach to develop and evaluate various
technologies in an effort to meet the customer needs. Based on our thorough analysis, we
recommend the WRS be internally funded for further development. The WRS will quickly
provide higher quality harnesses, with superior consistency than the current solutions. The WRS
is a competitive advantage that positions us to earn new lines of business.
1.2 Project
Structure

To be developed during ASE 6004
2 Business
Case


_____________________________________________________________________________
~ 1 0 ~
3 Requirements
Development
Process

Customer requirements were developed to define what the system should provide as well as
define any system constraints. Well-written and thorough requirements have been critical to the
success of the WRS because they ensure key customer needs are fulfilled.
In
order
to
begin
the
process
of
defining
requirements
for
the
WRS,
the
customers
and

multiple
stakeholders
were
consulted
to
help
identify
the
essential
needs
that
the
system

should
fulfill.

The
customers
and
stakeholders
solicited
during
this
process
are
listed

below:

The target customers of the WRS will be wire harness manufacturers in both the automotive
and aviation industries. All other groups listed above are stakeholders of the WRS and are
important because they impose requirements on the system. For example, wire manufactures
produce wire of a certain size and type which means the WRS must be compatible with wire
provided.
3.1 Customer
Requirements

Generating requirements for an innovative product is a difficult process because there is not
a clear understanding of the end product when the process begins. For this reason, the integrated
development team (IDT) utilized brainstorming sessions and created use cases to help generate
requirements. These two strategies will be discussed in further detail within this section.
Brainstorming sessions with the customers and stakeholder were a great way to identify
requirements for the system. The result was a large number of requirements, which served to
address the wide variety of needs and constraints on the WRS. Brainstorming also resulted in a
rough understanding of the system functionality. Based upon the results, the system should
receive inputs from a variety of operators, perform its intended function and then output a wire,
which is routed into a specific design.
The rough understanding of the WRS functionality gained from the brainstorming sessions
allowed the IDT to then create a use case diagram. This use case diagram can be seen in Figure
3.1 below.
§ Wire
Harness
Manufacturers
§ Wire
Manufacturers

§ Sustainment
Personnel
§ Wire
Routing
Technicians

§ Harness
Designers
§ Quality
Control

§ Wire
Harness
End
Users
§ Regulatory
Agencies

_____________________________________________________________________________
~ 1 1 ~

Figure 3.1
WRS
use
case
diagram
The use case diagram of the WRS helped to identify requirements that were not generated
during the brainstorming sessions. Note that WRS operators have been broken up into operators
of individual actions. This was done to provide more insight into the individual interactions
between the actors and the WRS. Identifying interactions and developing use case scenarios for
them helped flush out additional requirements. Figure 3.2 provides an example of one use case
scenario as well as the customer requirements that were derived from it.
Figure 3.2 Use case for route wire
The use case scenario presented a pre-condition where the WRS has a harness design loaded
and the correct wire available to it. The basic flow section illustrates the actions taken by the
operator and the WRS response to those actions. As an example of how use cases helped in
generating customer requirements, Step 3 states that the WRS terminates (cuts) the wire at the
Use
Case
Name 2.2
Navigate
Wire
in
3D
Space
Use
Case
Description Wire
Routing
System
(WRS)
Routes
wire
based
upon
the
3
dimensional

design
provided
to
it
Actor System
Command
Operator
Pre-‐conditions WRS
has
successfully
received
the
desired
wire
routing
design
and
wire

and
is
prepared
to
execute
wire
route
design
Post-‐conditions Wire
is
routed
along
the
desired
3
dimensional
route
and
constrained
in

place
Misuse
Scenarios a.

Wire
feed
runs
out
of
wire
b.

Wire
is
not
constrained
properly
and
falls
out
of
configuration
Basic
Flow 1.

Operator
commands
the
WRS
to
begin
routing
operation
2a.

WRS
converts
design
path
format
into
mechanical
motion
2b.

WRS
feeds/lays/guides/prints
wire
along
the
design
path

2c.

WRS
constrains
the
wire
along
the
design
path
configuration
as

the
wire
is
put
in
place
3.

WRS
system
terminates
wire
at
the
end
of
the
wire
route
path
4.

WRS
communicates
to
Operator
that
the
wire
route
is
complete

_____________________________________________________________________________
~ 1 2 ~
end of the wire route path. This particular step indicated the need for a requirement on the WRS
to limit the wire that exists outside of the routed envelope.
In addition to the use cases in Figure 3.2, four (4) more use cases were developed for the
following WRS-Operator interactions:
• Receive
Wire
Path
Design

• Receive
Wire

• Accommodate
Removal
of
Wire

• Receive
Input

The use cases can be seen in Table 9-1 in Appendix I along with their respective misuse
cases.
A large number of customer requirements resulted from the use case scenarios and
brainstorming sessions. To help organize and consolidate the requirements, the team utilized
two key analysis tools; an affinity diagram and a tree diagram. The affinity diagram served to
group the large amount of scattered requirements. This grouping is shown in Appendix I, Figure
9.1. By doing this, the team was able to identify requirements that were similar and could be
consolidated. The full list of customer requirements can be seen in Appendix I, Table 9-2. Once
the customer requirements were grouped and consolidated, they were organized by function and
structured into a tree diagram. The WRS tree diagram can be seen in Appendix I, Figure 9.2.
This began to paint a picture of how the system should be structured. It also identified gaps that
the customer requirements didn’t address. The next step was to derive requirements to fill the
gaps.
3.2 Derived
Requirements

Derived requirements are not explicitly stated in the set of customer requirements, yet are
necessary to satisfy one or more of them. The tree diagram made it clear which customer
requirements needed to be elaborated on. Figure 3.3 below shows several examples of
requirements that were derived from the list of customer requirements

_____________________________________________________________________________
~ 1 3 ~

Figure 3.3
Derived
Requirements
traceability
back
to
Customer
Require

The full list of derived requirements and their traceability back to the customer requirements
can be seen in Appendix I, Table 9-3.

3.3 Requirements
Analysis
and
Prioritization

Once all of the customer and derived requirements were established and traceable, the team
segregated the high level customer requirements and prioritized them based on customer
importance. This was accomplished using an evaluation criteria matrix and a requirements
prioritization matrix. First, the customer needs were scored against one another in the evaluation
criteria matrix to determine the correct weighting associated with each one with respect to the
others. This table can be seen in Appendix II, Table 9-4. Next, the high level customer
requirements were ranked against one another based upon how vital they were to each weighted
customer need. This process helped to identify the customers’ highest priority requirements and
their respective derived requirements. The requirements priority matrix can also be seen in
Appendix II, Table 9-5.
The requirements development process helped to achieve a solid understanding of all the
requirements and their priorities, which set the stage for the functional architecture development.

_____________________________________________________________________________
~ 1 4 ~
4 System
Architectures

4.1 Functional
Analysis

4.1.1 Functional
Architecture
Description

Based on the customer and derived requirements we developed a functional decomposition
tree depicted in Figure 9.2 in Appendix I . The major system functions were identified, broken
down and in some cases eliminated where necessary to remain within the project scope. This not
only helped to identify testable conditions but also to derive further requirements. As the team
broke down each function we began to establish the limits and boundaries of the WRS.
Traceability of each function back to the original WRS customer requirements can be seen in Appendix
IV Table 9-10.
The tier 1 functions of our decomposition were Utility, Operation and Sustainment. Of
these, the Operation decomposition led to most of the architectural features, while the Utility and
Sustainment sub-functions greatly assisted in understanding the boundaries.
The WRS functional architecture diagram is the baseline description of the WRS
functionality and can be seen in the Hatley–Pirbhai model, Appendix III, Figure 9.4. From this
functional decomposition we considered the sequence of the systems primary functions and how
they relate to one another on many levels.
The team decided to focus on the five key functions that drive the unique capability of this
system.
• 2.1.1 Receive Wire Path Design
• 2.1.2 Deploy Wire
• 2.2 Route Wire
• 2.3.2 Accommodate Removal of Wire
• 2.1 Receive Input
This led to the development of a Hybrid Communication-Sequence model to address the
flow of data and material throughout our system, see Section 6, Figure 6.1. The team also created
a system boundary model to illustrate critical internal subsystem boundaries and how the WRS
relates to external systems.
4.2 Concept
Exploration

Basic requirements of the system were established using industry need, as identified by
experts. Varying levels of complexity were brainstormed. An interrelationship digraph was
used to determine the sensitivity of early system requirements, see appendix III, Figure 9.3. User

_____________________________________________________________________________
~ 1 5 ~
interaction, routing wire to design specification, and maintainable were shown to be the most
sensitive. It indicated that the preferred alternatives are focused on satisfying the most sensitive
requirements. This focus will ensure robustness of the WRS design and reinforces the rational of
the design architecture choices made by the team.

The IDT used pair-wise comparisons to prioritize the customer requirements and used these
prioritized requirements to evaluate technology solutions identified during the technology market
survey (TMS) based on their ability to fulfill the prioritized customer values from the technology
impact matrix (TIM). A technology compatibility matrix (TCM) was then utilized to eliminate
configurations that would not allow for full system functionality. The remaining options were
organized into four (4) physical architecture alternatives. Each alternative was ranked against
one another with respect to the five (5) prioritized customer values using the analytical hierarchal
process. The analysis revealed that two (2) of the alternatives would be best suited to fulfill the
customer need. Figure 4.1, Ranked Architecture Alternatives With only a 1.79% discrepancy
between these alternatives, the IDT decided that further evaluation is needed to distinguish the
two (2) options and will be performed during a later iteration of the systems engineering process.
Figure 4.1 Ranked Architecture Alternatives
4.3 Architecture
&
Design
Specifications

4.3.1 Technology
Market
Survey

The WRS architectural design began with exhaustive technological research on five (5) key
functionalities, outlined above in the functional architecture description, Section 4.1.1. The
technology exploration illustrates information from a breadth of resources. These requirements
took precedence in the analysis because they represent the underpinnings of development and
will be integral in eventual system performance. The five (5) measures of effectiveness (MOE),
which were refined by the integrated design team (IDT) served as the set of evaluation criterion
in order to determine MOE relative importance amongst one another. The following is a

_____________________________________________________________________________
~ 1 6 ~
summary of the evaluation criteria matrix Appendix II, Table 9-4 and depicts the final % relative
importance of each respective MOE.
-‐ Accuracy/Repeatability = 31%
-‐ Simplified User Operation = 10%
-‐ Increased Reliability = 20%
-‐ Lower Operating Cost = 28%
-‐ Use of Existing Technology = 11%
Implementation of a TIM for each of the five (5) key functionalities provided a quantified
analysis on technology options and their ability to meet each MOE. The next table displays the
1st
and 2nd
place technology options that arose from each TIM study.
Table 4-1 First and second place technology options
Technology
Option

WRS
Function
1st
Place

2nd
Place

Ref
2.1
–
Receive

Input

Form
Based
(29%)

WIMP/GUI
(27%)

Ref
2.1.1
–
Receive

Wire
Path
Design

Universal
Serial
Bus
(38%)
Wired
Network
(36%)

Ref
2.1.2
–
Receive

Wire

Gear
Wheel
Straightener

(31%)

Conveyorless
(28%)

Ref
2.2
–
Route

Wire

Linear
Ball
Slide
(46%)
Belt
Driven
(40%)

Ref
2.3.2
–

Accommodate
Removal

of
Wire

Mechatronics
(71%)

Operator
Based
Modular

Equipment
(29%)

This data analysis shows a major distinction (highlighted in red) between the ‘mechatronics’
and ‘operator based modular equipment’ characteristics—with ‘mechatronics’ yielding a 42%
more impact to meet the WRS functional needs. This variation occurred for two (2) reasons:
1) The 9:3 ratio ‘mechatronics’ had against ‘operator based modular equipment’ for the
MOE of accuracy/repeatability.
2) The 9:1 ratio ‘mechatronics’ had against ‘operator based modular equipment’ for the
MOE of lower operating cost.
On the other hand, the four (4) other WRS functions that were analyzed with a TIM showed
a relatively low % discrepancy among technology options—all between 2-6%. Further iterations
of trade studies will be performed in the future to compare technology options with more
specificity. For example, there are various mechatronic and robotic technology designs available
on the market that could possibly fit the WRS needs—so discriminating against them with

_____________________________________________________________________________
~ 1 7 ~
another TIM study will continue through Phase 1 of the test plan, Section 5, until PDR. An exact
replica of each TIM study can be referenced in Appendix V, Table 9-11.
Additional market survey analyses on three (3) low-impact WRS functions can be examined
in Appendix V, Table 9-12. It should be noted, however, that these are not TIM studies, but do
help break down the following WRS functions:
-‐ Ref. 1.1 Power Supply
-‐ Ref. 1.2.2 Remove Exhaust/Particulate
-‐ Ref. 2.1.1.1 Translate Design to Route
4.3.2 Physical
Architecture

Compatibility amongst technologies was the next analysis performed to down-scale physical
architecture options using a TCM, Table 4-2 below. This technique discriminated amongst WRS
technology options; those that would not be able to perform, or integrate, with one another.
Table 4-2 Technology Compatibility Matrix
1
=
Incompattable
Form
Based
Capacitive
Touch
HMI
Command
Line
WIMP/GUI
Wired
Network
USB
2.0/3.0
Cloud
Based
Gear
Wheel

Straightener
Bearing
Wheel

Straightener
Conveyorless
Crank
Wheel
Belt
Driven
Linear
Ball
Slide
Manual
Peg
Board
Operator
Based

Modular
Equipment
Mechatronics
Ref.
2.1.2
Receive
Wire
Ref.
2.3.2

Accommodate

Removal
of

Wire
Ref.2.2
Route

Wire
Ref.
2.1
Receive
Input
Ref.
2.1.1
Receive

Wire
Path
Design
Form
Based 0 1 1 1 1 1
Capacitive
Touch

HMI
0 1 1 1 1
Command
Line 0 1 1 1
WIMP/GUI 0 1 1
Wired
Network
0 1 1 1 1
USB
2.0/3.0
0 1 1 1
Cloud
Based
0 1 1
Gear
Wheel

Straightener
0 1 1 1 1 1
Bearing
wheel

straightener
0 1 1 1 1
Conveyorless
0 1 1
Crank
Wheel 0 1 1 1
Belt
Driven
0 1 1 1
Linear
Ball
Slide 0 1 1
Manual
Peg
Board 0 1
Operator
Based

Modular

0 1
Mechatronics 0
Ref.2.2
Route
Wire
Ref.
2.3.2

Accommodate

Removal
of
Wire
Ref.
2.1
Receive

Input
Ref.
2.1.1
Receive

Wire
Path
Design
Ref.
2.1.2
Receive

Wire

_____________________________________________________________________________
~ 1 8 ~
Results of this analysis poised the IDT assigned to the WRS to arrive at four (4) varying
physical design architectures shown below in Table 4-3.
Table 4-3 Physical Architecture Alternatives
These four (4) architecture alternatives include:
-‐ High TRL Interface
-‐ Advanced Interface
-‐ Easy to Use
-‐ Bare Bones Basic
Two (2) of the architecture alternatives only differ in the WRS function Ref. 2.1 Receive
Input: the ‘High TRL Interface’ and ‘Advanced Interface’ alternatives, while the others have a
greater deal of variation among technology options.
These architecture alternatives will include a list of interface control documents, which will
be adequately defined and documented for PDR in the future.
4.3.3 Architecture
Documentation

4.3.4 Architecture
Quality
Attributes

5 System
Verification
and
Validation

We have been and will be preforming review and test sequences throughout our system’s
development. The team intends to use a mix of Informal, Static and Dynamic verification and
validation methods. A compliance matrix is included in Appendix IV, Table 9-9 to ensure that
requirements set by regulatory bodies are met.
The team has established a series of preliminary design review (PDR) entrance and exit
criteria. Similar reviews will be performed to ensure that the engineering team does not lose sight
of the customer need. Critical stages of development will include multiple reviews. Each of
WRS
Function High
TRL
Interface Easy
to
Use Bare
Bones
Basic Advanced
Interface
Ref.
2.1
Receive
Input Form
Based WIMP/GUI Form
Based WIMP/GUI
Ref.
2.1.1
Receive

Wire
Path
Design Wired
Network USB
2.0/3.0 USB
2.0/3.0 Wired
Network
Ref.
2.1.2
Receive

Wire Gear
Wheel
Straightener Bearing
Wheel
Straightener Conveyorless
Gear
Wheel

Straightener
Ref.
2.2
Route
Wire Linear
Ball
Slide
Belt
Driven Belt
Driven Linear
Ball
Slide
Ref.
2.3.2

Accommodate

Removal
of
Wire
Mechatronics Mechatronics
Operator
Based

Modular
Equipment
Mechatronics
Physical
Architecture
Alternatives

_____________________________________________________________________________
~ 1 9 ~
these reviews will compare the stated goals of a stage and the results; all criteria must be
satisfied before moving on to the next stage.
A similar review will be performed at the onset of each new stage to properly define and
communicate the goals to the team. These verification activities will take place throughout the
research and development of the WRS, however, during procurement and integration a much
more formal process will be utilized. For these critical stages a four phase validation plan has
been developed and can be found in Appendix IV Tables 9-6 and 9-7. The 4 phases are as
follows:
Phase
1
Phase
2
Phase
3
Phase
4

Individual
Component

Testing/
Middleware
AoA

Subsystem

Integrations

System
Level

Integrations

Prototype
Testing
incl.

Operation
and
Quality

Phase 1 will address the entry and exit to the component procurement stage of the project.
An evaluation of the various component options that resulted from our technology market study
will be used to develop further AoAs of the identified technology suites. Each suite will be
defined by the communication protocols and signals utilized; a technology impact matrix (TIM)
will ensure that no incompatibilities are built in to the WRS.
Phase 2 will mirror phase 1, incorporating mechanical and structural considerations. The
results of this stage will derive further requirements for the selection of the WRS operating
system.
Phase 3 will run through a similar process as the previous two phases, this time for the
assembled subsystems. Testing of the software operating system that best fits the decisions made
in Phases 1 & 2 will occur as well.
While each phase will be broken up into various subsections for continuity, those in Phase 4
are the most critical and must be considered very early in development for the project’s success.
Once cleared to proceed to Phase 4 the team will begin integrating those subsystems that resulted
from Phases 2 & 3. The first stage (Appendix IV, Table 9-6, Phase 4.1) of Phase 4 will review
the mechanical and structural interfaces. Upon acceptance of Review Gate 4.2(Appendix IV,
Table 9-7) operational testing (Appendix IV, Table 9-6, Phase 4.2) will begin to confirm that the
software and control systems react as expected during both normal operation as well as fault and
failure scenarios.
Once operational testing has been successfully completed, quality testing will begin. This
stage (Appendix IV, Table 9-6, Phase 4.3) will address the ability of the WRS to produce a
consistent product within the required specifications and confirm the systems durability. Phase 4
testing will be deemed successful once a technology demonstration has been performed and the
customer is satisfied with the results. However, in the event that the system does not perform as

_____________________________________________________________________________
~ 2 0 ~
expected the team will continue to the Rework (Appendix IV, Table 9-6, Phase 4.4) and Retest
(Appendix IV, Table 9-6, Phase 4.5) stages.
It is very important to note that review gates scheduled during this plan will elicit and allow
the team to act upon stakeholder feedback relevant to the progress and direction of the WRS.
A fifth phase will be implemented upon customer acceptance of the proof of concept system.
Phase 5 will include production validation, hardware improvements, additions and software
upgrades while verifying that the customer needs continue to drive development.
6 Design
Model

The WRS has a complex set of communication requirements between components, which
requires a rigid set of boundary definitions. The following hybrid communication-sequence
diagram demonstrates how data traverses the WRS from user execution through the WRS and to
the delivery system.
The WRS boundary diagram shows communications between hardware-software-hardware.
Each item that has a shared border in the graph is illustrating that there are communications
between them. Items within a red box are out of scope for our project, but still have
communications between them. This communication must be further developed for each
incremental upgrade in system capability.

_____________________________________________________________________________
~ 2 1 ~
Figure 6.1 Hybrid Communication-Sequence Diagram
Feeds wire on
demand
Attributes
Wire De-reeler
Routes physical
wire in 3D space
One routes a
single wire at a
time
Motors/PLCs
Middleware
Transfers data to
low level
middleware
Hard/software
WRS UX
Feeds wire on
demand
Holder of final
product
Wire Delivery
Request wire
from external
system
Send sequence
to low level
hardware
Move final
product to
delivery state
Inform user that
product is final

_____________________________________________________________________________
~ 2 2 ~
Figure 6.2 WRS boundary diagram
7 Project
Summary

7.1 Work
Breakdown
Structure

The WBS for the entire system development program is shown in Appendix V, Figure 9.5.
Each separate root (W<single digit #>) is a tier 1 level in the breakdown. Delineating from those
are the next work breakdown tiers and they reflect other major elements of the WRS program in
its entirety, from assembly and test to sustainment.

Project
Management
WBS

The WBS W1 refers to all elements related to the WRS program development, including
vendor oversight, procurement management, and facility related issues.
User/Software
UX
Version 1 «precondition» pre
«postcondition» post
Wire De-reeler
«precondition»
Wire present
«postcondition»
WRS requesting wire,
or FIN signal
Delivery system
«precondition»
Wire harness present
«postcondition»
Remove ﬁnal product
3D CAD codec
Version 1
Hardware
Version 1
WRS 3D
encoding
Version 1
Middleware
Version 1
High2Low translator
Version 1
Sequencing
Version 1
PLC
Version 1
Adadapters/
Connectors
Version 1
Structure
Version 1
Out of bounds Software Hardware Enclosure

_____________________________________________________________________________
~ 2 3 ~

Systems
Engineering
WBS

The WBS W2 involves the development of technical expertise, SEMP and the ConOps.
Understanding and updating of related technical documentation falls upon these R&D and
product development personnel.

Interface
Systems
WBS

The WBS W3 falls under the purview of the SME in relation to interface systems
technology. PDR on this issue will come through his or her oversight, and will be founded upon
appropriate research and documentation.

Control
System
WBS

The WBS W4 provides a breakdown of work associated with WRS control system
development. This includes process control, automation, and regulation of electro-mechanical
systems.

Mechanical
System
WBS

The WBS W5 for the Mechanical System is the most extensive aspect of the WRS. This
work breakdown involves hardware design and fabrication, component integration, along with a
large amount of V&V activities.

Management
Reserve
WBS

In order to better accommodate best practices, an allotted amount of reserve funds will be
distributed amongst three (3) sectors of WRS development: quality risk, cost risk, & schedule
risk. Early acknowledgement that there is a certain amount of risk involved in full scale
development provide a greater probability of success.

Assembly
and
Test
WBS

The WBS W7 for Assembly and Test provides process quality management in regards to
complete fabrication of validated devices. This will be supervised by the all W2.2 personnel
including: electrical lead, mechanical lead, team lead, software lead, and drafter.

Sustainment
WBS

The WBS W8 heavily details the development of manuals and training. Maintenance
schedules for the WRS will be discussed and developed, along with repair procedures for system
components. It is the responsibility of the PM and the SE to lead this process to completion.

_____________________________________________________________________________
~ 2 4 ~
7.2 Project
Plan

7.3 Risk
Management

8 Lifecycle
Management
Plan

8.1 Deployment
Plan

8.2 Support
Plan

8.3 Cost
Estimates

The cost estimates were derived by first identifying the top elements from our work
breakdown schedule. This included:
• Project Management
• Systems Engineering
• Interface Systems
• Control System
• Mechanical Systems
• Assembly and Test
• Management Reserve
• Sustainment
Second, using our determined deliverable life cycle methodology, we identified our tier one
cost elements from the WBS, and the subordinate elements in relation to our project life
cycle. The team labeled risks for each cost element, and the type of distribution patterned
matched each element’s risk factors. Some factors that influenced risks to the project were,
supply chain management, integration factors, scope, resource conflicts, changing customer
requirements and political influences.
Project Management: The project manager will be most crucial at the beginning of the
project, but will still be integral throughout the entire life cycle. We used a lognormal
distribution because the risks at the beginning are very high, but die slowly as the project reaches
the end of life.

_____________________________________________________________________________
~ 2 5 ~
Systems Engineer: Like the project manager the systems engineer will be critical to the
entire project life cycle, but will have slightly less risk in the beginning, and the highest amount
of risk will be centered around the integration, validation and verification phase because of this
we chose a Gaussian distribution.
Interface Systems: The interface system has its highest amount of risk around beginning to
middle of the whole project life. The risk for this element comes from unit testing each
software/hardware component, and integration with the rest of the system. We believe that this
risk pattern is best modeled with a Gaussian distribution.
Control Systems: The control system development is the cost element that pertains to the
translating of 3D cad file to a time-series plan for each mechatronic component to route a wire in
3D space. The risk for this cost element is Gaussian because it is needed for
Mechanical Systems: The risks for the mechanical systems has the greatest amount of the
risk due to the amount and variety of mechatronic components as well as the supply chain
logistics to obtain the parts. The amount of risk best fit a triangular (Mean (a+b+c)/3; Variance
(a^2+b^2+c^2 –ab-ac-bc)/18) distribution curve because this cost element changes significantly
through each phase due to integration.
Assembly and Test: The assembly and testing of all the component is a vital cost element
for this project. Because we are using items with a higher technology readiness we won’t have as
a high of a risk at any one phase of the project, but we will have a lognormal (Mean (e^µ+
σ^2)/2; Variance ((e^ σ^2) -1)(e^2*µ+ σ^2)) distribution curve that will slowly go to zero as the
project finishes its full life cycle.
Management Reserve: The management reserve fund is a fixed cost, and will provide the
project with a set of monies for project issues that are unforeseen, or need extra resources to keep
the project on time.
Sustainment: Sustainment will cover development of maintenance and repair guides, as
well as personnel to do the actual repairs/maintenance. This element will be later in the whole
project life cycle, and should be have a lesser amount of risk because it is at the end of
development. This is why we believe that the risk pattern for this is a normal distribution curve.

9 Appendices

9.1 Appendix
I
Requirements

Table 9-1 Use and misuse case scenarios based upon the use case diagram

_____________________________________________________________________________
~ 2 6 ~
Use
Case
Name 2.1.1
Receive
Wire
Path
Design Parent
Use
Case
Name 2.1.1
Receive
Wire
Path
Design
Use
Case
Description Wire
Routing
System
(WRS)
receives
a
3
dimensional
wire
harness
design

from
operator
Misuse
Case
ID 2.1.1a

Unrecognized
file
type
loaded
Actor Route
Design
Operator Misuse
Case
Description WRS
does
not
recognize
the
wire
harness
design
file
format
has
no
wire
harness
design
to
execute Actor Operator
has
no
wire
harness
design
to
execute
Basic
Flow 1.

Operator
activates
WRS
2.

Operator
makes
the
wire
harness
design
available
to
WRS
3.

Operator
utilizes
WRS
user
interface
system
to
select
correct
wire

harness
design
4.

WRS
does
not
recognize
file
type

5.

WRS
generates
error
message
displayed
through
user
interface
6.

WRS
prompts
Operator
to
re-‐attempt
file
selection
Post-‐conditions WRS
has
identified
wire
harness
design
and
is
prepared
to
execute
it Post-‐conditions WRS
has
communicated
file
type
error
and
awaits
new
file
Misuse
Scenarios a.

Unrecognized
file
type
loaded
Use
Case
Name 2.1.2
Receive
Wire
Parent
Use
Case
Name 2.1.2
Receive
Wire

Use
Case
Description Wire
Routing
System
(WRS)
receives
wire
from
the
Operator Misuse
Case
ID 2.1.2.a

Incorrect
wire
loaded
Actor Wire
Provider
Operator

Misuse
Case
Description Operator
provides
the
wrong
size/type
wire
has
identified
wire
type
and
size
needed
for
wire
harness
design;

Correct
wire
type
and
size
are
available

Actor Operator

has
identified
wire
type
and
size
needed
from
wire
harness
design;

Correct
wire
type
and
size
are
available

Basic
Flow 1.

WRS
communicates
to
the
operator
what
wire
type
is
need
for
the

design
2.

WRS
provides
step
by
step
instructions
showing
operator
how
to

load
wire
3.

Operator
follows
steps
presented
and
prepares
the
WRS
to

receive
the
wire
4.

Operator
makes
the
incorrect
wire
available
to
the
WRS
system
5.

WRS
recognizes
incorrect
wire
loaded

has
successfully
received
wire
and
is
prepared
to
execute
desired

wire
route
design
has
communicated
wire
size/type
error
and
awaits
correct
wire

Misuse
Scenarios a.

Incorrect
wire
loaded
Use
Case
Name 2.2
Navigate
Wire
in
3D
Space Parent
Use
Case
Name 2.2
Route
Wire
Use
Case
Description Wire
Routing
System
(WRS)
Routes
wire
based
upon
the
3
dimensional

design
provided
to
it
Misuse
Case
ID 2.2.a
Wire
feed
runs
out
of
wire
Actor System
Command
Operator Misuse
Case
did
not
load
enough
wire
to
complete
route
has
successfully
received
the
desired
wire
routing
design
and
wire

and
is
prepared
to
execute
wire
route
design
Actor WRS,
Operator
has
successfully
received
the
desired
wire
routing
design
and
wire

and
is
prepared
to
execute
wire
route
design
Basic
Flow 1.

WRS
communicates
to
the
operator
that
the
WRS
is
prepared
to

execute
wire
route
design
2.

Operator
commands
the
WRS
to
begin
routing
operation
3.

WRS
compares
wire
route
design
to
quantity
of
wire
available
in
wire

feed
5.

WRS
generates
error
message
stating
insufficient
quantity
of
wire

is
routed
along
the
desired
3
dimensional
route
and
constrained
in

place
has
communicated
wire
quantity
error
and
awaits
receipt
of
more

wire

Misuse
Scenarios a.

Wire
feed
runs
out
of
wire
b.

Wire
is
not
constrained
properly
and
falls
out
of
configuration
Use
Case
Name 2.3.2

Accommodate
Removal
of
Wire Parent
Use
Case
Name 2.3.2

Accommodate
Removal
of
Wire
Use
Case
Description Wire
Routing
System
(WRS)
enables
the
removal
of
a
successfully
routed

wire
which
has
been
constrained
in
place
Misuse
Case
ID 2.3.2.a
Improper
Wire
Handling
Actor WRS,
Operator Misuse
Case
Description 1.

Wire
is
not
released
properly
and
falls
out
of
configuration
has
successfully
routed
and
constrained
wire
but
it
is
still
contained

within
the
system
Actor WRS,
Operator
has
successfully
routed
and
constrained
wire
but
it
is
still
contained

within
the
system
Basic
Flow 1.

WRS
communicates
to
the
operator
what
wire
type/size
is
need
for

the
desired
design
2.

WRS
provides
step
by
step
instructions
showing
operator
how
to

load
wire
3.

Operator
does
not
correctly
follow
removal
steps
and
wire
falls
out
of

configuration
during
removal
4.

WRS
generates
error
message
stating
routed
wire
is
out
of

configuration
5a.
Operator
restores
wire
to
correct
configuration
and
proceeds
with

removal
5b.
Operator
removes
wire
with
incorrect
configuration
and
resorts
back

to
Function
2.2.
Route
Wire
is
removed
from
WRS
in
the
desired
route
configuration Post-‐conditions WRS
has
communicated
wire
configuration
error
and
awaits

next
step

from
Operator
Misuse
Scenarios a.

Improper
Wire
Handling
Basic
Flow 1.

Operator
activates
WRS
2.

Operator
makes
the
wire
harness
design
available
to
WRS
3.

Operator
utilizes
WRS
user
interface
system
to
select
correct
wire

harness
design
4.

WRS
System
recognizes
file
format
of
wire
harness
design
5.

WRS
indicates
that
receipt
of
wire
harness
design
was
successful
Basic
Flow 1.

Operator
commands
the
WRS
to
begin
routing
operation
2a.

WRS
converts
design
path
format
into
mechanical
motion
2b.

WRS
feeds/lays/guides/prints
wire
along
the
design
path

2c.

WRS
constrains
the
wire
along
the
design
path
configuration
as

the
wire
is
put
in
place
3.

WRS
system
terminates
wire
at
the
end
of
the
wire
route
path
4.

WRS
communicates
to
Operator
that
the
wire
route
is
complete
Basic
Flow 1.

Operator
request
wire
type/size
for
harness
design
2.

WRS
communicates
to
the
operator
what
wire
type/size
is
need
for

the
desired
design
3.

WRS
provides
step
by
step
instructions
showing
operator
how
to

load
wire
4.

Operator
follows
steps
presented
and
prepares
the
WRS
to

receive
the
wire
5.

Operator
makes
the
wire
available
to
the
WRS
system
6.

WRS
system
receives
wire
and
indicates
to
user
that
the
wire
is

successfully
received
1.

WRS
communicates
to
the
operator
that
the
wire
routing
process

is
complete.
2.

Operator
indicates
to
the
WRS
the
desire
to
remove
wire
from

system
3.

WRS
ensures
wire
is
securely
constrained
in
configured
route
4.

WRS
maneuvers,
allowing
Operator
access
to
the
routed
wire

5.

WRS
releases
wire
constraints
as
necessary
to
allow
removal
of

wire
without
losing
route
configuration
6.

Operator
communicates
to
the
WRS
that
the
wire
is
successfully

removed
and
the
WRS
is
clear
of
personnel
or
obstruction
7.

WRS
system
maneuvers
back
to
operational
configuration
Basic
Flow

_____________________________________________________________________________
~ 2 7 ~
Table 9-2 Complete list of WRS customer requirements
Table 9-3 Complete list of WRS derived requirements
Figure 9.1 Affinity diagram of customer requirements
Use
Case
Name 2.1
Receive
Input Parent
Use
Case
Name 2.1
Receive
Input
Use
Case
Description Wire
Routing
System
(WRS)
receives
input
from
operator Misuse
Case
ID 2.1.a
Workstation
Misuse
Actor System
Command
Operator
Misuse
Case
wants
to
perform
an
operation
that
is
not
displayed
is
in
a
state
of
standby
awaiting
input
from
Operator Actor Operator
is
in
a
state
of
standby
awaiting
input
from
Operator
Basic
Flow 1.

WRS
communicates
to
Operator
what
current
state
of
system
is
2.

WRS
presents
next
step
options
to
Operator
3.

Operator
determines
most
applicable
next
step
of
desired
outcome
4.

Operator
does
not
see
desired
option
5.

Operator
returns
to
"main
menu"
6.
Operator
navigates
to
desired
input.
7.

Operator
commands
WRS
to
perform
desired
next
operation
8.

WRS
received
input
and
is
ready
to
performs
command
has
successfully
received
desired
input
and
is
ready
to
perform

command
has
successfully
received
desired
input
and
is
ready
to
perform

command
Misuse
Scenarios a.

Workstation
Misuse
Basic
Flow 1.

WRS
communicates
to
Operator
what
current
state
of
system
is
2.

WRS
presents
next
step
options
to
Operator
3.

Operator
determines
most
applicable
next
step
of
desired
outcome
4.

Operator
commands
WRS
to
perform
desired
next
operation
5.

WRS
received
input
and
is
ready
to
performs
command
Req. # Req. Origin Requirement Short Text Requirement Long Text
CR1 D2.OPERATOR.BD.01 Manual
activation
and
deactivation Operator
shall
be
provided
means
to
activate
and
deactivate
the
WRS
manually
CR2 D2.OPERATOR.BD.04.1 Means
to
remove
completed
product The
WRS
shall
provide
operator
means
to
remove
the
completed
product
CR3 D2.OPERATOR.BD.02.1 Uploaded
wire
route
path Operator
shall
be
provided
means
to
upload
wire
route
path
data
into
the
WRS
software
CR4 D2.OPERATOR.BD.02 User
Interface The
WRS
shall
provide
operator
a
graphical
user
interface
CR5 D2.SYSTEM.TD.04 Visual
and
oral
queues The
WRS
shall
include
visual
and
oral
queues
to
guide
operation
CR6 D2.SYSTEM.TD.11 Uses
CNC
routing
files The
WRS
shall
accept
CNC
routing
files
CR7 D2.SYSTEM.TD.08 Maintainable The
WRS
shall
be
capable
of
receiving
maintenance
CR8 D2.SYSTEM.TD.03 Routes
wire
in
3D
space The
WRS
shall
route
wire
in
three
dimensional
space
CR9 D2.SYSTEM.TD.06 Auto
shutoff The
WRS
shall
include
an
automatic
shutoff
CR10 D2.SYSTEM.TD.15 Provides
status
to
operator The
WRS
shall
provide
operational
status
to
operator
CR11 D2.SYSTEM.TD.01 Provide
hazard
protection The
WRS
shall
protect
bystanders
from
hazards
presented
by
moving
parts
CR12 D2.SYSTEM.TD.07 Modular
The
WRS
shall
be
modular
to
allow
for
future
expansion
CR13 D2.WIRE.CV.07 Limit
wire
waste The
wire
that
exists
outside
the
routed
envelope
shall
be
limited
to
a
designated
length
CR14 D2.WIRE.CV.03 Routes
wire
within
design
specifications The
WRS
shall
produce
routed
wire
that
meets
design
path
tolerance
specified
within
engineering
requirements
CR15 D2.WIRE.CV.06 Wires
can
be
grouped The
routed
wire
shall
be
capable
of
being
grouped
together
with
other
wires
routed
along
the
same
path
CR16 D2.UTILITY.KL.06 Electrically
grounded The
WRS
shall
be
electrically
grounded
to
comply
with
national,
state,
and
local
regulations
CR17 D2.UTILITY.KL.07 Surge
protection The
WRS
shall
incorporate
utility
surge
protection
CR18 D2.LIFE.AS.05.1 Components
must
fit
through
doorways The
WRS
shall
disassemble
to
fit
through
NFPA
standard
openings
CR19 D2.SUSTAINMENT.SM.01 Uses
commercial
software The
Wire
Routing
System
shall
use
existing
Commercial-‐off-‐the-‐Shelf
(COTS)
software
CR20 D2.SUSTAINMENT.SM.04 Calibratable The
WRS
shall
incorporate
calibration
as
required
to
maintain
engineering
specifications
CR21 D2.UTILITY.KL.05 Manages
waste The
WRS
shall
manage
byproduct
waste
CR22 D2.UTILITY.KL.01 Powered
by
local
utilities The
WRS
shall
be
powered
by
local
power
utilities
WRS Customer Requirements
Req. # Cust. Req. Trace Requirement Short Text Requirement Long Text
DR22.1 CR22 Convert
Power Power
infusion
to
system
shall
be
distributed
within
standard
safety
parameters
of
the
power
source.
DR22.2 CR22 Distribute
Power The
WRS
shall
provide
Individual
electrical
components
with
the
appropriate
power
DR22.3 CR22 Operational
Conditions The
WRS
shall
provide
operational
environment
for
components
DR21.1 CR21 Provide
Ventilation WRS
shall
have
a
sub-‐system
exhaust
ventilation
to
meet
quality
standards
dictated
by
EPA.
DR14.1 CR6 Translate
Design
to
Route The
WRS
shall
read
CNC
file
types
and
convert
into
mechanical
motion
to
implement

wire
routing
designs
DR.8.1 CR4, CR14 Receive
Wire The
WRS
shall
receive
wire
based
upon
routed
wire
specifications
DR8.2 CR8 Support
Routed
Wire Routed
wire
shall
remain
in
routed
configuration
within
design
tolerances
until
further
processing
DR8.3 CR14, CR15 Deploy
Wire The
WRS
shall
deploy
wire
along
design
path
during
mechanical
motion
DR7.1 CR7 Receive
Lubricant The
WRS
components
shall
be
capable
to
receive
lubricant
DR19.1 CR7, CR19 Programmable
Software the
WRS
software
package
shall
accept
prescribed
updates
DR7.2 CR7, CR12 Replaceable
Interchangeable
Parts The
WRS
shall
utilize
commercially
available
hardware
to
prevent
obsolescence
DR12.1 CR12, CR18 Mechanically
&
Electrically
Separable The
WRS
shall
incorporate
reusable
connections
between
components
DR21.2 CR21 Utilize
Recyclable
Material The
WRS
shall
adhere
to
environmental
sustainment
regulations
WRS Derived Requirements

_____________________________________________________________________________
~ 2 8 ~

_____________________________________________________________________________
~ 2 9 ~
Figure 9.2 Functional Tree Diagram
9.2 Appendix
II
Requirements
Analysis

Table 9-4 WRS evaluation criteria matrix
Wire Routing System
1 Utility
2 Operation
3 Sustainment
1.1 Receive Power
1.1.1 Convert Power
1.1.2 Surge Protect
1.1.3 Ground Power
1.1.4 Distribute Power
1.2 Ventilate
Components
1.2.1 Cool Electronics
1.2.2 Remove Exhaust/
Particulate
2.1 Receive Input
2.1.1 Receive Wire Path
Design
2.1.1.1 Translate Design
to Route
2.1.2 Receive Wire
2.1.3 Receive Start/
Stop
2.2 Route Wire
2.2.1 Navigate Wire in
3D Space
2.2.3 Support Routed
Wire
2.2.2 Deploy Wire
2.2.1.1 Deliver Wire
along path
2.2.1.2 Allow for
Grouping
2.3 Produce Output
3.1 Maintainable
Functionality
3.1.1 Capable of
Receiving Service
3.1.2 Capable of
Receiving Repairs
3.1.2.1 Replaceable
Interchangeable Parts
3.1.1.1 Calibration
Capable
3.1.1.2 Capable of
Receiving Lubricant
3.1.1.3 Programmable
Software
3.2 Transportable
Components
3.2.1 Decomposable
Modules
3.2.1.1 Mechanically &
Electrically Separable
3.3 Environmentally
Friendly
3.3.1 Utilize Recyclable
Material
3.3.2 Use Reusable
Parts
2.3.1 Communicate
Messages
2.3.2 Accommodate
Removal of Wire
2.3.3 Remove Debris/
Waste
2.1.3.1 Activate Device
2.1.3.2 Deactivate
Device

_____________________________________________________________________________
~ 3 0 ~
Table 9-5 WRS requirements prioritization matrix
Evaluation
Criteria
Options
Increase
Accuracy /
Repeatability
Simplify User
Operation
Increase
Reliability
Lower
Operating
Cost
Use Existing
Technology
Total across
rows
% Grand total
A. Powered by local utilities [20] 0.0128 0.0012 0.0237 0.0160 0.0062 0.0599 0.0627
B. Provide hazard protection [10] 0.0063 0.0038 0.0138 0.0184 0.0029 0.0451 0.0473
C. Provide routed wire to operator [2] 0.0165 0.0150 0.0033 0.0229 0.0051 0.0628 0.0658
D. System is Transportable [18] 0.0059 0.0044 0.0088 0.0031 0.0025 0.0247 0.0259
E. Maintainable components [7] 0.0465 0.0078 0.0442 0.0117 0.0063 0.1166 0.1221
F. Receive operator inputs[1] 0.0065 0.0072 0.0135 0.0083 0.0041 0.0397 0.0416
G. Receive wire route path from operator [3] 0.0349 0.0177 0.0079 0.0265 0.0081 0.0951 0.0996
H. User Interface [4] 0.0167 0.0221 0.0262 0.0407 0.0155 0.1211 0.1269
I. Provides status to operator [9] 0.0159 0.0152 0.0279 0.0158 0.0039 0.0787 0.0824
J. Uses commercial software [16] 0.0076 0.0027 0.0100 0.0122 0.0266 0.0592 0.0620
K. Route wire within design specifications [22] 0.0930 0.0012 0.0118 0.0049 0.0041 0.1150 0.1205
L. Wires can be grouped [13] 0.0408 0.0091 0.0026 0.0279 0.0018 0.0822 0.0861
M. Manages waste [19] 0.0074 0.0073 0.0027 0.0279 0.0093 0.0546 0.0572
Column Total 0.3109 0.1146 0.1964 0.2364 0.0965 0.9548 1.0000

_____________________________________________________________________________
~ 3 1 ~
9.3 Appendix
III
Architecture

Figure 9.3 Interrelationship Digraph

_____________________________________________________________________________
~ 3 2 ~
Figure 9.4 Hatley–Pirbhai modeling

_____________________________________________________________________________
~ 3 3 ~
9.4 Appendix
IV
V
&
V

Table 9-6 Four (4) Phase Test Plan
Phase Description Strategy/Approach Scope
1
Individual Component
Testing/ Firmware AoA
Research & Sample, Compare
configurations of hardware components of
various programming languages
Requirements Design Development(RDD) Behavior model,
Default Behavior, Code hours Estimation Determine the
capabilities limitations of available options for Phase 2 & 3
selections
2
Subsystem Level
Hardware integration
testing
Build subsystems based on the Phase 1
recommendations
Interoperability of firm/middleware and PLCs, Ensure that
the pieces work well in the suggested arrangement and
determine alternatives where necessary, Firmware
teardown
3
Subsystem Level
Software integration
testing Define boundaries and error states
Interoperability of firm/middleware and software, RDD Test
In Process Review(does the code match the expected
behavior model, bug fix, Rigorous code walkthrough,
Ensure that the programs work well in the suggested
arrangement and determine alternatives where necessary
4 Prototype Test
Final Validation/ Rework as needed per
customer input
Integrate Phase 2&3 subsystems and Identify
Deficiencies/The pieces fit together-do they work together
4.1
Mechanical Interface/
Interference Tests
Interface Analysis & Testing,
Structural Testing Verify mechanical interfaces do not become interferences
4.2 Operational Testing
Fault Failure Insertion, Functional (black box)
testing
when an error is encountered/produced does the system
react as intended unforeseen errors/reactions?
4.3 Quality testing Top-Down Testing, Fatigue Testing
Real world simulations, Routed wire tolerance and
repetition
4.4 Rework Bottom-Up Testing Apply Necessary Corrections
4.5 Retest Restart Phase 4
5 Future Integrations Add on features & software updates Beyond the 2yr scope of Baseline Model development

_____________________________________________________________________________
~ 3 4 ~
Table 9-7 Review Gate Table
PHASE ENTRY GATE SCOPE PHASE EXIT GATE SCOPE
Review Gate 1.1
Determine if we are ready to begin
component procurement and testing Review Gate 1.2
Determine that previous phase was successful and
completed to allow project to move forward,
STAKEHOLDER INPUT REQUIRED
Review Gate 2.1
component integration and testing Review Gate 2.2
completed to allow project to move forward
Review Gate 3.1
system integration and testing Review Gate 3.2
completed to allow project to move forward,
Review Gate 4.1
system operational testing
Review Gate 4.2
Determine that mechanical
subsystems are appropriate
Review Gate 4.3
Determine that mechanical
subsystems are properly limited by
operatin system
Review Gate 4.4
Determine that software controls are
properly limited, hardware properly
monitored Review Gate 4.5
Determine complete or repeat,
Review Gate 4.6
Determine the scope and objective of
necessary rework
Review Gate 4.7 Determine success of rework Review Gate 4.1a Refer to Review Gate 4.1

_____________________________________________________________________________
~ 3 5 ~
Table 9-8 Validation Matrix
TRACE
ID
TEST
PLAN

Decomposed

Function

Customer

Requirement

Derived

Requirement

Phase
1

Phase
2

Phase
3

Phase
4

1

✓ ✓
1.1

✓ ✓
1.1.1
CR22
DR22.1
✓
1.1.2
CR17,
CR9,
CR11

✓
1.1.3
CR16,
CR11

✓
1.1.4
CR22
DR22.2
✓ ✓ ✓
1.2

✓ ✓
1.2.1
CR22
DR22.3
✓ ✓ ✓
1.2.2
CR21
DR21.1
✓ ✓
2

✓
2.1

✓ ✓
2.1.1
CR3

✓
2.1.1.1
CR6
DR14.1
✓
2.1.2
CR4,
CR24
DR.8.1
✓ ✓ ✓
2.1.3
CR1

✓ ✓
2.1.3.1
CR1

✓
2.1.3.2
CR1,
CR9

✓
2.2

✓ ✓
2.2.13
CR8,
CR14

✓ ✓ ✓
2.2.1.1
CR15,
CR14

✓
2.2.1.2
CR15

✓
2.2.2
CR8
DR8.2
✓ ✓
2.2.3
CR14,
CR15
DR8.3
✓ ✓
2.3

✓
2.3.1
CR4,
CR5,
CR10

✓
2.3.2
CR2

✓ ✓
2.3.3
CR21,
CR13

✓ ✓
3

✓
3.1

✓
3.1.1
CR7

✓
3.1.1.1
CR20,
CR7

✓ ✓
3.1.1.2
CR7
DR7.1
✓ ✓
3.1.1.3
CR7,
CR19
DR19.1
✓ ✓ ✓
3.1.2
CR7

✓ ✓
3.1.2.1
CR7,
CR12
DR7.2
✓ ✓
3.2

✓
3.2.1
CR12,
CR18

✓ ✓
3.2.1.1
CR12,
CR18
DR12.1
✓
3.3

✓
3.3.1
CR21
DR21.2
✓
3.3.2
CR21
DR21.3
✓ ✓

_____________________________________________________________________________
~ 3 6 ~
Table 9-9 Compliance Matrix
Requirement
Source
Category
Verification
Method

Verification
Status

(NV
=
not
verified,

V
=
verified)

Acceptance
Criteria

Customer
Requirement

Source

Functional

Identifier

Derived

Requirement

Identifier

Customer

Requirement

Identifier

NFPA
70B;
OSHA
29
CFR

1910.
269;
IEEE
67-‐1990
Utilities

Test,
Inspection
NV

per
NFPA,
OSHA,
IEEE

criteria
D2.UTILITY.KL.01
1.1.1
DR22.1
CR22

NFPA
70.285;
OSHA
29
CFR

1910.269;
IEEE
1-‐1986
Utilities

Test,
Inspection
NV

per
NFPA,
OSHA,
IEEE

criteria
D2.UTILITY.KL.06
1.1.2
DR22.2
CR16

NFPA
99;
OSHA
29
CFR

1910.269;
IEEE
32-‐1972
Utilities

Inspection
NV

per
NFPA,
OSHA

criteria
D2.UTILITY.KL.07
1.1.3
DR22.2
CR17

OSHA
1910.335
Utilities

Test,
Inspection
NV
per
OSHA
criteria
D2.SYSTEM.TD.06
1.1.4
DR22.2
CR12

IEEE
389-‐1996
Operations
Calculation,
Test
NV
per
IEEE
criteria
D2.UTILITY.KL.01
1.2.1
DR22.3
CR22

OSHA
1926.416
Operations

Analyses,
Test,

Inspection
NV

As
stated
in

requirement
text
D2.SYSTEM.TD.01
1.2.2
NA
CR11

Stakeholder
Defined
Operations
Calculation,
Test
NV

As
stated
in

requirement
text
D2.SYSTEM.TD.11
2.1.1
DR14.1
CR6

OSHA
1910.307
Operations

Design
Review
of

calculations,
Test
NV

As
stated
in

requirement
text
D2.SYSTEM.TD.15
2.1.2
NA
CR10

Stakeholder
Defined
Operations

Design
Review
of

calculations,
Test
NV

Calculation
specifies

Req
2.1.2
as
input

D2.WIRE.CV.03

D2.WIRE.CV.06
2.2.1
DR8.3

CR14

CR15

Stakeholder
Defined

Operations
Design
Review,
Test
NV

As
stated
in

requirement
text
Req.
D2.SYSTEM.TD.15
2.3.1
NA
CR10

Stakeholder
Defined

Operations
Analyses,
Test
NV

As
stated
in

requirement
text
Req.
D2.
OPERATOR.BD.04.1
2.3.2
DR21.1
CR2

EPA
NESHAP
Operations
Inspection
NV
per
NESHAP
criteria
Req.
D2.UTILITY.KL.05
2.3.3
DR21.2
CR21

NFPA
80
Sustainment
Test,
Inspection

NV
per
NFPA
criteria

Req.
D2.LIFE.AS.05.1
3.2.1
DR12.1
CR18

_____________________________________________________________________________
~ 3 7 ~
Table 9- 10 WRS
Traceability
Functional Decomposition
Original Customer
Requirement
Derived
Requirements
1.1.1 Convert Power CR22 DR22.1
1.1.2 Surge Protect CR17, CR9, CR11
1.1.3 Ground Power CR16, CR11
1.1.4 Distribute Power CR22 DR22.2
1.2.1 Cool Electronics CR22 DR22.3
1.2.2 Remove Exhaust/Particulate CR21 DR21.1
2.1.1 Receive Wire Path Design CR3
2.1.1.1 Translate Design to Route CR6 DR14.1
2.1.2 Receive Wire CR8 DR.8.1
2.1.3 Receive Start/Stop CR1
2.1.3.1 Activate Device CR1
2.1.3.2 Deactivate Device CR1, CR9
2.2.1 Navigate Wire in 3D Space CR8, CR14
2.2.1.1 Deliver Wire along path CR15, CR14
2.2.1.2 Allow for Grouping CR15
2.2.3 Support Routed Wire CR8 DR8.2
2.2.2 Deploy Wire CR14, CR15 DR8.3
2.3.1 Communicate Messages CR4, CR5, CR10
2.3.2 Accommodate Removal of Wire CR2
2.3.3 Remove Debris/Waste CR21, CR13
3.1.1 Capable of Receiving Service CR7
3.1.1.1 Calibration Capable CR20, CR7
3.1.1.2 Capable of Receiving Lubricant CR7 DR7.1
3.1.1.3 Programmable Software CR7, CR19 DR19.1
3.1.2 Capable of Receiving Repairs CR7
3.1.2.1 Replaceable Interchangeable Parts CR7, CR12 DR7.2
3.2.1 Decomposable Modules CR12, CR18
3.2.1.1 Mechanically & Electrically Separable CR12, CR18 DR12.1
3.3.1 Utilize Recyclable Material CR21 DR21.2
3.3.2 Use Reusable Parts CR21 DR21.3
1.2 Ventilate Components
1.1 Receive Power
1 Utility
Wire Routing System Requirements Traceability
3.3 Environmentally Friendly
3.2 Transportable Components
3.1 Maintainable Functionality
3 Sustainment
2.3 Produce Output
2.2 Route Wire
2.1 Receive Input
2 Operation

_____________________________________________________________________________
~ 3 8 ~
9.5 Appendix
V
Market
Research

Table 9-11 Technology Impact Matrices
Receive
Wire
Path
Design
TIM

Ref
2.1.1

Technology

MOE

%
Relative

Importance
Weight

Wired
Network
USB
2.0/3.0
Cloud
Based
Totals

Accuracy/Repeatability
0.31
6
9
6
21

Simplified
User
Operation
0.1
9
9
6
27

Increased
Reliability
0.2
9
6
3
21

Low
Operating
Cost

0.28
9
9
6
3

Technology
Readiness
Level
0.11
9
9
9
27

Weighted
Sums
8.07
8.4
5.73
22.2

Total
Percent
Weight
36%
38%
26%
100%

Receive
Wire
TIM

Ref
2.1.2

Technology

MOE

%
Relative

Importance
Weight

Gear
Wheel

Straightener

Bearing
Wheel

Straightener

Conveyorless
Crank
Wheel
Totals

0.31
9
9
6
3
27

Simplified
User
Operation
0.1
9
9
9
3
30

Increased
Reliability
0.2
9
9
6
1
25

Low
Operating
Cost

0.28
7
6
9
1
23

Technology
Readiness
Level
0.11
9
9
9
9
36

Weighted
Sums
8.44
8.16
7.77
2.9
27.27

Total
Percent
Weight
31%
30%
28%
11%
100%

Route
Wire
TIM

Ref
2.2

Technology

MOE

%
Relative

Importance
Weight

Belt
Driven

Linear
Ball
Slide

Manual
Peg

Board

Totals

0.31
6
9
3
18

Simplified
User
Operation
0.1
6
6
1
13

Increased
Reliability
0.2
6
6
1
13

Low
Operating
Cost

0.28
9
9
1
19

Technology
Readiness
Level
0.11
9
9
9
27

Weighted
Sums
7.17
8.1
2.5
17.77

Total
Percent
Weight
40%
46%
14%
100%

Receive
Input
TIM

Ref
2.1

Technology

MOE

%
Relative

Importance
Weight

Form
Based

Capacitive
Touch
HMI
Command
Line
WIMP/GUI
Totals

0.31
9
6
9
6
30

Simplified
User
Operation
0.1
9
3
1
9
22

Increased
Reliability
0.2
9
1
9
9
28

Low
Operating
Cost

0.28
3
9
1
6
19

Technology
Readiness
Level
0.11
9
3
9
6
27

Weighted
Sums
7.32
5.21
5.96
6.9
25.39

Total
Percent
Weight
29%
21%
23%
27%
100%

Accommodate
Removal
of
Wire
TIM

Ref
2.3.2

Technology

MOE

%
Relative

Importance
Weight

Operator
Based

Modular
Equipment

Mechatronics
Totals

0.31
3
9
12

Simplified
User
Operation
0.1
6
9
15

Increased
Reliability
0.2
6
6
12

Low
Operating
Cost

0.28
1
9
10

Technology
Readiness
Level
0.11
9
6
15

Weighted
Sums
3.34
8.07
11.41

Total
Percent
Weight
29%
71%
100%

_____________________________________________________________________________
~ 3 9 ~
Table 9-12 Technology Options
Ref.
1.1
Technology
Options

Ref.
1.1
Power
Supply
Technology

Technology
Attribute
Induction
Motor
Brushless
Motor

Brushed
Universal

Motor

Natural
Gas
Solar

Standard
US

Electrical
Receptacle

Control
Requirement
Optional
Always

Optional
Always
Always
None

Typical
Drive
AC
DC
DC
N/A
N/A
AC

Maintenance
None

None
Periodic
Periodic
Periodic
None

Efficiency

High
High
Moderate
High
High
Moderate

Manual

Activation/Deactivation

Yes
Yes
Yes
Yes
Yes
Yes

Power
Factor
Low/Moderate
(0.5-‐0.95)
N/A
Moderate
(0.94)
N/A
N/A
Moderate
(0.9)

High
High
High
High
Varies
Moderate/High

Simplified
User
Operation
Yes
Yes
Yes
Yes
Yes
Yes

Reliability
High
Moderate/High
High
Moderate/High
Varies
Varies

Cost

Low
High
Moderate

Low
High
Low

Existing
Technology
Yes
Yes
Yes
Developing
Developing
Yes

Technology
Readiness
Level
9
9
9
3
5
9

Ref.
1.2.2
Technology
Options

Ref.
1.2.2
Remove
Exhaust/Particulate
Technology

Technology
Attribute

Self
Dumping
Hopper
Manual
Ventilation
Exhaust

Effectiveness
Moderate/High
Low
High

Automated
Wire
Cutting
Varies
None
Varies

Maintenance
Moderate
High
Moderate

Conveyor
Belt
Specific
Varies
No
Varies

Low
Low
High

Simplified
User
Operation
Low
Low
High

Reliability
Low
Low
High

Cost

Moderate/High
Low
Moderate/High

Existing
Technology
Yes
Yes
Yes

Technology
Readiness
Level
9
6
9

Ref.
2.1.1.1
Technology
Options

Ref.
2.1.1.1
Translate
Design
to
Route
Technology

Technology
Attribute
SolidWORKS
Rhino
Pro/Engineer
LeapMotion

Commercial-‐Off-‐The-‐Shelf
Yes
Yes
Yes
Yes

3D
Capable
Yes
Yes
Yes
Yes

Augmented
Reality
Capable
No
No
No
Yes

Maintenance
Low
Low
Low
Moderate

High
High
High
Low/Moderate

Simplified
User
Operation
Low
Low
Low/Moderate
Low/Moderate

Reliability
High
High
High
Low/Moderate

Cost

High
High
High
High

Existing
Technology
Yes
Yes
Yes
Developing

Technology
Readiness
Level
9
9
9
3

_____________________________________________________________________________
~ 4 0 ~
Figure 9.5 Work Breakdown Structure
W2 Sys
Engineering
W2.2
Personnel
W2.2.1 Team
Lead
W2.2.2
Electrical Lead
W2.2.3
Mechanical
Lead
W2.2.4
Software Lead
W2.2.5 Drafter
W2.3 Research
& Development
W2.3.1Technol
ogy
W2.3.2
Procurement
W1 Project
Mgmt
W1.1
Personnel
W1.1.1 Project
Manager
W1.1.2
Financial
Planner
W1.1.3
Procurement
Manager
W1.1.4 Vendor
Oversight
W1.2 Facilities
W1.2.1
Property
W1.2.2
Equipment
W3 Interface
Systems
W3.1
Development
W3.2 Testing
of Software
Module
W3.2.1 Unit
Hardware Test
W3.2.2
Integration
W3.2.3 System
Test
W4 Control
System
W4.1 Control
Theory
Analysis
W4.2 Process
Control Software
Development
W4.2.1
Algorithm
Development
W4.2.2
Process
evaluation
W6
Management
Reserve
W6.1 Risk
mitigation
funding
W6.1.1 Quality
risk
W6.1.2 Cost
risk
W6.1.3
Schedule risk
W7 Assembly
and Test
W7.1 Facility
W7.1.1
Development of
facility requirements
W7.1.2 Facility
design
W7.1.3 Modify/
build to design
W7.2
Assembly and
test equipment
W7.2.1
Standard tools
W7.2.2
Specialty tools
W7.3
Assembly and
test personnel
W7.3.1 Internal
(WRS
personnel)
W7.3.2 External
(component
supplier SMEs)
W8
Sustainment
W8.1 Develop
maintenance
manuals
W8.1.1 Recommended
maintenance schedules
W8.1.2
Maintenance
procedures
W8.2 Develop
repair manuals
W8.2.1 Recommended
spare parts list and
quantities
W8.2.2 Repair
procedures
W8.3 Develop
training
curriculum
W8.3.1 Initial live
skills training and
certification
W8.3.2 Refresher
training and
recertification
W8.4
Sustainment
team
W8.4.1 Update
manuals
W8.4.2 Ensure
availability of
parts
W8.4.3 Update
training
W5 Mechanical
System
W5.1 Design
hardware
components
W5.1.1 Wire
deposit
hardware
W5.1.2 Wire
capture
hardware
W5.1.3 Wire
handling
hardware
W5.1.4 Utility
hardware
W5.1.6 Build
hardware
components
W5.1.7 Wire
deposit
hardware
W5.1.8 Wire
capture
hardware
W5.1.9 Wire
handling
hardware
W5.1.10 Utility
hardware
W5.2 V&V
W5.2.1 Design
V&V
W5.2.2 Build
V&V
W5.3
Component
Integration
W5.3.1 Design
of integration
points
W5.3.2
Interface
W5.3.3 Control
W5.3.4
Mechanical
W5.3.5
Subcontract/
vendor systems
W5.4
Coordination of
integration design
W5.4.1 Internal
coordination
W5.4.2
External
coordination
W1 Project
Mgmt
W2 Sys
Engineering
W3 Interface
Systems
W4 Control
System
W5 Mechanical
System
W6
Management
Reserve
W7 Assembly
and Test
W8
Sustainment
W1.1
Personnel
W1.1.1 Project
Manager
W1.1.2
Financial
Planner
W1.1.3
Procurement
Manager
W1.1.4 Vendor
Oversight
W1.2 Facilities
W1.2.1
Property
W1.2.2
Equipment
W2.2
Personnel
W2.2.1 Team
Lead
W2.2.2
Electrical Lead
W2.2.3
Mechanical
Lead
W2.2.4
Software Lead
W2.2.5 Drafter
W2.3 Research
& Development
W2.3.1Technol
ogy
W2.3.2
Procurement
W3.1
Development
W3.2 Testing
of Software
Module
W3.2.1 Unit
Hardware Test
W3.2.2
Integration
W3.2.3 System
Test
W4.1 Control
Theory
Analysis
W4.2 Process
Control Software
Development
W4.2.1
Algorithm
Development
W4.2.2
Process
evaluation
W5.1 Design
hardware
components
W5.1.1 Wire
deposit
hardware
W5.1.2 Wire
capture
hardware
W5.1.3 Wire
handling
hardware
W5.1.4 Utility
hardware
W5.1.6 Build
hardware
components
W5.1.7 Wire
deposit
hardware
W5.1.8 Wire
capture
hardware
W5.1.9 Wire
handling
hardware
W5.1.10 Utility
hardware
W5.2 V&V
W5.2.1 Design
V&V
W5.2.2 Build
V&V
W5.3
Component
Integration
W5.3.1 Design
of integration
points
W5.3.2
Interface
W5.3.3 Control
W5.3.4
Mechanical
W5.3.5
Subcontract/
vendor systems
W5.4
Coordination of
integration design
W5.4.1 Internal
coordination
W5.4.2
External
coordination
W6.1 Risk
mitigation
funding
W6.1.1 Quality
risk
W6.1.2 Cost
risk
W6.1.3
Schedule risk
W7.1 Facility
W7.1.1
Development of
facility requirements
W7.1.2 Facility
design
W7.1.3 Modify/
build to design
W7.2
Assembly and
test equipment
W7.2.1
Standard tools
W7.2.2
Specialty tools
W7.3
Assembly and
test personnel
W7.3.1 Internal
(WRS
personnel)
W7.3.2 External
(component
supplier SMEs)
W8.1 Develop
maintenance
manuals
W8.1.1 Recommended
maintenance schedules
W8.1.2
Maintenance
procedures
W8.2 Develop
repair manuals
W8.2.1 Recommended
spare parts list and
quantities
W8.2.2 Repair
procedures
W8.3 Develop
training
curriculum
W8.3.1 Initial live
skills training and
certification
W8.3.2 Refresher
training and
recertification
W8.4
Sustainment
team
W8.4.1 Update
manuals
W8.4.2 Ensure
availability of
parts
W8.4.3 Update
training
WRS

Wire Routing System

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Wire Routing System

Similar to Wire Routing System (20)

More from Sachin Mehta

More from Sachin Mehta (17)

Recently uploaded

Recently uploaded (20)

Wire Routing System