Preliminary Implementation and Validation of the Collaborative Engineering Demonstrator · 2016-05-31 · Deliverable D56 Preliminary Implementation and Validation of the Collaborative

Deliverable

D56

Preliminary Implementation and Validation of the Collaborative Engineering Demonstrator
WP37 Collaborative Engineering Demonstrator
Lutz Sc

P

SIXTH FRAMEWORK PROGRAMME

RIORITY IST-2002-2.3.1.9

David Golby Editor BAE SYSTEMS

Advanced Technology Centre 5nd February 2007

V1.0

Contributors hubert (HLRS)

D56 – Preliminary Implementation and Validation TRUSTCOM – 01945 05/02/2007

Page 2

LEGAL NOTICE

The following organisations are members of the TrustCoM Consortium: Atos Origin Sociedad Anonima Espanola, Council of the Central Laboratory of the Research Councils, BAE Systems, British Telecommunications plc, Universitaet Stuttgart, SAP AktienGesellschaft Systeme Anwendungen Produkte in der Datenverarbeitung, Swedish Institute of Computer Science AB, Europaeisches Microsoft Innovations Center GMBH, Eidgenoessische Technische Hoschschule Zuerich, Imperial College of Science Technology and Medicine, King's College London, Universitetet I Oslo, Stiftelsen for industriell og Teknisk Forskning ved Norges Tekniske Hoegskole, Universita degli studi di Milano, The University of Salford, International Business Machines Belgium SA .

© Copyright 2007 BAE SYSTEMS on behalf of the TrustCoM Consortium (membership defined above).

Neither the TrustCoM Consortium, any member organisation nor any person acting on behalf of those organisations is responsible for the use that might be made of the following information.

The views expressed in this publication are the sole responsibility of the authors and do not necessarily reflect the views of the European Commission or the member organisations of the TrustCoM Consortium.

All information provided in this document is provided 'as-is' with all faults without warranty of any kind, either expressed or implied. This publication is for general guidance only. All reasonable care and skill has been used in the compilation of this document. Although the authors have attempted to provide accurate information in this document, the TrustCoM Consortium assumes no responsibility for the accuracy of the information.

Information is subject to change without notice.

Mention of products or services from vendors is for information purposes only and constitutes neither an endorsement nor a recommendation.

Reproduction is authorised provided the source is acknowledged.

IBM, the IBM logo, ibm.com, Lotus and Lotus Notes are trademarks of International Business Machines Corporation in the United States, other countries or both.

Microsoft is a trademark of Microsoft Corporation in the United States, other countries or both.

SAP is a trademark of SAP AG in the United States, other countries or both.

'BT' is a registered trademark of British Telecommunications Plc. in the United Kingdom, other countries or both.

Other company, product and service names may be trademarks, or service marks of others. All third-party trademarks are hereby acknowledged.


Page 3

Deliverable Datasheet

Project acronym: TrustCoM Project full title: A trust and Contract Management framework enabling secure collaborative business processing in on-demand created, self-managed, scalable, and highly dynamic Virtual Organisations

Action Line: AL3 Demonstration Trials

Activity: Activity 3.1 Collaborative Engineering Demonstrator Work Package: WP37 Collaborative Engineering Demonstrator

Document title: Migration and Demonstration Plan for the Collaborative Engineering Demonstrator

Version: v1.0 Document reference: Official delivery date: 31st October 2006 Actual publication date: 5nd February 2007 File name: D56 Preliminary Implementation and Validation.doc Type of document: Report

Nature: Public

Authors: David Golby (Editor) Contributors: Lutz Schubert (HLRS)

Reviewers:

D56 – Preli

1 Introduction..................................................................................................................10

minary Implementation and Validation TRUSTCOM – 01945 05/02/2007

Page 4

TABLE OF CONTENTS Version History .....................................................................................................................8

Executive Summary..............................................................................................................9

2 Revised Plan ................................................................................................................11

3 Review of Requirements.............................................................................................13

3.1 Functional Requirements ....................................................................................13

3.2 Other Requirements.............................................................................................13

4 Application Scenario...................................................................................................16

4.1 Analysis.................................................................................................................17

4.1.1 Application Aspects of the Scenario ................................................................17

4.1.2 Security Aspects of the Scenario ....................................................................18

4.1.3 Reliability and Monitoring Aspects of the Scenario .........................................19

4.1.4 Collaboration and VO Management ................................................................21

5 Development of the Demonstrator.............................................................................23

5.1 Review of TrustCoM Components ......................................................................23

5.1.1 Infrastructural Components .............................................................................23

5.1.2 Security ...........................................................................................................24

5.1.3 Quality of Service ............................................................................................24

5.1.4 Management ...................................................................................................24

5.2 Application Service Development.......................................................................25

5.3 Integration of TrustCoM Components ................................................................26

5.4 Risks......................................................................................................................28

6 Next Phase ...................................................................................................................29

6.1 Requirements for the Next Phase .......................................................................29

6.2 Demonstrations ....................................................................................................29

7 Revised Demonstration and Reporting Plan.............................................................30

7.1 BAE Demonstration and Reporting Plan............................................................30

7.2 HLRS Demonstration and Reporting Plan..........................................................30

7.3 SAP Demonstration and Reporting Plan ............................................................31

7.4 Contribution to other initiatives ..........................................................................32


Page 5

8 Conclusions.................................................................................................................33

9 References ...................................................................................................................35

10 Appendices ...........................................................................................................37

10.1 Symbols Used in the Text....................................................................................37

10.2 An Optimisation Study for TrustCoM [Contributor: S Leary BAE SYSTEMS].37

10.2.1 Introduction .....................................................................................................37

10.2.2 The optimisation process ................................................................................38

10.2.3 Geometry Generation......................................................................................39

10.2.4 CFD Analysis ..................................................................................................40

10.2.5 Post-processing ..............................................................................................40

10.2.6 Optimisation Results .......................................................................................41


Page 6

Glossary An explanation of terms used within the document.

Term Description ACL Access Control List.

BPE Business Process Enactment- the business process management sub-system in the TrustCoM framework.

CD Collaboration Definition. A document that forms part of the VO agreement that binds the members together. It defines the information that specifies the business process choreography that the VO enacts.

CE Collaborative Engineering

CEM Computational Electromagnetic Modelling. The modelling of radar, antenna performance (mobile phones, aerials, radio etc) by means of numerical techniques similar to CFD.

CFD Computational Fluid Dynamics. The use of computers for the simulation of fluid (eg, air, water) behaviour. Used in weather forecasting, aerodynamics etc.

