SOW_Improved_ALRE_DAQ_System_FY18_RevD_vFedBid.docx

SOW for Improved ALRE DAQ FY2018 Rev C.

Statement of Work (SOW) Improved ALRE DAQ System Fiscal Year 2018 Revision D (April 18, 2018)

Author: Jon Lenskold (Code 4.8.9.5 Instrumentation Engineering Team Leader and Technical POC) Jon.lenskold@navy.mil 732-323-7057

Rodney Moss (Code 4.8.9.5 Branch Head) 732-323-7854 Jay.moss@navy.mil Contents Use Cntrl & left mouse click on Contents Hyperlinks to go immediately to the desired section.

1. Introduction & background

2. Overview of phases of the acquisition

3. GFE, Contractor requirements, Place of work, Period of performance

4. Scope of Work, requirements for maintaining legacy capabilities

5. Scope creep, requirements for submittals

6. Work Requirements

7. Acceptance Criteria, Deliverables

8. Common Data Format

9. ALDaps software overview

10. ALDaps confige changes (most recent)

11. BACK UP INFORMATION USER GUIDE TO LEGACY DAQ ALDAPS

12. ALDaps User’s Guide for SOW purposes

a. Test Specifications Tab

b. Single Channel Scan Tab

c. Multi Channel Scan Tab

d. Channel Definitions Tab

e. Calibration Tab

f. Event Recording Tab

g. Post Processing Tab

i. Clocks subtab

ii. Double Integration (Dint) subtab

iii. Differentiation (DxDt) subtab

iv. File Op subtab

v. Filter subtab

vi. Force subtab

vii. Integrate subtab

viii. Label subtab

ix. Math subtab

x. Pip2RPM subtab

xi. Rate subtab

h. Software Tab

i. Database

ii. New Test, Switch Test, New Setup, Edit Setup, Load Configuration

iii. Channel Configuration page

13. Data Analysis Tools

14. Enclosure 1: Double Integration Theory of Catapult Launch G’s

15. Enclosure 2: DAQ Configuration

1. Introduction NAVAIR Code 4.8.9.5 Instrumentation Engineering Branch, Lakehurst, NJ has a requirement for National Instruments (NI) Gold and/or Platinum Level Alliance Partner Distributors to develop an Improved Data Acquisition System (DAQ). The contractor shall develop a custom Data Acquisition System (DAQ) through a four (4) phase approach (discussed later in this document). The end product goal is for the contractor to develop DAQ software with National Instrument’s “Laboratory Virtual Instrument Engineering Workbench” (LabVIEW), and purchase the required NI DAQ hardware (and cabling), supporting third party hardware and provide it to the Government customer as fully configurable DAQ system(s).

The DAQ system’s purpose is to collect test data for programs that are executed at the Lakehurst Test sites, at Lakehurst facilities, on board air capable ships or at other facilities. Almost all data collection efforts are in support of Aircraft Launch and Recovery Equipment (ALRE); i.e. aircraft carrier catapults, aircraft arresting systems and support equipment. It is a mission critical aspect of the US Navy to successfully and safely launch and recover aircraft. The DAQ system collects the parametric data required by the test program that is ultimately used to certify the ALRE, verify computer models or establish performance limits.

Background In the early 90’s, NAVAIR Instrumentation Team developed an, in-house, custom Disk Operating System (DOS)-based DAQ system called DART (Data Acquisition Report and Transmit). A Common Data Format (CDF) was established by the team. The DAQ card at that time was a Keithley Metrabyte 16 channel 12 bit card. In the mid 90’s the DAQ was enhanced to provide up to 64 channels by utilizing the National Instruments NI-PCI-6071E DAQ card. The DAQ remained a DOS based system. In 2005, Apogee Labs was contracted to convert our DAQ software to be Windows based. The name of the DAQ software was renamed ALDaps (Apogee Labs Data acquisition processing system). There were no enhancements to DAQ capabilities developed at this time; however, there was for the first time, a GUI. From the late 2000’s through 2014, AlDaps was enhanced, in-house, to the system it is today. The enhancements included; capability of multiple remote distributed DAQ systems via PXI chassis’ with NI-PXI-6071E DAQ cards; nearly limitless channel count as cards and chassis’ could be added; synchronization between local and remote DAQ systems; automatic triggering and re-arming between events allowing the DAQ to operate autonomously; alarm limits; RS-232 port acquisition of ASCII code; ability to switch between GUI screens during operations, etc. The legacy DAQ system is rugged and functional, however does have some shortcomings which need to be address and is the purpose of this project.

2. Overview of phases of the acquisition Navy Lakehurst Test Instrumentation Branch is purchasing the replacement of our existing data acquisition and processing software which is used to acquire and process our current suite of National Instruments hardware. This hardware is fully functional but is obsolete. Current hardware suite configurations range from a single, locally acquired channel, to a complex system with multiple distributed chassis’ acquiring hundreds of channels dependent upon test requirements. Due to our large inventory of legacy hardware, it is required to continue using this hardware with the new DAQ system. In addition to supporting our existing hardware, we intend to supplement our hardware suite with new NI hardware with improved measurement resolution as well as providing new capabilities. This effort will be comprised of four (4) separate, logical yet related, phases. The purpose of the phased structure of this contract is to provide a logical pause during the development of the software to insure requirements are being met and to demonstrate progress at important phases of the software development. In brief, phase 1 is used to convert legacy software capability in to LabVIEW and make it Windows 10 compatible. Phase 2 is when the new DAQ hardware and GPS timing capability are introduced. Phase 3 is for further refinement of the DAQ software, fix bugs and purchase of the remaining hardware. Phase 4 is for software final version delivery, hardware delivery, training and delivery of final documentation. Post Phase 4 the software maintenance period begins and the hardware ordering period begins.

