as064-ilst-fatp issue 1_1 -- final acceptance test plan - signed

7/26/2019 AS064-ILST-FATP Issue 1_1 -- Final Acceptance Test Plan - Signed

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


2/46



Anthony Fokkerweg 2P.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


3/46

UNCLASSIFIED

Executive summary

UNCLASSIFIED



Report no.


Author(s)

E.J.A. Wegkamp

Report classification

UNCLASSIFIED

Date

April 2014

Knowledge area(s)

Elektronicatechnologie

Avionicakwalificatie

Descriptor(s)

Instrumentation

Wind Tunnel Apparatus

Data Acquisition

Data Processing

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 Processingsystems. 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 Unitsand 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.

Description of work

Testplan for Upgraded ILST Data


systems

Results and conclusions

Testplan for Upgraded ILST Data


systems.

ApplicabilityUpgraded ILST Data Acquisition

and Data Processing systems


4/46

UNCLASSIFIED

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

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
http://www.nlr.nl/http://www.nlr.nl/http://www.nlr.nl/http://www.nlr.nl/


5/46




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:


6/46


7/46


3

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


8/46


4

Contents

Scope 9

1.1 Identification 9

1.2 System Overview 9

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

3 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

4 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

5

Data recording, reduction, and analysis 23

6 Notes 24


9/46


5

Appendix A User requirements verification matrix 25

Appendix B DARS (derived) requirements verification matrix 40

Appendix C DPS (derived) requirements verification matrix 42


10/46


6

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


11/46


7

TPS Turbo Propulsion Simulator

WAP Wireless Access Point

WP Work Package


12/46


8

This page is intentionally left blank.


13/46


9

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.


14/46


10

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


15/46


11

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 PlansNot applicable.


16/46


12

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.


17/46


13

3

Test Environment

3.1General

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


18/46


14

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

Linux Operating System PC

FEA-CuMk3-EXT Front End Acquisition task for CU PC

FEA-DasHub* Front End Acquisition task for DasHub PC

FEA-NtcHub* Front End Acquisition task for

NTCHub

PC

FEA-PLC* Front End Acquisition task for PLC PC

FEA-ESM* Front End Acquisition task for ESM PC

FEA-SC* Front End Acquisition task for

Subscanner Controller

PC

FEA-PSI* Front End Acquisition task for PSI PC

CalCtl* Calibration application PC

DataSelection Data Selection Task PC

CIT Command Interface task PC

MeasurementControl Measurement Control PC

Synthetic* Calculation of tunnel parameters PC

MessageFile Captures messages PC

StrobeEdit* Strobe number editor PC

CU simulator (Real-Time) Simulation Environment PC

DasHub simulator* (Real-Time) Simulation Environment PC

NTC simulator* (Real-Time) Simulation Environment PC

PLC simulator*

(Real-Time) Simulation Environment PC*: Item is not part of Factory Acceptance Test, but tested at lower level.


19/46


15

Table 2 lists all software items that are necessary to perform the DPS software testing activities.

Table 2. DPS Software Items



Apropos Data Processing System PC

DARS Software Items (Real-Time) Simulation

Environment

PC

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



DPS Software Items (Real-Time) Simulation

Environment

PC

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.


20/46


16

Table 4. Hardware items for user requirements tests

Quantity Item

After DECEMBER

delivery: Remarks

1Data Acquisitie

computer

General purpose

computer (ODIC)

Dedicated computer, 2 GBE

ports for 2 networks

1Data Processing

computer

General purpose

computer (ODIC)Dedicated computer

1 Data serverGeneral purpose

computer (ODIC)Dedicated computer

1DA-DP Ethernet

switch

General purpose

switch (ODIC)-

1DARS Ethernet

switch

General purpose

switch (ODIC) -

2 Parallel I/O card* NLR spare cards -

1Subscanner

controller*

- Try to borrow from DNW?

1Calibration source

(Burster)*- Try to borrow from DNW?

1 Conditioning UnitProto ILST CU,

ETW CU

2 DAS Hub* ETW DAS Hub -

1 NTC DAS Hub* - Try to borrow from DNW?

1 NTC Conditioning* - Try to borrow from DNW?

1Temperature

Interface*

-Try to borrow from DNW

(availability unsure)?

1Inclinometer