COI Community of Interest. A particular interest group such as customers, system administrators, application developers, middleware providers etc etc.

CSM Computational Structural Mechanics. The modelling of the effect of impacts (eg, bird strike), detonations etc on structures (buildings, planes etc) by means of computer based experiments.

EM Electromagnetic, eg, EM Analysts- engineering specialists who analyse the performance of antenna or electronic equipment.

GVOA General Virtual Organisation Agreement- an electronic agreement between partners containing the SLAs and policies that govern the VO.

HPC High Performance Computing.

PDD Product Design Database. A database for the storage, retrieval and tracking of all product-related information including customer requirements, designs, production-related specifications and product manuals.

QoS Quality of Service.

RI Reference Implementation. This refers principally to the TrustCoM Reference Implementation in the text.


Page 7

SLA Service Level Agreement. The electronic agreement between the service provider and customer.

SME Small to Medium Enterprise.

SOA Service Oriented Architecture. The software architecture based on the use of web-services for inter-enterprise business messaging.

STS Security Token Service. Generates claims or statements about the originator of a web service message or of the provider of the service itself. Used for supporting federated Trust-based security within the VO.

TSC Trust, Security and Contract. Used in various contexts eg, for denoting a service within the TrustCoM framework or a particular task or task role within the TrustCoM Business Management framework.

TTP Trusted Third Party.

VO Virtual Organisation. A model of a collaboration that involves companies, academic institutions, governmental organisations sharing resources to achieve a common objective.


Page 8

Version HistoryDate Description Subversion Revision Id

05/01/07 Skeletal outline of the document, assigning partner’s responsibilities etc

-

05/02/07 Final edition. -


Page 9

Executive Summary The WP37 team have encountered the same kinds of uncertainties in its development plans as in WP35. As described in D65, these stem from the final phase of integration that has taken place over the period of November 2006 into February 2007. Aspects of this have taken longer than expected due to different conceptual and practical challenges. In all, these have impacted on the work planned for D56 necessitating a final spurt of effort over the January/February period of 2007. The application scenario has been modified from that originally planned due to a) changes in staff at BAE and b) developments within the SimDat project. The application scenario is now based on the BAE SYSTEMS Decifer optimisation tool that is a significant engineering application used by many internal Business Unit customers. We believe that the new application scenario now has stronger connections with other projects (through the planned adoption of GRIA) and will give existing customers a more tangible understanding of what TrustCoM can offer collaborative engineering. Resulting feedback will be used to improve the prototype in the final phase. Regarding the deployment of TrustCoM within the demonstrator, the decision was taken to focus as a first priority on infrastructural and security aspects of the TrustCoM RI. This has involved using the latest EN/VO components along with the revised STS and became available to the WP37 team in mid January. These components have undergone significant changes that have necessitated a fresh analysis of how they can be integrated into the demonstrator. At this time, a clear strategy for integrating them into the system has been identified and is currently in progress. Critical to this has been the support from the relevant development teams. The SLA sub-system within the demonstrator continues to use the same components as used in WP35 CE Test Bed. The new application scenario raises some new issues but we decided to adopt a pragmatic approach in the first phase that reduces risk and the need for last minute development. The management aspects of the scenario are perceived as lower priority at present but promise to bring much value in terms of automation and simplifying the configuration and management of the services within a collaboration. This will be pursued in the final phase of development. Critical to this is the final integration of the VO Toolkit and Gateway components, an activity that is only just being completed at the time of writing of this report. The demonstration planned for the review will show how selected components are used for supporting security and SLA with the application services.


Page 10

1 Introduction This document describes the progress that has been made to date in implementing the Collaborative Engineering Demonstrator. It describes the changes to the original plan, the development of the application services that has been achieved to date and the integration of TrustCoM components within the Demonstrator. Sections 2 and 3 describe the revised plan and requirements for the demonstrator. This also describes the strategy for HPC integration that is currently been adopted in the BAE SYSTEMS Advanced Technology team and in which the results from TrustCoM will be exploited. Section 4 describes the application scenario and provides an analysis of the TrustCoM components that are currently available to show how they will be deployed. The development of the demonstrator in this current phase is described in Section 5 and the next phase of work is described in Section 6. Progress with exploitation and dissemination has not been possible due to the high priority that had to be assigned to AL2 during this period. However, we present the revised exploitation and dissemination plans in Section 7.


Page 11

2 Revised Plan Progress in this work package has been affected by a number of factors:

1. the continued development of critical TrustCoM components required for the demonstrator

2. changes in staff at BAE, necessitating a change in the application scenario 3. effort required for AL2 during a very critical period of the project

Due to these factors, the plan has been revised. It now consists of the following tasks:

1. Review of Key Questions and Requirements 2. Development of a new application scenario 3. Assessment of TrustCoM components- their maturity and likely benefits for

the Demonstrator 4. Implementation of application services 5. Integration of TrustCoM components into the Demonstrator 6. Reporting and Dissemination

The following diagram shows the connections between the tasks.

T2TrustCoM

Component Selection

T2TrustCoM

Component Selection

BAE requirements

T1Review

Requirements

T3Scenario

Development T4App ServiceDevelopment

T4App ServiceDevelopment

T5Integration

Of TrustCoM

T5Integration

Of TrustCoM

T6Reporting andDissemination

T6Reporting andDissemination

Figure 1 Task relationships for the CE Demonstrator Work Package

The integration task (Task 5 above) is divided into two phases: 1. Integration with security and SLA sub-systems, and 2. Integration of VO Management into the Demonstrator and deployment of

application services over partner sites.


Page 12

The reasons for this two-phase approach are based on the preliminary evaluation of components described in D54 and which is discussed later in this report. It should be noted that the development work in AL2 was ongoing at the time of writing of this report:

1. EN/VO gateway was delivered in mid-January but required extensive end-user support during this period

2. The VO Toolkit was undergoing final integration with the EN/VO and other TrustCoM components

3. SLA was complete and ready for integration 4. Security – principally STS, PDP- were complete and ready for testing


Page 13

3 Review of Requirements

3.1 Functional Requirements The top-level functional requirements described in D37 are unchanged. Highest priority remains with service security, since this is a top-level concern within BAE SYSTEMS and is a critical factor in the further take-up of SOA within the company. Service reliability retains secondary importance as well. Ensuring that the performance of services is monitored and the ability to take an adaptive set of corrective actions as service behaviour changes continue to be important requirements. In third order of priority is management. Manageability and service governance are now very important issues for companies who have already satisfied themselves that security and reliability of SOA is, in principle at least, possible. The ability to manage services for different collaborators and suppliers is one that TrustCoM addresses within its VO model. VO Management becomes important for a company such as BAE when many ad-hoc collaborations are possible. At this present time this is not a near term requirement, at least for collaborative engineering, but is one that is important for the successful exploitation of services in future potential JVs that are formed to quickly exploit a market opportunity and which aggregate many services from different providers/suppliers.