Within 30 Days After Contract Award (DACA), the Government shall host a Post Award Conference (PAC). The PAC provides the contractor with an introduction to the Government’s Navy Lakehurst Test Instrumentation Branch and establishes a formal and informal means of communication. This meeting will include a full review of the Execution Plan (CDRL A001) to ensure agreement between both parties. During the PAC, all requirements of the SOW, CDRLs, and any other salient contract requirements will be discussed. Additionally, any preliminary questions or concerns that the contractor has with regard to the requirements of the contract may be discussed at this time.

2.1 PHASE 1

Description of effort: The first effort will be to convert host DAQ software from its existing Windows 7 Operating System (OS) to Windows 10 OS, utilizing National Instrument’s LabVIEW, while maintaining the same functionality and approximate look and feel of the current software. There is a mandate to eliminate the Windows 7 operating system as support for this operating system are due to sunset and subsequent Cyber Security threats and vulnerabilities could become more of a risk. This requirement to convert to Windows 10 must be completed by 2020. The Government requires that the software be written in LabVIEW for this effort and that the contractor to be a NI Alliance Partner Distributor at the Gold or Platinum level. The Government will provide the current/legacy software code, description of capabilities and operator’s manual along with a representative suite of National Instruments current stock DAQ hardware to the contractor.

*Note that there are a few legacy functions which are not required in the new DAQ software and are discussed in the description of the Legacy AlDaps software later in this document.

Government Furnished Equipment (GFE): The GFE hardware to be provided to the contractor, which was purchased via several contracts over a span of nearly 20 years, will consist of the following:

- Quantity of one (1) each of 2-Slot Magma Box PN: 01-04426-03 (PCI Extension chassis) with PCI card for PC and cable;

- Quantity of one (1) each of NI-PXI-1042 or 1031 Chassis;

- Quantity of three (3) each of NI-PXI-6071E Analog input DAQ modules (goes in 1031 chassis) with at least (1) cable and SCB-100 terminal board;

- Quantity of one (1) each of NI-PCI-6071E Analog input DAQ module (goes in Magma box) with at least (1) cable and SCB-100 terminal board and;

- Quantity of one (1) each of PXI-PCI-8336 MXI kit, Fiber Optic MXI-Express Remote Controller kit.

- Additional hardware may be available upon request.

*NOTE: All hardware will be checked by the Government to insure operation with legacy DAQ prior to being provided to the contractor.

Software Version 1.1:

The contractor shall demonstrate functionality of the Phase 1 V1.1 software, at Lakehurst, NAS with hardware provided by the Government of the same models, but different serial numbers. A draft version of the user manual and documentation shall be provided at this time in accordance with Contract Data Requirements List (CDRL) A003.

Success Criteria – Phase 1:

Phase 1 documentation and demonstration:

· The contractor shall deliver and demonstrate version 1.1 of the software development effort at Lakehurst, NAS to show that all requirements have been addressed / met as defined by Phase 1 of the Statement of Work (SOW). The demonstration shall be coordinated between the contractor primary point of contact (POC) and the Government’s technical point of contact (TPOC).

· The contractor shall also deliver and demonstrate the draft user manual and documentation for version 1.1 of the software. Appropriate hardware and lab space will be provided at Lakehurst for the demonstration, such that it is not necessary for the contractor to bring the GFE provided to them. The contractor shall also bring computer systems with Windows 10 OS to be used for the demonstrations.

· Successful demonstration of V1.1 software to show that all requirements have been addressed. Minor software bugs/glitches/nuisances are acceptable at this time. Assuming satisfactory demonstration of the Phase 1 requirements and an acceptable draft user manual documentation, the Government will then sign off on phase 1.

Schedule: Estimated at four (4) months after date of contract.

2.2 PHASE 2

Description of effort: The contractor shall purchase the National Instruments hardware list below. There is enough new hardware to build a local DAQ system, one local and one remote DAQ system or two remote DAQ systems. The DAQ system configurations are illustrated in Enclosure 2. The contractor shall select and purchase other supporting hardware which is not offered by NI, which supports DAQ system synchronization, such as specific Ethernet switches, GPS and IEEE 1588 clocking ability, to enable development of a local and distributed DAQ system. This supporting hardware’s purpose is to provide time synchronization across all of the local and distributed DAQ systems via GPS enabled Precision Time Protocol (PTP), and to insure that the DAQ system can be synchronized with other non-connected DAQ systems; such as, high speed imaging systems and aircraft telemetry systems where data is collected by other DAQ systems. The end goal is that all data non Navy DAQ acquisition systems can be time synchronized (this will not be demonstrated by the contractor). The contractor shall continue development of the LabVIEW DAQ software such that it can operate using either the obsolete legacy DAQ hardware or the new DAQ hardware. Both legacy hardware and new hardware shall function with the new capability of GPS and IEEE 1588 clocking ability.

Phase 2 is when the contractor shall incorporate the ability of creating either CDF (Common Data Format) files or both CDF and CSV (Comma Separated Values) formatted data during data acquisition. The capability to create CSV files shall be available during data acquisition (as an option) and via post processing. Also, all post processing of CDF files, which create or modify existing CDF files, shall have the option of creating both CDF and CSV format data. This is a new capability that did not exist with the legacy DAQ. Currently, this capability only exists via a custom Excel macro, and is not part of the legacy DAQ. This Excel macro can be provided.

When significant post processing of CDF files is required; it may make more sense to create all the post processed CDF files first, and then execute the post processing process to create all the CSV format data into one file.

