Imtech ICT Technical SystemsNWERC 2008 22 nov 2008 Practical development Illustrated using the GAIUS windtunnel automation system By: Evert van de Waal

Imtech ICT Technical Systems

NWERC 2008 22 nov 2008

Practical development

Illustrated using the GAIUS windtunnel automation system

By: Evert van de Waal Imtech ICT Technical Systems


NWERC 2008 22 nov 2008

Background Imtech

Imtech■ Imtech is a large (19.000) company■ Focus on technical services

– Infrastructure– Buildings, ships, communications, traffic

Imtech ICT Technical Systems■ 70 Professionals■ Focus on ‘technical software’■ Customers include Shell, Vanderlande, Philips, GE

Healthcare, Rijkswaterstaat, Assembleon, NXP, etc.


NWERC 2008 22 nov 2008

Background Evert

■ MSc Electrical Engineering (1993)■ Research Fellow Strathclyde University

(Control)■ Firmware developer small company■ Consultant at Imtech TS (since 2001)

■ Focus: Architecture, Control, Firmware■ National Champion SW Architecture

Description 2007■ URL:

http://www.nkictarchitectuur.nl/2007/Downloads/inzendingen/7-Imtech-Gaius/Gaius_Architecture_nka.pdf


NWERC 2008 22 nov 2008

Background GAIUS / DNW

■ DNW (German-Dutch Windtunnels) manages tunnels in Amsterdam, Marknesse, Braunschweig, Göttingen and Cologne

■ DNW management wanted a new control system, that– Is able to unify to look-and-feel of all tunnels– Allows a high level of experiment automation– Will give a competitive edge for 10 years


NWERC 2008 22 nov 2008

Wind tunnel Structure


NWERC 2008 22 nov 2008

Test Object


NWERC 2008 22 nov 2008

Data Acquisition


NWERC 2008 22 nov 2008

Presentation


NWERC 2008 22 nov 2008

Characteristics of a wind tunnel

■ Large and complex system■ Most wind tunnels are unique■ Constant changes and improvements■ Many types of experiments are performed■ Wind tunnel tests are essential for wind tunnel

users■ Most tunnels operate at the edge of physical

limitations


NWERC 2008 22 nov 2008

Examples of Experiments


NWERC 2008 22 nov 2008

Wind tunnel Characteristics:

Dutch Tunnels:■ Amsterdam HST: High Speed: 1.3M, 2.0x1.8m, 0.25 to 4 Bar,

16MW ■ N-O Polder LLF: Large Low Speed: 80 m/s, 9.5x9.5m, 20 MW■ N-O Polder LST: Low Speed: 80 m/s, 3x2.25m, 700KW

Auxilery systems:■ Pressurized air: 5 kg/s at 80 Bar■ Positioningsystems: better than 0.01 graden at 70KNm■ Moving belt for ground effects

Data Acquisitioning:■ 1000+ presure sensors■ Microphone array for locating sound sources■ Camera for measuring color changes in pressure sensitive paint■ Laser / camera systems that track movement of oil droplets


NWERC 2008 22 nov 2008

A Request

■ Please, make me an automation system

■ How would you proceed???


NWERC 2008 22 nov 2008

SW success factors

■ What is important for a wind tunnel automation system?– Algoritms– Performance?– Database structure?– OO design?– Architecture?– Development process?– GUI layout?– Requirements engineering?

■ Who decides what is important???


NWERC 2008 22 nov 2008

Actual SW success factors

■ The software must perform its main purpose well– The user defines ‘main purpose’ and ‘well’– Usually there are several user types: stakeholders

■ ‘well’ indicates that we are talking about non-functional behavior– That is e.g. user friendliness, robustness,

performance, stability, maintainability, extendibility, testability, etc.

■ What determines non-functional behavior???


NWERC 2008 22 nov 2008

Factors in non-functional behavior

■ Most non-functional behavior is determined by:– Algorithms used– Structure of software

■ Obviously, suitable algorithms need to be used

The design and architecture of SW determine non-func behavior

■ In fact, a design is only needed to meet non-func requirements


NWERC 2008 22 nov 2008


NWERC 2008 22 nov 2008

Different Worlds

Customer:· Wishes· Sub-conscious· Plain English

Developers:· Code· Formal requirements· Constraints


NWERC 2008 22 nov 2008

Bridging the Gap

Details

1

10

102

103

104

105

106

107

Architect


NWERC 2008 22 nov 2008

An Architecure

■ An architecture bridges the gap between customer and programmer– Compare with civil engineering

■ Architecture concretizes customer wishes■ Then it makes choices that will satisfy these

wishes

■ An architecture logs all main choices– including alternatives and rationale


NWERC 2008 22 nov 2008

Architecture as a bridge

Principles Choices Decomposition

Verify Verify Verify

Create Create

Failure


NWERC 2008 22 nov 2008

Steps in bridging the gap■ Start with customer wishes

■ Several steps are necessary to bridge the gap– First, a layers of principles for evaluating choices– Second, a layer of fundamental choices– Finally, the decomposition a developer can use

■ Be careful to rationalize choices– Use the principles as rationale for choices, etc


NWERC 2008 22 nov 2008

Customer wishes

■ Focus on stakeholders and their views■ There are several types of stakeholders:

– Internal & external– Different stakeholders for phases in product lifecycle– Actual users of the system– Those who pay for the system– Etc, etc


NWERC 2008 22 nov 2008

GAIUS Stakeholders

External (DNW)– Management– Project Engineer– Test configurator– Tunnel Operator– Developer

Internal (Imtech)– Management– Developer


NWERC 2008 22 nov 2008

Summary of GAIUS customer wishes