3.2 Other Requirements These concern requirements driven by the program of work being conducted within the ITG group in the area of HPC service provision. The requirements here are concerned with the advanced HPC capability that is now required for different internal and external customers. This is being developed using the results from many different past and present projects one of which concerns the present project, TrustCoM. The following diagram shows a representation of the HPC framework to which the BAE SYSTEMS ITG team are currently working.


Page 14

MicrosoftWorkflow Manager

GRIA SYSTEM

Job Manager

Data Provider

MicrosoftWindows Cluster

LinuxCluster Supercomputer

GRIAWorkflow Manager

MicrosoftWorkflow Client Taverna ModelCenter

HPC Platform

Resource Management

Workflow Management

Workflow Client

Figure 2 BAE SYSTEMS HPC Framework

The framework is intended to provide a flexible system that meets the varying needs of customers who have different preferred HPC platforms, workflow management and workflow definition clients. The framework consists of the following levels described in the following table:

Level Description

Workflow client A tool for the composition of an orchestrated process

Workflow management

A service for co-ordinating an orchestrated process that executes application services The process is also accessible as a single service in conformance with service compose-ability requirements.

Resource Management

A system for account and job management on HPC and data storage platforms.

HPC Platform The host of the application service.

Table 1 BAE SYSTEMS HPC Framework- Level description

For example, an engineer could use the Microsoft Workflow designer for specifying the process he/she wishes to enact. This is executed by the Microsoft Workflow Manager to coordinate services hosted a range of platform- which could include a Linux cluster, Microsoft Windows Cluster or a production supercomputer batch system. The customers for this system include:

1. Airbus UK- engineering-design optimisation services using ModelCenter as the client- using Decifer

2. BAE SYSTEMS Air Systems UK- engineering design optimisation and HPC services for design simulation using Decifer


Page 15

3. BAE SYSTEMS Insyte- image processing using HPC 4. Other BAE SYSTEMS Business Units including Land systems- for CFD and

engineering-design optimisation services and Air programmes. Corporate BAE IT services- for enterprise integration.

GRIA 5.0 [] is reserved a role for job management and data storage services. It hosts engineering applications that are managed through it- account management, authentication and an SLA system are currently supported. As can be seen in the above diagram, it encompasses a number of different layers of the architecture including workflow definition (Taverna), workflow management and resource management. GRIA has seen significant improvements in usability and maturity that make it a promising candidate for this role in the BAE HPC framework. Current limitations of the system include:

1. The SLA model used by GRIA is proprietary and not standards based 2. exceptional events within the system must be dealt with by human

intervention 3. The membership within any collaborations that uses these services is static

and not easily changed. 4. monitoring of services and reconfiguration of the system as service

performance changes is not currently possible. 5. limited support for policies that control membership and access controls

The requirements are therefore: 1. TrustCoM must be demonstrated within this framework using realistic

applications or problems of interest to current BAE customers 2. TrustCoM technologies must be integrated alongside the GRIA security and

account management system; GRIA is in a sense representative of legacy systems

3. The technologies must be compatible with, or work alongside, the process execution engines that are currently targeted. Eg, GRIA uses SCUFL

4. VO Lifecycle and membership models should, ideally, be adopted in order to automate the management of the collaboration.


Page 16

4 Application Scenario This section presents the revised application scenario for the Demonstrator. Note that it represents the full scenario that is the subject of this work package. Phase 1 of the development, described later, focuses on achieving particular parts of this scenario and not the full scenario. An aeronautical engineer has been tasked with taking an existing design of a wing and changing it to meet new design requirements. She has access to a design database with a set of 2D sections that are to be changed. One of these designs is selected and is to be improved against the set of new design requirements. Using her preferred client tool, the current design is viewed and the reference to the design is submitted to an in-house optimisation service that is used across her company. This in turn relies on a third party HPC provider that is used by the optimisation service to generate performance predictions of the many different design alternatives generated by the optimisation algorithm. The two services effectively constitute an ‘optimisation virtual organisation’ that provide a new capability for exploring possible design solutions. The optimisation service retrieves the model from the client’s PDD and activates its algorithm to generate many different design alternatives. These are all submitted to the HPC service and the results are used to generate a ‘response surface’. This gives her an impression of the critical design parameters that achieve the best performance of the design. The scenario now ends. The following diagram shows in pictorial form the scenario and the actors that are involved. It also indicates the sequence of interactions during the optimisation process. Note the agreement encompasses an operational policy and a service level agreement, both of which regulate the VO.

EngineerEngineer

Product Design DatabaseProduct Design Database

Optimisation VO

Client Company Domain

(1) (2)

(3)Optimisation

Service

HPCService

Agreement


Page 17

4.1 Analysis This section presents an analysis of the scenario from different perspectives and describes the various options for applying TrustCoM to the scenario.

4.1.1 Application Aspects of the Scenario The following diagram presents a top-level view of the optimisation loop that is used. The optimisation code to be used in this scenario is the BAE SYSTEMS Decifer system [5]. Decifer is a general purpose multi-disciplinary optimisation application based on the following architecture:

1) Model generation2) Simulation3) Post-processing

Evaluator

Decifer OptimisationSystem

Model parameterData for

Many runs

PerformanceData generated

From many simulations

Figure 3 Decifer Optimisation Loop

The optimisation service is based on a Genetic Algorithm (GA) which relies on the results of a batch of simulations (performed by the Evaluator component) to determine the optimal solution to the problem. The GA enters a cycle whereby many HPC requests are generated, data is extracted and new design variables are produced for the next cycle. This cycle continues until the design objective is met. Appendix section 10.2 describes the Decifer application study for TrustCoM in greater detail. In a service model, there would be advantages from deploying the Decifer optimisation system and the Evaluator as two separate services. However, there are two options for implementing the Evaluator:

1. splitting the evaluator into a client-side and service-side components. The client-side component would generate model data and upload it to a storage provider. The storage provider would then be accessed by a third-party general simulation service that hosts the application to be used.


Page 18

2. Treating the evaluator as a single component that can be deployed as a single service. All of the processing is done server-side.