During data acquisition, there shall be an option to create CSV files for all channels or just selected channels. This should be selected in the channel definitions tab Channel Definitions Tab.

The capability of creating CSV format data during post processing, shall allow the user to define the start time, stop time (or amount of time) and the timing interval for the CSV data/file creation. Example #1; convert CDF file(s) to CSV data with the following parameters: start at time = -1 second from Trigger 2 (start trigger); go to +3 seconds after Trigger 3 (stop trigger) and use an interval of 0.001 seconds. Example #2; convert CDF file to CSV file with the following parameters: start at time = -1 second from Trigger 2 (start trigger); convert for +13 seconds after Trigger 2 (start trigger) and use an interval of 0.005 seconds.

Additional options shall include:

- Pick average, minimum or maximum value over interval.

- Average all values between the start and stop time and produce one average value data point.

- Select all CDF files converted or check off which ones shall be converted.

- CSV file name and saved location shall user defined.

The CSV file shall incorporate all data into a single CSV file with the parameter name on the top row and the time in the left most column. Any post processed files converted to CSV shall be added to the CSV file.

*NOTE: Notice in the Enclosure 2 signal flow diagrams that there are NI-PXIe-8840 Controllers in each NI-PXIe-1082 Chassis rather than the more common chassis NI Remote Control Modules such as the NI-PXIe-8375 Fiber Optic Modules. This is because the PXIe connectivity between chassis’ would require costly fiber optic infrastructure changes to our test sites. By using the NI-PXIe-8840 Controllers, the existing fiber optic infrastructure may be utilized as it is.

Version 1.2 DAQ software in accordance with CDRL A003:

The hardware that will need to be purchased for Phase 2 shall be as follows:

- Quantity of four (4) each of NI-PXIe-8840 Controllers;

- Quantity of four (4) each of NI-PXIe-1075 Chassis;

- Quantity of eight (8) each of NI-PXIe-6363 Analog input DAQ modules;

- Quantity of sixteen (16) each of BNC-2090A Rack-mountable accessories for 68-pin;

- Quantity of sixteen (16) each of SHC68-68-EPM Shielded Cables;

- Quantity of four (4) each of NI-PXIe-4353 Thermocouple (TC) DAQ modules;

- Quantity of four (4) each of NI TB-4353 Isothermal Terminal Blocks;

- Quantity of four (4) each of NI-PXIe-4347 RTD DAQ modules;

- Quantity of four (4) each of NI TB-4357 Terminal Block Accessories;

- Quantity of four (4) each of NI-PXI-6683H Timing and Sync modules;

- Quantity of four (4) each of CONTRACTOR SELECTED Ethernet switches capable of IEEE- 1588v2 Precision Time Protocol (PTP);

- Quantity of two (2) each of CONTRACTOR SELECTED specified network server and;

- Quantity of two (2) each of CONTRACTOR SELECTED Master Clock source with GPS input producing IEEE-1588v2 PTP

Success Criteria – Phase 2:

Phase 2 documentation and demonstration:

· The contractor shall deliver and demonstrate version 1.2 of the software development effort at Lakehurst, NAS to show that all requirements have been met as defined by Phase 2 of the Statement of Work (SOW). Version 1.2 of the software is defined in the SOW under Phase 2 of the contract. The demonstration shall be coordinated between the contractor primary POC and the Government TPOC.

· The contractor shall also deliver and demonstrate the draft user manual and documentation for version 1.2 of the software. Appropriate hardware and lab space will be provided at Lakehurst for the demonstration, such that it is not necessary for the contractor to bring the GFE provided to them.

· The contractor shall deliver exactly one half of all quantities of each type of new hardware defined by Phase 2 requirements. (The other half of the quantities of each piece of hardware shall remain with the contractor for further software development.)

· The contractor shall demonstrate the new DAQ hardware with the GPS timing ability and the legacy DAQ hardware with the GPS timing ability. The contractor shall also bring computer systems with Windows 10 OS to be used for the demonstrations.

· Successful demonstration of V1.2 software to show that all requirements have been addressed and that purchase and receipt of hardware by the contractor was completed. Minor software bugs/glitches/nuisances are acceptable at this time. Assuming satisfactory demonstration of the Phase 2 requirements, the Government will then sign off on phase 2.

Schedule: Estimated at three (3) months following Phase 1 acceptance.

2.3 Phase 3

Description of effort: This phase will complete the initial period of performance acquisition of hardware and continues software efforts, fix issues and make any changes to the software that are necessary. The type of hardware and quantities to be purchased is listed below in Table 1. The requirement is to have multiple configurations of DAQ suites including:

1. Portable system configurations (both large and small channel count), with and without PTP and with old or new types of DAQ input modules;

2. Site based system configurations utilizing various quantities of the new types of DAQ cards with PTP and legacy configurations with and without PTP. Legacy DAQ module (6071E) systems are not required to be combined with the new 6363, 4353 or 4347 cards. The hardware to be purchase will be an expansion of Phase 2’s hardware with the quantities in Table 1. For a listing of the desired DAQ configurations, see Enclosure 2. An example signal flow diagram illustrating how all the hardware is integrated together is shown in Enclosure 2.

Version 1.2.x DAQ software in accordance with CDRL A003:

The hardware that will need to be purchased for Phase 3 approximately defined by Table 1 below.

Table 1:

· Quantity of twelve (12) each of NI-PXIe-8840 Controllers;

· Quantity of (8) each of NI-PXIe-1082 Chassis;

· (0) NI-PXIe-1075 Chassis;

· Quantity of (41) each of NI-PXIe-6363 Analog input DAQ modules;

· Quantity of (82) each BNC-2090A Rack-mountable accessories for 68-pin;

