FA855226RB001 RFP Attachment 17 CDRLs.pdf

For the best experience, open this PDF portfolio in

Acrobat X or Adobe Reader X, or later.

Get Adobe Reader Now!

http://www.adobe.com/go/reader

CUI

AIR FORCE TECHNICAL MANUAL CONTRACT REQUIREMENTS (TMCR)

HH-60W DEGRADED VISUAL ENVIRONMENT SYSTEM (DVES) TMCR

ATTACHMENT XX, CDRL SEQUENCE NUMBER A013A/B, EXHIBIT A

CONTRACT NUMBER FA8522-XX-X-XXXX , CLIN XX

CONTRACT TYPE: CPFF

Modification

TMCR TYPE: S1000D/SGML/PDF

SECTION 1. TECHNICAL ORDER (TO) PROGRAM REQUIREMENTS – S1000D/IETM

1. TMCR Tailoring. The Contractor may propose and submit, in writing, additional tailoring to the Technical Order Manager Agency/Agent (TOMA), Government Program Manager (PM) and Procuring Contracting Officer (PCO) as required by Section L of the RFP. The contractor may also submit additional Section 2 tailoring to propose new TO types (Table 1) and source data and TO updates (Table 2) required to support the HH-60W DVES TMCR program’s objectives. Modifications to contracts can continue to utilize the existing format until renegotiated/replaced. The acceptance of any contractor tailored TMCR will be at the discretion of the government and is not in effect until accepted in writing by the PCO or specified in the contract.

2. TO Program Scope. The Contractor must develop and deliver technical manuals in accordance with (IAW) this TMCR, the attached S1000D Decision Point Tool (section 3), and supplied Business Rules (BRs) that supports the HH-60W DVES TMCR requirements for technically usable manuals.

3. Technical Manual Specifications and Standards (TMSS) Tailoring. AF TMSS tailoring options and some Joint Service TMSS have been documented in preliminary Specification/Standard Interface Records (SIRS) included in Section 3. These preliminary SIRs provide the starting point for further tailoring. Contractors may recommend additional tailoring of the Joint Service TMSS SIRs and provide recommended SIRs for other TMSS as applicable. Tailoring must not change or delete mandatory requirements which are part of the XML schema structure or Document Type Definition (DTD) located in Section 2, Table 1.

NOTE: TMSS requirements marked “(F)” are specifically for Air Force use; “(A)” is for Army, “(M)” is Marine Corps and “(N)” is Navy. Comply with all unmarked and “(F)” TMSS requirements as modified by the tailoring options in each TMSS.

3.1. Questions concerning TMSS requirements may be submitted in writing with suggestions for resolution and supporting information to the PCO and Jeffrey McGovern, AFMCMC/WIH, 2240 B Street Building 11, 1st Floor, Room 130 Wright-Patterson AFB, OH 45433, (385)636-2980.

Deficiencies and suggested improvements may be submitted to the TMSS Preparing Activity (PA).

Recommendations, corrections and clarifications approved by the PCO, if any, will be maintained with contract documentation.

4. Subsequent TO/Data Requirements. When new TO requirements are identified the Contractor must notify the Government utilizing DI-TMSS-80067C, Technical Manual (TM) Contractor Furnished Aeronautical Equipment or Contractor Furnished Equipment (CFAE/CFE) Notices, or approved Contractor formats. This process must require Government review and approval of recommended additional requirements prior to developing additional data. When approved, the Contractor must incorporate the requirements within the Technical Manual Content and Product Plan where applicable.

5. TO Development. TOs must be written to a scope and depth of coverage to support the HH-60W DVES TMCR operations and maintenance concepts.

5.1. TO data must be developed IAW ASD/AIA S1000D, International Specification for Technical Publications Utilizing a Common Source Database, and MIL-STD-3048, Air Force Business Rules for the Implementation of S1000D. For S1000D, this includes program tailored functionality requirements and Project Business Rules when implemented. The Government tailored functionality requirements and Business Rule Decision Points for MIL-STD-3048 are included in the SIR found in Section 3 of this document. All delivered graphics must conform to the approved graphic creation and format guidelines listed in Attachment 1, Graphics Format Guidelines. If needed, the Contractor must contact the PCO and TOMA to request guidance from the Air Force PA, AFLCMC/GBS, Technical Data Section, 4170 Hebble Creek Rd, Bldg. 280, Door 15, WPAFB OH 45433-5653.

6. Data Rights. Contractors must comply with 10 U.S.C. 2320 and Defense Federal Acquisition Regulation Supplement (DFARS) provisions and clauses. The Government’s rights in technical data are specified in DFARS 252.227-7013, Rights in Technical Data-Noncommercial Items, 252.227-7014, Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation, and 252.227- 7015, Technical Data-Commercial Items and other applicable provisions and clauses from DFARS 227, 252.227, and DFARS 252.227-7018 Rights in Noncommercial Technical Data and Computer Software – Small Business Innovation Research (SBIR). In accordance with those clauses and provisions, the Contractor grants the Government Unlimited Rights, as defined therein, in all source data, TO publications, TO updates, and TO-related documents prepared specifically for the contract. The Contractor also grants the Government Unlimited Rights in all Government-funded business rules (tailoring and application methods and procedures) and documented business processes developed under the contract for the purpose of or for use in TO development. The contractor is required to deliver TO data with the data rights license required by the applicable DFARS clauses. Contractor must identify any data to be delivered to the Government with other than Unlimited Rights IAW DFARS 252.227-7017, Identification and Assertion of Use, Release, or Disclosure Restrictions and must mark such data only in accordance with the applicable DFARS clause. The Contractor must pass through and enforce all requirements in this TMCR to all sub-Contractors.

6.1. The Government shall have unlimited rights in technical data that are data pertaining to an item, component, or process which has been or will be developed exclusively with Government funds; studies, analyses, test data, or similar data produced for this contract, when the study, analysis, test, or similar work was specified as an element of performance; created exclusively with Government funds in the performance of a contract that does not require the development, manufacture, construction, or production of items, components, or processes; form, fit, and function data; necessary for installation, operation, maintenance, or training purposes (other than detailed manufacturing or process data);