The second option will be taken as it represents the most efficient way of performing the evaluations. Data can be cached locally and be directly re-used without any communication overheads. Having selected this option there are two further choices to consider. This concerns how the request to execute multiple design simulations (the input on the right hand side of the Evaluator shown in the figure) should be performed:

1. the evaluator service is sent many requests, each containing a single job specification, or

2. a single request is submitted containing many batched requests. In the first edition of the Demonstrator the first option will be taken as this exploits directly the previous work done with the NEC service in Al2. The second option will be implemented pending the success.of the first implementation and should be considered a performance-enhancing step. Other notes:

1. A 2D flow solver- XFOIL [6]- is used on the HPC service host to generate the flow predictions

2. The problem consists of a 2D airfoil for which the lift is fixed and the drag is minimised- a ‘constrained optimisation’ problem

3. A 2 parameter optimisation problem is used. This makes response surface visualisation easier.

4. The turnaround times of the simulation are very quick, enabling live demonstrations to be easily presented.

The use of Decifer meets the requirement of a demonstrator that uses non-trivial applications. However, the product to be optimised is deliberately chosen to be relatively simple for the sake of possible live demonstrations of the software.

4.1.2 Security Aspects of the Scenario As noted earlier, the overarching requirement for the demonstrator is to ensure that the security requirements of GRIA and the TrustCoM framework are harmonised or, at the very least, can be both satisfied without conflicts. In connection with the previous point, it should be noted that GRIA currently requires the user to digitally sign any requests using an X.509 certificate. Any resources created by the client- whether jobs or data- are under the client’s control and have associated permissions that are derived from the identity expressed in that certificate. Therefore, this requirement must continue to be respected.


Page 19

On the other hand, the TrustCoM authentication model is based on federated security using SAML based tokens. The current work will address to what extent this can work alongside the GRIA security requirements outlined above. If this turns out not to be possible, then other demonstration options will be considered – these are discussed later. The advantages of the TrustCoM security framework is that, it includes not only policy-based access control but also the ability to re-configure the system in response to any undesired events in the collaboration- eg, security intrusions. In particular, the demonstrator will include:

1. message interception by TrustCoM and enforcement of message security policies on organisational boundaries

2. access control policies based on security roles, in particular the engineer principal is assigned a security role ‘E’ that grants him access to the Optimisation VO. Assignment of this role is based on local policies that may either allow or deny access to the request before it leaves his/her domain.

3. the use of policy-based event-driven management to deal with exception occurrences- eg, a security breach in the VO is detected by the optimisation VO and access is denied to further requests from client.

We further stress that the integration of GRIA security and TrustCoM is an interesting test of how legacy systems with their own security requirements can be integrated with TrustCoM. This will be a key outcome of this work.

4.1.3 Reliability and Monitoring Aspects of the Scenario The SLA system in GRIA is currently based on its own proprietary system that is different to that adopted in TrustCoM. The options here are a) to integrate it with the TrustCoM sub-system in some way, or b) disable it and use the TrustCoM version instead. It has been decided that for the sake of time and effort that the second option should be taken. This option also ensures that one of the key contributions of TrustCoM- standards based SLA management- can be carried over into the demonstrator. In particular, the SLA system for the industrial demonstrator will continue to rely on the basic SLAs developed in WP35 for the CE Test Bed. More specifically, the demonstrator will re-use the SLA that is associated with an agreed level of CPU reservation for the client’s requests on the evaluator machine. However, the new application scenario poses new SLA issues that need to be addressed. This refers to the possibility, that certain simulations specified by the optimisation service may be poorly conditioned or may be out of the scope of the abilities of the simulation service being used in the Evaluation component. In other words, these simulations may fail not through the fault of the service provider host but through a fault of the input data provided by the client. From the SLA / contract perspective it is important to distinguish between the failures caused by the input data from those caused by faults in the resource the job(s) are


Page 20

hosted on. This is to ensure that the correct decisions and actions are taken with respect to the provider’s reputation, payment or related aspects. The SLA Management system is agnostic as to the actual meaning of errors in the system, i.e. whether an exception is caused due to an error of the platform or through some service application-fault. In any case, the SLA Monitor (as the component reporting the system status) is reliant upon measurable events that can be either queried or are actively provided to the monitor. According to the strict interpretation of the architecture, the responsibility for this rests with the data-providing components. In the typical case, these may be system monitoring tools such as WMI (integrated into the Windows Operating System) or Ganglia (an open source tool). There is, however, no restriction in principle as to what kind of, and accordingly how, such data could be gathered. The afore-mentioned system monitoring tools faithfully report accurate information since no hardware error as such is recorded during the application-failure of the service as outlined earlier. However, to ensure correct classification and registration of such events and for potentially allowing the user or system to react to such data given failure (e.g. by restarting the process with an alternative data set), it is recommended to provide monitoring systems that unambiguously identify the fault1. This kind of strategy is typically employed by most programmers in their applications, ie, throwing meaningful exceptions that can be trapped and managed in the correct manner. These application error events may, in principle, be easily captured and interpreted by the SLA Monitoring subsystem given the appropriate metrics (and hence some background knowledge about the applications executed). If such steps are not foreseen in the code, respectively are unknown to the constructor of the SLA metrics, alternative solutions strongly depend upon the metrics specified in the SLA: basically all circumstances not fulfilling the SLA conditions must relate to the erroneous data set. Note that there is no conceptual or practical issues involved with employing the SLA Monitoring subsystem as a simple supervision tool in the Service provider domain. In fact this kind of application is recommended for self-management in a service provider domain [7]. As such, it is possible for the Service Provider to host an application specific supportive SLA as provided by the customer who possesses more insight into the error behaviour of the code. The information gained through this “add-on” SLA may then again be exploited for the actual contract-related SLA by integrating the status events as a parameter source. In any case it will mostly depend upon both parties to construct an SLA that specifies unambiguous metrics that allow for identification of error codes given the underlying system tools. All in all, the SLA Management subsystem can cater for these kinds of scenarios, provided that the metrics are defined correctly in the underlying SLA(s) and that the

1 As opposed to unambiguously identifying any potential error source – it is up to the actual use case how defined such an information is required.


Page 21

parameters can be provided / accessed by the Monitor. This involves: 1) writing the appropriate SLA that both parties understand, 2) developing a data providing tool and 3) establishing a link between the SLA Monitor and this new data provider. The last step is a software integration issue since this requires a means of describing all potential tools sensibly in a way that would allow a standardised link to the SLA Monitor. At this time TrustCoM currently only supports the most common tools, namely WMI and Ganglia. In summary, it is a recommendation for follow on work to provide an open interface or API to make the integration of service providers’ application-specific tools easier. As a practical step in this demonstrator, we shall adopt a simpler approach and assume that a legal agreement should exist between the client and provider stating:

