Vous êtes sur la page 1sur 46

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

Nationaal Lucht- en Ruimtevaartlaboratorium


National Aerospace Laboratory NLR
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

Nationaal Lucht- en Ruimtevaartlaboratorium


National Aerospace Laboratory NLR

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
Acquisition and Data Processing
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
Acquisition and Data Processing
systems
Results and conclusions
Testplan for Upgraded ILST Data
Acquisition and Data Processing
systems.
Applicability
Upgraded ILST Data Acquisition
and Data Processing systems

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

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

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

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:

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

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

NLR-CR-2013-308-Issue-1.1

Appendix A

User requirements verification matrix

25

Appendix B

DARS (derived) requirements verification matrix

40

Appendix C

DPS (derived) requirements verification matrix

42

NLR-CR-2013-308-Issue-1.1

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

NLR-CR-2013-308-Issue-1.1

TPS

Turbo Propulsion Simulator

WAP

Wireless Access Point

WP

Work Package

NLR-CR-2013-308-Issue-1.1

This page is intentionally left blank.

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:

Chapter 1 gives the scope and overview of this document,

10

NLR-CR-2013-308-Issue-1.1

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

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.

Figure 1. ILST simulation environment as available at NLR

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

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

(Real-Time) Simulation Environment

PC

(Real-Time) Simulation Environment

PC

(Real-Time) Simulation Environment

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

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

NLR-CR-2013-308-Issue-1.1

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?

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?


Try to borrow from DNW?
Try to borrow from DNW
(availability unsure)?
Try to borrow from DNW
(availability unsure)?
Try to borrow from DNW
(availability unsure)?
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

NLR-CR-2013-308-Issue-1.1

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

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:

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

NLR-CR-2013-308-Issue-1.1

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

NLR-CR-2013-308-Issue-1.1

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

NLR-CR-2013-308-Issue-1.1

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

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

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

NLR-CR-2013-308-Issue-1.1

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

NLR-CR-2013-308-Issue-1.1

6 Notes
There are no notes.

24

NLR-CR-2013-308-Issue-1.1

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

[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

Inspection list of delivered equipment

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

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

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

Inspection list of delivered equipment

See UR-034

See UR-034

See UR-034

See UR-034

See UR-034

See UR-034

architecture definition, no user

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]

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)

Inspection list of delivered equipment

Inspection list of delivered equipment

See UR-048

See UR-048

See UR-048

See UR-048

Inspection list of delivered equipment

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

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

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?

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

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

Inspection: see Modification Kit

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).

Inspection: see Modification Kit

Inspection: see Modification Kit

Inspection: see Modification Kit

Inspection: see Modification Kit

Inspection: see Modification Kit

Test: verify that the DAS Hub can provide


data via ethernet to DARS (TBD
availability of test equipment).

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

No part of DARS, will not be validated

Inspection: list of delivered equipment

No part of DARS, will not be validated

No part of DARS, will not be validated

No part of DARS, will not be validated

No part of DARS, will not be validated

No part of DARS, will not be validated

Inspection: list of delivered equipment

Inspection: see Modification Kit

Inspection: see Modification Kit

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

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
Inspection: see Modification Kit

Inspection: list of delivered equipment

N
N

N
Y

31

Inspection: list of delivered equipment

Inspection: list of delivered equipment

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]

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

Inspection: list of delivered equipment

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

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]

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 ;
External interface: Ethernet;
Node DARS
Control the ILST Wind Tunnel
D/A System hardware;
External interface: Ethernet;
Node DARS
Control the ILST Calibration
System D/A hardware;
External interface: Ethernet;
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)
Inspection: verify that identified task is
performed on the identified node(s)

33

method

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

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.

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]

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;
External interface: Ethernet;
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
Calibration System Host;
Personal computer with
Linux
Calibration System Host; 24
widescreen monitor
Calibration System Host; Two
Ethernet ports
Calibration System Host;
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

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)
Inspection: verify that identified task is
performed on the identified node(s)
Inspection: verify that identified task is
performed on the identified node(s)

Y
Y

34

method

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

Inspection: verify that identified task is


performed on the identified node(s)

See UR-269 up to/incl UR-284

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

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

Inspection list of delivered equipment

Dual monitor output

Inspection list of delivered equipment

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
Operator GUI computer;
Personal computer with
Linux
Operator GUI computer;
Touch screen or widescreen
monitor
Operator GUI computer;
Dual monitor output
Portable GUI computer;
Quantity: 2
Portable GUI computer;
Ruggedized laptop computer
with Linux
Portable GUI computer;
Tablet computer (iOS or
Android)
Data server; Quantity: 1

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

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

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

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

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Gigabit switch; 24-port


Gigabit Ethernet switches:
DA-DP network (1); Wind
Tunnel D/A System (3);
Calibration D/A System (1)

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

Firewall; To enable remote


support via a secured
connection
Software packages for the
Host computers; Quantity: 6
Software packages for the
Host computers: DARS Host,
Calibration System Host, DPS
Host, DPS-GPS Host
Software packages for the
GUI computers; Quantity: 10
Software packages for the
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 equipment

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Inspection: list of delivered software

Test software: For testing of


the upgraded Conditioning
Units
Modification kits for the
Conditioning Unit Mk3 DAS;
Quantity: 50
Modification kits for the
Conditioning Unit Mk3 DAS;
Ethernet Interface board, as
a one-to-one replacement
for the current Digital
Interface board
Modification kits for the
Conditioning Unit Mk3 DAS;
Partial rear panel to mount
on the current rear panel
DAS Hubs; Quantity: 5

Inspection: list of delivered software

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

NTC DAS Hub; Quantity: 1

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

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection list of delivered equipment

Inspection: list of delivered


documentation

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

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation

Inspection: list of delivered


documentation
Inspection: list of delivered
documentation
Inspection: list of delivered
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

Inspection: list of delivered


documentation
Inspection: list of delivered
documentation
Inspection: list of delivered
documentation
Inspection: list of delivered
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

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]

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

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

Appendix B DARS (derived) requirements verification matrix


B.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>:

identification of the applicable proposal;

<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
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

Appendix C DPS (derived) requirements verification matrix


C.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>:

identification of the applicable proposal;

<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