corrections or changes to technical data furnished to the Contractor by the Government; otherwise publicly available or have been released or disclosed by the Contractor or subcontractor without restrictions on further use, release or disclosure, other than a release or disclosure resulting from the sale, transfer, or other assignment of interest in the technical data to another party or the sale or transfer of some or all of a business entity or its assets to another party; data in which the Government has obtained unlimited rights under another Government contract or as a result of negotiations; or data furnished to the Government, under this or any other Government contract or subcontract thereunder, with Government purpose license rights or limited rights and the restrictive condition(s) has/have expired; or Government purpose rights and the Contractor's exclusive right to use such data for commercial purposes has expired.

7. Classification, Distribution, Destruction, Disclosure, Export Control Notices, and Cyber Security.

Contractors must recommend the correct markings and controls for classified and restricted distribution data and TOs IAW the program’s Security Classification Guide and Department of Defense Manual (DODM) 5200.01V2 AFMAN 16-1404V2, Department of Defense Instruction (DODI) 5230.24, Department of Defense Directive (DODD) 5230.25, DoDI 5200.48, Controlled Unclassified Information, DAFI 61-201, Management of Scientific and Technical Information (STINFO), and MIL-STD-38784 (available at https://www.esd.whs.mil/dd/dod-issuances/, http://www.e-publishing.af.mil/ or https://quicksearch.dla.mil/qsSearch.aspx). The markings and notices must be reviewed during In-Process Reviews (IPR). The Contractor must also apply policy and procedures for Cybersecurity Program Management IAW AFI 17-130, AFMAN 17-1301, Computer Security (COMPUSEC) https://www.esd.whs.mil/dd/dod-issuances/ http://www.e-publishing.af.mil/ https://quicksearch.dla.mil/qsSearch.aspx

NOTE: Distribution limitations will be determined on a case-by-case basis as TOs are developed, dependent upon TO content.

8. TO Quality. The Contractor must ensure prepared TOs are: a) technically accurate and safe; b) written to a scope and depth of coverage to support the operations and maintenance concepts; c) properly classified and marked with export control and distribution limitation statements. The Contractor must maintain a Technical Manual Quality Assurance (TMQA) Program Plan for this effort. The TMQA Program Plan must be available for review at the TO Guidance Conference. The TMQA Program Plan must be sufficiently detailed to support TO certification to include actual performance of procedures or desk-top analysis for non-procedural data. Simulation (walk-through/talk-through) should be reserved for those procedures which would activate explosive devices or present a hazard to personnel or equipment.

8.1. Initial Technical Order Guidance Conference (TOGC). Working through the TOMA, the Contractor must co-host and participate in a guidance conference for this effort. The TOGC will be held within 60 calendar days after contract award. The Technical Manual Schedule and Status will be formalized at this conference. The Contractor must present a briefing on their interpretation of the basic contract, SOW/Performance Work Statement, CDRLs, Data Item Descriptions (DIDs), MIL-SPEC, MIL-DTL, MIL-STD, SIRs, this document and the planned preparation and delivery of the TOs and related data.

The Contractor must also provide their S1000D Technical Manual Content and Product Plan for review and approval.

8.2. In-Process Reviews. The Contractor must participate and co-chair In-Process Reviews (IPR) of the data developed for this effort IAW the TOMA-provided IPR checklists. In-Process Reviews are to ensure that data being developed as part of this effort is adequate and accurate and IAW contract requirements and cited specifications. The Contractor must ensure that all appropriate personnel required to execute a successful TO program will either attend or participate in the IPR. IPRs will be held IAW with TO 00-5-3 or as defined by the program office. During the IPRs the Contractor will be responsible to maintain a master markup or documented list of approved changes for the content being reviewed.

The Contractor must develop meeting minutes after each review documenting all approved changes and concurrent agreements for Government review and approval. This master markup or documented list of approved changes will be made available at the next scheduled review. A copy of the markup will be provided to the TOMA or designated individual at the conclusion of the review. The Contractor must ensure all comments from previous IPRs have been incorporated prior to the next scheduled IPR. With prior approval of the TOMA, IPRs may be combined.

8.3. TO Delivery Requirements for In-Process Reviews. IPR TO data must be technically edited and reviewed according to the TMQA Program Plan. Manuscript (handwritten) data is not acceptable for any data to be reviewed. The TMQA Program Plan checklists must be available for review by the Government during the IPRs. IPRs subsequent to the initial review may be accomplished using the approved IETM viewing presentation system and as specified within the Government provided IPR checklist. Delivery requirements are contained in Section 2 of the TMCR.

8.4. TO Certification. The Contractor must certify that new TO procedures and data developed to support the program are safe, accurate, adequate, current, and usable for their intended purpose. The Government may witness the certification activities. The Contractor must incorporate comments generated by the certification process into the TOs prior to submitting the TOs for verification. At the completion of the certification, the Contractor must submit a letter to the TOMA through the Government PCO and PM stating that certification has been completed, the certification method used, and that any deficiencies identified during the process have been corrected. The Contractor will ensure all necessary changes and corrections to affected manuals are accomplished in time to meet contract delivery schedule requirements. The Contractor must notify the Government, as identified in the contract, at least 180 days prior to the need date, of any Government Furnished Property (GFP), Government Furnished Information (GFI), and/or Government Furnished Equipment (GFE) as required, to perform certification tasks.

Technical Order 00-5-1 and 00-5-3 must be referenced for additional information on TO certification requirements.

8.4.1. The Contractor must propose opportunities to perform TO certification activities in conjunction with Government verification IAW TO 00-5-3, where applicable.

8.5. Verification Support. The Contractor must support Government verification activities as required by the TOMA and the program Technical Order Life Cycle Verification Plan (TOLCVP). Contractor verification support will consist of on station technical writing and engineering support. The Contractor must maintain a master mark-up of the TM or list of approved changes and record meeting-minute items during the Government verification process. The Contractor must also support all post verification reviews and ensure availability until 100% task verification is attained by the Government.

8.5.1. Verification of IETMs requires unique processes and procedures to verify the content.

Verification results can be incorporated using traditional pre-publication review methods or updated in real-time during the verification. The Contractor must provide technical support and common source database maintenance personnel required for changes resulting from verification.