conditioning*

-Try to borrow from DNW


1 Low Level Interface* -Try to borrow from DNW


1 High Level Interface* -

Try to borrow from DNW


1Engine Monitor

System

*

-

Develop an EMS simulator,

executing on simulator

laptop

n CU simulatorsGeneral purpose

computer (ODIC)

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


21/46


17

4 Formal Qualification Test Identification

4.1General 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.2Test 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].


22/46


18

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.3Test 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,

o detection and processing of hardware failures, and

o possible violations of software partitioning (if applicable).


23/46


19

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


24/46


20

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.


25/46


21

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.4Test 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.


26/46


22

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

1The 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 newversions of the DPS software, typically a regression mechanism.


27/46


23

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.


28/46


24

6

Notes

There are no notes.


29/46


25

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 inTable 5.The

requirements are identified using the following identification method:

[v-ps], with the following parameter explanation:

: identification of the applicable proposal;

v: applicable version of the proposal;: section identification of the applicable proposal;

p: paragraph in the section;

s: sentence in the paragraph.

As an example:

[ILST-V2v1.0-2.2p2s1]

Project: ILST

Proposal: V2 version 1.0

Section: 2.2

Paragraph: 2

Sentence: 1

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. ID Description validation method

UR-021 [ILST-V2v1.0-

2.2p2s1]

Except for both data

acquisition subnets, all

components of the DA-DP

network will consist of COTS

components.

N


2.2p2s2]

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.

Y Inspection list of delivered equipment


30/46


26



2.2p2s3]

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.



2.2.1p1s2]

The main DA-DP network

consists of six Host

computers:



2.2.1p1s2a]

The Data Acquisition &

Reduction System Host

(DARS Host) for control of all

measurement activities of

the Wind Tunnel Data

Acquisition (D/A) System;



2.2.1p1s2b]

The Calibration System Host

for all sensor calibration

purposes;



2.2.1p1s2c]

Two Data Processing System

Hosts (DPS Host) for all

online data processing tasks;



2.2.1p1s2d]

Two General-Purpose Data

Processing System Hosts

(DPS-GP Host) for all pre-

processing and post-

processing tasks.



2.2.1p2s1]

Data from the Host

computers is stored on a

dedicated Data Server with

RAID (Redundant Array of

Independent Disks).

Y Analysis: verify whether data transfer

from host computer to Data Server is

performed, inspect presence of Data

Server with RAID setup.


2.2.1p2s2]

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.

Y Analysis: verify that data is stored locally

during a test


2.2.1p2s3 ]

After completion of a run the

data will automatically be

transferred to the Data

Server.

Y Analysis: verify that the data is

automatically transferred after

completion of a test


2.2.1p3s2]

The following GUI devices

are foreseen on the following

locations:



2.2.1p3s2a1]

Two (extendable to four) GUI

devices for real-time wind

tunnel parameter data and

text (wall and desk);

Y See UR-034


2.2.1p3s2a2]

Four (extendable to eight)

GUI devices for plots and

graphics (wall);

Y See UR-034


2.2.1p3s2a3]

One Operator GUI device for

control and manual input of

parameters (desk);

Y See UR-034


2.2.1p3s2b]

Instrumentation Room: One

GUI device;

Y See UR-034


2.2.1p3s2c]

Customer Room: One GUI

device;

Y See UR-034


2.2.1p3s2d]

Test Section Hall: Two

wireless portable GUI

devices.

Y See UR-034

UR-044 [ILST-V2v1.0- Figure 2 Proposed upgraded N architecture definition, no user


31/46


27


2.2.1p4s3] DA-DP network architecture requirement

UR-045 [ILST-V2v1.0-2.2.1p5s1]

The network is alsoconnected to the ILST Video

System, in order to be able

to display overlay

information on monitors,

such as text and wind tunnel

parameters.

Y ILST video system test will be part ofApropos test (ref XXX)


2.2.1p5s2]

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.

N


2.2.1p5s3]

Foreseen is the use of an

8x16 or 16x16 matrix switch.



2.2.1p6s1]

A total of four printers are

connected to the DA-DP

network and its subnets:



2.2.1p6s1a]

A line printer to print raw

data in engineering units

from the DARS Host;

Y See UR-048


2.2.1p6s1b]

A line printer to print

