Академический Документы
Профессиональный Документы
Культура Документы
NLR-CR-2013-308-Issue-1.1
UNCLASSIFIED
Executive summary
UNCLASSIFIED
Report no.
NLR-CR-2013-308-Issue-1.1
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
UNCLASSIFIED
NLR-CR-2013-308-Issue-1.1
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
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:
NLR-CR-2013-308-Issue-1.1
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.
NLR-CR-2013-308-Issue-1.1
Contents
1
Scope
1.1
Identification
1.2
System Overview
1.3
Document Overview
10
1.4
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
15
3.4
16
3.5
16
17
4.1
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
18
4.3.3
19
4.4
Test Definitions
21
4.4.1
DARS-SW
21
4.4.2
DPS-SW
22
4.4.3
Regression Testing
22
23
Notes
24
NLR-CR-2013-308-Issue-1.1
Appendix A
25
Appendix B
40
Appendix C
42
NLR-CR-2013-308-Issue-1.1
Abbreviations
APROPOS
BPPT
CIDL
COTS
Commercial Off-The-Shelf
CU
Conditioning Unit
DA
Data Acquisition
DAS
DARS
DNW
DP
Data Processing
DPS
DRACHME
DIL
Dual In-Line
EGOIST
ESM
FMS
GUI
HMI
Human-Machine Interface
ICD
ILST
LAGG
LRU
MS
Milestone
NLR
NTC
NTP
PC
Personal Computer
PUSPIPTEK
Pusat Penelitian Ilmu Pengetahuan dan Teknologi (Research Center for Science
and Technology)
RAID
RMS
Root-Mean-Square
TBD
To Be Decided
NLR-CR-2013-308-Issue-1.1
TPS
WAP
WP
Work Package
NLR-CR-2013-308-Issue-1.1
NLR-CR-2013-308-Issue-1.1
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.
NLR-CR-2013-308-Issue-1.1
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:
10
NLR-CR-2013-308-Issue-1.1
Chapter 5 describes the process of data analysis to use during and after tests,
Acronyms are provided in a dedicated list in the first part of the document,
1.4
Not applicable.
11
NLR-CR-2013-308-Issue-1.1
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
NLR-CR-2013-308-Issue-1.1
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.
13
NLR-CR-2013-308-Issue-1.1
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
PC
FEA-DasHub
FEA-NtcHub
HW Platform
PC
NTCHub
FEA-PLC
FEA-ESM*
FEA-SC
PC
PC
PC
Subscanner Controller
*
FEA-PSI
PC
Calibration application
PC
DataSelection
PC
CIT
PC
Measurement Control
PC
PC
Captures messages
PC
PC
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
NLR-CR-2013-308-Issue-1.1
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
PC
(Real-Time) Simulation
PC
Environment
DA Data files
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
(Real-Time) Simulation
PC
Environment
3.3
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
NLR-CR-2013-308-Issue-1.1
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
-
Engine Monitor
System*
CU simulators
General purpose
computer (ODIC)
*: Item is not part of Factory Acceptance Test, but tested at lower level.
3.4
Not applicable.
3.5
16
NLR-CR-2013-308-Issue-1.1
Coverage of all user requirements as stated in Ref [2] and Appendix A of this
document.
Testing of complete functional chains between DARS I/O involving the DARS-SW
CSCI.
Coverage of all DARS-SW system requirements as stated in Ref [2] and Appendix B of
this document.
Testing of complete functional chains between DPS I/O involving the DPS-SW CSCI.
17
NLR-CR-2013-308-Issue-1.1
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:
18
NLR-CR-2013-308-Issue-1.1
19
NLR-CR-2013-308-Issue-1.1
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
NLR-CR-2013-308-Issue-1.1
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
21
NLR-CR-2013-308-Issue-1.1
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
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
NLR-CR-2013-308-Issue-1.1
23
NLR-CR-2013-308-Issue-1.1
6 Notes
There are no notes.
24
NLR-CR-2013-308-Issue-1.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>:
v<X.Y>:
<A.B>:
p<C>:
s<D>:
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
[ILST-V2v1.02.2p2s2]
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
NLR-CR-2013-308-Issue-1.1
Seq.
UR-023
ID
[ILST-V2v1.02.2p2s3]
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
Inspection list of delivered equipment
See UR-034
See UR-034
See UR-034
See UR-034
See UR-034
See UR-034
26
NLR-CR-2013-308-Issue-1.1
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]
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
December demo?
27
NLR-CR-2013-308-Issue-1.1
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
28
method
Test: verify that the DARS HOST can
receive data generated by the PLC
Simulator as defined in the ICD.
NLR-CR-2013-308-Issue-1.1
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
29
NLR-CR-2013-308-Issue-1.1
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
30
method
No change w.r.t. previous DAS bus units.
NLR-CR-2013-308-Issue-1.1
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
method
Inspection: see Modification Kit
N
N
N
Y
31
NLR-CR-2013-308-Issue-1.1
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]
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
Test: TBD
Test: TBD
Test: TBD
Test: TBD
See UR-156
No user requirement
No user requirement
NLR-CR-2013-308-Issue-1.1
Seq.
UR-164
UR-165
UR-168
UR-169
ID
Description
tools and applications.
[ILST-V2v1.02.2.5p4s4]
[ILST-V2v1.02.2.5p5s1]
[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
33
method
NLR-CR-2013-308-Issue-1.1
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]
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
NLR-CR-2013-308-Issue-1.1
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
Personal computer with
Linux
24 widescreen monitor
validation
Y
method
Inspection list of delivered equipment
35
NLR-CR-2013-308-Issue-1.1
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
Inspection list of delivered equipment
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
36
NLR-CR-2013-308-Issue-1.1
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
Instruction manual for the
upgrade of the Low Level
Interface
Instruction manual for the
upgrade of the High Level
Interface
Documentation set for the
upgraded Conditioning Unit
Mark III
Documentation set for the
upgraded Low Level
Interface
Documentation set for the
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
Inspection: list of delivered
documentation
No user requirement
No user requirement
No user requirement
No user requirement
No user requirement
Y
Y
Y
Y
Y
37
NLR-CR-2013-308-Issue-1.1
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]
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
NLR-CR-2013-308-Issue-1.1
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
NLR-CR-2013-308-Issue-1.1
Requirements identification
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>:
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
The data acquisition process shall signal all detected malfunctions of its measurement equipment, such
as: local control instead of computer control
The data acquisition process shall signal all detected malfunctions of its measurement equipment, such
as: overload of conditioning units
The data acquisition process shall signal all detected malfunctions of its measurement equipment, such
as: wrong filter setting
The data acquisition process shall signal all detected malfunctions of its measurement equipment, such
as: malfunctioning of subscanner devices
40
NLR-CR-2013-308-Issue-1.1
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
NLR-CR-2013-308-Issue-1.1
Requirements identification
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>:
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