8.6. TO Prepublication Reviews (PPR). PPRs are examinations of TOs that ensure incorporation of agreed upon changes from previous reviews and verification activities. The Contractor must prepare and deliver copies of TOs and TO updates in contract compliance for the PPR as shown in the delivery matrix.

The TOs for PPR must be approved by the Contractor’s QA, be in compliance with the contract specification/DTLs/STDs, and incorporate all verification comments and corrections approved by the TOMA or program management office representative.

8.7. Technical Data Assessment (TDA). The Contractor must submit in-work samples of each specified TM type deliverable to the Government for specification and standardization compliance review. TDAs may be accomplished by using organic TO sustainment environments with the assistance of AFLCMC/GBS (AF TMSS Office, SGMLSUPPORT@us.af.mil).

8.7.1. S1000D (XML) Data Files. The Contractor must submit S1000D XML tagged DMs, all layered BREX and all referenced graphics for assessment. During assessment, these DMs will be evaluated against the TMSS S1000D Validation Tool to parse/validate each DM to confirm all submitted DMs are S1000D compliant.

8.7.2. Error Resolution. The Contractor must correct any errors found during the TDA prior to each IPR. Additional TDAs may be necessary based on the amount of errors found during the initial TDA.

Completion of a TDA in no way relieves the Contractor from the requirement to fix errors found during future reviews.

9. TO Delivery. TO file delivery requirements are located in Section 2 of this document.

9.1. S1000D Source Files. The Contractor must parse and deliver everything necessary to properly generate and view the data in the approved IETM viewer or produce the desired presentation to the user.

This includes all DMs, database files, BREX, XSL, cascading style sheets (CSS), conversion scripts (such as Java or Perl), graphics, XML, viewer software, referenced HTML/PDF files, native source data files, process and training documentation, etc.

9.2. MIL-SPEC (SGML) Tagged Files. The Contractor must parse all SGML files required for the TOs prior to Government delivery and must verify the SGML is compliant with the appropriate DTD.

9.3. Modified Flight Manual (MFM). In addition to TOs delivered IAW Section 2 Table 5, the Contractor must deliver an approved 80% level MFM (if required) to support Developmental Testing

(DT).

NOTE: Contractors will protect GFI provided for the purposes of TO development IAW DFARS 252.204- 7000 Disclosure of Information and DFARS 252.227-7025, Limitations on the Use or Disclosure of Government Furnished Information Marked with Restrictive Legends.

10. Schedules. The Contractor must develop and maintain an Integrated Technical Manual Schedule and Status throughout the period of performance for all TO development activities associated with this order for the life of the contract. The schedule must be to the system/book or TCTO level and cover all major milestones of development. Any changes to the Integrated Technical Manual Schedule and Status after the TO Guidance Conference must be coordinated with and approved by program TOMA and PCO.

11. Time Compliance Technical Orders (TCTOs). The Contractor must prepare TCTOs, ITCTOs and resulting TO updates as required in support of HH-60W DVES TMCR IAW TO 00-5-15 and MIL-DTL- 38804 content requirements. TCTOs will be used to document all permanent modifications, initiate special “one time” inspections, or impose temporary restrictions on systems or equipment within specified time limits effecting HH-60W DVES TMCR. Costs for TCTO package development must be IAW with DAFI 65-601Vol.1.

11.1. The Contractor must deliver routine TCTO final drafts with “final” customer comments incorporated, within 5 working days of receipt of comments.

SECTION 2. TM TYPE AND DELIVERY REQUIREMENTS

TECHNICAL MANUAL TYPE SELECTION TABLES.

TABLE 1

TMSS REQUIREMENTS FOR THE HH-60W DVES TMCR Program

Title or Type of Manuals Specification Required

1. Time Compliance Technical Orders (TCTOs) MIL-DTL-38804

a. TCTO ☒

2. Illustrated Parts Breakdown MIL-DTL-38807 ☒

3. On-Equipment Organizational Maintenance Manual Set MIL-DTL-83495

a. Wiring Data (WD) Manual ☒

4. Operation and Maintenance Instructions in Work Package Format MIL-DTL-87929

a. Maintenance Manuals

1) Organizational Maintenance ☒

2) On Condition Maintenance ☒

b. With Illustrated Parts Breakdown ☒

TABLE 2

SUSTAINMENT/MODIFICATION UPDATES TM TYPE SELECTIONS

NOTES:

• Check all applicable boxes.

• For existing manuals not being updated to latest specification requirements, enter “Same style and format” under the specification heading.

TO Number, Title, or Type of Manual

Specification

Change

Revision

Supple-ment mental

TM

Source Data

1. 1H-60(H)W-2 MIL-DTL-38804

TABLE 3

TABLE 3 – S1000D TM DELIVERY REQUIREMENTS

FOR HH-60W DVES TMCR

• For all other media types indicate (Y)es or (N)o

• TCTO requirements are specified in the contract vehicle approving the TCTO.

DELIVERY SCHEDULE

Enter physical mailing address, electronic delivery location or web access point

2240 B Street Building 11, 1st Floor, Room 130 Wright-Patterson AFB, OH 45433

Event Number of calendar days data required prior to event

PDR

(Preliminary

Design Review)

CDR

(Critical Design

Review)

In Process Review(s) Verification Prepublication

Review Final

Delivery

( 30 Days) ( 30 Days) ( 30 Days) ( 30 Days) ( 30 Days)

Deliverable Common Source Data Base (CSDB)

Business Rules Exchange (BREX) files

Data Management Requirements List

(DMRL)

Stylesheets Output Generation Tools/Files

Multimedia Files

Graphic Files

Authoring Guide(s) Technical Manual Content and Product Plan

Configuration Control Management Plan

TECHNICAL MANUAL TYPE SELECTION TABLES.

TABLE 4

TMSS REQUIREMENTS FOR THE HH-60W DVES TMCR Program

Title or Type of Manuals Specification Required

1. Flight Operation Manuals MIL-DTL-7700

Flight Manuals

a. Flight Manual

b. Mission Crew Manual and Associated Checklists ☒

c. Abbreviated Flight Crew Checklist ☒

d. Acceptance and Functional Check Flight (FCF) Procedures (-6CF)

Manual ☒

e. Acceptance and Functional Check Flight (-6CL) Checklist ☒

Weight and Balance (Aircraft)