calibrated data and

calculation results from the

DPS Hosts;

Y See UR-048


2.2.1p6s1c]

A colour laser printer for

general printing purposes;

Y See UR-048

UR-052 [ILST-V2v1.0-2.2.1p6s1d]

A colour laser printer for theCalibration D/A System

subnet.

Y See UR-048


2.2.1p6s1]

A firewall between the DA-

DP network and Internet is

installed to allow remote

support (for maintenance,

software upgrades, etc.) by

external parties, such as NLR.



2.2.2p1s1]

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 theCalibration D/A System

respectively.

Y Analysis: verify that the network

architecture is defined in the ICD


2.2.2p3s1]

For the control of the two

Subscanner Controllers, one

or more COTS parallel I/O

cards are necessary in the

DARS Host.

Y Inspection: verify that the parallel I/O

cards are present in the ICD


2.2.2p3s2]

These controllers, on their

turn, control the Low Level

Scanners and the ScaniValve

units (both not drawn here

for clarity).

? December demo?


2.2.2p3s3]

The ScaniValve equipment

will be replaced in the future

by PSI equipment.

N


32/46


28



2.2.2p4s1]

Besides to the data

acquisition equipment, the

DARS Host is also connected

to the ILST PLC systems for

Model Control and Tunnel

Control.

Y Test: verify that the DARS HOST can

receive data generated by the PLC

Simulator as defined in the ICD.


2.2.2p4s2]

The Central PLC (PLC System

#1 in Figure 3) acts as the

main hub for the other PLC

systems.

N From DARS point of view, there is only

interaction with the main hub.


2.2.2p4s4]

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.

Y Inspection: verify the network

architecture as defined in the ICD


2.2.2p4s5]

Figure 3 Proposed Wind

tunnel D/A System subnet

N architecture definition, no user

requirement


2.2.2p5s3]

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

N No NLR requirement


2.2.2p6s1]

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.

? TBC: has this been configured? Default

setting in linux?


2.2.3p1s1]

In general, the use of

Ethernet instead of the DAS-

bus as the main data bus will

result in the following

changes of the Data

Acquisition and Data

Processing network

structure:


2.2.3p1s1a]

Replacement of the HP 1000

computers, HP 9000

computers and DAS

Interfaces by PCs with Linux;



2.2.3p1s1b]

Installation of standard

Ethernet switches to connect

the Conditioning Units and

DAS Hubs directly to the

DARS computer.



2.2.3p1s1c]

For the Conditioning Units:

Replacement of the DAS-bus

interface by an Ethernet

interface (see section

2.2.3.1);



2.2.3p1s1d]

For the remaining

unmodified equipment

(Calibration Generators,

Inclinometer Conditioning

Units, etc.): Connection to

Ethernet via a number of 8-

channel DAS Hubs (see

section 2.2.3.2).



33/46


29



2.2.3.1p1s1]

The upgrade of the

Conditioning Units to

Ethernet requires two

modifications on the

Conditioning Units:

Y Inspection: see Modification Kit


2.2.3.1p1s1a]

The replacement of the

current Digital Interface

board by an Ethernet

Interface board;



2.2.3.1p1s1b]

The modification of the rear

panel.



2.2.3.1p2s2]

All the functions for on-

board control, data

processing, data storage and

the interfacing with Ethernet

are implemented as

firmware in a COTS Linux-

embedded computer

module, the Toradex Colibri.

N No user requirement


2.2.3.1p3s2]

Particular attention has been

paid to the synchronization

of measurements between

Conditioning Units, other

DAS-bus equipment and

external equipment.

Y see UR-089


2.2.3.1p3s3]

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

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


2.2.3.1p4s2]

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.



2.2.3.1p4s4]

Two External Trigger input

connectors are placed to

allow daisy-chaining of

cabling between

Conditioning Units.



2.2.3.1p4s5]

It should be noted that this

version has another type of

Calibration Bus connector.



2.2.3.1p4s6]

Also, a cavity has been added

on top, intended glue a serial

number plate in.



2.2.3.1p4s7]

The ILST Conditioning Units

will have comparable rear

panels.



2.2.3.2p1s1]

With the DAS Hub (see

Figure 6) unmodified DAS-

bus equipment can be

connected to Ethernet using

a communication protocol

