AS064-ILST-FATP Issue 1 - 1 - Final Acceptance Test Plan - Signed

Nationaal Lucht- en Ruimtevaartlaboratorium
National Aerospace Laboratory NLR
NLR-CR-2013-308-Issue-1.1
Final Acceptance Test Plan of the Upgrade of the

ILST Data Acquisition and Data Processing
systems
Issue 1.1
E.J.A. Wegkamp

Anthony Fokkerweg 2
P.O. Box 90502
1006 BM Amsterdam
The Netherlands
Telephone +31 (0)88 511 31 13
Fax +31 (0)88 511 32 10
www.nlr.nl
UNCLASSIFIED

Executive summary
Final Acceptance Test Plan of the Upgrade of the ILST Data

Acquisition and Data Processing systems
Problem area
This document is the Test Plan (TP)
for the Upgraded ILST Data
Acquisition and Data Processing
systems. The major objective of the
Upgrade of the ILST Data
systems is the replacement of the
aging equipment for modern PCbased equipment, with the aim to
preserve the current functionality.
This objective will be achieved by
the development of new interfaces
for the existing Conditioning Units
and associated equipment (PLC
systems, Subscanner Controllers,
etc.) and the application of modern
PC-based computer systems, with
the Linux operating system. As part
of the project is identified the
update of the existing software
configuration items DA software in
the DARS host computer and the
DP software in the DPS host
computers.
During the project the hardware
modifications as well as dedicated
NLR furnished equipment will be
checked for its correct functioning
during the development and
manufacturing phase of the project.
As part of the overall check of the
integrated functionality of the ILST
Data Acquisition and Data
Processing systems a dedicated
UNCLASSIFIED
check process will be performed.

This process is described in this
Test Plan.
Description of work
Testplan for Upgraded ILST Data
systems
Results and conclusions
Testplan for Upgraded ILST Data
systems.
Applicability
Upgraded ILST Data Acquisition
and Data Processing systems
Report no.
Author(s)
E.J.A. Wegkamp
Report classification
UNCLASSIFIED
Date
April 2014
Knowledge area(s)
Elektronicatechnologie
Avionicakwalificatie
Descriptor(s)
Instrumentation
Wind Tunnel Apparatus
Data Acquisition
Data Processing
UNCLASSIFIED
Final Acceptance Test Plan of the Upgrade of the ILST Data Acquisition and
Data Processing systems
Nationaal Lucht- en Ruimtevaartlaboratorium, National Aerospace Laboratory NLR
UNCLASSIFIED
Anthony Fokkerweg 2, 1059 CM Amsterdam,

P.O. Box 90502, 1006 BM Amsterdam, The Netherlands
Telephone +31 88 511 31 13, Fax +31 88 511 32 10, Web site: www.nlr.nl

Final Acceptance Test Plan of the Upgrade of the