a. Loading Data Manual ☒

TABLE 5

SUSTAINMENT/MODIFICATION UPDATES TM TYPE SELECTIONS

• Check all applicable boxes.

• For existing manuals not being updated to latest specification requirements, enter “Same style and format” under the specification heading.

TO Number, Title, or Type of Manual

Specification

Change

Revision ment mental

TM

Source Data

1. 1H-60(H)W-1 MIL-DTL-7700

2. 1H-60(H)W-1CL-1 MIL-DTL-7700

3. 1H-60(H)W-1CL-2 MIL-DTL-7700

4. 1H-60(H)W-5-1 MIL-DTL-7700

5. 1H-60(H)W-5-2 MIL-DTL-7700

6. 1H-60(H)W-6CF-1 MIL-DTL-7700

7. 1H-60(H)W-6CL-1 MIL-DTL-7700

TABLE 6 – SGML/XML TM DELIVERY REQUIREMENTS

FOR HH-60W DVES TMCR

• For Paper and CD/DVD media delivery indicate required quantity

• For all other media types indicate (Y)es or (N)o

• TCTO/SB requirements are specified in the contract vehicle approving the TCTO/SB.

• All SGML/XML file delivers MUST include ALL graphic files.

• All TO files must not be password protected.

DELIVERY SCHEDULE

Event Number of calendar days data required prior to event In Process Review(s) (30 Days)

Verification

Prepublication Review

Final TO Delivery

Enter physical mailing address, electronic delivery location or web access point

DoD Safe Paper/ 0

SGML/ N

(I)PDF / Y

XML / N

CD-DVD/ 0

Paper/ 0

CD-DVD/ 0

CD-DVD / 0

SGML/ Y

CD-DVD / 0

SECTION 3. SPECIFICATION/STANDARD INTERFACE RECORDS (SIRS)

• All TMSS applicable to this contract must have an appropriately tailored SIR attached to this section.

• SIRs included in the untailored TMCR format represent the minimum tailoring requirements that must be included in the final contract, unless the entire SIR is not applicable; e.g., if MIL-DTL-22202D is not required, the entire SIR can be deleted.

• Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available from Acquisition Streamlining and Standardization Information System (ASSIST) web page, https://assist.dla.mil/online/start/index.cfm.

• TMSS entries designated with A, F, M or N refer to Army, Air Force, Marine Corps or Navy requirements.

• Comments (recommendations, additions, deletions) and any pertinent data which may be in use in improving Air Force

TMSS documents should be submitted to AFLCMC/GBS 4170 Hebble Creek Road, Bldg. 280, Door 15, Area A, Wright- Patterson AFB, Oh 45433-5653 or by email to; SGMLsupport@us.af.mil. Do not include the street address, a building number or a zip+4.

https://assist.dla.mil/online/start/index.cfm mailto:SGMLsupport@us.af.mil

ATTACHMENT 1

Graphics Format Guidelines

GUIDELINES:

Computer Graphics Metafile (CGM):

• Raster based images will not be saved as CGM.

• Any source data used in aiding of creation of CGM (templates, etc.) will be deleted from illustration prior to saving/exporting.

• CGM files must not be a mix of vector and raster images. Vector only.

• If multiple layers are used, then image is to be flattened into 1 single layer before exporting to minimize file size and reduce possible printing issues.

• Unless Version 4 is specifically required for hotspots and/or hyper linking, CGMs should be exported as version 3 to increase cross platform compatibility.

Annex 1

TECHNICAL ORDER S1000D PROJECT BUSINESS RULES

This section outlines the USAF PD BRs for HH-60W TOs. Each HH-60W PD BR is preceded by a section number and Header (i.e. 3.1 Information Generation – Introduction) which is directly traceable to the MIL- STD-3048 and International S1000D Standards. For the ease of cross referencing the PDs to the MIL-STD- 3048, the actual USAF PD BR designator precedes the BR definition, ex. AF 3.1-001 or PD 3.1-001. In addition, each CRH PD BR will include the applicability to CRH and its definition. The CRH PD BRs are written as found in MIL-STD- 3048 and include the section references listed in parenthesis preceding each BR, (e.g., (5.3.1.1.1) Information sets for new air projects.)

The annotation “No PD business rules” only denotes no action is required from the program. The section that uses this statement may have a USAF business rule and/or a DoD business rule assigned. It is the contractor’s responsibility to ensure all DoD and USAF business rules are addressed in addition to the CRH PD BRs.

3.1 Information Generation – Introduction

No PD business rules.

3.2 Information Generation – Data Modules

3.3 Information Generation – Information Sets

PD 3.3-001 Decide and agree on definitions for CE and legacy projects information sets.

(5.6.2.1) Definitions for Common Equipment (CE) and legacy projects

PROJECT RULE: Common Equipment (CE) shall be identified as interoperable devices that currently exist in the USAF inventory. CE is required to support and maintain a system or end item in its intended environment and have the capability to support a variety of weapon system requirements. The CRH program does not anticipate use of legacy project information sets.

3.4 Information Generation – Zoning and Access

PD 3.4-001 Decide whether to use zoning and access.

(5.7.2.1) Using zoning and access

PROJECT RULE: The CRH program shall use S1000D zoning and access as described in S1000D Chapter 3.4.

PD 3.4-002 Decide which method to use for zoning. (5.7.2.2) Methods for zoning PROJECT RULE: The CRH program shall use Method C for aircraft zoning as described in S1000D Chapter 3.4.

PD 3.4-003 Decide which method to use for identifying access points. (5.7.2.3) Identification access points PROJECT RULE: The CRH program shall use Method 1 for identifying access points as described in S1000D Chapter 3.4.

3.5 Information Generation – Zoning and Access

3.6 Information Generation – Security and Data Restrictions

3.7 Information Generation – Quality Assurance

PD 3.7-001 Decide on a set of rules for applying table top, on object or both.

(5.3.5.2.1) Decide whether first verification rules apply

PROJECT RULE: The CRH program shall use a combination of table top and on-object methods of verification.

The AF Program Manager and Technical Order Management Agency (TOMA), with coordination from the CRH contractor, shall identify data module verification rules.

For CRH TOs “first verification” is considered certification as described in AF TO 00-5-3. First verification will be carried out by the CRH contractor as defined in the CRH TMCR.