1. that the evaluator service provider shall inform the client of any application-faults that occur and record them to an audit service when they occur

2. that the service provider provides as much information as practically possible of the range of permitted input data parameters that can be supported by the service

3. that any application-faults that occur within scope of the supposed capabilities of the service shall lead to any roll-back of any charging that may have been incurred on the client’s account during the execution of the service

4. that the service provider is entitled to dispute any claims from the client that the service has defaulted on its required capabilities.

Therefore, the service is contractually required to report these faults directly to the client through application-specific error codes/messages contained in the output. Furthermore, these messages are recorded for future audit and accounting purposes that may be used by the client to dispute any particular charges that have been applied to his/her account during the lifetime of this VO. Regarding 2, information on the capabilities of the service will be communicated via some out-of-band mechanism- eg, via studies and reports (validation handbooks etc) that may be endorsed by trusted third party bodies. The reputation of the service- is one aspect of this and the extent to which the TrustCoM Reputation system can support this kind of scenario will be investigated further in phase 2.

4.1.4 Collaboration and VO Management These can be broken down into two aspects:

1. VO Management 2. Business process management

As noted earlier, the current limitation of the HPC framework is that dynamic membership and lifecycle aspects are not managed in either an automated way or through some software system. These have, to date, been done by out-of-band means.


Page 22

For reasons described earlier, the requirement for VO Management is currently classified as ‘desirable’ rather than ‘mandatory’ for the kinds of near-term collaborations that are envisaged. In the second phase of work, however, the TrustCoM VO management system will be deployed to address:

1. to what extent lifecycle management can be accommodated, eg, in discovery, negotiation and possible replacement of alternative simulation services, and

2. to see if a choreography model can work alongside the orchestration models adopted by GRIA/Taverna and other workflow systems

In principle the answer to the second question is ‘yes’ but at present the VO Member edition of the Toolkit assumes that a BPEL-compliant process execution engine is deployed in each partners domain. The options here are:

1. to write a translator for CDL to proprietary workflow formats 2. extracting WSDL interfaces for each business role from the CDL and relying

on these as the basis of services that enacting the business process roles 3. removing choreography as a fundamental aspect of this particular VO and

concentrating on service membership instead. The first approach here will be to adopt the VO Toolkit purely in its management role and to not apply the collaborative business process aspect in the CE Demonstrator. This would provide two important functions:

1. Managing and regulating the membership of HPC providers that are used by the Decifer system, ensuring that the best HPC providers are used, and

2. Managing the configuration of services as their respective service providers enter or leave the VO.


Page 23

5 Development of the Demonstrator As described earlier, the demonstrator is planned to be developed in two phases:

1. Phase 1: basic infrastructural support, security and SLA 2. Phase 2: VO Management and business process execution support

This report is focussed on Phase 1 and so the following analysis section places greatest emphasis on the relevant components.

5.1 Review of TrustCoM Components This section reviews the TrustCoM components that were used in the CE Test Bed and demonstrated at the October 2006 Review. The intention in phase 1 of the demonstrator reported here is to use the final editions of these components as planned to be delivered during the fall of 2006 in to January 2007.

5.1.1 Infrastructural Components The relevant components here are:

1. Service instantiator 2. PEP 3. Notification Proxy 4. SIR