■ GAIUS is an open system, with open interfaces to which new systems can be attached easily.

■ The data available in parts of the system is easy to share with other parts of the system.

■ It is easy to use ‘scripts’ to automate the control and measure systems.

■ It is easy to test & improve scripts in a simulated environment, without using the actual wind tunnel.

■ The GAIUS system is adaptable to accommodate the differences between various wind tunnels, and also changes in a wind tunnel system.

■ The GAIUS system is cost-effective.■ The GAIUS system runs on readily available hardware (PC’s).■ The GAIUS system is supported for a long period, in the order

of 10 years.■ It is possible to deploy the GAIUS system gradually, and with

as little interference with tunnel operations as possible.■ The configuration of GAIUS is easy to read and edit.


NWERC 2008 22 nov 2008

GAIUS ?

GAIUS refers to Gaius Julius Ceasar, one of the most famous dictators in history.

The ‘dictator’ (Latin for ‘someone who dictates orders’) was innovation in the Roman republic: a special magistrate with authority over regular magistrates. It was the most senior magistrate.

The GAIUS software system was designed using this philosophy.


NWERC 2008 22 nov 2008

Some key characteristics of GAIUS

■ Interconnect various sub systems■ Integrates these to one coherent system■ Simplifies testing by automatic test

procedures■ Facilitates evolutionary Change

– Adding, modifying and removing sub systems– Changing procedures

■ Flexible enough for custom experiments■ Safe and fault tolerant


NWERC 2008 22 nov 2008

Architecture Principles

■ These are the key decisions in a project– Take them with care– Verify them with stakeholders

■ Principles originate from several sources:– Customer wishes & other project context– Best practices (patterns)– You own experience & preferences

■ Be Creative!


NWERC 2008 22 nov 2008

Principles for GAIUS

1. Use Open Source Software (as much as possible)

■ Open and cost effective2. Use Python (as much as possible)

■ Proven high-productivity language, very open, portable

3. Use Industry Standards■ Again, open & cost effective

4. Use the GAIUS Bus (=blackboard pattern)■ Open, adaptable, best practice

5. Use a standard module interface■ Allows scripting


NWERC 2008 22 nov 2008

Additional principles

6. GUI’s are separate components■ Easy to simulate, allows automated testing■ Communicate with modules using GAIUS bus ■ Scripting uses same interface as GUI!

7. Communicate with HW through TCP/IP■ Open, easy to simulate & test without tunnel


NWERC 2008 22 nov 2008

Refinement of principles

■ Once formulated, the principles can be refined■ Refinement is done by making choices■ These choices undergird the principles


NWERC 2008 22 nov 2008

Some Fundamental choices in GAIUS

■ Use of RTPS as back-bone of GAIUS bus■ Use three different semantics in the bus

– Time-Triggered, real-time, no resend– Event-Triggered, no resend– Event-triggered with acknowledge for Commands

■ Use LabVIEW to create GUI’s– Interface to the GAIUS bus

■ Modules derive from base class, which:– Retrieves module configuration– Enforces compliance with the state model– Provides race-condition free event handling


NWERC 2008 22 nov 2008

Divide and conqueror

■ Next, the architecture will partition the software– Define modules and their interfaces

■ Thus development can be done in parallel– Up to a certain level! (‘The mythical Man-month’)


NWERC 2008 22 nov 2008

Main tunnel systems

■ Wind generation (‘Facility’)■ Model positioning (Test Object Positioning And

Control, ‘TOPAC’)– Controls all movable objects in the measurement

area■ Data Acquisition■ Data Processing

– Derives aeronautical data from measurements■ Safety


NWERC 2008 22 nov 2008

Wind tunnel systems


NWERC 2008 22 nov 2008

A GAIUS system

GAS

FacilityController

TOPACData

AcquisitionData

Processing

Low LevelController

PLCSensor

Systems

Apropos

Automated

Integrated

Computer

Manual

Preparation Presentation

GUI

Measurement CycleRT data area


NWERC 2008 22 nov 2008

GAS

RTPS

GAIUS Bus

GUI

TOPAC Data Processing Data Acquisition Facility Control

NFS

Mass Storage(NFS server) Backup


NWERC 2008 22 nov 2008

Architecture & Requirements???

■ Requirements focus on functional behaviour■ Architecture focuses on non-functional

characteristics■ Both are usually needed■ However, non-func determines customer

satisfaction!


NWERC 2008 22 nov 2008

Architecture & Requirements

Principles

Choices

Decomposition

Architecture

Project Planning

Project Estimate

Detailed Design

Implementation

Integration Plan

Acceptance Testing

Principles

Choices

Decomposition

Architecture

Project Planning

Project Estimate

Detailed Design

Implementation

Integration Plan

Acceptance Testing

Requirements


NWERC 2008 22 nov 2008

Architecture & Agile Development

■ GAIUS was an Agile project– Cost of full requirements analysis was prohibitive

■ Even in an Agile project, you need foundations– Architecture is the foundation of your software

■ Agile development is suicidal before architecture is clear!– Use prototypes to quickly finalize architecture


NWERC 2008 22 nov 2008

Lessons learnt

■ Don’t increase team size too soon– Architecture needs to be mature first!

■ When using Open Source, check for maturity– Open Source RTPS implementation not sufficiently mature– Made our own implementation in 1.5 manmonths

■ LabVIEW is not as open as advertized– Lots of quirks and missing documentation in C interface– Would not use it again for this purpose

■ Python offers an excellent programming platform– Saved the day!


NWERC 2008 22 nov 2008

Questions?

Documents

Imtech ICT Technical SystemsNWERC 2008 22 nov 2008 Practical development Illustrated using the GAIUS windtunnel automation system By: Evert van de Waal