very similar to the version

used in the Conditioning

Units.

Y Test: verify that the DAS Hub can provide

data via ethernet to DARS (TBD

availability of test equipment).


34/46


30



2.2.3.2p1s2]

A maximum of eight DAS-bus

units, either Binary or BCD

devices, can be connected to

a single DAS Hub.

N No change w.r.t. previous DAS bus units.


2.2.3.2p1s3]

A common External Trigger

input is provided for all

connected devices.

N No part of DARS, will not be validated


2.2.3.2p2s1]

For the NTC Conditioning a

dedicated DAS Hub is

available.

Y Inspection: list of delivered equipment


2.2.3.2p1s2]

This unit connects a single

NTC Conditioning to Ethernet

and is equipped with an

additional Step/Home

connector.



2.2.4.1p2s1]

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.



2.2.4.1p2s3]

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

board computer module.



2.2.4.1p2s4]

The firmware will also be

modified in order to

calculate the normalized

output, so it can be read by

the external DA computer.



2.2.4.1p2s5]

Figure 7 Calculation of

normalized output



2.2.4.2p1s1]

A total of fifteen additional

Conditioning Units are

offered to extend the

measurement capabilities of

the DA system.



2.2.4.2p1s2]

Because of obsolescence

problems with electronic,

electromagnetic and

mechanical components a

number of printed-circuit

boards will have to be

redesigned.



2.2.4.2p1s3]

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.



2.2.4.2p1s4]

The technical specifications

will also remain unchanged.

N


35/46


36/46


32


switch-off in case of

overload.


2.2.4.5p2s2c]

Remote Data Concentrator

(RDC)



2.2.4.5p2s2c1]

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.

N


2.2.4.5p2s2c2]

It acquires and conditions

the onboard temperature

signals from thermo-couples

and Pt-100 sensors.

N


2.2.4.5p2s3]

Figure 9 Block diagram of the

EMS

N


2.2.4.6p1s1]

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

N


2.2.4.6p1s3]

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.

N


2.2.5p1s1]

The software for the DARS

and Calibration System Host

computers will be based on

the DRACHME kernel.

Y Inspection: TBD verify Drachme in

application title or About menu?


2.2.5p2s7]

In short, the DRACHME

kernel software provides the

following services:

Y See UR-156 to/incl UR-159


2.2.5p2s7a]

Automatic (re-)configuration

of nodes;

Y Test: TBD


2.2.5p2s7b]

Real-time distribution blocks

of data between tasks;

Y Test: TBD


2.2.5p2s7c]

Distribution and routing of

commands between tasks;

Y Test: TBD


2.2.5p2s7d]

One-to-many distribution of

text messages betweentasks.

Y Test: TBD


2.2.5p3s1]

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.

Y See UR-156


2.2.5p4s2]

The ILST DARS software will

be developed using GNU and

Linux tools.



2.2.5p4s3]

The specific GUI tasks will be

developed using easy to useopen source development



37/46


33


tools and applications.


2.2.5p4s4]

The development package

will be used is Qt.



2.2.5p5s1]

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.

Y Inspection: verify that DRACHME is used

for both CS as well as DARS.


2.2.5p5s3a]

Main control task

(DRACHME); Node: DARS, CS

Y Inspection: verify that identified task is

performed on the identified node(s)


2.2.5p5s3b]

Graphical User Interfaces;

External interface: Ethernet;Node DARS, CS




2.2.5p5s3c]

Control of the DARS line

printer; External interface:

Ethernet; Node DARS




2.2.5p5s3d]

DPS Host interface ; External

interface: Ethernet; Node

DARS




2.2.5p5s3e]

Control of the Subscanner

Controllers ; External

interface: Parallel I/O; Node

DARS




2.2.5p5s3f]

Control of the PSI system ;

External interface: Ethernet;

Node DARS



UR-174 [ILST-V2v1.0-2.2.5p5s3g] Control the ILST Wind TunnelD/A System hardware;


Node DARS

Y Inspection: verify that identified task isperformed on the identified node(s)


2.2.5p5s3h]

Control the ILST Calibration

System D/A hardware;


Node CS




2.2.5p5s3i]

Interface with the Calibration

Database (CDB); External

interface: Ethernet; Node:

DARS, CS