During the development of the CE Test Bed in 2006 these components were found to satisfy the basic requirements for enterprise messaging in the Demonstrator, ensuring that messages were protected in transit between the client and the service and that a federated security model could be adopted. However, it should be stressed that the PEP and Instantiator components were at that time in an intermediate state and therefore it was decided to postpone using them until their final release versions were available. Therefore, all of the components above are adopted for the Phase 1 Demonstrator. The PEP and Instantiator components were undergoing their final phase of development during the latter part of 2006 and were finally released in mid-Jan 2007. These are currently being deployed with the support of the relevant development teams (BT and HLRS. The SIR is undergoing its final integration with the rest of the EN/VO infrastructure and will be used once it is ready. Therefore, work will proceed in two phases:

1. the Gateway and PEP components will be deployed and tested first with the application services.


Page 24

2. As soon as the SIR has been successfully integrated with the new EN/VO infrastructure this will be deployed as well.

The Notification proxy is now in a mature state and will be deployed within the demonstrator. This will be used in conjunction with the Policy service to respond to any events (application-specific of ‘infrastructural’) within the VO.

5.1.2 Security The relevant components include:

1. STS 2. PDP 3. SAWS

The STS has also undergone final revision during the autumn of 2006 and became available in early Jan 2007. This has been fully integrated into the EN/VO Gateway and will be used in the first phase described above.

5.1.3 Quality of Service GRIA includes its own SLA management sub-system. Since SLA is a critical component in TrustCoM- it is the main method for governing VO Membership to date- the GRIA SLA sub-system will be disabled for the purposes of this demonstration. The TrustCoM SLA sub-system encompasses the following components:

1. Data provider: for generating the basic performance data associated with the service SLA

2. SLA evaluator: for comparing the above data with the agreed SLA The evaluation found that the SLA sub-system satisfied the minimal requirements for service performance monitoring and reporting, including the ability to reconfigure the system to log messages to the SAWS. Therefore the two components shown above will be included in the Phase 1 Demonstrator.

5.1.4 Management Management encompasses the following TrustCoM components:

1. VO Management 2. Policy Service- for management using Event-Condition-Action rules 3. SLA Management, and 4. BPE


Page 25

It can be argued that 4 (BPE) is strictly speaking a non-management function within the system. However, it has very close associations with the management sub-system and so is included here for convenience’s sake. VO Management, as provided by the VO Toolkit, shows a promising way of governing the lifecycle and membership of the VO. However, it was found to be very challenging to use due to:

1. its requirement for a CDL description of the collaborative business process and

2. the need to populate a ‘knowledge base’ of BPEL fragments for each partner enacting a business role.

The latter is necessary for completing the internal private business processes that are executed by each partner. The task involved with populating the knowledge bases is ongoing at present and is being supported by SAP in AL2. Furthermore, at the time of the Review it was only possible to show a limited demonstration of its capability and was not fully integrated into the CE Test Bed. Therefore, to minimise risk we decided to postpone the use of the VO Toolkit until the work in WP35 produced more tangible results. In particular, the Knowledge Bases completed during that phase would be re-used for the applications being used in the demonstrator work. In the light of this experience, an alternative choreography would be developed for the new application scenario in the final phase. The other two components- Policy Service and SLA management- concern managing the VO from the perspective of the SLA only. In particular, it was able to show an adaptive and flexible management capability that was able to:

1. activate message logging if a service’s reputation was found to change, and 2. replace a member if the SLA between it and the client was broken

In view of the fact that the SLA management and VO Management sub-systems was being integrated during autumn 2006, it was decided to focus on the first capability for the time being. Lifecycle and membership management will be the focus of the second phase, described later.

5.2 Application Service Development This has involved the following tasks:

1. Development of application models and data for the optimisation study. 2. Deployment and configuration of the GRIA platform 3. Development of a Decifer Web Application interface, hosted by BAE 4. Development of an Evaluator service suitable for this scenario

Limitations and restrictions: 1. The SLA used in the AL2 CE Test Bed will be re-used for this scenario and

will be based on reserved CPU for the XFOIL Evaluator service


Page 26

2. The Evaluator service is restricted to a particular application- xfoil. The Decifer web application will present end-users with a web browser (or ‘portal’) interface to the demonstrator, ensuring that it is easily accessible to Communities of Interest. Being service-based, of course, enables it to be integrated with other applications (such as the Decifer desktop client) as well.

5.3 Integration of TrustCoM Components Where it has been possible to do so, this has involved the configuration of existing TTP services that were deployed in AL2. The following diagram shows the components and their deployment in the Demonstrator. Note that this represents the Phase 1 version of the Demonstrator where the deployed components are focussed on security and quality of service. Other TrustCoM partners act as TTPs that provide value-adding services. These include SLA evaluation services, Policy service, secure auditing services and notification brokering.

SICS:TTPSLA Evaluator

IC:TTPPolicy Service

SLA Data provider

BAE: Client

EN/V

O Infrastructure

GRIA

BAE: VO Member

BAE:TTPSAWS Decifer Web Application

Decifer

HLRS:TTPNotification Broker

PDP

STS

STS

SLA Data provider

XFOIL Evaluator

HLRS: VO Member

PDP

STS

PDP

Figure 4 Phase 1 Deployment Model


Page 27

The following enhancements were introduced in order to make the presentation of the Demonstrator easier:

1. The PDP now has a web browser front end, showing the different policies that are deployed.

2. The SAWS re-uses the web browser front end demonstrated at the October Review.

An important and critical aspect of this design is how the Decifer Web Application is to be integrated with the PEP. The PEP requires the user to present an appropriate WS-Addressing element with a client end-point reference that contains information about the collaboration of which the client is a part. This information contains, amongst other things, implicit details of the security roles that belong to the requestor. To address this, a simple internal database that associates portal clients with an appropriate EPR will be set up. This ensures that their messages are assigned the correct requestor EPR for their current security role and thereby ensuring that the correct PEP handler chain policy is loaded. The following diagram shows this in more detail:

AppServiceDeciferWebApp PEP

Acct DB

From:EPR

PEP

Client

Client creds

The ‘From:EPR’ has an implicit security role, eg,Analyst, Engineer or project manager for this federation.The appropriate PEP policy is loaded which hasthe correct claims that can be used in the STS request.

Header

PEPpolicy

STS

The acct DB maps theclient to some ‘From:EPR’ value thatcan be used in the outgoing request

PEPpolicy

STS

12 3

4 5

6 7

8

9 10

11

Figure 5 Integration of portal security with the PEP

Note that as discussed earlier the federation used are currently hard-wired into the system and defined by out-of-band means. This can be relaxed in the second phase when the VO Toolkit will be integrated into the demonstrator.


Page 28

5.4 Risks The ongoing development described in this report is presented with a number of risks. The most significant of these includes difficulties with integrating the GRIA service with the TrustCoM EN/VO- particularly with respect to satisfying the WS-Addressing and WS-Security requirements from both GRIA and the EN/VO. In the event of this happening the Job Manager Service developed in AL2 will be deployed instead. This is an application service that has no WS-Security or WS-Addressing requirements of its own and should not present any challenges since it has previously been integrated with the PEP.


Page 29

6 Next Phase

6.1 Requirements for the Next Phase The next phase of work will see the integration of the final edition of the VO Management sub-system into the test bed. This will be used to demonstrate the following requirements:

1. discovery of service providers with the minimum requirements for service reliability and best reputation scores (R1)

2. the ability to automate the management of service providers and show how alternative service providers can be enrolled into the VO (R2)

3. the ability to define and execute a collaborative business process by co-ordinated execution of private business processes (R3)

Meeting requirement R1 is an objective of the final implementation phase of AL2. This will help the VO Initiator to obtain a list of potential partners for a VO with the most favourable SLA and reputation values. If this is successful, then this will be implemented within the CE Demonstrator. Requirement R2 involves the final implementation of VO Membership and lifecycle management. This is dependent on the availability of the final edition of the VO Toolkit, integrated with the SLA management and EN/VO systems. Requirement R3 is assigned lowest priority at present. This is due to the possible practical difficulties associated with extending the application scenario into a choreography model. The decision to address this requirement is based on the ability to a) define the appropriate CDL and b) complete the knowledge bases that are required by each VO member.

6.2 Demonstrations If the above requirements are met, then it will be possible to demonstrate:

1. the ability to execute internal private processes that are extended to include proprietary and sensitive activities that cannot be observed by other partners

2. automated management of the services regulated by a single electronic agreement that can simplify the configuration of the services for security and reliability requirements

If R3 is achieved: 3. the ability for service providers to join peer-to-peer relationships with well-

defined business roles within a collaborative business process


Page 30

7 Revised Demonstration and Reporting Plan

7.1 BAE Demonstration and Reporting Plan It should be pointed out that TrustCoM cannot be expected to be exploited within any commercial BAE product at this current state of its maturity. The purpose of the demonstrator is to assess its most useful features, to determine where improvements must be made and derive new requirements for follow-on projects. In phase 1, we plan to show the demonstrator to enterprise IT teams within our business group. We will seek their advice on how the demonstrator could be improved for a final pitch to EXOSTAR. Furthermore, it is planned to disseminate early results to CFMS and thereby to Airbus UK. As described earlier, a web site has been developed as an application-specific access point to the VO. Access to this web site will be granted to parties who are interested in using it for non-critical design work, or simply to learn how the system can be used in real-life applications. Phase 2 will be used for a demonstration to technical and managerial personnel in EXOSTAR. Emphasis at this point is on the use of trusted third party services (eg, SLA evaluator, Policy service, notification brokering and possible Gateway services) and VO management (membership and lifecycle management aspects) that could be hosted by EXOSTAR in future collaborative engineering projects that extensively use web services.