· Quantity of (82) each of SHC68-68-EPM Shielded Cables;

· Quantity of (8) each of NI-PXIe-4353 Thermocouple (TC) DAQ modules;

· Quantity of (8) each of NI TB-4353 Isothermal Terminal Blocks;

· Quantity of (3) each of NI-PXIe-4347 RTD DAQ modules;

· Quantity of (3) each of NI TB-4357 Terminal Block Accessories;

· Quantity of (38) each of NI-PXI-6683H Timing and Sync modules;

· Quantity of (8) each of CONTRACTOR SELECTED Ethernet switches capable of IEEE-1588v2 Precision Time Protocol (PTP);

· Quantity of (9) each of CONTRACTOR SELECTED specified network server(s) and;

· Quantity of (4) each of CONTRACTOR SELECTED Master Clock source with GPS input producing IEEE-1588v2 PTP

The contractor will demonstrate functionality of the Phase 3 effort at Lakehurst, NAS with the hardware that was purchased under the Phase 2 and 3 efforts and legacy hardware again provided by the Government as was in Phase 1. The demonstration shall consist of local and distributed systems, with old and new DAQ hardware and system synchronization with old and new DAQ hardware. Assuming satisfactorily demonstrating Phase 3, the Government will then approve moving to the next phase of the acquisition effort. A 90% complete version of the user manual and documentation shall be provided at this time.

Success Criteria:

Phase 3 documentation and demonstration:

· The contractor shall deliver and demonstrate version 1.2.x of the software development effort at Lakehurst, NAS to show that all requirements have been met as defined by Phase 3 of the Statement of Work (SOW). Version 1.2.x of the software is defined in the SOW under Phase 3 of the contract. The demonstration shall be coordinated between the contractor primary POC and the Government technical POC.

· The contractor shall also deliver and demonstrate the user manual and documentation for version 1.2.x of the software is ~90% complete. Appropriate hardware and lab space will be provided at Lakehurst for the demonstration, such that it is not necessary for the contractor to bring the GFE provided to them.

· The contractor shall bring all new hardware defined by Phase 2 and Phase 3 requirements (all hardware under initial PoP). The contractor shall demonstrate the new DAQ hardware with the GPS timing ability and the legacy DAQ hardware with the GPS timing ability under multiple configuration scenarios defined by the Enclosure 2 of the SOW. The contractor shall also bring computer systems with Windows 10 OS to be used for the demonstrations.

· Successful demonstration of V1.2.x software to show that all requirements are being addressed and that purchase and receipt of hardware by the contractor was completed. Most software bugs/glitches/nuisances shall be remedied at this time, however a few (3 or fewer) will be considered acceptable. A 90% complete version of the user manual and documentation shall be provided at this time. Assuming satisfactory demonstration of the Phase 3 requirements, the Government will then sign off on phase 3.

Schedule: Estimated at two months following Phase 2 acceptance.

2.4 Phase 4

Description of effort: Phase 4 shall consist of formal training of trainers at Lakehurst estimated at 2 days. Approximately 3 people will be in attendance. Phase 4 is when the final user manuals and documentation shall be presented. Phase 4 is when the final version of the DAQ software version 1.2.x.x shall be delivered. The final version of the software shall not require any licensing and shall be capable of installation and operation on an unlimited number of computer systems. Phase 4 is the final phase of this effort, however, the one year software warranty and IDIQ aspect of this phase shall continue till expirations.

Final version of DAQ software version 1.2.x.x, in accordance with Contract Data Requirements List (CDRL A003),and all cabling systems required for each piece of hardware defined above.:

Success Criteria:

Phase 4 Training and final documentation:

· The contractor shall deliver and demonstrate version 1.2.x.x of the software development effort at Lakehurst, NAS to show that all requirements have been met as defined by Phase 4 of the Statement of Work (SOW). Version 1.2.x.x of the software is defined in the SOW under Phase 4 of the contract. The demonstration shall be coordinated between the contractor primary POC and the Government technical POC.

· The contractor shall also deliver and demonstrate the user manual and documentation for version 1.2.x.x of the software is complete. Appropriate hardware and lab space will be provided at Lakehurst for the demonstration, such that it is not necessary for the contractor to bring the GFE provided to them.

· The contractor shall deliver all remaining new hardware defined by Phase 2 and Phase 3 requirements (all hardware under initial PoP).

· The contractor shall deliver all GFE at this time (GFE can be provided back to the contractor if / when necessary).

· The contractor shall demonstrate the new DAQ hardware with the GPS timing ability and the legacy DAQ hardware with the GPS timing ability under multiple configuration scenarios defined by the Enclosure 2 of the SOW. The contractor shall also bring computer systems with Windows 10 OS to be used for the demonstrations. The contractor will then conduct training with the purpose of training the trainers to up to four (4) Government personnel, to include the Government’s TPOC. Training will consist of going through the user manual and documentation for the software and hardware; performing software installation on Government computers; configuring and operating the DAQ system software and hardware; creating test setups; taking calibration events; taking test events; performing post processing functions and setting up Elements and Macros.

· Successful completion and demonstration of V1.2.x.x software; Successful completion of training and delivery of manuals and documentation. Assuming satisfactory demonstrating of the Phase 4 requirements, the Government will then consider the initial PoP complete other than the software warranty and IDIQ aspect of the contract.

Schedule:

- Formal Training: Within (1) month following Phase 3.

- Final Documentation: Within (1) month following Phase 3.

- Final version of software (V.1.2.x.x): (1) month following Phase 3.

- Delivery of all cabling systems: Within (1) month following Phase 3.

- Software Warranty: (1) year following delivery of Formal Training, Final User Manuals and Documentation and Final version of software.