2.2.5p5s3j]

Interface with the ILST PLC

systems; External interface:

Ethernet; Node: DARS



UR-178 [ILST-V2v1.0-2.2.5p5s3k] Control of the Burstercalibration source; External

interface: RS-232; Node:

DARS, CS



2.2.5p5s3l]

Control of the Configurable

EMS; External interface:

Ethernet; Node: DARS




2.2.6p1s1]

The software for the DPS

Host computers is based on

the APROPOS C07 data

processing software, ported

to 64-bit Linux.

Y Inspection: verify that the DPS software

has Apropos as its origin. Verify that the

DPS software runs on 64-bit Linux.


2.2.6p1s2]

Since the accompanying

original user interface and

plotting software packages

are not supported anymore,

these components will be re-

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


38/46


34


developed using open source

and license free tools.


2.2.6p1s3]

For the GUIs, Qt will be used. N No NLR requirement


2.2.6p1s4]

The choice for the plotting

facilities has yet to be

determined.

N


2.2.6p1s6a]

Ported APROPOS C07 to

Linux x86_64; Node DPS,

DPS-GP




2.2.6p1s6b]

Graphical User Interfaces;

Node DPS, DPS-GP




2.2.6p1s6c]

Plot interface; Node DPS,

DPS-GP



UR-189 [ILST-V2v1.0-2.2.6p1s6d]

Control of the DPS lineprinter; External interface:

Ethernet; Node DPS, DPS-GP



2.2.6p1s6e]

DARS Host interface;


Node DPS




2.2.6p1s6f]

Interface with the Calibration

Database (CDB); External

interface: Ethernet; Node

DPS, DPS-GP




2.2.6p1s6g]

Interface with the ILST Video

System; External interface:

Ethernet or other standard

data bus; Node DPS




2.2.7p1s2]

Besides the hardware and

software components, alsothe relevant documentation

will be delivered to LAGG in

order to provide the

information needed for

LAGG to be self-supporting.

Y See UR-269 up to/incl UR-284


2.2.7p1s4a1]

DARS Host; Quantity 1 Y Inspection list of delivered equipment


2.2.7p1s4a2]

DARS Host; Personal

computer with Linux



2.2.7p1s4a3]

DARS Host; 24 widescreen

monitor



2.2.7p1s4a4]

DARS Host; Two Ethernet

ports



2.2.7p1s4a5]

DARS Host; Two parallel I/O

cards



2.2.7p1s4a6]

DARS Host; Dual monitor

ouput



2.2.7p1s4b1]

Calibration System Host;

Quantity 1



2.2.7p1s4b2]


Personal computer with

Linux



2.2.7p1s4b3]

Calibration System Host; 24

widescreen monitor



2.2.7p1s4b4]

Calibration System Host; Two

Ethernet ports



2.2.7p1s4b5]


Dual monitor output



2.2.7p1s4c1]

DPS Host/DPS-GP Host;

Quantity 4



39/46


35



2.2.7p1s4c2]


Linux



2.2.7p1s4c3]

24 widescreen monitor Y Inspection list of delivered equipment


2.2.7p1s4c4]

Dual monitor output Y Inspection list of delivered equipment


2.2.7p1s4d1]

GUI computers (for tunnel

parameters, text, plots and

graphics); Quantity: 8



2.2.7p1s4d2]

GUI computers; Personal

computer with Linux



2.2.7p1s4d3]

GUI computers; Dual monitor

output



2.2.7p1s4d4]

GUI computers; Widescreen

monitors: Control Room (6);

Instrumentation Room (1);

Customer Room (1)



2.2.7p1s4e1]

Operator GUI computer;

Quantity: 1



2.2.7p1s4e2]



Linux



2.2.7p1s4e3]


Touch screen or widescreen

monitor



2.2.7p1s4e4]


Dual monitor output



2.2.7p1s4f1]

Portable GUI computer;

Quantity: 2



2.2.7p1s4f2]


Ruggedized laptop computer

with Linux



2.2.7p1s4f3]


Tablet computer (iOS or

Android)



2.2.7p1s4g1]

Data server; Quantity: 1 Y Inspection list of delivered equipment


2.2.7p1s4g2]

Data server; Network data

storage computer server

with RAID



2.2.7p1s4h1]

Wireless Access Point (WAP);