7.2 HLRS Demonstration and Reporting Plan HPC resource provisioning is coupled with high demands in the areas of security standards (access restriction, data protection and user authentication), as well as administration and maintenance (incl. management of the resources and jobs). In addition, some HPC providers will restrict their resources regarding the customer’s trustworthiness on basis of a negative recommendation system, i.e. whenever the customer was judged untrustworthy by some other, well-known party. HLRS will demonstrate the capabilities of the TrustCoM framework in the context of High Performance Computing resource provisioning: the University of Stuttgart currently provides HPC to a series of automotive, government, SME engineering companies and academics that make use of the environment for their respective complex calculations. Each user puts forward different demands to the system according to their respective needs and budget. Along the same line, not only the required quality of service parameters differ widely, but also - implicitly - the pricing for these services. TrustCoM will support the tasks of both HPC provider and consumer deploying a (calculation) job on the HPC by allowing easy definition and autonomous enacting of


Page 31

access right restriction, authentication, security enactment, reputation management etc. In particular, SLA Management support allows for specifying individual cost terms and usage condition & terms, which serves multiple purposes:

1) defining the “quality” (the requirements towards the platform) as needed by the calculation job (respectively the customer)

2) ensuring that the quality is maintained by constantly monitoring it 3) enacting consequences from maintaining, respectively not maintaining the

agreed quality – ranging from reputation update, via fines and bonuses to potentially even a lawsuit

4) autonomous accounting of costs due to resource usage 5) supporting self-management of the resources, by allowing the HPC provider

to specify his/her own SLAs that serve the purpose of supervising critical aspects of a resource (such as CPU usage etc.)

All in all, the SLA Management system will support the resource provider to autonomously supervise his resources. This reduction in overhead will allow easier maintenance of the resources and thus cheaper services for business customers.

7.3 SAP Demonstration and Reporting Plan SAP will use the demonstrator to influence their software products by using it is a demonstrator within the company and for potential customers. It will show how to manage VOs in an integrated fashion as a business concept in B2B scenarios that minimizes the administration overhead without unnecessarily sacrificing security.


Page 32

7.4 Contribution to other initiatives This table is essentially unchanged from that presented in the original WP37 plan []. Adopting GRAI will, however, make the connection to SimDat stronger.

Partner Initiatives Strategy Timescales

SimDat (Euro) Demonstrate application of SimDat application services within TrustCoM framework, where possible. Promote architecture and profiles.

2006-2007

CFMS (UK) Centre for Fluid Mechanics Simulation. Demonstrate how TrustCoM can improve the management of services within aerospace collaborations.

2007-

BAE SYSTEMS

CRISP(UK) Re-use TrustCoM framework as a candidate architecture for CRISP.

2006-2008

HLRS Initiatives related to HPC European projects

Exploit TrustCoM concepts and technologies that may benefit next generation Grid projects in Europe and regionally.

2006-

XtreemOS (Euro)

Port elements of VO management to the application level of a prototype Gird platform for Business

2007 – 2009

SAP

SAP Internal Transfer the knowledge gained from security and VO management in TrustCoM to development in the area of B2B and Web Services

2006 – 2008


Page 33

8 Conclusions The aim of the industrial demonstrator is to show how TrustCoM can support a service outsourcing scenario that enables HPC demand to be provided by external parties. There are many basic requirements for this kind of scenario but two are the most relevant in the context of TrustCoM. The first of these is that there should be a pool of service providers that can be enlisted/ejected into/from a collaboration on the basis of a well defined service level agreement. Furthermore, a common web service security infrastructure must be quickly established between the organisations in order to prevent disruptions. The particular TrustCoM sub-systems that are of importance here include service infrastructure, service security and service performance assurance. First of all, it has to be noted that this work package has faced the same challenges as experienced in WP35, namely the ongoing integration of critical components within AL2. The two most critical sub-systems that have received the most attention in that integration work are the EN/VO infrastructure (incorporating the Gateway, PEP, SIR, Notification proxy) and the VO Toolkit. The EN/VO infrastructure is the most critical of the two for CE. The final editions of the most important EN/VO sub-components (namely the Gateway, PEP) were received in mid-January and it was found from an end-user perspective that these have changed significantly from their original editions. In the case of the PEP, it is now clear that the version used during the summer/autumn of 2006 was very much an intermediate version- which may explain some of the difficulties encountered using it [4]. From our current understanding we conclude that the latest edition of the PEP and its supporting component the Gateway appear to be versatile (only a single PEP per organisation is now required) and promise to make the deployment and configuration of services for different VOs much easier. A strategy for integrating the EN/VO within the portal has been identified and this is currently in progress. The SLA sub-system is the most mature of the technologies addressed in WP35 and the relevant components will continue to be used in this workpackage. Emphasis will be on reserved CPU and the issue of application faults- their responsibility and so-on- will be side-stepped in this first instance by means of secure message auditing and clauses within (synthetic) legal agreements. The VO toolkit will be deployed in the final edition of the demonstrator. It can be said with some confidence that the VO management aspects- the lifecycle and management aspects- will be the most valuable additions for administering services within different collaborations. In this particular scenario, it is planned to use the VO management sub-system to oversee the outsourcing of HPC services to external companies and to quickly establish a common security infrastructure between the two organisations through its use of the EN/VO Gateway. However, the role of business process execution remains the most challenging aspect of this component- the definition of choreographies and the population of knowledge bases continues to be very difficult and has previously required


Page 34

substantial support from ETHZ and SAP. In addition to this, we are encountering within other projects a wide variety of preferred business process execution languages that are not currently supported in the VO toolkit. This makes promotion of this particular technology more difficult. Will BPEL win out as a universal standard or will it be worthwhile to adapt CDL2BPEL to, say, the native business process execution language used in the GRIA/Taverna system (to pick a random example)? However, the importance of sharing best practice through business process languages is clearly recognised and so further work on this aspect of the demonstrator will be pursued in this new application scenario if time allows. The application scenario as defined in this document has significantly changed from the one presented in the original migration plan for WP37. It now uses an industrial strength application service- Decifer- and incorporates relevant technologies from other projects that has gained significant maturity such as GRIA. The intention is to merge the best aspects of these systems together as part of an ongoing HPC framework being developed in the BAE ITG team of which the author is a member. Another significant shift is to focus on a web portal interface that makes dissemination easier. However, being based on a service architecture provides options for integration with other applications, eg, desktop clients. This may be undertaken if this promotes interest in the TrustCoM technologies, however, given that customers have their preferred client applications this may be a lengthy process so emphasis will be given to improving the portal instead. It is also aligned with the trend towards Web 2.0 applications that is currently underway within CE and grid communities.