ILST Data Acquisition and Data Processing
systems
Issue 1.1
E.J.A. Wegkamp
No part of this report may be reproduced and/or disclosed, in any form or by any means without the prior
written permission of the owner.
Customer
Pro-Innov Technology Indonesia
Contract number
SID 7571
Owner
NLR
Division NLR
Aerospace Systems
Distribution
Limited
Classification of title
Unclassified
April 2014
Approved by:
Author
E. Wegkamp
Reviewer
T. ter Meer
Managing department
H. Slot
Date:
Date:
Date:
Summary
This document is the Test Plan (TP) for the Upgraded ILST Data Acquisition and Data
Processing systems. The major objective of the Upgrade of the ILST Data Acquisition and Data
Processing systems is the replacement of the aging equipment for modern PC-based equipment,
with the aim to preserve the current functionality.
This objective will be achieved by the development of new interfaces for the existing
Conditioning units and associated equipment (PLC systems, Subscanner Controllers, etc.) and
the application of modern PC-based computer systems, with the Linux operating system. As
part of the project is identified the update of the existing software configuration items DA
software in the DARS host computer and the DP software in the DPS host computers.
During the project the hardware modifications as well as dedicated NLR furnished equipment
will be checked for its correct functioning during the development and manufacturing phase of
the project. As part of the overall check of the integrated functionality of the ILST Data
Acquisition and Data Processing systems a dedicated check process will be performed. This
process is described in this Test Plan.
Contents
1
Scope
1.1
Identification
1.2
System Overview
1.3
Document Overview
10
1.4
Relationship to Other Plans
11
Referenced Documents
12
2.1
Government Documents
12
2.2
Non-government Documents
12
Test Environment
13
3.1
General
13
3.2
Software Items
14
3.3
Hardware and Firmware Items
15
3.4
Proprietary Nature, and Government Rights
16
3.5
Installation, Testing, and Control
16
Formal Qualification Test Identification
17
4.1
General Test Requirements
17
4.1.1
User Requirements
17
4.1.2
DARS software
17
4.1.3
DPS software
17
4.2
Test Classes
17
4.3
Test Levels
18
4.3.1
CSU/CSC level
18
4.3.2
CSC integration level
18
4.3.3
CSCI/CSCI validation level
19
4.4
Test Definitions
21
4.4.1
DARS-SW
21
4.4.2
DPS-SW
22
4.4.3
Regression Testing
22
Data recording, reduction, and analysis
23
Notes
24
Appendix A
User requirements verification matrix
25
Appendix B
DARS (derived) requirements verification matrix
40
Appendix C
DPS (derived) requirements verification matrix
42
Abbreviations
APROPOS
Aerodynamic PROcessing and Presentation Open-ended System
BPPT
Badan Pengkajian dan Penerapan Teknologi (Agency for Assessment and

Application of Technology)
CIDL
Configuration Item Data List
COTS
Commercial Off-The-Shelf
CU
Conditioning Unit
DA
Data Acquisition
DAS
Data Acquistion System
DARS
Data Acquisition & Reduction System
DNW
Duits-Nederlandse Windtunnels (Dutch-German Wind tunnels)
DP
Data Processing
DPS
Data Processing System
DRACHME
Distributed Real-time Automation and Control Host Multi-platform Executive
DIL
Dual In-Line
EGOIST
Eerste Geheel Online Interface Systeem Tunnels (First Completely Online

Interface System Tunnels)
ESM
Engine Simulation Monitor
FMS
Facility Management System
GUI
Graphical User Interface
HMI
Human-Machine Interface
ICD
Interface Control Document
ILST
Indonesian Low Speed Tunnel
LAGG
Laboratorium Aero-Gasdinamika dan Getaran (Aero-Gas Dynamics and

Vibration Laboratory)
LRU
Line Replaceable Unit
MS
Milestone
NLR
Nationaal Lucht- en Ruimtevaartlaboratorium (National Aerospace Laboratory)
NTC
Negative Temperature Coefficient
NTP
Network Time Protocol
PC
Personal Computer
PUSPIPTEK
Pusat Penelitian Ilmu Pengetahuan dan Teknologi (Research Center for Science
and Technology)
RAID
Redundant Array of Independent Disks
RMS
Root-Mean-Square
TBD
To Be Decided
TPS
Turbo Propulsion Simulator
WAP
Wireless Access Point
WP
Work Package
This page is intentionally left blank.
1 Scope
1.1
Identification
This document is the Test Plan (TP) for the Upgraded ILST Data Acquisition and Data
Processing systems.
Identification of the ILST system:
System name:
ILST Data Acquisition and Data Processing systems upgrade
Acronym:
ILST upgrade
NLR system number:
AS064
Specification document: Ref [2] + Ref [3]
1.2
System Overview
This document is the Test Plan for the upgrade of the Data Acquisition and Data Processing
systems of the Indonesian Low Speed Tunnel (ILST) of the Aero-Gas Dynamics and Vibration
Laboratory (LAGG).
The ILST is in operation since 1988 and has been developed within a framework of bilateral
technological cooperation between the governments of Republic Indonesia, represented by the
Agency for Assessment and Application of Technology (BPPT), and the Netherlands,
represented by the National Aerospace Laboratory NLR.
The mentioned systems, actually consisting of the Data Acquisition & Reduction System
(DARS), the Calibration System and the Data Processing System (DPS), have been developed
by NLR and are already in service for more than 25 years. The last years however obsolescence
problems with the used HP 1000 and HP 9000 computers have become a major issue.
Besides this, the on-going development at NLR of the Conditioning Units (the main
instrumentation units at the ILST) has resulted in a huge increase of its capabilities, in particular
the replacement of the proprietary Data Acquisition Systems bus by standard Ethernet.
The replacement of the current HP computers by robust personal computers with Linux
operating system and the related transition to Ethernet as the standard communication bus for
wind tunnel instrumentation constitutes a major upgrade of the ILST Data Acquisition and Data
Processing systems.
The major objective of the Upgrade of the ILST Data Acquisition and Data Processing systems
is the replacement of the aging equipment for modern PC-based equipment, with the aim to
preserve the current functionality.
This objective will be achieved by the development of new interfaces for the existing
Conditioning units and associated equipment (PLC systems, Subscanner Controllers, etc.) and
the application of modern PC-based computer systems, with the Linux operating system. As
part of the project is identified the update of the existing software configuration items DA
software in the DARS host computer and the DP software in the DPS host computers.
During the project the hardware modifications as well as dedicated NLR furnished equipment
will be checked for its correct functioning during the development and manufacturing phase of
the project. As part of the overall check of the integrated functionality of the ILST Data
Acquisition and Data Processing systems a dedicated check process will be performed. This
process is described in this Test Plan. Since the emphasis of the functionality check is on the
software as the typical realization of the functionality (although the involved hardware is
checked implicitly) the test plan is based on Software Test Plan practices.
It must be noted that the formal check of the ILST upgrade as described in this document will
be performed in three dedicated areas:
1. the general user requirements, which are defined in the ILST upgrade proposal;
2. the data acquisition software as operational on the DARS host, which is effectively the
core functionality of the acquisition process;
3. the data processing software as operational on the DPS host, which is the core
functionality of processing raw data files.
The execution of the Final Acceptance tests as described in this document are projected to take
place at NLR in the Netherlands, before final delivery of the software (V2) for DARS and DPS
to the user/customer. The test results of the Final Acceptance tests will be documented in a Final
Acceptance Test Result report, see Ref. [5].
The tests or demonstrations to be accomplished at ILST in Indonesia will need to be defined at a
later date.
1.3
Document Overview
This test plan is structured according to DI-MCCR-80014A of Ref. [1]. The document is
organised as follows:
Chapter 1 gives the scope and overview of this document,
10
Chapter 2 gives a list of referenced documents,
Chapter 3 identifies all resources for the tests,
Chapter 4 presents the test classes and levels,
Chapter 5 describes the process of data analysis to use during and after tests,
Chapter 6 provides applicable notes,
Acronyms are provided in a dedicated list in the first part of the document,
Appendix A provides the user requirements verification matrix,
Appendix B provides the DARS (derived ) requirements verification matrix,
Appendix C provides the DPS (derived) requirements verification matrix.
1.4
Relationship to Other Plans
Not applicable.
11
2 Referenced Documents
2.1
Government Documents
[1] Defense System Software Development Standard DOD-STD-2167A, US Department of
Defense, 1986, DOD-STD-2167A.
2.2
Non-government Documents
[2] NLR Proposal SID: 7571 V2, Upgrade of the ILST Data Acquisition and Data
Processing systems (Revised version) February 15, 2013.
[3] Memo ASAQ-2013-008 Technical description and planning for the upgrade of the ILST
Data Acquisition and Data Processing systems, Version 1.1, October 2013
[4] Memo ASAQ-2013-025 AS064-ILST-ICD Version 1draft 6 Interface Control
Document for the ILST FMS, December 2013.
[5] NLR-CR-2013-551, Final Acceptance Test Result Report of the upgrade of the ILST
Data Acquisition and Data Processing systems.
[6] Memo ASAQ-2013-019 Software design document for the Data Acquisition System and
Calibration System.
[7] Memo ASAQ-2013-020 Software design document for the Data Processing System.
12
3 Test Environment
3.1 General
This chapter specifies the test environments which are needed for the verification of the user
requirements and the requirements for the various systems in the ILST Data Acquisition and
Data Processing systems. The software and hardware items needed for verification can be
divided in items for verification of user requirements, DARS requirements, and DPS
requirements. The various environments are divided in hardware and software items.
For the verification of the user requirements, an ILST simulation environment is available at
NLR, as depicted in Figure 1.
Figure 1. ILST simulation environment as available at NLR
13
3.2
Software Items
Table 1 lists all software items that are necessary to perform the DARS software testing
activities.
Table 1. DARS Software Items
Component
Purpose
Linux
FEA-CuMk3-EXT
Operating System
PC
Front End Acquisition task for CU
PC
Front End Acquisition task for DasHub PC
Front End Acquisition task for
FEA-DasHub
FEA-NtcHub
HW Platform
PC
NTCHub
FEA-PLC
FEA-ESM*
FEA-SC
Front End Acquisition task for PLC
PC
Front End Acquisition task for ESM
PC
Front End Acquisition task for
PC
Subscanner Controller
*
FEA-PSI
Front End Acquisition task for PSI
PC
Calibration application
PC
DataSelection
Data Selection Task
PC
CIT
Command Interface task
PC
Measurement Control
PC
Calculation of tunnel parameters
PC
Captures messages
PC
Strobe number editor
PC
(Real-Time) Simulation Environment
PC
CalCtl
MeasurementControl
Synthetic
MessageFile
StrobeEdit
CU simulator
DasHub simulator
PC
PC
PC
NTC simulator
PLC simulator
*
: Item is not part of Factory Acceptance Test, but tested at lower level.
14
Table 2 lists all software items that are necessary to perform the DPS software testing activities.
Table 2. DPS Software Items
Component
Purpose
HW Platform
Linux
Operating System
PC
Apropos
Data Processing System
PC
DARS Software Items
(Real-Time) Simulation
PC
Environment
DA Data files
Off-line simulation environment
PC
Table 3 lists all software items that are necessary to perform the user requirements testing
activities.
Table 3. User Requirements Software Items
Component
Purpose
HW Platform
Linux
Operating System
PC
DPS Software Items
(Real-Time) Simulation
PC
Environment
3.3
Hardware and Firmware Items
Table 4 lists all hardware items that are necessary to perform the DARS software testing
activities and DPS software testing activities. For the performance of user requirements tests, a
number of hardware items will be needed at NLR (delivery of the dedicated hardware has
already taken place to ILST). Table 4 specifies the list of hardware items.
15
Table 4. Hardware items for user requirements tests
Quantity
1
1
1
1
1
2
1
1
Item
Data Acquisitie
computer
Data Processing
computer
Data server
DA-DP Ethernet
switch
DARS Ethernet
switch
Parallel I/O card*
Subscanner
controller*
Calibration source
(Burster) *
Conditioning Unit
2
1
1
DAS Hub*
NTC DAS Hub*
NTC Conditioning*
Temperature
Interface*
Inclinometer
conditioning*
1
1
After DECEMBER
delivery:
General purpose
computer (ODIC)
General purpose
computer (ODIC)
General purpose
computer (ODIC)
General purpose
switch (ODIC)
General purpose
switch (ODIC)
NLR spare cards
Remarks
Dedicated computer, 2 GBE
ports for 2 networks
Dedicated computer
Dedicated computer
-
Try to borrow from DNW?
Proto ILST CU,

ETW CU
ETW DAS Hub
-
Low Level Interface*
High Level Interface*
Engine Monitor
System*
CU simulators
General purpose
computer (ODIC)

Try to borrow from DNW
(availability unsure)?
Develop an EMS simulator,
executing on simulator
laptop
CU simulator software is
ready, executes on simulator
laptop
*: Item is not part of Factory Acceptance Test, but tested at lower level.
3.4
Proprietary Nature, and Government Rights
Not applicable.
3.5
Installation, Testing, and Control
To be detailed in Final Acceptance Test Report, see Ref. [5].
16
Formal Qualification Test Identification
4.1 General Test Requirements

4.1.1 User Requirements
The objective of verification of the user requirements is to evaluate compliance with the
applicable requirements as documented in Ref [2].
The criteria for verification/test case definition are:
Coverage of all user requirements as stated in Ref [2] and Appendix A of this
document.
4.1.2 DARS software

The objective of testing the DARS software is to evaluate compliance and robustness with the
applicable DARS requirements as documented in Ref [2] and Appendix B.
The criteria for test case definition are:
Testing of complete functional chains between DARS I/O involving the DARS-SW
CSCI.
Focus on interfacing between DARS-SW CSCI and other CSCIs.
Verification of DARS-SW timing aspects.
Coverage of all DARS-SW system requirements as stated in Ref [2] and Appendix B of
this document.
4.1.3 DPS software

