Embed Size (px)
Citation preview
NON-MEASUREMENT<SENSITIVE
MIL-HDBK-59to( 20 December 1988(V)
(0N
MILITARY HANDBOOK
DEPARTMENT OF DEFENSECOMPUTER-AIDED ACQUISITION AND LOGISTIC SUPPORT (CALS)
PROGRAM IMPLEMENTATION GUIDE
0I
OTICSELECTE f2''MAR 1989
. MSC N/A AREA ILSSDISTRIBUTION STA TEMEN1 A~. Approved for public release; distribution is unlimited.
MIL-HDBK-59
DEPARTMENT OF DEFENSEWASHINGTON, D.C. 20301
Department of DefenseComputer-aided Acquisition and Logistic Support (CALS)
Program Implementation Guide
1. This military handbook was developed by the Department ofDefense with the assistance of the military departments, federalagencies, and industry.
d2. This handbook provides information and guidance to personnelresponsible for the acquisition and use of weapon systemtechnical data. Its purpose is to assist in the transition frompaper-intensive processes to digital data delivery and access.It also supports the structuring of contract requirements toachieve integration of various contractor automated capabilitiesfor design, manufacturing, and logistic support.
3. Beneficial comments (recommendations, additions, deletions)and any pertinent data that may be of use in improving thisdocument should be addressed to: Office of the Secretary ofDefense, CALS Policy Office, DASD(S)CALS, Pentagon, Room 2B322,Washington, D.C. 20301-8000 by using the self-addressedStandardization Document Improvement Proposal (DD Form 1426)appearing at the end of this document or by letter.
Accession For
NTIS GRA&IDTIC TABUnanxouiced 0Justificatin
By
Distribut ion/
Availability Codes
A Avail and/or
DiSt Special1'ii
MIL-HDBX-59
FOREWORD
Computer-aided Acquisition and Logistic Support (CALS) is a DoDand Industry strategy to enable, and to accelerate, theintegration of digital technical information for weapon systemacquisition, design, manufacture, and support. CALS will providefor an effective transition from current paper-intensive weaponsystem life cycle processes to the efficient use of digitalinformation technology. The purpose of CALS is to improveindustry and DoD productirity and quality, and thus improvesupportability, military readiness, and combat effectiveness.The objectives of CALS are:
a. To accelerate the integration of design tools such asthose for reliability and maintainability into contrac-tor computer-aided design and engineering systems aspart of a systematic approach that simultaneouslyaddresses the product and its life cycle manufacturingand support requirements.
b. To encourage and accelerate the automation and integra-tion of contractor processes for generating weaponsystem technical data in digital form.
c. To rapidly increase DoD's capabilities to receive,store, distribute, and use weapon system cechnical datain digital form to improve life cycle maintenance,training, and spare parts reprocurement, and othersupport processes.
Currently, a variety of automated systems are utilized by weaponsystem contractors working as a production team to enter, update,manage, and retrieve data from data bases associated with speci-fic acquisition programs. Many of these systems are incompatiblewith one another other as well as with similar systems employedby the government to receive, store, process, and use deliveredtechnical data. The functional capabilities supported by thesediverse systems vary greatly. Data created in one functionalprocess is often manually re-entered or re-created in subsequentfunctional processes, thereby introducing errors and increasingcosts.
The near term goals for CALS implementation are attainment ofincreased lc-,els of interfaced, or integrated, functionalcapabilities, and specification of requirements for limitedgovernment access to contractor technical data bases, or fordelivery of technical data to the government in digital form.
iii
MIL-HDBK-59
These specifications are designed to comply with widely acceptedcommercial standards developed for these purposes.
The longer term goal of CALS is integration of industry and DoDdata bases to share common data in an Integrated Weapon SystemData Base (IWSDB) structure that is implemented throughContractor Integrated Technical Information Systems (CITIS) andgovernment technical information systems. Da~ta deliverablesfrom, or government access to, specified segments of CITIS datawill be explicitly required in future contracts, developed inaccordance with CALS standards and procedures. The technology toaccomplish this will be incrementally implemented as it isdeveloped and proven. DoD and industry will be implementing amixture of current and emerging technologies throughout the1990's.
This handbook applies to programs for acquisition and support ofweapon systems and related major equipment items (includingsupport systems) to which DoDD 5000.1, DoDI 5000.2, or DoDD5000.39 apply. Policy guidance issued by the Deputy Secretary ofDefense on August 5, 1988, (Appendix A, figure 3) requiresacquisition managers to evaluate CALS capabilities in sourceselection decisions and to implement cost effective CALSrequirements in contracts for weapon systems and related majorequipment items. To aid acquisition managers in implementingthis policy, this military handbook provides:
o An overview of Computer-aided Acquisition and LogisticSupport.
o A summary of the various ways in which digital data can beused and the forms in which digital data can be procured oraccessed.
O A set of decision criteria to apply when evaluatingalternative digital data delivery and access options.
o Model contract language for contractor integration ofspecific functional capabilities, delivery of digital data,and government access to contractor-maintained data bases.
iv
MIL-RDBK-59
TA~BLE OF CONTENTS
1. SCOPE . 1
1.1. Pu r pos e .... .... ... ... 1
1.2. Scoe.....pe ....... 1
2. REFERENCED DOCUMENTS.....................1
3. DEFINITIONS.........................1
4. GENERAL GUIDANCE......................2
4.1. Pulrpose .. ........................ 2
4.2. Digital technical data .. ................ 2
4.3. CALS requirements in weapon system acquisition. . . . 2
4.4. CALS requirements in automated data processing systemacquisition .. ...................... 3.4.5. Application guidance.. ................. 3
4.6. Government receiving systems. .............. 4
4.7. Functional capabilities. ................. 5
4.8. Data protection and integrity. .. ............ 5
5. DETAILED GUIDANCE. ..................... 6
5.1. Acquisition requirements .. ............... 6
5.2. Acquisition of digital data products .. ......... 10
5.3. Contract deliverables .. ................ 20
5.4. Data protection and integrity, data rights, andrelated issues. .......................20
5.5. Detailed guidance for applications .. ......... 21
6. NOTES............................22
6.1. Intended use. ...................... 22
O6.2. Subject term (key word) listing .. ............22
v
MIL-HDBK-59
APPENDIX A
CALS OVERVIEW
10. SCOPE...........................25
10.1. Purpose.......................... .. .. 25
20. REFERENCED DOCUMENTS...................25
20.1. Government documents . .. .. .. ... .. .. . . .
20.2. other publications....................28
20.3. Order of precedence...................29
30. DEFIN1TIONS........................30
30.1. Acquisition manager....................30
30.2. CALS Core Requirement...................30
30.3. Information systems...................31
30.4. Technical data......................31
30.5. Contract data deliverables and access ........... 32
30.6. File types........................33
30.7. Acronyms and abbreviations . .... .. .. .. .. .... 33
40. OVERVIEW OF COMPUTER-AIDED ACQUISITION AND LOGISTICSUPPORT (CALS).......................35
40.1. CALS overview.......................35
40.2. CALS concepts.......................36
40.3. CATS implementation....................41
40.4. CALS management organizations...............44
vi
MIL-HDBK-59
APPENDIX B
APPLICATION GUIDANCE FORACQUISITION OF DIGITAL DELIVERABLES
10. SCOPE ........... ......................... 51
10.1. Applicability ........ ..................... 51
10.2. Purpose .......... ........................ 51
20. REFERENCED DOCUMENTS ....... .................. 51
30. DEFINITIONS ......... ...................... 51
40. GENERAL GUIDANCE ........ .................... 52
40.1. Contracting for digital data .... ............. . 52
40.2. Tailoring and revision of functional standards. . . 52
40.3. Application of the master decision template ........ 52
O 40.4. Technology development and insertion ........... . 54
50. DETAILED GUIDANCE ....... .................. 56
50.1. Organization of guidance sections ... ........... .. 56
50.2. ACQUISITION OF TECHNICAL MANUALS ... ........... 56
50.3. ACQUISITION OF TECHNICAL DATA PACKAGES (TDP). . . . . 65
50.3.2. ENGINEERING DRAWINGS ...... ................. . 65
50.3.3. PRODUCT SPECIFICATIONS AND BOOK FORM DRAWINGS. . . . 73
50.3.4. OTHER TDP COMPONENTS (RESERVED) ... ........... 77
50.4. ACQUISITION OF LOGISTIC SUPPORT ANALYSIS RECORDS(LSAR) .......... ....................... 77
50.5. ACQUISITION OF TRAINING PRODUCTS ... ........... . 88
50.6. ACQUISITION OF TECHNICAL SPECIFICATIONS . ....... 95
50.7. ACQUISITION OF INTERACTIVE MAINTENANCE AIDS(RESERVED) ......... ..................... 96
vii
MIL-HDBK-59
APPENDIX C
FUNCTIONAL REQUIREMENTS FORINTEGRATION OF CONTRACTOR PROCESSES
10. SCOPE ........... ......................... 99
10.1. Applicability ........ ..................... 99
10.2. Purpose .......... ........................ 99
20. REFERENCED DOCUMENTS ....... .................. 99
30. DEFINITIONS ......... ...................... 99
40. GENERAL GUIDANCE ....... ................... 100
40.1. Contracting for integration of functional processes. 100
40.2. Strategic approach ...... ................. 100
40.3. Application environment. ....... .............. 100
40.4. R&M integration with CAD/CAE. ................... 101
40.5. Integration of contractor LSA processes with R&M anddesign engineering ....... .................. 101
40.6. Configuration management of technical data ........ .101
40.7. Concurrent engineering ...... ................ 101
50. DETAILED GUIDANCE ....... ................... o.102
50.1. Organization of guidance sections ..... ......... .102
50.2. FUNCTIONAL REQUIREMENTS FOR R&M INTEGRATION WITHCAD/CAE ........ .. ....................... 102
50.3. FUNCTIONAL REQUIREMENTS FOR INTEGRATION OF CONTRACTORLSA PROCESSES WITH R&M AND DESIGN ENGINEERING ....... .. 112
50.4. FUNCTIONAL REQUIREMENTS FOR CONFIGURATION MANAGEMENT OFTECHNICAL DATA. (RESERVED) ..... .............. 113
50.5. FUNCTIONAL REQUIREMENTS FOR CONCURRENTENGINEERING.(RESERVED) ..... . ................ 113
viii
MIL-HDBK-S9
APPENDIX D
CONTRACT REQUIREMENTS FOR DELIVERY MODES
10. SCOPE.............................117
10.1. Applicability......................117
10.2. Purpose...........................117
20. REFERENCED DOCUMENTS...................117
30. DEFINITIONS.......................117
40. GENERAL GUIDANCE.......................117
40.1. Access and delivery of digital data. .......... 117
50. DETAILED GUIDANCE......................118
50.1. Organization of guidance sections. ........... 118.50.2. Physical media.....................119
50.3 eeonnnctc3 . . . ... .. .... 12).
ix
MIL-HDBK-59
APPENDIX E
DATA PROTECTION AND INTEGRITY,DATA RIGHTS, AND RELATED ISSUES
10. SCOPE .......... ......................... 131
10.1. Applicability ........ ..................... 131
10.2. Purpose .......... ........................ 131
20. REFERENCED DOCUMENTS ....... .................. 131
30. DEFINITIONS ......... ..................... 131
40. GENERAL GUIDANCE ........ ................... 131
40.1. Contracting for digital data .... ............. .131
50. DETAILED GUIDANCE ....... ................... 132
50.1. Data protection and integrity ..... ............. .132
50.2. Data rights, privacy, and legal liability ......... ... 139
FIGURES
F1uURE 1. Decision template for acquisition of digital data . 15FIGURE 2. Digital information exchange .... ............ .37FIGURE 3. CALS implementation requirements ... .......... .46FIGURE 4. Decision template for technical manuals ....... .58FIGURE 5. Decision templatc for engineering drawi-gs ....... .. 68FIGURE 6. Decision template for product specifications and
book for drawings .... . . ................. 74FIGURE 7. Decision template for logistics support analysis
record (LSAR) ....... ................... 79FIGURE 8. Decision template for training product ......... ... 91
TABLES
TABLE I. CALS points of contact ...... .............. 45TABLE II. Technical manual forms and standards ... ........ .64TABLE III. Summary of engineering drawing forms and standards. 72TABLE IV. Summary of LSAR forms and standards .. ........ .85TABLE V. Summary of training products forms and standards. . 95TABLE VI. Identification of security by data item ........ 136
x
MIL-HDBK-59
1. SCOPE
1.1. Purpose. The purpose of this military handbook is toprovide general information and detailed application guidance forcontractually implementing Computer-aided Acquisition andLogistic Support (CALS) requirements in weapon system and relatedmajor equipment procurements.
1.2. Scope. This handbook describes functional requirements andtechnical standards applicable to all programs for acquisitionand support of weapon systems and related major equipment items(including support systems) to which DoDD 5000.1, DoDI 5000.2, orDoDD 5000.39 apply, and for which the acquisition of technicaldata in digital form is required in accordance with MIL-STD-1840,MIL-STD-1388-2, and supporting military specifications. Thishandbook also addresses those specific functional capabilitiesrequiring integration by the contractor to support weapon systemacquisition.
2. REFERENCED DOCUMENTS
See list of references appearing in Appendix A.
3. DEFINITIONS
See list of terms and acronyms appearing in Appendix A.
Q1
MIL-HDBK-59
4. GENERAL GUIDANCE
4.1. Purpose. Computer-aided Acquisition and Logistic Support(CALS) is a Department of Defense (DoD) and industry strategy toenable, and to accelerate, the integration of digital technicaldata in standard form for weapon system acquisition, design,manufacture, and support. The intent of CALS is to improveindustry and DoD productivity and quality. This leads toimproved supportability, and to increased readiness and opera-tional effectiveness.
4.2. Digital technical data. A primary CALS thrust isautomation and integration of the generation, delivery, and useof weapon system technical data over the weapon system's lifecycle. This technical data includes the part descriptions,product specifications, and standards that the initial designerdraws upon; the engineering drawings and product data used indesign and manufacturing; the information needed to guide thepeople who operate the system in the field, or who support andmaintain it at all echelons of the logistic support structure;the materials needed to train new operators, maintainers andother technicians; and the information needed for reprocurement,remanufacturing, modification, and feedback to industry forfuture design. CALS has published technical standards whichenable either delivery of this information in digital form orgovernment access to contractor-maintained technical data bases.A more complete discussion of CALS is found in Appendix A.
4.3. CALS requirements in weapon system acquisition. Policyguidance issued by the Deputy Secretary of Defense (see AppendixA, figure 3) requires that plans for new weapon systems andrelated major equipment items include use of the CALS standards.Specifically:
a. For systems entering full scale development orproduction prior to September 1988, acquisitionmanagers are required to review specific opportu-nities for cost savings or quality improvementsthat could result from changing paper deliverablesto digital delivery or access using the CALSstandards.
b. For systems entering development after September1988, specific cost and schedule proposals shouldbe obtained for: (1) integration of contractortechnical informAtion systems and processes, (2)authorized government access to contractor databases, and (3) delivery of technical information
20
MIL-HDBR-59
in digital form. These proposals shall be givensignificant weight for their cost and qualityimplications in source selection decisions. TheCALS standards are to be applied for digital datadeliverables.
4.4. CALS requirements in automated data processing systemacquisition. CALS implementation involves the participation ofboth weapon system acquisition managers, and government andindustry automated data processing system managers. Acquisitionsof future computer hardware, software, and telecommunicationsmust address CALS data interchange and access requirements. Thekey to supporting these requirements is an open architecture thatcan cost effectively support future as well as current datainterchange and access needs. Although the audience for thishandbook is the acquisition manager for weapon systems andrelated major equipment, automated data processing systemmanagers should also be familiar with its contents. The DeputySecretary of Defense policy guidance provided as Appendix A,figure 3, requires DoD components to program for automatedsystems to receive, store, distribute, and use weapon systemtechnical data in digital form in accordance with the CALS. standards.
4.5. Application guidance. A general framework for implementingCALS requirements is provided in Section 5.1, followed bydetailed guidance on choices among digital data delivery andaccess alternatives. Information on digital data requirementsfor specific functional areas, functional integrationrequirements, and delivery modes is provided in Appendices B, C,and D, respectively. Other acquisition issues, including dataprotection and integrity, are addressed in Appendix E.
4.5.1. Contract data requirements. Contract Data RequirementsLists (CDRL's) and Data Item Descriptions (DID's) from previouscontracts may not take advantage of automated capabilitiesavailable in current acquisition programs. Acquisition managersshould identify new requirements in invitations for bid. InRequests for Proposal (RFP's), the acquisition manager shouldtask contractors to conduct tradeoff studies to identify improvedmethods for data delivery or on-line access. Contractors shouldwork with acquisition managers and contract administrationactivities to implement on-line access to data files, and toestablisi guidelines defining the actions on the part of thecontractor and government that constitute delivery and acceptanceof data which may remain resident at the contractor's facility.Contractors should also identify redundant data deliverables ormultiple reports which can be produced from a single data file.. Contractors should propose implementation of alternate delivery
3
MIL-HDBK-59
methods: for example, by proposing delivery of LSAR Master Filesto fulfill multiple CDRL items for hard copy reports. In somecases, technical data in digital form can be acquired withexisting DID's, while in other cases new DID's must be developed.Appendix B provides additional guidance.
4.5.2. Government furnished information. An important subset ofdata required to support the acquisition of weapon systems isgenerated by the government and provided to the contractor asgovernment furnished information. The acquisition manager shouldprovide this information in digital form whenever possible.RFP's should specify contractor responsibilities for the integra-tion of government furnished information with contractor-generated data in preparation of documents, processable files, ordata bases for interactive access.
4.5.3. Guidance for subcontracting. The acquisition manager andpotential prime contractors should jointly pay particularattention to data requirements that will flow down to subcontrac-tors and suppliers. Requirements for delivery of digital data byprime contractors should reflect cost-effective delivery ofsub-tier data where needed. Hard copy, microfilm, or non-standard digital data should be evaluated when life cycle costsmay not support delivery of digital data in standard form by allsubcontractors and suppliers, but delivery in standard digiialform is the preferred mode. The mix of format requirementsshould be formalized and documented in block 16 (Remarks) of theCDRL (DD Form 1423) before contract award. When the mix offormat requirements cannot be determined until after contractaward, those requirements must be formalized as a contractmodification.
4.5.4. CALS application to small business. Small business makesup a substantial portion of DoD contractors and subcontractors.The policy guidance by the Deputy Secretary of Defense (AppendixA, figure 3) directs special attention to opportunities andsafeguards for small businesses operating in a CALS environment.Small business should not be put at a disadvantage because oflimited resources for the investments needed to comply with CALSdata delivery, data access, and functional integrationrequirements.
4.6. Government receiving systems. Contractor-generated digitaldata must be supported by government receiving systems that canaccess, receive, process, and distribute digital technical datausing CALS specifications and standards. Government receivingsystems are being established in the military departments andagencies during 1989-1995 for digital engineering drawings,technical manuals, and other technical data. Acquisition and
4
NIL-HDBK-59
delivery of, or access to, this digital data must be phased tocoincide with incremental upgrades to the government hardware,software, and procedures which constitute the receivinginfrastructure. Where appropriate, the acquisition manager mustconsider the status of the receiving infrastructure within theacquiring Service, other Services, and the Defense LogisticsAgency. Service and Defense Logistics Agency CALS offices listedin Appendix A can provide status information and additionalguidance on time phasing.
4.7. Functional capabilities. The functional capabilitiesdescribed in Appendix C constitute an evolutionary program toachieve functional integration within contractor processes andthe supporting CITIS. The acquisition manager should apply thegeneral guidance of Appendix C in the preparation of solicitationdocuments and resulting contracts. The acquisition manager maytailor the detailed requirements as necessary to support theacquisition strategy selected for the weapon system.
4.8. Data protection and integrity. DoD policies andacquisition regulations regarding data protection and integrityin the paper-based environment also apply to the CALS digital. environment. Control of the system, data base, and associateddata maintenance and configuration control responsibilities areimportant issues. These issues require consideration in thedesign of both Contractor Integrated Technical InformationSystems (CITIS) and government technical information systems.This includes restricted access/change procedures, audit trails,and electronic marking of digital deliverables where appropriate.Aa an early contractual task, acquisition managers should requirethe contractor to provide a detailed plan that describes theprocedures and specifications to be used in the integration,digital exchange, and sharing of data with the government andother contractors, including satisfactory security requirements.Government technical information system managers must share withCITIS managers responsibility for protection of classified,proprietary, or otherwise sensitive information (see Appendix E).
5
MIL-HDBK-59
5. DETAILED GUIDANCE
5.1. Acquisition requirements. The integrated set of automateddata processing systems and applications that will be used by theweapon system contractor team to enter, update, manage, andretrieve data from specific weapon system technical data base(s)is called the Contractor Integrated Technical Information System(CITIS). The CITIS provides the automated data processingcapability used by the contractor(s) to accomplish weapon systemdesign, manufacture, and support processes. To take advantage ofcurrent contractor CITIS capabilities, the government acquisitionmanager should request contractor proposals such as thosedescribed in the following paragraphs. These contractor propo-sals will be evaluated for their cost and quality implications aspart of the source selection process, and required under thesubsequently awarded contract. This section describes contractrequirements that could reasonably be expected to result fromthis process.
5.1.1. General contract requirements. The solicitation orcontract should state that an objective of the acquisition is torequire the contractor to generate information products from alldevelopment and production functions in an integrated informationsystem and a shared data environment. Ideally, this integrationshould be achieved as part of a comprehensive concurrentengineering strategy. The integrated environment will providefor generation, storage, indexing, distribution, and delivery oftechnical data products, and support weapon system developmentand production functions and processes. The objective is tocreate each data element once and use it repeatedly in subsequentprocesses without manual re-entry. The contractor should berequired to provide and adhere to a comprehensive plan formeeting this objective.
5.1.2. Contract implementation of digital data sharing andexchange. The contractor's CITIS should provide for the integra-tion, digital exchange, and sharing of data with the governmentand associated contractor(s). CITIS data base(s) should have thecapability of distinguishing among, and providing visibility andaccessibility of, the following data iterations:
o Working Data - Government may be provided a read onlycapability for in-process review of selected initial orchange data/information (using partitioned data basesor other appropriate techniques), as negotiated.
o Submitted Data - The CITIS storing data released forreview and approval must provide a method for incorpor-
6
NIL-HDBK-59
ation of government-proposed changes and feedback toworking data files, while maintaining version controland protection against unauthorized changes.
o Approved Data - Data that have been reviewed andapproved by the government or appropriate designee andrequires additional controls against unauthorizedchanges.
The contractor plan should provide a cost effective method ofmanaging the CITIS such that appropriate configuration andversion control of technical information is maintained, whileproviding current data for design, engineering analysis,manufacturing, and product support planning. The plan shouldaddress capabilities for digital demand reproduction ofCAE/CAD/CIM/logistic technical data, and provide for digitalexchange and integration among the logistics and other functionalareas.
5.1.3. CALS integration of Computer Aided Engineering (CAE),Computer Aided Design (CAD), and Computer Integrated Manufac-turing (CIM). The contractor should be required to provide for. integration of logistics processes with CAE, CAD, and CIMprocesses. This includes other computer aided technologies, suchas computer aided testing (CAT) and computer aided processplanning (CAPP). This will assure that logistic resources aredeveloped consistent with the configuration of the weapon systemand changes thereto. Process integration should be accompaniedby integration of the CITIS data elements supporting thoseprocesses. This will facilitate both integration of theseprocesses, and configuration control of the data that supportsthe processes. Changes in the as-designed, as-manufactured, as-delivered, and as-supported configurations of the product can bereduced, associated technical data changes can be bettercontrolled, and the quality of both the product and data aboutthe product will be improved.
5.1.4. Reliability, maintainability, and supportability. Theinclusion of CAE capability in support of reliability andmaintainability (R&M) development is best accomplished by makingCAE support of R&M a source selection factor. The contractorshould be required to describe the intended use of computersystems to provide:
a. Automated R&M analysis procedures tightly coupled toparts libraries and to material characteristics databases.
i7
XIL-HDBK-59
b. Automated R&M synthesis based on design rules incorpor-ating lessons learned from prior design experience andfield use.
c. Fully characterized (tested and validated) componentperformance and R&M characteristics data bases.
d. Consistent data management procedures that link majordesign decisions affecting the R&M characteristics ofthe end item to the CAE software and data bases used todevelop decision criteria and otherwise support theevolving configuration of the product.
e. A structure of hardware, software, and computer net-works adequate to support the procedures and processesof "a" through "d" above, and to closely couple R&Mspecific resources (including personnel) with the restof the design team.
5.1.5. Integrated Logistic Support (ILS) management information.The contractor should be required to establish an on-line directaccess system capable of recording, planning, scheduling, andreporting status of ILS program requirements. This system shouldprovide visibility of the contractor's logistic support develop-ment performance, highlighting potential problems, and shouldprovide schedule compatibility to assure logistic supportintegration. The on-line system should identify change impactson related areas of logistic support and status of retrofitprogram deliverables.
5.1.5.1. Interim/phased contractor support. The contractorshould be responsible for providing on-line detailed status andaccounting for interim/phased support programs as contracted.This will include status of all items inducted into a repair ormaintenance program. Program status and accounting should beprovided by digital means for accountability, and allow fortransitioning interim support to the customer. The contractorshould be required to conform with exchange standards for digitaldata transmissions between government and contractor activities.
5.1.5.2. Government furnished equipment and information. Thecontractor should provide for update and maintenance of thegovernment furnished equipment portions of the weapon systembased on government review, and for input of other governmentfurnished information such as usage data and reports of installedpopulation by operating site. Wherever possible, governmentfurnished information should be provided in digital form fordirect input into the CITIS.
8
0 MIL-HDBK-59
5.1.6. Supplier/vendor/subcontractor data requirements. Thecontractor should provide for capture and incorporation ofrequired supplier/vendor/subcontractor data. This should includeconsideration of the capability of the supplier to use neutralinterchange standards to deliver digital data that is compatiblewith the structure of prime contractor's CITIS where appropriate.It should also include alternatives such as providing terminalsand/or access to lower tier subcontractors.
5.1.7. Logistic Support Analysis (LSA) and Logistic SupportAnalysis Record (LSAR). The contract should require that datagenerated from the LSA program in accordance with MIL-STD-1388-1and maintained in the LSAR in accordance with MIL-STD-1388-2 bethe basis for logistics resource determinations.
a. Support equipment - The contractor should be able torespond to government agency requirements forsubmission in digital form of support equipmentrecommendation data, with provision for visibility ofgovernment changes/approvals without loss of originaldocumentation.
b. Technical manuals/data - The contractor should providefor computer assisted generation of technical data.These data are to be derived, to the maximum extentpossible, from integrated digital data files, e.g.,CAD/CAE/CIM/LSAR. These data should be provided inaccordance with contractually imposed functionalspecifications for technical manuals and other data(e.g., MIL-M-38784), the appropriate technicalspecifications (e.g., MIL-M-28001), in conformance withMIL-STD-1840.
c. Training and training equipment - The contractor shouldprovide training system development with data generatedand derived, to the maximum extent possible, from LSARin accordance with MIL-STD-1388-1/-2 and from technicaldata in 5.1.7.b.
d. Supply support - The contractor should provideprovisioning technical documentation in accordance withMIL-STD-1388-2 to facilitate automated ordering, supplymanagement, and distribution, and should provide on-line identification of spares, repair parts, andsource/maintenance/recoverability coding linked toprovisioning technical documentation.
e. Facilities - The contractor should provide facilities
requirements data in digital form.
9
MIL-HDBK-59
5.2. Acquisition of digital data products. This sectionprovides guidelines for acquisition (including both delivery andaccess) of weapon system engineering and integrated logisticsupport data in digital form. Appendix B applies this decisionprocess to specific logistic functional areas and data products,such as technical manuals and engineering drawings. Appendix Dprovides additional guidance on delivery and access mode options.
5.2.1. Acquisition considerations. CALS is a strategy foraccomplishing the transition from paper-intensive weapon systemsupport processes to an automated and integrated form. It is nota mandate to accomplish all data acquisition digitally, regard-less of other considerations. The acquisition manager must basedecisions concerning acquisitions of data in digital form in anylife cycle phase on acquisition policy, on technologyavailability, and on analysis of costs and benefits.
5.2.1.1. Data acquisition policy. DoD component policies anddirectives regarding the acquisition of digital data deliverablesmay govern preferred choices for specific applications and weaponsystem programs. These policies may address specific acquisitionstrategies, prime contractor/sub-tier contractor/vendor relation-ships and capabilities, existing Department/Agency automated dataprocessing systems and other technical investments, future plansfor automated CITIS and government systems, or other managementconsiderations. Acquisition managers should contact theappropriate Military Department or Agency CALS Office listed inAppendix A for the most current policy directives to determinewhether certain categories of data are already mandated forprocurement as digital document images, processable files, or on-line access.
5.2.1.2. Available technology. The availability of digital dataprocessing and telecommunications technology, and approvedstandards for creation, storage, transmission, data protectionand integrity, etc., of data at the time of delivery or accessare important criteria for acquisition decisions. The currentand projected capabilities of both the contractor and DoDagencies (Service and Defense Logistics Agency) must be assessedwith respect to program needs and schedules. Acquisitionmanagers should plan to acquire digital data products rather thanhard copy unless a clear case can be made that the costs willoutweigh the life cycle benefits.
5.2.1.3. Heterogeneous environment. The rapid introduction ofnew technology will cause DoD and industry to operate in a mixed-mode, heterogeneous environment for many years. Some contractorswith advanced capabilities will be on the leading edge of CALSIWSDB technology well before DoD is ready to put IWSDB specifi-
10
MIL-HDBK-59
cations and standards in place. Many contractors are ready toimplement current technology now, but will lag in the implemen-tation of future capabilities. DoD has some near term CALScapabilities in place, but generally is not yet ready to takeadvantage of all of the technology that is routinely used bydefense contractors. And there is still a legacy of hard copytechnical data: data produced for older weapon systems and stillbeing maintained in hard copy form, harA copy data beinggenerated now in response to contract requirements establishedseveral years ago, and hard copy data that will be generated inparallel with the introduction of digital data technology.Government must be prepared to support all of these technologylevels, and contractor teams must expect to deal with severaldifferent levels of capability among team members.
5.2.1.4. Cost/benefit analysis. Large productivity and qualitygains are typically realized when technical data are created,stored, distributed, and used in digital form. However, initialinvestment expenses in automation and integration may not beoffset by accrued benefits until later in the weapon system lifecycle. It is important that the acquisition manager requestbidders to provide comparisons of costs, cost avoidances, andO benefits for alternative approaches for deliverables in theirproposal. These comparisons should identify significant costsand benefits that are expected to accrue or be avoided throughoutthe weapon system life from both a contractor and governmentperspective, and the associated risks and tradeoffs. Theanalyses should be based upon program-specific guidance andfactors provided by the government, and consider governmentplanned capabilities to receive, distribute and use digitaltechnical information. Results of the analyses should enable theacquisition management to assess relative risk as well as com-parative costs, anticipated benefits, and return of investmentsassociated with implementing each alternative.
Estimated costs should reflect all significant investments,transition, and operating expenses associated with the variousCALS alternative approaches. Time-phased estimates of cost mayconsider, where applicable, categories such as:
a. Capital costs associated with new equipment requiredfor implementation and use.
b. One-time and recurring costs for equipment operation,maintenance, and user training.
c. Contractor data creation costs.
* d. Delivery and access expenses.
11
MIL-HDBK-59
e. Government distribution and use costs.
f. Ongoing data update, storage and maintenance costs.
Benefits should be identified in terms of anticipated improve-ments in productivity and military operations.
a. In terms of productivity, identify cost savings oravoidances associated with labor, materials and equipment,as well as time reduction for the actual data creation,delivery, distribution, update, maintenance, and use oftechnical information. In addition, program scheduleimpacts should be evaluated. For example, the ability toexpedite engineering change proposals within full scaledevelopment may help to reduce the overall development time,or at least reduce the risk of costly program slippages.Other benefits associated with improved functional processesand technical information should be identified (andquantified if at all possible).
b. Improvements to military operations may result due toincreases in weapon system quality and performance, dataaccuracy, industrial and military responsiveness, readinessand sustainability. For example, fewer design problemsshould lead to more producible, reliable, maintainableweapon systems which ultimately eZfects readiness andsustainability. Improved data accuracy in technical manualsshould improve the responsiveness and effectiveness of themaintenance process. Estimates of benefits shculd bequantified where possible.
To the extent practical, the acquisition manager should includeprovisions for tracking costs and benefits as they accrue duringthe period of contract performance. Similar systems should beestablished within the government in order to gain a betterunderstanding of the actual costs and benefits associated withCALS implementations.
5.2.2. Life cycle phases. The weapon system's life cycle andacquisition phase are major factors in most digital data acquisi-tion decisions. All of the potential applications for the datathroughout the life cycle must be considered early in theacquisition process. The contractor must have time to put inplace the automated tools to create information in theappropriate digital form for future government delivery oraccess. The uses of the data change as the program progressesthrough its acquisition phases. In the early phases (e.g.,Concept Exploration and Demonstration/Validation) of a program,data volatility is a key issue, and design changes are a frequent
12
MIL-HDBK-59
occurrence. Interactive access may be preferable to staticreports that are quickly outdated.
5.2.2.1. Full scale development phase. As the program movesinto full scale development, the volume of changes that requireacquisition office approval rapidly increases. Interactiveaccess could be justified to permit faster turnaround of changeapprovals and to help the program maintain schedule.
5.2.2.2. Production phase. The majority of data is deliveredduring the production phase. The major data acquisition issuesbecome the volume and types of technical data being procured, andappropriate configuration management requirements. Major consi-derations for the acquisition manager are: how will the data beused during the operational and support phase, and how will thedata be delivered and distributed throughout the logisticsorganizations?
5.2.2.3. Operation and support phase. The operation and supportphase, which encompasses the longest period of time of any of thelife cycle phases, sees the greatest use of old data and acontinuing need for additional new data as product improvementsand other changes evolve. Acquisition managers must plancarefully for the government organizations' ability to receivedata in a form appropriate for its revision and use for manyyears downstream. Even if data was acquired through on-lineaccess to a contractor CITIS, physical delivery of the data mustbe planned for at some point, such as when the weapon systemfinally goes out of production.
5.2.3. Data processing categories. The acquisition manager mustconsider how data will be processed in order to make good deci-sions on digital data requirements and format. The five definedcategories of data processing typical of most weapon systemprograms are archive, view, annotate/excerpt, update/maintain,and process/transform. In the following discussion, the fivecategories have been sequenced by level of sophistication, fromsimple archiving to very complex information processing andtransformation.
5.2.3.1. Archive. Archiving is the placing of data in a reposi-tory to preserve it for future use. Data may be archived in hardcopy; however, future use of the data is enhanced when the dataare prepared in digital form on media that allows automatedretrieval. Digital data storage is also much more spaceefficient than any hard copy storage media. Legal questionsremain on the certification of electronic records (digital data)as originals in lieu of hard copy. Use of digital deliverables. may be limited for certain contract administration and accounting
13
MIL-HDBK-59
functions. Data quality is usually more important than whenimmediate use of the data is planned, because the data may not beretrieved until after the experts who created it are no longeravailable to correct shortcomings. Early identification of thedata repository for each life cycle phase is necessary to lay ttlefoundation for required government and industry access for weaponsystem support.
5.2.3.2. View. View is the ability to examine a data filewithout the ability to change it. It is the traditional serviceoffered by early automated systems. It normally offers theoptions of screen display or hard copy output from a printer.Modern workstations and terminals, however, often include a localstorage device, i.e., either a hard or floppy disk drive, so thatanything displayed on the screen or output to a printer orplotter can be stored locally for later retrieval at theworkstation without reestablishing a connection with the hostcomputer.
5.2.3.3. Annotate/excerpt. Annotate/excerpt is the ability toevaluate and highlight for future reference or to make annota-tions, approvals, and comments without the ability to change theoriginal file. The extraction of relevant data for use in otherdocuments, or for summarization purposes, is also provided atthis level. The essential difference between annotate/excerptand view is that annotations can be returned either as an overlayfile or as a revised original file for processing by the hostcomputer. This effectively allows changes to be made to the datawhile maintaining configuration control, although it is oftencumbersome. For audit trails and version control, theacquisition manager should consider archiving these overlay andbackup files, or requiring the contractor to do so throughappropriate contractual tasking.
5.2.3.4. Update/maintain. Update/maintain is the ability tochange data, either directly or through controlling software, inthe active files on the host computer. An example of this dataprocessing type would be updating the government furnishedequipment portion of an assembly drawing and associated partslists. The service life of weapon systems may extend for thirtyyears or more; this longevity means that the supporting data hasa similarly long life during which it must be updated,maintained, and controlled.
5.2.3.5. Process/transform. Process/transform is the ability toextract and modify the format, composition, and structure of thedata into another useable form. Process/transform entails themost complex processing of technical data. For example, computeraided design (CAD) data may be transformed into computer
14
MIL-HDBK-59
integrated manufacturing (CIM) data for making spare parts onnumerical control machines, or technical manual text and graphicsdata may be transformed into very specific troubleshootingmaintenance aids for weapon system repair.
5.2.4. Data acquisition decision process. Figure 1 is themaster template that should be used by the acquisition manager tosystematically determine how data should be delivered, or madeaccessible, to the government by the contractor. Applicationguidance for use of the master template for specific functionalareas is provided in Appendix B. The decision points on thetemplate are not always exclusive and indicate a range of alter-natives open to the acquisition manager. That is, selecting oneoption at a decision point for a particular data product withinone life cycle phase does not necessarily preclude the selectionof other options for that same or other data products in otherlife cycle phases. On each weapon system program, the deliverymedia and technical use for each data product, contract lineitem, and CDRL item must be carefully evaluated. The evaluationprocess involves making four sets of decisions, as shown infigure 1, and explained in the following text.
0 Decision #1 Decision 82 Decision #3 Decision #4
Deliverable Form Standards Mode
Hard Copy Existing StdsJDI~s
Text File Tx
tds.oPhysical Media Ad oaGraphics nI Graphic
Souce DaessFileApluel ie Telecommunicationsm Tlcm
Data FliesAudio/Visual File / -,-- ts
Integrated Data Fl ! ____nt-- -,*td
Preleffned Query Application Unique ."aAccess Ad Hoc ue Contractor Unique
Data 3tds.
. FIGURE 1. Decision template for acquisition of digital data.
15
MIL-HDBK-59
5.2.4.1. Decision 1 - data deliverable type. The first decisionpoint involves evaluation of three data deliverable types: docu-ments, processable data files, and interactive access. Thesethree types differ in their flexibility and in the variety ofdata applications they can effectively accommodate. The firstoption is a document (such as a drawing, manual, or report) ineither hard copy or digital form. Utility of documents is muchmore limited than the other deliverable forms because the datahas already been processed into a finished technical dataproduct. The second option is delivery of digital data as aprocessable data file. Such data files can provide the sourcedata for multiple data applications, allowing standard and customdocuments to be created, as well as allowing manipulation of thedata for annotate/excerpt or update/maintain purposes. The thirdoption is interactive access, which provides an agreed-upondegree of access to the contractor's CITIS data bases. Thisoption can provide the greatest flexibility of use, withimmediate and timely data access for custom report generation anddocument creation, as well as on-line transactions to requesttransmittal of information, via physical media, as documents orprocessable data files. The following guidelines apply:
a. If a data product is currently ordered as hard copy,consider its digital equivalent, a digital documentfile.
b. If a source data deliverable is currently ordered,consider a processable data file.
c. If drafts or preliminary data products are currentlyordered, consider on-line interactive access toannotate/excerpt the contractor's file to perform thereview and provide comments.
5.2.4.2. Decision 2 - data form. The next options are the formsin which each data deliverable type can be procured.
5.2.4.2.1. Document. As shown at the top of figure 1, thedocument options are hard copy (e.g., paper and microfilm), or adigital document image (e.g., raster) file for printout anddisplay. Both of these are static data forms. Application ofthis data is limited to archive, view, or annotate/excerpt only.The digital document image file option is more flexible than thehard copy option because the data can be more easily stored,transported, and managed. Neither hard copy nor digitaldocuments can be easily modified or updated.
5.2.4.2.2. Processable data files. As shown in tie middle offigure 1, the processable data files option provides a dynamic
16
MIL-HDBK-59
form of the source data with two possibilities: separated filesfor text, graphics, alphanumeric, and audio/visual data; orintegrated files consolidating the different data representations(text, graphics, etc.). Either can be much more easilymanipulated and changed by users than can digital documentimages. Text files may contain free-form or structured text,depending on users and intended applications. Manuals andreports are typical examples of text files. Graphics files maycontain illustrations, design data, schematics, etc., in vectorformat.
A technical data product delivered as digital data may contain acombination of data types and forms. The technology forconverting text in hard copy or digital document image form intoprocessable data files is rapidly maturing, and is becoming costeffective to apply in many applications. The technology forconverting document graphics into processable data is alsoimproving, but it is not yet as capable as the technology fortext conversion. The choice between processable vector graphicsand non-processable raster graphics is dependent on the creationand application of the data. For example, one alternative forcreation of a technical manual may be the combination of aprocessable data file of text, together with raster documentimage illustrations.
Whether processable data files are to be delivered as separate orintegrated files is largely dependent on technology, the func-tional application, and the data creation process. Technology toenable integration of separate text and graphics data files isprogressing rapidly. Appropriate data standards are emerging,although they are only beginning to enter the commercial market.
5.2.4.2.3. Interactive access. The options shown at the bottomof figure 1 present choices for interactive access into contrac-tors' CITIS data bases, either by predefined query methods, or bymore flexible ad hoc queries. Through interactive access, theuser can tailor presentation of the data to meet the user'simmediate needs. As the data are needed, they can be accessed intheir most current authorized version. Although this is the mostpowerful data type, its use is constrained by the cost ofavailable technology, and not all contractors have an automateddata processing infrastructure that provides interactive accesscapability. When interactive access is used, the absence ofstandardized access query tools among many CITIS data baseslimits the ability to use the ad hoc query form.
5.2.4.3. Decision 3 - specifications and standards. Relevantspecifications and standards must be selected to contract for the. technical and functional aspects of the data. The third colLnn
17
MIL-HDBK-59
of figure 1 presents available alternatives for the threedeliverable options. Here, the decision template becomesapplication-specific. In some cases, specifications and stan-dards apply to a single functional application; MIL-STD-1388-2 isa standard that applies only to logistic support analysisrecords, for example. In other cases, a single standard canapply to several functional applications; MIL-STD-1840 is astandard that defines data organization and file layouts fortechnical manuals, engineering drawings, and other types oftechnical data.
5.2.4.3.1. Functional and technical standards. In a paper-basedenvironment, functional requirements (what data to create) andtechnical requirements (how to organize and format that data in areport) were commonly combined in a single document. Thispractice has carried over into automated data processing, but nowit is gradually being changed. Computer programmers and usershave both found that separating functional requirements andtechnical requirements into separate standards makes it easier tomanage changes in technology. Functional specifications andstandards must be cited to govern the data creation process and,within the context of specific applications, determine the datacontents and structure. Examples of functional specificationsare MIL-M-38784 for technical manuals and DoD-D-1000 forengineering drawings. Technical specifications and standardsmust be cited to govern data structures and formats, filetransfer procedures, interchange requirements, and presentationformats. Examples of technical specifications are MIL-M-28001for technical manual text and MIL-D-28003 for technical manualvector graphics.
5.2.4.3.2. Predefined and ad hoc queries. Options for interac-tive access to contractors' data bases are shown at the bottom ofthe third column of figure 1. Distributed relational data basetechnology is so new, and is evolving so rapidly, that CITIS databases usually have unique data organizations and unique accessmethods, depending on what technology the contractor has imple-mented, and how recently the CITIS architecture was designed.'Many different data base management systems, data base querylanguages, and software systems support these access methods.The options for interactive access recognize this situation.Predefined queries, the first option, retrieve and displayinformation from the CITIS using formats that are tailored to aspecific application and fixed in advance. Some latitude isprovided by allowing user-defined keys to select, sequence, orsummarize data. However, the information retrieval requirementsare well defined in advance, and can be incorporated into theCITIS architecture even if this must be done in a CITIS-uniquemanner. The second option for interactive access is the ad hoc
18
MIL-HDBK-59
query. By definition, an ad hoc query is application-independent. Therefore ad hoc query options are driven bytechnology rather than application. This leads to twoalternatives for ad hoc queries: contractor-unique, and datastandards. Currently, the unique data access capabilities ofmany contractors' CITIS may require the acquisition manager toevaluate a variety of non-standard proposals for ad hoc queries.This is the first alternative, but it is not the long-termsolution.
5.2.4.3.3. Data standards. Data standards, the secondalternative for ad hoc queries, address emerging technology andstandards that govern the basic data, independent of theircreation processes and their internal relationships with eachsubcomponent. These concepts will form the basis for developmentand implementation of longer term CALS capabilities. The goal ofthese data standards is a neutral view of data that is consistentfor all applications needing the data. When this goal isachieved, data definitions, relationships, and rules for consis-tency and integrity will be controlled by a master data model andan active data dictionary, permitting uniform, standard accesstechniques for both computers and computer users. Data accessO methods can then be hardware and software independent, notrequiring the user to be familiar with multiple, different database access methods.
5.2.4.4. Decision 4 - digital delivery mods. The final optionsare the delivery modes in which to procure the technical data indigital form. The right side of figure 1 presents two alterna-tives for delivery: physical media and telecommunications.Physical media forms for delivery of digital data consist ofmagnetic tape, magnetic disk, and optical disk. Delivery ofdocuments or processable data using telecommunications is not thesame as interactive access, but rather is simply one-wayelectronic mail. Telecommunications delivery alternativesinvolve the selection of high-speed dedicated lines, public orprivate networks such as the Defense Data Network (DDN), orsatellite links. The best medium of delivery is dependent on ananalysis of data volumes, urgency, and frequency of use versusthe cost and security of each delivery medium. With currenttechnology, physical media transfer is generally the most cost-effective means of transferring large data files. Telecommuni-cation networks are in increasingly widespread commercial as wellas DoD use. However, CALS introduces new problems because of thevolume of digital data that will be transmitted, and associatedrequirements for data protection and integrity. Therefore,telecommunications is currently most appropriate for interactiveaccess or special low volume use.
19
MIL-HDBK-59
5.3. Contract deliverables. The contract statement of workshould task the contractor to prepare a CALS implementationstrategy, taking into consideration the assumptions andconstraints established by the acquisition manager. Supported bynecessary trade studies, this strategy should enumerate anddescribe the framework for CALS implementation activities to beaccomplished during each phase of weapon system development. Itshould list the technical data that will be acquired in digitalform, and describes the actions to be taken by the contractor toachieve functional process integration. The implementationstrategy will serve as a guide in developing contract require-ments in later program development phases. It should be updatedat the beginning of each program phase to define implementationplans for the upcoming phase in greater detail, resolveoutstanding strategy issues, respond to strategic changes, anddefine appropriate contract language for the upcoming developmentphase.
5.4. Data protection and integrity, data rights, and relatedissues.
5.4.1. Industry. Contractors may choose to limit access to datadocumenting products, procedures, and processes for which thegovernment or other contractors do not possess the data rights.In addition, much of the data documenting weapon systems issubject to technology transfer limitations, such as the ArmsExport Control Act, that impose restrictions on free release ofsuch data. Contractors must develop and follow procedures whichensure that digital data delivered to, or accessed by, thegovernment are properly marked and that controls and safeguardsin the digital environment provide at least the level of protec-tion provided in the paper-based environment. Where classifiedinformation is developed or used by industry, additionaloversight, programmatic controls, and special handling procedureswill be imposed by the acquisition manager, who will be supportedby an extensive community of security organizations. Technologyand standards are still being developed to address the newly-emerging issues associated with data protection and integrity ina digital environment. Procedures for ensuring data protectionand integrity are extensive; selected areas that require reviewduring planning for the acquisition of digital information arediscussed in Appendix E.
5.4.2. Government. The government must identify duringacquisition planning the procedures that should be developed foreffective management of classified, sensitive, or limited rightsdata. Successful implementation will require clear contractualagreement on how data will be safeguarded, both by the contractorand subsequently by the government. In addition, where govern-
200
KIL-HDBK-59
ment access of a contractor data base is desired, contractorswill be concerned about government access to data that have notbeen validated by the contractor, data the contains proprietaryinformation, and data that is outside the scope of thecontractual agreement. In such cases the government shouldconsider acquiring access to a separate data base of validateddata that has been delivered in place, until proven proceduresare developed for managing government access to contractor's datasystems.
5.5. Detailed guidance for applications. The preceding sectionprovides general guidelines for procurement and integration oftechnical data in weapon system acquisition contracts. Thetransition from paper to digital data deliverables and digitaldata access requires review and revision of traditional ways ofprocuring data, and development of new contractual approaches.To aid the acquisition manager in accomplishing the evolutionarytransition to a contractor/government shared data environment,initial CALS attention has been focused on functional areas thatare large generators or users of technical data. Appendices tothis handbook are provided for the following topics:
Appendix A, CALS Overview.
Appendix B, Application Guidance for Acquisition of DigitalDeliverables.
Appendix C, Functional Requirements for Integration ofContractor Processes.
Appendix D, Contract Requirements for Delivery Modes.
Appendix E, Data Protection and Integrity, Data Rights, andRelated Issues.
21
XIL-HDBK-59
6. NOTES
6.1. Intended use. The purpose of this military handbook is toprovide weapon system and equipment acquisition managers withgeneral information and detailed application guidance for con-tractually implementing Computer-aided Acquisition and LogisticSupport (CALS) requirements in weapon system and related majorequipment procurements. This military handbook also describesCALS, aids in the implementation of functional integrationrequirements for contractors, and provides guidance to facilitatethe generation, access, and delivery of digital technicalinformation.
6.2. Subject term (key word) listing.
Acquisition managementCADCAECALSCAMComputer-aided acquisition and logistic supportComputer aided designComputer aided engineeringComputer aided manufacturingComputer integrated manufacturingComputer securityContract requirementsContractor integrated technical information systemConcurrent engineeringCosts and benefitsData base managementData managementData protection and integrityIntegrated logistic supportLife cycleLogistic support analysisWeapon systems
22
MIL-HDBX-59APPENDIX A
* APPENDIX A
CALS OVERVIEW
23
MIL-HDBK-S90APPENDIX A
THIS PAGE INTENTIONALLY LEFT BLANK.
24
MIL-HDBK-59
APPENDIX A
10. SCOPE
10.1. Purpose. This appendix provides a detailed discussion ofComputer-aided Acquisition and Logistic Support.
20. REFERENCED DOCUMENTS
20.1. Government documents.
20.1.1. Specifications, standards, and handbooks. Unlessotherwise specified, the following specifications, standards, andhandbooks of the issue listed in that issue of the Department ofDefense Index of Specifications and Standards (DoDISS) specifiedin the solicitation form a part of this handbook to the extentspecified herein.
SPECIFICATIONS
MILITARY
DOD-D-1000 Drawings, Engineering and AssociatedLists
MIL-D-5480 Data, Engineering and TechnicalReproduction, Requirements for
MIL-D-8510 Drawing, Undimensioned, Reproducibles,Photographic and Contact, Preparation of(ASG)
MIL-M-9868 Requirements for Microfilming ofEngineering Documents, 35mm
MIL-D-28000 Digital Representation forCommunications of Product Data: IGESApplication Subsets
MIL-M-28001 Markup Requirements and Generic StyleSpecification for Electronic PrintedOutput and Exchange of Text
MIL-R-28002 Raster Graphics Representation in BinaryFormat, Requirements for
MIL-D-28003 Digital Representation for Communicationof Illustration Data: CGM Application
0 Profile
25
XIL-HDBK-59APPENDIX A
MIL-M-38761 Microfilm and Microfilm Frame Desk Usedfor Recording Engineering Drawings andAssociated Data
MIL-M-38784 Manuals, Technical: General Style andFormat Requirements
(Application for copies should be addressed to the Naval Publica-tions and Forms Center (NPFC), 5801 Tabor Avenue, Philadelphia,PA 19120 or Defense Communications Agency, DDN PMO (B613),Washington, DC 20305.)
STANDARDS
FEDERAL STANDARDS
FED-STD-1041 (FIPS PUB 100-1) Interface between DataTerminal Equipment and Data Circuit-Terminating Equipment for Operation withPacket-Switching Data CommunicationNetworks. (Adoption of CCITT Recommen-dation X.25).
FEDERAL INFORMATION PROCESSING STANDARDS
FIPS PUB 146 Government Open System InterconnectionProfile (GOSIP)
(Application for copies should be addressed to the Superintendentof Documents, Government Printing Office (GPO), Washington, D.C.20402, or the National Technical Information Service (NTIS) 5285Port Royal Road, Springfield, VA 22161.)
MILITARY
DOD-STD-100 Engineering Drawing Practices
MIL-STD-188-114 Electrical Characteristics of DigitalInterface Circuits
MIL-STD-470 Maintainability Program for Systems and
Equipment
MIL-STD-499 Engineering Management
MIL-STD-785 Reliability Program for Systems andEquipment Development and Production
MIL-STD-804 Formats and Codihg of Aperture Cards
26
MIL-HDBK-59
APPENDIX A
MIL-STD-1379 Military Training Programs
MIL-STD-1388-1 Logistic Support Analysis
MIL-STD-1388-2 DoD Requirements for a Logistic SupportAnalysis Record
MIL-STD-1777 Internet Protocol Standard
MIL-STD-1778 Transmission Control Protocol Standard
MIL-STD-1780 File Transfer Protocol
MIL-STD-1781 Simple Mail Transfer Protocol
MIL-STD-1782 TELNET Protocol Specificdtion
MIL-STD-1840 Automated Interchange of TechnicalInformation
MIL-STD-2165 Testability Program for ElectronicSystems and Equipments
HANDBOOKSMILITARY
MIL-HDBK-217 Reliability Prediction of ElectronicEquipment
(Application for copies should be addressed to the Naval Publica-tions and Forms Center (NPFC), 5801 Tabor Avenue, Philadelphia,PA 19120 or Defense Communications Agency, DDN PMO (B613),Washington, DC 20305.)
20.1.2. Other government documents. The following governmentdocuments and publications form a part of this military handbookto the extent specified herein.
FEDERAL
NSDD 145 National Policy on Telecommunications andAutomated Information Systems Security
MILITARY
DDN X.25 Host Interface Specification, animplementation of CCITT Recommendation X.25
27
MIL-HDBK-59APPENDIX A
(Application for copies should be addressed to the DefenseCommunications Agency, ATTN: DDN P1O, Code B600, Washington, DC20305.)
DoD-5200.28-STD DoD Trusted Computer System Evaluation
Criteria
DoD-5220.22-M Industrial Security Manual
NCSC STD-004-85 Guidance for Applying the Department ofDefense Trusted Computer SystemEvaluation Criteria in SpecificEnvironments
NCSC TG-005 Trusted Network Interpretation of theTrusted Computer System EvaluationCriteria
(Application for copies should be made to the Superintendent ofDocuments, U.S. Government Printing Office, Washington, DC20402.)
20.2. Other publications. The following documents form a partof this specification to the extent specified herein. The issuesof the documents that are indicated as DoD adopted shall be theissue listed in the current Department of Defense Index ofSpecifications and Standards (DoDISS) and the supplement thereto.
Electronic Industries Association (EIA)
EIA RS-232-C Interface between data terminal equipment anddata communication equipment employing serialbinary data interchange.
EIA RS-422-A Electrical Characteristics of BalancedVoltage Digital Interface Circuits.
EIA RS-449 General purpose 37-position and 9-positioninterface for data terminal equipment anddata circuit-terminating equipment employingserial binary data interchange.
(Application for copies should be addressed to the ElectronicIndustries Association, Standard Sales, 2001 I Street, NW,Washington, D.C. 20006.)
028
NIL-RDBK-59APPENDIX A
Network Information Center (NIC)
Request for Change (RFC) 826 An Ethernet Address ResolutionProtocol (IP address to mediaaccess control addresstranslation).
(Application for copies should be addressed to the ARPANETNetwork Information Center; SRI International, Menlo Park, CA94025.)
20.3. Order of precedence. In the event of a conflict betweenthe text of this handbook and the references cited herein, thetext of this handbook shall take precedeiLce.
29
MIL-HDBK-59
APPENDIX A
30. DEFINITIONS
30.1. Acquisition manager. The system/equipment programmanager, the program manager's staff, and other DoD officialsresponsible for determining contract requirements for thegeneration, acquisition, and use of weapon system/equipmenttechnical data, and having acquisition authority for weaponsystems and equipment.
30.2. CALS Core Requirement. The set of documents that definesthe environment necessary for Computer-aided Acquisition andLogistic Support (CALS) to function. These documents fall intothree basic categories: functional standards, technicalstandards, and data standards.
30.2.1. Functional standard. A document that establishes anddefines requirements for management, design processes,procedures, practices, methods, and data applicable to thecreation of data products.
30.2.2. Technical standard. A standard that controls the mediumor process of exchanging data between a sending and a receivingsystem. Data exchange is defined in terms of presentationformats and transformations of those presentation formats.Technical standards include document image standards; separategraphics, text, and alphanumeric standards; and integratedstandards.
30.2.2.1. Document image standard. A technical standarddescribing the digital exchange format of a print/display file ofa report or other document. (CCITT Group 4 and the proposedStandard Page Description Language are examples.)
30.2.2.2. Graphics standard. A technical standard describingthe digital exchange format of graphics data. (CCITT Group 4 andCGM are examples.)
30.2.2.3. Integrated standard. A technical standard describingthe exchange format of digital data which integrates text, gra-phics, alphanumeric, and other types of data in a single(compound) file. (ODA/ODIF is an example.)
30.2.2.4. Text standard. A technical standard describing thedigital exchange format of textual data. (SGML is an example.)
30.2.3. Data standard. A specific set of data entities,relationships among data entities, and their attributes, oftenexpressed in the form of a Data Dictionary and a set of rules
30
MIL-RDBK-59APPENDIX A
that govern data definition, data integrity, and dataconsistency. (The proposed PDES standard is an example.)
30.3. Information systems.
30.3.1. Source system. The computer hardware and software thatwill structure technical information for interchange.
30.3.2. Destination system. The computer hardware and softwarereceiving transferred data.
30.3.3. Government receiving system. The collective term forall government agencies and offices responsible for receiving,processing, reviewing, or approving technical data ordered ongovernment contracts, including the destination system.
30.3.4. Integrated Weapon System Data Base (IWSDB). The logicalcollection of shared data for a specific weapon system thatsupports both Contractor Integrated Technical Information System(CITIS) and government technical information system usersthroughout the weapon system life cycle. The physical locationof the data may be distributed among contractor or government. automated data processing systems.
30.3.5. Technical information systems. The generic term for theenterprise network of existing and augmented automated dataprocessing systems used by government and contractors formanagement of technical information in support of the design,manufacture, and logistic processes for products such as weaponsystems and related major equipment items.
30.3.5.1. Contractor Integrated Technical Information System(CITIS). The collection of automated data processing systems andapplications used by the co:tractors (i.e., the prime(s) and allsubcontractors) to enter, update, manage, retrieve, anddistribute technical data from a specific Integrated WeaponSystem Data Base.
30.3.5.2. Government Technical Information Systems. Thecollection of automated data processing systems and applicationsused by government agencies and offices to enter, update, manage,retrieve, and distribute technical data from a specificIntegrated Weapon System Data Base.
30.4. Technical data. Information including CAD data, CAE data,CIM data, configuration management data, group technology data,process planning and control data, engineering design data, billof materials data, inventory data, and technical publications. data.
31
MIL-HDBK-59APPENDIX A
30.4.1. Product data. All data elements necessary to define thegeometry, the function, and the behavior of a piece part or anassembly of parts over its entire lifespan. The term includesall product definition data elements as well as additionallogistics elements for reliability and maintainability.
30.4.2. Product definition data. The totality of data elementsrequired to completely define a product. Product definition datainclude geometry, topology, relationship, tolerances, attributes,and features necessary to completely define a component part oran assembly of parts for the purposes of design, analysis,manufacture, test, and inspection.
30.4.3. Product data exchange specification (PDES). Proposedstandard for communicating a complete product model withsufficient information content so as to be interpretable directlyby advanced CAD/CIM applications such as generative processplanning and CAD directed inspection.
30.4.4. Engineering data. Any data, either government,contractor, or vendor, that contain authoritative engineeringdefinition or guidance on material, items, equipment systempractices, methods, and processes relating to the design,manufacture, acquisition, test, inspection, or maintenance ofitems or services. Engineering data includes the following:drawings, associated lists, contractor or vendor specifications,standards, documents referenced on drawing lists, revisionauthorization documents, engineering change orders, government orindustry associated specifications and standards, and otherrelated documents.
30.5. Contract data deliverables and access.
30.5.1. Document. A set of text or graphics technical dataorganized and formatted for direct human interpretation. A docu-ment can be delivered as printed pages or digitally in the formof composed page images. Technical data supplied in documentform are not intended for subsequent processing ortransformation.
30.5.2. Document Image File. A file of composed page images indigital form. Examples are raster image files and pagedescription language files.
30.5.3. Processable Data File. Alphanumeric, text, graphics orintegrated data files organized and formatted so that anautomated data processing system can further structure orrestructure the data in a variety of ways. Unlike document imagefiles, processable data files may contain information that isdirectly machine-interpretable. Processable data files provide
32
MIL-IBX-59APPENDIX A
additional flexibility of use because they consist of the digitalsource data from which documents of varying types can beproduced.
30.5.4. Interactive Access. The ability to access authorizedportions of the source data in a CITIS or government system viaon-line telecommunications data transfers in real or near-realtime using various types of queries. Interactive access can beused to generate documents, processable data files, or both.Data processing categories for interactive access cover theentire range from view only to the full capability of down-loading data for subsequent processing and transformationpurposes. Interactive access also includes on-line transactionswhich request transmittal of information via physical media asdocuments or processable files.
30.6. File types.
30.6.1. Alphanumeric File. A data file containing structurednumeric or alphanumeric fields. Data base files are alphanumericfiles.
30.6.2. Text file. A file which uses the American Standard Codefor Information Interchange (ASCII) or similar system torepresent the text of a document. Data within a text file aredelineated as human readable words, sentences, and paragraphsrather than data elements.
30.6.3. Text/Graphics integration. The necessary indexing andlinkages between a computer readable text file and computerreadable graphics file so that they can both be output or updatedas a single, apparently continuous, file.
30.7. Aoronyms and abbreviations. The acronyms andabbreviations used in this military handbook are defined asfollows:
ANSI - American National Standards InstituteASCII - American Standard Code for Information InterchangeCAD - Computer Aided DesignCAE - Computer Aided EngineeringCALS - Computer-aided Acquisition and Logistic SupportCCITT - International Consultative Committee on Telegraphy and
TelephonyCD-ROM - Compact Disk-Read Only MemoryCDRL - Contract Data Requirements ListCGM - Computer Graphics MetafileCIM - Computer Integrated Manufacturing. CITIS - Contractor Integrated Technical Information SystemDDN - Defense Data Network
33
KIL-RDBK-59APPENDIX A
DID - Data Item DescriptionDLA - Defense Logistics AgencyDoD - Department of DefenseEDI - Electronic (business) Data InterchangeFIPS - Federal Information Processing StandardGOSIP - Government Open Systems Interconnection ProfileIGES - Initial Graphics Exchange SpecificationILS - Integrated Logistic SupportIP - Internet ProtocolISD - Instructional Systems DesignIWSDB - Integrated Weapon System Data BaseLAN - Local Area NetworkLSA - Logistic Support AnalysisLSAR - Logistic Support Analysis RecordODA/ODIF - Office Document Architecture / Office Document
Interchange FormatOSD - Office of the Secretary of DefenseOSI - Open Systems InterconnectionPDES - Product Data Exchange SpecificationPDL - Page Description LanguageR&M - Reliability and MaintainabilityRFP - Request for ProposalSGML - Standard Generalized Markup LanguageSOW - Statement of WorkSPDL - Standard Page Description LanguageTCP - Transmission Control ProtocolTDP - Technical Data Package
34
MIL-HDBK-59APPENDIX A
40. OVERVIEW OF COMPUTER-AIDED ACQUISITION ANDLOGISTIC SUPPORT (CALS)
40.1. CALS overview. Computer-aided Acquisition and LogisticSupport (CALS) is a Department of Defense (DoD) and industrystrategy to facilitate the integration of digital technicalinformation for weapon system acquisition, design, manufacture,and support functions. The Deputy Secretary of Defense launchedthe DoD CALS initiative in September 1985 and established a DoDSteering Group to oversee its implementation. CALS will providean effective transition from current paper-intensive weaponsystem acquisition and support processes to the efficient use ofdigital technical information. CALS will reduce acquisition andoperating costs, shorten lead times for acquisition and logisticsupport, and thereby improve military readiness and combateffectiveness.
40.1.1. CALS requirements. Both DoD and industry are investingin automation of a variety of functional areas to achieveproductivity and quality gains. Existing islands of technicaldata automation within DoD, between DoD and industry, and withinindustry must be interfaced and integrated to reduce duplicativeO data generation and maintenance, and to eliminate requirementsfor expensive hard copy output and reentry of data. CALSaddresses requirements for an orderly transition from a labor andpaper-intensive environment to the use of digital technicalinformation for design, manufacturing, acquisition, and supportprocesses.
40.1.2. CALS strategy. To achieve CALS benefits, a phased CALSstrategy has been established by a team consisting of Office ofthe Secretary of Defense (OSD), the military departments, theDefense Logistics Agency (DLA) and industry. The key elements ofthat strategy are:
a. Standards and integration requirements. Accelerate thedevelopment and testing of standards for digitaltechnical data interchange and integrated data baseaccess.
b. Weapon system applications. Implement CALS standardsin weapon system contracts and encourage Industrymodernization and integration.
c. Technology development and demonstration. Sponsor thedevelopment and demonstration of the necessarytechnology for integration of technical data and
* processes in high risk areas.
35
MIL-HDBK-59APPENDIX A
d. DoD systems. Implement CALS standards and integrationrequirements in DoD planning and infrastructuremodernization programs. Infrastructure is theunderlying framework of organizations, systems andprocesses within which DoD operates.
40.2. CALS concepts. The CALS system of systems approach, shownin figure 2, consists of these key elements:
a. Industrial systems (i.e., design, manufacturing, andcustomer support).
b. Government systems, (i.e., acquisition and logisticsupport).
c. Interfaces between industry and government.
d. Interfaces within industry among prime contractors,subcontractors, and vendors.
Information can pass between these systems, in both directions,in the form of documents, processable data files, and interactiveaccess to data bases.
40.2.1. CALS standards. Three broad groups of requirementsdocuments constitute the CALS interchange standards shown infigure 2. They are:
a. Functional Standards. Military standards, militaryspecifications, and Data Item Descriptions (DID's)which define functional processes, data requirements,data creation procedures, and the content and format ofdata products.
b. Technical Standards. Federal standards, militarystandards, military specifications, and other relevantconventions (including their associated DID's) for themanagement, formatting, and physical media or telecom-munications exchange of text, graphics, alphanumerics,and other forms of digital data.
c. Data Standards. Data dictionaries that provide rulesgoverning data element definitions, data relationships,and requirements for data integrity and consistency.The standards also include file structure definitions,index keys, and other descriptive information neededfor access to data bases.
36
NIL-HDBK- 59APPENDIX A
INDUSTRY GOV ,ERNMENT
LS AD REPOSITORIPU S
DOCUM ENTS ARMY PROCUREMENT
PROCESSABLE NAVYPLYPRIME DATA FILES USAF
CONTRACTOR INTERACTIVE DLA
AC-WCCES Other FederalAgencies
FUNCTIONAL INTERCHANGE UINTEGRATION STANDARDS
REQUIREMENTSnl Stada REQUIREMENTSR UI0 Technical Standards
FIGURE 2. Digital information exchange.
40.2.2. Functional integration requirements. A major CALSobjective is a standardized approach for integrating technicaldata use within a weapon system program. Functional integrationrequirements are contractual tasks to be used in statements ofwork (SOW) or incorporated in functional standards articulatingthe required contractor capabilities for the integration of datasystems and processes. These requirements specify theintegration of design, manufacture, and support processes, aswell as other elements of concurrent engineering, for theperformance of DOD contracts. They also establish the means bywhich contractors will demonstrate the capability to access andshare data bases among and between functional areas. Thesefunctional requirements will eventually be incorporated inupdates to appropriate military standards and specifications.The model SOW language in this handbook is provided for use. pending these updates.
37
MIL-HDBK-59APPENDIX A
4C.&-.;. Cont:nctor Integratad Technical inforation System(CITIS). As CALS capabilities evolve, technical data required bythe government for a single weapon system will be logicallyintegrated (not necessarily physically integrated) into tightlycoupled, controlled, and secure weapon system technical databases, allowing access and transfer of data to those parties withproper authorization and need to know. The integrated automateddata processing systems and applications that are utilized by thecontractor to enter, update, manage, retrieve, and distributedata from technical data bases for a specific weapon system iscalled a Contractor Integrated Technical Information System(CITIS). The required functional integration of those contractorprocesses necessary to ensure the security, currency, andaccuracy of the technical information resident in the weaponsystem technical data bases will be articulated and contractuallyspecified as requirements for the contractor's CITIS. Inaddition to requiring integration of the contractor's internaldata and processes themselves, further integration of internalcontractor data and processes with the government furnishedinformation for each weapon system is essential.
40.2.4. Government Technical Information Systems. Thecollection of automated data processing systems and applicationsthat are utilized by the government to enter, update, manage,retrieve, and distribute data from technical data bases for aspecific weapon system will exist on multiple distributedautomated data processing systems. It will cross functionalboundaries and may combine data from more than one DoD componentto support all requests for data from a single weapon system'suser community. This degree of interchange and integration willrequire tight control and coordination of the separate physicaldata bases to allow transparent support to the user. The neededcontrol and coordination within and among the CITIS andgovernment systems supporting a weapon system will be provided bya logical data structure called the CALS Integrated Weapon SystemData Base.
40.2.5. CITIS and government technical information system datafor common items. Technical data for subsystems or componentswith multiple weapon system applications must be available tousers without unnecessary storage redundancy. Hence, the issuesof integration and standards for data exchange and access arejust as applicable horizontally across weapon systems as they arevertically within the integrated technical data infrastructurefor a single weapon system.
40.2.6. Technical data and business data. CALS deals withtechnical data, which includes CAD/CAE/CIM and configurationmanagement data, group technology and process planning/controldata, engineering design and bill of materials data, inventory
38
0 MIL-HDBK-59APPENDIX A
data, and technical publications data. Another key aspect ofinformation interchange in digital form deals with businesstransactions for ordering, shipping, and making payment for theproducts described by CALS technical data. Business data indigital form is addressed by DoD's electronic data interchange(EDI) program, which also implements approved national standards(ANSI X.12) and reflects a common government and industrymigration to a digital commercial environment. CALS will developEDI transaction sets for accessing and ordering technical datafrom remote data bases, and for enveloping technical datapackages and exchanges of technical information within anenterprise network.
40.2.7. Concurrent engineering. Concurrent engineering is asystematic approach to creating a product design that considersall elements of the product life cycle from conception throughdisposal. In so doing, concurrent engineering simultaneouslydefines the product, its manufacturing processes, and all otherrequired life cycle processes, such as logistic support. Concur-rent engineering is not the arbitrary elimination of a phase ofthe existing, sequential, feed-forward engineering process, butrather the co-design of all downstream processes toward a moreO all encompassing, cost effective optimum. Nor does concurrentengineering entail simultaneous design of the product andexecution of the production process, an approach which isdemonstrably unsound. Concurrent engineering is an integrateddesign approach that takes into account all desired downstreamcharacteristics during upstream phases to produce a more robustdesign that is tolerant of manufacturing and use variation, atless cost than sequential design. It affects all systemprocurement activities from Milestone 0 (concept definition andexploration) to the start of Milestone III (the end of full scaledevelopment).
There are three dominant approaches being taken by contractorstoday to implement elements of concurrent engineering:
a. Engineering process initiatives to improve theorganizations and procedures used to develop a product,such as formation of design teams that include peoplefrom multiple disciplines.
b. Computer-based support initiatives such as improvementof computer aided design tools, leading to integrationof various software applications and supporting data.This is part of a broader objective to create a dataobject once, and use it as a source for many functionsand processes, including design synthesis and verifica-tion, production planning, and logistic supportplanning.
39
MIL-RDBK-59APPENDIX A
C. Use of a variety of formal methods, including theapplication of special purpose tools for design andproduction support. Examples include statisticalprocess control, design of experiments, design forassembly, and Taguchi quality engineering.
CALS initiatives to improve technical data creation, management,and use provide an enabling environment tha. will accelerate theapplication of concurrent engineering concepts, and theirconsequent benefits. These benefits include the opportunity forsignificant reductions in product development cycles, a widerange of cost savings, and substantial improvements in productquality. Specific CALS thrusts, such as integration ofreliability and maintainability (R&M) with computer aided design(CAD) and computer aided engineering (CAE) will directlycontribute to application of concurrent engineering concepts.
40.2.8. Integration of R&M with CAD and CAE. Integration of R&Mwith CAD/CAE is a high leverage, high payoff CALS target whichwill provide significant improvements in the inherent reliabilityand maintainability characteristics of a weapon system's design.These gains will translate into greater operationaleffectiveness, and will decrease life cycle costs associated withthe weapon system when deployed. Integration of R&M tools withthe CAD/CAE process is a contributor to a comprehensiveconcurrent engineering strategy, whose objective is designoptimization through integration of R&M and other domains withina cost effective engineering process. R&M integration withCAD/CAE will require changes to conventional post design analysisprocesses. These changes will consist primarily of thefollowing:
a. The development of user-friendly analytical tools thatare tightly coupled to the product design data base andthat can be rapidly executed by the designer to provideshort-cycle feedback about the effectiveness of thedesign approach during the design process itself.
b. The development of effective means to take advantage oflessons learned from prior design experience and fielduse in the form of design rules, expert systems, etc.
c. The development of fully characterized componentdesign, performance, and reliability data in a formatreadily accessible by these automated tools.
For further details see Appendix C.
40
MIL-RDBK-59APPENDIX A
40.3. CALS implementation. CALS is organized into twooverlapping phases which are characterized by the application ofdifferent levels of technology to technical data management, andby different degrees of impact on functions and processes allowedby this enabling technology. Near term implementation focuses onconverting current paper flows to digital form while beginningthe integration process. Longer term implementation focuses onreplacing the parallel and duplicative requirements imposed byvarious acquisition disciplines and functions (e.g., designengineering, configuration management, integrated logisticsupport, test and evaluation, etc.) with requirements to developintegrated weapon system data bases that are implemented throughCITIS and government technical information systems. These CALScapabilities will allow technical data sharing at the data baselevel, rather than at the physical file level, with multipleformats of the same data from a common, configuration-controlledsource available to different users. This will include theinformation needed for product design, engineering analysis,manufacture, and bupport, and will facilitate application of acomprehensive concurrent engineering strategy by makinginformation accessible to a variety of industry and DoD usersthrough automated and highly integrated means. However, CALSOimplementation will be characterized by a heterogen-ius, mixedmode environment in which initiatives at different l-vels oftechnology often will be implemented in parallel as evolving.capabilities allow.
40.3.1. Near term CALS capabilities. Initial implementationfocuses on exploiting current and near-term technology to enhancethe highest impact acquisition and logistics functions; specifi-cally, it focuses on:
a. Engineering drawings and other information used tosupport competitive spares procurement.
b. Technical manuals and other information used to supportweapon system raintenance.
c. Logistic Support Analysis Records (LSAR's) and otherinformation used to plan logistic support.
d. Life cycle configuration management of weapon systemtechnical information.
e. Automated interfaces among R&M data, logistics, systemengineering, and CAD.
40.3.1.1. Near term CALS events. In these early implementation.activities, application of technical standards will permitdigital data interchange in neutral format within and among DoD
41
MIL-HDBK-59APPENDIX A
components, and between DoD and industry. This interchange oftechnical data without resorting to paper products will result inincreased accuracy and timeliness of data transfer at lowercosts. Wherever possible, DoD is adopting approved national andinternational standards rather than creating unique DoD protocolsto define this interface. From a technical perspective, CALS isapplicable to equipment items at all levels of indenture, fromthe weapon system and weapon system platform to piece parts.However, CALS will find its most productive initial applicationsat the weapon system level, where the contractor and governmentinfrastructures to use these technical standards are already inplace or planned.
40.3.1.2. Near term CALS mechanisms. The mechanism forimplementing these near term capabilities is a set of corerequirements (i.e., sample contract language and technicalstandards) that will be used by the DoD components in near-termweapon system and data system acquisitions. The initialstandards have been coordinated throughout DoD and the defenseindustry, and published as MIL-STD-1840, along with associatedmilitary specifications. Although it was published before CALSwas established, MIL-STD-1388-2 is also considered to be one ofthe CALS technical standards. This handbook is a companiondocument to the CALS standards that provides initial CALSimplementation guidance to the acquisition manager..
40.3.1.3. CALS military specifications. CALS technicalstandards are being developed and published incrementally toprovide additional levels of functionality and technicalcapability. MIL-STD-1840 provides data interchange and filemanagement requirements for a family of supporting militaryspecifications. The specifications already published includeMIL-D-28000, MIL-M-28001, MIL-D-28002, and MIL-R-28003 (20.1.1).As other CALS military specifications are developed, thishandbook will be updated to provide necessary applicationguidance.
40.3.2. Longer term CALS capabilities. While near term CALSimplementation converts current paper flows to digital flows in afile transfer environment, longer term objectives target newfunctional capabilities that will be achieved through redesign,integration, and consolidation of the numerous parallel, duplica-tive processes that have grown up in our current paper-basedculture.
40.3.2.1. CALS integrated data bases and processes. CALS willexploit the additional emerging power of the computer byredesigning data formats and integrating what are now separateand often redundant collections of data. These actions willfully integrate support into the design process, as well as S
42
MIL-HDBK-59APPENDIX A
develop a variety of logistics data products from a design database. This integration will produce large savings inproductivity and result in improved readiness through muchimproved planning and support. CALS integrated data bases andprocesses will be designed to the extent feasible throughindustry cooperative efforts, because industry must implementmost of the systems to create this capability.
40.3.2.2. CALS Integrated Weapon System Data Base (IWSDB). Thelogical collection of shared data for a specific weapon systemthat is contained within CITIS and government data bases, and isused throughout the weapon system life cycle is called an IWSDB.The physical location of the data may be distributed amongcontractor or government automated data processing systems. TheCALS IWSDB structure is evolving and will be the basis for theintegrated, shared data environment. The CALS IWSDB will providea logical (not physical) collection of shared data to supportboth CITIS and government users throughout the weapon system lifecycle. The IWSDB will be governed by an active data d.ctionaryimplemented through standards such as the InformationRequirements Dictionary System, and will be consistent with CALSdata standards, including PDES as well as data standards tocontrol support data. The data standards will provide dataelement definitions, together with the data relationships andrules for data integrity and data consistency required toaccommodate the changes in user requirements and computertechnologies that are inevitable throughout the 20 to 40 yearlife of the weapon system.
40.3.2.3. CALS technology development. CALS must evaluatealternative technology approaches before committing to full-scaleimplementation of the IWSDB concept. This is being done througha series of technology R&D and demonstration programs that havebeen prioritized to facilitate the transition from interfaced tointegrated systems and processes. Key development areas includeadvanced product data technology for CAD/CAE/CIM, electronictechnical manual creation and delivery systems, concurrentengineering and integration of R&M with design, and telecommu-nications/gateway access to parts data bases.
40.3.2.4. IWSDB mechanisms. As with near term implementation,the mechanisms for implementing longer term CALS objectives willbe a set of core requirements that address the functional andtechnical needs of acquisition managers. The difference will bethe increasing emphasis on redefinition of functionalrequirements in a concurrent engineering environment, and on theapplication of appropriate supporting technology such as datamanagement and access standards. The technology and standards.for interfacing systems will be necessary but not sufficient forimplementation of long term CALS objectives, and transition
43
MIL-HDBK-59APPENDIX A
bridges between the capabilities of interfaced and integratedsystems will be needed.
40.3.2.5. Long term CALS benefits. Achieving these long termCALS objectives will yield the following benefits:
a. More complete integration than is possible withininterfaced "stovepipe" systems of contractor design,manufacturing, and support data systems based onadvanced product data models.
b. Near real-time updates of technical data to matchweapon system configuration.
c. On-line access by authorized government users todistributed contractor and government data bases.
d. Data bases owned by DoD, but possessed and maintainedeither by DoD or by contractors.
e. Automated technical manual and training materialauthoring and delivery.
f. Automated interfaces of spares procurement withflexible manufacturing systems.
g. Integration of R&M engineering as an on-line part ofthe CAD/CAE design processes.
h. Application of concurrent engineering strategies andprograms to optimize product and acquisition processdesign and development.
40.3.3. CALS implementation schedules. Implementation of CALSrequirements is technically and economically feasible now.Implementation of technology to interface contractor systems withgovernment systems is already in process, and will continue intothe mid-1990's and beyond. Planning and development for systemintegration has commenced; technology R&D activities are alreadyunderway, and implementation will start in the 1990's. DoD andindustry will be implementing a mixture of system interfacing andsystem integration initiatives throughout the next decade.
40.4. CALS management organizations. To achieve theseobjectives, the Office of the Secretary of Defense (OSD)established a CALS policy office within the office of theAssistant Secretary of Defense (Production and Logistics) todevelop policy and plans for CALS implementation, developstandards and corporate architecture elements, and facilitateaccelerated implementation within industry. The Services and DLA
44
MIL-HDBK-59APPENDIX A
have also designated CALS offices to meet the program objectivesidentified in table 1. The DoD CALS Steering Group establishedby the Deputy Secretary of Defense provides policy guidance andcoordinates implementation activities.
TABLE I. CALS points of contact.
DEPARTMENT/ ADDRESS COMMERCIAL AUTOVONAGENCY
OSD CALS Point of Contact 202-697-0051 227-0051DASD(S) CALSThe Pentagon, Room 2B322Washington, DC 20301-8000
ARMY CALS Point of Contact 703-274-9759 284-9759HQTRS, US Army MaterialCommand, ATTN: AMCRE-C
5001 Eisenhower AvenueAlexandria, VA 22333-0001
O NAVY CALS Point of Contact 202-694-9111 225-5728Naval Supply SystemsCommand, ATTN: PML 5505-T
Crystal Mall #3, Room 5171931 Jefferson Davis HighwayArlington, VA 22202
AIR FORCE CALS Point of Contact 301-981-3915 858-3915HQTRS, Air Force SystemsCommand, ATTN: PLXC
Andrews AFB, DC 20334-5000
DEFENSE CALS Point of Contact 703-274-4210 284-4211LOGISTICS DLA-Z (DCLSO) or 284-4212AGENCY 6301 Little River Turnpike
Beauregard Square, Suite 310Alexandria, VA 22312
45
MIL-HDBK-59APPENDIX A
THE DEPUTY SECRETARY OF DEFENSE
WASHINGTON, D.C. 20301
5 AUG 1988
MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTSDIRECTOR, DEFENSE LOGISTICS AGENCY
SUBJECT: Computer-aided Acquisition and Logistic Support (CALS)
To achieve productivity and quality improvements, mySeptember 1985 letter on CALS set the goal of acquiring technicaldata in digital form (rather than paper) for weapon systemsentering production in 1990 and beyond. We have now taken amajor step toward routine contractual implementation. TheDepartment of Defense (DoD) has coordinated with industry thefirst in a series of CALS issuances of national and internationalstandards for digital data delivery and access. These standardshave been published in MIL-STD-1840A, "Automated Interchange ofTechnical Information," and supporting military specifications.The CALS standards will enable either digital data delivery orgovernment access to contractor-maintained technical data bases.
Effective immediately, plans for new weapon systems andrelated major equipment items should include use of the CALSstandards. Specifically:
o For systems now in full-scale development or production,program managers shall review specific opportunities forcost savings or quality improvements that could result fromchanging weapon system paper deliverables to digitaldelivery or access using the CALS standards.
o For systems entering development after September 1988,acquisition plans, solicitations, and related documentsshould require specific schedule and cost proposals for:(1) integration of contractor technical information systemsand processes, (2) authorized government access to contrac-tor data bases, and (3) delivery of technical information indigital form. These proposals shall be given significantweight for their cost and quality implications in sourceselection decisions. The CALS standards shall be appliedfor digital data deliverables.
DoD components shall program for automated systems toreceive, store, distribute, and use digital weapon system tech-nical information, including achieving the earliest possible datefor digital input to DoD engineering data repositories. Thesesystems shall be configured or adapted to support the CALS
FIGURE 3. CALS implementation requirements.
46
MIL-HDBX-59APPENDIX A
standards. Plans for CALS implementation and productivityimprovements will be addressed in Defense Acquisition Board andMajor Automated Information System Review Council acquisitionreviews, and in corresponding Service and Agency reviews.
Each application decision shall be made on its own meritswith respect to the productivity and quality improvementsexpected at either prime contractor or subcontractor level. TheUnder Secretary (Acquisition) will issue further guidance oncontract requirements, such as CALS options, in invitations forbid; opportunities and safeguards for small business and othervendors and subcontractors; government and contractor incentives;and funding mechanisms for productivity-enhancing investments inautomation and CALS integration by defense contractors.
I believe that CALS is one of the most important and farreaching acquisition improvements we have undertaken. I wouldappreciate having the Assistant Secretary (Production andLogistics) receive your plan of action within 90 days, includingidentification of systems where opportunities exist for costsavings or quality improvement through application of CALStechnology, the investment required to achieve these benefits,and proposed schedules for implementation.
William H. Taft, IV
cc: Under Secretary of Defense (AcquisiLion)Assistant Secretaries of Defense
FIGURE 3. CALS Implementation Requirements - Continued.
47
MIL-EDBX- 59APPENDIX A
THIS PAGE INTENTIONALLY LEFT BLANK.
48
MIL-HDBK-59APPENDIX B
APPENDIX B
APPLICATION GUIDANCE FORACQUISITION OF DIGITAL DELIVERABLES
49
MI L-HDBK- 59APPENDIX B
THIS PAGE INTENTIONALLY LEFT BLANK.
50
0 MIL-HDBK-59APPENDIX B
10. SCOPE
10.1. Applicability. This appendix provides guidance togovernment activities on acquisition of digital deliverables inthe functional areas that currently produce the greatest volumeof hard copy technical data. It is applicable to all Departmentof Defense (DoD) components which acquire weapon systems andequipment.
10.2. Purpose. This appendix provides decision guidance andmodel language for tailoring the wording of standard DoD Requestsfor Proposal (RFP's) and Contract Data Requirement Lists (CDRL's)to allow and encourage the integrated preparation and submissionof, or access to, digital data for design, manufacturing, andsupport applications.
20. REFERENCED DOCUMENTS
See list of references appearing in Appendix A.030. DEFINITIONS
See list of terms and acronyms appearing in Appendix A.
051
MIL-HDBK-59APPENDIX B
40. GENERAL GUIDANCE
40.1. Contracting for digital data. A major thrust of theComputer-aided Acquisition and Logistic Support (CALS) program isdelivery of, or access to, weapon system data in digital form. Asecond major thrust is the integration of the data bases whichproduce that data and make it available for use. Implementationof these thrusts requires changes to DoD solicitations andcontracts, including their attachments and enclosures. Thesechanges should be made with full consideration of the ability ofcontractors to provide digital data and the ability of governmentactivities to make cost effective use of digital datadeliverables or access.
40.2. Tailoring and revision of functional standards. Existingfunctional standards may be insufficient to invoke thesealternatives contractually. Many of these standards were writtento address not only hard copy delivery requirements, but alsostyle and format provisions designed for the paper environment.Therefore, tailoring is frequently required when they are citedby the contract. In some cases, tailoring out inappropriaterequirements may be insufficient, and alternative language may beneeded as part of the statement of work. The acquisition managershould identify necessary changes to functional standards andforward them to the appropriate preparing activity to facilitaterevision and publication of updated functional standards.
40.3. Application of the master decision template. The masterdecision template (Figure 1, 5.2.5) provides guidance foranalysis of how technical data should be acquired by thegovernment from the contractor. This appendix discusses theapplication of the master decision template to specificfunctional areas, including the appropriate technical standardsand specifications.
40.3.1. Tailoring to meet program requirements. In each case,the master template must be tailored to meet the requirements ofthe functional area. In addition, each weapon system program mayinclude unique requirements for which additional program-specifictailoring will be needed. Most of the applicable CALS standardsand specifications contain contract-negotiable options amongwhich the acquisition manager must choose to satisfy program-specific requirements, including multiple classes or types ofdata formats, and different requirements for interim and finaldeliverables. Consequently, the acquisition manager must applythis handbook as a guidance document, not as a rulebook.
52
MIL-HDBK-59APPENDIX B
40.3.1.1. Classes of data. Section 1 (scope) and section 6.2(ordering data) of a military specification will list classes(types, levels) of data addressed by the specification. Usually,the acquisition manager must choose one of these classes based onthe program's information requirements. For example, MIL-D-28000includes several data classes, including Class I for technicalillustrations, Class II for engineering drawings, Class III forelectrical and electronic applications, nd Class IV fornumerical control machining data. Class I is usually mostsuitable for technical manuals, class II for engineering drawingsand book form drawings, etc.
40.3.1.2. Contract negotiable options. Section 6.2 (orderingdata) of a military specification also summarizes other contract-negotiable options allowed to be ordered under the specification.For example, MIL-M-28001 requires delivery of an SGML-taggedsource file as a final deliverable. However, it also allowsdelivery of a page description language (PDL) file as an interimdeliverable or as a second final deliverable.
40.3.1.3. Data delivery procedures. CALS military. specifications provide technical requirements for delivery ofdigital data. MIL-STD-1840 provides rules for organizing filesof digital data (for example, MIL-M-28001 text files and MIL-D-28003 graphics files) into a complete data package, such as atechnical manual in digital form. Therefore, in most casesdelivery of digital data must be specified in accordance withboth MIL-STD-1840 and an appropriate military specification.
40.3.2. Selection of multiple options. The alternativescontained in the decision template are not mutually exclusive,and are applied individually to each technical data requirementwithin the functional area. For example, the acquisition managermay choose digital document image data for preliminary review andapproval, and processable data files for final deliverables.However, early selection (or rejection) of one deliverable optionmay cause that option or other options to be excluded fromfurther consideration for deliverables in subsequent programphases. For example, an early decision to require technicalillustrations in raster form may result in creation of data thatcannot easily be converted to vector form.
40.3.3. Data item descriptions (DID's). A DID identifiesspecific data requirements, which may include the format of areport used to display the data. Most current DTD's wereprepared with only the hard copy (paper, aperture card, etc.)document environment in mind. In a CALS environment, two aspects. of data acquisition must be examined to determine whetherexisting DID's are adequate: the deliverable itself (documents,
53
MIL-HDBK-59APPENDIX B
processable data files, interactive access), and the deliverymode (physical media or telecommunications).
40.3.3.1. Documents and media. If a document is acquired, ineither hard copy (paper, aperture card, etc.) or digital (raster,PDL, etc.) form, then this requirement is not additive to thebasic set of data requirements and the existing DID can be usedwithout revision. Similarly, a new DID is not required when aphysical media delivery mode is specified, because thisrequirement is not additive to the basic set of datarequirements. If a telecommunications delivery mode but notinteractive access is specified (that is, when electronic mail isused), a new DID is also not required.
40.3.3.2. Processable data files. The basic set of datarequirements does change when processable data files areacquired, even though the exact same data elements are included.Therefore, new DID's must be prepared for processable data files.Until such DID's are widely available, the acquisition managershould prepare a program-specific DID and submit it for approval.Such program-specific DID's will be the foundation for revisingthe body of current DID's that are available for all acquisitionprograms. I
40.3.3.3. Interactive access. In the case of interactiveaccess, the acquisition manager is acquiring a service, notmerely deliverable documents or data. In this case, therequirements will have to be addressed in the contract statementof work. In some cases, such as when a contractor is maintainingand updating the technical data for government users after itsoriginal creation, the requirements may be subject to a separatecontract action.
40.4. Technology development and insertion. One characteristicof CALS system integration initiatives will be application of newtechnology that is currently still in the research anddevelopment process. However, the technology for interfacingsystems is also evolving. This is reflected in all aspects oftechnical data delivery and access, and in the telecommunicationsand computer-aided capabilities through which data delivery andaccess is implemented. Data which cannot cost effectively beprovided through interactive access today will be routinelyexchanged using this medium in the future. New specificationsand standards will be developed and implemented to allow digitaldocuments and processable data files to be more efficientlymanaged. Computer system vendors will provide more capablehardware and software that can integrate processable data filesthrough which different forms of data (text, graphics, etc.) aretreated as a single, compound data structure. Acquisition
54
MIL-HDBK-59APPENDIX B
managers should be alert for opportunities to apply this moreadvanced technology, as well as cautious about prematureimplementation. CITIS and government technical informationsystem architectures must plan for technology insertion, and forthe attendant problems of managing both multiple concurrentcapabilities (e.g., raster and vector graphics) and multipleconcurrent technology levels (e.g., untiled and tiled raster).
55
MIL-RDBK-59APPENDIX B
50. DETAILED GUIDANCE
50.1. Organization of guidance sections. This appendix isorganized by functional area. Each section can be usedseparately or in combination with others to contract for digitalCALS data. The functional areas covered in this release of MIL-HDBK-59 are:
a. 50.2 Technical Manuals.
b. 50.3 Technical Data Packages (including EngineeringDrawings, Product Specifications and Book FormDrawings, and other Technical Data Packagecomponents).
c. 50.4 Logistic Support Analysis Records.
d. 50.5 Training Products.
Among the functional areas that will be included in futurereleases of MIL-HDBK-59 are:
a_ 50.6 Technical Specifications and Reports.
b. 50.7 Interactive Maintenance Aids.
50.2. ACQUISITION OF TECHNICAL MANUALS
50.2.1. Scope. This section addresses the selection of digitaldata deliverables for technical manuals (technical orders in theAir Force). Technical manuals are the operating and maintenanceinstructions for military technicians. They contain acombination of textual narrative and illustrative graphic imagespresented in a formal, structured, page-oriented format governedby specific functional standards. These manuals havetraditionally been prepared and delivered in hard copy form ascamera-ready copy, which are, in turn, printed in large lots.
50.2.1.1. Digital data deliverables. The implementation ofautomated data processing technology offers numerous improvementopportunities in both preparation of technical manuals, and thedelivery, storage, distribution, and maintenance of manuals.Technical manual data in digital form can be stored on magneticor optical media, transmitted and shown on computer terminals,and printed on demand. Acquiring technical manual deliverablesin digital form allows the military user to view requiredinformation without printing it on paper. Acquiring processable
56
0 MIL-HDBK-59APPENDIX B
data files provides the opportunity to tailor outputs forparticular users and uses. Data can be reformatted into step-by-step trouble-shooting formats for maintenance personnel, it canbe adapted to expert system diagnostic programs, or it can beused to generate training aids.
50.2.1.2. Advances in computer capability. Many of today'scomputer systems still manage and interchange textual datadifferently from graphics data, making it difficult to insureconsistency between the narrative and illustrative materialsrequired in technical manuals. Technology and standards (such asODA/ODIF) are being developed and implemented to overcome thisproblem, and will become increasingly available. Contractorswill implement this technology rapidly, and acquisition managersshould anticipate improved tools for maintaining and deliveringtechnical manual data.
50.2.1.3. Data sources for technical manuals. The LogisticSupport Analysis Record (LSAR) consolidates logistics-orientedtechnical information in conjunction with data for the variousengineering disciplines and Integrated Logistic Support elements. to reduce redundancy, facilitate timely usage, and enhanceconsistency among data elements and disciplines. The quality andproductivity of technical manual development is enhanced when theLSAR is used as a principal data source for this process.Integration of the data bases that produce LSAR task analysis(and other) data, technical manuals, and training materials willproviae even greater benefits.
50.2.2. Decision node discussion. Figure 4 applies the masterDecision Template for Acquisition of Digital Deliverables totechnical manual deliverables. The foll'owing paragraphs discussthe required decisions shown in figure 4.
50.2.2.1. Deliverable options - decision #1. Technical manualdata can be delivered as composed documents or processable files.Interactive access to data bases containing technical manual datais a future goal. The composed document deliverable optionoffers the least flexibility, even in digital form. It is astatic, formatted presentation of the manual, which can only bearcnived, viewed, and printed after receipt. Processable files,on the other hand, offer more robust capabilities. These filescan be updated or transformed into many different data types.With appropriate data processing systems, processable files cansupport creation of job guides, training documents, and eventualon-line distribution of selected portions of the data tomaintenance personnel.
057
MIL-HDBK-59 0APPENDIX B
Decision #I Decision #2 Decision #3 Decision #4
Deliverable Form Standards
Hard Copy MIL-M-38784 and Others
_ MIL-R-28002
Technical V MIL-STD-1840
Manua !sr Document Image"SPDL"................................ a n tc T p
MIL'M-28001/ / Physical Mea
Text File MIL-STD-1840 ne D0 MIL.R-28002/ Optca Di.............
MIL-STI 1840
Accessable MLu-2800C.r
Technical Graphics File FtMrL-STD-1840e
Manual MIL-D-28003/Files \MIL-STD-1840
Integrated Data File50.2.e.................... cn ... . .. P...........r..e.....a.bj
nteractive ... Legend:
i Accessto o Current... Contractor
a p Technical l cm t g q en d s wa FutureManualDatabase
FIGURE 4. Decision template for technical manuals.
50.2.2.1.1. Destination system constraints on form. Processabledata files are preferable to composed documents, but the presenceof both text and graphics may cause some difficulty because notall presently installed computing equipment and software can
simultaneously process text with embedded graphics. This issueis rapidly disappearing. Nonetheless, during the period ofintended use, installed hardware and software at both thecontractor's site (i.e., the source system) and government's site(i.e., the destination system) will be the deciding factor as towhich form the deliverable may take.
50.2.2.1.2. Interim dual deliverables. Requirements fortechnical manual deliverables may include both composed documentsin digital form and processable data files. However, until moreadvanced government systems are available, it may be necessary toaccept, for each deliverable, both one hard copy (paper)technical manual for approval and reproduction/distribution, anda digital form of that manual for archiving or update andmaintenance. When the government implements more advanced
58
MIL-HDBK-59APPENDIX B
computer systems, processable technical manual files (with orwithout composed document image files of the technical manual)should suffice. Check with the appropriate Service CALS point ofcontact (Appendix A) for up-to-date guidance.
50.2.2.2. Forms options - decision #2. A technical manual ismade up of both text (including narrative and tables) andgraphics. Integrating these elements into a complete technicalmanual, and dealing with user zequirements that are different forinterim review and approval than for final delivery, may requiremore than merely choosing a single optimum form. The acquisitionmanager may have to choose the appropriate forms for multipledeliverables (eg, a processable data file that can be updated andmaintained, plus a document image file that can be displayed andprinted on demand), or for the elements of a single deliverable(eg, processable data files for text, and document image filesfor graphics).
50.2.2.2.1. Forms options - decision #2 (for composeddocuments). As shown at the top left of figure 4, if composeddocuments have been selected at decision #1, the forms for. technical manual delivery can be either hard copy (paper ormicrofilm) or a digital composed document image file. Thedigital form of this deliverable consists of composed page imagesof the full manual. It offers greater advantages than hard copyin storage, distribution, viewing, and printing. It alsoprovides slightly more flexibility than hard copy with respect tofutuze data uses, although its format will be fixed andunyielding. It is a two-dimensional image of each manual page,offering no further updating or processing features beyondreplication. Neither the hard copy nor the digital form supportsupdate or maintenance except with great difficulty.
50.2.2.2.2. Forms options - decision #2 (for processable files).If processable files are selected at decision #1, the forms fortechnical manual delivery can be either one or more sets of textand graphics files, or an integrated data file that contains textand graphics in a compound data architecture. The use of anintegrated data file is a future option. At present, aprocessable technical manual file will be comprised of one set offiles for textual or numeric data and a separate set of files forgraphic illustrations and drawings. In the future, these sametext and graphics data will be available as integrated data fileswith configuration management and positioning features. However,the technologies to accomplish such integration are justbeginning to be introduced.. 50.2.2.2.3. Forms option - decision #2 (mixed mode). Atechnical manual typically contains about 60% text and 40%
59
MIL-RDBK-59APPENDIX B
graphics. The graphics may include illustrations imported from adesign data base, artwork that has been newly created on anadvanced authoring work station, and illustrations originallycreated on the drafting table that must now be treated as adigital image. The text will include both straight narrative andtables, and the tables may be so elaborate that it is technicallyeasier to construct them as if they were a graphic illustration,rather than organized textual information. In cases such asthis, the digital deliverable may be made up of files ofprocessable data (e.g., the text and the graphics imported fromdesign) accompanied by composed document image files (e.g.,illustrations that have been raster scanned from hard copyartwork). See the discussion of raster versus vector graphicsbelow.
50.2.2.3. Specification and standard options - decision #3.
50.2.2.3.1. Decision #3 for composed documents. Technicalmanuals acquired as composed documents may be acquired in theform of either camera-ready masters or digital document imagefiles. Camera-ready masters should be delivered in accordancewith MIL-M-38784 or other appropriate MIL-SPECs or MIL-STDs.Digital document image files in raster form should be acquired inaccordance with MIL-R-28002. MIL-R-28002 provides two options:Type I (the default option) for untiled raster data, and Type IIfor tiled raster data, for which a new national standard is beingdeveloped. Storage of document images in a Page DescriptionLanguage (PDL) provides an alternative form which is slightlyeasier to maintain. A PDL file is a program that is executed byan interpreter that controls a raster printer or other outputdevice. PDL document image files can be acquired as interimdeliverables, or as final deliverables in addition to (but not inplace of) processable data files using MIL-STD-1840 and MIL-M-28001. However, these are not standardized, for a Standard PageDescription Language (SPDL) is still being developed.
50.2.2.3.2. Decision #3 - specifications and standards forgraphics.
50.2.2.3.2.1. Raster versus vector graphics. Graphics data maybe in either raster or vector formats. Assuming an adequatescanning resolution, raster provides nearly exact fidelity forillustrations, whereas vector graphics translates data betweendifferent sending and receiving system native forms. (Forexample, a line expressed as a pair of end points, versus a lineexpressed as an origin, direction, and length.) This canintroduce errors, even when an intermediate neutral format (thestandard) is agreed upon. Vector representations are easilyedited, maintained, and updated, whereas raster representations
60
MIL-HDBK-59APPENDIX B
can be edited only with great difficulty. Vector representationsalso have the advantage of much smaller file size, even when theraster bit-map image has been compressed using an algorithm suchas that specified by MIL-R-28002. Nevertheless, raster graphicillustrations are frequently encountered because scanning remainsthe only practical way of converting a legacy of hard copydrawings into digital data. Despite the limitations of rasterdata, the practical consequence of the hard copy legacy requiressupporting both raster and vector formats for graphics. Rasterillustrations belong to the class of document image filesdiscussed in the previous paragraph and should be acquired usingMIL-R-28002.
50.2.2.3.2.2. Specifications for vector graphics. There are twochoices of standards to consider for vector graphics: MIL-D-28003 for CGM and MIL-D-28000 for IGES. Generally, the ComputerGraphics Metafile (CGM) is appropriate for graphics in thecategories of illustrations, charts, etc., while engineeringdrawings and technical illustrations derived from design data arethe domain of IGES, the Initial Graphics Exchange Specification.CGM files are smaller than equivalent IGES files by a factor of. up to four. For technical manuals, CGM is the preferred optionbut IGES is allowed. Extensions to the standard to allowtranslation of native CAD data into CGM are still beingdeveloped. If technical manual illustrations are being deriveddirectly from design data, then system limitations may constrainthe choice of de]ivery standard. In selecting the appropriateoption, the acquisition manager should recognize the potentialproblems created by multiple translation steps (e.g., unique CADsystem to IGES to CGM). MIL-D-28003 specifies an ApplicationProfile with two options: Level I for publication quality data,and Level II for draft quality data. Uncompressed raster datacan be included in a CGM file, but MIL-D-28003 should only beused where the predominate form of the graphics information isvector. MIL-D-28000 specifies several subsets of IGES designedto meet different application needs. In most cases, when IGES isused for technical manual illustrations, the Class I TechnicalIllustration subset is appropriate. In a few cases, programrequirements may make it appropriate to specify use of the ClassII Engineering Drawing subset. In either case, data would bedelivered in either ASCII or compressed ASCII, as specified byMIL-D-28000.
50.2.2.3.3. Decision #3 for processable text. Processable textdata files should be acquired in accordance with MIL-M-28001,which implements the Standard Generalized Markup Language (SGML).An SGML Document Type Definition and Output Specification must be.selected from MIL-M-28001, or created in accordance with the pro-
61
MIL-HDBK-59APPENDIX B
visions of MIL-M-28001, to meet the document structure and formatrequirements of the technical manual.
50.2.2.4. Digital delivery mode options - decision #4. As shownat the right side of figure 4, physical media are currently theonly practical option for the delivery of document image files or'processable data files. While telecommunications bulk transferof these files may be possible, it is usually not an economicaloption because of the large volume of data contained in thesefiles, particularly the raster document image and raster graphicsfiles. When interactive access to a contractor's technicalmanual data base becomes a third deliverable option (see leftside of figure), then telecommunications may be warranted as adelivery mode for interim deliverables. In a few cases,telecommunications networks are already being used for on-linereview and approval of technical manuals or portions of manuals.
50.2.2.4.1. Decision #4 - magnetic tape. As shown at the farright of figure 4, the preferred physical media option to use ismagnetic tape. Standards for tape media are contained inAppendix D of this handbook. It is a mature, stable technologythat is usually available at all sending and destination systems.
50.2.2.4.2. Decision #4 - optical disk. Optical disk or CD-ROMwill be alternative physical media option in the future, and aregenerally well suited for data archiving because they canaccommodate very large volumes of data quite efficiently.However, because they are relatively new technologies, opticaldisk and CD-ROM may necessitate new hardware investments by boththe contractor and the government to accommodate this media, andthey are not yet standardized.
50.2.2.5. Digital deliverable summary. Selection of the optionsat each node of the Technical Manuals decision template should bealigned to the needs of the organizations responsible fortechnical manual publication and maintenance within each militarydepartment. However, requirements for interim deliverables thatare provided only for review and approval (verification) may beevaluated differently than are final deliverables. Delivery ofprocessable data is less important when the principalapplications are view and annotate, than when the intendedapplications are update/maintain and process/transform.Consequently, document image files may be more appropriate earlyin the life cycle of the program; however, processable data filesshould be the deliverable of choice when the government assumesthe responsibility for technical manual update and maintenance.These files should be usually be delivered on magnetic tape.
62
MIL-RDBK-59APPENDIX B
50.2.2.6. Example - delivery of digital data into the AutomatedTechnical Order System (ATOS). For example, the appropriateselection options for technical manuals delivered to the AirForce Automated Technical Order System should be processabletechnical manual files composed of:
a. SGML text files in accordance with MIL-M-28001 and MIL-STD-1840.
b. Raster graphics files in accordance with MIL-R-28002Type I and MIL-STD-1840.
c. Vector graphics files in accordance with MIL-D-28000Class I and MIL-STD-1840.
50.2.3. Decision guidelines. As noted previously, digitaldelivery options for technical manuals are not mutuallyexclusive. There will often be cases when several options willbe combined for specific deliverables during a weapon systemacquisition. The decision criteria presented in this handbookare intended to aid in selecting the best options. The following. is guidance for applying the criteria to technical manuals.
50.2.3.1. Intended data use. The following general guidelinesare provided:
a. Select processable files if internal or third partyupdate and maintenance is anticipated, document imagefiles if no further revision or change is anticipated.
b. Select processable files if the future creation ofspecialized documents and aids is envisioned.
c. Select vector graphics files if update and maintenanceof illustrations and drawings is desired, rastergraphic files if hard copy illustrations are beingconverted to digital form.
50.2.3.2. Life cycle phases. The acquisition life cycle phaseof the weapon system and its technical data is an importantconsideration. The following general guidelines apply:
a. Select document image files if a program is in a latephase (i.e., full scale development, or production anddeployment) and large amounts of data already exist inhard copy.
63
MIL-HDBK-59APPENDIX B
b. Select document image files for interim deliverablesfor in-process review prior to assumption of managementand maintenance responsibility.
c. Select processable data files for final delivery, whenmaintenance and update responsibility is assumed by thegovernment.
50.2.3.3. Delivery cost. Costs associated with the deliveryprocess are a consideration. The following guideline applies:
Select tape for delivery of large volumes of digital data.
50.2.3.4. Available technology. The limitations of thegovernment receiving system are a consideration. The followingguideline applies:
Select document image files if the receiving system lacksupdate and maintenance capability, processable data filesfor subsequent processing and transformation.
50.2.4. Contract implementation of digital data delivery. Thereare five basic, yet non-exclusive, digital deliverable alterna-tives. These are summarized in table II.
TABLE II. Technical manual forms and standards.
Deliverable and Preferred Implement WithForm Delivery Mode
1. Document Image Magnetic Tape MIL-R-28002 or MIL-File M-28001 (PDL only),
and MIL-STD-1840
2. Processable Text Magnetic Tape MIL-M-28001 andFile MIL-STD-1840
3. Raster Graphics Magnetic Tape MIL-R-28002 andFile MIL-STD-1840
4. Vector Graphics Magnetic Tape MIL-D-28000 andFile-IGES MIL-STD-1840
5. Vector Graphics Magnetic Tape MIL-D-28003 andFile-CGM MIL-STD-1840
50.2.4.1. Digital data deliverables. MIL-M-38784, Technical
Manuals: General Style and Format Requirements, is commonly used
64
MIL-IDBK-59APPENDIX B
to order technical manuals; other specifications govern specifictypes of manuals, and are often invoked in conjunction with MIL-M-38784. When delivery (or access) of technical manuals indigital form is planned, all relevant functional standards mustbe reviewed to ensure that they do not specify requirements whichare incompatible with the applicable CALS standards.
50.2.4.2. Ordering requirements. In addition, the tailored MIL-M-38784 should be referenced in Block 16 of the CDRL (DD Form1423) to specify delivery of digital data in accordance with MIL-STD-1840. The physical media standards for magnetic tapedelivery mode shown in Appendix D should also be specified.
50.3. ACQUISITION OF TECHNICAL DATA PACKAGES (TDP).
50.3.1. Scope. A technical data package is a technicaldescription that is adequate to support acquisition of an item,including engineering and production. The technical descriptionconsists of all applicable technical data, such as engineeringdrawings, associated lists, product and process specificationsand standards, performance requirements, quality assuranceprovisions, and packaging details. This section addressesacquisition of the elements of a TDP.
50.3.2. ENGINEERING DRAWINGS.
50.3.2.1. Scope. This section addresses the acquisitionalternatives for engineering drawings, a major component ofTechnical Data Packages (TDP's). The emphasis is on thosedrawing levels (as defined in DoD-D-1000) that will be used tomanufacture hardware: Level 2 (production prototype and limitedproduction) and Level 3 (production), rather than Level 1(conceptual and developmental design). Typically, only Levels 2and 3 are delivered to DoD repositories for archiving andsubsequent application and use. This section, and the section onproduct specifications and book form drawings that follows,distinguish between technical data that is primarily graphic withassociated text annotation, and technical data that contain amore proportional mix of graphics and text.
50.3.2.2. Overview. Engineering drawings are documents thatdisclose directly or by reference, by means of graphic andtextual information, the physical and functional end-productrequirements of an item. Geometry, material requirements, andprocess data, along with notational explanations pertaining toO specific functions and features of the representation, are itstypical contents. Process and manufacturing engineers interpret
65
MIL-HDBX-59APPENDIX B
the drawings and create additional information on the materialand physical processes required to fabricate the parts,assemblies, or products described by the engineering drawing. Inaddition, machine instructions can be created from the drawing bya process engineer to direct the fabrication and inspectionprocesses for parts fabricated on computer numerical control andautomated production machines.
50.3.2.2.1. Product definition data. An engineering drawing isa subset of what CAD users have come to call product definitiondata. Product definition data includes the information neededfor design, analysis, manufacture, test, and inspection (see thedefinitions in Appendix A, Section 30). Product definition data,in turn, is a subset of product data, which adds the elements flife cycle support to those of design and manufacture. Eventhough an engineering drawing does not contain all productdefinition data, let alone all product data, it is the acceptedform in which product design information is communicated anddocumented for the record in a hard copy environment. It willcontinue the serve this same function while users transition intoa CIM environment.
50.3.2.2.2. Drawing conventions and standards. Becauseengineering drawings meet a wide scope of information and userneeds, conventions and standards governing their creation havebeen developed to ensure consistency of creation andinterpretation. These requirements have been codified in ahierarchy of military standards and specifications, with DoD-D-1000 and DoD-STD-I00 at the apex.
50.3.2.2.3. Evolving technology for engineering drawing data.Some design work is still being done on the drafting table, butusers are increasingly adopting computer aided design (CAD)technology. Regardless of how the engineering data is created,however, it can still be exchanged between users in either hardcopy or digital form.
50.3.2.2.4. Use of raster graphics. DoD stores over 200 millionengineering drawings and specifications in its repositories, andmost of this information is duplicated in the repositories of thedefense contractors who created the drawings. The storage ofengineering drawings and the generation of spares reprocurementpackages has become increasingly difficult and time consuming asthz vclum, =f hard copy data in DoD repositories has continued toexpand. Thirty years ago, engineering drawing users transitionedfrom paper/vellum to aperture cards as the medium of interchangefor drawings. Now that new technology is available, and storageof engineering drawings on aperture cards can no longer keep upwith user needs, the Services' data repositories have initiated
66
MIL-HDBK-59APPENDIX B
the process of raster scanning hard copy engineering drawings formore compact storage on optical disk. While this adds nointelligence to the engineering data itself, it doessignificantly improve data management capabilities.
50.3.2.2.5. Computer aided design (CAD). Defense contractorsare expanding the use of CAD and computer integratedmanufacturing (CIM) systems to automate design and manufacturingfunctions. These CAD and CIM systems create and use vectorgraphics files, defining the geometry and associated dataattributes of weapon system assemblies and components. Thistechnology facilitates use of other automated tools, such asthose for reliability and maintainability (R&M) analysis, in thedesign process. PDES, an evolving DoD and industry-supporteddata standard for description of the product over its life cycle,will provide additional functionality when it becomes available.PDES used with CIM technology will facilitate the integration ofengineering design, manufacturing, logistic support, andconfiguration management data. Engineering drawings, an outputof the engineering design process, will be able to be extracteddirectly from product data, largely without intermediate manualO processes. Ultimately, engineering drawings may no longer benecessary for spares reprocurement, particularly when PDESproduct data can be directly transferred between CIM systems.
50.3.2.3. Decision node discussion. The master DecisionTemplate for Acquisition of Digital Deliverables is applied tothe Engineering Drawings Application as shown in figure 5. Eachdecision is discussed in the following text.
50.3.2.3.1. Deliverable options - decision #1. The first columnlists the first set of deliverable options for engineeringdrawings. The current choices are engineering drawing images orthe more comprehensive product definition data files used by somecontractors. Interactive access to engineering design data basesis a future goal.
50.3.2.3.2. Form options - decision #2.
50.3.2.3.2.1. Forms options - decision #2 (for engineeringdrawing images). The deliverable form options for engineeringdrawing images are hard copy and raster image files. Paper,vellum, mylar, roll microfilm, and aperture cards are someexamples of the media used for hard copy. The aperture card hasbecome the accepted medium for acquiring reproducible hard copyimages of engineering drawings, although other forms are still inuse. Aperture cards or other hard copy forms delivered to DoD. automated engineering data repositories will be converted toraster images for storage. This conversion can be avoided by
67
MIL-HDBK-59APPENDIX B
choosing delivery of a raster image file. Raster image files arethe representation of digitally scanned paper drawings oraperture cards. There is no intelligence in the raster imagefile. Human interpretation is required, as it is with paperdrawings or aperture cards. Raster image files are primarilyuseful for data that are to be used in a print on demand, hardcopy (paper or aperture card) mode.
Decision #1 Decision #2 Decision #3 Decision #4
Specs & DeliverDeliverable Eorm Standarda Mode
DoD-STD-100/Hard Copy MIL-M-804
SDocument - MIL-R-28002/
CRAster image File MIL-STD-1840
Magnetc TapePhysical Media /
J Optical DiskMIL-D-28000/-..... ....... .
CAD Data File MIL-STD-1840
rctes integrated Productd t Data Files Data F hle PDES
.... ................... Leg en d :
Contractor dioCurrentMaintained
CDatabase wl t i o r e nFutureInteractive
Access
FIGURE 5. Decision template for engineering drawings.
50.3.2.3.2.2. Forms options - decision #2 (for product
definition data files). The options for product data definitionfiles are the CAD data file and the inateted product data file.The CAD data file consists of vector data with geometrically
accurate and precise representations of the product, togetherwith associated annotations (dimensions, tolerances, etc.). ThisCAD data can be either two-dimensional or three-dimensional,although the CALS standard (MIL-D-28000) described below definesa three-dimensional CAD data file. CAD data contains limitedintelligence, and is suitable for automated interrogation andmanipulation, such as alternate views of the object or pathgeneration for numerically controlled manufacturing machinery.
DoD repositories plan to accept digital data created by CADsystems as input, although in the near term the principal output
68
NIL-RDBK-59APPENDIX B
medium from those repositories will be hard copy or rasterimages. The integrated product data file will contain moreinformation. It will include three dimensional features, solidsmodeling, parametric design, material specifications, designtradeoffs, process and manufacturing engineering, and machineinstructions for automated parts manufacturing. This optionrequires technologies that are not yet fully developed or inwidespread use, and for which standards are still underdevelopment.
50.3.2.3.3. Specifications and standards options - decision #3.DoD-STD-100 and DoD-D-1000 are the functional standardscontrolling the subject matter and content requirements ofengineering drawings. Changes to these functional standards, ornew standards, may need to be developed if current or future CADtechnology leads to changes in the subject matter or content ofengineering drawings. Technical specifications and standards arewell defined for aperture cards, raster image files, and CAD datafiles.
50.3.2.3.3.1. Specifications and standards options - decision #3. (for engineering drawing images). Aperture cards are governed byMIL-M-38761 and MIL-STD-804 (hollerith data) requirements. MIL-M-9868 governs the microfilming of engineering documents. Rasterimage files are governed by MIL-R-28002. The default format fordelivery of raster data is MIL-R-28002 Type I (untiled).However, MIL-R-28002 Type II (tiled) may be negotiated if theappropriate sending and receiving system capability is in place.
50.3.2.3.3.2. Specifications and standards options - decision #3(for product definition data files). CAD data files are governedby MIL-D-28000 (IGES). In most cases, the MIL-D-28000 Class IIsubset (engineering drawings) is appropriate. For electrical andelectronic applications, the MIL-D-28000 Class III subset may bemore appropriate, Specialized data requirements (whichtechnically are not engineering drawings) should be met withother IGES subsets (eg, Class IV for numerical control data). Ineither case, data would be delivered in either ASCII orcompressed ASCII, as specified by MIL-D-28000. The PDES standard(when available) for the integrated product definition data fileshould be considered for future deliverables from programs thatare in the very early phases of concept development. However,use of PDES will offer the opportunity to acquire informationthat exceeds the current scope of engineering drawings, and mayrequire development of new functional standards, or changes toDoD-STD-100 and DoD-D-1000.
O 50.3.2.3.4. Digital delivery mode options - decision #4. Thedigital delivery mode options are shown at the right side of
69
MIL-RDBK-59APPENDIX B
figure 5. Physical media is currently the only practical optionfor the delivery of raster image files. Telecommunications bulktransfer is possible; however, it is not the preferred method dueto cost considerations. Future interactive access to thecontractor's data base will present the option to access specificportions of the data as appropriate and, at that time,telecommunications may be a viable option for certain interimdeliverables. An alternative may be to use interactive access tolocate and order data that is subsequently delivered usingphysical media. The preferred physical media option to use atthis time is magnetic tape. Reference the tape media standardsdiscussed in Appendix D of this handbook.
50.3.2.3.4.1. Decision #4 - magnetic tape. Magnetic tape is thepreferred physical medium for delivery. It is a mature, stabletechnology that is usually available at all sending anddestination systems.
50.3.2.3.4.2. Decision #4 - optical disk. Optical disk will bea future alternate physical media due to emerging standards andthe increasing number of DoD programs using optical disktechnology. The major optical disk advantage is its ability toarchive and store large volumes of data.
50.3.2.3.5. Digital deliverable summary. In general, theevaluation and selection of options at each decision node of theEngineering Drawings decision template must be aligned to thecapabilities of the automated engineering data repository systemsof the using Military Department. Raster image files should beacquired early in the life cycle of the program, when theprincipal application is review and approval. CAD data filescould be the final deliverables of choice for drawings obtainedfor spares reprocurem. t technical data packages if the data wereoriginally developed on CAD systems.
50.3.2.3.6. Example - delivery of digital data to DoDengineering data repositories. For example, the appropriateselection of options for engineering drawings delivered to theArmy Digital Storage and Retrieval of Engineering Data System(DSREDS), the Air Force Engineering Data Computer AssistedRetrieval System (EDCARS), or the Navy/Defense Logistics AgencyEngineering Data Management Information and Control System(EDMICS) should be as follows:
a. Raster image files delivered on magnetic tape inaccordance with MIL-STD-1840 and MIL-R-28002 Type I.
b. CAD data files in IGES delivered on magnetic tape inaccordance with MIL-STD-1840 and MIL-D-28000 Class II.
70
MIL-RDBK-59APPENDIX B
50.3.2.4. Decision guidelines. Digital deliverable options forengineering drawings are not mutually exclusive. There willoften be cases when several options will be combined for specificdeliverables during a weapon system acquisition.
50.3.2.4.1. Intended data use. To help evaluate the variousoption combinations, the following guidelines are provided:
a. Select raster image files for archiving and print-on-demand requirements.
b. Select IGES data files for subsequent input togovernment or industry CAD systems or to CIM systems formanufacture of spares.
50.3.2.4.2. Life cycle phases. To help evaluate the variousoption combinations, the following guidelines are provided:
a. Select raster image files for early phases with lowvolumes or frequent anticipated design changes, except whenthe drawings submitted for design approval are to undergodata processing analysis by the government.
b. Select raster image files in later phases if earlyphase engineering drawings were paper-based.
c. Select IGES data files in later phases if the data areto be input to CAD/CIM systems for modification or sparesmanufacture.
50.3.2.4.3. Delivery cost. To help evaluate the various optioncombinations, the following guideline is provided:
Select magnetic tape for delivery of large volumes ofengineering drawing data.
50.3.2.4.4. Available technology. The following guidelineapplies:
Select IGES data files if the engineering drawings werecreated on contractor CAD systems.
50.3.2.5. Contract implementation for digital data. The priordiscussion of nodes on the Decision Template for EngineeringDrawings indicated that there were two basic, yet non-exclusive,digital deliverable alternatives, as listed in table III.
O 50.3.2.5.1. Digital data deliverables. For both alternatives intable III, DoD-STD-100 is insufficient to describe the
71
MIL-HDBK-59APPENDIX B
TABLE III. Summary of engineering drawing forms and standards.
Deliverable and Preferred Implement WithForm Delivery Mode
1. Raster Image File Magnetic Tape MIL-R-28002 ref.byMIL-STD-1840
2. CAD Data File Magnetic Tape MIL-D-28000 ref.byMIL-STD-1840
appropriate methods to contractually invoke these alternatives.Therefore, the following changes to DoD-STD-100 have beensubmitted for review, coordination, and publication:
a. Add paragraphs 101.1.2; 101.1.4; 104.3; and 106.1.1- asfollows:
101.1.2 Raster/Vector (SELECT RASTER FOR RASTER IMAGE FILE.SELECT VECTOR FOR CAD DATA FILE.) Drawing Format. The sheetlayout, border, title block, revision block, and otherconventions of engineering drawing format includingdefinition and use of explicit scaling factors shall beintegral to the raster/vector (REPEAT SELECTION AS ABOVE.)data file.
101.1.4 Layer or level conventions. The file layer or levelconventions shall be identified for all data residing in thedigital data file.
104.3 Raster/Vector (SELECT RASTER FOR RASTER IMAGE FILE.SELECT VECTOR FOR CAD DATA FILE.) Digital Data Originals.Raster/Vector (REPEAT SELECTION AS ABOVE.) digital dataoriginals must be verified to ensure the validity of thedata format contained in the data file.
106.1.1 Scale of digital data. The digital data base shouldrepresent an object or assembly at full scale to ensure theshareability of represented data. The visual or reproducibleimage should be at a scale appropriate for humanunderstanding.
b. Add sentence to the end of paragraph 201.1.1, asfollows:
72
MIL-HDBK-59APPENDIX B
Engineering drawings prepared by the use of a CAD systemshall conform to figures 200-1 through 200-41, unlessotherwise instructed by the contracting officer.
c. Add note to paragraph 502.1, as follows:
Note: Revisions made to the digital data base shouldaccurately and precisely represent the change in dimensionsto the geometry of the object or assembly to ensure theshareability of the represented data.
d. Add paragraph 503.7, as follows:
503.7 Identifying location of revisions on digital dataimages. All changes made to digital data bases must beidentified explicitly on their visual output.
Pending publication, these additional requirements should beincluded in the statement of work, or in Block 16 of the CDRL (DDForm 1423) to specify delivery of digital data in accordance withMIL-STD-1840. The physical media standards for magnetic tapedelivery mode (shown in Appendix D) should also be specified.
50.3.3. PRODUCT SPECIFICATIONS AND BOOK FORM DRAWINGS.
50.3.3.1. Scope. Product specifications and book form drawingsprovide information such as material content, manufacturing andtreatment processes, inspection and testing procedures,performance requirements, etc, needed for the acquisition of thedrawing item. This information is an essential element of theproduct definition data set. It is characterized by a mix ofapproximately equal amounts of graphics and supporting narrativetext. Specifications and book form drawings applicable to anitem are referenced on the engineering drawing of that item.Additionally, a referenced specification or book form drawing mayitself reference related specifications and book form drawings,creating a hierarchy of referenced information, all of which arerequired to fully describe the iteT,.
50.3.3.2. Purpose. This section identifies the options fordelivery of product specifications and book form drawings. Theoptions selected for delivery of specifications and book formdrawings are not necessarily the same as for engineeringdrawings. However, these information products are usuallycreated, processed, and used in conjunction with one another.Consequently, when selecting the delivery option for. specifications and book form drawings, the delivery option for
73
MIL-HDBK-59APPENDIX B
the engineering drawings should be taken into consideration rortechnical data package (TDP) consistency.
50.3.3.3. Decision option discussion. Figure 6 shows the MasterDecision Template for Acquisition of Digital Deliverables asapplied to the specifications and book form drawing portion of aTDP. The alternatives presented, while not exclusive, must beconsidered and applied in context of the complete TDP and not theindividual elements of a TDP.
Decision #1 Decision #2 Decision #3 Decision #4
IDefive[yDeliverable Form Stan rds Mode
Hard Copy DoD-STD-100
Document MIL-M-9868
Raster Image File MIL-R-280021MIL-STD-1840
Magnetic Tape
Text File MIL-M-28001/
MIL-STD-1 840 Pyia ei'..Optical Disk
ontractor Processable I Graphics File MIL-D-28000/S Di nMIL-STD-1s840S u cData Files M I - T - 84 ...........................................
Integrated Data File..................... ........... PDES
Legend:
-- CurrentInteractiveAccess .......... Future
FIGURE 6. Decision template for product specifications and bookform drawings.
50.3.3.3.1. Deliverable options - decision #1. Thespecifications and book form drawings portion of the TDP can bedelivered as documents or as processable data files. Interactiveaccess to engineering design data bases containing productspecifications and book form drawings is a future goal. Thedocument deliverable option offers the least flexibility, evenwhen provided in digital form. Documents are static, formattedpresentations of information which can only be archived, viewed,and printed after receipt. Processable data files, on the otherhand, offer greater capabilities; these files can be updated ortransformed into many different document types. Delivery of
74
MIL-HDBK-59APPENDIX B
specifications and book form drawings as processable text and CADdata files is both preferable and technically feasible. Sourcedata can be created by electronic publishing systems (text) andCAD systems (graphics). However, the government data processinginfrastructure to permit acceptance and utilization of theinformation in this form are not yet available in DoD.Therefore, the deliverable option for the specifications and bookform drawings portion of the TDP is effectively limited to thedocument category at present.
50.3.3.3.2. Form options - decision #2. For documents, theoptions are either hard copy (paper or aperture cards), ordigital raster images. While the hard copy option includespaper, the usual procedure is to deliver documents in the sameaperture card form as for engineering drawings. The digitaloption is limited to raster image data because the PDLalternative has not been developed for specifications and bookform drawings as it has been for technical manuals. As shown infigure 6, certain types of processable data files are technicallyfeasible, although not yet available because of receiving systemlimitations. When implemented, these options will includedelivery of product specifications and book form drawings asprocessable text and graphics files, and ultimately integrateddata files containing both text and graphics. Delivery of acombination of raster image text and CAD data files is alsotechnically feasible. However, this imposes an additional layerof processing complexity on the sending system, and is notconsidered a practical alternative.
50.3.3.3.3. Specifications and standards option - decision #3.Since the processable data file option cannot currently besupported by DoD receiving systems, the relevant standards forthat option will not be discussed, although they are listed infigure 6. (See the discussion of specifications and standardsfor technical manuals and engineering drawings for additionalinformation.) For deliverable documents, aperture cards are thepredominant medium for capturing hard copy images of thespecifications and book form drawings portion of a TDP.Specifications and standards governing hard copy preparation areDOD-STD-100, DOD-D-1000, MIL-STD-804, MIL-D-5480, MIL-M-38761,MIL-D-8510 and MIL-M-9868. MIL-R-28002 governs delivery ofraster image files; the default form is Type I (untiled raster),with Type II (tiled raster) available to meet specific contractrequirements. It is extremely unlikely that program needs woulddictate a different raster type selection for specifications andbook form drawings than is made for engineering drawings.. 50.3.3.3.4. Digital delivery mode options - decision #4. Thedelivery mode for specifications and book form drawings as
75
MIL-HDBK-59APPENDIX B
documents (raster image files) may be either physical media ortelecommunications. However, because of cost considerations, thedelivery of raster image files using telecommunications bulktransfer conventions is not recommended. Of the physical mediaoptions shown at decision #4, magnetic tape is currently thepreferred alternative. As with engineering drawings, opticaldisk provides a desirable future delivery mode option, althoughit is not yet widely available or standardized. See Appendix Dof this handbook for the applicable tape media standards.
50.3.3.3.5. Digital deliverable summary. In general, theevaluation and selection of the options at each decision node ofthe specifications and book form drawings decision template mustbe aligned to the capabilities of the automated engineering datarepository systems of the using Military Department. Selectionsshould be consistent with those made for engineering drawingsunless there is a specific reason for making different choices.
50.3.3.4. Decision guidelines. In general, the options selectedfor delivery of specifications and book form drawings in digitalform are closely tied to the options selected for the associatedengineering drawings in the TDP. As with the drawings, it islikely that no single option may apply to all specifications andbook form drawings data. Finally, the delivery options selectedfor the specifications and book form drawings portion of the TDPmust be compatible with the receiving system capabilities. Thefollowing guidelines are provided to assist in the optionselection process.
50.3.3.4.1. Intended data use. The following general guidelineis provided:
Select raster image files for archiving and print on demandrequirements.
50.3.3.4.2. Delivery cost. The following general guideline isprovided:
Select magnetic tape delivery for delivery of large volumesof specifications and book form drawings.
50.3.3.4.3. Available technology. The following generalguideline is provided:
Select raster image files until destination systemtechnology allows delivery of specifications and book formdrawings as processable data files.
076
O MIL-HDBK-59
APPENDIX B
50.3.4. OTHER TDP COMPONENTS (RESERVED).
(This section will provide a decision template and supportingrationale for the acquisition in digital form of other elementsof a technical data package. The CALS Industry Working Group onSpares Acquisition is defining those elements and the resultswill appear in a future update to this handbook.)
50.4. ACQUISITION OF LOGISTIC SUPPORT ANALYSIS RECORDS (LSAR).
50.4.1. Scope. This section addresses the acquisitionalternatives of LSAR data. Logistic Support Analysis (LSA)builds upon data from related systems engineering and designanalyses, and produces a consolidated and integrated set oflogistics-related technical data. The resulting Logistic SupportAnalysis Record (LSAR) is a logically integrated data baseconsisting of both the engineering source data upon whichanalysis tasks are based, and the analysis results. With theexception of very small programs, documentation of the LSAR isaccomplished using automated LSAR systems. MIL-STD-1388-2defines the format and content of the LSAR and the structure ofvarious standard reports that allow delivery of the data indigital form. It also defines LSAR system processingrequirements and encourages additional LSAR system development.
50.4.1.1. LSAR data elements. MIL-STD-1388-2 defines the totalset of data elements that could make up an LSAR data base. Theacquisition manager must tailor application of the standard toweapon system program requirements by selecting the subset ofdata elements actually required. This is done by incorporatingin the contract DD Forms 1949-1 and 1949-2 listing the specificLSAR data that the contractor must generate and provide (throughaccess or delivery) to the government. Some data elements (suchas LSA control numbers) are required because they are keys to thedata base organization. However, few weapon system programsrequire all LSAR data elements.
50.4.1.2. Joint service LSAR data system. A baseline LSARsystem, the Joint Service LSAR Automated Data Processing System,has been developed as one alternative for LSA automation. Thisbatch mode, flat file system is capable of satisfying therequirements of MIL-STD-1388-2, but it lacks many desirablefeatures and capabilities afforded by current technology. Manycontractors have augmented the joint service system by addingfront-end software to improve data entry efficiency. Others haveused data base management software to make the data accessible to. both on-line inquiries and various LSA software tools. Finally,some contractors have linked software tools for other
77
MIL-RDBK-59APPENDIX B
engineering, design, and Integrated Logistic Support (ILS)functions to the LSAR to use or update LSAR data. DoD iscurrently revising the Joint service LSAR data system toimplement relational data base technology.
50.4.1.3. Flexibility of the LSAR. Because of the range of datathat can be documented in an LSAR, the LSAR is able to satisfythe data requirements of a number of the deliverables commonlyappearing on a Contract Data Requirements List (CDRL), such asProvisioning Lists and Failure Modes, Effects, and CriticalityAnalysis reports. When these deliverables are submitted to thegovernment as processable data files, or when direct access tothe data base is provided, improvements in data accuracy andintegrity usually result. Since the LSAR is already a logicallyintegrated data base, it invites the use of other software toolsand linkage with related engineering data bases. Furthermore,cost and time savings in data review or receipt of deliverablescan also be achieved. During the initial acquisition contract,the most cost effective means of LSAR data access or deliveryshould be evaluated to enable the contractor to offer as part ofthe subsequent phase proposal one or more digital means of datadelivery or access.
50.4.1.4. Relationship of standards for LSAR to other CALS stan-dards. Two functional standards govern LSA and the LSAR. MIL-STD-1388-1 defines the LSA process, as a result of which LSA datais created. MIL-STD-1388-2 defines the requirements for theLSAR, through which much of that data is assembled, managed, andreported. MIL-STD-1388-2 is also a technical standard fordelivery of LSAR data in digital form. Because it serves as botha functional and a technical standard, it is unnecessary (andincorrect) to use MIL-STD-1840 to define requirements fordelivery of LSAR data in digital form. Future revisions mightseparate MIL-STD-1388-2's functional standard role from itstechnical standard role, if such a separation appeared to serve apractical purpose. At this time, it does not appear that thiswould be the case.
50.4.2. Decision option discussion. The master DecisionTemplate for Acquisition of Digital Deliverables as applied tothe LSAR is displayed in figure 7.
50.4.2.1. Deliverable options - decision #i. LSAR data can bedelivered as LSAR reports, LSAR data files, or throughinteractive access to a contractor LSA data base. All threeoptions either encourage or require a contractor automated LSAR.The requirements for LSAR final deliverables will likely be acombination of at least two of these options.
78
MIL-HDBK-59APPENDIX B
50.4.2.1.1. Deliverable options - decision #1 (for LSARreports). The LSAR reports option includes the reportsidentified in Appendix B of MIL-STD-1388-2, plus anycontractually-required, project-unique reports that can beproduced using LSAR data. Most reports allow refinement or focusfor a specific user by tailoring or reformatting. Many of thereports were designed as analysis and data review tools and arenot intended to be deliverable products. LSAR reports are staticpresentations of LSAR data and cannot be updated or processedfurther after delivery. They offer the least flexibility forLSAR data use. Therefore, requiring LSAR reports as a deliverableoption is appropriate only for one-time deliveries or when nofurther processing capability is available.
Decision #1 Decision #2 Decision #3 Decision #4
Specs &DeliveryDeliverable Form Standards Mode
Hard Copy MIL-STD-1 388-2
LR Report Image File MIL-STD-1388-2
Physical Mei Magnetic Tape
DN
LSAR Alphanumeric File MIL-STD-1388-2 eicm uc..n OircoData a T \ elecommunication, d/ ::
Source Fil- C rrentr
ate I ntegrated Data e.ot tr
................................. ....................... ................................ ueii
Ir d Predefined Query SA Unique Legend:5 .eiver o nAccessnto #1 (dCurrentContractor fi s Ctractor aUndqueatLSA ireAd Hoc QUery (such.as .nFutureDatabase "'-.Data Std'.
FIGURE 7. Decision template for logistic support analysisrecords (LSAR).
50.4.2.1.2. Deliverable options - decision #1 (for LSAR datafiles). LSAR data files, the second option, includes the threeLSAR master files defined in MIL-STD-1388-2, and other LSAR datafiles that require processing after delivery (such as input filesfor Provisioning, Defense Logistics Services Center (DLSC). Screening, or Packaging Systems, among others). An internal dataprocessing capability is required for each LSAR data file.
79
MIL-HDBK-59APPENDIX B
Delivery of the LSAR master files provides the capability tosubsequently produce any of the LSAR reports and other data filesthat the LSAR data base was designed to support, and provideshistorical baseline data for weapon system/equipment. Separatedelivery of other LSAR data files places responsibility for theirgeneration with the contractor rather than the government.Because of the flexibility provided by these processable datafiles, they can be used to satisfy both interim and final LSARdelivery requirements. Periodic delivery can reduce time spentfor on-site data reviews by providing a vehicle for advancedreview of the data. Final contract deliverables can beconsolidated and reduced by internal processing of LSAR datafiles, in part or in total.
50.4.2.1.3. Deliverable options - decision #1 (for interactiveaccess). The third LSAR deliverable option is interactive accessto a contractor's LSA data base. Interactive access includes theability to selectively retrieve, review and print, and processcontractor LSA source data. Interactive access for fastergovernment review of LSAR information represents more of acontractor service capability than a specific deliverablerequirement. This capability makes the most current authorizeddata available to the government and eliminates the time requiredfor preparation and submission of deliverable products. It canalso significantly reduce the time requirement for on-sitereviews, while supporting internal analyses and planning thatrequires up-tc-date supportability information. Interactiveaccess provides the greatest flexibility for using LSAR data,either by utilizing the contractor's automated LSAR capabilitiesor by electronically transferring the data for further internalprocessing. Since interactive access can support interim andfinal delivery of both LSAR reports and data files, it mayentirely eliminate the need to bring the LSAR data in-house.(However, it is advisable to have LSAR master files delivered atcontract completion.) The interactive access service can be veryeffective for satisfying LSAR deliverable requirements during theearly life cycle phases when the volume of LSAR is low. Inlatter phases, interactive access may be more appropriate as acontract compliance, data review, and internal analysis toolrather than for bulk transfers of complete LSAR master or otherdata files.
50.4.2.1.4. Requirement for automated LSAR. Regardless of whichdeliverable option is selected, statement of work language (SOW)requiring the contractor to establish an automated LSARcapability should be included in the LSA Program SOW. (SeeContract Implementation for Digital Data for sample SOW's.)
080
MIL-HDBK-59APPENDIX B
50.4.2.1.5. Use of multiple LSAR data sets. Logistic supportanalysis is a dynamic, iterative process requiring real-timeinteraction between the design, engineering analysis and productsupport planning functions. By this means, logistics considera-tions are made an inherent part of the design process, not anafter-the-fact consequence of design decisions that excludedsupport requirements. The requiring activity (the government)must identify what LSAR data is required, and the performingactivity (the contractor) must decide how best to structure theCITIS in which that LSAR data is processed, stored, and madeavailable to users while maintaining appropriate data protectionand data integrity. These decisions must balance the requirementfor continuous, real-time update of LSAR data that documents LSAtasks already performed and supports LSA tasks underway or yet tobe performed, with the requirement to periodically baselinetechnical information about the product being designed. Suchbaselines are needed to support configuration management of theproduct and its technical data, and to meet contractualrequirements. Cost is an important consideration in thisdecision -- the additional costs of maintaining and reconcilingmultiple LSAR data sets, against the additional costs that resultfrom losing configuration control of the product or of. information about the product. The concept of working data,submitted data, and approved data is one solution to thisproblem, but it may not always be the optimum solution. ContractSOW requirements such as those suggested here must be establishedwith due consideration of these program management and costconsideracions.
50.4.2.2. Form option - decision #2. Each of the threedeliverable options for the LSAR provides one or more viable formoptions.
50.4.2.2.1. Form option - decision #2 (for LSAR reports). Asshown at the top of figure 7, LSAR reports can be deliveredeither as hard copy reports or as a report image file. Hard copyreports include both computer-generated LSAR reports (Appendix Bof MIL-STD-1388-2) and program-unique LSAR reports. Report imagefiles, the digital equivalent of these reports, require nofurther data processing and can be loaded, viewed, and printedusing standard system utilities. Both options are a fixedpresentation of the TSAR data and the applicable DID's must beselected for the desired reports. If the hard copy form isselected, the DID hard copy option should be noted.
50.4.2.2.2. Form option - decision #2 (for LSAR data files).The single available form option, alphanumeric files, isdiscussed above. The use of an integrated data file is a future
81
MIL-HDBK-59APPENDIX B
option presently under development that will be addressed in thenext update to this handbook.
50.4.2.2.3. Form option - decision #2 (for interactive access).As shown at the bottom of figure 7, interactive access to acontractor's LSA data base can take two forms: predefined queriesor ad hoc queries. A predefined query is a established a fixedformat, with a controlled set of options, to extract informationfrom LSA source data. All of the LSAR reports including program-unique reports that are contractually required, as well as LSARmaster files and data files, can be described as predefined inthis context. With the format, content, and options alreadyhaving been specified, the user selects the file or report(usually via a menu choice) to be displayed. On the other hand,ad hoc queries allow the aggregation and presentation of acontractor's LSAR source data to be defined by a user during anon-line session with the contractor's system. Ad hoc querycapabilities are governed by the specific technologies andsoftware of the contractor's system, and their availability willbe controlled by the contract or other form of agreement. AsCALS data standards for LSAR are developed, this limitation maybe altered, as reflected by the dashed line for data standards atthe bottom of figure 7. Until then, although the ad hoc querycapability can be identified in the LSA SOW, it can only bedefined by a contractor's proposal. Care should be exercised inevaluating contractor proposals to ensure that the proposed adhoc query capability will satisfy government requirements.
50.4.2.3. Specifications and standards - decision #3. There areno decision options on the standards for LSAR reports or LSARmaster data files. These files are all alphanumeric tabular datafiles as specified in MIL-STD-1388-2. Since report image filescan be generated by a sending system so easily, the technicallyfeasible alternative of raster image data adds an additionallevel of data processing complexity, and is not a practicalalternative.
50.4.2.4. Digital delivery mode options - decision #4. As shownat the right of figure 7, there are two delivery mode options forLSAR report image files and for data files: physical mediadelivery or telecommunications transfer. Physical media consistsof data delivery on magnetic tape, with the use of optical disktechnology as a future alternative. Telecommunications involvesthe bulk electronic transfer of data files using network that iscompatible with a specific telecommunications standard (DDN'sTCP/IP, or OSI's GOSIP FIPS 146), or a public, or contractor-specific non-standard telecommunications network. If interactiveaccess is not chosen for interim reviews, the most cost effectiveoption for final delivery of LSAR reports and data files will
82
MIL-HDBK-59APPENDIX B
normally be magnetic tape. When an interactive access capabilitywill be established, the cost and accessibility benefits oftelecommunications versus physical media delivery modes must beevaluated. For physical media delivery, use existing or program-unique DID's and indicate the tape delivery option. Referencethe tape media standards contained in Appendix D of thishandbook. For telecommunications delivery of LSAR report imagefiles or data files, the reports or data files to beelectronically transferred should be included in the LSA programSOW.
50.4.2.4.1. Interactive access. For the interactive accessservice, the only deliverable mode option is telecommunications.Options for selection of a telecommunications standard anddelivery network are listed at the end of the telecommunicationsbranch in figure 8. The choice depends upon the volume of datato be transferred, as well as the technologies in place atcontractor and government facilities.
50.4.2.4.2. Queries. If predefined queries are selected as theaccess form, the LSAR reports and files and thetelecommunications standard should be included in the LSA program. SOW. It ad hoc queries are chosen, the LSA program SOW mustcontain appropriate language without delineating specific reportand data files. If both predefined and ad hoc queries arerequired, include this in the LSA program SOW and indicate theLSAR report and other files to be accessed. (See 50.4.4 forsample SOW paragraphs.)
50.4.3. Decision guidelines. Options for delivery of LSAR datain digital form are not mutually exclusive. There will often becases when several options will be combined for specificdeliverables during a weapon system acquisition. The decisioncriteria presented in this handbook focus on the best options,but must be evaluated against program-specific requirements. Theguidance below applies the decision criteria to the various LSARoptions.
50.4.3.1. Intended data use. The following guidelines apply:
a. Select LSAR data files for consolidation ofdeliverables.
b. Select LSAR data files if significant internal analysisof the data is anticipated.
c. Select LSAR data files for input to automated* government receiving systems.
83
MIL-HDBK-59APPENDIX B
d. Select interactive access with predefined queries toreview LSAR data.
e. Select interactive access with ad hoc queries tosupport unique analysis or delivery needs.
50.4.3.2. Life cycle phases. The following guidelines apply:
a. Select LSAR data files for later, high volume phases.
b. Select interactive access to replace early phase LSARdeliverables.
c. Select interactive access to support LSAR data reviewsin all phases.
d. Select LSAR hard copy reports for early phases if lowvolumes of data in the current or later phases do notjustify the cost of additional automated processing.
e. Select LSAR hard copy reports for nondevelopmental
programs with limited service life data requirements.
50.4.3.3. Delivery cost. The following guidelines apply:
a. Select LSAR report image files if multiple reportcopies are required and the processing capabilities ofgovernment receiving system are limited.
b. Select LSAR data files, in general, as the most costeffective option for all deliverables.
c. Select interactive access to minimize on-site reviewrequirements.
d. Select magnetic tape for delivery of high volumes of
digital data.
50.4.3.4. Available technology. The following guidelines apply:
a. Select LSAR hard copy reports or interactive access ifno internal data processing system capabilities areavailable.
b. Select LSAR report image files or interactive access ifonly limited internal data processing systemcapabilities are available.
84
MIL-HDBK-59APPENDIX B
c. Select LSAR data files for full scale development orproduction phases if internal data processing capabili-ties are available or planned for that time.
50.4.4. Contract implementation for digital data. Automationand telecommunications technologies, while providing extendedcapabilities to industry and government, are altering the ways inwhich LSA and LSAR reporting and use are performed. The priordiscussion of decision choices on the LSAR decision templateindicated that there were six basic, yet non-exclusive, alterna-tives for delivery of digital data. These alternatives requirethat specific procedures be established for LSAR configurationmanagement, interactive access controls, government review andfeedback, and product delivery. The alternatives associated withtelecommunications assume that an interactive access capabilityexists for LSAR report files. When existing functional standardsare insufficient to describe the appropriate methods to contrac-tually invoke these alternatives, new SOW language must beprovided. Each alternative has specific SOW phrases that shouldbe included in the LSA program SOW. Sample SOW's are provided inthe following text to implement the alternatives as summarized intable IV.
TABLE IV. Summary of LSAR forms and standards.
Deliverable and Preferred Implement WithForm Delivery Mode
1. LSAR Report Magnetic Tape New SOW #1Files
2. LSAR Report Telecommunications New SOW's #1 &Files #2
3. LSAR Master & Magnetic Tape New SOW #1Data Files
4. LSAR Master & Telecommunications New SOW's #1 &Data Files #2
5. Interactive Telecommunications New SOW's #1 &Predefined Query #2
6. Interactive Ad Telecommunications New SOW's tl,
Hoc Query #2, & #3
50.4.4.1. Sample SOW language. The following sample SOW's
describe the contractor technology capabilities required by the
85
MIL-HDBK-59APPENDIX B
alternatives. These SOW's are cumulative based upon thecombination of alternatives desired within the program.
a. SOW #I is suggested for automated LSAR capability.
The contractor shall establish and maintain a validated LSARautomated data processing system capable of input, storage,and retrieval of LSAR data in accordance with MIL-STD-1388-2. The contractor may use an internally developed andvalidated LSAR automated data processing system, anindependently developed and validated LSAR automated dataprocessing system, or the government furnished Joint ServiceLSAR Automated Data Processing System. The validated LSARautomated data processing system shall comply with paragraph4.2.2 of MIL-STD-1388-2 and shall be used for thepreparation of LSAR output reports as specified in the CDRL.
b. SOW #2 is suggested for interactive access with prede-fined queries.
The contractor shall establish and maintain automated setsof LSAR data for the management and control of the LSAR. Asa minimum, the contractor shall maintain a set of LSARworking data for in-process review and a set of governmentapproved LSAR data. The LSAR data contained in the working(in-process review) set shall be LSAR that has beensubjected to internal contractor review procedures andfrozen, pending government review and approval. The LSARworking data shall be updated in accordance with theschedule in the LSA plan regardless of the approval statusof their content since the last update. Upon governmentapproval, LSAR data contained in the working set shall betransferred to the government-approved LSAR data set. Allgovernment-directed changes resulting from the LSAR reviewprocess shall be incorporated prior to relocation of thedata. The government-approved LSAR data shall be cumulativeof all government-approved LSAR data.
The contractor shall provide the government with interactiveaccess to both the working and approved LSAR data sets. Thecontractor shall provide the means for controlling accesscapability. The interactive access capability shall includethe ability to interrogate, retrieve, review, and print thefollowing:
1. Predefined standard LSAR summaries using establishedstandari LSAR report selection procedures contained inthe applicable Data Item Desuriptions.
86
MIL-HDBK-59APPENDIX B
2. Any of the following government specified reports:(SPECIFY CONTENT, FORMAT, AND SEQUENCE OF EACH REPORT)
The software will provide the capacity for terminal displayof the specified queries or data files in 80 and/or 132character format and will include the capability to printthe results of the queries on a local printer at designatedlocations. The user shall have the capability to specifyqueries by data set. User options shall include generationof queries from the working data, the approved data, or acombination of both.
The contractor shall provide government with the interact 2veaccess capability ----------------. (SPECIFY PERIODS OFREQUIRED ACCESS, i.e.,. 0800-1600 EASTERN STANDARD TIMEDAILY, 24 HOUR CONTINUOUS, ETC.) Government use of theaccess capability shall be limited to-----------------(SPECIFY ACCESS USAGE REQUIREMENTS, i.e., IN CPUMINUTES/MONTH, TOTAL CONNECT TIME, ETC.) Access shall belimited to the following locations: (SPECIFY LOCATIONS)
The contractor shall establish telecommunications capabilityusing one or more of the following methods and shallestablish a means for ensuring completeness and accuracy ofdata transmissions.
1. Point-to-point dedicated lines,
2. A mutually acceptable commercial timesharing or packetswitching network,
3. Telecommunications equipment and networks compatiblewith OSI using FIPS 146,
4. The Defense Data Network (DDN), or
5. Another mutually acceptable method as defined in the
contractor's proposal.
In addition, the contractor shall provide:
1. The hardware for each of the designated locations (ifrequired).
2. Maintenance for contractor furnished equipment andsoftware (if required).
3. Training for --- (SPECIFY NUMBER) operators at each* designated location.
87
MIL-HDBK-59APPENDIX B
4. --- (SPECIFY NUMBER) set(s) of automated dataprocessing system operator manuals and userdocumentation per location.
c. SOW #3 suggested language for interactive access withad hoc queries.
In addition to the predefined LSAR output reports, thecontractor shall establish the capability for on-line ad hocquery (report generation). Ad hoc reporting capabilitiesshall be defined by the contractor's LSAR automated dataprocessing system software and presented in the LSA portionof the contractcr proposal. As a minimum, the ad hoc reportgeneration shall be capable of keying on and displaying thefollowing LSAR data elements: LSA Control Number (LCN),Alternate LSA Control Number Code (ALC), Part Number, ItemName, Task Frequency, Federal Supply Code for Manufacturers(FSCM), Quantity Per Assembly, Unit of Measure Price, (ADDADDITIONAL DATA ELEMENTS AS REQUIRED TO THIS LIST).
50.5. ACQUISITION OF TRAINING PRODUCTS.
50.5.1. Scope. This section provides guidance in determiningtraining products to be delivered to the government in digitalform, and describes appropriate acquisition alternatives. Manybut not all training products are suitable candidates for digitaldevelopment, delivery, and application. Many training productscontain a combination of textual narrative and illustrativegraphic images presented in a formal, structured, page-orientedformat, which allows use of the same technologies and CITIScapabilities as are used for preparation and delivery oftechnical manuals. The guidance in this section assumes that theInstructional Systems Development (ISD) process described in MIL-T-29053 and the ISD deliverables identified in MIL-STD-1379D(DRAFT) or similar service-specific functional standards will beused to determine the appropriate form and format of trainingproducts to be delivered.
50.5.1.1. Training products and media. Training products areused to train military personnel in the safe and effectiveoperation and maintenance of weapon systems and equipment. Theycontain a composite of textual narrative and illustrative graphicimages presented in a variety of media which are determined byprogram-specific training needs. Each of these products andmedia has particular attributes which make it an appropriatetraining solution to a particular set of training needs.Although training products can be developed in a variety offorms, they are all presented via a finite set of training media.
88
MIL-HDBK-59APPENDIX B
Each of these training media could be contracted for anddelivered in a standardized digital format with varying degreesof ease and usefulness. The media used to present instructionalproducts can be grouped into the following media categories:
50.5.1.1.1. Instructor-based training. Instructor-based trainingincludes any form of training which utilizes an instructor,monitor, resource person, lab assistant, etc. Most of thetraining products which support instructor-based training couldeasily be contracted for and delivered as digital data. Theseproducts include instructor lesson plans, paper-basedsupplementary pr'duicts, student workbooks, copies of visualtraining aids, performance evaluation tools, and job aids.
50.5.1.1.2. Paper-based (page-oriented) training. Thepaper-based training category includes training that is conductedprimarily by some form of paper-based material. Paper-basedtraining products are page-oriented products in that informationis organized and presented via a page. Paper-based trainingusually includes the use of self-paced or instructor leadworkbooks, tutorials, or job aids. Also included in paper-basedtraining products are reference guides such as technical manualsand system documentation. (These are addressed separately inthis handbook.) A significant percentage of all trainingproducts currently developed are paper-based. Paper-basedproducts and training products could easily be contracted for anddelivered as digital data in much the same way as technicalmanuals.
50.5.1.1.3. Computer-based training. Computer-based trainingrefers to training which is delivered via a computer.Computer-based training includes tutorials, drill and practice,simulations, testing, and may also include embedded training.Computer-based training programs are already delivered in digitalform to the government. However, they are currently delivered ina variety of formats and on a variety of magnetic media.
50.5.1.1.4. Video-based and audio-based training. Video mediaincludes video tape or film training packages, interactive video-tape training, and interactive video disc training. Audio-basedtraining includes cassette tape programs, instructional records,training extension course tapes, and audio-workbooks.Audio-based training is often supplemented by paper-basedtraining such as job aids or workbooks and visual-based trainingproducts such as slides. Current technology would not allow forvideo-based training programs to easily be delivered in a digitalformat. Delivery of audio-based training programs in digital. form ir feasible. Whether or not it is cost effective and
89
MIL-HDBK-59APPENDIX B
useful to require audio-based training programs to be deliveredin digital format is undetermined.
50.5.1.2. Training products development. DoD has developed theISD methodology as a standard approach for the development of allcontractor produced training programs throughout the military.ISD is a highly structured methodology which calls for thedevelopment of standard interim products, such as reports andplans, and ongoing government review. This highly structuredmethodology lends itself to delivery of products in digital formfor government review and approval before the contractor moves tothe next step in the development process. For the purposes ofsimplicity, this appendix addresses deliverables set forth inMIL-STD-1379D (DRAFT). However, the guidance provided in thisdocument also applies to other service-specific trainingdevelopment guidance documents.
50.5.1.2.1. Interim products. The standard interim products thatresult from the ISD methodology typically include paper-based,page-oriented products such as training programs and trainingequipment plans; manpower, personnel, and training reports,personnel performance profile reports, media selection andsyllabus reports; and course, module, and lesson objectives, etc.Additional products which may be developed in either paper-basedor digital form include course, module, lesson flowcharts, tests,storyboards, and visual or video media shotsheets. The ISDmethodology specifies that the government must review and approveeach interim product before the contractor moves to the next stepof the development process.
50.5.1.3. Data sources for training products. The LogisticSupport Analysis Record (LSAR) consolidates logistics-orientedtechnical information in conjunction with data for the variousengineering disciplines and Integrated Logistic Support elementsto reduce redundancy, facilitate timely usage, and enhanceconsistency between data elements and disciplines. The qualityand productivity of training product development is enhanced whenthe LSAR is used as a principal data source for this process.Integration of the data bases that produce LSAR task analysis(and other) data, technical manuals, and training materials willprovide even greater benefits.
50.5.1.4. Coverage. This section only addresces the delivery indigital form of page-oriented training products. Requiring alltraining products to be delivered in a standard digital formwould probably not be co'st effective at this time.
50.5.2. Decision option discussion. Figure 8 shows the decision
template applied to page-oriented training product deliverables.
90
MIL-HDBK-59APPENDIX B
Decisions regarding whether training products should be deliveredin digital form and the specifications for that form should beconsistent with decisions made for other contract deliverablessuch as technical manuals. The following sections describe thedecisions to be made in determining the form and appropriatespecifications for training product deliverables.
Decision #1 Decision #2 Decision 83 Decision #4SO S&Delivery
Deliverable Eorm tandards Modi
Hard Copy MIL-STO-1379
Training MIL-STD-1840
Documents-
DataL
S P OL.... ... .... .... ... .... ... M a g n e t ic T a p e
FaPhysical Mediau
Text File MIL-STD-1840 Tpdcs
an Processele MIL STd-1840 ............................. .............
datafile.lTesefGraphics Filert a
.............................. Legend:interactiveSAccess to Cur n
...iTraining ......... Future ISDevelopment.Data .........
FIGURE 8. Decision inatme for training products.
50.5.2.1. Deliverable options - decision #1. Training productscan be delivered as either composed documents, or as processabledata files. The use of interactive access is a future goal,largely because of the absence of integrated data bases oftraining data in sending systems. As these CITIS capabilitiesare established and merged with technical manual authoringsystems, interactive access will become a practical alternativefor review and approval of interim training products.
50.5.2.1.1I. Deliverable options - decision #1 (for composedtraining product documents). The composed document deliverable,option offers the least flexibKility, it is a static, tormattedpresentation of the material which can only be archived, viewed,or printed after receipt. Documents can be delivered as either. camera-ready hard copy, or as a digital print/display file.
91
XIL-HDBK-59APPENDIX B
50.5.2.1.2. Deliverable options - decision #1 (fzr processablefiles). Processable training product data file deliverablesoffer more robust capabilities than document form deliverables.These files can be updated or transformed into many differentdocument types. With the appropriate governmental receivingsystems, processable files can support the development of summaryguides, training aids, and eventual on-line distribution ofselected portions of the data to trainees. Processable files arepreferable because of their flexibility and maintainability;however the tools to permit acceptance and utilization of theinformation in this form are in various stages of development atthis time.
50.5.2.2. Form options - decision #2.
50.5.2.2.1. Form options - decision #2 (for composed trainingproduct documents). The form for composed training productdocument delivery can be either a hard copy or a digitalprint/display file. The digital form of this deliverableconsists of composed page images of material. It offers greateradvantages in storage, distribution, viewing, and printing thanhard copy. It also provides slightly more flexibility than hardcopy with respect to future data uses, although its format willbe fixed and unyielding. It is a two-dimensional image of eachpage, offering no further updating or processing features beyondreplication. When changes are made, however, they can be moreeasily distributed than paper-based changes.
50.5.2.2.2. Form options - decision #2 (for processable datafiles). At present, a processable file must comprise one set offiles for textual or numeric data and separate files forgraphics, i.e., illustrations and drawings. In the future, textand graphics files will be available as integrated data fileswith configuration management and positioning features. Thetechnologies and standards to accomplish such integration and toallow joint processing or creation of the two data formats forconcurrent presentation, however, are not yet sufficientlyadvanced.
50.5.2.3. Specifications and standards - decision #3.
50.5.2.3.1. Specifications and standards - decision #3 (for hardcopy). Currently each deliverable form, with the exception ofthe processable files graphic file form, has one predeterminedstandard and specification. The hard copy form should beacquired in compliance with MIL-STD-1379D (DRAFT).
50.5.2.3.2. Specifications and standards - decision #3 (forprint/display files). The digital form of the composed training
92
MIL-HDBK-59APPENDIX B
product document, a print/display file, requires tailoring MIL-STD-1379D (DRAFT) by referencing the appropriate standards shownin 50.5.4. This data can also be delivered as raster pageimages, in accordance with MIL-R-28002. For most applications,the default Type I (untiled) format is applicable. Storage ofpage images in a Page Description Language (PDL) provides anintermediate form which is slightly easier to maintain. PDLfiles can be acquired using MIL-M-28001. However, these are notstandardized, for no Standard Page Description Language (SPDL)exists yet.
50.5.2.3.3. Specifications and standards - decision #3 (forprocessable files). Processable training product files compriseseparate text and graphics files. There is only one availabletext file standard, MIL-M-28001 (SGML), but users must requirecreation and delivery of appropriate document type definition andoutput specification support files, as well as the SGML-taggedsource file. There are several standards available for graphicsfiles. As with technical manuals, a mixed mode deliverable,consisting of processable text in accordance with MIL-M-28001 andraster document image files in accordance with MIL-R-28002 is aviable option. Raster format is often an attractive,. cost-effective alternative for converting existing paper-baseddrawings and illustrations into digital form. Because they offermore flexibility and utility, and may be created and used on agreater variety of computer systems, vector graphics arepreferred for new weapon system acquisitions. Use of CGM ispreferred, but IGES is allowed. MIL-D-28003 addresses CGM vectorgraphics data; based on program requirements for interim andfinal training product deliverables, the acquisition managershould choose between draft quality Level II and publicationquality Level I CGM conforming metafiles. MIL-D-28000 addressesvector graphics in IGES format; the Class I technicalillustration subset is most appropriate.
50.5.2.4. Digital delivery mode - decision #4. As shown on thedecision template, physical media are currently the only deliverymode option for the digital delivery of document image files orprocessable files. While a telecommunications bulk transfer ofthese files may be possible, it is not currently a feasibleoption because of the large volume of data contained in thesefiles, particularly the raster page image and raster graphicsfiles. Magnetic tape is currently the only physical media optionavailable for the delivery of print/display files or processablefiles. Optical disk will become a future alternative physicalmedia standard. For magnetic tape standards, reference the tapemedia standards contained in Appendix D of this handbook.
93
MIL-HDBK-59APPENDIX B
50.5.3. Decision guidelines. Options for delivery of trainingproducts in digital form are not mutually exclusive. There willoften be cases when several options will be combined for specificdeliverables during a weapon system acquisition. The decisioncriteria presented in this Handbook can be used to help make thedecisions on the decision template. The following is guidancefor applying the criteria to training products.
50.5.3.1. Intended data use. The following guidelines areprovided:
a. Select processable files if government update andmaintenance is anticipated for the future.
b. Select processable files if the future creation ofspecialized documents and aids is envisioned.
c. Select raster image files if only an automated print-on-demand capability is desired or available.
d. Select vector graphics files if update and maintenanceof illustrations and drawings is desired.
50.5.3.2. Life cycle phases. The following guidelines areprovided:
a. Raster image or print/display files should be acquiredearly in the life cycle of the program if most costeffective.
b. Processable training product files should be thedeliverable of choice when the government assumes theresponsibility for training manual update and maintenance.
c. Select static page-oriented documents if a program isin a late phase and large amounts of data already exist inpaper form.
50.5.3.3. Delivery cost. The following guideline is provided:
Select magnetic tape for delivery because of the highvolumes of digital data required by training products.
50.5.3.4. Available technology. The following guidelines areprovided:
a. Options should be aligned to the automated publishingsystems/computer resources in the Military Departmentreceiving the deliverable.
m m |94
MIL-RDBK-59APPENDIX B
b. Select hard copy if no internal data processing systemcapabilities are available or planned.
c. Select raster print/display files if only minimal dataprocessing capabilities are available internally.
50.5.4. Contract implementation for digital data. There are fivebasic, yet nonexclusive, alternatives for delivery of digitaldata. These are shown in table V. The existing functionalstandard is insufficient to contractually invoke thesealternatives. Therefore, tailoring of MIL-STD-1379 is required.
TABLE V. Summary of training products forms and standards.
Deliverable and Preferred Implement WithForm Delivery Mode
1. Training Product/ Magnetic Tape MIL-R-28002 or Mil-M-Print Display 28001 (PDL only), and
MIL-STD-1840
2. Processable Magnetic Tape MIL-M-28001 and MIL-Text File STD-1840
3. Processable Vec- Magnetic Tape MIL-D-28000 and MIL-tor Graphics STD-1840File - IGES
4. Processable Vec- Magnetic Tape MIL-D-28003 and MIL-tor Graphics STD-1840File - CGM
50.5.4.1. Training functional standard. Following itspublication, reference the tailored MIL-STD-1379D in Block 16 ofthe CDRL (DD Form 1423) to specify delivery of digital data inaccordance with its requirements and MIL-STD-1840. Pendingpublication of MIL-STD-1379D (draft), make its language part ofthe statement of work. The physical media standards for magnetictape delivery mode shown in Appendix D should also be specified.
50.6. ACQUISITION OF TECHNICAL SPECIFICATIONSAND REPORTS (RESERVED).. (This section will provide a decision template and supporting
rationale for the acquisition of technical specifications,
95
MIL-HDBK-59APPENDIX B
reports, plans, and other contractual deliverables involvingintegrated text and graphics, e.g., those prepared in a desk toppublishing environment. The National Institute of Standards andTechnology is doing the work and the results will appear in afuture update of this handbook.)
50.7. ACQUISITION OF INTERACTIVE MAINTENANCE AIDS (RESERVED).
(This section will provide a decision template and supportingrationale for the acquisition of interactive maintenance aids indigital form.)
960
MIL-HDBK- 59APPENDIX C
APPENDIX C
FUNCTIONAL REQUIREMENTS FORINTEGRATION OF CONTRACTOR PROCESSES
0 97
MIL-HDBK-59APPENDIX C
THIS PAGE INTENTIONALLY LEFT BLANK.
98
MIL-HDBK-59APPENDIX C
10. SCOPE
10.1. Applicability. This appendix provides guidance togovernment activities on establishing contract requirements forfunctionally integrated contractor design and systems engineeringprocesses on weapon system and major equipment developmentefforts. It is applicable to all Department of Defense (DoD)components which acquire weapon systems through the normalcontracting process.
10.2. Purpose. This appendix is intended to suggest the bestmethods for tailoring the wording of standard DoD Requests forProposal (RFP's) and Contract Deliverable Requirement Lists(CDRL's) to allow and encourage the integration of designengineering, systems engineering, and support engineering effortsand the digital exchange of data among them.
20. REFERENCED DOCUMENTS
See list of references appearing in Appendix A.
30. DEFINITIONS
See list of terms and acronyms appearing in Appendix A.
99
MIL-HDBK-59APPENDIX C
40. GENERAL GUIDANCE
40.1. Contracting for integration of functional processes. Amajor objective of CALS is the application of computer-aidedmethods and supporting technologies to incorporate logisticsupport functions as an integral element in the weapon systemcontractor's design process. To achieve this, the acquisitionmanager should apply the detailed requirements contained insection 50, tailored to fit the acquisition strategy selected forthe program. These requirements specify the integration ofdesign, manufacture, and support processes, as well as otherelements of concurrent engineering, for the performance of DoDcontracts. At a minimum, the general goals and objectivesapplicable to each identified functional area should be stated inindustry informational briefings, commerce business dailylistings, source solicitations, or instructions to RFP offerors.The full benefit to the program is realized only when thefunctional requirements are included in the RFP and the proposalevaluation/source selection process, and made contractuallybinding as described in section 50.
40.2. Strategic approach. As CALS evolves, weapon systemtechnical data will be logically integrated into tightly coupled,controlled, and secure CITIS and government technical informationsystem data bases, allowing access and authorized sharing of dataat the data base level. Functional integration of contractorprocesses to ensure the security, currency, and accuracy of CITISinformation will be articulated and contractually specified asCITIS requirements. CALS initiatives to improve technical datacreation, management, and use provide an enabling environmentthat will accelerate the application of concurrent engineering, asystematic approach to creating a product design that considersall elements of the product life cycle from conception throughdisposal. In so doing, concurrent engineering simultaneouslydefines the product, its manufacturing processes, and all otherrequired life cycle processes, such as logistic support. CALSfunctional requirements for concurrent engineering will providethe necessary focus for a comprehensive concurrent engineeringstrategy that addresses multiple approaches and the necessaryenabling environment. Specific CALS thrusts, such as integrationof R&M with CAD and CAE will directly contribute to applicationof concurrent engineering concepts.
40.3. Application environment. The earlier in the acquisitioncycle that this strategy is introduced, the greater the potentialproductivity and quality improvements. As decisions affecting aproduct's design are made, both acquisition and operationalsupport costs become defined. The earlier in a system's design
100
MIL-RDBK-59APPENDIX C
definition that the user's requirements can be addressed by theproduct design and associated manufacturing processes, thegreater the opportunity to produce a more robust, supportabledesign at lower life cycle cost and greater operationaleffectiveness. This requires a change to the way most companiesfunction. For example, new product designs historically havebeen the property of the company's engineering department. Whendesign and engineering analyses are completed, the design passesto manufacturing, where necessary engineering changes areidentified, beginning a costly iterative process resulting in theas-designed vs. as-manufactured configurations of the product. ACALS and concurrent engineering strategy must begin at Milestone0 to produce the greatest returns in terms of development time,acquisition cost, life cycle support cost, and productreliability and maintainability.
40.4. R&M integration with CAD/CAE. The detailed requirementscontained in section 50 are applicable to all engineeringactivities that define, establish, or influence reliability andmaintainability (R&M) properties during all phases of itemdevelopment, including concept exploration, demonstration andvalidation, full scale development, and production. The intent. of section 50 is to influence the contractor to conductengineering activities which have a bearing on the R&M propertiesof the ultimate fielded product, using computer aided design(CAD) and computer aided engineering (CAE) procedures thatinteract and actively share data with all other designengineering processes and procedures. Traceability of key designdecisions having a major bearing on the R&M properties of theitem to the engineering procedures, design criteria, and databases that influenced the decisions is also a major goal.
40.5. Integration of contractor LSA processes with R&M and
design engineering. (Reserved).
40.6. Configuration management of technical data. (Reserved)
40.7. Concurrent engineering. (Reserved)
0 101
XIL-HDBX-5 9APPENDIX C
50. DETAILED GUIDANCE
50.1. Organization of guidance sections. This section isorganized into several major sub-sections, which can be usedseparately or together to contract for integration of contractorfunctional processes.
50.2. FUNCTIONAL REQUIREMENTS FOR R&M INTEGRATION WITH CAD/CAE
50.2.1. Purpose. This section provides guidance for theprocuring activity in generating contractual requirements toachieve the integration of computer aided R&M engineeringtechniques with CAD and CAE in the development of weapon systems.It is applicable to all engineering activities that define,establish, or influence R&M properties during all stages of enditem development, including concept exploration, demonstrationand validation, full-scale development, and production.
50.2.2. Impact of R&M. R&M has a decisive influence on weaponsystems acquired by DoD.
50.2.2.1. R&M influence on effectiveness. Weapon system R&Mcharacteristics influence the weapon system's operational effec-tiveness by driving its readiness for battle, sustainabilityduring battle, and utilization of personnel and material duringtraining and battle. It is recognized that good R&Mcharacteristics are force effectiveness multipliers by offeringthe means to defeat a numerically superior force by engaging itrepeatedly. Reliable weapons systems result in increased combatcapability while employing fewer fielded spare parts and lessmanpower. Similarly, maintainable systems require fielding offewer people and specialized skill levels, while achievingreduced maintenance times. Good R&M characteristics improve themobility of forces because there are fewer people and lesssupport equipment and spares to move. In short, the R&M featuresof each weapon system contribute significantly to the conflictcapabilities of forces at sea and in the field.
50.2.2.2. R&M influence on life cycle cost. The R&Mcharacteristics of a weapon system are also key leverage pointsin determining the weapon system's total life cycle costs andoperational effectiveness. An estimated 30 percent of life cyclecosts can be traced directly to R&M characteristics of the weaponsystem's design. These costs occur not only as budgeted lineitems in the procuremeit and operations and maintenanceappropriations for the particular weapon system, but also asindirect costs of the supporting logistics facilities and
102 0
MIL-DBK- 59APPENDIX C
activities, manpower, attrition replacements and replenishmentspares.
50.2.2.3. R&M in the design process. While conventional stand-alone post-design R&M engineering tasks, such as test, analyze,and fix (TAAF), have been moderately successful in achievingimproved R&M, these approaches are fundamentally limited by theirinability to influence the design process itself. To a largeextent, the R&M characteristics of a weapon system are attributesof its design, or more precisely, a direct function of the atten-tion given to them in the design process. They are analyzed intothe design after it has been completed only with great difficultyand cost. Additionally, the R&M improvement effort must competewith integration and operational testing for test resources andschedule.
50.2.2.4. CAE in development. The application of CAE resourcesto the R&M characteristics of weapon system development in anintegrated design environment has the potential for effecting aquantum improvement in R&M. When applied to R&M design, CAE willprovide the designer with closely-coupled, short-cycle analysisand feedback about the efficacy of the design approach so that.corrective action and optimization can occur during the designprocess rather than later. In addition, concurrent designsynthesis techniques offer'a superior inherent R&M designcapability. In essence, CAE enables the designer to design theproduct right the first time with respect to R&M, the objectiveof Total Quality Management (TQM).
50.2.3. General implementation guidance. The ultimate goal ofintegration of R&M into CAE is for all major design decisionsaffecting the R&M characteristics of the end item to be fullysupported by automated procedures that are appropriate to thenature and level of the decision in a concurrent ornear-concurrent fashion.
50.2.3.1. Achieving the potential of CAE. Achieving the fullpotential of integrated CAE requires capabilities in fivefundamental areas:
a. Automated R&M analysis procedures tightly coupled toparts libraries and materials characteristics databases.
b. Automated R&M synthesis processes based on design rulesincorporating lessons learned from prior design experi-ence and field use.
0103
MIL-HDBK-59APPENDIX C
C. Fully characterized (tested and validated) componentperformance and R&M characteristics data bases.
d. Configuration management procedures that link majordesign decisions affecting the R&M characteristics ofthe end item to: (1) the CAE software.and data basesused to develop decision criteria and otherwise supportthe decisions, and (2) the evolving configuration ofthe product, documented through configuration-controlled versions of the digital product description.
e. a supporting structure of hardware, software, andcomputer networks adequate to support the proceduresand processes of (a) through (d) above and to closelycouple R&M-specific resources (including personnel)with the rest of the design team.
50.2.3.2. Contrast of traditional and integrated approaches.Traditional R&M requirements take the form of independent tasksto be performed by the contractor as detailed in the contractStatement of Work (SOW), and in any R&M-related attachments andexhibits. The results of these tasks are to be delivered inaccordance with the Contract Deliverable Requirements List (CDRL)in the format specified by a Data Item Description (DID). Theintegrated R&M functional requirement is different because itplaces an indirect requirement on the contractor's engineeringresources, in the form of R&M-specific CAE techniques,procedures, and data bases. This indirect requirementnecessitates a different contracting approach than doestraditional R&M tasking, but is consistent with streamlining, andallows the contractor more freedom to determine how to satisfythe government's requirements. It replaces emphasis on specificSOW tasking with increased emphasis on the use of instructions toofferors and source selection criteria. This approach leads thecontractor to tell the government how integrated R&M-specific CAEis to be applied to the program being bid, rather than tellingthe contractor how to apply it.
50.2.3.3. Integrated procedure. In essence, using thisapproach, the government will ask the contractor to describetheir existing and proposed R&M automation capabilities; awardthe contract based, in part, on the strength of the response;make any necessary adjustments during final negotiations; andincorporate the results in the ensuing contract. No additionalCDRL items or DID's are required. CDRL items and DID's normallyinvoked to acquire R&M data can be tailored in ways thatencourage the contractor to develop automated means for thegeneration and submission in digital form of these data.
104
NIL-HDBK-59APPENDIX C
Suggested wording to implement tailoring is presented in50.2.5.1.
50.2.4. RYP and source selection guidance. The followingguidance is provided on contracting for integrated R&M data.
50.2.4.1. Approach.
50.2.4.1.1. Instructions to offerors. Section L (Instructionsto Offerors) of the Request for Proposal (RFP) should require thecontractor to:
a. Identify its capability and experience in the use ofautomated R&M functions.
b. Explain to what extent R&M design tasks are integratedwith its CAE system.
c. Describe how specific CAE techniques, processes, anddata bases will be used to satisfy R&M requirements.
d. Describe how R&M data bases will be used to supportlogistic support analysis and record generation.
50.2.4.1.2. Evaluation criteria. Section M (EvaluationCriteria) should be structured to emphasize these issues.
50.2.4.1.3. Contractual Application. The offeror's proposedcapability should be made part of the final contract.
50.2.4.1.4. Summary of benefits. This process ensures that:
a. R&M CAE functions are user-driven and not justresponses to government requirements.
b. R&M CAE is essential to winning contracts, andtherefore will be given proper emphasis.
c. Specific R&M CAE capabilities will be used in thedesign and logistic support processes and will not betraded off or deleted because specific SOW requirementswere not defined.
50.2.4.2. Sample language. The following subparagraphs containsample language that is recommended for incorporation in SectionsL and M of an RFP.
105
MIL-RDBK-59APPENDIX C
50.2.4.2.1. Wording for Section L. The following wording is
suggested for incorporation in Section L of RFP's:
System Engineering: Computer Aided R&M Engineering Support
The offeror shall submit a description of the way in whichComputer Aided Engineering (CAE) techniques and relatedresources are to be used to ensure that design decisionsaffecting the ultimate R&M properties of the system (item)are adequately supported by automated trade-off analysis,engineering simulation, or concurrent design synthesisprocesses. This shall include a general description of theCAE environment within which design and development isintended to take place, and a specific description of theCAE capabilities dedicated to R&M support. It shall alsoinclude a discussion of the offeror's formal procedures toverify and maintain the accuracy and effectiveness of theseR&M CAE capabilities by validating the quality of theengineering functional capability performed, data basemaintenance, and development of lessons learned design rulesfrom all sources of feedback. This documentation shallconstitute a major element of Part III - EngineeringSpecialty Integration, of the System Engineering ManagementPlan (SEMP). The offeror's internal format is acceptablefor this documentation. The System Engineering MasterSchedule (SEMS) shall describe the timeliness of theseinputs relative to the overall system engineering programand other design activities.
The general description, including implementation status(current or proposed) of the CAE environment shall consistof the following:
1) CAE hardware resources available to the program,including percentage availability of shared resources.
2) CAE application programs available to the program,including source of commercial software, identification ofproprietary software, and methods used to assure softwarequality.
3) Integration approach, including communicationsnetworking, data base sharing and management, andconfiguration control.
4) Policies, procedures, and organizational responsibilityfor control of CAE automation, specifically R&M automatedtools.
106
MIL-HDBK-59APPENDIX C
5) Data standards and technical standards available fordelivery of technical data to the government in digitalform.
The specific description of R&M resources based within theCAE environment shall consist of the following:
1) An overview of the CAE resources, including hardware,software, and data bases to be applied to R&M.
2) The degree to which R&M tasks and functions, includingtestability and manufacturability tasks, are automated. Asa minimum, all tasks imposed in accordance with MIL-STD-470,MIL-STD-785, and MIL-STD-2165 shall be classified into thefollowing categories:
a. Not automated.
b. Stand alone, no direct access to the CAE design database.
c. R&M algorithms reside within the CAE system,interfacing with the evolving resident item design wheninvoked.
d. R&M algorithms reside with the CAE system, respondingautomatically to all initial inputs, derived factors,and design changes where appropriate to support adesign decision.
The offeror will receive credit in proposal evaluation fordesign-integrated R&M tasks and functions provided they aredemonstrated to contribute to a coherent end-to-end R&M,CAE, or LSA engineering process.
3) Descriptions of the offeror's formalized procedure andpast history of deriving 'lessons learned' from testresults, field feedback, and vendor data, and translatingthem into design rules incorporated into the CAE system.This is not intended to be a repetition of the offeror'splan for a Failure Reporting, Analysis, and CorrectiveAction System (FRACAS) for the specific program. It shallbe a description of how the offeror uses information fromvendors, testing, and the field to improve both products,and design and manufacturing processes on an institutionalbasis, and how that process is intended to be applied to theprogram. The description should contain the process forconfirming and assigning a level of confidence to the designrules; the controls over R&M design rules that are exercised
107
MIL-NDBK-59APPENDIX C
by the R&M organization; and the process by which tradeoffsbetween R&M design rules, cost, and equipment performanceare accomplished.
4) A listing of the key design decision points influencingR&M in the proposed effort, the automated R&M functions thatwould be used to support them, and the relative time (withrespect to major design reviews) of the decisions.
5) Description of data bases to support R&M characteristicsof the features, components and materials applicable to theprogram (e.g. preferred parts list), including supportinginformation on source of data (vendor, company tests,government data bases, etc.); confidence factors reflectingboth quantity of their source, and whether or not they arebased on estimates, simulation, broad categories of parts,tabular data, or actual measurements; applicability to theprogram; specificity and level of detail; and applicabilityto reliability, maintainability, or diagnostics.
6) Description how product development configurationcontrol procedures will be applied to R&M, including thecapture of design decision criteria; discussion of thelinkages between the design process and the R&M-specific CAEresources that were applied to it; discussion oftraceability of design decisions to CAE resources, includingsoftware and data bases that supported them; and proceduresin place to rapidly reassemble those resources to effect andrecord the impacts of an engineering change proposal withminimal impacts to the R&M characteristics of the system(item). State if this engineering history will be availableto the government.
7) Description of the integration of R&M-specific resourceswith the other product development resources, includingpersonnel, CAE communication networks, application software,and data bases.
8) The specific proposed wording for R&M CAD/CAErequirements to be imposed on all subcontractors ofelectronic subsystems, modules, assemblies, and customcomponents. The general criteria used to evaluate asubcontractor's responses to R&M CAE requirements relativeto other criteria such as cost, schedule, and performance.
9) Description of the offeror's internal procedures throughwhich the automated R&M functions including supporting databases are demonstrated to be correct, including conformanceto industry standards if applicable.
108
MIL-HDBK-59APPENDIX C
10) Description of the capability to deliver Failure Modes,Effects, and Criticality Analysis (FMECA); predictions;LSAR; failure summary reports; and other R&M reportsappearing in the attached contract CDRL as digital data ingovernment-approved standard formats.
50.2.4.2.1.1. Wording if risk reduction is required. If theInstructions to Offeror contain a requirement for a sectiondescribing a risk reduction effort, the following wording inaddition to 50.2.4.2.1 is suggested:
The offeror shall identify the intended use of ComputerAided Engineering (CAE) techniques to aid in reliability andmaintainability risk reduction, outlining the risks to beaddressed, how CAE is intended to help reduce them, and thebenefit of CAE over other approaches, including level ofrisk reduced, accuracy, or timeliness of results.
50.2.4.2.1.2. Wording if preliminary design is required. Wherethe Instructions to Offeror contain a requirement to providepreliminary design, system block diagram, functional partitioningof requirements, definition of configuration items, or. preliminary system or item specifications, the following isintended to be added. The exact wording of the informationrequested from the offeror should be substituted for the phrasepreliminary design.
It is critical that preliminary design data provided to thegovernment by the offeror contain sufficient supplementaldocumentation so that the government can understand thedesign criteria used to support the preliminary design.Information documenting the CAE resources that supportedmajor tradeoff decisions impacting R&M, including adescription of the tradeoff decisions and a summary tracingthe specific nature of the input to the decision from R&M,shall be provided.
50.2.4.3. Sample language for Section X. The following wordingis suggested for incorporation in Section M, Evaluation Criteria,of RFP's:
The offeror's (technical/management/system engineering) planwill be evaluated for the extent of intended application ofCAE. It is not adequate for evaluation purposes simply tocite the use of CAE on a blanket basis; i.e., CAE resourceswill be applied where applicable. The offeror must demon-strate their understanding of the use of CAE by including ina proposal a brief discussion of how CAE is to be applied tothe R&M engineering process. The discussion should include
109
XIL-HDBK-S9APPENDIX C
a specific summary of the CAE resources intended to beapplied, the points in the development process whereleverage from CAE is anticipated, any government requiredanalysis that will be generated in whole or in part by CAE,and expected benefits to the program. The followingspecific criteria will be used:
1) What is the capability described by the offeror fordirect concurrent or near-concurrent synthesis of the R&Mcharacteristics of the design based on design rules,embedded design knowledge, feature-based design, or lessonslearned files? What major R&M design decisions are sosupported?
2) What processes does the offeror describe for conversionof lessons learned from the field or test processes to R&Mdesign rules? Is there a formal process for creating,implementing, and validating new rules on the same CAEsystem/data base used to design the product?
3) Are adequate design analysis tools available to providethe information necessary for trade studies and for supportof other data requirements (e.g., logistics)? Do thesetools interact with relevant CAE design data base parametersas they evolve?
4) Are the R&M-specific CAE feature, component, andmaterials characteristics data bases (including failureproperties, mechanical properties, and component models tosupport detailed engineering simulation of the product)adequate to support the design effort required? To whatextent are they validated?
5) If the government plans to take over responsibility forsustaining engineering, to what extent will the offerorprovide design decision traceability, including supportingdata packages or data files? Are the interfaces between thecontractor and the government, and between the contractorand any suppliers, adequate to support transportation ofproduct data and models?
6) Does the offeror intend to employ sufficient CAEresources, including hardware, software, integration, andnetworking facilities, to adequately reduce risk andaccomplish the proposed R&M program in a timely fashion?
50.2.5. Contract requirements. Contractor responses to SectionL of the RFP should be used in final negotiations with thewinning contractor. The object is to incorporate as contract
110
MIL-KDBK-59APPENDIX C
requirements all proposed items that the government andcontractor believe will provide significant benefits to thedesign in terms of improved R&M performance. As contractrequirements, the chance of R&M CAE functions being eliminateddue to pressures from other program elements (e.g., costs,schedule) will be minimized.
50.2.5.1. CDRL items. No additional Contract Data RequirementsList (CDRL) items are required as a result of R&M CAE implemen-tation. While R&M CAE may reduce CDRL costs for some items, thespecific CDRL requirements for each program should be based onspecific government needs for design data.
50.2.5.2. Tailoring. In general, the CDRL lists the data to bedelivered under the contract, frequency of submittal, generationprocedures, and required formats. One method of motivatingcontractors to undertake R&M tool development and integration isto tailor the CDRL and the associated DID's. Selected tailoringcan accomplish this goal by providing incentives for automateddata item generation. A recommended tailoring approach for eachof these elements is discussed below, followed by models ofcontract wording where appropriate.. 50.2.5.2.1. R&M task selection. The availability of computerprocessable data must be considered when attempting to encouragethe automation of any R&M task. The selection of the R&M tasksto be accomplished and the associated data items delivered aredevelopment phase dependent. This information can also be foundin various military standards that describe the requirements forR&M programs. When an R&M task is required, the level of dataexpected to be available must be considered. For example, duringthe concept exploration phase, the Failure Modes, Effects, andCriticality Analysis (FMECA) can be performed to the functionallevel. The detailed level of digital data available during thefull scale development phase, however, permits the accomplishmentof the FMECA down to the device level. Where the offerorproposes to use CAE to support an R&M analysis task, thegovernment program office can expect higher quality andtimeliness in delivery of detailed data in a more useable form.
50.2.5.2.2. CDRL/DID cross references: tailoring for digitalformat. The CDRL will include a reference to the proceduresrequired to perform the data item generation and to the desiredformat by referencing the Data Item Description (DID) to be usedin Block 4 of DD Form 1423. During the phase-in period, thecontractor can be encouraged to use automated data itemgeneration capabilities by permitting data to be delivered inO formats and standards that are not in conformance with CALS
111
MIL-HDBK-59APPENDIX C
directives. The following CDRL wording may be used in Block 4 ofDD Form 1423:
Block 4: If automated data item generation capability isused, contractor's format is acceptable.
50.2.5.2.3. Tailoring: frequency of submissions. In an effortto reduce the number of submissions required, one CALS objectiveis to establish government access to contractually approvedportions of the contractor's CITIS data base. The program officeshould explore this option where applicable to reduce datadelivery.
50.2.5.2.4. Tailoring DID language. The DID references theappropriate military standards and guidance to be used for dataitem generation, and includes formatting instructions.Generally, DID's are tailored to account for unique programaspects. Tailoring of the procedures and methods required fordata item generation and the format of the deliverable can alsoencourage automation of the data item preparation task. Thefollowing wording is suggested:
It is recommended that the contractor employ automatedcapabilities in the generation of the data items required.Modification of the submission format consistent with thelevel of automation proposed is acceptable. Submission ofdata in digital format is encouraged.
50.3. FUNCTIONAL REQUIREMENTS FOR INTEGRATION OF CONTRACTOR LSAPROCESSES WITH R&M AND DESIGN ENGINEERING.
50.3.1. Purpose. This section provides guidance for theprocuring activity in generating contract requirements forintegration of LSA and R&M engineering processes. Theseprocesses are often performed by separate contractororganizations, supported by separate automated sys4 ems.Integration can reduce duplication of effort, improve theconsistency and quality of data, and improve the quality of thesystem or item under development. The following statement ofwork (SOW) language is appropriate when the contractor has, or isexpected to have, automated LSAR and R&M data systems.
50.3.2. Suggested contract wording. The following wording issuggested for incorporation in the SOW:
The contractor shall identify in the LSA plan theprocedures, either automated or manual, that will be used toensure LSAR documentation requirements for reliability and
112
MIL-HDBK-59APPENDIX C
maintainability (R&M) information are satisfied through useof appropriate (R&M) data sources. The procedures shalldescribe how R&M source data are to be used in developingthe LSAR, and shall address initial R&M inputs as well aschange control for data additions, deletions andmodifications. The procedures shall also identify thealgorithms or transformations that must be applied to sourcedata elements to conform to LSAR documentation requirements.The procedural description shall be of sufficient detail toclearly demonstrate traceability between the LSAR andindividual R&M data sources, and the preservation ofappropriate data flows while maintaining established LSARdata element relationships and interdependencies.
50.4. FUNCTIONAL REQUIREMENTS FOR CONFIGURATION MANAGEMENT OFTECHNICAL DATA. (RESERVED)
(This section will provide suggested SOW language forconfiguration management capabilities in government-owned,contractor-maintained data bases that support integratedfunctional processes. The CALS Industry Working Group on. Configuration Management and Indexing is doing the work and theresults will appear in a future update to this militaryhandbook.)
50.5. FUNCTIONAL REQUIREMENTS FOR CONCURRENT ENGINEERING.(RESERVED)
(This section will provide suggested SOW language for applicationof a concurrent engineering strategy as part of the design anddevelopment process for weapon systems and major equipment items.The CALS Industry Working Group on Concurrent Engineering isdoing the work and the results will appear in a future update tothis military handbook.)
113
NIL-NDBX-59APPENDIX C
THIS PAGE INTENTIONALLY LEFT BLANK.
114
)MIL-RDBI-59APPENDIX D
APPENDIX D
CONTRACT REQUIREMENTS FOR DELIVERY MODES
115
MIL-HDBK-59APPENDIX D
THIS PAGE INTENTIONALLY LEFT BLANK. 0
0116
MIL-HDBK-59APPENDIX D
10. SCOPE
10.1. Applicability. This appendix provides guidance togovernment activities on the use of physical media andtelecommunication networks for delivery of technical data indigital form, or digital access to technical information databases. It is applicable to all Department of Defense (DoD)components which acquire weapon systems and related majorequipment items, and their associated technical data.
10.2. Purpose. This appendix is intended to suggest the bestmethods for defining statement of work (SOW) requirements, andtailoring the wording of DoD Requests for Proposal (RFP's) andContract Data Requirement Lists (CDRL's) to allow and encouragethe integrated preparation and submission of, or access to,technical data in digital form.
20. REFERENCED DOCUMENTS
See list of references appearing in Appendix A.
30. DEFINITIONS
See the list of terms and acronyms appearing in Appendix A.
40. GENERAL GUID, . E
40.1. Access and delivery of digital data. A major thrust ofthe Computer-aided Acquisition and Logistic Support (CALS)program is access to, and delivery of, weapon system technicaldata in digital form. This appendix provides guidance forcontracting for the delivery alternatives discussed in Section 5and Appendix B of this handbook.
0 117
MIL-HDBK-59APPENDIX D
50. DETAILED GUIDANCE
50.1. Organization of guidance sections. This appendix isorganized into two major sections that address physical media andtelecommunications alternatives for data delivery or access.These sections can be used separately or together to contract fortechnical data in digital form.
50.1.1. Options. The Decision Template for Acquisition ofDigital Data reflects two options available for delivery ofdigital documents and processable data files, together with asingle option for interactive access to CITIS data bases. Thetechnology for both options has advantages for the user, andlimitations on the ability to benefit from those advantages.
50.1.1.1. Physical media. Older types of physical media (i.e.,magnetic tape) provide a mature, stable technology in which theuser can place great confidence. Unfortunately, this media formis also slow, bulky, and cumbersome. Newer types of physicalmedia (i.e., WORM optical disk and CD-ROM) hold great promisebecause of their much greater storage capability, but standarddata formats are only now beginning to emerge, andinteroperability remains a problem. Unlike magnetic tape, wheresystem hardware investment is largely a sunk cost, use of WORMoptical disk or CD-ROM may involve substantial investment costs.
50.1.1.2. Telecommunications. Secure, on-line transmission ofthe full volume of technical data for major weapon systems istechnically feasible, but beyond the economical capability ofcurrent telecommunication networks in DoD and industry. In thenear term, telecommunications will be limited to electronic mailexchange of high priority technical data, and interactive accesswhere traffic volume is limited to queries, selective review andapproval of data, or other clearly defined uses. In the longerterm, cost effective and secure telecommunications capabilitywill be essential for successful implementation of the IWSDB.Substantial amounts of government and industry research areunderway to provide this capability. CALS is helping to defineuser requirements in this area. Development and implementationof DoD telecommunications capability is the responsibility of theDefense Communications Agency, under the policy guidance of theAssistant Secretary of Deiense for Command, Control,Communications, and Intelligence. The National Institute ofStandards and Technology can provide additional information onexisting and planned commercial and government capabilities.
118 0
MIL-HDBK-59APPENDIX D
50.2. Physical media.
50.2.1. Physical media options. Physical media options includemagnetic tape, magnetic disk, and several forms of optical media.Magnetic tape is the preferred physical medium for delivery oftechnical data in digital form because it is a mature, stabletechnology that is able to handle the large volumes of datatypically involved in a major weapon system acquisition.Standards are well defined and usually well implemented, andlittle investment cost will be involved because almost all CITISsource systems and government destination systems providemagnetic tape read/write hardware. Magnetic disk is also widelyimplemented on personal computers and work stations, and may bethe physical medium of choice for small business contractors.Several primary de facto magnetic disk formats are available, butno official standard has been accepted. Compatibility problemsexist, but can be overcome with only moderate effort. Opticalmedia is used here as a generic term to include CD-ROM (compactdisk, read only memory), CDI and DVI (compact disk interactiveand digital video interactive), WORM (write once and read manytimes), and erasable optical disk.. 50.2.1.1. Magnetic tape. Magnetic tape includes three principaltape densities, only two of which are acceptable for delivery oftechnical data in digital form. The oldest is 800 characters perinch. Though still in use in many government and industryautomated data processing systems, CALS government and industryusers have decided that this is essentially obsolete technology,and is no longer an acceptable tape density for the large volumesof technical data that CALS data deliverables will typicallyencompass (see MIL-STD-1840). Instead, acceptable tape densitiesare 1600 and 6250 characters per inch, written on 9-track tapesin accordance with the Federal Information Processing Standardslisted in MIL-STD-1840, paragraph 5.2.1. MIL-STD-1840 alsoincludes specific instructions on single and multi-volume tapes,and data file organization. To acquire digital deliverables onmagnetic tape, Block 16 of the CDRL (DD Form 1423) should bemodified to incorporate the appropriate language from MIL-STD-1840.
50.2.1.2. Magnetic disk. The revolution that has changed 1970'smainframe computing to 1980's distributed, desktop computing hasmade magnetic disk a viable alternative for interchange ofdigital technical data. Although most large companies haveimplemented local area networks (LAN's) to interconnectindividual users, magnetic disk (floppy disk and removable harddisk) remains a major medium for moving digital data amongpersonal computers and work stations. For small business, where. LAN's are not yet as widely implemented, magnetic disk remains
119
MIL-NDBK-59APPENDIX D
the dominant exchange medium. Magnetic disk may have only alimited role to play in delivery of technical data in digitalform to the government, but it may have a major role in exchangeof digital data among prime contractors and subcontractors. Mostgovernment destination systems are not prepared to receivedigital data on magnetic disk, although jury rig solutions arenot difficult. Acquisition managers should examine closely therole that magnetic disk could play as a digital delivery mediumin specific program applications.
50.2.1.3. Optical media. For simplicity, the term optical mediais used in this handbook to encompass several categories ofphysical media that have distinctly different physical andtechnical characteristics. Usually these categories are notlumped together, and computer specialists will draw majordistinctions between each form. However, all these forms shareone important characteristic: they are not yet ready forwidespread use as a medium for digital delivery of technicaldata. Four categories are addressed in the following sections.
50.2.1.3.1. CD-ROM. DoD is conducting demonstrations andprototypes of CD-ROM technology for distribution of technicalpublications and other forms of technical data. CD-ROM disks areproduced in a mastering studio, the investment cost of whichremains significant. CD-ROM players are approaching the statusof "standard option" on personal computers. However, data on aCD-ROM disk cannot be changed. The disk itself cannot beupdated, only replaced.
50.2.1.3.2. CDI and DVI. This is a very new technology, whichcombines the capabilities of CD-ROM with video. It is stillexpensive because it has not yet left the research anddevelopment phase, and it has limitations on the amount ofinformation it can communicate. CDI and DVI are competingapproaches for providing a standard implementation of thistechnology. As the technology matures, and its cost declines,CDI will probably find its first application in digital trainingproducts.
50.2.1.3.3. WORM. This form of optical disk will be the firstto be routinely used for delivery of digital data. It is thebasis for DoD's automated engineering data repositories, and isbeing widely implemented by large contractors. (It is not aswidely implemented as CD-ROM among smaller contractors andindividual users.) Unlike CD-ROM, WORM optical disks can beupdated at the user's work station. However, updating consistsof writing a new file and file directory onto the disk. The olddata is not replaced, so eventually an optical disk becomes full.To offset this disadvantage, the inability to erase or replace
120
MIL-IDBK-59APPENDIX D
data means that every configuration change is permanentlydocumented. Current technology includes several WORM disk sizes.Twelve inch disks and the newer fourteen inch disks are primarilyused for data storage by central repositories, and will be themedium for data delivery in only a few cases where (literally)huge volumes of data are being delivered. Five-and-a-quarter (51/4) inch disks will be used by DoD to exchange data betweenprimary and secondary repositories, and will be a storage mediumfor digital technical data at desktop work stations. Evensmaller disk sizes are now appearing. These are the disk sizesthat will probably become the primary physical medium for datadelivery in the near future. However, the investment cost foroptical disk read/write hardware remains a barrier toimplementation. Also, standards for physical formatting andlogical formatting of optical disks are still being defined.
50.2.1.3.4. Erasable optical disk. This is another newtechnology, the routine application of which remains severalyears away. This category of optical disk can be both read andwritten at the individual work station, just as a magnetic diskis today. DoD and industry will implement this technology in thefuture, and most probably will eventually make it the principalOphysical medium for exchange of digital data. However, thetechnology itself is still emerging; standardization remainsseveral years away.
50.3. Telecommunications.
50.3.1. Telecommunication options. In the current environment,the user of telecommunications for either data delivery or accesshas three options. The government and the contractor must worktogether to select the option that best fits user requirementsand available capabilities.
50.3.1.1. Contractor-specific networks. The first option is useof an existing, oftentimes non-standard network alreadyestablished by the contractor. The government, in effect, ishanging terminals onto the contractor's system, and becominganother node of the CITIS. In this case, the acquisition managerhas the advantage of using an existing investment and a provendata architecture, and the disadvantage of being a captiveaudience. Nonetheless, this is a highly practical solution to animmediate requirement. Depending on the type of terminal andsoftware used, and the procedures established for system and dataprotection and integrity (see Appendix E), processable data filescan be downloaded onto physical media (e.g., a magnetic disk).The data are then available for additional processing andtransformation under the control of the acquisition manager.
121
MIL-NDBK-59APPENDIX D
50.3.1.2. TCP/IP-based DDN. The second option is providing thecontractor with an interface to the Defense Data Network (DDN).Because the DDN is a DoD network, sized to support defenserequirements within available funding, the acquisition managermust provide sponsorship for defense contractor nodes, and mustsatisfy Defense Communications Agency requirements to justify andschedule connection to the network. The DDN is currently basedon the Transmission Control Protocol and Internet Protocol(TCP/IP) standards which are widely supported in government andindustry with many commercial, off-the-shelf products. However,DoD has committed to accompany industry in the transition to OpenSystem Interconnection (OSI) compatible products, implementedthrough new standards such as the Government OSI Profile (GOSIP).
50.3.1.3. OSI compatibility. The third option fortelecommunications is OSI compatibility, the telecommunicationstechnology that industry as well as government is moving rapidlyto implement. Unfortunately, OSI products won't be in widespreadgovernment use for several years, and R&D is still needed toaddress major issues such as data protection and integrity.Nonetheless, standards have already been established, and DoD hasestablished a timetable for conversion from TCP/IP-based to OSI-based technology. As OSI-compatible DDN networks areestablished, the acquisition manager must meet DefenseCommunications Agency requirements to establish connectivity.However, implementation will be simplified because futureindustry telecommunications networks will also be OSI-compatible.
50.3.2. DDN compatibility. The DDN was developed in the 1960'sto satisfy DoD telecommunication requirements. DoD helpedpioneer this technology. Like most pioneers, DoD implementedsystems from which later computer and telecommunication expertslearned the improvements that would be needed to make widespread,standardized telecommunications technology more effective andmore efficient. DoD will transition to the new OSI-compatibletechnology, but the legacy investment in TCP/IP-based technologymeans that this will not happen overnight.
Each DoD component has developed specific implementing technicallanguage to accommodate its network-specific needs within acommon DDN architecture. The following sections summarize (andgeneralize) that component-specific language. This informationis not intended to substitute for component-specific technicalrequirements, but rather is intended to inform the acquisitionmanager of the general framework of capabilities that should berequired. These generic requirements are for the current TCP/IP-based DDN only, and do not include requirements for migration tothe OSI standards. They include DDN protocols up to andincluding the file transfer protocol, simple mail transfer
122
MIL-IDBX-59APPENDIX D
protocol, internet control message protocol, and TELNET. They donot address environmental considerations, performancerequirements, training manuals, maintenance/warranty provisions,special security, installation, or network control.
50.3.2.1. Interface with the DDN. The contractor should providethe appropriate number of DDN interfaces for each host, node, orLAN. Long-haul or packet-oriented LAN communications capabilitywill be provided by the DDN. The contractor should supply allrequired hardware, software, and accessory equipment necessary toachieve DDN operability for the proposed system. Each DDNinterface node or host within the proposed configuration will beconnected by the contractor to a DDN access circuit, which willbe extended by the government to the site wherein the proposedsystem is installed. The contractor should provide the necessarycabling between the DDN access circuit terminus and thedesignated interface node or host.
50.3.2.1.1. Data protection and integrity. All hosts interfacedto DDN should be capable of being certified at an appropriatesecurity level by an agreed upon date. Hardware, software, andprocedures should be adequate to prevent misuse or abuse of both.the system (computers and telecommunications) and data residentin the system (Appendix E).
50.3.2.1.2. Topology. If LAN topology is proposed, a gateway toDDN should serve as the interface device. Neither a LAN nor agateway is required; only the DDN interface itself is a require-ment. Another topology may be proposed. If a LAN is proposedthat is packet-oriented, each designated DDN host on a particularLAN should have MIL-STD-1777/1778 installed for intra-LANinformation transfer, along with internet control messageprotocol, MIL-STD-1780/1781/1782. If an Ethernet LAN isproposed, Request For Change 826 should provide addressresolution between IP and LAN media access control. The EthernetLAN will be IEEE 802.3 compliant.
50.3.2.1.3. Gateways. If a DDN LAN gateway is proposed, thecontractor should provide the hardware and software necessary toserve as a DDN gateway between the proposed system and the DDN,and should interface the gateway to both the proposed system andthe DDN packet switching node. The gateway should be implementedin contractor-provided equipment independent of the proposedsystem. The contractor should supply all appropriate gatewayprotocols to allow full communication between hosts and terminalson the proposed system and those on the DDN. The proposed systeminterfaces should provide transparent internetwork addressing andcomplete functional interconnectivity to the user. The gateway.should be connected to the LAN, should support a minimum of 256
123
MIL-RDBK-59APPENDIX D
logical connections simultaneously, and should implement thechannel access protocol for interfacing the gateway with the LAN.Hardware and software used to connect the gateway to the LANshould be provided. The connection to the LAN should support theminimum data transfer rate specified for the full-duplex gatewayto DDN packet switching node interface.
50.3.2.1.4. Interfaces. The data link and network interfaceshould comply with the DDN X.25 host interface specification.The physical interface should also comply with EIA RS-449, andshould be capable of transmitting and receiving binary data atall of the following discrete data transmission rates: 4800,9600, 19200, 50000, and 56000 bits per second. The electricalinterface should comply with EIA RS-422-A and MIL-STD-188-114.The DDN exterior gateway protocol and all internet protocol (MIL-STD-1777 and supporting Defense Communications Agencyinterpretations) should be implemented in the gateway. The IPsoftware should be able to automatically operate with receivingIP's that have not implemented identical IP options. Internetcontrol messages should conform to the requirements of theinternet control message protocol, and should be capable ofreceiving all message protocol message types.
50.3.2.2. DDN protocols. The contractor should provide thenecessary protocol support to achieve the specified level ofservice interface with DDN. The network, TCP, and IP (asappropriate) protocols must be accessible by the user from higherlayer services and user-developed code via service accessprotocols within each respective protocol in order to permitlocalized adaptations to the interface. Specific softwareprocedures required to use the services of applicable protocolsshould be documented and made available to the government.
50.3.2.2.1. Transport service. For transport service, all TCPoptions specified in MIL-STD-1778 should be implemented, and allTCP systems parameters should be settable. The TCP softwareshould be able to automatically operate with a receiving TCP thathas not implemented identical TCP options.
50.3.2.2.2. Application level protocols. Terminal-to-hostservice should conform to MIL-STD-1782, including all DoD-approved TELNET options. All functions available to locallyconnected users should also be available to remote users at alllocations following successful implementation of both system andapplication sign-on procedures. Some application functions maynot have specific sign-on procedures. File transfer serviceshould conform to MIL-STD-1780. At a minimum, ASCII and imagedata representations should be accepted. Electronic mail serviceshould conform to MIL-STD-1781. In addition, an end-user mail
124
MIL-HDBK-59APPENDIX D
handler that utilizes the facilities of simple mail transferprotocol and the local file system should be provided, and shouldestablish and maintain user mailboxes as required, and supportappropriate mail host administrator functions. The end-user mailhandler should automatically send or receive mail via MIL-STD-1781 ports, with logical-to-network address translation.
50.3.2.3. Host-to-host front-end protocol interface (network anddata link and physical layers). The physical interface shouldconform to EIA RS-449 and MIL-STD-118-114. The interface shouldbe capable of transmitting and receiving binary data at one ormore of the following discrete data transmission rates: 4800,9600, 19200, 50000, 56000, and 64000 bits per second. Data link,network interfaces, and service access for host-to-host front-endprotocol communication should conform to the DDN host front-endprotocol and service access protocols. The host front-endprotocol link should conform to FED-STD-1041 (FIPS PUB 100-1).Two way simultaneous operation should be supported.
50.3.2.4. Subscriber interface. These requirements apply onlyto systems requiring Defense Communications Agency-approvedinterfaces. Government users who need unique, custom-designedDDN connections should define the specific characteristics ofthat interface following the DDN layered hierarchy description.
Examples of Standard DDN Protocols
Physical RS-449, RS-232-CData Link High-level data link controlNetwork DDN X.25 (Standard)Transport TCP/IPSession LocalPresentation (and) TELNETApplication File Transfer Protocol, Simple
Mail Transfer Protocol, NativeMode, Special User Applicationsas Required
50.3.2.5. System-specific modification. The protocols listedabove are examples of a DDN standard configuration. Wherespecial needs exist, they should complement, not replace, thebasic DDN protocol structure. The system definition may requiremodification based on the unique needs of each acquisition, butthe overall layered protocols used by DDN will be intact.Special, non-approved vendor protocols cannot substitute forlisted DDN protocols. They must exist, if needed, outside theDDN domain.
is 125
MIL-HDBK-59APPENDIX D
50.3.3. OBI compatibility. The preferred future standard fortelecommunications media access and delivery are protocols thatprovide Open System Interconnection (OSI) compatibility. OSIprotocols have been developed by international standardsorganizations, primarily the International Organization forStandardization (ISO) and the Consultative Committee onInternational Telephone and Telegraph (CCITT). To provide OSIcompatible networking capability for government users, agovernment OSI profile (GOSIP) has been published as a federalinformation processing standard. GOSIP defines the initial suiteof protocols through which DoD and other government agencies willtransition from current heterogeneous telecommunication systemsto an OSI architecture.
50.3.3.1. Origin of GOSIP. GOSIP defines a common set of OSIdata communication protocols which enable systems de\eloped bydifferent vendors to interoperate and enable the users ofdifferent applications on these systems to exchange informationwithout use of physical media. GOSIP is based on agreementsreached by vendors and users of computer networks participatingin the National Institute of Standards and Technology's Workshopfor Implementors of Open System Interconnection. To providecompleteness, GOSIP is augmented with material from internationalstandards and documents progressing toward international standardstatus.
50.3.3.2. General application. The GOSIP (FIPS 146) iseffective as of February 25, 1989. For a period of eighteenmonths thereafter, until application of GOSIP becomes compulsoryand binding, agencies are permitted to acquire alternativeprotocols that provide equivalent functionality. However,agencies are encouraged to use the standard for solicitation andcontracts for new network products and services to be acquiredafter the effective date. For the indefinite future, agencieswill be permitted to buy network products in addition to thosespecified by GOSIP and its successor documents. This includesother non-proprietary protocols, proprietary protocols, and OSIfeatures and options not yet included in GOSIP.
50.3.3.3. DoD application. Waivers to FIPS may be granted undercertain exceptional circumstances. However, DoD policy on theuse of GOSIP was established even before the GOSIP FIPS waspublished. GOSIP was adopted in 1987 as an experimental co-standard to the TCP/IP protocols that provide similar serviceswithin the current structure of the Defense Data Network. GOSIPcould be specified in addition to, in lieu of, or as an optionalalternative to the DDN protocol standards. Now that the 1OSIPFIPS has been formally published, it is a full DoD co-standard,and after the established transition period will become the sole
126
MIL-HDBK- 59APPENDIX D
mandatory interoperable protocol suite. However, a capabilityfor interoperation with the DDN protocols has been provided toensure that existing systems can continue to function fully andeffectively.
50.3.3.4. Industry compatibility. GOSIP is consistent with, andcomplementary to, industry's manufacturing automation protocol(MAP) and technical and office protocol (TOP). MAP/TOP addressesa broader range of functionality, and defines more advancedtechnology as a way to establish guidelines for future commercialproduct development.
50.3.3.5. GOSIP implementation and extension. GOSIP addressesthe need of the federal government to move immediately to multi-vendor interconnectivity without sacrificing essentialfunctionality already implemented in critical networking systems.All capabilities specified in GOSIP exist as standard products orare close enough to market that they can be proposed by vendors.OSI protocols providing additional functionality will be added toGOSIP as implementation specifications for those protocols aredeveloped by the OSI Implementors Workshop. For each incrementalextension to GOSIP, an eighteen month transition period will be. applicable. Appendices to the GOSIP specification describeadvanced requirements for which adequate profiles have not yetbeen developed.
50.3.3.6. GOSIP functionality. Currently, GOSIP addresses filetransfer, access, and management (access and movement of infor-mation files among network users), and message handling systems(electronic mail or messaging between netwcrk users). GOSIPprovides enough functionality to be generally useful for allgovernment computer networking needs. If additionalfunctionality is required to meet CALS technical data interchangeand access needs, it can also be specified by the acquisitionmanager.
50.3.3.7. Contracting for OSI delivery. To require OSI/GOSIPcompatibility as a delivery or access mode, FIPS PUB 146 shouldbe cited. The GOSIP architecture supports a range of protocolchoices at different protocol layers. A subset of theseprotocols may adequately satisfy an individual programrequirement. If a subset of the GOSIP protocols and serviceinterface profiles are chosen, it is the acquisition manager'sresponsibility to ensure that all paths through the architectureare complete.
127
MIL-RDBR-59APPENDIX D
THIS PAGE INTENTIONALLY LEFT BLANK.
128
MIL-HDBK-59APPENDIX E
APPENDIX E
DATA PROTECTION AND INTEGRITY,DATA RIGHTS, AND RELATED ISSUES
0 129
XIL-HDSK-5gAPPENDIX R
THIS PAGE INTENTIONALLY LEFT BLANK.
1300
MIL-HDBK-59APPENDIX E
10. SCOPE
10.1. Applicability. This appendix provides guidance on dataprotection and integrity, data rights, change control, andrelated issues to government activities acquiring technical datain digital form or establishing CITIS functional integrationrequirements. It is applicable to all Department of Defense(DoD) components responsible for acquisition of weapon systems orrelated major equipment items.
10.2. Purpose. This appendix identifies issues that should beaddressed by the acquisition manager, and suggests the bestmethods for tailoring the wording of standard DoD Requests forProposal (RFP's) and Contract Data Requirement Lists (CDRL's) toallow and encourage the integrated preparation, government accessto, and digital submission of deliverable data.
20. REFERENCED DOCUMENTS
See list of references appearing in Appendix A.
30. DEFINITIONS
See list of terms appearing in Appendix A.
40. GENERAL GUIDANCE
40.1. Contracting for digital data. A major thrust of theComputer-aided Acquisition and Logistic Support (CALS) program isthe delivery of weapon system data in digital form. A secondthrust is integration of the data bases which produce that dataand make it available for use. Implementation of theseobjectives must be accomplished in a manner that protects fromunauthorized access, use, or change: (1) information that isclassified as having national security implications, (2)information that is contractor proprietary or competitionsensitive, (3) information that is subject to export control astechnologically sensitive, and (4) the systems that create,store, and distribute that information. Additional issues to beconsidered in contracts include data rights, privacy, and legalliability.
131
MIL-IDBK-59APPENDIX E
50. DETAILED GUIDANCE
50.1. Data protection and integrity. The goal of CALS dataprotection and integrity policy is to ensure the integrity andconfidentiality of all CALS assets to the extent possible withinexisting regulations, procedures, etc. Inherent in theattainment of this goal is the requirement for adequate risk anddata protection planning and implementation throughout the lifecycle of weapon system technical data. The purpose of thissection of the handbook is to aid acquisition managers inaccomplishing system and data protection and integrity planningto ensure proper development, implementation, and administrationfor CALS programs and activities. This section of the handbooksupports implementation of DoDD 5200.28, Security Requirementsfor Automated Information Systems. It is not intended as asubstitute for the extensive specialized functional and technicalguidance available on this subject.
50.1.1. Background discussion. The emergence of digital mediahas resulted in a new series of methods and techniques forunauthorized use and dissemination of information. Theacquisition manager, other government users of technical data,and the contractor have a shared responsibility to provide anadequate level of protection in all CALS-related delivery andaccess modes. The level of protection must be commensurate withthe level of information sensitivity. Providers and users oftechnical data should recognize that evolving technology andstandards for system and data protection are being matched byevolving technology for protection infringement. The acquisitionmanager should address system and data protection and integrityrequirements early and continuously throughout the life cycle ofthe weapon system. The program office security officer should bethoroughly familiar with CALS concepts for delivery of data indigital form, and for interactive access by government users tocontractor data bases and by contractor users to government databases. Using this knowledge, the program office security officershould play an active role in selection of the appropriatedelivery or access modes. The contractor should be advised asearly as possible of the security-related requirements fortechnical data to be delivered or accessed in accordance withCALS standards and statement of work provisions. The contractorshould be required to thoroughly describe the procedures to beimplemented at each level of sensitivity to protect technicaldata, and the systems and networks hosting that data, fromunauthorized use or abuse.
50.1.2. Systems approach to data protection and integrity. Dataprotection and integrity requirements for CALS are divided into
132
MIL-HDBK-59APPENDIX E
six interrelated security disciplines: communications security,computer security, operations security, physical security,personnel security, and information security. These disciplinesmust be integrated into an overall systems approach.
50.1.3. Government data protection and integrity issues.Technical data generated in support of a weapon systemacquisition program will include data that is unclassified, ForOfficial Use Only (FOUO), subject to export control, corporateproprietary/source selection sensitive, or classified from anational security standpoint, (e.g., confidential, secret, topsecret, etc.). Although the bulk of this data will usually beunclassified, the inferences which can be drawn from theaccumulation of unclassified data (data aggregation) may dictatea higher level of classification for the data elements or theaggregate data. The delivery mode(s) selected for transmissionof technical data to the government must provide a level ofprotection commensurate with the data's level of sensitivity.Multiple delivery modes may be specified in some cases. Forexample, a small classified appendix to an unclassified technicalmanual may be delivered in hard copy while the main body of thetechnical manual is delivered as a set of processable data files.O For interactive access to weapon system data, provisions foraccess control and telecommunications security must be addressedin accordance with DoD and National Security Agency regulationsand instructions. The procurement must clearly state what degreeand levels of access will be required.
50.1.4. Industry data protection and integrity issues. Inaddition to providing protection for technical data commensuratewith government-designated levels of sensitivity, industry mustdeal with company proprietary, competition-sensitive, orliability sensitivities of data. This is the responsibility ofthe contractor's facility even if government personnel haveinteractive access capability.
50.1.5. Telecommunications. The interrelationship andinterdependency between telecommunications and computer systemsare defined by Public Law 100-235, the Computer Security Act of1987. Government agencies and systems security steering groups,including the National Security Agency and the National Instituteof Standards and Technology, have been given the responsibilityto establish policies, standards, products, andtechnical/research centers. Encryption of classified orsensitive military data should be in accordance with proceduresestablished by the National Security Agency. Encryption of othersensitive data should be by commercial practice commensurate withlevel of sensitivity.
0 133
XIL-RDBK-59APPENDIX Z
50.1.6. Computer security levels. Information processingproducts are evaluated to determine the level of their capabilityto protect information from unauthorized access. This evaluationis performed in accordance with the requirements set forth in DoD5200.28-STD, The DoD Trusted Computer Systems EvaluationCriteria. One of the levels of information security is broadlycategorized as system high. An information system that isoperating at system high requireas that all users with physicalaccess to that system have a current security clearanceequivalent to, or greater than, the highest classification levelof any data resident on that system. A second level ofinformation security is categorized as multilevel security.Multilevel security offers more advantages than system high tousers who must deal with technical data whose elements are atdifferent levels of classification or sensitivity. However,implementing an approved multilevel security system may posemajor problems. An information system that incorporatesmultilevel security allows system access to users who havesecurity clearances that are at a lower level than some of thedata resident on the system. A multilevel security system musttherefore protect information from unauthorized disclosure toindividuals who have a lower security clearance, but who areauthorized to access the system. All options and alternatives tomultilevel security, including multiple physically isolated databases, must be considered.
50.1.7. Data protection and integrity requirements. Technicaldata generated, processed, and disseminated in a computer aidedand telecommunications environment must be protected inaccordance with applicable statutes, regulations, and guidelines.Some data will be classified, and its protection is defined bylaw, executive order, and directive. Most data will beunclassified, but its protection is still necessary for thesuppliers and users of the data. System and data administratorsmust also plan for disaster recovery; although this issue isunrelated to system/data compromise, the problems associated withrestoration of data of known integrity are comparable.Survivability of both technical data and the weapon systemssupported by that data will require the application of dataprotection and integrity measures for information, hardware,software and operating systems, and weapon system components.Life cycle data protection and integrity modeling will be usedas:
a. A framework for analyzing all aspects of CALS dataprotection and integrity.
b. A basis for establishing data protection policies,plans, and procedures.
134
MIL-BDBK-59APPENDIX E
50.1.7.1. Industry. Appropriate data protection measures andstandards are required when proprietary or technologicallysensitive acquisition and logistics data are created, changed,transmitted, received, and stored in digital form. Effectiveindustry application depends in part on the degree of controlneeded to meet data protection requirements, and the quality ofthe implementation and enforcement of those controls. To obtainearly visibility and management of data protection and integrityissues, a risk assessment and security plan should be developedin response to anticipated weapon system program requirements aspart of the offeror's proposal in response to an acquisition RFP.This plan should address levels of data protection for eachaccess mode, and procedures for protection of classified data,with particular attention to interactive data base access andtelecommunications.
50.1.7.2. Government. Since CALS technologies allowdissemination and use of industry-developed data beyond thecontrol of the owner of the data, government access and controlof this contractor information must be managed through the use ofDoD-wide uniform standards. Data protection and integrityrequirements will increase significantly as CALS encompasses more. classified and sensitive information, and employs more automatedsystems to originate, communicate, and receive data. It is theresponsibility of the program office to conduct a security riskanalysis to identify anticipated data protection requirements asdescribed in table 6.
50.1.7.3. Risk approval procedures. Risk approval proceduresshould be established to ensure the acquisition manager isprovided with information on risk, trade off, and cost/benefitanalyses that is adequate to make an informed decision concerningoptimal data protection and integrity procedures. Risk approvalprocedures are based on the recognition that achieving perfectdata protection and integrity (i.e., the absence of allvulnerabilities) is not usually feasible. The goal of the riskapproval process is to provide the weapon system program with thebest security practicable, at acceptable cost, consistent withother critical program parameters.
50.1.8. Considerations for implementation of data protection andintegrity. System security engineering principles, as outlinedin MIL-STD-1785, will be utilized to integrate data protectionand integrity disciplines in an effective and efficient manner toachieve assured service, integrity, and confidentiality. Dataprotection and integrity programs will be developed on the basisof formal risk versus vulnerability assessment procedures.
135
MIL-HDBK-59APPENDIX E
TABLE VI. Identification of security by data item.
SECURITY CLASSIFICATIONS
* DoD REQUIREMENTS LEVELS OF SECURITY CONTROL
TOP SECRET System level currently forSECRET classified informationCONFIDENTIAL Transaction level currently forFOR OFFICIAL USE ONLY (FOUO) sensitive unclassified dataMOSAIC Data element level in futureEXPORT CONTROL CALS systems
* INDUSTRY REQUIREMENTS USER PROFILES
COMPETITION SENSITIVE Access & Control (for example)COPYRIGHTED by domestic companyTECHNOLOGICALLY SENSITIVE by foreign companyCOST SENSITIVE by departmentMOSAIC (applies to industry by projectas well as DoD data) by group
Procedures and software rules for access control userprofiles, which becomes a matrix matching the data securitylevel with the user profiles.
50.1.8.1. Industry. In the transition from hard copy to CALSdata interfacing and data integration technologies, therequirements for the protection of proprietary information willincrease in sophistication and cost in proportion to theincreased level of access control required. Access controlissues exist at contractor/government sending and receivingsites, and in the telecommunication links connecting them. Dataprotection and integrity standards should be established andenforced early in the program in accordance with a CALS technicaldata security plan approved by the government program office.Access controls should be established in accordance with thisplan.
50.1.8.2. Government. Information and communication-computerdata protection and integrity management for CALS technical datamust be addressed in accordance with DoD 5200.1-R, InformationSecurity Program Regulation, and DoDD 5200.28, SecurityRequirements for Automated Data Processing Systems. The processfor establishing data protection and integrity requirements is asfollows:
136 0
MIL-HDBK-59APPENDIX E
a. Establish data protection and integrity requirementsusing CSC-STD-004-85, Guidance for Applying theDepartment of Defense Trusted. Computer SystemEvaluation Criteria in Specific Environments. For agiven maximum data sensitivity and minimum clearance orauthorization of a system user, a computer securitycategory, ranging from Cl to Al, is required.
b. Use DoD-5200.28-STD, the DoD Trusted Computer SystemEvaluation Criteria as a source for information pro-cessing product evaluation. The Evaluated Products forTrusted Computer Systems (called the Evaluated ProductsList) is contained in the Products and Services listthat is prepared and published quarterly by theNational Computer Security Center.
c. After definition of information and communication-computer data protection and integrity requirements byDoD weapon system and data system acquisition managersand by security managers, requirements should be passedto contractors using DD Form 254, DoD Contract SecurityClassification Specifications.
O 50.1.9. Implementation guidance. The acquisition manager shoulddevelop a progran plan that incorporates a multi-disciplinarysystems approach to meeting the data protection and integrityrequirements of the program. This plan will identify responsiblepersonnel and resources, and require government or contractorperformance of:
a. Data protection and integrity threat and vulnerabilityanalyses.
b. Data protection and integrity risk assessments andtrade-off analyses.
c. Data protection and integrity test and evaluation.
d. Configuration control for security systems and trustedsystem components.
e. Identification of vulnerabilities that remain afterimplementing all reasonable security measures.
f. Periodic inspections to ensure compliance.
50.1.9.1. Program Office Security Officer. Information andcommunication-computer data protection and integrity requirementsmust be addressed early and continuously throughout the life of
137
MIL-RDBK-59APPENDIX B
the weapon system. Oftentimes, the most easily compromisedinformation is that which is considered too fluid, toopreliminary, and too incomplete to warrant serious dataprotection. The program office security officer shouldcompletely familiarize himself with CALS digital informationdelivery objectives and related data protection and integrityissues, as described in this appendix and in other DoDinstructions relating to protection of classified and otherwisesensitive data. The program office security officer should fullyparticipate in all decisions concerning access or delivery modesand media for technical data in digital form. These decisionsshould be made in a manner which is consistent with the CALSobjective for the program, and which provide an appropriate levelof protection at reasonable cost. In conjunction with otherprogram office personnel involved in setting requirements fordelivery of technical data, the program office security officershould determine the anticipated data protection and integrityrequirements for the program, including volume of dataanticipated to be delivered or accessed at each level. Thesecurity plans proposed by the various offerors, and the securityplans and facilities available at government activities whichwill receive and process technical information, should bereviewed and taken into account in recommending the appropriatemethod of delivery or access.
50.1.9.2. Contract implementation. Determination of dataprotection and integrity requirements for technical informationto be delivered or accessed, such as anticipated classificationlevels for technical manuals, engineering drawings, and othertechnical data, should be accomplished early in the program.Early dissemination of this information to potential contractorsshould be accomplished prior to award of contract, either as partof the bidder's briefing or in the RFP. This description shouldgo beyond the scope of the DD Form 254, and should provide thecontractor with a sufficient level of detail to develop acontractor data protection and integrity plan. The RFP shouldrequest a description of the offeror's proposed method forimplementing data protection and integrity procedures for theprotection of both classified information and information thatthe offeror anticipates being proprietary or sensitive from anexport :i-%ndpoint. The plan should be used by the government toplan and acquire the resources needed to receive, store, andprocess sensitive technical data at government facilitiesinvolved in the life cycle support of the weapon system.
50.1.9.3. Suggested instructions to offeror language. Thefollowing language is suggested for inclusion in instructions toofferors:
138 0
MIL-HDBK-59APPENDIX E
The offeror shall develop a preliminary plan which addressesintended data protection and integrity provisions for tech-nical data to be developed and maintained by the contractor,and delivered to the government or accessed by governmentpersonnel. This plan shall be derived from the anticipated
4program data protection and integrity requirements providedby the government. It shall address levels and methods ofdata protection for all levels of technical data from theviewpoints of economy, impact on other program contractactivities and schedule, and government plans forinteractive access. It shall describe requirements (such asnumber and type of data encoding devices) to accomplish thedata protection and integrity provisions contained therein.It shall be complete enough that the government can assessofferor's potential for compliance with data protection andintegrity requirements while meeting the CALS objectives.
50.1.9.4. Suggested statement of work (SOW) language. Thefollowing language is suggested for incorporation in SOW's forclassified data:
The contractor shall minimize the volume of informationrequiring specialized handling for purposes of dataprotection and integrity, and shall provide information atthe lowest classification level practicable. For example,unclassified technical manuals are preferred over classifiedmanuals, provided they contain adequate information toperform the function described therein. Largelyunclassified technical manuals with a classified appendix orsupplement are preferred over largely classified technicalmanuals. In organizing technical information in thismanner, the contractor shall pay particular attention toitems of information which by themselves are unclassified,but when taken together, allow classified information to beinferred. The government shall retain the right to conductannounced and unannounced inspections by securityspecialists at any time to review, audit, and account forclassified materials.
50.2. Data rights, privacy, and legal liability. (CALS relatedwork in the area of data rights, privacy, and legal liability isbeing performed by the CALS Acquisition Task Group. Supplementalguidance will appear in the FY '89 update to this handbook.)
50.2.1. Application of CALS standards. Application of CALSstandards must be analyzed to ensure that adequate managementprocedures are implemented to control access to data that mayrequire controlled distribution for reasons other than the data's
0 139
MIL-HDBK-59APPENDIX E
security classification. Access and distribution may becontrolled because of any of the following:
a. Sensitive technology as indicated by documents orcomputer files marked or annotated in accordance withDoD 5230.24, Distribution Statements on TechnicalDocuments, and controlled in accordance with DoD5230.25, Withbclding of Unclassified Technical Datafrom Public Disclosure. Refer to the relevant Service,Agency, or Command office, or, in accordance withService or Command procedures, to the office of theDeputy Undersecretary of Defense for Research andTechnology.
b. Rights in technical data. Refer to Defense FAR Supple-ment Part 27.4 and the basic data rights clause at52.217-7013.
50.2.2. Liability and warranty. Liability and warranty issuesmust also be addressed. Liability is often confused withownership, but is a more precise concept. It is possible to owna computer program, such as a word processing application,without having the right to copy it, nor responsibility, norliability for its proper use. Adequate control of changes anddetermination of change authority is also a critical legal issue.These issues are conceptually the same in a CALS environment asin the current paper-based environment. However, the applicationof CALS technologies provides both an opportunity to betteraddress these issues, and the potential for additional abuse. Itis the responsibility of the acquisition manager, in coordinationwith supporting DoD legal counsel, to establish, implement, andenforce procedures and safeguards to preclude the opportunity forsuch abuse. The contractor shares a responsibility to develop,implement, and enforce corresponding procedures and safeguards.
50.2.3. Information change management and configuration control.The selection of digital standards also requires review of manualand automated procedures for controlling and tracking datachanges. Generally, the more functional utility provided by adata interchange or access standard, the more sophisticated andextensive must be the procedures for configuration management ofthe technical data. The ability to manage, control, and identifychanges and change authority is absolutely necessary to properassignment of liability and responsibility.
140
MIL-HDBK-59APPENDIX E
Custodians: Preparing ActivityArmy - CR OSD-CLNavy - SH (PROJECT ILSS-0035)Air Force - 24DLA - DH
Review activities:Army - AMAir Force - 01, 02NSA - NSDCA - DCNSA - NAOther - NBS, DOE, GPO, NCS
User activities:OSD - IRArmy - AL,AT,AV,CR,EA,ER,GL,ME,MI,MR,SM,TE,TMNavy - AS,EC,OS,SA,YDAir Force - 11,13,14,17,18,19,68,79,99
0
0 141
MIL-NDBK-59APPENDIX R
THIS PAGE INTENTIONALLY LEFT BLANK.
142
I
I STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL(See Instructions - Reverse Side)
1. DOCUMENT NUMBER 2. DOCUMENT TITLE
MIL-HDBK-59 POD COMPUTER-AIDEP ACQUISITION AND LOGISTIC SUPPORT(CALS) PROGRAI
I 3. NAME OF SUBMITTING ORGANIZATION 4. TYPE OF ORGANIZATION (Mark one)
IE VENDOR
I _--__USER
b. ADDRESS (Street, City, State, ZIP Code) MANUFACTURER
I ! OTHER (Specify):
5. PROBLEM AREAS
.Paragraph Number and Wording:
- I b. Recommended Wording:
I. c. Reason/Rationale for Recommendation:
"I
7a. NAME OF SUBMITTER (Last, First. MI) -Optional b. WORK TELEPHONE NUMBER (Include AreaCode) - Optional
c. MAILING ADDRESS (Street. City. State, ZIP Code) -Optional 8 DATE OF SUBMISSION (YVMMDD)
I Do 82OMR 42 PREVIOUS EDITION IS OBSOLETE.
I 6 2 MAR Y&
INSTRUCTIONS: In a continuing effort to make our standardization documents better, the DoD provides this form for use in
submitting comments and suggestions for improvements. All users of military standardization documents are invited to provide
suggestions. This form may be detached, folded along the lines indicated, taped along the loose edge (DO NOT STAPLE), and
mailed. In block 5, be as specific as possible about particular problem areas such as wording which required interpretation, was Wtoo rigid, restrictive, loose, ambiguous, or was incompatible, and give proposed wording changes which would alleviate the
problems. Enter in block 6 any remarks not related to a specific paragraph of the document. If block 7 is filled out, an
acknowledgement will be mailed to you within 30 days to let you know that your comments were received and are beingconsidered.
NOTE: This form may not be used to request copies of documents, nor to request waivers, deviations, or clarification of
specification requirements on current contracts. Comments submitted on this form do not constitute or imply authorization
to waive any portion of the referenced document(s) or to amend contractual requirements.
(Fold along thia line)
(Fold along this line)
Director, GALS policy Office I IIOASD (P&L) WSIG NO POSTAGE
EU I NECESSARYThe Pentagon, Rm. 2B322 IECE iii IF MAILED
Washington, DC 20301-8000 INTEUNIED STATES
PENALTY FOR PRIVATE USE $300 B S E REPLY MAILFIRST CLASS PERMIT NO. 4966 Alexandria, VA %r
POSTAGE WILL BE PAID BY
Defense Systems Improvement
and Analysis Officec/o Defense Logistics Agency
Cameron StationAlexandria, VA 22034-6183