· IDIQ additional Hardware: (5) years following ARO.

3. Government Furnished Equipment

-The Government will provide legacy DAQ software code (contractor shall agree to and sign a confidentiality agreement upon receipt).

-The Government will offer an information session to interested contractors to demonstrate AlDaps software; show hardware; discuss AlDaps and new requirements; tour test sites; show examples of data and show examples of cabling systems. All questions with the requirements or clarifications shall be emailed to the contract specialist.

Contractor requirements -The Government requires the DAQ software development platform to be LabVIEW and that the contractor will be a National Instruments Gold or Platinum level Alliance Partner.

-The NI hardware to be purchased will be defined by the Government customer unless otherwise specified.

-The contractor shall select and purchase the hardware required to support the requirement for ‘Master Clock source with GPS input producing IEEE-1588v2 PTP’.

Place of work

· Software development and testing shall be done at contractor’s site

4. Scope of Work

Required new capabilities of DAQ system:

a) DAQ shall operate under Windows 10.

b) DAQ shall use the following DAQ modules: NI-PXIe-6363 (analog input), NI-PXIe-4353 (Thermocouple), NI-PXIe-4357 (RTD) and also current stock, legacy inventory, DAQ modules (NI-PCI/PXI-6071E) as part of a single overall DAQ system. DAQ system may be local to the user, distributed and/or both local and distributed. Software must auto-detect the type of modules(s) and chassis’ installed. Legacy and new DAQ modules will not be combined in the same DAQ system. A complete listing of hardware is in Enclosure 2.

c) DAQ shall be capable of 16 bit data resolution, however selectable down to 12 bits (current limitation of legacy DAQ 6071E module).

d) DAQ shall utilize the Differential Input capability of all of the NI-DAQ cards and all cabling shall respect differential input. Legacy DAQ cards are currently setup for single ended inputs, however, the DAQ shall be able to utilize the legacy 6071E modules in either single ended mode or differential mode as part of the new capability. The govt customer will be responsible for converting cabling systems to accommodate the legacy 6071E cards for use with differential input.

e) DAQ shall be capable of utilizing GPS/IRIG timing to establish time read in by the DAQ software, and/or be capable of using computer time (legacy DAQ). The NI-PXI-6682H GPS, IRIG-B, IEEE 1588v2, or PPS PXI Synchronization Module shall be used to acquire GPS. This module shall be capable of being networked to other distributed systems such that all systems are time synchronized to within 1 microsecond, or better than one data sample of timing resolution (whichever is greater). This is illustrated in Enclosure 2.

f) DAQ shall be capable of displaying data in Engineering Units (EU) versus time of day (local 24 hour time from computer or GPS or GMT from GPS) or versus relative time (first data point is time=0). Time of day shall be capable of being provided by either GPS/IRIG time, computer time or the network server drive time to which data is being written. Data processing and display programs shall be capable of handling all of the time formats. Start of acquisition (time =0) shall be time stamped with time of day and be included as part of the header (CDF file format).

g) DAQ shall be capable of providing selectable data formats compatible with Matlab and Excel (CSV) and/or also provide CDF data formats (legacy DAQ).

h) Fix bugs / nuisances in the Event tab highlighted in red.

i) Fix bugs / nuisances discussed in Channel configuration highlighted in red.

j) Add convenience button for Atlas (In-house data analysis application)

k) Fix bugs / nuisances discussed with PasteBoard

l) The following legacy Functions (Tabs) are obsolete and may be removed from the new DAQ software:

i. Math

ii. Pip2RPM

iii. Rate

Requirements for maintaining legacy capabilities:

1. DAQ shall maintain current look, feel and functionality of AlDaps, including ability to use current Government customer inventory National Instruments DAQ hardware as defined below:

a. NI-PCI-6071E DAQ cards PN N/A

b. NI-PXI-6071E DAQ cards PN777676-01

c. NI-PXI-1031 and 1042 Chassis PN 778932-01 and 778636-01, respectively

d. NI PXI-PCI8336 MXI-4 Kit PN 778641-10

e. SCB-100 Connector Block PN 776990-01

f. Type SH1006868 Cable Assembly PN 182849-02

g. SCB100 Connector blocks PN 777812-01

2. All legacy applications within the GUI shall perform normally. All legacy functionality running within AlDaps shall be revised to be able to work with new data files and legacy data files, unless specified throughout this SOW.

3. CDF shall be utilized to insure backward and forward compatibility of legacy and newly acquired data allowing new DAQ to work with legacy data.

5. Requirements for submittals:

a) Proof of Gold or Platinum National Instruments Alliance Partner.

b) Contractor’s organizational structure supporting the NI requirements for an Alliance Partnership.

c) Contractor will present a design plan, schedule, WBS, testing plan, training plan, delivery plan and maintenance plan

d) POCs.

e) Define how legacy functions will be maintained, while providing new capabilities as defined above.

f) Proof of comprehension of requirements

i. Illustration of interpretation of AlDaps code

ii. Illustration of interpretation of new requirements

iii. Illustration of how the legacy and new requirements will coexist.

g) Cost breakdown.

i. For Phase 1.

ii. For Phase 2.

iii. For Phase 3.

iv. For Phase 4, excluding IDIQ part of contract. Estimate anticipated inflation rate for hardware for the final four years of the IDIQ.

v. Total cost, excluding IDIQ part of contract.

h) Schedule breakdown.

i. For Phase 1.

ii. For Phase 2.

iii. For Phase 3.

iv. For Phase 4, including IDIQ part of contract.

6. Work Requirements

1. Kickoff

a. Contractor shall present to Government customer a design plan, schedule, WBS, testing plan, training plan, delivery plan and maintenance plan.

