1. Practical development
Illustrated using the GAIUS windtunnel automation system
By: Evert van de Waal
Imtech ICT Technical Systems

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

3. 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:
In this presentation, the approach used to create the winning entry is described

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

5. Wind tunnel Structure
Fan, Silence chamber, contraction, measure location, control room

6. Test Object
Model positioning, Large forces, point out the various sensors (balance, pressures, optical)

7. Data Acquisition

8. Presentation

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

10. Examples of Experiments

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

12. A Request Please, make me an automation system
How would you proceed???
Interaction: ask the public what they would do when approached with this question.
Write down the remarks

13. 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???
Ask public who determines what is important, write down answers.
These are all stakeholders!

14. 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???
Let the public think about what determines non-func behaviour

15. 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
Ask if they agree with the final observation

17. Different Worlds

18. Bridging the Gap

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

20. Architecture as a bridge

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

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

23. GAIUS Stakeholders External (DNW) Internal (Imtech) Management
Project Engineer
Test configurator
Tunnel Operator
Developer
Internal (Imtech)

24. 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.
Main one: use scripts to automate the system
Adaptable to accommodate changes!

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

26. 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
These are the selling points of GAIUS
A different view / summary of the system
Next slide: priciples

27. 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!

28. Principles for GAIUS Use Open Source Software (as much as possible)
Open and cost effective
Use Python (as much as possible)
Proven high-productivity language, very open, portable
Use Industry Standards
Again, open & cost effective
Use the GAIUS Bus (=blackboard pattern)
Open, adaptable, best practice
Use a standard module interface
Allows scripting

29. Additional principles
GUI’s are separate components
Easy to simulate, allows automated testing
Communicate with modules using GAIUS bus
Scripting uses same interface as GUI!
Communicate with HW through TCP/IP
Open, easy to simulate & test without tunnel
Next slide: refinement -> choices

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

31. 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
Next slide: decomposition

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

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

34. Wind tunnel systems Complexity filters upwards Safety downwards
Multiple independent tasks operating together on a common task

35. A GAIUS system
RT data area
Measurement Cycle

36. GAS GUI Backup GAIUS Bus RTPS TOPAC Data Processing Data Acquisition
Facility Control
NFS
Mass Storage
(NFS server)
Backup

37. Architecture & Requirements???
Requirements focus on functional behaviour
Architecture focuses on non-functional characteristics
Both are usually needed
However, non-func determines customer satisfaction!

38. Architecture & Requirements
Animated slide: without and with requirements

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

40. 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!

41. Questions? Some questions: -> Role of the architect in the team
-> Role during project sales
->