PD 3.7.002 Decide on the extent to which Quality Assurance (QA) is applied.

(5.10.2.3) Degree of Application PROJECT RULE: QA shall be implemented and applied as described in CRH TMCR and AF TO 00-5-3.

Specific processes and procedures covering the extent of CRH TO QA will be formally documented in the CRH Technical Order Verification Plan (TOVP) as mandated in AF TO 00-5-3.

PD 3.7-003 Decide and agree on the application of second verification.

(5.3.5.2.3) Application of second verification PROJECT RULE: For CRH TOs “Second verification” is considered verification as described in AF TO 00-5-3.

Second verification will be carried out by the USAF with contractor support as defined in the CRH TMCR.

3.8 Information Generation – Disassembly Principles

3.9 Information Generation – Authoring

3.9.1 Authoring – General Writing Rules

PD 3.9.1-001 Decide whether to use Simplified English (ASD STE 100).

(5.11.2.1) Use of Simplified English PROJECT RULE: The CRH program shall not make use of Simplified English for CRH technical data.

Requirements contained in CRH TMCR shall be referenced for Reading Grade Level (RGL) and relevant language requirements.

PD 3.9.1-002 In order to achieve and maintain consistency for names of hardware and software related to the project, decide whether to develop a terminology database or glossary.

(5.11.2.2) Terminology database or glossary PROJECT RULE: A Terminology database shall be used as described in S1000D chapter 3.9.1. Maintenance terminology will be determined by the CRH Technical Order IETM Integrated Product Team (IPT).

3.9.2 Authoring – Illustration and Multimedia

PD 3.9.2-001 Decide which parts of the deliverable needs to be printable.

(5.12.2.1) Scope of printable data PROJECT RULE: All CRH technical data shall be capable of being printed as identified in the CRH TMCR.

Flight manual TOs shall be able to be easily printed as compete TOs.

Maintenance procedures, maintenance data modules, or IETM process printing shall be printed to relevant TMCR military specifications and contain specific disposition instructions.

PD 3.9.2.002 Decide and agree which multimedia technologies can be used in certain environments.

(5.12.2.2) Multi-media technologies and environment PROJECT RULE: Types of multi-media allowed are defined in the CRH TMCR. Selected multimedia technologies must be capable of being displayed for all CRH TOs. Normal environmental operational ranges of the CRH aircraft vary from arctic to desert conditions. Refer to the CRH aircraft system specification for aircraft and IETM environmental operating conditions.

3.9.2.1 Illustration rules and multimedia – Illustrations, General PD 3.9.2.1-001 Decide whether schematics derived from engineering drawings should include the original drawing number and revision status within the illustration reproduction area.

(5.13.2.1) Engineering numbers and revision status PROJECT RULE: CRH illustrations shall contain the unique art file number associated with each illustration within the reproduction area. CRH illustrations will not contain any engineering source data numbers or revision status information within the reproduction area.

3.9.2.2 Illustration rules and multimedia – Navigation and Configuration No PD business rules.

3.9.2.3 Illustration rules and multimedia – Use of Color and Photographs No PD business rules.

3.9.2.4 Illustration rules and multimedia – Multimedia, General No PD business rules.

3.9.2.5 Illustration rules and multimedia – Interactive 3D Content

3.9.2.6 Illustration rules and multimedia – E-Learning and SCORM

3.9.3 Authoring – Warnings, Cautions, and Notes

PD 3.9.3-001 Decide whether to use the collection of warnings and cautions for multiple occurrences within the data module.

(5.17.2.1) Use of the collection of warnings and cautions PROJECT RULE: The use of warning and caution collections for multiple occurrences within a data module is allowed.

3.9.4 Authoring – Front Matter

3.9.5 Authoring – Data Modules

3.9.5.1 Data Modules – Identification and Status Section

PD 3.9.5.1-001 Decide and agree on a data module coding strategy.

(5.19.2.1) Data module coding strategy PROJECT RULE: CRH shall use an alphanumeric character data module coding structure (element <dmCode>).

To the maximum extent, use the smallest code possible as long as it does not interfere with other BRs.

PD 3.9.5.1-002 Decide whether to allow the exchange of draft data modules between the supplier and the customer.

(5.19.2.2) Exchange of draft data modules within the project PROJECT RULE: For CRH, the exchange of draft data modules is allowed.

PD 3.9.5.1-003 Decide on the source of the technical names (preferably a terminology database) and use them consistently. In all cases, the technical name shall reflect the item represented by the Standard Numbering System (SNS).

(5.19.2.3) Source of the technical names

PROJECT RULE: The CRH program shall use the numbering system contained in MIL-STD-1808. The technical names, and its corresponding System, Sub-system, Sub-sub system, Number (SSSN), shall be used. This will be information used to populate the element <techName>. Technical names will be linked with PD 3.6-002.

PD 3.9.5.1-004 Decide whether to create and maintain a list of CAGE codes for the responsible partner company and originator.

(5.19.2.4) List of CAGE codes PROJECT RULE: CAGE codes shall be created and sustained for all CRH IETM/TO data.

3.9.5.1.1 Identification and Status Section – Export Control

3.9.5.2 Data Modules – Content Section

3.9.5.2.1 Content Section – Common Constructs

3.9.5.2.1.1 Common Constructs – Change Marking

3.9.5.2.1.2 Common Constructs – Referencing

PD 3.16-001 Decide on the use of the attribute referred Fragment. The project shall state in the business rules when referred Fragment will be used and shall list the precautions if it is used.

(5.3.16.2.1) Use and Format of the attribute referred Fragment of element <dmRef> PROJECT RULE: CRH shall use the attribute referred Fragment. Linking to elements within the data modules is allowed.

3.9.5.2.1.3 Common Constructs – Lists

3.9.5.2.1.4 Common Constructs – Caption Groups

3.9.5.2.1.5 Common Constructs – Titles

3.9.5.2.1.6 Common Constructs – Tables

3.9.5.2.1.7 Common Constructs – Figures and Foldouts

3.9.5.2.1.8 Common Constructs – Hotspots

3.9.5.2.1.9 Common Constructs – Preliminary requirements and Requirements after Job completion 3.9.5.2.1.10 Common Constructs – Text Elements