Quantity: 1



2.2.7p1s4h2]

Wireless Access Point (WAP);

To be mounted in the Test

Section Hall



2.2.7p1s4i1]

Line printer; Quantity: 2 Y Inspection list of delivered equipment


2.2.7p1s4i2]

Line printer; DPS Line Printer

and DARS Line Printer



2.2.7p1s4i3]

Line printer; Ethernet and

USB ports



2.2.7p1s4j1]

Colour laser printer;

Quantity: 2



2.2.7p1s4j2]

Colour laser printer; For DA-

DP network and Calibration

D/A System



2.2.7p1s4k1]

Gigabit switch; Quantity: 5 Y Inspection list of delivered equipment


2.2.7p1s4k2]

Gigabit switch; 24-port

Gigabit Ethernet switches:

DA-DP network (1); Wind

Tunnel D/A System (3);Calibration D/A System (1)



40/46


36



2.2.7p1s4l1]

Firewall; Quantity: 1 Y Inspection list of delivered equipment


2.2.7p1s4l2]

Firewall; To enable remote

support via a secured

connection



2.2.7p1s5a1]

Software packages for the

Host computers; Quantity: 6

Y Inspection: list of delivered software


2.2.7p1s5a2]


Host computers: DARS Host,

Calibration System Host, DPS

Host, DPS-GPS Host



2.2.7p1s5b1]


GUI computers; Quantity: 10



2.2.7p1s5b2]


GUI computers: GUI

computers (8), Operator GUI

computer (1) and wireless

GUI laptop computer (1)



2.2.7p1s5c1]

Software package for the GUI

tablet; Quantity:1



2.2.7p1s5d1]

Software package for the

data server; Quantity: 1



2.2.7p1s5e1]

Operating System software

package; Quantity: 1



2.2.7p1s5e2]

Operating System software

package; Linux Operating

System for all DA-DP

computers, including 17

licenses



2.2.7p1s5f1]

Test software; Quantity: 1 Y Inspection: list of delivered software

UR-246 [ILST-V2v1.0-2.2.7p1s5f2] Test software: For testing ofthe upgraded Conditioning

Units



2.2.7p1s6a1]

Modification kits for the

Conditioning Unit Mk3 DAS;

Quantity: 50



2.2.7p1s6a2]



Ethernet Interface board, as

a one-to-one replacement

for the current Digital

Interface board



2.2.7p1s6a3]



Partial rear panel to mount

on the current rear panel



2.2.7p1s6b1]

DAS Hubs; Quantity: 5 Y Inspection list of delivered equipment


2.2.7p1s6c1]

NTC DAS Hub; Quantity: 1 Y Inspection list of delivered equipment


2.2.7p1s6d1]

Additional Conditioning

Units; Quantity: 15



2.2.7p1s6e1]

Modification kits for the Low

Level and High Level

Interfaces; Quantity: 18



2.2.7p1s6f1]

Calibration Sources;

Quantity: 2



2.2.7p1s6g1]

Engine Monitor System;

Quantity: 1



2.2.7p1s7a]

Instruction manual for the

upgrade of the ConditioningUnit Mark III

Y Inspection: list of delivered

documentation


41/46


37



2.2.7p1s7b]


upgrade of the Low Level

Interface


documentation


2.2.7p1s7c]


upgrade of the High Level

Interface


documentation


2.2.7p1s7d]

Documentation set for the

upgraded Conditioning Unit

Mark III


documentation


2.2.7p1s7e]


upgraded Low Level

Interface


documentation


2.2.7p1s7f]


upgraded High Level

Interface


documentation


2.2.7p1s7g]

Software design document

for the Data Acquisition

System and Calibration

System


documentation


2.2.7p1s7h]

Software design document

for the Data Processing

System


documentation


2.2.7p1s7i]

User manual for the Data

Acquisition System and the

Calibration System


documentation


2.2.7p1s7j]

User manual for the Data

Processing System


documentation


2.2.7p1s7k]

User manual for the Engine

Monitor System


documentation


2.2.7p1s7l]

Binder with all manuals all

COTS hardware and software

components


documentation


2.2.7p1s7m]

Software installation

instructions for all computers


documentation


2.2.7p1s7n]

Configuration Item Data List

(CIDL)


documentation


