The Defense Logistics Services Center (DLSC) supports defense
system procurement via assigning, tracking, and retiring National
Stock Numbers (NSNs) for all equipment used by the Department
of Defense (DoD). DLSC maintains a database, the Federal Logistics
Information System (FLIS), relating each NSN to information about
the appropriate item. The assignment of a single NSN prevents
duplication and unnecessary stock and storage of items. However,
there is more to the system than NSNs. The FLIS contains information
including item names, characteristics information, interchangeability
and substitutability data, hazardous material disposal codes,
demilitarization data, unit pricing, manufacturer's part numbers,
and much more. DLSC supports all logistics functions of the DoD,
other Government agencies and foreign governments through the
collection, processing, storage and dissemination of this data.
DLSC uses the FLIS as the primary means to organize and maintain
information from the Federal Catalog System. The NSNs are assigned
by DLSC at Battle Creek, Michigan based on requests from the armed
services branch using the item.
The request for NSNs often comes from Military Service Type Designation
organizations such as the U.S. Army's Central Electronics Command
(CECOM) and the Air Force Material Command (AFMC). Each of these
organizations have a system (a Military Service Type Designation
System or MSTDS) of standards for naming and codifying equipment
according to a type designation which specifies the installation,
equipment type, and purpose of the item. A type designation is
assigned for each item used by the U.S. Military Services. The
request for an NSN assignment to DLSC comes after the type designation
has been assigned.
DLSC, CECOM and AFMC share some common information such as type
designation, drawing number and part number. Although this is
a duplication of information, at present contractors and Government
personnel often have to work with all these organizations to find
information relevant to systems or equipment they are provisioning,
developing, modifying, repairing, etc. In fact, if the inquirer
does not know the exact organization involved with the equipment
then relevant information will be missed altogether. These conditions
exist because there is no direct connectivity between the various
MSTDSs and between the MSTDSs and DLSC. Each exists as an independent
system with only loose, and usually manual, ties to the others.
According to DLSC this lack of connectivity is a contributing
factor in the duplication of acquisition and logistics efforts,
inability to find parts in inventories, duplicate parts in inventories,
and other logistics management issues.
In order to address this lack of connectivity DLSC has proposed
that an automated system be established, the DLSC Information
Hub, which will allow access to parts information in the FLIS
and MSTDSs through a single user interface (see Figure 1.1-1).
This system would allow a user to enter certain key information
(e.g., a part number or type designation) and discover which systems
had information on a part and what the information is. Thus,
all information on a part would be available to a DLSC user and
the problems discussed above would be alleviated.
Task 2 of the Continuous Acquisition and Life-Cycle Support
(CALS)/Integrated Data Environment (IDE) program was tasked with
assessing the client-server architecture proposed by DLSC for
the DLSC Information Hub and the capability of the existing type
designation systems at CECOM and AFMC to participate in this architecture.
While this Task was established with a fairly correct understanding
of the existing environment for the DLSC Information Hub this
was not true in regard to the CECOM and AFMC type designation
systems.
Task 2 was initiated with the understanding that CECOM and AFMC
had some type of automated type designation system in place. Unfortunately
we found that neither CECOM nor AFMC have automated MSTDS. No
complete computer resident database or computer-readable database
exists. CECOM and AFMC each keep a small dBase III database for
tracking DD Form 61 (DD61) requests as they come in.
DD Form 61 is the standard form which must be submitted
to an MSTDS for type designation. The two databases share only
a few common data fields, contain only a small subset of DD61
data, contain much data not on DD61s, and have only been in use
for a few years.
Beside this tracking database, CECOM has no automation for their
system. AFMC, however, uses a Canonfile 250 image scanner to
scan and store DD61s to optical disks. These disks can then be
read by a Canon Diskfile Drive 5001S with CFView software for
viewing and manipulating the DD61's image on any IBM compatible
PC. AFMC has used this equipment since 1987 for all DD61s. As
a courtesy they have provided Canonfile disk copies to CECOM
for the DD61s that are sent from the USAF to CECOM for processing.
Beyond this use of the Canonfile equipment and the tracking database
there is no automation of the type designation process.
The result of our analysis of CECOM and AFMC was to determine
"the degree which the CECOM and AFMC type designation systems
need to be augmented" in order to participate in the DLSC
client-server architecture. Unfortunately we have discovered
that the "degree of augmentation needed" could be summarized
as follows:
No automated MSTDS systems exists at CECOM or AFMC which can take
advantage of the proposed DLSC architecture. Thus, there is currently
nothing to augment. Before CECOM or AFMC can participate in
the DLSC hub concept, their MSTDS must be automated.
Building these systems was not envisioned when the present contract
was undertaken. However, after all parties understood the real
state of the CECOM and AFMC systems we agreed to undertake an
effort to work with CECOM and AFMC to develop the necessary automated
systems. This work is beyond the original scope of the contract,
but meets the real needs of the DoD CALS community, CECOM, and
AFMC. Further detail on our analysis of the environment at CECOM
and AFMC appear in Section 2, CECOM and AFMC. A brief
description of what we are currently doing and what we intend
to do to resolve this lack of automation is explained in Section
4 of this report, Direction.
Section 3, DLSC Information Hub, reviews our analysis of
this system. Before getting into the detailed analysis sections
we present a brief overview of the current state of the DLSC Information
Hub.
At this time DLSC, working with various contractors, is developing
a proof-of-concept prototype, the Type Designator/Federal Logistics
Information System Interface (TD/FLIS), not a working fielded
system. The TD/FLIS prototype will provide a query only capability
against the FLIS and CECOM and AFMC type designation databases.
This prototype is only meant to prove the feasibility of connecting
these databases in order to allow meaningful retrieval of system
and item data from FLIS and MSTDSs. The prototype cannot be used
in this initial form to support actual acquisition and logistics
activities.
Users enter a query via a Graphical User Interface (GUI). A user
at a client workstation enters one or more parameters related
to FLIS or codified equipment The query is sent to the DLSC hub
and from there to FLIS and the MSTDSs. Relevant data in all the
databases matching the query parameters is then returned to the
user and formatted by the hub for presentation via the GUI. The
user can then use certain responses to "drill down"
into the data by choosing only certain rows of data on the response
screen and launching a new query. More detailed information will
then be retrieved. For this prototype no more than 100 rows of
data can be returned for any query.
These capabilities will enable a user to easily retrieve data
on a item of interest to the user and discover which entity, FLIS
or specific MSTDS, controls that data. Thus, even if the user
does not retrieve all the data desired the user will know where
to search for more detailed information.
We now present details of our findings at CECOM and AFMC and concerning
the DLSC client-server architecture.
As previously mentioned the process for these Military Service
Type Designation Systems (MSTDSs) is almost completely manual.
The process for assigning a type designation is basically sequential
following these steps:
This is the basic process for assigning a new type designation.
A revision or cancellation has some slight modification, but
follows basically the same process.
Besides working the DD61s, CECOM and AFMC personnel must respond
to customer request for information. In some cases, especially
for DD61s which are in the process, this is a lookup in the tracking
database. However, often the request precedes a DD61 submittal.
At CECOM this then involves manually searching through forms,
microfiche and microfilm to find requested information. At AFMC
this involves searching through the Canonfile disks and, to a
much lesser extent, old paper DD61s.
Since there is no automated system in place, no network exists
specifically for the type designation systems. The existing telecommunication
and network capabilities at CECOM can, most likely, be utilized
to support the TD/FLIS prototype once a small database of DD61
data is established for purposes of testing this prototype. The
CECOM and AFMC MSTDSs may need to be connected to the Defense
Logistics Agency's (DLA) Logistic Remote User's Network (LOGRUN)
for the purposes of this prototype, but this has not yet been
firmly established. Access to LOGRUN is envisioned by DLSC as
causing no barriers.
It must be pointed out, however, that we have been unable to meet
with representatives of Information Builders Incorporated (IBI)
and thus have been unable to conclusively establish that the impact
of various Enterprise Data Access/Standard Query Language (EDA/SQL)
software in the TD/FLIS configuration will be negligible and cause
no serious network modifications (see section 3.0 for further
detail on EDA/SQL). Based on the EDA/SQL documentation provided
by IBI and separate meetings with CECOM network personnel we can
only make a preliminary assessment that the TD/FLIS prototype
can be accommodated with only minor modifications to existing
networks.
MSTDS data has been stored in many different forms of media. These include:
Present Data. Currently all requests are made via a paper
DD61 form. Data to be used for the TD/FLIS test will be extracted
from these paper forms and/or from the Canonfile optical disks
which are used by AFMC to store DD61 images. Only a small set
of data from CECOM and AFMC will be used for the TD/FLIS test;
the exact amount is To Be Determined (TBD).
Legacy Data. The legacy data is stored in all the formats
The microfiche and microfilm are not in DD61 format, do not include
some DD61 fields, and names some equivalent data elements to the
DD61 differently than the DD61. The microfilm, which appears
to cover the years 1943 to 1981, contains images of, at least,
four different forms. CECOM is attempting to read UNISYS 9 track
tapes but has been unable to do so, to this date, as the S2K format
is obsolete. There are large amounts of data in each medium (e.g.,
75,000 pages on microfiche, 85,000 paper DD61s). Much of the
data is of poor quality (e.g., CECOM estimates 30% of the microfilm
is possibly illegible).
The legacy data thus presents an enormous challenge, technically,
logically, cost-wise and time-wise. Thus, the legacy data issue
will not be addressed for the TD/FLIS prototype test. This issue
is discussed further under section 4.0 Direction.
Obviously the personnel currently working the DD61s are users
of the MSTDS. The customers who prepare and submit the DD61 are
also users. These include government contractors, program offices
and DoD control points. There are thus, potentially, thousands
of users who can make inquiries for information, fewer who can
submit the final DD61.
Some users have the potential to easily be networked to an automated
MSTDS system, others would involve a significant investment in
hardware and software.
Hardware. These are existing personal computers of FLIS
users with a minimum of the Windows 3.1 operating system.
The requirements for Random Access Memory (RAM) and hard-disk
storage for the TD/FLIS client front end on each client are TBD.
Software. The TD/FLIS client front end will consist of
a Graphical User Interface (GUI) and Enterprise Data Access/Standard
Query Language (EDA/SQL) client software package from IBI. The
GUI will be developed in Visual Basic and enable user queries
to the TD/FLIS via the EDA/SQL client software package. The
EDA/SQL client software will provide Transmission Control Protocol/Internet
Protocol (TCP/IP) network protocol support enabling access to
the hub server. All EDA/SQL software will be provided by IBI.
Hardware. This will be a Hewlett-Packard (HP) UX T-520
computer installed in Battle Creek, Michigan. The HP's TCP/IP
process will provide network access in conjunction with the hub's
EDA/SQL software.
Software. The EDA/SQL server/client engine software package
will function as the hub server software. This software will
provide network protocol support for inbound clients and outbound
user requests.
FLIS. The DLSC FLIS database is stored within an Amdahl
5995 mainframe computer in Columbus, Ohio. In order to enable
TD/FLIS the present system will be augmented with an EDA/SQL server
configured with a DB2 driver for the native FLIS Relational Database
Management System (RDBMS). The EDA/SQL software will authenticate
user access attempts, provide network protocol support and retrieve
appropriate FLIS data in response to queries.
CECOM and AFMC. Currently there are no RDBMSs for these
systems. The CECOM and AFMC type designator systems are currently
in their requirements definition phase. The results of the current
assessment and considerations of CECOM and AFMC environments,
needs and constraints will determine the appropriate hardware
for these sites. EDA/SQL Relational Gateway server software will
be necessary at each site to accommodate the TD/FLIS queries.
The DLSC hub EDA/SQL server will interface to each of the EDA/SQL
subservers at MSTDS sites. The DLSC hub server will initiate
Remote Procedure Calls (RPCs) that trigger a database Standard
Query Language (SQL) query at the these type designator systems.
Networking capabilities will be supplied via the Defense Logistics Agency's (DLA) Logistic Remote User's Network (LOGRUN). All clients must have access and authentication for LOGRUN to use TD/FLIS. The client's Local Area Network (LAN) must support TCP/IP. The FLIS is already accessible via LOGRUN. Connectivity of the type designation system databases to LOGRUN will be provided once the procurement procedure for this hardware and software are complete. At present it is envisioned that CECOM and AFMC can utilize existing physical networks to provide the physical connectivity. Any modification should be minor (e.g., additional cabling, connections, etc.). The use of EDA/SQL software at CECOM and AFMC in conjunction with existing TCP/IP use on their networks will provide the logical connectivity to LOGRUN.
Users of the prototype will come from an existing base of users
of various DLA systems (e.g., FLIS). User training will be minimal,
mostly provided by a user guide. Some developer training will
be provided, but this will be limited to a few DLSC personnel.
At present the TD/FLIS prototype is envisioned as supporting at
most fifty users and the connect time is limited (a few minutes
at most). However, typical usage is estimated at five users performing
10 queries each per day for a total of 50 queries per day.
Obviously, when Task 2 of the present contract was established
it was done so with the understanding that the task called for
integrating existing automated MSTDSs at CECOM and AFMC with the
DLSC hub. As pointed out in section 1.2.1 our analysis found
that there were no automated systems at CECOM and AFMC. Although
the work is beyond the original scope of our contract we have
agreed to undertake an effort to assist CECOM and AFMC in automating
their systems.
In order to develop these systems we have gathered detailed information
on the current environment, legacy data, needed hardware and software,
data conversion procedures, etc. Appendix A shows a questionnaire
which was developed to initiate this information gathering from
DLSC, CECOM and AFMC personnel. We also undertook an analysis
of some U.S. Navy MSTDSs which are automated to a certain degree.
The results of this analysis will be used to facilitate the development
of the CECOM and AFMC systems.
We quickly discovered that the challenges were so severe that
we could not develop automated systems in time to meet the desired
TD/FLIS testing time frame (approximately mid-March, 1997). Therefore,
it was decided to pursue development in two phases. In the first
phase we will work to develop an RDBMS containing a small subset
of DD61 data at CECOM and AFMC to meet the TD/FLIS test time frame.
The second phase, begun concurrently with the first but completed
much later, involves actual development of the automated CECOM
and AFMC automated type designation systems. There are a number
of major issues which must be resolved in this development such
as:
Appendix B shows a briefing given December 6, 1996 which
laid out and gave a high level plan for resolving these issues.
The Task 2 Plan of Action and Milestone report, being delivered
concurrently with this report, explains our current direction
in detail, expanding upon the high level plan.
With the support of our customer, DLSC, CECOM and AFMC we are
confident that our efforts in the next phase of this contract
will meet the true needs of the DoD CALS community in regard to
MSTDS and the DLSC hub concept.
In order to assess the concept of Defense Logistics Services Center
(DLSC) to Type Designation System (TDS) connectivity, we need
to understand a great deal about the proposed DLSC side of this
system. We need to understand the functionality which
the DLSC architecture enables and we need to understand the proposed
physical and software environment. We have developed a series
of questions which will help us to develop this understanding.
These questions will be used as the basis of discussions with
you when we meet.
We would like you to look over these questions and form some response
to each one. Please formulate the best answer you can at this
point. If you do not know an answer, consider if you know of
someone or some source (document, web page, etc.) that may supply
the information. We do not expect any one person to be able to
answer all of these questions. Just discovering who can best
answer which questions is one of the early goals of our assessment.
You do not have to write down answers (but you may wish to do
so for your own benefit). We will discuss them at our meeting.
Thanks for your help in this.
Functionality of DLSC Architecture
Environment of DLSC Architecture
General
Telecommunications
Users of DLSC Hub
In order to assist in automating your Type Designation System
(TDS) and assessing the concept of Defense Logistics Services
Center (DLSC) to Type Designation System connectivity we need
to understand a great deal about the Type Designation Systems
identified as sites participating in this prototype. We need
to understand the current process used at each site, the
extent to which the TDSs are automated, the current and proposed
physical environment, the data items which should be in the proposed
relational database and the amount and quality of this data.
We have developed a series of questions which will help us to
develop this understanding. These questions will be used as the
basis of discussions with you when we meet.
We would like you to look over these questions and form some response
to each one. Please formulate the best answer you can at this
point. If you do not know an answer consider if you know of someone
or some source (document, web page, etc.) that may supply the
information. We do not expect any one person to be able to answer
all of these questions. Just discovering who can best answer
which questions is one of the early goals of our assessment.
You do not have to write down answers (but you may wish to do
so for your own benefit). We will discuss them at our meeting.
Thanks for your help in this.
Existing TDS Process and Automation
If workstations are used, can you explain their configuration
(i.e., hardware, operating system, usual software installed, memory
limitations, network capability, etc.)?
Telecommunications
Data
In regard to data on DD61:
Data quality:
Users
| AFMC | Air Force Material Command |
| CALS | Continuous Acquisition and Life-Cycle Support |
| CECOM | Central Electronics Command |
| dBase III | Data Base III |
| DD61 | DD Form 61 |
| DD180 | DD Form 180 |
| DLA | Defense Logistics Agency |
| DLSC | Defense Logistics Services Center |
| DoD | Department of Defense |
| E-R | Entity Relationship |
| EDA/SQL | Enterprise Data Access/Standard Query Language |
| FLIS | Federal Logistics Information System |
| GUI | Graphical User Interface |
| HP | Hewlett-Packard |
| IBI | Information Builders Incorporated |
| IDE | Integrated Data Environment |
| IP | Internet Protocol |
| JETDS | Joint Electronics Type Designation Systems |
| LAN | Local Area Network |
| LOGRUN | Logistic Remote User's Network |
| MSTDS | Military Service Type Designation Systems |
| NSN | National Stock Number |
| PC | Personal Computer |
| RAM | Ready Access Memory |
| RDBMS | Relational Database Management System |
| RPC | Remote Procedure Calls |
| SQL | Standard Query Language |
| TBD | To Be Determined |
| TCP | Transport Control Protocol |
| TCP/IP | Transmission Control Protocol/Internet Protocol |
| TD | Type Designator |
| TDAS | Type Designation Automated System |
| TDS | Type Designation System |
| TD/FLIS | Type Designation/Federal Logistics Information System Interface |
| USAF | United States Air Force |