PD 3.9.5.2.1.10-001 Decide which types of quantity data to use in what contexts and whether to extend the list of types.

(5.27.2.1) Types of quantity data PROJECT RULE: CRH shall utilize quantity data. Refer to PD 3.9.5.2.1.10-002 PD 3.9.5.2.1.10-002 Decide whether to use quantity data markup and to what extent it is used. (5.27.2.2) Level of implementation

PROJECT RULE:

Quantity Data Types and Units of Measure

Voltage Units of Measure Unit of Measure S1000D Assigned Attribute

Value Volt V Millivolt mV

Volt

The S1000D specification does not does not define AC volts and DC volts as separate values for the quantity tag set, only "V" as volts in general. We recommend that VAC and VDC be defined as project specific values, using values "um51" and "um52". Also need to define if these should be displayed in upper case, or lower case, as well as if they should be represented as VDC/VAC (vdc/ vac) or V DC/ V AC (v dc/v ac)

Resistance Units of Measure Unit of Measure S1000D Assigned Attribute Value Ohms ohm Megaohms M ohm Milliohms mohm Capacitance Units of Measure Unit of Measure S1000D Assigned Attribute Value Microfarad uF Picrofarad Pf Current / Amperage Units of Measure Unit of Measure S1000D Assigned Attribute Value Milliamps mA Ampere A Torque Units of Measure Unit of Measure S1000D Assigned Attribute Value Inch-pounds lbf.in Foot pounds ft.lbf

Inch-Pounds Markup Example <para>Torque nut to <quantity> <quantityGroup quantityUnitOfMeasure="lbf.in">

<quantityValue>10</quantityValue> </quantityGroup> </quantity>.</para>

Possible print/screen display of markup Torque nut to 10 inch-pounds. Foot-pounds

Foot Pounds Markup Example

<para>Torque bolts to quantity><quantityGroup quantityUnitOfMeasure="ft.lbf"><quantityValue>100</quantityValue>

</quantityGroup></quantity>.</para>

Torque bolts to 100 foot-pounds.

Velocity / Acceleration Units of Measure

Miles Per Hour (MPH) mi/h Revolutions Per Minute (RPM) rev/min

Feet / second squared (FT/Sec2) ft/s2

Knot knot

Miles Per Hour (MPH) Markup Example

<para>Speed of <quantity> <quantityGroup quantityUnitOfMeasure="mi/h"> <quantityValue>160</quantityValue> </quantityGroup> </quantity> was recorded during test.</para>

Print/screen display of markup Speed of 160 miles per hour was recorded during test.

Revolutions Per Minute (RPM)

<para>The engine has a maximum speed of <quantity> <quantityGroup quantityUnitOfMeasure="rev/min"> <quantityValue>15000</quantityValue> </quantityGroup> </quantity> .</para>

The engine has a maximum speed of 15000 RPM .

Feet / second squared (FT/Sec2)

<para>Maximum rate of acceleration is <quantity> <quantityGroup quantityUnitOfMeasure="ft/s2"> <quantityValue>100</quantityValue> </quantityGroup> </quantity>. </para>

Maximum rate of acceleration is 100 ft/sec2.

Knot

<para>Maximum rate of acceleration is <quantity><quantityGroup quantityUnitOfMeasure="ft/s2"><quantityValue>100</quantityValue>

</quantityGroup></quantity>. </para>

Maximum rate of acceleration is 100 ft/sec2.

Linear Units of Measure

Feet ft Inches in Miles (Statute) mi Miles (Nautical) nautmi Yard yd

Temperature Units of Measure

Degrees Fahrenheit degF Degrees Kelvin K Degrees Deg Celsius C Pressure/Stress Units of Measure Unit of Measure S1000D Assigned Attribute Value Inches of Water at 39.2 deg F psi psig inH2O(39.2F)

Inches of Water at 60 deg F inH2O(60F) Inches of Hg at 32 deg F inHg(32F) Inches of Hg at 60 deg F inHg(60F) Pounds per square inch (PSI) psi

Pounds per square inch gauge psig Pounds per square inch differential (PSID)

S1000D has no assigned value for this unit of measure. Recommend usage of ‘um53’

Volume Units of Measure

Cubic inches (in3) in3 Cubic feet (ft3) cu ft

Ounce (US fluid) fl ozUS Pint (US fluid) ptUS Quart (US fluid) qtUS Gallon (US fluid) galUS Area Units of Measure Unit of Measure S1000D Assigned Attribute Value Square inches (in2) In2 Square feet (ft2) Sq ft Square yard (yd2) Yd2 Weight (Mass)Units of Measure Unit of Measure S1000D Assigned Attribute Value Ounce Ozm Gram g Pound lbm Ton tonUS Sound Units of Measure Unit of Measure S1000D Assigned Attribute Value Decibel dB Force Units of Measure Unit of Measure S1000D Assigned Attribute Value Ounce ozf Pound lbf Frequency Units of Measure Unit of Measure S1000D Assigned Attribute Value Hertz Hz Kilohertz kHz Megahertz MHz Millihertz mHz

PD 3.9.5.2.1.10-003 If using the value and tolerance decomposition, decide at which level of the markup that the unit of measure is to be applied.

(5.27.2.3) Use of unit of measure

Markup example <para> <quantity> <quantityGroup quantityUnitOfMeasure="ft.lbf"> <quantityValue>10</quantityValue> <quantityTolerance quantityToleranceType="plusorminus" quantityUnitOfMeasure="ft.lbf">2</quantityTolerance> </quantityGroup>

</quantity>.</para>

Torque bolts to 10 ± 2 foot pounds.

Another markup example <para>Torque bolts to <quantity> <quantityGroup quantityUnitOfMeasure="ft.lbf"> <quantityValue>10</quantityValue> <quantityTolerance quantityToleranceType="plus">2</quantityTolerance> <quantityTolerance quantityToleranceType="minus">4</quantityTolerance> </quantityGroup> </quantity>.</para>

Torque bolts to 10 + 2, - 4 foot pounds.

Example of minimum / maximum torque range Markup example <para>Torque bolts to <quantity> <quantityGroup quantityGroupType="minimum" quantityUnitOfMeasure="ft.lbf"> <quantityValue>8</quantityValue> </quantityGroup> <quantityGroup quantityGroupType="maximum" quantityUnitOfMeasure="ft.lbf"> <quantityValue>12</quantityValue> </quantityGroup> </quantity>.</para>