2. Development phase

a. Contractor shall develop / modify all programs

b. Contractor shall resolve all software issues until all requirements are met

3. Implementation phase

a. Contractor shall provide all software and relevant supporting software to Government customer

b. Contractor shall provide all DAQ hardware and GPS hardware

c. Contractor shall provide all cabling

d. Contractor shall provide all user manuals and documentation

4. Training phase

a. Contractor shall provide on Government site training.

b. Operators manual shall be written and provided.

5. Handoff/Closure

a. Contractor shall provide one year of included software maintenance to repair bugs, etc.

b. Contractor shall provide Points of Contact for email and phone conversation about software and/or hardware

c. Contractor shall provide email or phone support during normal business hours

d. All software, manuals and documentation shall be delivered via CD initially; however, revisions to software, documentation, drivers, libraries, etc, shall be downloadable via vender’s secure website. Documentation shall be provided for the following:

i. File structure

ii. Cabling

iii. DAQ hardware

iv. GPS/IRIG/Synchronization between chassis’ and systems

v. Contractor shall provide all code via CD(s)

vi. Software installation

7. Acceptance Criteria

The development of the Improved ALRE DAQ System shall be considered acceptable upon completion of the following:

a) Software product has been demonstrated by the contractor that all requirements have been met and that the way the requirements are met are acceptable (user interface is intuitive and is logical)

b) Software installation package works properly and is documented in the user manual

c) All hardware has been purchased and delivered to the Government and is performing to manufacture specifications

d) All cabling system are properly manufactured and are delivered with the hardware

e) All documentation, specifications and user manuals are complete, comprehensive and have a logical structure

f) Terms of maintenance period are well defined and acceptable

g) IDIQ aspect of contract is defined and includes projected material costs for the duration of the IDIQ.

Deliverables

a) Contractor shall provide copy of all source code and executables developed under this contract.

b) Contractor shall provide all Intellectual Property – Code which was previously developed but used for this contract.

c) All DAQ hardware defined by the contract shall be delivered to the Government customer.

d) All cabling defined by the contract shall be delivered to the Government customer.

e) Any loaned legacy hardware shall be returned following delivery, however may be delayed to support maintenance if necessary.

f) Execution Plan. Contractor shall present to Government customer for review a design plan, schedule; list of long lead items (greater than 6 weeks), WBS, testing plan, training plan, delivery plan and maintenance plan in accordance with CDRL A001.

g) The Contractor shall submit a monthly Status Report in accordance with DI-MGMT-80227 and CDRL A002.

h) The contractor shall demonstrate functionality of the Phase 1 effort, at Lakehurst, NAS with hardware provided by the Government of the same models, but different S/Ns. A draft version of the user manual and documentation - V1.1 software - shall be provided at this time in accordance with CDRL A003 - Phase 1 documentation and demonstration.

The contractor will demonstrate functionality of the Phase 2 effort, at Lakehurst, NAS with the hardware that was purchased under the Phase 2 effort and legacy hardware again provided by the Government as was in Phase 1. A revised draft version of the user manual and documentation shall be provided at this time in accordance with CDRL A003 - Phase 2 documentation and demonstration.

The contractor will demonstrate functionality of the Phase 3 effort at Lakehurst, with the hardware that was purchased under the Phase 2 and 3 efforts and legacy hardware again provided by the Government as was in Phase 1. The demonstration shall consist of local and distributed systems, with old and new DAQ hardware and system synchronization with old and new DAQ hardware. A 90% finalized version of the user manual and documentation shall be provided at this time in accordance with CDRL A003 - Phase 3 documentation and demonstration.

i) Formal Training in accordance with CDRL A001.

j) Final User Manuals and Documentation in accordance with CDRL A003 - Phase 4 training and documentation. This includes: File structure documentation, cabling documentation, DAQ hardware documentation, GPS/IRIG/Synchronization between chassis’ and systems documentation, Contractor shall provide all software CD(s) and Software installation instructions. Contractor shall provide copy of all source code and executables developed under this contract. Contractor shall provide all Intellectual Property – Code which was previously developed but used for this contract.

All information from this point forward is a description of the Legacy ALDaps Software and is intended to provide pertinent information to the potential contractors who may be providing a quotation and/or developing the Improved ALRE DAQ System. Some of the information will be repeated many times throughout the document. Hyperlinks are used throughout the document to quickly navigate around the document.

GFI

Common Data Format:

During data acquisition and/or as a result of digital signal processing technique in the DART software system, files are used to store digitized time series data. This data is structured to conform to the COMMON data format (CDF). In the COMMON data format each channel of time series information is maintained in its own file. Each file is binary formatted and consists of two parts: the header and the raw data. The header occupies the first 512-bytes of the file and contains the descriptive information listed below. The length of the raw data part of the COMMON data format depends on the length of the time series it contains. The raw data part uses one sixteen bit word for each time series sample it holds. If the time series data was acquired using less than sixteen bits per sample, the higher order bits are sign extended. (This really has no impact with Data Acquisition. Polarity of data is programmed via scale factor and offset to create EU)

