MIL-HDBK-59A APPENDIX C APPENDIX C FUNCTIONAL REQUIREMENTS FOR INTEGRATION OF CONTRACTOR PROCESSES 131 MIL-HDBK-59A APPENDIX C THIS PAGE INTENTIONALLY LEFT BLANK. 132 MIL-HDBK-59A APPENDIX C 10 SCOPE 10.1 Applicability. This appendix provides guidance to government activities on establishing contract requirements for functionally integrated contractor design and systems engineering processes on weapon system and major equipment development efforts. It is applicable to all Department of Defense (DoD) components which acquire weapon systems through the normal contracting process. 10.2 Purpose. This appendix is intended to suggest the best methods for tailoring the wording of standard DoD Requests for Proposal (RFPs) and Contract Deliverable Requirement Lists | (CDRLs) to allow and encourage the integration of design, | engineering, manufacturing, and support efforts through the | digital exchange of data. | 20 REFERENCED DOCUMENTS See list of references appearing in Appendix A. 30 DEFINITIONS See list of terms and acronyms appearing in Appendix A. 133 MIL-HDBK-59A APPENDIX C 40 GENERAL GUIDANCE 40.1 Contracting for integration of functional processes. A major objective of CALS is the application of computer-aided methods and supporting technologies to incorporate logistic support functions as an integral element in the weapon system contractor's design process. To achieve this, the acquisition manager should apply the detailed requirements contained in section 50, tailored to fit the acquisition strategy selected for the program. These requirements specify the integration of design, manufacture, and support processes, as well as other elements of concurrent engineering, for the performance of DoD contracts. At a minimum, the general goals and objectives applicable to each identified functional area should be stated in industry informational briefings, commerce business daily listings, source solicitations, or instructions to RFP offerors. The full benefit to the program is realized only when the functional requirements are included in the RFP and the proposal evaluation/source selection process, and made contractually binding as described in section 50. 40.2 Strategic approach. As CALS evolves, weapon system technical data will be logically integrated into tightly coupled, controlled, and secure contractor and government systems and data | bases, allowing access and authorized sharing of data at the data | base level through CITIS. Functional integration of contractor | processes to ensure the security, currency, and accuracy of | information will be articulated and contractually specified as | program requirements. Access to these processes and data will be | through the CITIS. CALS initiatives to improve technical data | creation, management, and use provide an enabling environment that will accelerate the application of concurrent engineering, a systematic approach to creating a product design that considers all elements of the product life cycle from conception through disposal. In so doing, concurrent engineering simultaneously defines the product, its manufacturing processes, and all other required life cycle processes, such as logistic support. CALS functional requirements for concurrent engineering will provide the necessary focus for a comprehensive concurrent engineering strategy that addresses multiple approaches and the necessary enabling environment. Specific CALS thrusts, such as integration of R&M with CAD and CAE will directly contribute to application of concurrent engineering concepts. 40.3 Application environment. The earlier in the acquisition cycle that this strategy is introduced, the greater the potential productivity and quality improvements. As decisions affecting a product's design are made, both acquisition and operational support costs become defined. The earlier in a system's design 134 MIL-HDBK-59A APPENDIX C definition that the user's requirements can be addressed by the product design and associated manufacturing processes, the greater the opportunity to produce a more robust, supportable design at lower life cycle cost and greater operational effectiveness. This requires a change to the way most companies function. For example, new product designs historically have been the property of the company's engineering department. When design and engineering analyses are completed, the design passes to manufacturing, where necessary engineering changes are identified, beginning a costly iterative process resulting in the as-designed vs. as-manufactured configurations of the product. A CALS and concurrent engineering strategy must begin at Milestone 0 to produce the greatest returns in terms of development time, acquisition cost, life cycle support cost, and product reliability and maintainability. 40.4 R&M integration with CAD/CAE. The detailed requirements contained in section 50 are applicable to all engineering activities that define, establish, or influence reliability and maintainability (R&M) properties during all phases of item development, including concept exploration, demonstration and validation, full scale development, and production. The intent of section 50 is to influence the contractor to conduct engineering activities which have a bearing on the R&M properties of the ultimate fielded product, using computer-aided design (CAD) and computer-aided engineering (CAE) procedures that interact and actively share data with all other design engineering processes and procedures. Traceability of key design decisions having a major bearing on the R&M properties of the item to the engineering procedures, design criteria, and data bases that influenced the decisions is also a major goal. 40.5 Integration of contractor LSA processes with R&M and design | engineering. One approach to achieve integration of LSA, R&M and | design engineering activities is through the concurrent | engineering process. The purpose of LSA/R&M involvement in the | concurrent engineering environment is to (1) achieve high | quality, reasonable price and on-schedule delivery of a robust, | supportable weapon system, (2) allow engineering, manufacturing | and support processes to be performed in parallel to the extent | practicable, and (3) employ the voice of the user to help | determine important product attributes. A concurrent engineering | environment can be an efficient, systematic approach that | implements the design of high quality products with the processes | to produce and support them. The integration of the LSA/R&M | processes into the concurrent engineering environment assists in | a robust design development of the product and all required life | cycle processes such as the support system. This process | requires the designers, from the outset, to consider all elements | 135 MIL-HDBK-59A APPENDIX C of the product life cycle from conception through disposal to | include cost, schedule, and user requirements. This can be | accomplished by the principle designer using appropriate | algorithms and the criteria provided by R&M and LSA engineers. | 40.6 Configuration management of technical data. Section 50 | provides guidance to both industry and government to establish, | manage, and provide configuration control of technical data | generated and distributed within CALS environments. This | guidance is oriented toward processable data files and | interactive access as may be provided through CITIS. For each | case, RFP considerations are identified in areas such as system | operating environment, approval and authentication, baselining of | data bases and/or files, change control, and maintenance of audit | trails. Since much of the technical data exchanged within CALS | environments has the potential to be impacted by configuration | change, these considerations become vitally important for | ensuring the integrity of contractor-generated technical data. | The acquisition manager should carefully assess the detailed | requirements of Section 50 in developing his plan for acquisition | and implementation of configuration management. | 136 MIL-HDBK-59A APPENDIX C 50 DETAILED GUIDANCE 50.1 Organization of guidance sections. This section is organized into several major sub-sections, which can be used separately or together to contract for integration of contractor functional processes. 50.2 Functional requirements for R&M integration with CAD/CAE 50.2.1 Purpose. This section provides guidance for the procuring activity in generating contractual requirements to achieve the integration of computer-aided R&M engineering techniques 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 end item development, including concept exploration, demonstration and validation, full-scale development, and production. 50.2.2 Impact of R&M. R&M has a decisive influence on weapon systems acquired by DoD. 50.2.2.1 R&M influence on effectiveness. Weapon system R&M characteristics influence the weapon system's operational effec- tiveness by driving its readiness for battle, sustainability during battle, and utilization of personnel and material during training and battle. It is recognized that good R&M characteristics are force effectiveness multipliers by offering the means to defeat a numerically superior force by engaging it repeatedly. Reliable weapons systems result in increased combat capability while employing fewer fielded spare parts and less manpower. Similarly, maintainable systems require fielding of fewer people and specialized skill levels, while achieving reduced maintenance times. Good R&M characteristics improve the mobility of forces because there are fewer people and less support equipment and spares to move. In short, the R&M features of each weapon system contribute significantly to the conflict capabilities of forces at sea, in the air and on land. | 50.2.2.2 R&M influence on life cycle cost. The R&M characteris- tics of a weapon system are also key leverage points in determining the weapon system's total life cycle costs and operational effectiveness. An estimated 30 percent of life cycle costs can be traced directly to R&M characteristics of the weapon system's design. These costs occur not only as budgeted line items in the procurement and operations and maintenance appropriations for the particular weapon system, but also as indirect costs of the supporting logistic facilities and | activities, manpower, attrition replacements and replenishment spares. 137 MIL-HDBK-59A APPENDIX C 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 achieving improved R&M, these approaches are fundamentally limited by their inability to influence the design process itself. To a large extent, the R&M characteristics of a weapon system are attributes of its design, or more precisely, a direct function of the atten- tion given to them in the design process. They are analyzed into the design after it has been completed only with great difficulty and cost. Additionally, the R&M improvement effort must compete with integration and operational testing for test resources and schedule. 50.2.2.4 CAE in development. The application of CAE resources to the R&M characteristics of weapon system development in an integrated design environment has the potential for achieving a | quantum improvement in R&M. When applied to R&M design, CAE will provide the designer with closely-coupled, short-cycle analysis and feedback about the efficacy of the design approach so that corrective action and optimization can occur during the design process rather than later. In addition, concurrent design synthesis techniques offer a superior inherent R&M design capability. In essence, CAE enables the designer to design the product right the first time with respect to R&M, the objective of Total Quality Management (TQM). 50.2.3 General implementation guidance. The ultimate goal of integration of R&M into CAE is for all major design decisions affecting the R&M characteristics of the end item to be fully supported by automated procedures that are appropriate to the nature and level of the decision in a concurrent or near-concurrent fashion. 50.2.3.1 Achieving the potential of CAE. Achieving the full po- tential of integrated CAE requires capabilities in five fundamental areas: a. Automated R&M analysis procedures tightly coupled to parts libraries and materials characteristics data bases. b. Automated R&M synthesis processes based on design rules incorporating lessons learned from prior design experi- ence and field use. c. Fully characterized (tested and validated) component performance and R&M characteristics data bases. d. Configuration management procedures that link major 138 MIL-HDBK-59A APPENDIX C design decisions affecting the R&M characteristics of the end item to: (1) the CAE software and data bases used to develop decision criteria and otherwise support the decisions, and (2) the evolving configuration of the product, documented through configuration- controlled versions of the digital product description. e. A supporting structure of hardware, software, and | computer networks adequate to support the procedures and processes of (a) through (d) above and to closely couple 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 tasks to be performed by the contractor as detailed in the contract Statement of Work (SOW), and in any R&M-related attachments and exhibits. The results of these tasks are to be delivered in accordance with the Contract Deliverable Requirements List (CDRL) in the format specified by a Data Item Description (DID). The integrated R&M functional requirement is different because it places an indirect requirement on the contractor's engineering resources, in the form of R&M-specific CAE techniques, procedures, and data bases. This indirect requirement necessitates a different contracting approach than does traditional R&M tasking, but is consistent with streamlining, and allows the contractor more freedom to determine how to satisfy the government's requirements. It replaces emphasis on specific SOW tasking with increased emphasis on the use of instructions to offerors and source selection criteria. This approach leads the contractor to tell the government how integrated R&M-specific CAE is to be applied to the program being bid, rather than telling the contractor how to apply it. 50.2.3.3 Integrated procedure. In essence, using this approach, the government will ask the contractor to describe its existing and proposed R&M automation capabilities; award the contract based, in part, on the strength of the response; make any necessary adjustments during final negotiations; and incorporate the results in the ensuing contract. No additional CDRL items or DIDs are required. CDRL items and DIDs normally invoked to | acquire R&M data can be tailored in ways that encourage the contractor to develop automated means for the generation and submission in digital form of these data. Suggested wording to implement tailoring is presented in 50.2.5.2. 50.2.4 RFP and source selection guidance. The following 139 MIL-HDBK-59A APPENDIX C guidance is provided on contracting for integrated R&M data. 50.2.4.1 Approach. 50.2.4.1.1 Instructions to offerors. Section L (Instructions to Offerors) of the Request for Proposal (RFP) should require the contractor to: a. Identify its capability and experience in the use of automated R&M functions. b. Explain to what extent R&M design tasks are integrated with its CAE system. c. Describe how specific CAE techniques, processes, and data bases will be used to satisfy R&M requirements. d. Describe how R&M data bases will be used to support logistic support analysis and record generation. 50.2.4.1.2 Evaluation criteria. Section M (Evaluation Criteria) should be structured to emphasize the above a - d areas. 50.2.4.1.3 Contractual Application. The offeror's proposed capability 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 just responses to government requirements. b. R&M CAE is essential to winning contracts, and therefore will be given proper emphasis. c. Specific R&M CAE capabilities will be used in the design and logistic support processes and will not be traded off or deleted because specific SOW requirements were not defined. 50.2.4.2 Sample language. The following subparagraphs contain sample language that is recommended for incorporation in Sections L and M of an RFP. The language represents the most comprehensive approach and thus should be scoped by the acquisition management office to reflect specific requirements relating to the solicitation and the proposal responses. 50.2.4.2.1 Wording for Section L. The following wording is sug- 140 MIL-HDBK-59A APPENDIX C gested 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 which Computer-Aided Engineering (CAE) techniques and related resources are to be used to ensure that design decisions affecting the ultimate R&M properties of the system (item) are adequately supported by automated trade-off analysis, engineering simulation, or concurrent design synthesis processes. This shall include a general description of the CAE environment within which design and development is intended to take place, and a specific description of the CAE capabilities dedicated to R&M support. It shall also include a discussion of the offeror's formal procedures to verify and maintain the accuracy and effectiveness of these R&M CAE capabilities by validating the quality of the engineering functional capability performed, data base maintenance, and development of lessons learned design rules from all sources of feedback. This documentation shall constitute a major element of Part III - Engineering Specialty Integration, of the System Engineering Management Plan (SEMP). The offeror's internal format is acceptable for this documentation. The System Engineering Master Schedule (SEMS) shall describe the timeliness of these inputs relative to the overall system engineering program and other design activities. The general description, including implementation status (current or proposed) of the CAE environment shall consist of 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 of proprietary software, and methods used to assure software quality. 3. Integration approach, including communications | networking, data base sharing and management, and configuration control. 4. Policies, procedures, and organizational responsibility | for control of CAE automation, specifically R&M automated tools. 5. Data standards and technical standards available for | 141 MIL-HDBK-59A APPENDIX C delivery of technical data to the government in digital form. The specific description of R&M resources based within the CAE 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, including | testability and manufacturability tasks, are automated. As a minimum, all tasks imposed in accordance with MIL-STD-470, MIL-STD-785, and MIL-STD-2165 shall be classified into the following categories: a. Not automated. b. Stand alone, no direct access to the CAE design data base. c. R&M algorithms reside within the CAE system, interfacing with the evolving resident item design when invoked. d. R&M algorithms reside with the CAE system, responding automatically to all initial inputs, derived factors, and design changes where appropriate to support a design decision. The offeror will receive credit in proposal evaluation for design-integrated R&M tasks and functions provided they are demonstrated to contribute to a coherent end-to-end R&M, CAE, or LSA engineering process. 3. Descriptions of the offeror's formalized procedure and | past history of deriving 'lessons learned' from test results, field feedback, and vendor data, and translating them into design rules incorporated into the CAE system. This is not intended to be a repetition of the offeror's plan for a Failure Reporting, Analysis, and Corrective Action System (FRACAS) for the specific program. It shall be a description of how the offeror uses information from vendors, testing, and the field to improve both products, and design and manufacturing processes on an institutional basis, and how that process is intended to be applied to the program. The description should contain the process for confirming and assigning a level of confidence to the design rules; the controls over R&M design rules that are exercised by the R&M organization; and the process by which tradeoffs 142 MIL-HDBK-59A APPENDIX C between R&M design rules, cost, and equipment performance are accomplished. 4. A listing of the key design decision points influencing | R&M in the proposed effort, the automated R&M functions that would be used to support them, and the relative time (with respect to major design reviews) of the decisions. 5. Description of data bases to support R&M characteristics | of the features, components and materials applicable to the program (e.g., preferred parts list), including supporting information on source of data (vendor, company tests, government data bases, etc.); confidence factors reflecting both quantity of their source, and whether or not they are based on estimates, simulation, broad categories of parts, tabular data, or actual measurements; applicability to the program; specificity and level of detail; and applicability to reliability, maintainability, or diagnostics. 6. Description of how product development configuration | control procedures will be applied to R&M, including the capture of design decision criteria; discussion of the linkages between the design process and the R&M-specific CAE resources that were applied to it; discussion of traceability of design decisions to CAE resources, including software and data bases that supported them; and procedures in place to rapidly reassemble those resources to effect and record the impacts of an engineering change proposal with minimal impacts to the R&M characteristics of the system (item). State if this engineering history will be available to the government. 7. Description of the integration of R&M-specific resources | with the other product development resources, including personnel, CAE communication networks, application software, and data bases. 8. The specific proposed wording for R&M CAD/CAE | requirements to be imposed on all subcontractors of electronic subsystems, modules, assemblies, and custom components. The general criteria used to evaluate a subcontractor's responses to R&M CAE requirements relative to other criteria such as cost, schedule, and performance. 9. Description of the offeror's internal procedures through | which the automated R&M functions including supporting data bases are demonstrated to be correct, including conformance to industry standards if applicable. 143 MIL-HDBK-59A APPENDIX C 10. Description of the capability to deliver Failure Modes, | Effects, and Criticality Analysis (FMECA); predictions; LSAR; failure summary reports; and other R&M reports appearing in the attached contract CDRL as digital data in government-approved standard formats. 50.2.4.2.1.1 Wording if risk reduction is required. If the Instructions to Offeror contain a requirement for a section describing a risk reduction effort, the following wording in addition to 50.2.4.2.1 is suggested: The offeror shall identify the intended use of Computer- Aided Engineering (CAE) techniques to aid in reliability and maintainability risk reduction, outlining the risks to be addressed, how CAE is intended to help reduce them, and the benefit of CAE over other approaches, including level of risk reduced, accuracy, or timeliness of results. 50.2.4.2.1.2 Wording if preliminary design is required. Where the Instructions to Offeror contain a requirement to provide preliminary design, system block diagram, functional partitioning of requirements, definition of configuration items, or preliminary system or item specifications, the following is intended to be added. The exact wording of the information requested from the offeror should be substituted for the term | "preliminary design". | It is critical that preliminary design data provided to the government by the offeror contain sufficient supplemental documentation so that the government can understand the design criteria used to support the preliminary design. Information documenting the CAE resources that supported major tradeoff decisions impacting R&M, including a description of the tradeoff decisions and a summary tracing the specific nature of the input to the decision from R&M, shall be provided. 50.2.4.3 Sample language for Section M. The following wording is suggested for incorporation in Section M, Evaluation Criteria, of RFPs: | The offeror's (technical/management/system engineering) plan will be evaluated for the extent of intended application of CAE. It is not adequate for evaluation purposes simply to cite the use of CAE on a blanket basis; i.e., CAE resources will be applied where applicable. The offeror must demon- strate their understanding of the use of CAE by including in a proposal a brief discussion of how CAE is to be applied to the R&M engineering process. The discussion should include 144 MIL-HDBK-59A APPENDIX C a specific summary of the CAE resources intended to be applied, the points in the development process where leverage from CAE is anticipated, any government required analysis that will be generated in whole or in part by CAE, and expected benefits to the program. The following specific criteria will be used: 1. What is the capability described by the offeror for | direct concurrent or near-concurrent synthesis of the R&M characteristics of the design based on design rules, embedded design knowledge, feature-based design, or lessons learned files? What major R&M design decisions are so supported? 2. What processes does the offeror describe for conversion | of lessons learned from the field or test processes to R&M design rules? Is there a formal process for creating, implementing, and validating new rules on the same CAE system/data base used to design the product? 3. Are adequate design analysis tools available to provide | the information necessary for trade studies and for support of other data requirements (e.g., logistics)? Do these tools interact with relevant CAE design data base parameters as they evolve? 4. Are the R&M-specific CAE feature, component, and | materials characteristics data bases (including failure properties, mechanical properties, and component models to support detailed engineering simulation of the product) adequate to support the design effort required? To what extent are they validated? 5. If the government plans to take over responsibility for | sustaining engineering, to what extent will the offeror provide design decision traceability, including supporting data packages or data files? Are the interfaces between the contractor and the government, and between the contractor and any suppliers, adequate to support transportation of product data and models? 6. Does the offeror intend to employ sufficient CAE | resources, including hardware, software, integration, and networking facilities, to adequately reduce risk and accomplish the proposed R&M program in a timely fashion? 50.2.5 Contract requirements. Contractor responses to Section L of the RFP should be used in final negotiations with the winning contractor. The object is to incorporate as contract 145 MIL-HDBK-59A APPENDIX C requirements all proposed items that the government and contractor believe will provide significant benefits to the design in terms of improved R&M performance. As contract requirements, the chance of R&M CAE functions being eliminated due to pressures from other program elements (e.g., costs, schedule) will be minimized. 50.2.5.1 CDRL items. No additional Contract Data Requirements List (CDRL) items are required as a result of R&M CAE implemen- tation. While R&M CAE may reduce CDRL costs for some items, the specific CDRL requirements for each program should be based on specific government needs for design data. 50.2.5.2 Tailoring. In general, the CDRL lists the data to be delivered under the contract, frequency of submittal, generation procedures, and required formats. One method of motivating contractors to undertake R&M tool development and integration is to tailor the CDRL and the associated DIDs. Selected tailoring | can accomplish this goal by providing incentives for automated data item generation. A recommended tailoring approach for each of these elements is discussed below, followed by models of contract wording where appropriate. 50.2.5.2.1 R&M task selection. The availability of computer processable data must be considered when attempting to encourage the automation of any R&M task. The selection of the R&M tasks to be accomplished and the associated data items delivered are development phase dependent. This information can also be found in various military standards that describe the requirements for R&M programs. When an R&M task is required, the level of data expected to be available must be considered. For example, during the concept exploration phase, the Failure Modes, Effects, and Criticality Analysis (FMECA) can be performed to the functional level. The detailed level of digital data available during the full scale development phase, however, permits the accomplishment of the FMECA down to the device level. Where the offeror proposes to use CAE to support an R&M analysis task, the government program office can expect higher quality and timeliness in delivery of detailed data in a more useable form. 50.2.5.2.2 CDRL/DID cross references: tailoring for digital format. The CDRL will include a reference to the procedures required to perform the data item generation and to the desired format by referencing the Data Item Description (DID) to be used in Block 4 of DD Form 1423. During the phase-in period, the contractor can be encouraged to use automated data item generation capabilities by permitting data to be delivered in formats and standards that are not in conformance with CALS directives. The following CDRL wording may be used in Block 16 146 MIL-HDBK-59A APPENDIX C of DD Form 1423: Block 16: If automated data item generation capability is used, contractor's format is acceptable. 50.2.5.2.3 Tailoring: frequency of submissions. In an effort to reduce the number of submissions required, one CALS objective is to establish government access to contractually approved portions of the contractor's data base through CITIS. The program office should explore this option where applicable to reduce data delivery. 50.2.5.2.4 Tailoring DID language. The DID references the appropriate military standards and guidance to be used for data item generation, and includes formatting instructions. Generally, DID's are tailored to account for unique program aspects. Tailoring of the procedures and methods required for data item generation and the format of the deliverable can also encourage automation of the data item preparation task. The following wording is suggested: It is recommended that the contractor employ automated capabilities in the generation of the data items required. Modification of the submission format consistent with the level of automation proposed is acceptable. Submission of data in digital format is encouraged. 50.3 Functional requirements for integration of contractor LSA processes with R&M and design engineering. 50.3.1 Purpose. This section provides guidance for the procuring activity in generating contract requirements for integration of LSA and R&M engineering processes. These processes are often performed by separate contractor organizations, supported by separate automated systems. Integration can reduce duplication of effort, improve the consistency and quality of data, and improve the quality of the system or item under development. The following statement of work (SOW) language is appropriate when the contractor has, or is expected to have, automated LSAR and R&M data systems. 50.3.2 Suggested contract wording. The following wording is suggested for incorporation in the SOW: The contractor shall identify in the LSA plan the procedures, either automated or manual, that will be used to ensure LSAR documentation requirements for reliability and maintainability (R&M) information are satisfied through use of appropriate (R&M) data sources. The procedures shall 147 MIL-HDBK-59A APPENDIX C describe how R&M source data are to be used in developing the LSAR, and shall address initial R&M inputs as well as change control for data additions, deletions and modifications. The procedures shall also identify the algorithms or transformations that must be applied to source data elements to conform to LSAR documentation requirements. The procedural description shall be of sufficient detail to clearly demonstrate traceability between the LSAR and individual R&M data sources, and the preservation of appropriate data flows while maintaining established LSAR data element relationships and interdependencies. 50.4 Functional requirements for configuration management of | technical data | | 50.4.1 Purpose. Configuration management of technical data | (see definitions for data iterations provided in 5.1.3) is key to | managing data integrity in the era of electronic data | interchange. Its disciplines are applied to such items as | information structures, data base architecture, operating system | environments, and network access, as well as the hardware, | application software, and all associated digital data. | | This section reviews current government and industry progress, | addresses factors applicable to processable data file and | interactive access modes of information exchange, and provides | guidance for the acquisition and implementation of configuration | management. | | 50.4.2 Background. Configuration Management has been | traditionally applied to: | | a. Deliverable end items, including both Configuration | Items (CIs) and Computer Software Configuration Items | (CSCIs); | | b. Data defining baselines for the CIs and CSCIs, e.g., | development and product specifications and engineering | drawings; | | c. Data, such as material and process specifications and | standards, called out by engineering drawings that are | part of the product baseline, and all other related | data that requires change as a result of an approved | Engineering Change Proposal (ECP); and | | d. Other related data in digital form maintained by | contractors for government access. | 148 MIL-HDBK-59A APPENDIX C 50.4.2.1 Reference Documents. The following documents provide | guidance for the implementation of configuration management. | Planned DOD revisions to many of these documents will enhance | their use in applying the discipline in the CALS environment. | | DOD CONFIGURATION MANAGEMENT DIRECTION | DODD 5010.19 | JOINT CM REGULATION | | CONFIGURATION MANAGEMENT PLANNING | MIL-STD-483 | DOD-STD-1456 | DOD-STD-2167 | | CONFIGURATION IDENTIFICATION | DOD-STD-100 | MIL-STD-483 | MIL-STD-490 | DOD-STD-2167 | MIL-N-18307 | | CONFIGURATION CONTROL | DOD-STD-480 | MIL-STD-481 | | CONFIGURATION STATUS ACCOUNTING | MIL-STD-482 | MIL-STD-483 | DOD-STD-2167 | | REVIEWS/AUDITS | MIL-STD-1521 | DOD-STD-2167 | | 50.4.2.2 Current Environment. | | 50.4.2.2.1 Government. In today's Computer-aided Acquisition | and Logistic Support (CALS) environment, manual or partially | automated configuration management systems will not adequately | support the volume and timeliness goals of digital transfer of | technical data. Selected activities aimed at developing | improvements in this area include the following: | | a. Army. The U.S. Army Technical Data/Configuration | Management System (TD/CMS) has been assisting the | Army's configuration management community since 1968. | This system uses second generation batch processing, | and eventually will be upgraded to DBMS technology. | 149 MIL-HDBK-59A APPENDIX C b. Navy. Naval Sea Systems Command has established the | Ship Configuration and Logistics Support Information | System (SCLSIS), which encompasses the automated data | processing systems and all practices and procedures for | identification data reviews, and equipment | configuration audits. For ships already in service, | the SCLSIS specification established Configuration Data | Managers (CDMs) as the single activity responsible for | the database. | | c. Marines. The Marine Corps Logistics Base in Albany, | Georgia (MCLB-A) has been using TD/CMS for tracking and | reporting CM data. The second generation TD/CMS has | been expanded so that the completed functionality of | the TD/CMS is available in an on-line interactive | database management system environment. | | d. Interactive TD/CMS. One of the best examples of shared | digitized data is the linkage between the on-line | interactive TD/CMS and the optical image storage | systems being implemented at data repositories operated | by the Military Services. In this application, TD/CMS | provides a driver mechanism whereby the user needs only | to enter a top drawing number for the system to | determine all related supporting information. | | 50.4.2.2.2 Industry. Although industrial programs vary from | company to company, they can be typically categorized as | transitional, from "islands of automation", reflected by clusters | of independently developed, stand-alone computer systems, to one | of related databases which provide the capability for integrated | information systems. Each corporation has its own architecture | to fulfill its present and future internal processing needs in | response to customer demands. | | In general, automation of configuration management within | industry is based upon the administration of data elements | concerning paper-based product data. A number of commercial | software tools for version and library control are widely | employed. Some inroads are being made into the CAD/CAM | management of product data files with the use of file-based Data | Management Systems (DMS). | | 50.4.2.3 Processable Data Files (Data Transfer Relationships). | Using the decision templates in Appendix B, the government may | require the contractor to create, use and configuration manage | processable data files in support of an acquisition (e.g., | engineering data, manufacturing data and logistics data). | 150 MIL-HDBK-59A APPENDIX C 50.4.2.4 Interactive Access through CITIS (access to Contractor | Data Bases). Using the decision templates the government may | require interactive access through CITIS as the applicable form | of deliverable. In this case the methods of specifying | requirements and maintaining configuration control are similar to | those for delivered processable files. However, data are not | physically submitted but are made accessible to the government by | pre-defined or ad hoc query. | | 50.4.3 Implementation Guidance. This section provides guidance | to implement configuration management (CM) of both processable | data files and interactive access to contractor and government | databases. For each environment, requirements for data element | definition, linkages and standardization, and the issues | pertinent to the management and control of technical data to be | exchanged, are identified. | | The CALS CM concept involving interactive access of a contractor | database is based on the assumption that a contractor will | maintain the databases and provide transmission and shared | access, as well as CM control, of digital data among | subcontractors, associate contractors and the government. | Typically, CM involvement today is concerned largely with | baseline control of contract line items (hardware and software | deliverables). In a CALS environment, the role of CM should be | extended to include the control and management of the on-line | interactive database file transactions. | | Two primary configuration control issues come into play in this | process. The first concerns information identifying the files or | data bases involved; the second concerns the controls applied to | the information to be extracted to assure data integrity. Data | integrity, as used here, refers to the built-in controls | necessary to ensure the correct relationships between data | elements from both an update cycle/date basis, and from a | configuration change/revision/version standpoint. | | As in the case of R&M integration with CAD/CAE, the capabilities | described should be scoped by the acquisition management office | to reflect specific requirements relating to the solicitation and | proposal responses. | | 50.4.3.1 Processable Data Files. Recognizing that there will be | a mix of paper-based data delivery and electronic data | interchange for some time to come, this section addresses the | configuration management issues involved as CALS transitions from | exchanging data files on magnetic media to networked | communication. | 151 MIL-HDBK-59A APPENDIX C Configuration Management issues with respect to the integrity of | the data are similar for all categories of data described in | Appendix B but differ in degree of significance. Hard copy or | microform documents can clearly define or limit the applicability | of the information they contain. When information is extracted | by query from a processable data file, however, the limits of | applicability will be lost unless the data relationships are | properly structured. Following are concerns applicable to | processable data files: | | a. Control of access to read and/or write to the | files; | | b. Timeliness of the information (i.e., current as of | what date); | | c. Relationship of specific data within the file to | the correct configuration, version or revision of | hardware, software or document; and, | | d. Cross-indexing of updates to the contents of the | data files with approved changes to the product | (hardware or software under contract). | | The myriad of data created by various sources and used for | acquisition and support application make the need for | unambiguous, generic data element definitions imperative for | exchanging processable data files. Standard data definitions | occur by reference to a MIL-STD or Data Item Description, which | may make reference to a future CALS data dictionary. The CALS | data dictionary likely will include not only standard data | definitions, but the ability to modify or qualify those | definitions with standard descriptive modifiers. | | 50.4.3.1.1 Data element linkages. Having standard data | definitions with common modifiers, however, is not sufficient to | insure that the data in a processable data file retains its | integrity. A processable data file is, after all, one that can | be further manipulated by both the source and the receiver of the | file. This means that the file can be: | | a. Combined with other files; | | b. Queried with information extracted by the user; | | c. Added to either by file update or file expansion; or, | | d. Changed or deleted. | 152 MIL-HDBK-59A APPENDIX C This ability adds another dimension to the limits formerly | inherent to paper or microform transmittal of data and to the | transmission of read-only files. Each of these retains the data | relationships imposed by the provider of the file or report. | Liability for the misuse or misinterpretation of the data rests | solely with the receiver. | | With a processable data file, however, this safeguard is tenuous | unless controlled data element linkages, or relationships, are | defined as part of the data dictionary or provided as an inherent | feature of the data file structure. Further manipulation of the | data by the receiver would then be limited to that which does not | distort the basic data relationships established by the provider. | | 50.4.3.1.2 RFP Considerations. This section discusses the | acquisition of processable data files by the government. It | describes those elements of the Statement of Work (SOW) and | Contract Data Requirements List (CDRL) that define the adequate | use and control of the files. The government should consider the | following when defining requirements in the SOW and CDRL. | | 50.4.3.1.2.1 Definition of Deliverables. | | a. System Environment. The following fundamental areas are | required. | | 1. System/equipment/operating compatibility. | | a. Assurance that system compatibility exists at | least at the file level to assure delivered files | are not inadvertently changed by a system's | hardware or software. | | b. Telecommunication networks and protocols are | compatible between the source(s) and receiver(s). | | c. Interface criteria for dissimilar systems shall be | defined. This implies interface characteristics | both for the single package (i.e., a design data | file) and data processing information extractable | from a database management system. As a minimum, | the government should specify the system and | equipment configuration with which the contractor | must interface. | | d. Compatibility of translators or other software | processors (e.g., file compressors) existing | between the source(s) and receiver(s). | 153 MIL-HDBK-59A APPENDIX C e. Government shall define file interface formats. | | f. Where applicable, government hardware, software | and information that will be provided to the | contractor shall be defined. | | 2. Multiple source integration. The integrating | contractor, or the government integrator, were | applicable, shall provide the necessary Data Base | Management System (DBMS) to integrate data from | multiple sources. This shall include formatting to | meet customer requirements as well as | verification/validation of the integrated data. | | a. Where applicable, data developed in different | environments shall be integrated into the host | system. Sources may be internal, subcontractor | and/or vendors. | | b. Database management systems shall be compatible at | the interfaces. | | 3. Configuration Management. The contractor shall | implement and maintain configuration management, in | accordance with the government-approved configuration | management plan. | | b. Media. The contractor shall develop media in accordance | with MIL-STD-1840 using Appendix D of this document. | | c. Frequency/Type of Update. The contractor shall provide | electronic data in accordance with the CDRL. Batch vs real | time update shall be determined by the customer. | | d. Data Dictionary. The definition of data elements shall be | in accordance with the standard CALS data dictionary which | shall be maintained consistent with the 28000 series of MIL- | STDs and the applicable functional standards and DIDs. | | e. Validation of electronic data transmittal. The contractor | shall validate all electronic data in accordance with the | requirements of the contract. | | f. System Data Protection & Integrity. The contractor shall | provide the necessary degree of data protection in | accordance with Appendix E of this document. | | | 154 MIL-HDBK-59A APPENDIX C g. Local Government Representative. The contractor shall | provide the necessary facilities and administrative support | to accommodate on-site customer representative review. | | h. Data Retention. The contractor shall ensure that digital | data delivered to the government are properly archived, | stored and safeguarded in a digital environment. | | 50.4.3.1.2.2 Approval/Authentication | | a. Acknowledgment of receipt. | | 1. Acknowledgment of receipt by the receiving agency shall | be as follows. | | a. When the physical media is sent to the contracting | agency, acknowledgment of receipt shall be with a | returned signed copy of the data transmittal | letter to the sending agency, or equivalent | message of endorsement. | | b. When the data is electronically transmitted (e.g., | modem) the receiving agency's data file shall have | the capability of generating an acknowledgement of | receipt of the data at the end of the | transmission. | | 2. A method of error detection in data transfer must be | implemented to insure deliverable products are capable | of being recreated in human readable format, e.g., | text, graphics, plots, raster, etc. | | b. Data/information distribution/access. Distribution codes | shall be assigned in accordance with MIL-STD-1806 and DODD | 5230.24. Access shall be limited in accordance with the | applicable distribution statements. | | c. Deliverable Data Approval. System will have the capability | to accept, acknowledge approval and/or acceptance, and | provide status upon receipt of that approval. | | 50.4.3.1.2.3 Change Control & Notification. | | a. Release. Release may be generically defined for change | control purposes as a change in control authority over data. | For example, the passing of control for changes and | distribution from the data creator to CM, which often | includes the authority to pass data on to external | functions, such as the customer (for approval or other | 155 MIL-HDBK-59A APPENDIX C action), a subcontractor (providing information and | direction), or an interfacing contractor (providing | interface definition). It also includes the authority for | internal functions to use the data, e.g., manufacturing, | procurement, materials, etc. | | Prior to release, the data creator/originator has full | control over his data product and may change it at his sole | discretion, subject only to the particular authority granted | to him by internal procedures. | | 1. Internal review & approval. A fundamental requirement | for data release is that it be properly reviewed and | approved by appropriate individuals or disciplines | within the organization, and certified as to its | accuracy and completeness, that it is indeed authorized | for release, and that release records are maintained. | In the case of engineering product definition data, | these records must retain the record of superseded | configurations and provide the audit trail to the | composition of any part in terms of its subordinate | parts. In the case of CDRL data items that are to be | submitted to the customer, data certification is also | required (by the FAR) and the information must be | properly identified. All other official data also | requires some review and authorizing signature. | | Review and approval requirements are even more important in | the CALS environment than in the paper-based world, | particularly because of the ease with which they can be | circumvented. The result of ignoring these requirements is | transmission of unofficial data, chaos resulting from | multiple or conflicting submittals, flawed data, or worse. | | Means must be provided for proper data review, approval and | validation, and for the originator (individual with | responsibility for the data content) to correct errors and | add to the existing data, as necessary, as part of this | process. Since the data to be released may be in the form | of CAD designs, documentation, and software code (both | source and machine readable object code), automated tools | will have to be employed to validate the processable data | files both prior to and after entry onto the transmittal | media. | | To prevent these requirements from becoming a delaying | process which obviates the benefit of electronic | transmission over paper submittal, the culture of the review | and approval process, much like that of the automated | 156 MIL-HDBK-59A APPENDIX C factory, must change from one of "product inspection" to one | consisting largely of "process measurement and control" | | 2. Approval signature. The method of implementing | approval and acceptance shall be determined by the | contractor in consultation with the customer. The | implementation method shall ensure that only authorized | personnel can activate the appropriate approvals for | the document. | | The contractor shall define the method of implementing | approval signature controls. These controls should take | into consideration the checks and balance required to | prevent the unauthorized transmittal of data to the | customer. | | Documents may be approved electronically. The system of | electronic approval should be adequate to identify the | responsible individual, his area of expertise/function. The | contractor's CITIS manager shall ensure the system has | adequate safeguards and secure means to protect the | integrity of the authorization from unauthorized | individuals. | | When electronic means are used to implement authorization | and transmittal, they should include, but not be limited to, | the following requirements: | | a. Compatible with Systems Management. | | b. Define authorized approver(s) along with area of | responsibility within both internal and external | organizations. | | c. Define whether it supersedes normal signature | system or not. If not, a procedure to relate | manual system to CALS is required. | | d. Defined policies & procedures for implementation. | | e. Electronics acceptance of document for release. | | f. The originator's data protection and integrity | system shall assure that authorizations are | obtained before the document is formally released. | | g. A valid release record for each document is | created and maintained. | 157 MIL-HDBK-59A APPENDIX C b. Baselining data bases/files. | | 1. Establishing Baselines. A baseline document is one | which has been approved in accordance with the contract | and is subject to customer change control. | | The concept of baseline management must be adapted for use | in the CALS environment. Data that has been authenticated | for use by the procuring agency, i.e., baselined, must be | clearly identified and changes to this data must be approved | prior to insertion into a previously baselined file. The | method for identifying the baselined status may be contained | in the document release file, a baseline report, or integral | to the document. | | All superseded versions of a baseline document shall be | retained and shall be accessible to authorized users. When | the document is requested, unless a specific version is | specified, the current baselined version shall be presented. | | 2. Control of Interface Information. A data dictionary, | or its equivalent, will be defined to identify the | interrelationships between data elements and | methodology for identification so that a complete | database for each item can be extracted. | | 3. New Technology Insertion. As new technology becomes | available, which adds to or modifies the existing | capabilities of the systems used by both contractors | and the government, it should be added to the database | under careful change control in accordance with the | approved configuration/data management plans. | | 4. Baseline Change Control. Once the database has been | baselined, any change to that baseline shall be | authorized only by the formal change control process | imposed by the contract. The contractor should specify | how he intends to control this baseline in the CALS | implementation plan and should negotiate its | implementation with the customer. The plan should | specify what types of data will be included in the | baseline and shall, as a minimum, include the | engineering data. Changes may be prepared/approved by | electronic means but must be formally released before | the baseline can be updated. | | 5. Control of Other Submitted Documents. The methodology | of implementing control and updates to submitted data | that does not require customer approval shall be | 158 MIL-HDBK-59A APPENDIX C defined by the contract, i.e., submittal of revisions, | as required or other means. | | c. Review and Update. | | 1. The review and update procedures for processable data | files shall be identified by the contractor, however, | the following generic requirements will be applicable | to all data. | | The file shall be annotated by the responsible | reviewing agencies within the contractor's and | customer's organizations. However, this review must | not impact the integrity of the currently approved | version of the document. Annotation shall be made to a | separate working copy which shall be renamed. | | The contractor shall use procedures that define the | control of data during the customer and contractor | review and update cycle. As a minimum the following | must be defined: | | a. How data and changes are to be transmitted; | | b. How changes are identified; | | c. Annotation of where changes occurred; | | d. Notification of receipt, return, or acceptance; | | e. Re-identification of marked up version, if | required; | | f. Time constraints or data acceptance; and | | g. Data Status Accounting Log. | | 2. Prior to Baselining. The contractor shall notify the | customer when data has been submitted for | review/approval. Recommended changes | (contractor/customer) shall be iterated, until | resolution has been reached. Upon modification and | receipt of customer approval the data shall be updated | and baselined. | | 3. Subsequent to Baselining. The contractor shall prepare | or update proposed recommendations for all data files | and electronically submit to the customer for review, | comment, and approval before update. Once agreement has | 159 MIL-HDBK-59A APPENDIX C been reached and customer approval has been granted, | the update shall be released into the approved | baseline. Data revisions of items transmitted for | information will not require customer approval or | concurrence. | | d. Customer/Receiver Alteration of received data. If the | customer desires to make changes to received data, he must | re-identify the altered file. If the contractor's file will | not be maintained as the "master", the customer becomes | custodian of the data and the following conditions apply: | | 1. The design authority has been transferred from | contractor to the customer. | | 2. Identification/re-identification has been agreed to | between contractor and customer. Engineering data | furnished to the customer (government) needs to be re- | identified in accordance with procedures delineated in | DOD-STD-100. | | 3. Although the data was originally prepared using the | contractor's design activity, Contractor and Government | Entity (CAGE) code, and the contractor's document | numbering system, alterations shall be identified by | government CAGE code. | | Multiple data bases may be maintained by both contractor and | customer. Contractor shall maintain the database(s) | required to establish the baseline(s) of the data delivered. | The customer shall maintain the database(s) required to | track the change history from the contractor baseline(s). | | If the customer determines to leave the approved database(s) | resident at contractor facility, then conditions and | agreements will be required relative to cost, system | database management, change controls, and conditions for | change notification. | | e. Change History. The contractor shall maintain in his status | accounting system, a complete change history for all | processable data files. The contractor's system shall be | capable of providing: | | 1. The status of all data within the database, including | release record; | | 2. The approved revision status of all data including the | enabling document (ECP/Release); and | 160 MIL-HDBK-59A APPENDIX C 3. The listing of all changes that have been submitted but | not yet approved. | | f. Audit Trails. Audit trails should be such that the | traceability history is retained, from initial customer | submittal throughout the remainder of the contract life. | | An audit trail shall be established for the database. The | trail shall allow traceability from the current version and | back to the original baseline. During an audit, each | applicable version of the data and the change which created | that version shall be identifiable, and available. | | 50.4.3.2 Interactive Access through CITIS. In future CALS | environments, the totally automated or electronic practices are | implemented. The emphasis is on government access through CITIS | to contractor maintained databases. Essential to the successful | implementation is a full definition and understanding of the | capabilities offered and constraints needed to provide use of | available data while protecting the integrity of the program | database. | | 50.4.3.2.1 Categories for Interactive Access. The emphasis | shifts from types of media to database accession modes and the | types of data available in the database -- database integrity | issues are now increased due to the increased accessibility of | source data by a wider population. Not only is the data visible | to more people, it is in a form more readily subject to | modification by users. | | CM concerns with data and database integrity center around | controlling access, defining queries, potential loss of original | data, severing of vital linkages and controlling changes to the | database. Elements subject to categorization are queries, data | processing interactions and data types. | | 50.4.3.2.1.1 Queries. There are two categories of database | queries - predefined and ad hoc: | | a. Predefined (CITIS Level 2) - A predefined query is data | accessed in a tailored form and in fixed format, not | readily changeable by the user. Such inquiries | typically consist of menu screens that allow the user | to select an option from the menu. | | b. Ad-Hoc query (CITIS Level 3) - An ad-hoc query allows | most if not all the data elements in the database to be | accessed by the user in the format the user defines at | the time of making the query. Such queries typically | 161 MIL-HDBK-59A APPENDIX C are made through using a command language that allows | the user to define the parameters of the query. The | command language normally allows the use of Boolean | operators and logic to define the parameters of the | query and define data relationships. | | 50.4.3.2.2 Data Processing Interactions. Interactive access | shall provide a means for a full range of interactions with the | database from a "read only" capability to maintenance and update. | | 50.4.3.2.3 Data Element Definition and Standardization. The | database will be accessed and manipulated by a diverse community | including government, contractor and subcontractor activities. | This makes it essential that unambiguous, generic data element | definition be established and used. | | Standard data definitions should be used to the maximum extent | possible. Where elements are not properly defined, standard data | element definition should be established for the immediate need | and then proposed for inclusion in future application. | | 50.4.3.2.4 Data Linkages. Having standard data definitions with | common modifiers, however, is not sufficient to insure that the | data in an accessible database retains its integrity. With an | interactive database, unless controlled data element linkages, or | relationships, are provided as part of the data dictionary or as | an inherent feature of the database structure, the data is | subject to severe degradation. Manipulation of data entity | relationships by the accessor should be limited to prevent | distortion of the basic data linkages established by the | provider. | | 50.4.3.2.5 CALS File/Data Indexing. In an interactive | environment which will cross multiple databases among government, | prime and subcontractors, a standard indexing scheme to enable | navigation among the many databases to locate the correct source | is required. | | A master data dictionary or directory is a critical precursor to | the indexing process. Each contractor and government agency must | provide a translator relating his system unique field names to | the generic language in the dictionary. The index provides the | pointers and the road maps to locate the applicable database and | files which need to be accessed. Each database that is part of | the total virtual integrated weapon system database must be | represented in the index. Within each database a subordinate | index must point to specific files and the data content it | contains. Updating of the index must be tightly controlled to | maintain database integrity. An automated methodology must be | 162 MIL-HDBK-59A APPENDIX C implemented within each CALS database to provide index | maintenance concurrence with file update. | | CALS data indices should consider as a minimum the following: | | a. Weapon system identity; | | b. Database identity/location; | | c. Translator/identify/location; | | d. Type information available; | | e. Commercial and government entity code; | | f. Terminology cross-reference (standard dictionary vs | contractor/government vernacular); and, | | g. Configuration item identity. | | 50.4.3.2.6 RFP Considerations. This section assumes that the | required portions of paragraph 50.4.3.1.2 of this appendix have | been included elsewhere in the RFP as appropriate. In addition, | the government needs to define the number of system users and any | access limitation such as, read only, read with report | capability, and the time of day or night when the system will be | accessed for report generation. | | This section discusses interactive access to the contractor data | files. Two options may be procured for interactive access, | either by predefined query method of by ad hoc query as described | previously. | | 50.4.3.2.6.1 Definition of Deliverables. In addition to the | requirements described for processable data files, the government | should consider the following additional requirements in the SOW | and CDRL, for interactive access: | | a. Users Manual. The contractor shall prepare and deliver | a Users Manual in accordance with the CDRL. The manual | shall describe the system and operating procedures | necessary to access the database for on-line query and | report generation using either the predefined query | and/or the ad hoc query techniques. | | b. Usage and Storage. The contractor shall provide the | ability for the government to access the database | residing in the contractor's computer. The time of day | or night for government access shall be negotiated. | 163 MIL-HDBK-59A APPENDIX C The contractor shall include in the proposal the rate | for this access, the recommended time(s) for access, as | well as the rate for data storage. | | 50.4.3.2.6.2 Approval/Authentication. The text of 50.4.3.1.2.2, | written for processable data files is applicable as well to | interactive access, including the following subtopics: | | a. Acknowledgment of receipt by the receiving agency shall | be as follows: | | 1. When the physical media is sent to the contracting | agency, acknowledgment of receipt shall be with a | returned signed copy of the data transmittal | letter to the sending agency, or equivalent | message of endorsement. | | 2. When the data is electronically transmitted (e.g., | modem) the receiving agency's data file shall have | the capability of generating an acknowledgment of | receipt of the data at the end of the | transmission. | | b. A method of error detection in data transfer must be | implemented to insure deliverable products are capable | of being recreated in human readable format, e.g., | text, graphics, plots, raster, etc. | | c. Distribution codes shall be assigned in accordance with | MIL-STD-1806 and DODD 5230.24. Access shall be limited | in accordance with the applicable distribution | statements. | | d. The system will have the capability to accept, | acknowledge approval and/or acceptance and provide | status upon receipt of that approval. | | 50.4.3.2.6.3 Change Control & Notification | | a. Release. While the basic definition of release, as | generically defined in paragraph 50.4.3.1.2.3, is valid for | interactive access, there are additional factors that must | be considered for the interactive access mode. The | customer, as well as internal functional areas, will have | access to released data that resides in the contractor's | database. This access, for design oversight, review, or | other action, may encompass the ability to extract discrete | data and manipulate it for purposes of evaluation and | analysis, or for other purposes. This capability will bring | 164 MIL-HDBK-59A APPENDIX C about a major change in the way design reviews and | configuration audits are accomplished by enabling design | data to be remotely reviewed. | | Of significant concern is a means to inhibit the premature | use of "released" data files, that are nonetheless subject | to continuing iteration by the contractor, without | inhibiting useful and cost-effective accomplishment of | properly timed and legitimate functions. | | Access protocols working with the configuration control | process shall cause migration of released data into a | "submittal" status at the appropriate time. This would | occur although no physical submittal of the data would take | place. When data are approved, migration to approved status | must be accomplished. Customer information access priority | would be Approved, then Submitted, then Released with | appropriate warnings, such as the following. | | Response to your query contains either: | | Level 1 (Approved) data only; | | Level 2 (Submitted) data for which notice of | change will be provided to the cognizant | government activity; or, | | Level 3 (Released) data that is subject to change | without notification. | | 1. Internal review & approval. The fundamental | requirements for data release described in 50.4.3.1.2.3 | for processable files, i.e., proper review, approval, | certification and release records, also apply to data | made available for access. Particularly important is | the set of controls to ensure the retention of | superseded configurations. | | 2. Approval signature. The method of implementing | approval and acceptance of data will be changing as the | information base moves from a document-oriented basis | to an interactive data file basis. It will no longer | be possible to conduct a review of the information base | in its existing manifestation. Much like a computer | program, the subset of the data file subject to review | will only be able to be validated by test, or by | examination of different views of the data extracted | from the database. (One such view might look like | today's conventional two, or tomorrow's three | 165 MIL-HDBK-59A APPENDIX C dimensional drawing.) That portion of the file that is | approved will be migrated to the approved database (or | directory) to which read-only access is allowed. To | update "approved" data, it must first be copied to a | working file or directory and it cannot be replaced in | the "Approved" directory without appropriate | authorization by the approving authority. Approvals, | by electronic means, must relate unambiguously to the | discrete data sets being approved. | | b. Baselining data bases/files. | | 1. Establishing Baselines. The concept of baselined design | disclosure documents will have to evolve to a concept | of baselined files. A contractually baselined file is | a file which has been approved in accordance with the | contract and is subject to customer change control. | | Data that has been baselined must be clearly identified | and changes to this data must be approved prior to | release of the updated baselined file. Each approved | update to a baselined file must be uniquely identified | (i.e., filename change, or version/revision number | change), and accompanied by archiving of the prior | baseline file and a record of the authorized | differences. | | The new file must retain the record of prior | configurations which are active or could be active. | When data are requested, unless identified as a request | for historical information, it shall be serviced | against the current version. | | 2. Control of Interface Information. A data dictionary or | its equivalent will be defined to identify the | interrelationships between data elements. File re- | identification will automatically update the data index | so that access to correct and current data is assured. | | 3. New Technology Insertion. As new technology becomes | available, which adds to or modifies the existing | system capabilities, it shall be added to the databases | under careful change control to assure the continued | system integrity. No new system features should be | added without thorough testing to assure that there is | no adverse impact on users of the data. The approved | configuration/data management plan should include | provisions for coordinating any downtime of systems on | the interactive network as well as providing change | 166 MIL-HDBK-59A APPENDIX C evaluation and approval, as required. | | 4. Baseline Change Control. Once the database has been | established, any change to that baseline shall be under | the formal change control document imposed by the | contract. If none is specified, the contractor should | specify how he intends to control this baseline. The | contractor should indicate what types of data will be | included in the baseline, which as a minimum shall | include the engineering data applicable to the | contract. Changes may be prepared/approved by | electronic means but must be formally released before | the baseline can be updated. | | 5. Control of Other Submitted Data. The methodology of | implementing control and updates to submitted data that | does not require customer approval shall be defined by | the contract. | | c. Interactive Review and Update. | | 1. The contractor's system (CITIS Level 2 services) shall | have the capability to support review and annotation of | the released and submitted files by various agencies | within the contractor's and customer's organizations. | However, this review must not impact the integrity of | the currently approved version of the file. | | The contractor shall have procedures that define the | control of databases and files during the customer and | contractor interactive review and update cycle. As a | minimum the following must be defined: | | a. How data is to be accessed; | | b. Request for access and logging of access for read- | only or annotation; | | c. Naming of temporary working version of the file | for purpose of annotation/markup; | | d. Means of indicating whether a comment/annotation | is mandatory or suggested; | | e. Re-identification of marked-up version, as | required; | | f. Method of indicating acceptance, provisional | acceptance, approval, rejection, etc.; | 167 MIL-HDBK-59A APPENDIX C g. Time constraints or data acceptance, i.e., | automatic approval; | | h. Automated status accounting including tracking | disposition of required changes; and, | | i Re-identification of changed files. | | 2. Prior to Baselining. The contractor shall notify the | customer when a file is available for review/approval. | This will be handled like an electronic accession list. | Recommended changes (contractor/customer) shall be | iterated until resolution has been reached. Upon | modification and receipt of customer approval the | document shall be baselined. | | 3. Subsequent to Baselining. The contractor shall prepare | or update proposal recommendations for all data files | and electronically transmit notification of submittal | to the customer for either his review, comment and | approval before update, or his information - | notification that the database has been updated. | | Once agreement has been reached and customer approval | has been granted, the update shall be released into the | approved baseline. Data revisions of items transmitted | for information will not require customer approval or | concurrence. | | d. Customer/Receiver Alteration of received data. The customer | shall make changes to received data, only after re- | identifying the subject file, thus becoming the custodian of | the altered file. The following conditions apply: | | 1. The design authority has been transferred from | contractor to the customer. Changes made by the | customer without contractor concurrence shall be | identified in the change record by government agency | CAGE code. | | 2. Re-identification procedure has been agreed to between | contractor and customer. Engineering data furnished to | the customer shall be re-identified in accordance with | DOD-STD-100. | | 3. Multiple databases should be maintained by both | contractor and customer. The contractor shall maintain | the database(s) required to establish the baseline(s) | for the data delivered. The customer may maintain the | 168 MIL-HDBK-59A APPENDIX C database(s) required to track the change history from | the contractor baseline(s), or alternatively may | utilize contractor facilities, remotely accessing | customer modified files. In the later case, conditions | and agreements will be required relative to cost, | system database management, change controls, and | conditions for change notification. | | 4. Other items to be considered when a customer alters the | data base include supplier notification, product | liability, warranty, R&M, LSA and LSAR. | | e. Change History. The contractor shall maintain in his status | accounting system, a complete change history for all data | files. The contractor's system shall be capable of | providing: | | 1. The status of all released, submitted and approved | files within the data base, including release record. | | 2. The approved revision status of all documents including | enabling document (ECP/Release). | | 3. The listing of all changes that have been submitted but | not yet approved. | | f. Audit Trails. Audit trails should be such that the | traceability history is retained, from initial availability | for access throughout the remainder of the contract life. | | An audit trail shall be established for the database. The | trail shall allow traceability from the current file | baseline and back to the original released version. At each | stage of an audit, the applicable version and the change | authority which created that version shall be identified. | 169 MIL-HDBK-59A APPENDIX C THIS PAGE INTENTIONALLY LEFT BLANK. 170