Torque bolts to 8 - 12 foot-pounds.

PD 3.9.5.2.1.10-004 If using the value and tolerance decomposition, decide which unit of measure types to allow and whether to extend the list of types.

(5.27.2.4) Types of unit of measure PROJECT RULE: See PD 3.9.5.2.1.10-003

3.9.5.2.1.11 Common Constructs – Controlled Content

3.9.5.2.1.12 Common Constructs – Common Information

3.9.5.2.2 Content Section – Descriptive Information

PD 3.9.5.2.2-001 Decide on the granularity of descriptive data modules.

(5.30.2.1) Granularity

PROJECT RULE: Descriptive data modules shall be tagged at a level which reflects the minimum level of reusable content to support display of ETM and IETM information. Use of System/Subsystem/Sub-Subsystem levels shall be followed to determine granularity of descriptive data modules when not in conflict with display of ETM or IETM information.

3.9.5.2.3 Content Section – Procedural Information

3.9.5.2.2.4 Content Section – Fault Information

PD 3.9.5.2.2.4-001 Decide whether and how to use the correlated fault concept. (5.32.2.1) Correlated fault concept

PROJECT RULE: The CRH IETM shall use correlated fault messages and warnings to detect and display fault information via the IETM.

<correlatedFault id="CFS0001"> <basicCorrelatedFaults> <bitMessage> <fault faultCode="100FC01"/> <faultDescr> <descr>Engine Inlet jammed</descr>

</faultDescr> </bitMessage> <bitMessage> <fault faultCode="200FC01"/> <faultDescr> <descr>Unusual Engine noise</descr> </faultDescr> </bitMessage> </basicCorrelatedFaults> <isolateDetectedFault> Applicable to: All S1000D-A-03-09-0502-04A-040A-A Chap 3.9.5.2.4 DMC-S1000D-A-03-09-0502-04A-040A-A_006-00_EN-US.doc 2008-08-01 Page 24 S1000D-I9005-01000-00 <lruItem> <lru> <name>Engine</name> <identNumber> <manufacturerCode>KZ120</manufacturerCode> <partAndSerialNumber> <partNumber>Inlet-120</partNumber> </partAndSerialNumber> </identNumber> </lru> </lruItem> </isolateDetectedFault> <remarks> <simplePara> Disconnect No. 1 engine yellow cable connector W4P1 from connector J2 on No. 1 engine DEC. </simplePara> </remarks> </correlatedFault>

3.9.5.2.5 Content Section – Maintenance planning

information PD 3.9.5.2.5-001 Decide which tasks belong to which groups. (5.33.2.1) Task groupings PROJECT RULE: CRH shall capture the maintenance planning information by utilizing the four types of maintenance schedule data modules: time limits, task definitions, inspection definitions, and maintenance allocation.

PD 3.9.5.2.5-002 Decide how to sequence the tasks.

(5.33.2.2) Task sequence PROJECT RULE: Tasks shall be sequenced in the most logical order for the procedure.

3.9.5.2.6 Content Section – Crew/Operator Information

PD 3.9.5.2.6-001 Decide whether to use the element <crewRefCard>.

(5.34.2.1) Use of the reference information branch PROJECT RULE: The use of the element <crewRefCard> is allowed for CRH.

3.9.5.2.7 Content Section – Parts Information

3.9.5.2.8 Content Section – Battle Damage Assessment and Repair Information

3.9.5.2.9 Content Section – Wiring Data

3.9.5.2.9.1 Wiring Data – Wire Data Schema Basic Rules

3.9.5.2.9.2 Wiring Data - Wire

3.9.5.2.9.3 Wiring Data - Harness

3.9.5.2.9.4 Wiring Data – Electrical Equipment

3.9.5.2.9.5 Wiring Data – Standard Parts, Connector

3.9.5.2.9.6 Wiring Data - Standard Parts, Distribution Part

3.9.5.2.9.7 Wiring Data - Standard Parts, Accessory

3.9.5.2.9.8 Wiring Data - Standard Parts, Solder Sleeve

3.9.5.2.9.9 Wiring Data - Standard Parts, Shrink Sleeve

3.9.5.2.9.10 Wiring Data - Standard Parts, Identification Sleeve

3.9.5.2.9.11 Wiring Data - Standard Parts, Conduit

3.9.5.2.9.12 Wiring Data - Standard Parts, Wire Material

3.9.5.2.9.13 Wiring Data - Wiring Data Description Schema Basic Rules

3.9.5.2.10 Content Section – Process data module

PD 3.9.5.2.10-001 Decide the level at which to apply applicability for context filtering purposes.

(5.38.2.1) Level of context filtering PROJECT RULE: The CRH shall utilize context filtering associated with aircraft serial numbers, for conditional circumstances of maintenance, i.e. Procedure A is applicable only under these circumstances, for power on or off situations, and any other circumstance which may branch out into multiple conditional situations.

PD 3.9.5.2.10-002 Decide whether to use the applicability Model structure for configuration items and applicability expressions for dynamic variables only or use the applicability expressions for both configuration items and dynamic variables.

(5.38.2.2) Model structure or expression PROJECT RULE: CRH can use applicability expressions for both configuration items and dynamic variables.

PD 3.9.5.2.10-003 Decide on the method of tagging the variables being passed using element <receiveByName> or element <receiveByPosition> when more than one person, company, or program will be creating an external application call to the same application.

(5.38.2.3) Method of tagging variables

PROJECT RULE:

CRH shall use both the elements <receiveByName> and <receiveByValue> Part Ordering Interface - Value by Name

