LIST OF FIGURES

      

      

The request for NSNs often comes from Military Service Type Designation organizations such as the U.S. Army's Communication and Electronic 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 a 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.0-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 (Contract No. DEAM21-96-MC32239) 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. Task 2 was initiated with the understanding that CECOM and AFMC had some type of automated type designation system in place. Unfortunately it was 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 requests as they come in. DD Form 61 is the standard form that 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 DD Form 61 data, contain much data not on DD Form 61s, 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 DD Form 61s to optical disks. These disks can then be read by a Canon Diskfile Drive 5001S with CFView software for viewing and manipulating the DD Form 61's image on any IBM compatible PC. AFMC has used this equipment since 1987 for all DD Form 61s. As a courtesy they have provided Canonfile disk copies to CECOM for the DD Form 61s that are sent from the United States Air Force (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. Further detail on the analysis of the environment at CECOM and AFMC appear in the report "Preliminary Military Type Designator Systems Assessment for the DOD CALS IDE Project" January 1997, Contract Data Requirements List (CDRL) Sequence Numbers A005.

The result of an 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, it was discovered that the "degree of augmentation needed" could be summarized as follows:

Building these systems was not envisioned when the contract was undertaken. However, after all parties understood the real state of the CECOM and AFMC systems, it was agreed to undertake an effort to work with CECOM and AFMC to develop the necessary automated systems. This work is beyond the or iginal scope of the contract, but meets the real needs of the DoD CALS community, CECOM, and AFMC.

In order that all parties understand the proposed automated system to be built for CECOM and AFMC this non-CDRL document will explain the Concept of Operations (CONOPS) for a Type Designation Automated System (TDAS) to be developed. Since the challenges faced by MSTDS personnel at CECOM and their users are greater, the TDAS system will first be developed for and deployed at CECOM. Close contact is being continued with AFMC so that the resultant TDAS will also meet the needs of AFMC without substantial modification.

1.1  Layout of This Document

This document is laid out in the following manner. Section 2 describes the current process and how an automated system can overcome inefficiencies in this process. The objective, requirements, scope, constraints and assumptions, as well as concept of operations are described in Section 3. A series of operational scenarios of TDAS are discussed in Section 4. Section 5 analyzes the TDAS and summarizes advantages and disadvantages. Finally, several issues regarding the implementation are addressed in Section 6; and a brief discussion of the DLSC Information Hub is included in Section 7.

      

1. Customer prepares and mails DD Form 61(s) to MSTDS. The customer may mail one or a group of DD Form 61s. The latter occurs when a system with new parts is being nomenclatured.
2. MSTDS personnel receive DD Form 61(s) and quickly screen it/them for apparent errors (such as the source request number missing) and correct number of copies. DD Form 61s may be rejected and sent back to the customer at this point, if errors are severe.
3. Tracking data (e.g., date received, source request number) is entered into the dBase III tracking database.
4. The paper DD Form 61 is either stored in a file cabinet for later working (CECOM) or scanned into the Canonfile 250 (AFMC).
5. DD Form 61s are retrieved for working according to the oldest date received and a further validation of data is begun by the MSTDS personnel.
6. If there are minor errors then the customer responsible for the DD Form 61 is contacted, problems are resolved, and the process continues. If there are severe errors, the DD Form 61 is sent back to the customer with an error report explaining what needs to be corrected.
7. If the customer is requesting a new item name, the MSTDS personnel prepares and sends a DD Form 180 (DD180) to request a new item name from DLSC. The process continues only when the MSTDS receives the new item name assignment from DLSC.
8. The MSTDS personnel verifies that all necessary data is present, in correct format and there are no conflicting data fields (e.g., if the request is to assign a modification there must be some indication of the degree of interchangeability between this and present models).
9. The MSTDS personnel retrieves a ledger book that shows all nomenclatures ever assigned at the MSTDS.
10. The appropriate page is found for the requested item and the next nomenclature in the sequence is assigned on the original DD Form 61.
11. The ledger is updated to reflect the new nomenclature.
12. The DD Form 61 is sent to supervisory personnel for signatures. This action is largely perfunctory and is being removed.
13. A cover letter is prepared for the DD Form 61.
14. Copies are made of the letter and the completed DD Form 61. These are then sent to the customer and appropriate agencies in the Army or USAF and to DLSC.
15. The tracking database is updated with information such as completion date and final nomenclature.
16. The original DD Form 61(s) and cover letter(s) are filed.

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 DD Form 61s, CECOM and AFMC personnel must respond to customer requests for information. In some cases, especially for DD Form 61s that are in the process, this is a lookup in the tracking database. However, often the request precedes a DD Form 61 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.

2.1  Overcoming Inefficiencies in the Current Process

Obviously a manual process such as described above has many inefficiencies which can be improved by an automated system. First, there is the storage of the data. At present CECOM data is simply stored as the actual paper DD Form 61s submitted. AFMC stores the DD Form 61s as Canonfile images. There is also some redundancy in that some data is kept on the dBase III tracking file and some in the ledger books. The paper and ledger books use substantially more storage space then an automated system. Storing into this media at present means that someone must manually take the DD Form 61 copies and place them, in the appropriate location, in a file cabinet. In the case of the ledger books someone must write in the correct subset of data. A single automated system would remove the redundancy, reduce storage space, reduce the time to place into storage and reduce the possibility of human errors in entering handwritten data.

Legacy data is currently stored in five media: paper DD Form 61s, Canonfile images, microfiche, microfilm, and UNISYS tape reels in System 2000 (S2K) format. Some of the data in the same media is in different formats. This storage obviously takes up more space and is more difficult to manage than an automated system.

A second and related issue is that of the retrieval of data. At present when CECOM receives a request for data they must manually search for it. Even at AFMC, search is not completely automated, for they must manually search through the images. After a search CECOM or AFMC mails the customer copies of the data, often many more DD Form 61s or other media copies than the customer needs. The customer must then search through the paper copies to find the data elements needed. Using an automated system, the customer will be able to directly query and retrieve only the data elements needed and in a much shorter time (minutes instead of days).

A third issue is the use of the mail to submit DD Form 61s, send rejection notices, and notify completion to the customer and appropriate agencies. This adds many days, possibly weeks in the case of a rejected and resubmitted DD Form 61, to the process. With an automated system the customer can submit the DD Form 61 as soon as it is completed and it is immediately received at the MSTDS. Furthermore, the customer can be immediately notified if the MSTDS finds an error and can resubmit as soon as the error is corrected. The customer and appropriate agencies can be notified immediately upon completion of a DD Form 61. Thus, automated submittal, rejection, and acceptance notification should greatly reduce the time to process a DD Form 61.

Another activity, which takes a great deal of time and effort in the process, is the manual validation of the data on a DD Form 61. The MSTDS personnel have to manually check every field to insure that there is data in the field, it is in the appropriate format, and the entry is logically possible for the type of request and the equipment being nomenclatured. Although not pointed out in the process outlined above, the requesting customer must review the form before it is submitted. Much of this manual validation would be removed in an automated system. An automated system would ensure that all fields that must have them, do have entries and that the entries are in a correct format. Customers and MSTDS personnel will not have to check for these types of errors. The only errors which will require manual validation are those which require expert judgment. For example, that the requested item name is logical and type designation appear logical given the type of request and equipment. Automated validation will save submitter and MSTDS personnel a great deal of time and reduce the possibility of missing or incorrectly formatted data to near zero.

There is also some effort expanded in checking for the appropriate number of copies and making copies to send. This effort would be greatly reduced since the customer and MSTDS personnel can create multiple copies if needed via an automated request, send multiple copies, and attach copies to E-Mail.

Finally the activity of assigning the nomenclature and updating the database will be enhanced. The MSTDS personnel will not have to access a ledger and find the appropriate page and nomenclature list, but will simply query the system based on key data elements (e.g., item name and type designation) to retrieve possible assignments. Once this change is made and any other changes to the DD Form 61 are final the MSTDS personnel can update the database with a simple click on a screen or entry of a command. The appropriate DD Form 61 will then be updated as a final set of data in the TDAS database. Also, since security precautions will be taken, only the appropriate personnel can modify and update this data.

      

3.1  Objective

The objective of this effort is to provide an automated system that will replace the current manual, paper based MSTDS in use at sites such as CECOM.

3.2  Requirements

The proposed TDAS will include, but not be limited to, the following requirements:

1. Allow customers to directly retrieve CECOM's type designation data.
2. Allow MSTDS personnel to directly retrieve and update DD Form 61 data.
3. Enable electronic submittal of DD Form 61.
4. Facilitate customer entry of appropriate data on DD Form 61.
5. Facilitate verification of appropriate data on DD Form 61 input.
6. Develop database of relevant DD Form 61 and previous type designation data.
7. Enable retrieval of legacy DD Form 61s via key fields in database.
8. Enable connectivity to DLSC Information Hub.
9. Provide security to control access to DD Form 61 data .
10. Enable production of custom reports.

3.3  Scope

The automated system - the TDAS - will enable electronic submittal of DD Form 61s, inquiries to retrieve previous type designation data stored in the database within TDAS and assignment of nomenclature. All the data submitted on the electronic DD Form 61s submitted via TDAS will be stored within the TDAS database. The extent of the legacy data that will be stored within the database is To Be Determined (TBD). Custom reports will be provided but the exact reports are TBD.

3.4  Constraints

TDAS will be designed to allow Transport Control Protocol (TCP)/Internet Protocol (IP) access to its functions. Also, Information Builders, Inc. Enterprise Data Access (EDA)/Structure Query Language (SQL) software will be included to enable responses to the DLSC hub. Outside of these capabilities TDAS will supply no other networking capabilities. These capabilities - all necessary network software and hardware - are to be provided by the sites in which TDAS is to be installed.

TDAS will function in a Windows NT client/server environment using an Oracle 7.3 Relational Database Management System (RDBMS). See the Operational Environment Section (3.6) for more specific detail on the environment necessary to run TDAS.

3.5  Assumptions

It is assumed that customers will access TDAS via the Internet. Super-clients will connect to TDAS via a Local Area Network (LAN) at the installation housing the TDAS server.

Legacy data will be loaded into the database in phases. While the exact phasing and the specific data is TBD it has been established that data from paper DD Form 61s will be loaded first. Based on conversations with CECOM, it appears that only microfiche and S2K data then needs to be loaded. However, there are current problems reading the S2K and the microfiche contains data not in DD Form 61 format. Thus, further efforts must be expanded to resolve these legacy data issues before they can be loaded.

The completed version of TDAS at CECOM will include the TDAS software, Oracle DBMS software, EDA/SQL, a Windows NT server, and two Pentium processor PCs. The exact complement of TDAS software and hardware components to be delivered at sites beyond CECOM is TBD.

Although, due to refinement in working with the users, TDAS may contain some modification of the functionality outlined herein the current plan for TDAS is to provide only the functionality described in this document.

3.6  Operational Environment

Distributed processing and database configurations have evolved through a number of stages from host-based processing to master-slave processing and, finally, to client/server computing and World Wide Web (WWW) application. These two techniques will be used to serve both internal TDAS users (a.k.a. super-client: personnel of CECOM and AFMC who are responsible for DD Form 61s processing) and external users (a.k.a. client who currently submits DD Form 61s through the mail), respectively. The preliminary system architecture is illustrated in Figure 3.6­1.

Two different levels of users of TDAS have been identified: super-client and client. Super­clients are TDAS personnel who are responsible for DD Form 61s processing. Because they need to approve or reject DD Form 61 requests, generate various reports, and perform other tasks to support their day-to-day functionality, they will be given greater access privileges to the database system.

On the other hand, clients are those (including Government agencies and contractors) who submit DD Form 61 requests to the TDAS. In addition to the submittals, they often need to inquire about information from the type designation system regarding, for example, nomenclature, part number, or Commercial And Government Entity (CAGE) code. These users will be allowed to perform inquiries but not updates, therefore, they will be given restricted access to the database. Furthermore, because these two roles have very different responsibilities, the user interface and application will be tailored to meet their specific requirements. Most likely, a client application will only have a subset of functionality of what a super-client will have.

3.6.1  The Client/Server Architecture

Although WWW computing can also be categorized as client/server computing in which the web server acts as server and web browser as client, the client/server discussed in the section is the more traditional one that is operated in a LAN environment. The components of this architecture are mainly the DBMS running on the TDAS server and two super­client workstations.

Client/server computing has been recognized as one of the new standards in the database applications arena. A typical two-tier client/server database application is somewhat like a PC on a LAN. While the PC on a LAN asks for files from a file server, the client/server database application asks for data from a database server. The user interface portions of the application runs on a local PC and is separated from the data by a network cable and a database server. The front-end client portion runs on a local PC, while the back-end database engine runs on a database server. Thus, this arrangement takes advantage of distributed processing. Based upon the needs and requirements, client/server can either be as simple as two­tier, three-tier with an additional application server, or multi-tier architecture.

Advantages of client/server computing are summarized below:

• Better leveraging of emerging desktop computing technology.
• Reduction in network traffic.
• Encouragement of open system because the flexibility of the selections of both front­end development tool and back-end database server.
• Ease of training and user acceptance through the use of a Graphical User Interface (GUI).
• Performance and scalability in improving query performance against large tables.
• Integrity and security because of the separation of client application and the data.

3.6.2  WWW/Internet Computing

Originally, the users of the Internet were the people who built the Internet, but as time passed and the Internet become more useful, they were joined by more people. Ever since the introduction of HyperText Markup Language (HTML) and the graphical web browser, the Internet has further drawn a tremendous number of users. Because of this popularity, HTML has become virtual computing standard and has created many emerging technologies and applications.

On the other hand, this popularity creates many problems that were not foreseen when the Internet was built or that have not been resolved effectively. These problems could include the occasional performance-degrading due to the insufficient network infrastructure and lack of planning, or the security concern while conducting electronic commerce. Nevertheless, the Internet still provides far more benefits than drawbacks, and thus, it is the approach taken to support the external clients of the TDAS.

The most significant benefit of a WWW approach is the elimination of the software installation and management problem. There would be a tremendous cost in terms of person hours and money necessary to install software on hundreds of users of CECOM and AFMC. The process and cost would be repeated whenever there is any software update. Therefore, the WWW approach is attractive and cost-effective for supporting external clients. Even though the Internet is having access, capacity, and performance problems from time to time, it is still a preferable choice considering the trade-offs. Furthermore, the network access will be closely monitored and these concerns will be addressed when the system is in operation.

3.6.3  Hardware and Software

After the thorough analysis of CECOM's current process, initial TDAS hardware and software requirements have been identified. Although the requirements are mainly based on CECOM's needs and workload, they can be easily applied to the other MSTDSs since CECOM represents the largest workload (about 3,000 DD Form 61 requests per year) among all MSTDSs. Furthermore, because of the proposed open and scaleable approach, the final selection of hardware and software can be customized to meet each MSTDS's requirements without affecting the underlying architecture.

3.6.3.1  Server

One of the most critical components within this client/server architecture design is the TDAS server itself. This server will serve as a DBMS, as well as a web server and will host the EDA/SQL server that is mandated by DLSC for the connection to the Information Hub. Given the analysis and budget constraints, the following has been identified as the base for the server configuration.

Hardware

Based on performance and cost, a Intel Symmetric Multi-Processor (SMP) Pentium Pro­based system with two (2) CPUs installed, expandable to four (4), has been selected. UNIX-based systems such as machines from SUN and Hewlett Packard (HP) were also evaluated but with the workload of less than twenty (20) requests per day and estimated growth over the next three years to be less than (50) concurrent users, the selected "SMP" Pentium Pro offered a better performance/cost ration. The system will also be equipped with ten (10) gigabytes of storage space.

Operating System

Windows NT

Software

RDBMS: Oracle 7.3

Web Server: Oracle Web Server or Microsoft Internet Information Server (IIS) augmented with another third-party product to provide web-database connectivity.

Middleware: EDA/SQL server

If the workload exceeds the predicted value in the future, this configuration provides a great deal of expandability. First, two (2) more CPUs can be added without affecting any existing software or hardware component. Second, the RDBMS can be moved to a separate system to provide further expandability.

3.6.3.2  Client

There are different categories of clients who will access the TDAS. In this CONOPS and the initial development of the TDAS, the focus is on contractors and Departmental Control Points. Contractor is a non-government organization that is developing or modifying a system or part to be nomenclatured. They fill out the information about the item on the DD Form 61 and wait for the pre­approval from the Departmental Control Point before being processed by the CECOM or AFMC. Special attention is paid to the recommended item name, type designation, and source request number. The detail of the interactions between these two clients will be discussed in a later section.

The only requirement to these clients who submit DD Form 61s electrically and perform simple data inquiry is a Java-enabled web browser such as Netscape Navigator or Microsoft Explorer. Because the web application resides on the TDAS server itself, there is no software updating cost associated with each client. In addition, any modification to the application will not impose any effect on the clients except possible change of the interface.

3.6.3.3  Super-Client

A super-client has a very different role as an external client. A super-client does not only perform data inquiry, but also needs to be able to edit/correct the data, approve DD Form 61 requests, and generate reports. Consequently, the super-client application will be more complicated than client web application. PowerBuilder from Powersoft has been identified as the development tool for the super-client application. Two of the major advantages of PowerBuilder are its object-oriented Rapid Application Development (RAD) and scaleable capabilities. Because PowerBuilder is easy to learn, developers will be able to modify the TDAS application in the future if they choose to do so.

The connection to the Oracle database and EDA/SQL server will utilize the existing LAN infrastructure. Although a super-client needs to perform more functionality than a client, a typical Intel-based system will be enough for its tasks. For example, a system with a Pentium CPU and thirty-two (32) Megabytes Random Access Memory (RAM) augmented by two (2) Gigabytes storage space.

3.6.3.4  Telecommunication

Because Oracle and EDA/SQL are both capable of supporting multiple network protocols, it is almost certain that there is no need to alter the current LAN infrastructure to accommodate TDAS. On the other hand, the web approach does require the external clients to have access to TCP/IP.

Because TCP/IP is the most widely used protocol today, it can be easily acquired either through a direct LAN-WAN (Wide Area Network) connection or through a dial-up connection from Government-supported agencies or commercial Internet Service Providers (ISP).

      

We intend to develop the capability of submittal approval and updating prior to the data inquiry capability.

4.1  TDAS Client Point of View

As mentioned earlier, there are two categories of external clients: contractors who initially fill out the DD Form 61s and Departmental Control Points who have the responsibilities for pre­approving that the information filled out is complete and correct before being processed by the CECOM or AFMC. All of these activities will be done from a web browser accessing TDAS's Uniform Resource Locator (URL).

4.1.1  Submittal of DD Form 61s

The following is a typical scenario showing contractors how to submit DD Form 61s:

1. Access TDAS's URL from a web browser, provided TCP/IP has been acquired either through a direct or dial-up connection.

2. Fill out the form from the browser as the user would normally do on the paper. This form resembles the look and feel of current DD Form 61 with only minor modifications in order to comply with HTML syntax and format. Because of the resemblance between the web form and the paper DD Form 61, users will be able to adjust to the web interface easily.

3. Submit the form by clicking on the "submit" button. Intelligence will be built into the web application to validate the inputs for some formatting and required entries. It will then inform the users about the errors, thus shortening the turn around time and alleviating some of the burden from the Departmental Control Point personnel.

4. A special control sequence will be attached to this DD Form 61 request either being filled out by the contractor or derived automatically from the username and password if applicable. The control sequence is to be used as an identifier that will allow only the appropriate Departmental Control Point to have access to this DD Form 61 for the pre-approval process. In other words, the control sequence is a link between a contractor and his Departmental Control Point.

5. Finally, the DD Form 61 request just being submitted will have the status of "waiting-for-pre-approval". There will be built-in notification mechanism in the TDAS to inform the appropriate Departmental Control Point indicating there is a request waiting for the pre-approval.

In the case when a user wants to submit a package of related DD Form 61s, he or she can proceed as described above because the "package" will be handled by the modified Source Request Number (SRN) that is agreed on by CECOM. The modified SRN will clearly indicate the total number of related DD Form 61s that have been submitted and the order of each DD Form 61 in this package.

4.1.2  Pre-Approval of DD Form 61

The following is typical scenario for a Departmental Control Point to pre-approve DD Form 61 requests:

1. Access TDAS's URL from a web browser, provided TCP/IP has been acquired either through a direct or dial-up connection. Because of the control sequence, a Departmental Control Point will be allowed to access only those requests under its control.

2. Verify that the information on the DD Form 61 is correct and complete and assign the SRN.

3. Submit the form by clicking on the "pre-approve" button. Similarly, intelligence will be built into the web application to validate the inputs for some formatting and required entries. It will then inform the users about the errors, thus shortening the turn around time and alleviating some of the burden from TDAS personnel.

4. Finally, the DD Form 61 request just being pre-approved will have the status of "pre­approved". Also, there will be built-in notification mechanism in the TDAS to inform the CECOM or AFMC indicating there is a request waiting for the approval.

When an error is found, the Departmental Control Point can either correct the error if that is allowed, contact the submitter for further action, or open a window in TDAS to summarize the problem. The submitted DD Form 61 with the problem annotation can then be sent back to the submitter for reworking.

4.1.3  Data Inquiry

Data inquiry will be handled in a similar manner. Several pre-determined queries will be included in the TDAS web page. For example, the user could query using a part number or drawing number or could query about whether or not a particular DD Form 61 request has been processed and its status.

Although it is completely transparent to a user, depending on the type of query, there can be three very different data sources responding to the queries. The three data sources are:

1. The TDAS data repository to which the user connects,
2. Other TDAS data repositories that are remote to the user, and
3. The FLIS data repository.

For example, if the user queries upon a particular part number or drawing number, the query will be sent to all the three data sources; results from these data sources will then be compiled and presented to the user in a single and uniform view. In fact, the DLSC Information Hub is supposed to fulfill such queries through the uniform DLSC interface for cross-reference to the other TDASs and FLIS. However, it is more logical and feasible that the query be initiated directly from the TDAS where the client is accessing without the extra step to the DLSC Information Hub.

4.2  TDAS Super-Client Point of View

One of the major goals that developing TDAS should achieve is to eliminate the ledger books that have been used by these MSTDSs for tracking the history of nomenclatures. With legacy data being fully digitized and the capabilities provided by modern DBMS, not only can these ledger books be eliminated completely, but the personnel who processes DD Form 61s (super­client) can access more information in a more systematic way than was possible in the past.

The major activities that a super-client will perform are described in the following sections. All these will be done from the super-client application developed from PowerBuilder.

4.2.1  Approval and Update of DD Form 61s

The "package concept" is important in the approval process. It is more reasonable to process each package all together than jumping from one request in one package to another request in another package. The TDAS will facilitate this "package concept" by allowing approval only when an entire package of DD Form 61s has been received. As stated above, this will be handled by the modified SRN as described in Section 4.1.1.

The default processing order of the approval will be first come, first serve. However, from the super-client application, a user will be given the capability to select which pending DD Form 61 requests to process. For example, a super-client can select and process the DD Form 61 requests from the same originator or with related type designator in a group ­ whichever make sense for a particular circumstance.

The pre-approved request will be shown on a super-client screen with the same look and feel of the existing paper DD Form 61. Similar to the client web application, validation rules will be built into the application to assist the super-client in the approval process. With the full access to the database, the validation rules can be very comprehensive. For example, a request for revision can be approved only if there exists an assignment for the same nomenclature.

When an error is found, the super-client can either correct the error if that is allowed, contact the submitter for further action or open a window in TDAS to summarize the problem. The submitted DD Form 61 with the problem annotation can then be sent back to the Departmental Control Point for reworking. Once a request has been validated by both the TDAS personnel and the application, an E-Mail message or other communication mechanisms will be triggered to notify the submitter that such request has been approved and of any modification that has been made to it. Finally, the approved DD Form 61 will have the status "approved" and be stored permanently in the TDAS for future references.

4.2.2  Data Inquiry

The data inquiry activity will be very similar to the one described in the client section, except this is done from the PowerBuilder application with more complicated query capability. Some standard queries will be built into the super-client application, but they can also be customized easily for each TDAS.

4.2.3  Tracking

All the tracking data will be logged into the database automatically by the super-client application. The following is the information that will be recorded:

• When a DD Form 61 request is submitted.
• When a request is processed.
• When and why the approval process is on hold.
• When and why a request is rejected.
• When a request is approved.

This information will provide a detailed history of each DD Form 61 request. It not only can be utilized to provide better customer service, but it can also serve an internal monitoring purpose.

4.2.4  Report Generation

Given the full access to the database, TDAS and the super-client will have the ability to generate reports with the constraint that some reports might not be able to be generated from legacy data. Similarly, some common reports, as yet to be identified, will be included in the super-client application. Most importantly, the reporting capability can be fully customized by each MSTDS to meet its own mission. For example, a TDAS could generate a summary report of DD Form 61 requests submitted by a particular originator within a certain period of time or a performance analysis report indicating average turn-around time from submittal to approval.

      

5.1  Summary of Advantages

Following are the major advantages provided by the TDAS. These advantages are provided either by the approach taken to implement the TDAS, the design of the database, or simply the automation of the MSTDS.

Automation of MSTDS (TDAS)

• Elimination of the error-prone ledger books.
• Full and easy access to the history of each DD Form 61.
• Reduction of manpower and human mistakes with built-in verification and validation.
• Capability of generating various reports.
• Reduction of turn-around time from submittal to approval or rejection.
• Capability of on-line data inquiry.

Client/Server Computing

• Better leveraging of emerging desktop computing technology.
• Reduction in network traffic.
• Encouragement of an open system with the flexibility of the selections of both front­end development and back-end database server.
• Ease of training and user acceptance through the use of a GUI.
• Performance and scalability in improving query performance against large tables.
• Integrity and security because of the separation of client application and the data.

WWW/Internet

• Reduction of software distribution, installation, and updating costs.
• Reduction of support and maintenance costs.
• Greater acceptance by users since there is no application to be installed to their systems.
• Reduction of training cost through the usage of common and user-friendly web browser interface.
• Ease of access to the TDAS since no application is required except TCP/IP and a web browser.

5.2  Summary of Disadvantages

One major potential drawback of the design is the usage of the Internet as the communication mechanism for external clients. Inevitably, there must be some kind of connection between a TDAS and its external clients. Other than the public Internet, a private or military network is another choice. However, if the Internet is not used, not only will the cost be extremely higher, but the usage will be limited since not everyone will have, or even be qualified to, access the private or military network.

Based upon CECOM estimates, one of the busiest TDAS, the average number of DD Form 61 requests is to be twenty (20) per day. With this workload and the non-time-critical nature of the requests, the performance-degrading resulting from occasional Internet problems can be tolerated.

5.3  Alternatives and Tradeoffs Considered

Several alternatives considered during the design of the TDAS are described in this section.

TDAS Server Hardware

The selection of TDAS server hardware is primarily based on the following three criteria: performance, cost (including both purchasing and maintenance costs), and computing power required of the TDAS. Systems considered included: SUN and HP running UNIX operating system, and Intel Pentium Pro running Microsoft Windows NT. Although mid-range to high-end systems from SUN and HP provide greater performance, they were determined to be both too costly and unnecessary for a TDAS server. In addition, a low-end SUN or HP does cost less but it does not perform as well as a Pentium Pro system with the same price tag.

Web Application Development

Many approaches have been considered: Fourth-Generating Language (4GL) client/server development tool with extensions for the web, such as PowerBuilder; Java development tool with the Java Database Connectivity (JDBC); web application server tool including Oracle Web Server and ColdFusion. The selection of the tool is again constrained by the cost and requirement. Therefore, some of the tools that post high technical merits were not evaluated because of their high costs.

Currently, the 4GL approach has been eliminated because it will require proprietary plug-ins which is against the open system concept that we are trying to preserve. The Java approach provides a high-degree of platform support and richer programming features but its immaturity is the major concern. The web application server approach does not need proprietary plug-ins, nor other client software. This makes the approach more suitable for the TDAS application. Furthermore, Oracle Web Server is designed mainly for the Oracle RDBMS, and thus, has the advantages of better performance and security among all the alternatives. However, both the Oracle Web Server and ColdFusion use an HTML-like programming toolkit. Since HTML is not a programming language, this essentially limits the programming ability and creativity of the web interface design.

The final decision should come soon after the release of this document. In order to take advantage of the benefits that various approaches provide and to achieve the goals of performance, security, and programming features, a hybrid approach will possibly be taken.

      

6.1  Legacy Data

Type designation data has been stored in many different forms of media. These include:

• The original paper DD Form 61s,
• Images of DD Form 61s on Canonfile optical disks,
• Microfilm,
• Microfiche,
• UNISYS 9 track tape in S2K format,
• The tracking databases which have a subset of the data, and
• Ledger books which contain a subset of the data.

Obviously, the first issue is that data will have to be converted from various media into a common format: American Standard Code for Information Interchange (ASCII) format which can then be entered into the TDAS database. At this time, we believe that it is only necessary to use three media - paper, microfiche, and S2K - to cover all data from 1943 to the present. However, this still presents challenges in using different equipment and conversion processes to convert each medium. The present plan is to use a conversion service to convert paper and microfiche data. CECOM is handling the conversion of the S2K data.

Another issue is that microfiche is not in the DD Form 61 format. In fact the microfiche, which appears to cover the years 1943 to 1969, contains images of, at least, four different forms. These forms do not include some DD Form 61 fields. Also, some data elements, which are equivalent to DD Form 61 data elements in meaning, are named differently than those DD Form 61 elements on the microfiche forms. Thus, separate scripts would have to be developed for each medium and the database schema will be more complex in order to accommodate all data fields.

We are unsure of the S2K format as 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. This inability to read S2K data at this time is a third issue. The S2K data covers the years from 1970 to 1986 and, being in a database format already, would seemingly provide the least conversion challenge. However, we have not been provided with a data dictionary for this database, nor have we seen one single record, so we have no way of knowing how closely this format matches the DD Form 61 format. It is likely that a third script will need to be developed for this medium and it is possible, if more or different fields are discovered, that the database schema will be further complicated.

There are large amounts of data in each medium. Our current estimates are 82,500 pages of paper, 176,000 pages of microfiche, and 75,000 records on S2K. Data conversion is labor intensive and there is very little volume discount.

There are visual aspects of some of the data, at least of paper and microfiche, that will cause errors or be unreadable by automated conversion or even human data entry. These aspects include: handwriting, illegible data entries, multiple fonts, degradation of data due to xerographic copying, data in block 14 not following the prescribed format. Close investigation of 111 paper forms shows that every one has some handwriting and up to 23% have some visual aspect which will cause conversion problems. Thus, each page will need human inspection after conversion, raising the cost. Also, some entries (poor handwriting, illegible) will require CECOM expertise to insure the correct data is entered.

The various media, various formats across and even within media and the visual aspects of some data forms, mean that automated data conversion, followed by use of a single or even multiple scripts to automate the database entry process, is not feasible without substantial human inspection. Each page of the output of the conversion process will need to be inspected at a service provided. They can provide correction and can make (e.g., key-stroking in legible handwriting) and flag problems that need expert (i.e., CECOM) attention such as deciding what should be entered when the handwriting or the typewritten entry is barely legible. CECOM experts will then have to work those pages to enter the correct data. CECOM personnel will also have to do a random checking of the entire converted data to verify the data. Also, even after entry into a database via scripts, CECOM experts will have to randomly check and verify that the script has functioned correctly.

The legacy data thus presents an enormous challenge technically and in terms of manpower and costs. The final approach is currently being determined. Note that even with an Optical Character Recognition (OCR) approach multiple scripts are required and extensive inspection of the converted data must take place. It is thus very possible that an approach of keystroking the data directly into a file might be the best way to achieve the legacy data conversion with high confidence. The cost of such an alternative is based on the number of keystrokes. In order to reduce this cost to an acceptable level the best way to handle the legacy data is to keystroke only the key fields and store the associated images in the database.

6.2  EDA/SQL

The deployment of EDA/SQL server software has been mandated by DLSC. Because of its proprietary nature, the only way to communicate with EDA/SQL software is from another EDA/SQL software package. The EDA/SQL provides the capability of accessing multiple data sources, including relational databases and mainframe non-relational databases, and presents the result back to users in a uniform manner. However, in addition to the high purchasing cost, it also requires high levels of maintenance effort and costs. Training or service support is probably necessary for each TDAS because of the complexity of EDA/SQL software. Another major disadvantage is the implementation of the catalogue server module which stores the information of other catalogue servers for the naming translation among various data sources. Any change to one TDAS database schema, as long as the change is in the public interest, will necessitate an update to all the other catalogue servers. Unfortunately, there is no automated updating capability, all updating will need to be carried out by all TDAS personnel manually. It will be very cumbersome for such action especially when the number of TDASs becomes large.

6.3  Security

Security is a baseline requirement for network computing that includes both client/server and WWW/Internet approaches in our design. Privacy, authentication, authorization, and integrity are all important elements of any security strategy. These practices work to defend against the threats of eavesdropping, manipulation, and impersonation. The purpose of this section is only to discuss security features that will be implemented in the TDAS and other security measure that might be of interest to each MSTDS. It is not our intent to influence any current security practice at each MSTDS, nor do we suggest one measure is better than another.

6.3.1  User Authentication

Accurate identification is a prerequisite for security. The correct username and password is required in order for a super-client or client to access the TDAS. Each external client will need to apply a valid username and password before accessing TDAS web pages. Thus, each TDAS will have full control of who will be granted the access privilege. Naming conventions and other rules on assigning a username and password will be totally up to each TDAS. However, it is not unusual for users to write down their passwords in exposed places or to divulge them to others. Therefore, it is recommended that passwords should be changed periodically.

6.3.2  Database-Level Security

In addition to the basic user authentication, a database-level of security will also be implemented. As mentioned, the external client can only perform submitted and query functions against the TDAS database. Also, a submitted DD Form 61 request will need to be approved by a super-client before it can be permanently stored in the database. With these implementations, an unauthorized external access resulting from a stolen password and even an intentional misuse of the system will not damage the integrity of the database.

6.3.3  Internet Security

Security on the Internet is a complex subject. Although there are many potential weaknesses and many diverse types of attacks, one should not be discouraged by the usage of Internet computing. With appropriate measures, Internet computing can be save and efficient. The following paragraphs are brief discussions of some of today's popular security measures, which might be of interest to each TDAS.

Firewall

Firewalls are software and/or hardware products that precisely define, control, and limit the access to internal computers from outside computers across a network. They are most often employed to limit exposure when connecting an organization's network to the Internet or other external or untrusted networks, and to deter hackers and other unauthorized users from unauthorized access, use, or damage to internal computers, data, and computing resources. The installation of a firewall can obviously provide additional security to each TDAS.

Public Key

Public key technology involves the use of a pair of related keys, one of which is freely distributed and another one is tightly controlled by the owner. These keys are algorithmically related such that a message encrypted by user A with the public key of user B can only be decrypted by user B, even though the encryption key used by user A is known to all. Furthermore, public keys have the property that if a message is encrypted with user A's secret key, then user B, in possession of user A's freely distributed public key, can decrypt the "signature" and authenticate that only user A could have originated the message.

The obvious benefit of the technology is that clients and servers could use public known keys and encrypt messages or decrypt signatures to protect and validate transactions. There is, however, a major problem with dissemination of public keys. Although one part of the key is public, there is nothing inherent in the model to prevent user C from placing a public key in the public domain and claiming it to be user A's public key. Therefore, unless this problem is eliminated, this public key technology might not be the most conducive for the open Internet computing.

Secure Socket Layer

Netscape has designed and specified a protocol for providing data security layered between application protocols (such as HyperText Transfer Protocol [HTTP], Telnet, Network News Transfer Protocol [NNTP], or File Transfer Protocol [FTP]) and TCP/IP. This security protocol, called Secure Socket Layer (SSL), provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.

SSL is an open, nonproprietary protocol. It has been submitted to the W3 Consortium (W3C) working group on security for consideration as a standard security approach for web browsers and servers on the Internet. It is important to track emerging developments with this protocol due to the rise in popularity of the Netscape browser and its influence on the web community.

6.4  Database Schema Design

General database schema design practice has been taken for the TDAS. However, the design of database schema is also constrained by the following factors:

• The legacy data that can be extracted correctly and cost-effectively from various media.
• The degree of modifications that can be made to the layout of DD Form 61.
• The changes that can be made to the process that are currently in place at each MSTDS and external client sides.

As addressed in the previous section, legacy data imposes one of the biggest challenges of the implementation. Until the final approach has been determined for each medium, the schema can not be finalized.

It is understood that there was no RDBMS frame of mind when the DD Form 61 was created. Therefore, it is anticipated that several changes of the DD Form 61 will be needed in order to accommodate and fully take advantage of a RDBMS. We have been very pleased by CECOM's full cooperation and willingness during the design phase. It is very important that the other MSTDSs have the same level of cooperation.

      

First, according to the information that has been released, all the queries will be initiated only from the DLSC Information Hub to either FLIS or TDASs, not the other way around. For example, both CECOM super-clients and clients will access the DLSC Information Hub to perform queries. While this can be done, it is more logical that CECOM TDAS users, including both super-client and client, perform a query directly from CECOM TDAS. Also, there may be a performance problem at the Information Hub since all Government and industry weapon system developers and project managers are potential users of the Information Hub.

Second, no intelligence will be built into the Information Hub (partly because of the usage of the EDA/SQL software). Upon receiving a query related to TDAS, the Information Hub will simply broadcast the query to all the TDASs and wait for each of them to respond. This wastes a large degree of network bandwidth which could be easily reduced if there is some sort of intelligence within the Information Hub.

APPENDIX A:   REFERENCES

      

"Web Application Development Tools, Sorting the Strategies," InfoWorld, February 24, 1997, Volume 19, Issue 8.

National Computer Security Association (NCSA) web page: www.ncsa.com.

APPENDIX B:  ACRONYMS AND ABBREVIATIONS