2.2.7p1s7o]

Final Acceptance Test Plan Y Inspection: list of delivered

documentation


2.2.7p1s7p]

Final Acceptance Test Report Y Inspection: list of delivered

documentation


2.2.8p1s2a]

LAGG is requested to send

one unmodified Conditioning

Unit, one Low Level Interface

and one High Level Interface.



2.2.8p1s2b]

These three units will be

modified at NLR and will be

used for:



2.2.8p1s2b1]

Testing of the DA and DP

software;



2.2.8p1s2b2]

Verification of the

normalized output

modification on the

Conditioning Units (see

section 2.2.4.1);



2.2.8p1s2b3]

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;


UR-291 [ILST-V2v1.0-2.2.8p1s2b4] A means to develop themodification kits for these N No user requirement


42/46


38


units.

UR-292 [ILST-V2v1.0-2.2.8p1s3a]

LAGG is also requested toprovide 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).


UR-293 [INFO-V2v1.0-

2.2.8p1s3b]

This NLR in-house testing will

assure a proper operation of

the DA-DP network before

delivery to LAGG.


UR-294 [ILST-V2v1.0-2.2.8p1s4a]

Finally, LAGG is requested todeliver the Interface Control

Document of the interface

between the PLC systems

and the DARS Host computer

(DARS-PLC ICD).



2.2.8p1s4b]

This document will describe

the interface in detail, both

with respect to protocol and

timing.



2.2.8p1s4c]

An initial version will be used

as a basis to discuss the

optimal and most efficient

interface implementation on

both sides.


UR-297 [ILST-V2v1.0-2.2.8p1s4d]

A template for the ICD willbe provided by NLR.



2.2.8p1s4e]

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.



2.2.9p1s1]

A part of the software

development activities will

be performed by LAGG.



2.2.9p1s2]

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.



2.2.9p2s1]

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.



2.2.9p2s2]

NLR will compile the

interface definitions, whichwill be based on the



43/46


39


DRACHME and APROPOS

software, and propose this to

LAGG.


2.2.9p2s3]

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.



44/46


40

Appendix B

DARS (derived) requirements verification matrix

B.1 Requirements identification

The summary of the derived requirements of the DARS is provided inTable 6.The

requirements are identified using the following identification method:

[---v], with the following parameter explanation:


: source identification

: functional part

: sequence number

v: applicable version of the proposal.

As an example:

[SWDR-DARS-1-v1.0]

Type: SW (Software)

Source: DR (Derived Requirement)

Part: DARS

Sequence id: 1

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

Requirement text

SWDR-DARS-1-v1.0 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.

SWDR-DARS-2-v1.0 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.SWDR-DARS-3-v1.0 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.

SWDR-DARS-4-v1.0 It shall be possible that a number of 20 measurement values and associated ranges be entered manually

via thumbwheel switches.

SWDR-DARS-5-v1.0 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.

SWDR-DARS-6-v1.0 The data acquisition process shall signal all detected malfunctions of its measurement equipment, such

as: power off


as: local control instead of computer control


as: overload of conditioning units


as: wrong filter setting

SWDR-DARS-10-v1.0 The data acquisition process shall signal all detected malfunctions of its measurement equipment, suchas: malfunctioning of subscanner devices


45/46


41

Derived Requirements

DP-Req-number

Requirement text

SWDR-DARS-11-v1.0 The data acquisition process shall check on a correct sequence of measurement commands during a run

SWDR-DARS-12-v1.0 Each measurement run shall start with a precycle record containing run-related constants, that areentered by the DA-operator

SWDR-DARS-13-v1.0 Idle conversion of the sensor output shall have a rate of at least 2 times per second

SWDR-DARS-14-v1.0 Data transfer to the Data Processing process shall be possible: immediately after each measurement

(on-line transmission)

SWDR-DARS-15-v1.0 Data transfer to the Data Processing process shall be possible: at any time after a run (off-line

transmission of backup data)

SWDR-DARS-17-v1.0 Data that has been measured for Real-time Display processing can only be transmitted immediately

after the measurement

SWDR-DARS-21-v1.0 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

SWDR-DARS-22-v1.0 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.


46/46


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:

[---v], with the following parameter explanation:


: source identification

: functional part

: sequence number

v: 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: 1

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.