512 byte Header Structure Byte ¦ Description ¦ Type ¦ Length Position¦ ¦ ¦ (bytes) 0 ¦ UNUSED ¦ char ¦ 20 20 ¦ whole blocks ¦ long ¦ 4 24 ¦ UNUSED ¦ char ¦ 20 44 ¦ last block ¦ long ¦ 4 48 ¦ UNUSED ¦ char ¦ 80 128 ¦ units ¦ char ¦ 12 140 ¦ mantissa of scale factor ¦ long ¦ 4 144 ¦ exponent of scale factor ¦ long ¦ 4 148 ¦ mantissa of offset ¦ long ¦ 4 152 ¦ exponent of offset ¦ long ¦ 4 156 ¦ UNUSED ¦ char ¦ 84 240 ¦ exponent of sampling rate ¦ long ¦ 4 244 ¦ mantissa of sampling rate ¦ long ¦ 4 248 ¦ UNUSED ¦ char ¦ 8 256 ¦ trigger1 scan position ¦ long ¦ 4 260 ¦ trigger2 scan position ¦ long ¦ 4 264 ¦ trigger3 scan position ¦ long ¦ 4 268 ¦ trigger4 scan position ¦ long ¦ 4 272 ¦ UNUSED ¦ char ¦ 120 392 ¦ date ¦ char ¦ 8 400 ¦ site ¦ char ¦ 20 420 ¦ item ¦ char ¦ 12 432 ¦ test ¦ char ¦ 20 452 ¦ event ¦ char ¦ 8 460 ¦ number of channels ¦ char ¦ 4 464 ¦ channel number ¦ char ¦ 4 468 ¦ channel description ¦ char ¦ 28 496 ¦ data source ¦ char ¦ 16

ALDaps 1.1.5 SOFTWARE OVERVIEW 2/25/14

Background

· Software originally built by Apogee Labs, Inc in 2005.

· ALDaps = Apogee Labs Data Acquisition & Processing Software.

· Built upon previous DOS-based routines to provide complete Windows recording and data processing environment.

· Follow on expansion and maintenance done in-house with some major changes including multi-chassis synchronization, pre-trigger, and autonomous recording.

Libraries

· Microsoft Visual C++ 2003

· Microsoft .NET 1.1

· National Instruments DAQmx 8.7.11.11

· National Instruments VISA 8.5.11.310

· Dundas Win Gauge 1.6.1.35

· ZedGraph 4.2.4.2411

· All libraries require upgrade. Visual Studio 2012 on hand with IA team.

Program Configuration

· ALDaps consists of ALDaps.exe, Quicklook.exe, and PasteBoard.exe

· New update to PasteBoard written by Brian Compter in use at EMALS site should be included but currently is not.

· Most recent version of ALDaps.exe (1.1.5) put out as executable only, IA team has on hand.

· All versions stored in different directories by version, currently residing in backup and on development computer in D:\projects\ALDaps1_0_5\ through current build which is just \projects\ALDaps\

· Project files in \projects\ALDaps\ALDaps\ALDaps.vcproj and \projects\Quicklook\Quicklook\Quicklook.vcproj

· Solution file is \projects\ALDaps\ALDaps.sln

Code Overview (ALDaps.exe)

· Consists of 8 tab pages and 1 main form as Windows forms that inherit from a base class, root.h

· In order to use Visual C++ designer, would need to change class declaration from INHERIT to public System::Windows::Forms::Form

· Designer sometimes problematic, especially with Dundas Gauge integration and can cause unexpected problems or changes since most control properties have been set manually in the code. Designer can unset some of these settings so make sure a backup is in place before use.

· MainPane is the parent form for all of the tabs.

· Handles initiating the National Instruments hardware and setting up the system with the correct number of cards (or card slots).

· NUM_CARDS specifies number of cards in system

· NUM_SLOTS specifies how many open slots to use with system configuration.

· EO[] array stores information on cards in case some are missing

· If first card in system is Dev2 (usually is Dev1), EO[0] would = 1 to account for the empty slot offset in a lot of the indexing.

· Handles all error reporting to the Debug Console.

· Launches Card Setup screen, Debug Console, Serial Port Interface, PasteBoard, and Quicklook

· Test Specification is the first page (start page) and only displays some setup information

· Shows last test setup parameters.

· Shows current card inventory with missing cards highlighted, if applicable.

· System sets Dev1 to be name of first device, Dev2 second, etc.

· Any other name (set in NI Measurement & Automation Explorer program) will come up as error and missing card.

· Single Channel Scan shows current scan information for a given channel

· Receives data through own asynchronous callback function while not recording.

· Receives data through data transfer from Recording page while recording.

· Multi Channel Scan shows current scan information for multiple channels simultaneously.

· Receives data through own asynchronous callback function while not recording.

· Receives data through data transfer from Recording page while recording.

· Clicking gauge switches to Single Channel Scan on the clicked channel.

· Channel Definitions shows setup information on all channels.

· Can show setup for cards that aren’t currently in system.

· I_Scale is input scale.

· I_Offset is input offset.

· Scale is actual scaling taken directly from I_Scale for a MANUAL scaling and from calibration event for SHUNT scaling.

· Offset is actual scaling taken directly from I_Offset for a MANUAL scaling and from calibration event for SHUNT scaling.

· Calibration sets scaling information by recording an event and using a known deflection and zero point.

· Takes average value for zero and shunt position and calculates y = mx + b scaling for SHUNT channel

· m = Scale, b = Offset

· Event Recording page records data and displays up to one channel of live data.

· Uses own asynchronous callback setup to collect data from card and write to disk

· ScanCallBackSync() is the gatekeeper function for all of the data calls.

· Waits for individual card callbacks to complete before moving on, which allows data acquisition to be sequenced and predictable.

· Is itself called asynchronously though a delegate, calls StopRecordDelegate when complete, which in turn calls StopRecordAux which shuts down the recording and finalizes the data.

· Calls auxiliary function to process data – ScanCallBackAux when system is ready and all of the trigger monitoring / data writing completed in this function.

· Post Processing page encapsulates all of the data altering functions that are used to modify data after an event.

· Conceptually, functions are the individual commands that do one thing like Force and Label.

· Elements are lists of functions to be executed in a row and are customizable and savable.