The objective of testing the DPS software is to evaluate compliance and robustness with the
applicable DPS requirements as documented in Ref [2] and Appendix C.
The criteria for test case definition are:
Testing of complete functional chains between DPS I/O involving the DPS-SW CSCI.
Coverage of all DPS-SW-system requirements as stated in Ref [2] and Appendix C of

this document.
4.2 Test Classes

The following test classes are identified:
1. Performance tests: Test cases shall be designed to show that the performance of the
DARS and DPS CSCIs is according to the requirements as stated in Ref [2].
17
2. Functional tests: Test cases shall be designed to show that the behaviour of the system
is according to the specified or designed behaviour, as defined by either high-level
requirements or low-level (software) requirements.
3. Robustness tests: Existing test cases shall be enhanced and further test cases shall be
designed to determine the extent to which the software continues to operate correctly
despite invalid inputs. The purpose is to show that the software does not do anything
that it is not specified to do. This step depends primarily on error guessing, relying upon
the experience of the test designer to anticipate problem areas.
4. Configuration tests: The DARS software can be configured by means of a dedicated
configuration file. Test cases will be defined to check the behaviour of DARS with
different configuration files.
5. Hardware/software tests: Tests shall be performed to verify that the software is
compatible with the target hardware.
4.3 Test Levels
The following three test levels are identified:
1. CSU/CSC level. Applicable test classes: 2,3,5
2. CSC integration level. Applicable test classes: 1,2,3,5
3. CSCI/CSCI validation level. Applicable test classes: 1,2,3,4,5
The test levels are described below.
4.3.1 CSU/CSC level
Not applicable.
4.3.2 CSC integration level
The purpose of (integration) testing of an integrated CSC is to load its executable object code in
to the target environment and to verify that the CSC correctly fulfils its functionalities. The
approach for the ILST-project is to load a complete CSCI executable and to test it on its merits,
using a host computer environment due to unavailability of the target computer(s).
For each integrated CSC of the ILST-project, verifications are performed on the following
points:
validation of high-level requirements that are to be qualified on the integration testing

level and allocated to one or more specific CSCs. These requirements typically refer to:
o
meeting of performances and constraints, interfaces with the hardware,
detection and processing of hardware failures, and
possible violations of software partitioning (if applicable).
18
sequencing of the elements issued from the CSC architecture,
interface between software functionalities (CSCs), and
possible incorrect initialization of variables and constants.
4.3.3 CSCI/CSCI validation level

4.3.3.1 ILST system level - User Requirements
The purpose of this level of testing is to validate that the ILST CSCI is compliant to the user
requirements as specified in Ref. [2] and in Ref. [4].
This level of verification consists of validation of the various system parts and conformance to
the ICD, to verify compliance with the high-level requirements as specified in Ref. [2] and Ref.
[4]. In most of the cases there is no need for an actual test: DARS and DPS related requirements
will be verified as part of these CSCI tests (see sections 4.3.3.2 and 4.3.3.3 of this document).
4.3.3.2 DARS CSCI
The purpose of this level of testing is to validate that the DARS CSCI is compliant and robust to
the software requirements as specified in Ref. [2] and the dedicated DARS software
requirements as specified in Appendix B of this document. Preferably these tests would be
executed on the actual target hardware, but this is not possible for the ILST project due to early
delivery of the actual target hardware. The CSCI level tests will therefore be mainly executed on
the ILST simulation environment at NLR.
This level of testing consists of a black box test of the software by simulation of the operational
inputs to verify compliance with the high-level requirements as specified in Ref. [2]. Test cases
may be derived using the same techniques as for testing on CSC integration level, using the
high-level requirements as reference.
During the verification program of the DA CSCI, a DARS test system will be used. This test
system will have the capability of simulating a number of outputs of Conditioning Unit (CU)
equipment and be able to collect also the output of the DARS. The output of the DARS can be
analysed and be verified for the correctness of the response. The system is able to perform
DARS functional and performance tests under manual control. Figure 2 shows a block diagram
of the system.
19
Figure 2. DARS test system setup
The DARS test system uses a COTS PC, executing Linux with at least the following interface
adapters:
- Ethernet I/O.
4.3.3.3 DPS CSCI
The purpose of this level of testing is to validate that the DPS CSCI running on the actual target
is compliant and robust to the software requirements as specified in Ref. [2] and the dedicated
DPS software requirements as specified in Appendix C of this document.
This level of testing consists of a black box test of the software by simulation of the operational
inputs to verify compliance with the high-level requirements of the SRS/IRS documents. Test
cases may be derived using the same techniques as for testing on CSC integration level, using
the high-level requirements as reference.
During the verification program of the DPS CSCI, archived raw data files and processed data
files from the ILST will be used. With these files the processing of the original, archived files
can be repeated with the DPS CSCI on a host PC. The archived processed data can be compared
with the output of the DPS CSCI, to conclude the correct functioning of the DPS CSCI. This
setup will be used to perform DPS functional and performance tests under manual control.
Figure 3 shows a block diagram of the system.
20
Figure 3. DPS test process flow
The DPS test system uses a COTS PC, executing Linux with at least the following interface
adapters:
- Ethernet I/O.
4.4 Test Definitions
The tests planned for DARS-SW and DPS-SW are described in the following sections. In this
section only a summary of the objective(s) and the methods used will be documented. The
verifications/tests will be further detailed into test cases and procedures, but not documented in
this test plan.
4.4.1 DARS-SW
Objective
The objective of this test is to verify that DARS produces the correct output data, based on the
input of, among others, CU generated data and user commands. The data is specified in Ref. [4]
and Ref. [6].
Requirements
DARS (derived) requirements verification matrix, see Appendix B.

Test Level
CSCI/CSCI validation level.

Test Class
Applicable test classes: 1, 2, 3, 4, 5.
21
Qualification Method
Any of the available qualification methods can be used in the process of verification of the
DARS software requirements. The methods available are: demonstration/test, analysis, and
inspection.
4.4.2 DPS-SW
Objective
The objective of this test is to verify that DPS produces the correct output data (format: file).
The correct data is specified in Ref. [4] and Ref. [7].
Requirements
DPS (derived) requirements verification matrix, see Appendix C.

Test Level
CSCI/CSCI validation level

Test Class
Applicable test classes: 1, 2, 3, 4, 5

Qualification Method
Any of the available qualification methods can be used in the process of verification of the DPS
software requirements. The methods available are: demonstration/test, analysis, and inspection.
4.4.3
Regression Testing
The objective of regression testing is to check the integrity of the system after a (software)
modification. Regression testing is not foreseen for the ILST software items 1.
The testing of the DPS software in itself can be seen as a large regression test, since the DPS software has been adapted for use
on a PC with Linux-based operating system software. The tests are based on comparison of the test results of the old and new
versions of the DPS software, typically a regression mechanism.
22
5 Data recording, reduction, and analysis

The test results will be recorded into test log files and are analysed by the relevant test tool or
the user to perform comparison with the specified expected test results.
The resulting test result files are analysed manually to check on the pass or fail of any test. All
test result files will be stored and either included or referenced in the Software Test Report. All
test results will be placed under configuration management.
23
6 Notes
There are no notes.
24
Appendix A User requirements verification matrix