<!—Receive Value by Name: This is a unidirectional message push (with only a status of the message being received being returned as a integer. 0 = success, anything else is an error.

<externalApplication application="POI"> <paraBasic>Part Ordering Interface</paraBasic> <send> <sendName>mcn</sendName> <stringValue>00PSQAA</stringValue> </send> <send> <sendName>tec</sendName> <stringValue>AHXD</stringValue> </send> <send> <sendName>cageNumber</sendName> <stringValue>78286</stringValue> </send> <send> <sendName>partNumber</sendName> <stringValue>ADC-34700X</stringValue> </send> <send> <sendName>nomen</sendName> <stringValue>No. 1 Air Data Computer</stringValue> </send> <send> <sendName>qty_ord</sendName> <integerValue>1</integerValue> </send> <send> <sendName>repairable</sendName> <stringValue>Y</stringValue> </send> <send> <sendName>user</sendName> <stringValue>maintA</stringValue> </send> <send> <sendName>timestamp</sendName> <stringValue>20141105214832Z</stringValue> </send> <receiveByName> <returnedValueName>status</returnedValueName> <variableRef variableName="ext.poi.iRtnStatus"/> </receiveByName> </externalApplication>

<!—Receive Value by Position:

Example of IETM launching the Plug Locator Application, sending the Reference Designator and in return getting the coordinates -- > <externalApplication application="PLA">

<paraBasic>Plug Locator Application</paraBasic> <send> <sendName>RefDes</sendName> <stringValue>P254</stringValue> </send> <receiveByPosition> <returnedValuePosition>1</ returnedValuePosition > <variableRef variableName="ext.pla.sStation"/> </ receiveByPosition > < receiveByPosition > < returnedValuePosition >2</ returnedValuePosition > <variableRef variableName="ext.pla.sWaterline"/> </ receiveByPosition > < receiveByPosition > < returnedValuePosition >3</ returnedValuePosition > <variableRef variableName="ext.pla.sButtline "/> </ receiveByPosition > </externalApplication>

PD 3.9.5.2.10-004 Decide whether to provide dialogs for variables in the variable declaration markup or author explicit dialogs whenever a variable in an expression might not have a value.

(5.38.2.4) Dialogs associated with variables

PROJECT RULE: For CRH, the use of dialogs for variables in the variable declaration markup or to enable for IETM functionality is allowed.

<process> <variableDeclarations> <!—e.g., “partnum” variable Explicit Dialogs: Declared variable is used via an explicit dialog box. As part of troubleshooting steps, dialog box is explicitly defined to get the value of the variable --> <variable valueType="string" variableName="partnum">

<!— e.g., “stepnum” variable Dialogs associated with variables: Dialog box is defined within the variable declaration. Anytime, this variable value is missing, the associated dialog will be displayed in IETM. Dialog box can be reused --> <variable valueType="string" variableName="stepnum"> <dialog> <dialogGroup> <dialogGroup> <menu> choiceSelection="single" choiceType="select">

<prompt> <paraBasic>Remove and check pin filtered adapter from P117</paraBasic> </prompt> </menu> <menuChoice> <prompt> <paraBasic>If pin filtered adapter is good </paraBasic> </prompt> <assertion> <variableRef variableName="stepnum"/>

<expression> <stringValue>2</stringValue> </expression> </assertion> </menuChoice> <menuChoice> <prompt> <paraBasic>If pin filtered adapter is not good, replace pin filtered adapter</paraBasic> </prompt> <assertion> <variableRef variableName="stepnum"/> <expression> <stringValue>7</stringValue> </expression> </assertion> </menuChoice> </dialogGroup> </dialogGroup> </dialog> </variable></variableDeclarations> <dmSeq> <dmNode> <dialog> <dialogGroup> <dialogGroup> <userEntry > <prompt> <paraBasic>Enter Part number</paraBasic> </prompt> <variableRef variableName=“partNum"/> </userEntry> <dialogGroup> </dialogGroup> </dialog> </process>

PD 3.9.5.2.10-005 Decide when to use menu or user entry type dialogs.

(5.38.2.5) Menu or user entry dialogs PROJECT RULE: For CRH, the use of both menu and user entry type dialogs is allowed. Rules for when to use menu or user entry type dialogs are as follows:

Menu Dialog <menu choiceSelection="single" choiceType="select">

<paraBasic>Remove and check pin filtered adapter from P117</paraBasic>

</prompt> <menuChoice> <prompt> <paraBasic>If pin filtered adapter is good</paraBasic>

<variableRef variableName=“stepNum"/> <expression> <stringValue>2</stringValue> </expression> </assertion> </menuChoice> <menuChoice>

<paraBasic>If pin filtered adapter is not good, replace pin filtered adapter</paraBasic>

<variableRef variableName=“stepNum"/> <expression> <stringValue>7</stringValue> </expression> </assertion> </prompt> <noAssertions/> </menuChoice> </menu>

User-Entry Dialog <userEntry> <prompt> <paraBasic>Enter Part number</paraBasic> </prompt> <variableRef variableName=“partNum"/> </userEntry> <userEntry dataEntryFieldLength="3"> <prompt> <paraBasic>Enter voltage</paraBasic> </prompt> <variableRef variableName=“vdcValue"/> <validate errorMessage=“Voltage value must be between 100 and 115"> </validate> </userEntry>

PD 3.9.5.2.10-006 Decide whether or not to use default choices in menus and/or default values in user Entry dialogs.

(5.38.2.6) Dialog defaults PROJECT RULE: CRH shall use of both default choices in menus and default values in user Entry dialogs as necessary to enable effective IETM use.

PD 3.9.5.2.10-007 Decide whether to use the element <proceduralStepAlt>.

(5.38.2.7) Use of alternatives PROJECT RULE: CRH shall use the element <proceduralStepAlt> to support CRH IETM use.

PD 3.9.5.2.10-008 Decide where and when to use the loop construct.

(55.38.2.8) Use of loops

PROJECT RULE: Decisions for where and when the loop construct will be used shall be decided by the CRH TO

IPT.

PD 3.9.5.2.10-009 Decide which entries in the dialog require responses and which have optional responses.

(5.38.2.9) Optional or mandatory entries in dialogs PROJECT RULE: The CRH TO IPT shall define and document a list of the entries that will have responses and those which are optional.

PD 3.9.5.2.10-010 Decide whether error messages are generated by the validation condition or author entered messages.

(5.38.2.10) User-Entry validates error messages PROJECT RULE: The CRH TO IPT shall define and document use of validation condition and author entered messages.

PD 3.9.5.2.10-011 Decide on the naming scheme for variables and typing.

(5.3.32.2.11) Variable naming and typing

PROJECT RULE: CRH shall develop a standardized naming scheme and…