Page 35

9 References 1. SIMDAT Project home page. http://www.scai.fraunhofer.de/710.0.html 2. Migration and Demonstration Plan, TrustCoM deliverable D37, Ed. D Golby 3. Enhanced CE Test Bed, TrustCoM deliverable D41. 4. Final Evaluation of the CE and AS Test Beds- TrustCoM internal deliverables

D54+D55, Ed D Golby, I Soler. 5. The Efficient Multi-Objective Design of Air-Vehicle Configurations using

ModelCenter AIAA Paper 2006-6946. 11th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, Portsmouth, Virginia, 6th-8th September 2006. S. Leary, P. Birtwell, H. Holden, and G. Johnson

6. XFOIL Home Page http://web.mit.edu/drela/Public/web/xfoil/ 7. Towards Autonomous SLA Management Using a Proxy-like Approach,

'Conference Proceedings NODe 2005, GSEM 2005', B Koller, L Schubert.

http://www.scai.fraunhofer.de/710.0.html

http://web.mit.edu/drela/Public/web/xfoil/


Page 36

10


Page 37

Appendices

10.1 Symbols Used in the Text Symbol Description

A web service component

Resources such as file storage, HPC servers etc.

A software component such as an API or software artefact that supports a service.

TrustCoM sub-systems for SLA management, VO management, Business Process Enactment, Enterprise Network/VO Infrastructure, Policy and Trust and Security.

Service

SLA BP

EN/VO Policy

VO Mgmt Security

10.2 An Optimisation Study for TrustCoM [Contributor: S Leary BAE SYSTEMS]

10.2.1 Introduction The scenario is based around the design of a minimum-drag airfoil section subject to a given lift constraint. The following diagram shows the airfoil to be optimised


Page 38

Figure 6 NACA Airfoil to be modified by this optimisation

If we use the Geometry service (described below) to generate an airfoil section with 6% camber and maximum camber at 40% chord length we generate the well known NACA 6409 section shown above. Processing this with the XFOIL CFD solver for our given operating conditions we obtain a drag coefficient CD of 0.00761 and a lift coefficient CL of 0.8520. The goal of the scenario is to try to find an airfoil with lower drag than the NACA 6409 section but that has at least as much lift - a constrained optimisation problem. In our scenario the operating conditions are a Mach number of 0.25 and an angle of attack of 2 degrees.

10.2.2 The optimisation process The optimisation framework used here requires:

• An optimisation service – for this study the BAE ATC Optimisation suite DECIFER will be used. In particular the DECIFER Genetic Algorithm (GA) will be employed in this study.

• A Geometry Generation service that takes a suggested design from DECIFER and generates an Airfoil section in a form that is readable by the CFD code (XFOIL).

• The CFD service (XFOIL). • A Post-processing Service that takes output from XFOIL and generates a file

readable by DECIFER. • HPC Service for running the CFD

The optimisation service will be hosted at the ATC and will output a set of points for CFD analysis based on a Genetic algorithm. The other services can be based


Page 39

elsewhere and take the outputted set of points, create a geometry, run the CFD code at these points and post-process the results before sending the results back. This process then iterates. A schematic of this is shown on the following diagram.

HPC

DECIFERSet of Designs to be

Analysed

An Airfoil Geometryis Generated for each Design (Possibly in

Parallel)

Each Airfoil Geometryis Analysed using CFD

(Possibly in Parallel)

Each CFD Result isPost-Processed

(Possibly in Parallel)Access to Services in Managed in a Secure and Accountable Way

Set of Results

Figure 7 Decifer Iterative process

10.2.3 Geometry Generation A Java class (Airfoil.class) reads a new design specification generated by DECIFER (input.dat) and produces a file (section.dat) containing airfoil section information in a form that is readable by XFOIL. In our scenario two design variables are used to manipulate the shape of the airfoil. These are the percent camber and the percentage of chord with maximum camber. These vary from 0.2 to 0.8 and from 0.1 to 0.5 respectively. This corresponds to 2%-8% camber and the position of the maximum camber in the range 10%-50% chord. The input.dat file contains two rows, each with a single number- design variable 1 on line 1 and design variable 2 on line 2. The service outputs the file section.dat containing 202 rows of (x,y) airfoil coordinates ordered in an XFOIL readable format. The following figures show the typical geometries that are generated during the optimisation. Note that the centre of the design space is shown in blue, examples of varying the two design variables are shown in red. All of these sections were produced using the Geometry service.


Page 40

Figure 8 Possible geometries generated during the opitmisation

10.2.4 CFD Analysis A Java class (RunXFoil.class) takes the definition of the airfoil section contained in the file section.dat as well as a supplied file xfoil.def and calculates the lift and drag on the airfoil section. In our scenario the operating conditions are a Mach number of 0.25 (note that XFoil is a subsonic CFD code) and an angle of attack of 2 degrees. The output is a file FILE1 which contains information on the airfoil’s performance, including the quantities that are of interest to us in this study (lift and drag).

10.2.5 Post-processing A Java class (PostProcess.class) takes the output from XFoil (FILE1) and generates a DECIFER readable file output.dat containing the objective and constraint values.


Page 41

10.2.6 Optimisation Results The following figures indicate how the performance of the airfoil varies as the geometry is varied.

Figure 9 Variation in airfoil drag and lift as geometries are varied

The drag decreases as we reduce the camber and move the percent chord with maximum camber towards the trailing edge of the airfoil. The drag varies between 0.0063 and 0.01445. For a number of designs the CFD code fails to converge. These are given a drag value of 0.2 in this figure and are shown in red. The lift increases as we increase the camber and move the percent chord with maximum camber towards the trailing edge. The lift varies between 0.4041 and 1.102. As for the drag data, for a number of designs the CFD code fails to converge and these are assigned a lift value of 0.3 in this figure (shown in blue).


Page 42

The following figure shows the design space for this study. The optimum design occurs on the constraint boundary (shown as the solid curve) at (0.5403,0.5) and has a drag coefficient CD of 0.0067 and a lift coefficient CL of 0.8520.

Figure 10 Design space

In the following figure the GA optimum is shown by the blue square. The NACA 6409 result is shown by the magenta square. Note that the two airfoils have the same lift (they are both located on the lift constraint boundary) but the optimised result has a lower drag.

Documents

Preliminary Implementation and Validation of the Collaborative Engineering Demonstrator · 2016-05-31 · Deliverable D56 Preliminary Implementation and Validation of the Collaborative