A.1
Requirements identification
Ref. [2] defines the outline of the ILST-project. The user requirements are acquired from that
document by analysis of the provided text. The sentences of chapter 2 of Ref. [2] are
categorized as providing information or defining an actual requirement. The summary of the
requirements, without stating the informational sentences, is provided in Table 5. The
requirements are identified using the following identification method:
[<project proposal-id>v<X.Y>-<A.B>p<C>s<D>], with the following parameter explanation:
<project proposal-id>:
identification of the applicable proposal;
v<X.Y>:
applicable version of the proposal;
<A.B>:
section identification of the applicable proposal;
p<C>:
paragraph in the section;
s<D>:
sentence in the paragraph.
As an example:
[ILST-V2v1.0-2.2p2s1]
Project:
ILST
Proposal:
V2 version 1.0
Section:
2.2
Paragraph:
Sentence:
A.2
Requirements matrix
The following table (Table 5) provides the user requirements and defines the need for
validation, stating either Y (Yes) or N (No) in the column validation. If a validation is
identified, then the method for performing the validation is provided in the column method.
Table 5. Summary of user requirements
Seq.
UR-021
ID
[ILST-V2v1.02.2p2s1]
UR-022
Description
Except for both data
acquisition subnets, all
components of the DA-DP
network will consist of COTS
components.
The Host computers and GUI
computers will be
implemented as rugged
personal computers with Red
Hat Enterprise Linux x86_64
operating system with KDE
desktop software.
validation
N
25
method
Inspection list of delivered equipment
Seq.
UR-023
ID
UR-025
[ILST-V2v1.02.2.1p1s2]
UR-026
[ILST-V2v1.02.2.1p1s2a]
UR-027
[ILST-V2v1.02.2.1p1s2b]
UR-028
[ILST-V2v1.02.2.1p1s2c]
UR-029
[ILST-V2v1.02.2.1p1s2d]
UR-030
[ILST-V2v1.02.2.1p2s1]
UR-031
[ILST-V2v1.02.2.1p2s2]
UR-032
[ILST-V2v1.02.2.1p2s3 ]
UR-034
[ILST-V2v1.02.2.1p3s2]
UR-036
[ILST-V2v1.02.2.1p3s2a1]
UR-037
[ILST-V2v1.02.2.1p3s2a2]
UR-038
[ILST-V2v1.02.2.1p3s2a3]
UR-039
[ILST-V2v1.02.2.1p3s2b]
[ILST-V2v1.02.2.1p3s2c]
[ILST-V2v1.02.2.1p3s2d]
UR-040
UR-041
UR-044
[ILST-V2v1.0-
Description
Except for the wireless
devices, these computers will
also be equipped with dual
monitor outputs, in order to
allow connecting additional
GUI screens in the future.
The main DA-DP network
consists of six Host
computers:
The Data Acquisition &
Reduction System Host
(DARS Host) for control of all
measurement activities of
the Wind Tunnel Data
Acquisition (D/A) System;
The Calibration System Host
for all sensor calibration
purposes;
Two Data Processing System
Hosts (DPS Host) for all
online data processing tasks;
Two General-Purpose Data
Processing System Hosts
(DPS-GP Host) for all preprocessing and postprocessing tasks.
Data from the Host
computers is stored on a
dedicated Data Server with
RAID (Redundant Array of
Independent Disks).
To prevent a possible loss of
data during the execution of
a wind tunnel test, the
relevant measurement data
will initially be stored locally
on the respective Host
computers.
After completion of a run the
data will automatically be
transferred to the Data
Server.
The following GUI devices
are foreseen on the following
locations:
Two (extendable to four) GUI
devices for real-time wind
tunnel parameter data and
text (wall and desk);
Four (extendable to eight)
GUI devices for plots and
graphics (wall);
One Operator GUI device for
control and manual input of
parameters (desk);
Instrumentation Room: One
GUI device;
Customer Room: One GUI
device;
Test Section Hall: Two
wireless portable GUI
devices.
Figure 2 Proposed upgraded
validation
Y
method
Analysis: verify whether data transfer

from host computer to Data Server is
performed, inspect presence of Data
Server with RAID setup.
Analysis: verify that data is stored locally

during a test
Analysis: verify that the data is

automatically transferred after
completion of a test
See UR-034
See UR-034
See UR-034
See UR-034
See UR-034
See UR-034
architecture definition, no user
26
Seq.
ID
2.2.1p4s3]
Description
DA-DP network architecture
validation
UR-045
[ILST-V2v1.02.2.1p5s1]
UR-046
[ILST-V2v1.02.2.1p5s2]
UR-047
[ILST-V2v1.02.2.1p5s3]
[ILST-V2v1.02.2.1p6s1]
The network is also

connected to the ILST Video
System, in order to be able
to display overlay
information on monitors,
such as text and wind tunnel
parameters.
NLR will propose a video
matrix system to LAGG after
further discussion on the
detailed specifications, such
as the required type of
cameras and interface
requirements, pan & tilt
possibilities, audio
possibilities, etc.
Foreseen is the use of an
8x16 or 16x16 matrix switch.
A total of four printers are
connected to the DA-DP
network and its subnets:
A line printer to print raw
data in engineering units
from the DARS Host;
A line printer to print
calibrated data and
calculation results from the
DPS Hosts;
A colour laser printer for
general printing purposes;
A colour laser printer for the
Calibration D/A System
subnet.
A firewall between the DADP network and Internet is
installed to allow remote
support (for maintenance,
software upgrades, etc.) by
external parties, such as NLR.
The network includes two
dedicated subnets for data
acquisition; the DARS Host
and the Calibration System
Host each control the
networks for the Wind
Tunnel D/A System and the
Calibration D/A System
respectively.
For the control of the two
Subscanner Controllers, one
or more COTS parallel I/O
cards are necessary in the
DARS Host.
These controllers, on their
turn, control the Low Level
Scanners and the ScaniValve
units (both not drawn here
for clarity).
The ScaniValve equipment
will be replaced in the future
by PSI equipment.
UR-048
UR-049
[ILST-V2v1.02.2.1p6s1a]
UR-050
[ILST-V2v1.02.2.1p6s1b]
UR-051
[ILST-V2v1.02.2.1p6s1c]
[ILST-V2v1.02.2.1p6s1d]
UR-052
UR-053
[ILST-V2v1.02.2.1p6s1]
UR-054
[ILST-V2v1.02.2.2p1s1]
UR-062
[ILST-V2v1.02.2.2p3s1]
UR-063
[ILST-V2v1.02.2.2p3s2]
UR-064
[ILST-V2v1.02.2.2p3s3]
method
requirement
ILST video system test will be part of
Apropos test (ref XXX)
See UR-048
See UR-048
See UR-048
See UR-048
Analysis: verify that the network

architecture is defined in the ICD
Inspection: verify that the parallel I/O