· Macros are groups of elements and are executable, if necessary, immediately following an event.

· Elements and macros stored in XML format on disk.

· Software Configuration is used to store and set all channel information for recording setups

· Pulls in information from a database which stores last setup information, how many cards were used, and all of the lists of standard tests, locations, and personnel.

· Also pulls in information from ALDaps.log which is stored in the setup directory

· Directory structure for recording is testdata\location\test\setup\event

· Setup is dated directory in YYMMDD00 format where 00 is number of setup for day (usually only one, so 00)

· Event is 7 digit positive integer representing test event number.

· Current problem with .NET framework 1.1 and using CTRL-C (or clipboard call) on Channel Configuration grid (datagrid class).

· Currently using internal cut/copy/paste routine but future upgrade will hopefully allow for copying from external sources.

ALDaps 1.1.5 CONFIGURATION CHANGES (Rev A) 9/18/14

· Multi Channel Scan: Clicking channel gauge switches page to Single Channel Scan w/ selected channel displayed.

· No more strip chart / numeric indicator.

· Number of cards in system now user-selectable

· Use Card Setup button to set new card number.

· System looks for highest Dev#, number of cards in last setup (from database), and the device inventory of cards. Selects highest value from those and user input.

· Program restarts with card number change.

· Allows for continuity of setups with missing cards / disconnected chassis.

· Empty card slots show in red on Test Specification and Event Recording.

· Only real cards will work on Single / Multi Channel Scans.

· On Post Processing, F5 now refreshes folder view.

· Folder also switches to new event folder after recording complete (but doesn’t change page anymore).

· Last folder path used saved for restart in ALDaps\lastdir.log

· Functions like Label that used to output information on every channel’s header change now combine all channels into one.

· All Post Processing output now written to file in EVENT folder, postprocess.log

· On Software Configuration, now able to set / edit / refresh system database:

· Folder button is to Set / Change Database

· Pencil / paper button is to Open / Edit Database

· Double arrow button is to Refresh Database (information for test / location / personnel fields.

· Could run multiple instances of ALDaps with unique setups if:

· Each instance installed in separate folder: C:\ALDaps1\, C:ALDaps2\, etc.

· Each instance uses its own database.

· No two instances will be armed or collecting data on the same card at the same time.

· Allows for arming, channel monitoring, and separate event recording of different system cards.

· CTRL-C no longer throws error on channel names.

· However, now CUT / COPY / PASTE now only works within Software Configuration and not from external programs.

· Added toggle between internal / external mode in upper lefthand corner.

· Debug Console: Receives most critical error and status information instead of pop-up windows which often interfered with recording.

· Displays automatically, click Debug Console button to bring up again.

· Console writes all information to debug.log in \ALDaps\ folder on start, and in setup folder for remainder of program execution.

· Serial Port: Provides same functionality as Apogee Labs ASCII to Voltage Converter boxes.

· Reads in ASCII radar values from selected COM port, click Connect button to start.

· Converted analog output signal comes out on AO 0 (analog output zero), pin 20 (+) and pin 23 (ground).

· Zero Out button outputs zero value for home position in calibration. (0.0 knots)

· Cal Out button outputs shunt value for shunt position in calibration. (76.8 knots)

· Tie AO 0 to any input channel to record as channel.

· Event number now settable on Event Recording page instead of Test Specification.

· Post process macro will update over to new setup destination automatically.

· No more Create Event Directory button, this function ran on system ARM.

· Event directory deleted on DISARM.

· Keyboard shortcuts only recognized while main ALDaps screen has focus.

· If key detected while Debug Console has focus, console will close (but will have to hit key again).

· Can hit F8 to RECORD immediately if necessary.

· Status LEDs can be attached to system to provide remote indication of system status.

· ARM signal comes out on P0.0 (digital output ch. 0), pins 25 and 24 / 33 (D GND).

· REC signal comes out on P0.1 (digital output ch. 1), pins 27 and 24 / 33 (D GND).

· See “ALDaps 1.1.5 OUTPUTS AND HARDWARE CONFIGURATION” diagram for complete wiring to use drive LED from system.

· New synchronization mode: Clock Output provides most accurate multi-chassis sync.

· Outputs actual sample clock on lowest Dev# in setup (Overall Master) on PFI 9 (pins 48 [+] and 24 [-]) like previously used Hardware Mode.

· Lowest Dev# in slave chassis receives synchronization in on PFI 9.

· Other cards in slave chassis (or PC) receive sync through PXI backplane (automatic) or RTSI cable (PC, must be added both physically to card and into Measurement & Automation Explorer).

· Overall Master card sample rate must be divisible by all slave card rates, for example: if Overall Master sample rate is 5000, a slave rate of 50 or 1000 will work but 600 or 6000 will make the system default to normal Hardware Mode.

· Proper operation with Clock Output will light transmit / receive lights on SITECH fiber converters steadily during entire ARM / RECORDING phase (Hardware Mode only blinks them on ARM).

· Slave / Chassis Master rate limit = 5000 samples / sec. Took out limit – could not recreate problem, and looks like everything works fine up to 100000 Hz.

· Pre Trigger Mode: Records up to 10 seconds of pre-RECORDING data.

· Separate files written to \ALDaps\TEMP\E_YYYYMMDDHHMMSS where E is event number, and remainder is date / time.

· TEMP\ directory deleted on program start.

· Pre-trigger files written in an incremental overwrite mode, which means that the data will be slightly scrambled because oldest data will be somewhere in the middle of the file. This data is normally unscrambled and attached to permanent recording files at end of normal event.

· Files which actually record less than the specified pre-trigger time will have empty space in file in that region.

· Post Stop: Records for specified duration after stop condition…