cards are present in the ICD
December demo?
27
Seq.
UR-065
ID
[ILST-V2v1.02.2.2p4s1]
UR-066
[ILST-V2v1.02.2.2p4s2]
UR-068
[ILST-V2v1.02.2.2p4s4]
UR-069
[ILST-V2v1.02.2.2p4s5]
[ILST-V2v1.02.2.2p5s3]
UR-072
UR-073
[ILST-V2v1.02.2.2p6s1]
UR-075
[ILST-V2v1.02.2.3p1s1]
UR-076
[ILST-V2v1.02.2.3p1s1a]
UR-077
[ILST-V2v1.02.2.3p1s1b]
UR-078
[ILST-V2v1.02.2.3p1s1c]
UR-079
[ILST-V2v1.02.2.3p1s1d]
Description
Besides to the data
acquisition equipment, the
DARS Host is also connected
to the ILST PLC systems for
Model Control and Tunnel
Control.
The Central PLC (PLC System
#1 in Figure 3) acts as the
main hub for the other PLC
systems.
The existing RS-422 link
between the DARS Host and
the Central PLC will be
replaced by an Ethernet link
using TCP/IP and/or UDP/IP
communications protocol.
Figure 3 Proposed Wind
tunnel D/A System subnet
LAGG will be responsible for
the purchase of this card, the
development of the required
PLC software and the
composition (in cooperation
with NLR) of the Interface
Control Document (ICD).
The Time Code Generator
will be replaced by the
Network Time Protocol (NTP)
as a means to synchronize all
computers and to provide a
unique time stamp for the
acquired data points.
In general, the use of
Ethernet instead of the DASbus as the main data bus will
result in the following
changes of the Data
Acquisition and Data
Processing network
structure:
Replacement of the HP 1000
computers, HP 9000
computers and DAS
Interfaces by PCs with Linux;
Installation of standard
Ethernet switches to connect
the Conditioning Units and
DAS Hubs directly to the
DARS computer.
For the Conditioning Units:
Replacement of the DAS-bus
interface by an Ethernet
interface (see section
2.2.3.1);
For the remaining
unmodified equipment
(Calibration Generators,
Inclinometer Conditioning
Units, etc.): Connection to
Ethernet via a number of 8channel DAS Hubs (see
section 2.2.3.2).
validation
Y
From DARS point of view, there is only

interaction with the main hub.
Inspection: verify the network

architecture as defined in the ICD
architecture definition, no user

requirement
No NLR requirement
28
method
Test: verify that the DARS HOST can
receive data generated by the PLC
Simulator as defined in the ICD.
TBC: has this been configured? Default

setting in linux?
Seq.
UR-080
ID
[ILST-V2v1.02.2.3.1p1s1]
UR-081
[ILST-V2v1.02.2.3.1p1s1a]
UR-082
[ILST-V2v1.02.2.3.1p1s1b]
[ILST-V2v1.02.2.3.1p2s2]
UR-084
UR-088
[ILST-V2v1.02.2.3.1p3s2]
UR-089
[ILST-V2v1.02.2.3.1p3s3]
UR-091
[ILST-V2v1.02.2.3.1p4s2]
UR-093
[ILST-V2v1.02.2.3.1p4s4]
UR-094
[ILST-V2v1.02.2.3.1p4s5]
UR-095
[ILST-V2v1.02.2.3.1p4s6]
UR-096
[ILST-V2v1.02.2.3.1p4s7]
UR-097
[ILST-V2v1.02.2.3.2p1s1]
Description
The upgrade of the
Conditioning Units to
Ethernet requires two
modifications on the
Conditioning Units:
The replacement of the
current Digital Interface
board by an Ethernet
Interface board;
The modification of the rear
panel.
All the functions for onboard control, data
processing, data storage and
the interfacing with Ethernet
are implemented as
firmware in a COTS Linuxembedded computer
module, the Toradex Colibri.
Particular attention has been
paid to the synchronization
of measurements between
Conditioning Units, other
DAS-bus equipment and
external equipment.
This is supported by means
of an External Trigger input,
which replaces the original
DAS-bus Strobe signal, as
well as by several software
trigger options (using
Ethernet command
messages).
The modification of the rear
panel is required to replace
the current DAS-bus and
accompanying Strobe
connectors with Ethernet
and External Trigger input
connectors.
Two External Trigger input
connectors are placed to
allow daisy-chaining of
cabling between
Conditioning Units.
It should be noted that this
version has another type of
Calibration Bus connector.
Also, a cavity has been added
on top, intended glue a serial
number plate in.
The ILST Conditioning Units
will have comparable rear
panels.
With the DAS Hub (see
Figure 6) unmodified DASbus equipment can be
connected to Ethernet using
a communication protocol
very similar to the version
used in the Conditioning
Units.
validation
Y
method
Inspection: see Modification Kit
No user requirement
see UR-089
Test: verify that the DARS can provide a

trigger signal via ethernet. The CU itself is
not subject of this test, trigger
functionality is verified after modification
(TBC).
Test: verify that the DAS Hub can provide

data via ethernet to DARS (TBD
availability of test equipment).
29
Seq.
UR-098
ID
[ILST-V2v1.02.2.3.2p1s2]
UR-099
[ILST-V2v1.02.2.3.2p1s3]
UR-101
[ILST-V2v1.02.2.3.2p2s1]
UR-102
[ILST-V2v1.02.2.3.2p1s2]
UR-109
[ILST-V2v1.02.2.4.1p2s1]
UR-111
[ILST-V2v1.02.2.4.1p2s3]
UR-112
[ILST-V2v1.02.2.4.1p2s4]
UR-113
[ILST-V2v1.02.2.4.1p2s5]
[ILST-V2v1.02.2.4.2p1s1]
UR-114
UR-115
[ILST-V2v1.02.2.4.2p1s2]
UR-116
[ILST-V2v1.02.2.4.2p1s3]
UR-117
[ILST-V2v1.02.2.4.2p1s4]
Description
A maximum of eight DAS-bus
units, either Binary or BCD
devices, can be connected to
a single DAS Hub.
A common External Trigger
input is provided for all
connected devices.
For the NTC Conditioning a
dedicated DAS Hub is
available.
This unit connects a single
NTC Conditioning to Ethernet
and is equipped with an
additional Step/Home
connector.
For a proper implementation
it is necessary that the
actually applied excitation
voltage is measured for the
on-board calculation of the
normalized value (i.e. no
post-processing required)
and that this measurement
does not influence the
overall conversion speed of
the Conditioning Unit.
This requires a modification
on the Ethernet Interface
board (see section 2.2.3.1),
i.e. electronic circuitry will be
added to measure and
digitize the actual voltage, so
it can be read by the onboard computer module.
The firmware will also be
modified in order to
calculate the normalized
output, so it can be read by
the external DA computer.
Figure 7 Calculation of
normalized output
A total of fifteen additional
Conditioning Units are
offered to extend the
measurement capabilities of
the DA system.
Because of obsolescence
problems with electronic,
electromagnetic and
mechanical components a
number of printed-circuit
boards will have to be
redesigned.
The printed-circuit boards
will be regarded as Line
Replaceable Units (LRU) and
will therefore be functionally
the same to allow
exchanging with the original
boards.
The technical specifications
will also remain unchanged.
validation
N
No part of DARS, will not be validated
Inspection: list of delivered equipment
30
method
No change w.r.t. previous DAS bus units.
Seq.
UR-120
ID
[ILST-V2v1.02.2.4.3p2s1]
UR-121
[ILST-V2v1.02.2.4.3p2s2]
UR-122
[ILST-V2v1.02.2.4.3p2s3]
UR-123
[ILST-V2v1.02.2.4.4p1s1]
UR-124
[ILST-V2v1.02.2.4.4p1s2]
UR-125
[ILST-V2v1.02.2.4.4p1s3]
UR-126
[ILST-V2v1.02.2.4.4p1s4]
UR-129
[ILST-V2v1.02.2.4.5p1s2]
UR-130
[ILST-V2v1.02.2.4.5p1s3]
UR-133
[ILST-V2v1.02.2.4.5p2s2]
UR-134
[ILST-V2v1.02.2.4.5p2s2a]
[ILST-V2v1.02.2.4.5p2s2a1]
UR-135
UR-136
UR-137
[ILST-V2v1.02.2.4.5p2s2b]
[ILST-V2v1.02.2.4.5p2s2b1]
Description
The most efficient solution to
these problems is the
replacement of the used
Newport panel voltmeters
with a drop-in printedcircuit board replacement.
This new development will
have comparable
specifications as the original
Newport voltmeters.
It will also consist of a preamplifier section with fixed
gains of 1 and 100 in order to
support both types of
Newport voltmeters.
The two aging Calibration
Generators are replaced by
COTS devices.
Foreseen is the Burster
Model 4462 EN High
Precision Calibration Source
[1].
This device has at least the
same accuracy as the NLR
Calibration Generator.
The advantages are that this
device can be calibrated
regularly and economically at
any location worldwide, and
can that is can easily be
connected to the new DARS
computer.
This third-generation EMS
supports up to four TPS
engines and is much smaller
than the previous systems.
It is intended for use with the
updated DNW data
acquisition systems, i.e.
based on Ethernet
communication and has
therefore no DAS-bus and
Display-bus anymore.
The EMS consists of the
following main components
(see Figure 9):
Engine Monitor Host (EMH)
validation
Y
The Host consists of a

professional PC and provides
the Human-Machine
Interface (HMI) with a
number of GUIs, and all test
preparation and logging
functions.
Main Front-End (MFE)
The Main Front-End takes

care of all safety critical and
real-time functions such as
data acquisition of engine
parameters, limits
monitoring and emergency
method
N
N
N
Y
31
Seq.
UR-138
UR-139
ID
Description
switch-off in case of
overload.
[ILST-V2v1.02.2.4.5p2s2c]
[ILST-V2v1.02.2.4.5p2s2c1]
Remote Data Concentrator

(RDC)
The Remote Data
Concentrator has to be
mounted on-board the wind
tunnel model and is used to
limit the amount of wiring
between the model and the
EMS.
It acquires and conditions
the onboard temperature
signals from thermo-couples
and Pt-100 sensors.
Figure 9 Block diagram of the
EMS
LAGG intends to update the
current ScaniValve pressure
measurement equipment of
the Wind Tunnel D/A System
(see Figure 1) in the future
by a more modern system of
Pressure Systems Inc. (PSI).
NLR will incorporate the
required external interface in
the DARS DA software (see
section 2.2.5) as soon as the
hardware has been selected
by LAGG.
The software for the DARS
and Calibration System Host
computers will be based on
the DRACHME kernel.
In short, the DRACHME
kernel software provides the
following services:
Automatic (re-)configuration
of nodes;
Real-time distribution blocks
of data between tasks;
Distribution and routing of
commands between tasks;
One-to-many distribution of
text messages between
tasks.
Together with a number of
open source and industry
standard toolboxes, the
DRACHME kernel can be
used to develop any Facility
Management System (FMS)
for wind tunnel applications
and may consists of one or
more nodes.
The ILST DARS software will
be developed using GNU and
Linux tools.
The specific GUI tasks will be
developed using easy to use
open source development
UR-140
[ILST-V2v1.02.2.4.5p2s2c2]
UR-141
[ILST-V2v1.02.2.4.5p2s3]
[ILST-V2v1.02.2.4.6p1s1]
UR-142
UR-144
[ILST-V2v1.02.2.4.6p1s3]
UR-146
[ILST-V2v1.02.2.5p1s1]
UR-155
[ILST-V2v1.02.2.5p2s7]
UR-156
[ILST-V2v1.02.2.5p2s7a]
[ILST-V2v1.02.2.5p2s7b]
[ILST-V2v1.02.2.5p2s7c]
[ILST-V2v1.02.2.5p2s7d]
UR-157
UR-158
UR-159
UR-160
[ILST-V2v1.02.2.5p3s1]
UR-162
[ILST-V2v1.02.2.5p4s2]
UR-163
[ILST-V2v1.02.2.5p4s3]
validation
method
N
N
32
Inspection: TBD verify Drachme in

application title or About menu?
See UR-156 to/incl UR-159
Test: TBD
Test: TBD
Test: TBD
Test: TBD
See UR-156
No user requirement
No user requirement
Seq.
UR-164
UR-165
UR-168
UR-169
ID
Description
tools and applications.
[ILST-V2v1.02.2.5p4s4]
[ILST-V2v1.02.2.5p5s1]
The development package

will be used is Qt.
The software for the
Calibration System (CS) will
be more or less identical to
the software of the DARS,
although the Calibration
System will have less
external interfaces and less
GUI tasks.
Main control task
(DRACHME); Node: DARS, CS
Graphical User Interfaces;
External interface: Ethernet;
Node DARS, CS
Control of the DARS line
printer; External interface:
Ethernet; Node DARS
DPS Host interface ; External
interface: Ethernet; Node
DARS
Control of the Subscanner
Controllers ; External
interface: Parallel I/O; Node
DARS
Control of the PSI system ;
Node DARS
Control the ILST Wind Tunnel
D/A System hardware;
Node DARS
Control the ILST Calibration
System D/A hardware;
Node CS
Interface with the Calibration
Database (CDB); External
interface: Ethernet; Node:
DARS, CS
Interface with the ILST PLC
systems; External interface:
Ethernet; Node: DARS
Control of the Burster
calibration source; External
interface: RS-232; Node:
DARS, CS
Control of the Configurable
EMS; External interface:
Ethernet; Node: DARS
The software for the DPS
Host computers is based on
the APROPOS C07 data
processing software, ported
to 64-bit Linux.
Since the accompanying
original user interface and
plotting software packages
are not supported anymore,
these components will be re-
[ILST-V2v1.02.2.5p5s3a]
[ILST-V2v1.02.2.5p5s3b]
UR-170
[ILST-V2v1.02.2.5p5s3c]
UR-171
[ILST-V2v1.02.2.5p5s3d]
UR-172
[ILST-V2v1.02.2.5p5s3e]
UR-173
[ILST-V2v1.02.2.5p5s3f]
UR-174
[ILST-V2v1.02.2.5p5s3g]
UR-175
[ILST-V2v1.02.2.5p5s3h]
UR-176
[ILST-V2v1.02.2.5p5s3i]
UR-177
[ILST-V2v1.02.2.5p5s3j]
UR-178
[ILST-V2v1.02.2.5p5s3k]
UR-179
[ILST-V2v1.02.2.5p5s3l]
UR-180
[ILST-V2v1.02.2.6p1s1]
UR-181
[ILST-V2v1.02.2.6p1s2]
validation
No user requirement
Inspection: verify that DRACHME is used

for both CS as well as DARS.
Inspection: verify that identified task is

performed on the identified node(s)
33
method










Inspection: verify that the DPS software

has Apropos as its origin. Verify that the
DPS software runs on 64-bit Linux.
Test: verify that the UI (NLR tcl/tk GUI) is

able to control the DPS software. Verify
that the DPS can generate plots using the
plotting software.
Seq.
UR-182
UR-183
ID
Description
developed using open source
and license free tools.
validation
[ILST-V2v1.02.2.6p1s3]
[ILST-V2v1.02.2.6p1s4]
For the GUIs, Qt will be used.
The choice for the plotting

facilities has yet to be
determined.
Ported APROPOS C07 to
Linux x86_64; Node DPS,
DPS-GP
Graphical User Interfaces;
Node DPS, DPS-GP
Plot interface; Node DPS,
DPS-GP
Control of the DPS line
printer; External interface:
Ethernet; Node DPS, DPS-GP
DARS Host interface;
Node DPS
Interface with the Calibration
Database (CDB); External
interface: Ethernet; Node
DPS, DPS-GP
Interface with the ILST Video
System; External interface:
Ethernet or other standard
data bus; Node DPS
Besides the hardware and
software components, also
the relevant documentation
will be delivered to LAGG in
order to provide the
information needed for
LAGG to be self-supporting.
DARS Host; Quantity 1
DARS Host; Personal

computer with Linux
DARS Host; 24 widescreen
monitor
DARS Host; Two Ethernet
ports
DARS Host; Two parallel I/O
cards
DARS Host; Dual monitor
ouput
Calibration System Host;
Quantity 1
Personal computer with
Linux
Calibration System Host; 24
widescreen monitor
Calibration System Host; Two
Ethernet ports
Dual monitor output
DPS Host/DPS-GP Host;
Quantity 4
UR-186
[ILST-V2v1.02.2.6p1s6a]
UR-187
[ILST-V2v1.02.2.6p1s6b]
[ILST-V2v1.02.2.6p1s6c]
[ILST-V2v1.02.2.6p1s6d]
UR-188
UR-189
UR-190
[ILST-V2v1.02.2.6p1s6e]
UR-191
[ILST-V2v1.02.2.6p1s6f]
UR-192
[ILST-V2v1.02.2.6p1s6g]
UR-194
[ILST-V2v1.02.2.7p1s2]
UR-197
[ILST-V2v1.02.2.7p1s4a1]
[ILST-V2v1.02.2.7p1s4a2]
[ILST-V2v1.02.2.7p1s4a3]
[ILST-V2v1.02.2.7p1s4a4]
[ILST-V2v1.02.2.7p1s4a5]
[ILST-V2v1.02.2.7p1s4a6]
[ILST-V2v1.02.2.7p1s4b1]
[ILST-V2v1.02.2.7p1s4b2]
UR-198
UR-199
UR-200
UR-201
UR-202
UR-203
UR-204
UR-205
UR-206
UR-207
UR-208
[ILST-V2v1.02.2.7p1s4b3]
[ILST-V2v1.02.2.7p1s4b4]
[ILST-V2v1.02.2.7p1s4b5]
[ILST-V2v1.02.2.7p1s4c1]
No NLR requirement


Y
Y
34
method



See UR-269 up to/incl UR-284
Seq.
UR-209
UR-210
UR-211
UR-212
UR-213
UR-214
UR-215
UR-216
UR-217
ID
[ILST-V2v1.02.2.7p1s4c2]
[ILST-V2v1.02.2.7p1s4c3]
[ILST-V2v1.02.2.7p1s4c4]
[ILST-V2v1.02.2.7p1s4d1]
[ILST-V2v1.02.2.7p1s4d2]
[ILST-V2v1.02.2.7p1s4d3]
[ILST-V2v1.02.2.7p1s4d4]
[ILST-V2v1.02.2.7p1s4e1]
[ILST-V2v1.02.2.7p1s4e2]
UR-218
[ILST-V2v1.02.2.7p1s4e3]
UR-219
[ILST-V2v1.02.2.7p1s4e4]
[ILST-V2v1.02.2.7p1s4f1]
[ILST-V2v1.02.2.7p1s4f2]
UR-220
UR-221
UR-222
[ILST-V2v1.02.2.7p1s4f3]
UR-223
[ILST-V2v1.02.2.7p1s4g1]
[ILST-V2v1.02.2.7p1s4g2]
UR-224
UR-225
UR-226
UR-227
UR-228
UR-229
UR-230
UR-231
UR-232
UR-233
[ILST-V2v1.02.2.7p1s4h1]
[ILST-V2v1.02.2.7p1s4h2]
[ILST-V2v1.02.2.7p1s4i1]
[ILST-V2v1.02.2.7p1s4i2]
[ILST-V2v1.02.2.7p1s4i3]
[ILST-V2v1.02.2.7p1s4j1]
[ILST-V2v1.02.2.7p1s4j2]
[ILST-V2v1.02.2.7p1s4k1]
[ILST-V2v1.02.2.7p1s4k2]
Description
Linux
24 widescreen monitor
validation
Y
method
Dual monitor output
GUI computers (for tunnel

parameters, text, plots and
graphics); Quantity: 8
GUI computers; Personal
computer with Linux
GUI computers; Dual monitor
output
GUI computers; Widescreen
monitors: Control Room (6);
Instrumentation Room (1);
Customer Room (1)
Operator GUI computer;
Quantity: 1
Linux
Touch screen or widescreen
monitor
Dual monitor output
Portable GUI computer;
Quantity: 2
Ruggedized laptop computer
with Linux
Tablet computer (iOS or
Android)
Data server; Quantity: 1
Data server; Network data

storage computer server
with RAID
Wireless Access Point (WAP);
Quantity: 1
Wireless Access Point (WAP);
To be mounted in the Test
Section Hall
Line printer; Quantity: 2
Line printer; DPS Line Printer

and DARS Line Printer
Line printer; Ethernet and
USB ports
Colour laser printer;
Quantity: 2
Colour laser printer; For DADP network and Calibration
D/A System
Gigabit switch; Quantity: 5
Gigabit switch; 24-port

Gigabit Ethernet switches:
DA-DP network (1); Wind
Tunnel D/A System (3);
Calibration D/A System (1)
35
Seq.
UR-234
UR-235
UR-237
UR-238
UR-239
UR-240
UR-241
UR-242
UR-243
UR-244
UR-245
UR-246
ID
[ILST-V2v1.02.2.7p1s4l1]
[ILST-V2v1.02.2.7p1s4l2]
[ILST-V2v1.02.2.7p1s5a1]
[ILST-V2v1.02.2.7p1s5a2]
[ILST-V2v1.02.2.7p1s5b1]
[ILST-V2v1.02.2.7p1s5b2]
[ILST-V2v1.02.2.7p1s5c1]
[ILST-V2v1.02.2.7p1s5d1]
[ILST-V2v1.02.2.7p1s5e1]
[ILST-V2v1.02.2.7p1s5e2]
[ILST-V2v1.02.2.7p1s5f1]
[ILST-V2v1.02.2.7p1s5f2]
UR-248
[ILST-V2v1.02.2.7p1s6a1]
UR-249
[ILST-V2v1.02.2.7p1s6a2]
UR-250
[ILST-V2v1.02.2.7p1s6a3]
UR-252
[ILST-V2v1.02.2.7p1s6b1]
[ILST-V2v1.02.2.7p1s6c1]
[ILST-V2v1.02.2.7p1s6d1]
[ILST-V2v1.02.2.7p1s6e1]
UR-255
UR-257
UR-260
UR-263
UR-265
UR-269
[ILST-V2v1.02.2.7p1s6f1]
[ILST-V2v1.02.2.7p1s6g1]
[ILST-V2v1.02.2.7p1s7a]
Description
Firewall; Quantity: 1
validation
Y
method
Firewall; To enable remote

support via a secured
connection
Software packages for the
Host computers; Quantity: 6
Host computers: DARS Host,
Calibration System Host, DPS
Host, DPS-GPS Host
GUI computers; Quantity: 10
GUI computers: GUI
computers (8), Operator GUI
computer (1) and wireless
GUI laptop computer (1)
Software package for the GUI
tablet; Quantity:1
Software package for the
data server; Quantity: 1
Operating System software
package; Quantity: 1
Operating System software
package; Linux Operating
System for all DA-DP
computers, including 17
licenses
Test software; Quantity: 1
Inspection: list of delivered software
Test software: For testing of

the upgraded Conditioning
Units
Modification kits for the
Conditioning Unit Mk3 DAS;
Quantity: 50
Ethernet Interface board, as
a one-to-one replacement
for the current Digital
Interface board
Partial rear panel to mount
on the current rear panel
DAS Hubs; Quantity: 5
NTC DAS Hub; Quantity: 1
Additional Conditioning
Units; Quantity: 15
Modification kits for the Low
Level and High Level
Interfaces; Quantity: 18
Calibration Sources;
Quantity: 2
Engine Monitor System;
Quantity: 1
Instruction manual for the
upgrade of the Conditioning
Unit Mark III
Inspection: list of delivered

documentation
36
Seq.
UR-270
ID
[ILST-V2v1.02.2.7p1s7b]
UR-271
[ILST-V2v1.02.2.7p1s7c]
UR-272
[ILST-V2v1.02.2.7p1s7d]
UR-273
[ILST-V2v1.02.2.7p1s7e]
UR-274
[ILST-V2v1.02.2.7p1s7f]
UR-275
[ILST-V2v1.02.2.7p1s7g]
UR-276
[ILST-V2v1.02.2.7p1s7h]
UR-277
[ILST-V2v1.02.2.7p1s7i]
UR-278
[ILST-V2v1.02.2.7p1s7j]
[ILST-V2v1.02.2.7p1s7k]
[ILST-V2v1.02.2.7p1s7l]
UR-279
UR-280
UR-281
UR-282
UR-283
UR-284
UR-286
[ILST-V2v1.02.2.7p1s7m]
[ILST-V2v1.02.2.7p1s7n]
[ILST-V2v1.02.2.7p1s7o]
[ILST-V2v1.02.2.7p1s7p]
[ILST-V2v1.02.2.8p1s2a]
UR-287
[ILST-V2v1.02.2.8p1s2b]
UR-288
[ILST-V2v1.02.2.8p1s2b1]
[ILST-V2v1.02.2.8p1s2b2]
UR-289
UR-290
[ILST-V2v1.02.2.8p1s2b3]
UR-291
[ILST-V2v1.02.2.8p1s2b4]
Description
upgrade of the Low Level
Interface
upgrade of the High Level
Interface
Documentation set for the
upgraded Conditioning Unit
Mark III
upgraded Low Level
Interface
upgraded High Level
Interface
Software design document
for the Data Acquisition
System and Calibration
System
Software design document
for the Data Processing
System
User manual for the Data
Acquisition System and the
Calibration System
User manual for the Data
Processing System
User manual for the Engine
Monitor System
Binder with all manuals all
COTS hardware and software
components
Software installation
instructions for all computers
Configuration Item Data List
(CIDL)
Final Acceptance Test Plan
validation
Y
method
documentation

documentation

documentation

documentation

documentation

documentation

documentation

documentation

documentation
documentation
documentation
Final Acceptance Test Report
LAGG is requested to send

one unmodified Conditioning
Unit, one Low Level Interface
and one High Level Interface.
These three units will be
modified at NLR and will be
used for:
Testing of the DA and DP
software;
Verification of the
normalized output
modification on the
Conditioning Units (see
section 2.2.4.1);
Verification of the
refurbishment on the Low
Level and High Level
Interfaces (see section
2.2.4.3) and the proper
operation in combination
with the DAS Hub;
A means to develop the
modification kits for these

documentation
documentation
documentation
documentation
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
Y
Y
Y
Y
Y
37
Seq.
ID
Description
units.
UR-292
[ILST-V2v1.02.2.8p1s3a]
UR-293
[INFO-V2v1.02.2.8p1s3b]
UR-294
[ILST-V2v1.02.2.8p1s4a]
UR-295
[ILST-V2v1.02.2.8p1s4b]
UR-296
[ILST-V2v1.02.2.8p1s4c]
UR-297
[ILST-V2v1.02.2.8p1s4d]
[ILST-V2v1.02.2.8p1s4e]
LAGG is also requested to

provide a data set of an
existing wind tunnel test,
consisting both of raw data
and results, in order to
compare and verify the
behaviour of the original
system with the behaviour of
the upgraded system (in
particular the DARS-DPS
chain).
This NLR in-house testing will
assure a proper operation of
the DA-DP network before
delivery to LAGG.
Finally, LAGG is requested to
deliver the Interface Control
Document of the interface
between the PLC systems
and the DARS Host computer
(DARS-PLC ICD).
This document will describe
the interface in detail, both
with respect to protocol and
timing.
An initial version will be used
as a basis to discuss the
optimal and most efficient
interface implementation on
both sides.
A template for the ICD will
be provided by NLR.
After mutual agreement the
final document will be the
basis for NLR to develop a
PLC System Interface
Simulator that will be used
to test the required external
interface software for the
DARS computer.
A part of the software
development activities will
be performed by LAGG.
This concerns the
development of the
Graphical User Interfaces
(GUIs) of the DA and DP
systems, the development of
the DP plotting facilities and
the development of the DP
software interface with the
ILST Video System.
The joint development of
software by NLR and LAGG
has been defined such, that
it is possible to describe a
clear and well-defined
software interface between
the activities of both parties.
NLR will compile the
interface definitions, which
will be based on the
UR-298
UR-300
[ILST-V2v1.02.2.9p1s1]
UR-301
[ILST-V2v1.02.2.9p1s2]
UR-302
[ILST-V2v1.02.2.9p2s1]
UR-303
[ILST-V2v1.02.2.9p2s2]
validation
38
method
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
Seq.
UR-304
ID
[ILST-V2v1.02.2.9p2s3]
Description
DRACHME and APROPOS
software, and propose this to
LAGG.
After mutual agreement, the
software development
activities of both parties can
commence and can be
performed more or less
independently and will
therefore not interfere with
each other.
validation
39
method
No user requirement
Appendix B DARS (derived) requirements verification matrix

B.1
The summary of the derived requirements of the DARS is provided in Table 6. The
requirements are identified using the following identification method:
[<type><source>-<part>-<sequence-id>-v<X.Y>], with the following parameter explanation:
<type>:
<source>:
source identification
<part>:
functional part
<sequence id>:
sequence number
v<X.Y>:
applicable version of the proposal.
As an example:
[SWDR-DARS-1-v1.0]
Type:
SW (Software)
Source:
DR (Derived Requirement)
Part:
DARS
Sequence id:
Version:
1.0
B.2
Requirements matrix
The following table (Table 6) provides the derived requirements for the DARS software.
Table 6. Software Derived Requirements DARS
Derived Requirements
DP-Req-number
SWDR-DARS-1-v1.0
SWDR-DARS-2-v1.0
SWDR-DARS-3-v1.0
SWDR-DARS-4-v1.0
SWDR-DARS-5-v1.0
SWDR-DARS-6-v1.0
SWDR-DARS-7-v1.0
SWDR-DARS-8-v1.0
SWDR-DARS-9-v1.0
SWDR-DARS-10-v1.0
Requirement text
In order to allow for a standard numbering scheme for connection of measurement equipment to the
Data Acquisition process, the Data Acquisition process shall support 160 measurement channels, of
which maximal 125 can be measured and processed simultaneously.
The times at which the physical quantities are sampled for one datarecord will be no more than 50
milliseconds apart, except for the quantities sampled by the Computer-aided Tunnel Control process.
It shall be possible that measurement values be averaged in the Data Acquisition process over an
operator -specified number of samples, to produce one averaged measurement value.
It shall be possible that a number of 20 measurement values and associated ranges be entered manually
via thumbwheel switches.
The Data Acquisition process shall keep a backup copy of all measurement data sent to the Data
Processing process, except the measurement data read out for real-time display.
The data acquisition process shall signal all detected malfunctions of its measurement equipment, such
as: power off
as: local control instead of computer control
as: overload of conditioning units
as: wrong filter setting
as: malfunctioning of subscanner devices
40
Derived Requirements
DP-Req-number
SWDR-DARS-11-v1.0
SWDR-DARS-12-v1.0
SWDR-DARS-13-v1.0
SWDR-DARS-14-v1.0
SWDR-DARS-15-v1.0
SWDR-DARS-17-v1.0
SWDR-DARS-21-v1.0
SWDR-DARS-22-v1.0
Requirement text
The data acquisition process shall check on a correct sequence of measurement commands during a run
Each measurement run shall start with a precycle record containing run-related constants, that are
entered by the DA-operator
Idle conversion of the sensor output shall have a rate of at least 2 times per second
Data transfer to the Data Processing process shall be possible: immediately after each measurement
(on-line transmission)
Data transfer to the Data Processing process shall be possible: at any time after a run (off-line
transmission of backup data)
Data that has been measured for Real-time Display processing can only be transmitted immediately
after the measurement
Status messages of the data acquisition process shall be sent to the data acquisition operator and to the
Computer-aided Tunnel Control process when the latter is commanding the Data Acquisition process
The data acquisition process shall be able to compute and display the current values of Ma, Re, V and q
at least twice per second.
41
Appendix C DPS (derived) requirements verification matrix

C.1
The summary of the derived requirements of the DPS is provided in Error! Reference source
not found.. The requirements are identified using the following identification method:
[<type><source>-<part>-<sequence-id>-v<X.Y>], with the following parameter explanation:
<type>:
<source>:
source identification
<part>:
functional part
<sequence id>:
sequence number
v<X.Y>:
applicable version of the proposal.
As an example:
[SWDR-DP-1-v1.0]
Type:
SW (Software)
Source:
DR (Derived Requirement)
Part:
DP (DPS)
Sequence id:
Version:
1.0
C.2
Requirements matrix
No derived requirements for the DPS software have been determined. The DPS software has
been ported to another platform, but has in essence the same functionality. This is particularly
valid for the internal functionality. The interface functionality has seen a number of changes,
such as the delivery of the results of data processing via udp sockets in xml format. Validation
of the DPS software will be performed with existing data sets of wind tunnel measurements.
42

AS064-ILST-FATP Issue 1 - 1 - Final Acceptance Test Plan - Signed

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

AS064-ILST-FATP Issue 1 - 1 - Final Acceptance Test Plan - Signed

Caricato da

Copyright:

Formati disponibili

Nationaal Lucht- en Ruimtevaartlaboratorium

National Aerospace Laboratory NLR

Final Acceptance Test Plan of the Upgrade of the

Nationaal Lucht- en Ruimtevaartlaboratorium

Nationaal Lucht- en Ruimtevaartlaboratorium

Final Acceptance Test Plan of the Upgrade of the ILST Data

check process will be performed.

Nationaal Lucht- en Ruimtevaartlaboratorium, National Aerospace Laboratory NLR

Anthony Fokkerweg 2, 1059 CM Amsterdam,

Nationaal Lucht- en Ruimtevaartlaboratorium

Final Acceptance Test Plan of the Upgrade of the

Pro-Innov Technology Indonesia

Relationship to Other Plans

Hardware and Firmware Items

Proprietary Nature, and Government Rights

Installation, Testing, and Control

Formal Qualification Test Identification

General Test Requirements

CSC integration level

CSCI/CSCI validation level

Data recording, reduction, and analysis

User requirements verification matrix

DARS (derived) requirements verification matrix

DPS (derived) requirements verification matrix

Aerodynamic PROcessing and Presentation Open-ended System

Badan Pengkajian dan Penerapan Teknologi (Agency for Assessment and

Configuration Item Data List

Data Acquistion System

Data Acquisition & Reduction System

Duits-Nederlandse Windtunnels (Dutch-German Wind tunnels)

Data Processing System

Distributed Real-time Automation and Control Host Multi-platform Executive

Eerste Geheel Online Interface Systeem Tunnels (First Completely Online

Engine Simulation Monitor

Facility Management System

Graphical User Interface

Interface Control Document

Indonesian Low Speed Tunnel

Laboratorium Aero-Gasdinamika dan Getaran (Aero-Gas Dynamics and

Line Replaceable Unit

Nationaal Lucht- en Ruimtevaartlaboratorium (National Aerospace Laboratory)

Negative Temperature Coefficient

Network Time Protocol

Redundant Array of Independent Disks

Turbo Propulsion Simulator

Wireless Access Point

This page is intentionally left blank.

Chapter 1 gives the scope and overview of this document,

Chapter 2 gives a list of referenced documents,

Chapter 3 identifies all resources for the tests,

Chapter 4 presents the test classes and levels,

Chapter 6 provides applicable notes,

Appendix A provides the user requirements verification matrix,

Appendix B provides the DARS (derived ) requirements verification matrix,

Appendix C provides the DPS (derived) requirements verification matrix.

Relationship to Other Plans

Figure 1. ILST simulation environment as available at NLR

Front End Acquisition task for CU

Front End Acquisition task for DasHub PC

Front End Acquisition task for

Front End Acquisition task for PLC

Front End Acquisition task for ESM

Front End Acquisition task for