Deliverable Number: DB5.3 Users Guide to Athena ... · IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Piloting including Technology Testing Coordination and Pilot Infrastructure

Programme

Integrating and Strengthening the European Research Strategic Objective

Networked businesses and governments Integrated Project / Programme Title

Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application

Acronym

ATHENA Project No

507849 ATHENA – Project Name

Piloting including Technology Testing Coordination and Pilot Infrastructure ATHEN A - Project No

B5

Deliverable Number: DB5.3

Users Guide to Athena Prototyping Services

Work package – B5.3 Leading Partner: Troux Technologies AS

Security Classification: Public (PU)

March 2007

Version 1.0

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Piloting including Technology Testing Coordination and Pilot Infrastructure ATHENA - Project Number B5 Document Deliverable DB5.3 Date 06.03.07

070306_ATHENA_DB53_V10.doc CONFIDENTIAL Page ii / 51

Table of contents

1 Summary ..................................................................................................................................... 1

2 Introduction.................................................................................................................................. 2 2.1 Overview of the Pilots .............................................................................................................................. 2 2.2 The Context and Scope of this Work........................................................................................................ 3 2.3 The Structure of this Document................................................................................................................ 4

3 Core Perspectives on Interoperability ......................................................................................... 5 3.1 The Work Perspective .............................................................................................................................. 5 3.2 The Content Perspective.......................................................................................................................... 5 3.3 The Architecture Perspective ................................................................................................................... 6

3.3.1 Enterprise Service Architectures (ESAs) ......................................................................................... 8 3.4 Degree of User Interaction ....................................................................................................................... 9

4 Automotive Pilot ........................................................................................................................ 10 4.1 Pilot purpose and architecture................................................................................................................ 10 4.2 Which Athena Services .......................................................................................................................... 11

4.2.1 Virtual & Physical Testing: ............................................................................................................. 11 4.2.2 Strategic Sourcing.......................................................................................................................... 11 4.2.3 Collaborative Product Development............................................................................................... 12

4.3 How to use Services .............................................................................................................................. 12 4.4 Guidelines and Experiences................................................................................................................... 13

5 Aerospace Pilot ......................................................................................................................... 14 5.1 Pilot purpose and architecture................................................................................................................ 14 5.2 Which Athena Services .......................................................................................................................... 16 5.3 The Services .......................................................................................................................................... 16 5.4 How to Use the Services ........................................................................................................................ 19 5.5 Guidelines and Experiences................................................................................................................... 22

6 Furniture Pilot ............................................................................................................................ 24 6.1 Pilot purpose and architecture................................................................................................................ 24 6.2 Which Athena Services .......................................................................................................................... 26 6.3 How to use Services .............................................................................................................................. 28 6.4 Guidelines and Experiences................................................................................................................... 29

7 Telecom Pilot............................................................................................................................. 30 7.1 Pilot purpose and architecture................................................................................................................ 30 7.2 Which Athena Services .......................................................................................................................... 32 7.3 How to use Services .............................................................................................................................. 32 7.4 Guidelines and Experiences................................................................................................................... 33

8 IV&I Pilot.................................................................................................................................... 35 8.1 Pilot purpose and architecture................................................................................................................ 35 8.2 Which Athena Services .......................................................................................................................... 35 8.3 How to use Services .............................................................................................................................. 36 8.4 Guidelines and Experiences................................................................................................................... 37

9 Outbound Logistic Pilot ............................................................................................................. 38 9.1 Pilot purpose and architecture................................................................................................................ 38 9.2 Which Athena Services .......................................................................................................................... 38 9.3 How to use Services .............................................................................................................................. 39


070306_ATHENA_DB53_V10.doc CONFIDENTIAL Page iii / 51

9.4 Guidelines and Experiences................................................................................................................... 41

10 Future Work towards Enterprise Service Architectures and Platforms..................................... 42 10.1 A Model-Configured Service Oriented Architectures.............................................................................. 42

10.1.1 Generic Infrastructure Services ..................................................................................................... 43 10.1.2 Service Team Support ................................................................................................................... 44 10.1.3 Model-Configured Application Services ......................................................................................... 44 10.1.4 Industrial Solutions, Stakeholder and Business Services .............................................................. 44 10.1.5 Community Services ...................................................................................................................... 44

10.2 Services for Piloting, Testing, Integration and Prototyping..................................................................... 44 10.2.1 Piloting Services ............................................................................................................................ 44 10.2.2 Testing Services ............................................................................................................................ 45 10.2.3 Integration Services ....................................................................................................................... 46 10.2.4 Prototyping Services ...................................................................................................................... 46

10.3 Architecture of Model-Configured........................................................................................................... 46

11 Conclusions ............................................................................................................................. 48

12 References................................................................................................................................ 49

13 Glossary .................................................................................................................................... 50


070306_ATHENA_DB53_V10.doc CONFIDENTIAL Page 1 / 51

1 Summary

In the ATHENA project B5, industrial interoperability and collaborative business (c-Business) is implemented and validated in six use case pilots. The purpose of this deliverable is to serve as a reference manual to the solutions developed in the six use cases.

For all six pilots, the services provided to pilot solution builders for configuring application services and the use of application services to achieve interoperability are described in this deliverable. The pilots are:

The Automotive pilot at CRF aims to improve interoperability solutions in Collaborative Product Design, involving tier 1 and possibly tier 2 suppliers from the start of new car platform projects. The solution bridges across PLM systems by introducing more interoperable Collaborative Business Processes, and extending processes with interoperability services.

The Aeronautic pilot at EADS first built small test pilots for each action line A result. Then a new approach to product design was prototyped, integrated in model-configured collaboration spaces. Finally, an EADS internal platform using many Athena and PLM services were implemented. This platform will be further developed.

The Furniture pilot at Aidima is about improving the document flow, messaging and decision-making among core shareholders in an interior decoration project, integrating Order Management System (OMS), Product Data Management (PDM), and accounting systems for order handling, delivery and invoicing. The solution uses a SAP suite of tools, the Athena Semantics Suite, and STEP transformation tools.

The Telecom pilot at Intracom focuses on Product Portfolio Management and product data sharing among key actors inside a telecom company. The pilot is implemented using a model-generated workplace to give access to the information, tools and services that each stakeholder needs, currently emphasising the role of the product manager.

The Inventory Visibility and Interoperability pilot at the AIAG-led Consortium uses Semantic Mediation, Enterprise Modeling, and Web Service Execution results from ATHENA for enabling inventory replenishment data exchange among stakeholders based on the eKanban process.

The Outbound Logistics pilot captures a challenge for the deregulated automotive industry, allowing multi-brand dealers. Brand independent systems, knowledge, information, data and identification schemes will enable “senders and receivers” to identify, interpret, use, and manage the logistics and information of each other. Process transformations are implemented as software agents on the JACK tool as developed in the A7 project.

Three pilots and their supporting platforms and knowledge will be continued as commercial project offerings and will potentially become commercial products.

One of the main problems encountered in the piloting activities was to select the right interoperability tool for the right interoperability barrier, given the large number of action line A results. The business issues and profiles from B3, the requirements and issues to solutions mapping provided by A4, and the ATHENA Interoperability Framework from A4 all provide assistance to solve these problems. However, to provide the best possible solution for industrial development, piloting, prototyping, testing, and integration of interoperability solutions, an operational piloting architecture is required. Based on the experiences from the pilots, this document at the end provides guidelines and directions for how to implement a layered Enterprise Service Architecture (ESA) serving these needs. Typical services are listed, and a model-based approach for customising the ESA is outlined.



2 Introduction

The deliverable is a user guide to Athena Prototyping Services, documenting guidelines and experiences from using Athena knowledge, software components, and services. It is written based on practical approaches and methods used in building six industrial pilots, and on experiences gathered from developing the pilots. The services in this deliverable span all from web services and software components to specific tools and application services, irrespective of how they are implemented, invoked and used.

This deliverable is closely related to DB5.4, where the pilots, their test data, and usability validation of interoperability and other properties are documented. The architectures of the pilots are also documented in DB5.4. The deliverable builds on service categories discussed and described WD B5.3.2.

This Users Guide is not a guide to a polished commercial service or product, but rather to a set of research prototypes. Its purpose is to make it easier for Athena partners to adopt the Athena results as services to future community prototyping and solution development. Services to prototype, experiment, test, verify and validate the interoperability of Athena components, knowledge models, and task patterns have been applied and tested in these six pilots. When describing the services emphasis is on how the pilots should be performed in order to demonstrate the services for building, integrating and performing prototyping inside the different pilot workplaces and environments. To enable the integration action line A project results, action line B knowledge and all scenarios have been built with reuse in mind, as model-driven service platforms.

2.1 Overview of the Pilots The pilots are quite different with respect to approaches and methodology applied, and infrastructure

services configured and operated. The services therefore do not constitute a homogeneous set of services from one approach for developing and configuring and using Service-Oriented Architectures to build and operate the pilots. There are at least three distinctly different approaches to developing the pilots as will be obvious from the description of the pilots, and from the Athena components configured as pilot services.

The pilots built to prototype Athena components and services are: 1. The automotive pilot at CRF, focusing testing of car systems 2. The aerospace pilot at EADS, focusing on aircraft landing gear engineering change management, 3. The furniture pilot at Aidima, focussing on the exchange of information and data among the key

stakeholders and the decision support given, 4. The telecom pilot built at Intracom, focussing on model-configured workplaces for Product

Managers, supporting Product Portfolio Management services, 5. The IV&I pilot, focussing Inventory Visibility, built by a group of partners coordinated by AIAG

/NIST in the USA, 6. The Outbound Logistics pilot, focusing part identification scheme interpretation, built by a group

of partners coordinated by CAS AG, The table below identifies which pilots use which Athena services and results to achieve

interoperability of one or more aspects of enterprise systems.



Services Pilots A1 A2 A3 A4 A5 A6

Other – pilot

specific Automotive

Collab. Product Design

Process

MPCE platform EM tools POP*

for model exchange

CBP lang. Maestro,

Nehemiah x-organ. process

mediation

No tools used to

transform semantics

Gabriel for task

execution.

Johnson server & front-end

BRFM Peer2Peer framework

PSI and CATnet for

testing Action Plan CRO SOAP

XSRM

Aeronautic ECM in Collab.

Product Design

AKM and CPPD for

Collaboration Space

modeling

CBP lang. Maestro,


mediation

ATHOS, A’,

ARGOS, THEMIS,

and ARES

Gabriel for task

execution, infrastructure

integration

Johnson SOAP server

No tools but knowledge

results used.

NCPD infrastructure: open source

services, STEPMap

PLM services

Furniture e-Proc.

document flow

ARIS to model processes, GRAI for decisions

Maestro, Nehemiah for collab.

model simulation

ATHOS, A’,

ARGOS, and ARES

Gabriel for message

orchestration

Johnson message Sending front-end

No tools but knowledge

results used.

ERP, OMS, PDT system

and EXP transformation

Services Fun-STEP

Telecom Product Portfolio

Management

MPCE platform EM tools,

POP*, MEAF, and model-generated workplaces

No Collab. Business Process

tools used

No tools used to

transform semantics

No results used

Johnson for design

and services

execution

No tools and no

knowledge used

Test-driver from B5, to

test new workplaces

and services

IV&I – Inventory

Visibility & Interoper. Platform

Uses MPCE Platform, Metis Repository and MOOGO tool and POP* for

modeling enterprises

No CBP tools used

ATHOS, A’,

ARGOS, THEMIS,

and ARES

Gabriel for message

orchestration

Johnson for

services execution

The A6 semaphore

tool and knowledge

results used.

Pilot developed

WSS, X2R2X, NIST Gateway and Apollo for

IV

CAS Outbound Logistics Platform

Use of CAS Instance

Modeler model dealer delivery

CBP lang. Maestro,


mediation

No tools used to

transform semantics

Gabriel for message

orchestration

Johnson services

Execution PIM4SOA

Meta-model

The A6 semaphore

tool and CAS

Instance transformer

CAS Instance Modeler and Aggregator, Schema and

Process Adaptors

CRM system

Some of the services used in building and operating the pilots have been provided ready for pilot prototyping by the A project partners, while other services have been extended and adapted by the piloting teams. As can be seen from the rightmost column in the table, some piloting teams have chosen to develop services specific for their pilot or their preferred piloting platform.

The pilot solutions and the ATHENA methodologies and platforms that implement them, should be interoperable and field extendable, but the piloting teams have not had the resources or the time to pursue deployment of the pilots to more than one site.

The pilots have been developed independent from the other, so there were no or few initial common approaches to achieve interoperability, few shared methodologies, no shared development platforms, and few shared application services. What these pilots had in common were reference models, the initial Athena framework, some Athena A project results, and some partner specific platforms. Most of the reference models were methodologies, such as Enterprise Modelling Languages. The three pilots that started in month 24 have all had access to more results, but have had shorter time to absorb, categorize, model and learn how to apply the results to support interoperability in their selected pilots.

2.2 The Context and Scope of this Work Figure 1 illustrates the scope of the work of piloting and testing, on integration and prototyping, and

the most important related work within the ATHENA project.



Figure 1: The Athena operational architectures, the scope and context of the work for defining and applying services to piloting and integration, testing and prototyping of Athena

results.

The work in project A4 has sought common approaches and services to achieving interoperability in

traditional IT systems, see deliverables DA 4.2, DA4.3 and DA4.4.

2.3 The Structure of this Document The document consists of these chapters:

• Chapter 1 is the executive summary, providing an overview of the six pilots and the piloting services developed, and presenting some conclusions for future work.

• Chapter 2 is this introduction to the pilots, their purpose, context and the ATHENA solutions applied in each pilot.

• Chapter 3 introduces four different dimensions that the solutions differ according to: the work perspective, the content perspective, the architecture perspective, and the user interaction perspective.

• Chapters 4 to 9 describe the six pilots, prototyping the Athena services and results, by purpose and pilot architecture, by Athena services applied to build the pilot, how to use the pilot services, and finally by giving some guidelines and sharing some experiences.

• Chapter 10 presents guidelines for future work towards a more coherent Enterprise Services Architecture (ESA) providing piloting, integration, testing, and prototyping services to industrial users. A layered, agile, model-configured approach to establishing the ESA is proposed, and typical services to include are listed.

• Chapter 11 summarises some important conclusions from the ATHENA piloting activities. Reference list and glossary are found at the end.

Test Scenarios

As-Is Scenarios

To-Be Scenarios

Technological solutions from A projects, packaged as profiles by A4

Capabilities

Prototyping, Integration

DB5.4 Pilots

applyingDB5.1

methods

B4 Requirements& Needs

WD B5.4

Piloting Services

Demonstrators

Requirements

B1, B2, C3

Result & Exploi-tation



3 Core Perspectives on Interoperability

In section 2.1 we discussed the Athena operational perspective, presented as one view, illustrating how piloting and testing, including A project results, integration in B5 scenarios and results prototyping and exploitation in B6 and C3 constitute an interdependent set of domains.

So in order to better understand the needs for, the composition and orchestration of, and the usage and management of interoperability solutions, we here outline four important perspectives on service platforms. Together these perspectives on the same knowledge space, a use-case or piloting scenario, will make the structuring and hopefully the reading and use of this working document and its services definition more valuable. • The work to be performed to achieve the objectives and goals of the enterprise, covering all from

Collaborative Business Processes (CBP) for defining the process hierarchy and repeated flows, to work processes for defining roles and workplaces, and finally tasks to execute work in an agile context and reusable architecture,

• The content perspective, dealing with how the depth of communication can extend from data exchange, via information flow, to knowledge sharing and competence and resource pooling,

• The architecture perspective, describing how business-processes, services and data can be made interoperable by building enterprise knowledge architectures, and support different approaches to and services for piloting and integration,

• The degree-of-user-interaction perspective dealing with the required involvement of users and engineering ownership, and access rights to adapt, extend and change existing services and to define and provide new services.

3.1 The Work Perspective The work perspective is all about how we can become more effective and happy in performing the

tasks assigned to us in our roles. Work environment studies dates back to the work of Owen on workplace organization in weaving mills in the mid 1890s. It was said then as it should now that to be effective workers must have a clearly defined role, with well defined tasks, views of current information or materials and updated real data, and finally a well organized infrastructure for handling information and work coordination. We may add that it should all happen in a context of an infrastructure that provide certain automatic or behind the scene services to the worker, such as adapting tasks and content of work to competence and skills, and getting relevant help and support for the worker to be effective.

This is all about recognizing the personal knowledge space and dynamically being able to design and configure operational workspaces. Each generated user workplace should be composed of these four knowledge dimensions; • the data and information aspects used and produced, • the role to support with competence and skill profiles required, • the tasks for execution and task-pattern-ties to other roles and workplaces, • the preferred views of data and information that the user would need to see while performing his

tasks. As we can easily understand the work perspective is not very well supported in current IT systems

and by current IT systems engineering approaches and methodologies, and without it we will never be able to preserve enough context to save and restore workspaces.

3.2 The Content Perspective The content perspective is illustrated in Figure 2. Interoperability problems are traditionally

discovered at the top of the iceberg as data exchange problems. The problems are manifested as syntactical data format incompatibility and data invalidity outside the application system domain. Basic software engineering approaches to resolving interoperability also emphasize this level, which of course can and should not be ignored. For many years industry has had access to domain specific data exchange standards, such as the STEP-formats. Although some interoperability issues can be resolved by looking at the syntactical level alone, most will require us to look at the semantic layer, and also at the pragmatic logic layer of processes and working patterns involved in creating and managing information flows and knowledge sharing.

The information flow layer is foremost about harmonizing the logistics, the nomenclature (conventions for determining unique identifiers, coding schemes etc.), and the methods of communication amongst networked companies. This whole area is poorly understood by IT experts and practitioners, and



standardized semantics, thesauri, ontologies, and taxonomies alone will not suffice in order to provide interoperable solutions.

In order to facilitate deeper level knowledge sharing among collaborating partners, joint action and concerted work and experience management is needed When experiences and other competencies are being captured and utilised we can create a base for developing methods that will assist companies in performing just value and risk management, and eventually we can involve the human and social layers and methods to enable competence and resource pooling and the management of human competence and skill, and working habits and team attitudes.

Partner competence and resource pooling may occur in collaborative enterprise networks. This is a prerequisite for increased concurrency and change in ways of working and performing work management. Networked collaboration must enhance the current simple ways of work planning and resource allocation to jobs to enable “just-in-time” task assignment to available and pre-qualified people, and to enable shared views for task execution monitoring, training, and quality verification.

Figure 2: Defining the content perspective on interoperability.

3.3 The Architecture Perspective An architecture perspective on interoperability is shown in figure 3 below. At the top, we find the most

known approach, known as Enterprise Application Integration, Semantic reconciliation, or Service Oriented Architecture (SOA). This approach emphasise the wrappings and mappings of enterprise application functionality as services, and data exchange enabled through standardised data formats, typically in XML. There are many flavours to this bottom-up reconciliation approach, cf. DA 6.1.

Business Process Management architectures (BPM) address the logistics of process choreography and information flow, providing a foundation for business transactions in rather simple collaboration patterns with limited or no knowledge sharing. The reason for this non-interoperability is that the software services are simply re-architected legacy systems with severe logistic, information flow and data validity limitations Here the A2 project has proposed some major enhancements in the form of Model-driven Architectures, intelligent agent based extensions, and shared views for increased stakeholder involvement..

Finally, we have the Model-configured, User-composed Platforms and Services (MUPS) approach and architectures, which aims to support business, knowledge and technology interoperability among partners. MUPS is a foundation for middle-out collaborative product and process design. The MUPS

Data exchange

Information flow (logistics)

Knowledge sharing

Competence and resource pooling



architecture enables concurrent modelling and execution of executable enterprise models, and model-configured, user-composed platform solutions. A layer of situated knowledge constructs and structures is giving visual support to users to interact with the models, hence the term active knowledge models. The MUPS approach and the supporting MPCE1 platform has the potential to flexibly integrate any other architectural approach and platform. The MUPS approach and its supporting modelling and execution platform is developed in project A1, and further described in DA 1.5.1.

The three major enterprise architectures being worked on in Athena are depicted in simple views in figure 3. More comprehensive as well as detailed views and descriptions can be found in the documents produced in the A projects.

The most robust and high performing architecture is today no doubt the SOA. It is simply software components and metadata encoded in running software systems. The big drawback with SOA is its lack of adaptability, extensibility and of capturing and reusing knowledge. It provides no means for capturing knowledge. This is recognised by most researchers today.

The BPM architectures we have seen so far are very similar to the SOA, but there are alternative approaches emerging that take advantage of new emerging technologies such as web standards, visual models, intelligent agents, code generators and workplace generators. The MPCE platform and architecture and the MUPS approach and its knowledge architectures have their powers and advantages from the many views and relationship among lean software components and simple plug-and-play IT architectures, and knowledge constructs and architectures that can be adapted, extended and even defined by users This approach is best suited for early design and concurrent engineering, and to support repetitive and iterative work. It is not as robust and high volume performing as the SOA. In industrial solutions we will most likely need all three approaches, their platforms, services and architectures, so we must look at how best to integrate them. This would involve both horizontal integration at identified layers as well a vertical integration within domains and across layers. This work requires a cooperation across all projects driven by B4 use-cases and B5 test scenarios.

1 AKM AS has further developed the MPCE Platform to a commercial product the AKM Platform.



Figure 3: The architecture perspective on interoperability.

3.3.1 Enterprise Service Architectures (ESAs) A common term for these three distinct and yet related approaches is Enterprise Service Architecture

(ESA). Most industrial networks that will cover entire business or product life-cycles will have a need to integrate all three types of ESAs. This will require the development of an Enterprise Knowledge Architecture to support model-configured We therefore advocate to integrate SOA and BPM architectures into a common ESA using the more flexible MUPS approach, which allows multiple different meta-views to co-exist and co-evolve This kind of work must be performed in a use-case or test scenario setting, where we have access to real data and situated knowledge, that is knowledge from within a knowledge space where work is performed and multiple views are interrelated by common properties, but possibly with diverse parameter and value-sets. This approach will be outlined in more detail in chapter 10.

Business

Knowledge

Technology

Company A

Business

Knowledge

Technology

Company B

Business

Knowledge

Technology

Company C

Service oriented architecture with wrapping of applications and services (circles) and data exchange mappings (arrows) between partners,

Business

Knowledge

Technology

Company A

Business

Knowledge

Technology

Company B

Business

Knowledge

Technology

Company C

BPM architecture handling: - information flow logistics and basic business transactions and messaging, but limited or no knowledge sharing and infrastructure evolution.

Business

Knowledge

Technology

Company A

Business

Knowledge

Technology

Company B

Business

Knowledge

Technology

Company C

AKM Model-configured, User-composed Platforms and Services (MUPS) architectures, enabling collaborative networked enterprising with knowledge sharing,and competence and resource pooling.



3.4 Degree of User Interaction This perspective has to do with the need for users to be involved in defining, composing, using and

managing services. For industry and users to have trust in services and service providers they must own their project and application services, and have life-cycle control over which services were used to perform the work. How, these project and application services are composed, by whom they were model-configured and which other services were configured to compose them must also be saved. So to really get industry to rely on service providers, some categories of services must be for project and application services development, model- configuring of services and for life-cycle managing services.

The service categories needed by industrial users to manage their use of the ESA include: 1. Services to help them use services 2. Services for adapting, extending and model-configuring (orchestration) 3. Services for composing and re-composing to re-engineer for partner adaptation 4. Services for defining, developing and re-engineering (collaborative service provisioning) 5. Services for managing the evolution and use of services. All ESA approaches offer services to most user categories to adapt and extend provided services,

but peer-to-peer mapping has limited support for categories 2 and 3, and no support for 4 and 5. Some BPM service solutions may now have good coverage up to category 4, but only the AKM

approach using the CPPD methodology will configure, orchestrate and provide all the service categories, providing the support that allows industry to manage and reuse over multiple life-cycles. The CPPD components and services are the languages and modelling constructs that allow us as solution model builders to deliver customized platforms.



4 Automotive Pilot

Since the beginning of Athena, the automotive use-case has been analysed from different perspectives in order to identify the lack of interoperability affecting the multiple layers that compose it: business processes, technical methods and the data management.

Figure 4: Automotive Collaborative Product Development Processes are not integrated

The use case is focused on Collaborative Product Development (CPD) in the automotive contest (Figure 4), that is the core of the development process of a new vehicle (or a restyling of a previous design), i.e. the process that precedes and prepares for meeting the market and customer requirements and the equipping of the production plants. During the CPD many objectives have to be achieved, from the final definition of all the vehicle engineering specifications to the supplier partnership establishment. Within the use case different test cases have been identified following its logical structures in sub-processes and these parts have been studied by the different research lines in Athena (Action line A).

The requirements collected along these project phases have been elaborated by project B4 for guiding the research activities. The automotive pilot architecture is described in this chapter while the final considerations of the pilot evaluation are shown in deliverable DB5.4, titled Post test evaluation.

4.1 Pilot purpose and architecture The purpose of the Pilot is to validate Athena results in a CPD project that presents all the

characteristics that have been identified during the use case analysis. As it has been said in the previous sub-section, requirements arisen since from the initial analysis belong to different conceptual levels (from business process level to application and data level) and have different priority. The fast evolution of product concepts and specifications due to the dynamicity of today’s market, requires a continuous updating of the OEM process-driven environment, extending the collaboration to new partners or restricting it to a smaller subset. This business trend consideration has brought to the identification of a set of main challenges that OEMs (like big manufacturers) have to face in order to be competitive in the present market. Each time a new stakeholder joins the partnership or when another one retires, the general terms of the consortium have to be rearranged from an operative point of view. This means that all the activities that are performed together need to be revised and the applications that support the collaborative processes have to be redesigned, rewritten and re-compiled. All these changes cost a lot in terms of time and development work. The project planning of the product development cannot afford the delays required by these rearrangements, time to market being an objective that cannot be postponed. Thus, this is one of the most important issues that the OEMs have to solve nowadays, and our pilot shows an approach directed to overcome it using Athena research solutions.

ProductPlanning

Target Setting

AlternativeChoice

OEMSuppliers

Production Plant equippingand testing Tuning DesignArchetipes

Concepts

Virtual and physical testingSupplier Choice and Integration (Sourcing)

T1 T2 T3 T4 T5 T6

Styling Tooling Supply

Setting-Up Development Production

Part Supply

CPDProductPlanning

Target Setting

AlternativeChoice

OEMSuppliers

Production Plant equippingand testing Tuning DesignArchetipes

Concepts Production Production Plant equippingand testing Tuning DesignArchetipes

Concepts

Virtual and physical testingSupplier Choice and Integration (Sourcing)

T1 T2 T3 T4 T5 T6

Styling Tooling SupplyStyling Tooling SupplyTooling Supply

Setting-Up Development Production

Part SupplyPart Supply

CPDCPD



The Collaborative Product Development is founded mainly on four processes that have been employed separately as use cases for the research and pilot for the assessment of the Athena results. The core process in CPD is the Target Setting, an OEM-internal technical and decisional process that guides all the relationships with the other processes. In chronological order, the pilots that have been developed and executed involve the following sub-processes: • Target Setting and Virtual & Physical Testing • Target Setting, Design and Strategic Sourcing • CPD (overall)

In the following, the architectures related to these pilots are described and an overall view is composed in the final CPD pilot.

4.2 Which Athena Services

4.2.1 Virtual & Physical Testing: The first portion of the Collaborative Product Development that has been analysed and in which a

test case for piloting has been identified, is Virtual & Physical Testing (Fig.2), the process with which the OEM tests the prototypes of the car systems and supplier components.

Figure 5: Virtual and Physical Testing

Business processes as well as rough data are exchanged between the OEM and the Test Supplier applications.

The Athena services employed in this pilot are: • A1/POP* - Enterprise model exchange specifications • A1/Metis - Enterprise Model Authoring Tool and its extension for POP* format • A1/Mo2Go - Enterprise Model Authoring Tool and its extension for POP* format • A1/Grai - Enterprise Model Authoring Tool and its extension for POP* format • A1/MPCE – Modelling Platform for Collaborative Enterprises

In addition it has been necessary to integrate these solutions in the OEM environment, in particular with the legacy applications:

PSI – (Piano Sperimentale Integrato), an application for supporting product performances and test management

CATnet – (Computer Aided Testing on the network), a web-based application for test management

4.2.2 Strategic Sourcing The second portion of the Collaborative Product Development considered has been the Strategic

Sourcing, i.e. the process selecting the suppliers that will participate in the development and the production of the car (Fig. 3).

OEMSuppliers

Design

Target setting

Virtual and physical testing

OEMSuppliersOEMSuppliers

Design

Target setting

Virtual and physical testing



OEMSuppliers

OEM

Sourcing

1st TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

OEMSuppliersOEMSuppliers

OEM

Sourcing

1st TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

2nd TierSupplier

Figure 6: Strategic Sourcing

The Sourcing process under examination is not only a mere supplier choice process, but it is strongly concerned with defining product specifications and product innovation. In fact, this strategic sourcing gravitates around the exchange of a particular document (Request For Quotation) that contains a product description and that is completed and improved during the process by means of the negotiation between the OEM and the first tier suppliers and also between the first and the second tier suppliers. But if we compare the collaboration between the OEM and the first tier supplier with the collaboration between the first tier supplier and the second tier suppliers we notice significant differences in the interoperability requirements. On the OEM side we find a process-driven environment, where the number of participating first tier suppliers is low, and the first tier suppliers rarely change. On the first tier supplier side, we find a number of second tier suppliers. Second and lower tier suppliers join and leave the environment very dynamically. The business processes must continuously adapt to these events, which results in an event driven collaboration paradigm, as opposed to the process driven paradigm on the OEM side. The pilot development has been realised by the collaboration between CR-FIAT and Siemens, acting as OEM and first tier supplier, also outside the Athena consortium. The Athena services used in this first piloting are: • A1/Mo2Go - Enterprise modelling tool and its extension format for Maestro • A2/CBP construct - collaborative business process definition • A2/MAESTRO - Enterprise modelling tool for collaborative business process • A2/Nehemiah - Process engine and simulator • A4/Gabriel - Task management tool • A5/Johnson - SOAP client/server • A6/BRMF - Business Resources Management Framework, a event and document-driven p2p

platform Besides these Action line A solutions, other services and applications are used in the pilot. The

legacy applications: • PSI - (Piano Sperimentale Integrato), for product performances and test management • ActionPlan - Suppliers data Repository (used by FIAT Purchasing department)

and the necessary wrappers for the integration of all the above mentioned applications: • CRQ soap – web services developed by CRF • XSRM – eXtended Supplier Relationship Manager, the main interface of the integrated platform,

developed by CRF

4.2.3 Collaborative Product Development The CPD global pilot is the composition of all the previous pilot– portions, that has as a consequence

to combine and integrate as well the services and applications in one only platform. The XSRM interface allows the user to manage all the processes shown in figure 1.

In addition, another service is required by the current pilot configuration: • Orange - the design/testing norms repository.

4.3 How to use Services In the following picture (Fig. 4) the runtime storyboard for the CPD of a car in restyling is simplified in

order to show the use of the services. The numbers in the picture represent the chronological phases of the process.

1- The first step is the choice of the vehicle performance that has to be improved with respect to the previous model of the car. PSI is the system managing all the relationships between car performances



and related car systems, and allows selecting the systems that can be impacted by any changes in performance.

XSRM

Supplier 1st TierOEM

1

PSI

ActionPlan

RFQ

Nehemiah

Gabriel RT

Johnson

CRF_CRQSOAP

2

addRfQOrange

Ack

ShowRFQ

4

RespondRFQ

RespondRFQ

GetRFQ

GetRFQ

3

SupplierApplication

5

Internet

AddQuoteQuote 7

6

8

XSRM

Supplier 1st TierOEM

1

PSI

ActionPlan

RFQ

Nehemiah

Gabriel RT

Johnson

CRF_CRQSOAPCRF_CRQSOAP

2

addRfQaddRfQOrange

AckAck

ShowRFQShowRFQ

4

RespondRFQ

RespondRFQ

RespondRFQ

RespondRFQRespondRFQ

GetRFQ

GetRFQ

GetRFQGetRFQ

GetRFQ

3

SupplierApplication

SupplierApplication

5

Internet

AddQuoteQuote 7AddQuoteQuote

AddQuoteQuoteQuote 7

6

8

Figure 7: Runtime storyboard for the CPD

2- The second step is the identification of the set of suppliers that have to be contacted for the new supply. This task is performed by ActionPlan, a database application developed by CRF and used by the Purchasing department in FIAT.

3- Once that the car system and the related suppliers have been identified, the user (the buyer at this stage of the process) starts the sourcing process, preparing a RFQ document (Request for Quotation) and sending bidding invitations to the suppliers. Note that XSRM is the interface that allows governing all of the sourcing process, and so far no other Athena services has been yet involved. The delivery of the invitation to bid is the first action performed by the SAP suite (Maestro, Nehemiah, Gabriel and Johnson) and at this moment the collaborative process starts. The SAP suite manages the design time phase of the Sourcing Process as well as the runtime. In the runtime the workflow modelled in Maestro is executed by Nehemiah, the process engine. So, Nehemiah starts the collaboration process triggering Johnson to send the Invitation to Bid (I2B) xml document to supplier applications. The suppliers receive this document and evaluate the possibility to participate to the bid. This decision is made within the Supplier organization and can involve heterogeneous technologies that are not discussed here. Once the Supplier has decided to participate, the RFQ document is requested and the SAP Suite manage all the document exchanges described in Fig. 7, covering points 4 to 7.

4.4 Guidelines and Experiences The process described here is relative to one supplier only. The advantages brought by the adoption

of the SAP suite are that it is possible to model and execute multiple collaborative processes at the same time. From the same interface (Maestro) it is possible to switch between different processes (related to different suppliers), and execute them. The easy and fast modelling and re-arranging of the processes, their technical level developing (registering and linking the services in Johnson and Gabriel) and the easy to handle process engine, are characteristics that can improve consistently the efficiency of the processes, overcoming the most common barricades to the process interoperability.

Even if the progress of tools developed, used and tested has been satisfactory the pilot and the results are still at the early prototyping stage. It is clear that visual collaboration has a great potential in CPD. For a complete analysis of the benefits identified in the usage of these Athena results please refer to the deliverable DB5.4, Post Test Evaluation.



5 Aerospace Pilot

The aerospace pilot is about Engineering Change Management (ECM) where the change to manage is changing a part in the aircraft landing gear system. The pilot is developed by EADS in close cooperation with most of the A project partners using most of the results produced.

5.1 Pilot purpose and architecture As explained and detailed in ATHENA projects B4 and B6 (c.f. ATHENA DB4.3 and ATHENA B6 PDE2 training), current trends in the industry in general, and for Aerospace market in particular, are virtualization of the product (paper based models are being replaced by e-models), virtualization of the enterprise, and establishment of PLM (Product Lifecycle Management) strategy. The solution sought is to take advantage of digital simulation involving actors and stakeholders of the entire product lifecycle at the early stage of initial product design.

These trends are generating challenges and important needs in the area of interoperability of enterprise technical application interoperability. First it should be possible for persons belonging to different companies to work together seamlessly despite heterogeneity of hardware, software application, methods, process and objectives. Second it should be possible for different organisation (departments, functions, enterprises…) to share, exchange, retain and federate controlled product data managed in configuration, despite their distribution between different heterogeneous information and management. Finally, the capacity for Information and Communication Technology departments to support effective and flexible collaboration within Integrated Enterprise, Extended Enterprise and Virtual Enterprise should be improved, in particular to support establishment of PLM strategy. In this context, the EADS pilot is based on a scenario enabling a Collaboration Space for federated PDM within the virtual enterprise. This Collaborative Space will allow the different members of the virtual enterprise network, in our case the Aerospace integrator (OEM) and the equipment providers that have their own PDM system and PLM strategy, to work together. The established collaboration should take advantage of their respective legacy PDM systems, establishing a loose coupling between them by mean of the solutions proposed by ATHENA. In addition, all the enterprises of the establish network, including sub-contractors of level one and further, should be able to enter, participate and leave the collaboration space.

The to-be business scenario established to develop the pilot is the following: a specific organisation (the Network Collaborative Product Development Organisation or NCPDO) is in charge of creating, supporting and governing a collaboration space, with a set of collaboration models, rules, reference models, interoperability services and ICT infrastructure.

The infrastructure, based on principles developed by ATHENA to establish seamless collaboration, provides: • A service oriented execution platform based on standards and that can be interconnected through

Intranets or Extranets. The different kind of technologies infrastructures enabling interoperability for distributed systems are to be considered (and not only the WEB technologies proposed by W3C, as they are today not yet mature and robust enough for industrial needs). The federation should be established between applications at data layer, application layer and user interface layer. At application and user interface layers, the integration should be possible using :

o Interconnection of fully automated processes composing published services (WEB services, CORBA services, others)

o Interconnection of semi automated processes distributing activities between human actors and system actors (workflow systems, human/application interactions) and composing services provided by several kind of systems (organisation or automates).

• Services for semantic mediation with neutral ontology of reference. The semantic mediation should be achieved at the level of messages between systems, Product Data (documents and models), Product Metadata (for federation of heterogeneous product data structures), PDM and PLM services and finally modelling constructs for definition of services and processes. It is a prerequisite to be able to reuse existing manufacturing Application Protocols defined by ISO TC184 SC4 as ontology of reference, in particular the common part addressing Product Data Management (PDM Module or



PDM Schema) for Product Data exchange, but also for definition of inputs and outputs of the services and as neutral conceptual model for application users (who are providing the requirements, designers, developers and execution components)

• Services to support evolution and maintenance of the collaborative space taking into account organisational aspect (using Enterprise Modelling in order to define Computer Independent Model and the functional use cases of the application components), design and integration aspect (by the mean of Application modelling that will allow to define Platform Independent Model of the application components), development and unitary test aspects (by the mean of Software development technologies based on code generation from a Platform Specific Model) and finally deployment and support (by the mean of Component Based Execution Infrastructure based on principles of the CORBA Component Model in general , Enterprise Java Beans specification in particular). In order to establish such services, it is important to define a practical and controlled MDA Transformation Strategy and set of constraints for Model Driven Application Engineering transformations, i.e. CIM PIM PSM Code transformation and underlying standard components. As Model Driven Approach is generic and universal, i.e. functional domain independent, it should be coupled with usage of Domain specific Model of reference. For the NCPD pilot, the target is the usage of STEP application protocols, PLM services and Quality standards for Configuration Management (CM II).

• Computer Aided Governance of the collaborative space (Dynamic Requirement Definition System for networked organisation – as defined in B4)

It is important to point that ATHENA AL A project are not addressing all the needs and requirements

coming from such a platform. They are focussing on some gaps identified for usage of current technologies: • “Executable” Enterprise, knowledge and Application modelling (A1- Enterprise Modelling in the

Context of Collaborative Enterprises) • Executable Process interconnection between different organisations and enactment systems(A2-

Cross-Organisational Business Processes) • “Service Oriented Execution platform” (A5- Planned and Customisable Service-Oriented

Architectures) • “Model-driven and Adaptive Interoperability Architectures” (A6) • ”Semantic mediation between tools, organisation, actors and stakeholders” (A3-Knowledge Support

and Semantic Mediation) The final Pilot definition was driven by EADS business scenario related to “Change Management

process within virtual enterprise», that shows how two or several enterprises (EADS and Landing Gear Provider) collaborate when a change issue occurs in EADS and has some impact on Landing Gear Provider. Both enterprise have already their own Product Data Management System and well defined internal change management process.



5.2 Which Athena Services The final Aerospace pilot was aiming to propose a prototype of what such a collaboration space,

implementing on the vision and approach defined by ATHENA, could be.It is based on ATHENA results inception and evaluation through several other pilots, more limited in scope, and aiming to evaluate individually Action Line A projects outputs (A3 and A2, using some components from the other projects) aligned with existing standardized ontology or services for PLM: • The A2/A5 SAP tools suite (Maestro, Nehemiah, Gabriel and Johnson) for Cross-organizational

business process modelling and execution • The STEPMapper for the EXPRESS to UML transformation • The PLM Services from Mantis • The A3 tools suite (ATHOS, A*, ARGOS, THEMIS, ARES) for the semantic reconciliation

It was done for some of the components coming from A3, A2, A5, A1 and A6 through establishment of demonstrators of each project.

In parallel, other alternative or complementary solutions not provided by ATHENA were studied and evaluated in parallel when useable and compatible with the ATHENA vision and appropriate for the NCPD infrastructure.

Some important criteria were established for selection of the components: • reusability after ATHENA project without paying fees or licence • support of open standards enabling interoperability and interchangeability of solutions (target: to be

solutions independent and driven by a framework based on standardised interfaces) • Robustness and usability within an industrial context

Then an “Integrative Pilot” was launched aiming to integrate most of the components. A first phase of the pilot was the “definition of the collaborative space infrastructure”, that aimed in the context of the defined to-be business scenario, to evaluate if the components of ATHENA should be useable in order to prototype such a platform. Feed back and analysis of the results are being provided to B4 project (for next set of specific requirements), AL A projects (for next set of generic requirements), A4 (for completion and recommendation concerning AIF), the program (Identification of gaps in order to complete next version of interoperability roadmap) and the community (PDE2 training, dissemination, exploitation).

After the evaluation, it appears that most of the ATHENA provided components were more at the level of demonstrators (proof of concepts) than really useable components (prototypes). Most of the time they do not handle some complex cases like specific structures commonly used in a piloting environment; they are all using a very heterogeneous underlying executioner platform (Jetty, Tomcat, PHP, J2EE…) and were even sometimes not deployable. All of this implied a lot of integration that was not so seamless. Thus, as there were gaps in the functional requirements we added some external tools to our platform It was then decided to build from scratch a collaborative platform and to illustrate from this platform were future industrial components based on AL A results will be very important in order to really enabling usage of such a platform.

The services proposed by this platform are nevertheless to be considered as ATHENA services, as they were produced in the context of B4, B5, A4 and Cross Action lines activities.

Finally the platform is an ongoing effort that will be continued after elaboration of this document, and made available on the ATHENA Aerospace Piloting WEB site. It means that documentation on the services will be regularly updated on the WEB site itself, and be available during final review of the ATHENA program.

5.3 The Services • Portal related services

The NCPD is based on an Open Source Portal implementing Portlet standards (JSR168 and WSRP). It means that it provides: • User interface integration services (syndication of portlets) • Working space parameterisation services

o For personal workspace o For organisation workspace o Enterprise o Community



• Portal administration services o Portal o Enterprise o Community o Persons o Profiles o Porlets o Should be coupled with LDAP

• Application server related services The NCPD is based on an Open Source Application Server implementing EJB specification and

consequently the CORBA Component Model. It means that it is based on business containers that are: • Allowing to deploy business objects as entities, services and messages beans • Allowing applying enterprise common services to these business objects through the policies applied

to the containers where the business components are deployed. The common services are those proposed by the J2EE platform, for which exist open specification through the SUN community and that are aligned with the CORBA Common Services of OMG. J2EE platform consequently appears that a standard based execution platform for which several implementation can be provided for defined components. For example, several EJB based application server implementation exist like JBOSS, JONAS, GERONIMO, Websphere, and Glassfish. If willing to change execution platform, adopted MDA approach should allow targeting other platform as .net, php or OpenCCM. The choice of J2EE was made at it appears as the one providing the best architecture for enterprise applications, because it is OS independent (can run on Microsoft windows, Unix, Mac, Mainframes…), because they are free and finally because interfaces specifications are open and maintained by the Java Community, with in addition some certification test suites (that are free for Open Source software like JBOSS or JONAS).

The important services that are consequently available for the NCPD platform are:

• Persistence services • Serialisation services (in particular XML serialisation) • Access and security service • Automated publication of EJB services during deployment as CORBA (that can be accessed through

RMI on IIOP) or WEB-services services (that can be accessed through WSDL endpoints) • Transactional services • Load Balancing services

o Fully automated execution related services • The NCPD integrates a BPEL engine (active BPEL Engine) that allows to benefits: • BPEL enactment service • BPEL administration service • BPEL process monitoring service • BPEL service publication • Associated with a BPEL modeller, it provides “WEB services composition” service

o Semi automated process related services It encompasses services related to Workflow systems, based on Wfmc standards

• Workflow enactment service • Workflow monitoring service • Workflow administration service • Should be coupled with LDAP • Associated with a Workflow modeller and WAPI agents, it provides a “Services

composition” service, services being WEB services, CORBA services or others o Distributed application connection services

It encompasses several open and standardized middleware technologies that are integrated within the NCDP components

• CORBA bus services based on RMI over IIOP, integrated in Java as core component of Application server – integrated ORB of Java can be replaced by any other

• Naming service (JNDI or other COS Naming implementation), trading services (COS training and UDDI) and interface repositories services.

• ESB bus services: based on AXIS and eventually complementary components as



those implementing Java Business Integration • Static and Dynamic interface to code and code to interface generation services (part of

Java JDK and Axis) – take advantage of Java introspection services o PLM services

It is based on usage of PLM Services server of reference coming from the XPDI project (Automotive – related to VBA, GALIA and ODET networks) and standardized at OMG Mantis. Alternative is based on PLCS PLM services specification at OASIS and coming from the PLCS project. No implementation is available now. Based on Models Generated Workplace, replacement by the server of reference by a server generated from standards using approach defined by ATHENA is on-going. PLM services current version is 1.0, a second version is being specified.

• PLM data repository service • PLM querying services • PLM navigation services • PLM check out services • PLM check in and modification service (specified but not implemented) • Change and Configuration management services (being specified in PLM Services

v2.0) • Service for login are specified but redundant with those provided by other components

(it is to be managed by the portal services) o Product Data Transformation services

These services should be plugged on the platform but will depend on which kind of data is considered: • Data at data layer within

o Relational database systems o XML document repositories o Information server as defined by the Standard Data Access Interface in Part 22 of ISO STEP

• Data at Business layer being access by services or publish objects. This layer encapsulates and hides the data tiers. It is the one considered for PDM systems standardized interfaces as those defined by PDM Enablers (OMG, Mantis) or PLM services (MANTIS and OASIS)

• Data at Presentation layer, that are made available for users (user interface, printers, etc) Depending on the application and its architecture, it is possible to require:

• Preservation of concepts designation; it implies transformation between the different modelling and structuring constructs used by the software components of the application only (e.g. concepts of an application protocols are used to generate data base structure, EJB entities, forms fields and labels, etc… using the same name defined by the Application Protocol)

• Wrapping of the business concepts; it implies translation between different business models (e.g. AIRBUS internally defined engineering concepts, visible at the presentation layer, mapped with internal model of the used Commercial of the shelves, mapped with an application protocol in order to allow Product data exchange with other Application within other organizations)

Finally, all these transformation are required at runtime, during execution time. It should also be important to consider transformation allowing to exchange or shared information between application at runtime and modelling platforms (Enterprise, Applications, Processes, Workflows, Knowledge, Urbanism). Here again, the transformation can be done at the modelling, developing or execution languages constructs level, or at the business level (business models used are not equivalent but some correspondences are established allowing sharing of information during a collaboration.

For technological frameworks developed for the semantic WEB, the boundaries between classes and instances, or entities and data, no more exist. A resource can be at the same time an individual, a class or a property. If of particular interest for usage of intelligent agents or knowledge management systems, they are usually less adapted for application that have to manage huge set of information and requiring performance with Quality of Service. The architecture and components selected for the NCPD are more related to the second category, but ability to establish links between data repositories and distributed WEB resources is of particular interest. The choice made for the NCPD is to provide some services allowing producing resources aligned with data schemas or object models in order to allow their usage for semantic WEB agent technologies: • RDB2RDF service (Relational Database to Resource Description Framework) • XML2RDF service for messages – proposed in order to solve integration of A3 tools with other

AHENA components



Some others services allowing taking advantage of Semantic and Knowledge based tools are: UML2OWL and OWL2UML in order to validate a UML model as valid (logical viewpoint for support of

reasoning) or to take advantage of code generation based on inference mechanism based on declarative languages (that can be faster and less error prone than typical UML based tools that are not based on reasoning and declarative languages).

A component was developed by EADS CCR in order to reuse application protocols as CIM, PIM or PSM components, but also to put application protocols and models that are derived from it within an OWL repository to take advantage of reasoning and federation capabilities of OWL and associated tools.

Some others were developed by AIDIMA in order to transform EXPRESS in UML according Part 25 of STEP and to XML (XML Schema) according part 28 of STEP.

All these transformation services aimed to be integrated within the NCPD platform but due to maturity of the components or of the precise specification of wished mapping and transformation, only some of them are currently available. They are currently under integration: • AIDIMA Express to UML and Express to XML • STEP to OWL Mapper • STEP to PIM AndroMDA profiles Mapper

PSM AndroMDA profiles to code for the NCPD platform – currently for entities (Forms for CRUD, WEB tier components and EJB Entities for CMP)

PIM/PSM AndroMDA profiles for User/Application interaction modelling to code for the NCPD platform (Forms, WEB tier components, links with services by means of a controller)

The AndroMDA profiles were defined for Service Oriented and WEB based platforms (EJB application server and now .net). As the application is open source ands of sufficient quality compare demonstrators coming from ATHENA, the choice was to use this platform for the NCPD and then to enrich it in order to integrate missing PIM4SOA components and transformation for future robust execution components implementing CBP concepts. It is also targeted to enrich the profiles in order to be able to perform transformation from CIM/PIM models to Portal platform in the both directions.

POP* to PIM4SOA services will not be provided on the NCPD platform, but will be documented in order to highlight the innovation proposed by ATHENA and illustrate what can be targeted for a near future to correct drawbacks of the current NCPD. • Test and conformance services

For a platform like the NCPD platforms, numerous kind of conformance tests are to be performed: • CIM, PIM and PSM validation (integrated in the transformation tools of AndroMDA and to extend

latter on) • XML models, documents and messages validation (syntax and schema) • RDF resources validation • OWL ontology validation (reasoning supported?) • Web services validity (using WS-I test suites) • STEP based models validity (syntax and Express schema including constraints) – note – the quality

checker developed by UNINOVA in the furniture portal is similar, but based on usage of XML technological framework. Constraints defined in Express are translated using SCHEMATRON that is applied to models transformed in XML (Part 28 based transformation tool is used).

• Transformation quality checker: this was not addressed within ATHENA but this item is of particular importance.

• Process validation o Static validation (similar to other models) o Dynamic validation by means of simulation

Available with Jawe for Workflow based on Wfmc standards Available with Intalio BPEL modeler Maestro and Nehemiah for CBP (note: will illustrated on the NCPD portal but not integrated nor

deployed, as not of sufficient quality to be made available at the outside – more demonstrator than prototype as most of the AL A tools)

5.4 How to Use the Services This part is a draft: as NCPD portal is an un-going development. The progress of this part can be followed on the http://nfig.hd.free.fr/ATHENA web site.



Current documentation: “The approach used for the EADS pilot is a service oriented one. A collaboration service has been

setup by the mean of a NCPD (Network Collaborative Product Development) collaboration portal. This portal is based on open source components with a robust implementation and is web oriented. It illustrates what is currently possible with standards and shows the upcoming innovations. The chosen implementation is Liferay which offers users management within communities for easy administration and the usage portlets (JSR 138) to integrate external components. On this web portal we deployed many services we provide to the user and which are described below. The user can also integrate himself external services of his choice by the mean of portlets.



Figure 8: Screenshots of the implementation of the NCPD Collaboration Space

We enabled prototyping services: an application server has been deployed and a design development suite has been chosen (Eclipse as a development tool supports many languages for implementation). Some application modeling services (PIM and PSM profiles), code generation (AndroMDA) and deployment services with their documentation and recommendations are also available to use the MDA approach. A tool for a user friendly and easy invocation of web services (Johnson) is also running.

Some transformation services developed within ATHENA are also available (to be completed with

description concerning their usage on the NCPD Portal): • STEP to OWL (StepMapper) • STEP to UML PIM (StepMapper) • STEP to UML Part 28 (EXP2XSD) • STEP to UML Part 25 (EXP2XMI) • XML to RDF (Axtor) • RDF to XML (Artox) • Semantic mediation

o A3 tools suite with the STEP AP as business ontology ** o XSLT o EXPRESS-X o QVT

• POP* -> PIM4SOA * • PIM4SOA -> execution platform *

Some of these tools have not been evaluated (*) and some are not deployed (**). Some enactment services have also been deployed:

• A BPEL engine where BPEL model for web services orchestration can be deployed • An XPDL engine for XPDL workflow (WFMC standard) models • A Cross-organizational Business Process (CBP) execution engine (Nehemiah from ATHENA Action

Line 2) where the models designed with Maestro can be deployed. In the aeronautic pilot, the A2 tools have been used to model the change management process

between EADS and Landing Gear Provider. These tools allow the partners to model their private process



and then to create a public view of these processes by hiding some part of them. The CBP is created by linking together the two public views. Then the models are deployed to Nehemiah where they can be executed in a distributed environment (the two partners should be running one instance of Nehemiah). Nehemiah provides a graphical representation of the state of the process execution. These processes can also call the PLM web services through Gabriel and Johnson.

Figure 9: structure of the current NCPD collaboration platform

5.5 Guidelines and Experiences The ATHENA program helped EADS CCR to set up a prototype of a Network Collaborative Product

Development platform enabling collaboration between members of the virtual enterprise network, being persons, organisation (enterprises, communities or application systems). This platform was based on the innovative vision promoted by IDEAS project and supported by the ATHENA program: • Interoperability is to be addressed at organisation, knowledge and ICT levels together • It should be improved using a model transformation based approach targeting open and flexible

Service Oriented Execution Platform based on standards • Interchange between the different actors and systems should be performed on the basis of semantic

mediation. • All the process and produced artifacts, encompassing: • As is and To-be scenario definition • Requirements engineering within the DRDS • Iterative test and piloting activities • Final piloting platform

… are made available on the ATHENA B5 Aerospace piloting WEB site. This site also provide access to a real collaboration platform the people can use (for experimentation)

with several deployed services. The experimentation of the innovative components coming from ATHENA together with development

of the NCPD platform based on existing and available commodities of the WEB was the opportunity to compare current state of the art and to highlight promises coming from innovative solutions coming from the AL A projects but also future actions to envisage having a real impact: • The CBP in particular is a very innovative and useful concept, as it responds to some constraints for

transversal automated process (between engines and organisations), hiding private process but

BPEL Engine

Workflow Enactment

CBP Engine

Semantic Mediation

Service HUB

Liferay

JBoss

Struts+Tomcat+Apache

MySQL

ActiveBPEL

Shark

ATHENA A2

ATHENA A3

ATHENA A5



providing a better visibility on collaboration than current tools and solutions. But it is only done for fully executable processes and with a bottom-up approach. For a real impact, some actions should be undertaken to push the CBP concepts within BPEL, BPMN and Wfmc standards. Extension to support top-down approach and consolidate collaboration view taking into account workflow participants, applications and relevant data should be undertaken. Finally, link with Enterprise Modelling and Presentation layer of application should be addressed. Today, the solution is more a solution for software engineers than for end users.

• Knowledge base generated platforms are also of particular interest. But a difficulty is to adapt the approach with today’s existing legacy execution platforms that are not flexible enough. In addition, about no commodities of industrial quality are available on the WEB. Finally, as maturity of industrial users is not good enough today, some times will be required before to be able to have some standards emerging that will solve interoperability issues at the execution layer.

• Semantic mediation is the future, as the semantic WEB is becoming a reality. But the current technological framework is not really compatible with usual XML technology framework, as illustrated by problems to be able to transform XML messages in RDF message when willing to use A3 tools for semantic mediation. In addition, the approach was too complex for simple messages or documents. But such approach will be very valuable for Product Data Models interchange and sharing on the WEB, particularly willing to use intelligent agents to support collaborative, concurrent and multidiscipline engineering. Based on A3 results, EADS CCR is now developing the concept of Semantic PLM on the WEB, in order to defined new way of working that will use all the potential of the semantic web infrastructure

All these points will be made available and developed through the other ATHENA deliverables (End User Watchdog group report, PDE2 training, Piloting WEB sites).

They will be disseminated, illustrated or demonstrated during the final review of the ATHENA program.



6 Furniture Pilot

The furniture pilot is about e-Procurement (e-Proc) where support for the RFQ to order-delivery process and for stakeholder messaging is in focus. The pilot is developed by Aidima in close cooperation with selected A project partners, exchanging documents with product data and applying mainly STEP transformation and semantic reconciliation tools.

6.1 Pilot purpose and architecture The furniture sector is a very complex industry regarding data sharing, process methodologies and

business processes between organisations across the supply chain. The EU furniture industry accounts for about half the world furniture production and is one of the

largest manufacturing industries in the EU. The furniture industry in the EU accounts for 8,800 enterprises with over 20 employees, employing 600,000 people, and more than 80,000 enterprises with under 20 employees (employing almost 300,000 persons). The SMEs which are mostly owned by families, as a labour-intensive industry, provide employment for around one million people. Those companies are using a wide range of information systems, many of them developed by small software houses, usually in a very strong competition in the market. Design, production and services available are the major aspects that SMEs have to deal in order to achieve the success.

The current usage of the e-Business within the furniture industry is reduced to the use of some exchanging e-mails with documents attached.

The objective of the furniture e-Procurement pilot is to facilitate the interoperability among e-Business services and the implementation of the integration mechanisms by analysing the current level of e-Business implementation in the furniture sector.

The full benefits from e-Commerce will only be gained when the business and technical levels are fully aligned and are interoperable between both.

The furniture procurement scenario, see figure below, involves four stakeholders: furniture manufacturer, raw-material supplier, retailer and customer. Although the document flow is started by the retailer, the action starts when a costumer looks for furniture at the Retailer’s facilities or website. The costumer browses the catalogue and asks the salesman to obtain a quotation for the desired furniture products.

The Retailer starts the procurement document flow process by sending to the Manufacturer the R1. Request for Quotation document to obtain the current product price list according to the costumer desires. The information included in the R1 document is mainly composed by a product list with the corresponding specifications such as finishing, handles, fabrics and special measurements or cuts. Additionally, the Retailer might send the R1 document with an interior Decoration Project2 attached. The deco project is only a representation of what the user wants and where to place the furniture in relation with the room.

Once the R1 document is at Manufacturer’s side, specifically at the Sales Dept, the internal process regarding to the quotation process is the following: • The R1 document is formatted as an internal document identifying it with an internal number; • Then, the formatted R1 flows from Sales to the Product Design Dept which studies the design and

the manufacturing restrictions for the asked products, and the production costs by creating the R2. Quotation document

• After designing and pricing the products, the R2 document flows from Product Design to the Sales Dept who sends it to the Retailer ready to be accepted by the customer. The document includes the prices of the specified products

2 In a Deco Project, the pieces of furniture are placed in a room and taking into account the special configuration of the room (dimensions, shape, walls, painting …).



MANUFACTURER R5 & R6

R7

RETAILER

Customer communication

R3

R1 R2

R4

Interior Decoration Project

Looks for furniture

Invoice

Delivery

Delivery

Figure 10: Furniture retailer-side scenario

To accept the quotation sent by the Manufacturer, the Retailer has to perform the R3. Order Document including a reference to the quotation. The Retailer might include also the decoration project as an attached draft of the ordered products. Once the R3 document arrives to the Sales Dept, the Manufacturer processes the document in the following way: • Sales Dept formats the R3 document to an internal format checking for any possible errors

(configuration errors, missing information, non-legible characters, …) that might exist • This process is also valid for inserting the order in the ERP’s database by giving it an order number • Once the order is introduced into the database, the R4. Order Confirmation document is

automatically generated with the order number, delivery date and payment conditions. This document is sent to the Retailer

At this moment, Sales sends to the Production Dept the list of ordered products. This department

plans the product manufacturing by calculating the amount of raw material that is necessary to produce the goods. If there is any lack of raw material, Procurement Dept is asked for it: • Procurement Dept searches for the best suitable provider which could procure the requested

material by the Production Dept in the shortest time • If the requested material has any special remark like special cuts, measurements or shapes, the raw

material procurement process starts with the processing of the M1. Request for Quotation and the M2. Quotation documents

• In any case, the Procurement Dept sends a M3. Order document with the requested raw material, and the Provider sends the M4. Order Confirmation which, as the R4 document, would include the delivery date, order number and payment conditions

• The Provider sends to the Manufacturer the requested raw material accompanied with the M5. Delivery Note document, which is a list of the delivered products that must be duly signed by the Manufacturer and returned back to the Provider

• Finally, the Provider sends also the M6. Invoice document By the way, the Production Dept goes on the product manufacturing and waits for the raw material to

be provided for finishing the product. Eventually, during the manufacturing process, the Retailer might start a Customer Communication

process to know the current status of the order. Once the product is manufactured, the different parts of the furniture are packaged. The packages

are identified and sent to storage waiting for the shipping and being prepared to be loaded into the transportation.



While this process is being performed, the Administration Dept prepares the last documents to be sent to the Retailer: R5. Delivery Note and R7. Invoice documents. Additionally, the Production Dept prepares the R6. Packing List which is the product list contained in the R5 broken down in the different identified packages.

The products are loaded into the transportation and sent to the Retailer accompanied with the R5 and R6 documents. The Retailer signs the R5 and returns it to the Manufacturer who finally sends the invoice (R7).

The stakeholders involved in the pilot of e-Procurement interact between them in the usual message exchange performed during the Request for Quotations (RfQ) and Order processes. In the current situation (AS IS scenario3) the systems used by the different stakeholders can be classified in the following concepts: • Order Management System (OMS): system used for the generation of RfQs and orders. This system

is the trigger of the whole process, no matter if the RfQ and/or the Order include a special product or a serial product.

• Product Data Tool (PDT): this tool is used for the generation of the product data and price lists. Usually it is a simple database with a simple Graphical User Interface (GUI) against which all the queries related to the price lists are launched.

• Usual accounting systems which are in charge of the generation of the payment related data. An important issue related to the current situation is that the validation of the documents is done

manually. This validation implies checking the validity of products –wrong references–, prevent references misunderstanding related to wrong product descriptions or missing information.

Related to the desirable situation (TO BE scenario4) the systems used by the different stakeholders can be classified under the following concepts: • The OMS are desired to be used with the same approach but with a slight difference. The OMS is

asked to perform the documents based on a standardised XML Schema file. This schema file has been developed under the funStep projects.

• The PDT is desired to have a more sophisticated approach. It would be not only to attack a database but also should be able to communicate with the other internal systems.

• The usual accounting systems with the same approach.

Having in mind that migrating from a manual management and fax & phone communication to an automated documents generation and WS-communication is a more than a media break, solving this problem will, surely, imply a change in the furniture industry way-of-doing-business. Also, it would imply a huge amount of investment in infrastructure to adapt the current IT systems to the new Internet-based communications.

For this all, the ATHENA tools which are going to be used are classified in the following categories:

• Collaborative Business Process (CBP) Tools used for modelling the collaborative environment for helping in the development and improvement of the Business Processes of each actor;

• Semantic Suite used for managing the funStep furniture Ontology, for annotating different instances of the same document to allow the reconciliation and the matching between different documents against the same concepts;

• Lastly, the STEP Suite will be used to validate the documents both syntactically and basic-semantically against the XML Schema documents.

6.2 Which Athena Services The different ATHENA Tools and Services used to the implementation of the pilot infrastructure are

the following: • Collaborative Business Process (CBP) Tools:

o Maestro: SAP developed tool to model a collaborative environment based on the work done by Enterprise Modelling tools which will help in the development and improvement of the Business Processes of each actor.

3 The communication is done mainly with fax and phone. 4 The communication is desired to be done through Web Services and the messages deployed with the XML technology.



o Nehemiah: SAP developed tool to simulate the CBP model developed under Maestro. o Gabriel: SAP developed tool to orchestrate the Process and the Messages. o Johnson: SAP developed system which will act as a kind of Outlook. This tool is going to act

as a front-end of the different actors and will have uploaded the Web Services to receive and send documents.

• Semantic Suite:

o ATHOS: Athena Ontology Management System. LEKS developed tool to create and manage ontologies. Under the scenario it has been uploaded the furniture ontology developed under the funStep projects.

o A*: Semantic Annotation Tool used to annotate different instances of the same document to allow the reconciliation and the matching between different documents against the same concepts.

o ARGOS: Rules Generation Tool used to generate the run-time tools for checking and annotating documents.

o ARES: Run time environment. This tool will be uploaded into Johnson as a plug-in, so this will allow the reconciliation and annotation on run-time the documents. Additionally ARES will help in validating the semantic of the documents against the ontology.

• STEP Suite: o Conformance Test: This tool, developed by UNINOVA, will perform the validation of the

documents both syntactically and basic-semantically against the XML Schema documents. The CT tool, as ARES, will be uploaded into Johnson to allow all the users to check the validity of documents.

o EXP2XSD, EXP2SCH, EXP2PIM4SOA2WSDL: These transformation tools, also developed by UNINOVA, will be used for transforming the EXPRESS schemas into a more machine-understandable languages, such as XML, and Web Services Definition.

Figure 11: ATHENA tools usage in the Furniture pilot



6.3 How to use Services The integration among manufacturers and retailers, during run-time, is achieved by means of

installing a kind of front-end which would work as a sending-and-receiving the commercial documents (RfQ, Quotations, Orders …). For this reason, among all the set of solutions provided by the ATHENA project, the tools that have been selected to reach the objectives of the pilot are the following: • Johnson + Ares (Semantic Gateway): This combination works as a semantic checker against the

funStep furniture ontology. • Johnson + Conformance Test (Front-end): On the other hand, this combination works as a syntactic

and basic-semantic checker against the XML schemas of the commercial documents. Additionally, it has also the capability of sending and receiving documents.

Figure 12: Furniture run-time instantiation

The documents are deployed through the ERP of the company, either the manufacturer or the

retailer, and are e-mailed as an attachment. The front-end is in charge of performing the syntactic and a basic-semantic validation, e.g. it checks that the order lines are not priceless or with no quantity, of the document to be sent. The document is then sent through the “outbox” of Johnson to the other party’s “inbox”.

During the transportation, the e-mail is checked by the Semantic Gateway looking for potential semantic errors and inconsistencies against the funStep furniture ontology. Once checked and validated, the document is delivered to the receiver ready for final internal checking, in terms of manufacturing possibilities, and finally manufacture the furniture piece.



Figure 13: Furniture run-time description

6.4 Guidelines and Experiences The tools and services developed in the Action Line A projects have been very helpful to set up the

pilot. They could handle many of the interoperability issues that had to be solved for this pilot. However, not all required tools and services could be provided by ATHENA. To complete the pilot, AIDIMA has selected the Grai tool from ITREC to deal with the Interoperability Issue related to the Supplier rating. In general, the functionality provided by the tools and services often was not comprehensive enough and many versions of the final pilot architecture have been studied during the pilot life. Although the Pilot activities in ATHENA were conceived to be deployed in a prototypical way, the reality has shown this approach was not affordable in ATHENA due to time restrictions. Anyway, for future work, the prototypical tools and services could be enhanced step by step to provide a full set of functionality for practical applications.



7 Telecom Pilot

The telecom pilot is about Product Portfolio Management (PPM) where support for selecting the right product to produce and deliver is in focus. The pilot is developed by Intracom in close cooperation with most of the A project partners using most of the results produced.

7.1 Pilot purpose and architecture

The Telecom pilot is intended to test the applicability and usefulness of Athena interoperability solutions in a typical industrial scenario of a medium-to-large-size company developing and maintaining a variety of high technology product lines, in a sector characterized by highly competitive and rapidly changing market conditions, the Telecommunications product manufacturing sector. The use case scenario is based on the process of Product Portfolio Management, hereafter PPM. Starting from enterprise modeling constructs, Web-based workplaces are created that offer navigation and work views to the end user, supporting all his operational tasks as depicted in the enterprise model. Interaction with enterprise information repositories is facilitated via an underlying service-oriented architecture.

PPM is a process involving decisions made at different levels, where the company’s active products list is constantly updated and revised. Therefore, new products are evaluated, selected and prioritized; existing ones may be accelerated, killed or reprioritized; and resources are allocated and reallocated to the active development projects. The objective is to allocate resources in a way to maximize sales and profits and minimize risks, as well as to achieve balance of development projects taking under consideration risks, technology and market trends.

PPM is of significant importance especially to a large enterprise with many business units and complex products, the development of which requires the collaboration of many different engineering teams inside the same business unit or corporate environment, as well as within a business network of collaborative enterprise. In this study, the focus is on intra-enterprise level.

PPM involves many business processes (new product development, product management, supply chain management), and many actors at various positions that perform different tasks from strategic level (e.g. Business Unit Manager, Sector Manager), and tactical level (Product Manager, Project Manager) to operational level (Team Leader, Engineer).

The focus of the Pilot is on Product Management and on supporting the role of the Product Manager. At INTRACOM Telecom the objective of Product Management is to identify the need for a product/product-line, justify the inclusion of a product/product-line in the company solutions and control the execution of the development roadmap. In doing so, it needs to stand between the product development and manufacturing departments as well as the sales, technical support and public relations ones. The Product Manager is assigned to a product or product family and is responsible for developing or overseeing all aspects of the product including product definition, product development, product launch, current product management, and product phase-out.



Business DevelopmentManager

Product Development Manager

Product Manager

Team Manager

ERP System

Project Planning

Project Finance

Warehouse Management

Sales Data

Contract Management

Production Planning

ADARES

SIS

iKnow

Product Issues Management

Document Management

Marketing Intelligence

Product Issues Management

HR Management

Quality Engineer

Figure 14: Telecom Pilot - A high-level overview of the as-is situation

It is apparent from the figure above that PPM and particularly the role of Product Manager entails

access to information of varying nature, stored in various systems and diverse platforms and implementations. The evolution of such systems in any typical medium-size enterprise has been typically outside a planned framework of interoperable systems, a situation that is changing lately with the introduction of service oriented platforms and architectures. It is therefore currently difficult for the PM to access those disparate systems and retrieve the information needed in a comprehensive and user-friendly presentation mode. The architecture instantiated for the Pilot is shown in figure 15.

In the architecture most of the enterprise modelling takes place in the ‘Business” level/layer. The “Process” layer represents Model Generated Workplaces that result from the enterprise modelling and are presented to the user as interfaces for their tasks. The “Services” layer encompasses all services that are used or created in order to support the workplaces. Web services are used to retrieve information from the (enterprise) ‘Data” layer.



Run time• Picture representing the runtime storyboard of the

scenario under execution• RKR: this may be a run time demo architecture (green

background =design time and yellow background =run time)

• or do they mean that we must describe the product management processes we are going to use in our demonstration?

Data

Services

Business

Data

Services

Processes

Business

Enterprise Modelling

Web Services,AKM Service and MUPS Services

Web Services and repositories

MO²GO

Processes

Web-based Workplaces

MPCE

Troux Internet Portal (TIP)

Process Assistant (PA)

Metis Enterprise Server

iKNOW

iKNOW Document Management

NetWeaver

METIS

Data

Services

Business

Data

Services

Processes

Business

Enterprise Modelling

Web Services,AKM Service and MUPS Services

Web Services and repositories

MO²GO

Processes

Web-based Workplaces

MPCE

Troux Internet Portal (TIP)

Process Assistant (PA)

Metis Enterprise Server

iKNOW

iKNOW Document Management

NetWeaver

METIS

Figure 15: Telecom Pilot - A high-level overview of the Architecture

7.2 Which Athena Services The following ATHENA results and tools have been used to support the Telecom Pilot:

• POP* (Project A1) – for Modelling the different aspects of the enterprise and Generating the workplace through the models

• Import/export of POP* (Project A1) – for Modelling different aspects of the enterprise • MPCE (project A1) for Modelling different aspects of the enterprise • Transform ITM & BPM models to MEAF models (Project A1) for Modelling different aspects of the

enterprise • MEAF ATHENA extensions (Project A1) to facilitate Web services, task management, user interface

modelling • MGWP (PA + TIP) (Project A1) during the Generation of the workplaces through the models

o MO2GO for Process Assistant (PA) generation o Metis for Troux Information Portal (TIP)

• MGWP TIP Services for Web Services (Project A1 + B5) for Discovery of web services and linking them to the models

• Johnson (+ Lyndon) - (Project A5) for Design, Testing and Deployment of Services • Test Driver (Project B5) for Testing Services Conformance and Integrity

7.3 How to use Services The services and tools used in the Athena Telecom Pilot are organized as shown before in the

Architecture figure and are generally presented along the six steps that are shown in the next figure.



• Model reference model in MO2GO

• Generate a Process Assistant

• Use MPCE to exchange reference model with Metis

• Create and make available Web Services

• Model Workplace models in Metis

• Generate Workplaces in TIP

Figure 16: Telecom Pilot – Steps of Using Athena Services

Step 1, modelling the Reference Model in MO2GO is a preliminary modelling step that results in the enterprise Reference Model in MPCE. The Process Assistant Workplace can be automatically generated in Step 2.

MPCE is used to exchange the reference model with the Metis tool where additional modelling can be performed to instantiate constructs of the Instance Model relevant to a user role. In the Telecom Pilot this role is the Product Manager. Before the TIP workplace can be generated with any meaningful usability, Web-services that interact with the Data layer and retrieve information from enterprise repositories must be designed, tested and made available to Metis.

The service creation step entails use of the Johnson and TestDriver tools from A5. When the web services are created, they can be deployed in any service infrastructure accessible by Metis. Metis is used to import the available web services, instantiate MUPS services and finally generate the TIP workplace (realizing the Instance model of the enterprise) which is the actual GUI the PM uses in his work.

7.4 Guidelines and Experiences Present experience with the development of Model-Generated Workplaces in the PPM scenario

strongly supports the effectiveness of the approach for creating role specific application spaces that can support day-to-day tasks while adhering to the corporate standards captured in the enterprise model. The actual usefulness and usability of the MGWP for the selected role (Product Manager) will be evaluated in the near future but it has been clearly shown that the generated workplaces can go far beyond a traditional application development approach. Future directions for extending the MGWP concept so it can evolve into an end-to-end interoperability solution framework may be inspired by the following observations and challenges: • The actual design and implementation of underlying information retrieving Web services does not

stem from the Enterprise Models. The services pre-exist and are currently “linked” to appropriate tasks in the models. This creates a “boundary” or “mismatch” between the model-generated workplace, which is formally created, and the services supporting it, which usually are not. This is not a problem in services supporting document-related tasks, which can be uniformly designed, but it is a problem in all other types of data services. The main issue is the need to “match” constructs resulting from two very different processes at the boundary of the Enterprise Model and the existing (legacy) systems (in other words, the Shared and Network-visible Service Layer).

• Even more so, TIP User-Composable Services (MUPS) presuppose the existence of a “complete” set of visible services or the ability to transparently combine and orchestrate existing services in order to support all tasks modeled and supported by TIP. This is not a workplace task but is a barrier



in the effective utilization of such a workplace. Further efforts should identify ways of formally creating a description of this “complete” set of services needed and expected by the workplace.

• Deriving Views for each Role, which is the last step in the modelling procedure, is at present rougly defined. There is no current best practise, guideline or mechanism that identifies how to derive the role specific view from a model “automatically”. A preferred approach is probably the customization of appropriated services (e.g. Web services) based on the enterprise model on demand. Subsequently the model has to contain all necessary information in order to customize the right service. This means a high level of granularity and increase of model complexity. Some solution to manage this issue has to be developed.

• Model-configured solutions can facilitate tangible knowledge-sharing across roles and disciplines involved in PPM, only if actual product structures are captured in the models, so that workplaces can be adapted to them. Recent extensions to the Metis/TIP Web service plug-in, which are currently under testing, are intended to support importing of large data structures from XML business documents (e.g. Web service results) so that they can be mapped to model concepts and imported automatically. The workplaces can also update legacy system data by replicating the tasks that invoke update Web services for each component, element, or parameter in the product models.



8 IV&I Pilot

In the current approaches to standards development, the standard specifications developed are made normative only for the implementation level artefacts while the model artefacts are only made informative (i.e., non-normative). Within the Inventory Visibility and Interoperability (IV&I) Pilot, we seek to advance the traditional standards development approach by taking advantage of model-driven approaches to interoperability artefacts development. Within such a scenario, we employ and validate relevant ATHENA results. A concrete industrial context was selected to be the AIAG IV&I international project.

8.1 Pilot purpose and architecture The purpose of the test case is to support validation of a number of phases in developing standards-

based interoperable systems where the ATHENA tools are employed to enhance the traditional development approach, as shown in Figure IVI-TC1 below:

In the First Phase (P1), an Enterprise Modeling tool (i.e., MOOGO) is brought to bear on the IV&I Enterprise/Business Process Model capture. A goal for the IV&I enterprise modelling process is to capture the IV&I data exchange requirements. Another goal for the IV&I enterprise modelling is to show that multiple tools (e.g., ARIS) may use the IV&I enterprise modeling results. A desired outcome of this stage was to capture in a computational form the data exchange requirements for the communicating partners (i.e., supplier and customer).

Next, an additional modeling activity refines the IV&I business process model to the level of the atomic concepts and relationships that define the intended data exchange. As a result of this step, an IV&I Reference Ontology (RO) is developed using the ATHOS ontology management tool.

Then, in the Second Phase (P2), the application vendors annotate the local application interface models and the IV&I developer annotates the IV&I Business Object Document (BOD) Schemas. The annotation is done with respect to the IV&I RO developed in the First Phase. To accomplish the annotation process, the ASTAR tool is used.

Next, the annotations of the local models and BOD schemas are used to perform reconciliation of the differences among each of the local application interface models and the IV&I BOD models with the RO. The Reconciliation Tool (i.e., ARGOS) generates a Reconciliation Rule Base for each of the reconciliation situations: (1) translating data instances from a source application data format to the RO format (and back); and (2) from the RO format to the intermediate IV&I BOD data format (and back).

Next, during the Third Phase (P3), the Run-time Reconciliation Engine (i.e., ARES) is employed to use the Reconciliation Rule Bases and to translate the source application data format to the standard IV&I BOD data format. This transformation may be done locally or using a globally accessible reconciliation service. Finally, the IVI BOD instance data (packaged using the IVI BOD interface) is sent ‘over the wire’ using a standard service profile configured and executed by the a Web Service Execution Tool (i.e., Johnson).

8.2 Which Athena Services The following ATHENA results and tools have been used to support the IV&I Validation Pilot

• MOOGO and ARIS – Enterprise Model Authoring Tools • POP* -- Enterprise Model Exchange Specification and MPCE Enterprise Model reporistory; • ATHOS – Ontology Management and Authoring Tool • ASTAR – Model Annotation Tool • ARGOS – Reconciliation Rules Authoring Tool • ARES – Reconciliation Rules Execution Tool • THEMIS – Model Management Repository • Johnson – Web Services Execution Tool.

In addition, the following IV&I Pilot results and tools have been developed to make the validation pilot feasible: • WSS – Web Services Security plug-in for Johnson to support WS-I Security compliant service. • X2R2X – Messaging Transformation (from XML Schema to RDF Schema, XML to RDF, and RDF to

XML) • NIST Gateway – Coordination of Application Interfacing, Messaging Transformation, Reconciliation,

and Web Services Execution



• Apollo – Inventory Visibility application with RDFS-based native interface

8.3 How to use Services Figure IVI.1 shows the way the ATHENA solutions are employed in the pilot

Figure 17: ATHENA Results Utilized in the IV&I Pilot

1. During the first part, the enterprise modeler and analysts worked to define the IV&I eKanban Enterprise Model. The enterprise modeler used an EM tool (e.g., MO2GO) and an EM repository to author the IV&I eKanban Enterprise Model and capture the requirements for data exchange messages between the IV&I-conformant applications in a computable form. A part of the model was exchanged between multiple EM tools using the POP* and MPCE. (In the future, the IV&I Enterprise Model should be a basis for development of IV&I Reference Ontology in support of the eKanban data exchange. Presently, in our validation pilot, however, we focused only on data exchange requirements capture and interoperable exchange of models among EM tools. Due to limited resources, we did not validate the Enterprise Modeling part in combination with the latter parts of the pilot. This is indicated with the dotted line connecting the IV&I EM and RO in the figure.)

2. The IV&I RO was created using the ATHOS ontology authoring tool by an ontology designer. The IV&I RO contains concept and relationship definitions necessary to create models of IV&I eKanban documents. These models of the IV&I documents or BODs are based on the automotive industry adopted data exchange schema standard and interviews done with the business process analysts from industry.

3. The data exchange schema specification was required to be represented using the Open Applications Group Integration Standard (OAGIS) XML Schema-based BODs. These OAGIS XML Schemas needed to be annotated and reconciled with the IV&I RO using ASTAR and ARGOS tools. To accomplish this, however, the XML Schemas needed to be transformed into the required RDFS format using the XSD2RDFS tool. The outcome of these activities was a set of Reconciliation Rules that effectively maps BOD message instances, transformed into the required RDF format, into and out of the IVI RO representation. In this way the Public Interface is modeled and its schema is defined to handle data over the wire without the vendors necessarily knowing the form of the schema or doing anything specific to implement that particular schema.



4. Within the second, private part of the process, the ASTAR and ARGOS tools are used in a similar manner to reconcile the public and private interface models of the Inventory Visibility (IV) applications: The IV application local interface model is, again after the required transformation into RDFS, first annotated and then reconciled with the IV&I RO. The outcome of these activities is a set of Reconciliation Rules that effectively maps IV Application Interface Schema instances (transformed into RDF instances and in conformance with their model) into and out of the IVI RO elements. In this way, the Private IV Application Interface Model (e.g., proprietary XML Schema) is reconciled with the Public Interface Model (i.e., the IV&I eKanban BOD XML Schema annotated with the IV&I RO).

5. As a result of the public and private side of modeling and reconciliation, the reconciliation rules are made explicit and are based on the model’s intended meaning of the document elements rather than on how the document elements are to be encoded and transacted! Once the Reconciliation Rules are successfully defined, the vendor could execute these rules using the ARES run time engine. Successful reconciliation was accomplished by two independently developed applications: Apollo, capable of sending only its proprietary version of the AuthorizeKanban message and another GM-developed IV application also capable of sending its own proprietary version of the same message.

6. Both the Apollo and GM IV applications were able to exchange data using their proprietary message formats with an IV&I-conformant application (i.e., Ford-developed Test Harness). Тhe applications used the NIST Gateway that invoked the reconciliation function using the ARGOS semantic mediation engine, then called AXTOR and/or ARTOX service to transform the RDF instance from and/or to an XML instance conformant to the BOD schema, and, finally, was ready to send a message over the wire.

7. Finally, the NIST Gateway used the Johnson WS Execution Engine that allows Web Services profile specification and a WS call execution. As described later, our original goal was to test both WS-I specified Basic Profile and RAMP/RSP Profile. To enable the integration of the ATHENA tools and their usage in the pilot, the additionally developed

services in the IV&I Pilot have been used in the above steps: 1. Apollo Inventory Visibility (IV) application was used to support the visibility business process. 2. X2R2X transformation service was used at design time to provide XML Schema to RDF Schema

transformation (as required by the ATHENA tool set) and at run time to provide the corresponding (also required) transformations from XML to RDF and RDF to XML.

3. NIST Gateway was provided to coordinate at run time the actual transaction execution from the IV application side with necessary X2R2X transformations, the ARES reconciliations, and Johnson Web services execution.

4. The WSS plugin module was provided for Johnson tool to support WS-I Security compliant service.

8.4 Guidelines and Experiences The overall ATHENA architecture supported the validation pilot. Even though the AIAG IV&I

eKanban brought in a different perspective of using some aspects of the ATHENA architecture, the overall ATHENA solution set was adapted with additional effort to meet a new set of industrial requirements.

Based on the validation pilot, a number of additional services and tools were necessarily developed within the IV&I pilot. Together, these original ATHENA solutions and services begin to provide a set of solutions to support the envisioned model-based standards development approaches. Further steps are required to further the ATHENA methods and tools including the important step to work on maturing, hardening, and making robust these tool sets to adequately address harsh industrial requirements for scalability, usability, and reliability.



9 Outbound Logistic Pilot

The EU passenger car market is huge: in 2002 more than 14 million new cars were registered. For nearly 20 years, it had been regulated by a set of EU block exemption regulations. In 2002, a drop of these exemptions changed this marked fundamentally. For the first time, dealers became able to sell cars of different brands and different manufacturers on one common sales ground, thus improving the competitiveness of their business relations. However, since then, such multi-brand dealers have to face numerous interoperability issues. No longer can they rely on the IT system of one specific car manufacturer, but have to use a bunch of different brand-specific IT systems. Two very important interoperability problems arise: First, the integration of the configuration, customization and ordering functionality for a variety of brands into the existing IT landscape of the multi-brand dealer, and second, the seamless integration of data from the systems provided by the manufacturers into the dealer’s CRM5 system. As a result, the main advantage of multi-branding, i.e. to seamlessly offer cars of different manufacturers and to achieve comparability among the different products, is seriously threatened. What can be observed is the phenomenon of “early brand selection”: within a car buying process, customers have to choose the desired brand at the very beginning and perform the complete and brand-specific product configuration and ordering process for this brand. A change of the brand at a later point in time is only possible by restarting of the overall process.

9.1 Pilot purpose and architecture The purpose of the pilot is to transform this set of isolated, monolithic, manufacturer-specific systems

into an integrated, open and interoperable system. The vision here is a manufacturer-independent and CRM-integrated configuration and ordering system that can leverage the possibilities and the turnover of European multi-brand car dealers, especially for small and medium enterprises. However, the results should also be transferable to other branches where complex products of different manufacturer have to be configured in an integrated manner.

The overall architecture of the pilot is divided into two parts (which is described in more detail in Deliverable D.B5.4): • The integration of the manufacturers using a service oriented architecture (SOA). Car manufacturers

are supposed to offer their services (such as configuration, ordering etc.) as web services, what allows them to hide sensitive data and functionality behind an opaque interface. The mediation of the different expected processes, message formats and contained instance information is performed in three phases. In each phase, the exchanged messages are transformed.

• The integration of the customers and their individual or standard software into the vending process of the multi-brand dealer. Both parties, i.e. the customers and the dealer profit of this: on the one hand, customers are guided through the different steps of product finding and ordering and can obtain support in each step; the dealer, on the other hand, is able to get information about the current vending status of each customer by inspecting the state of the process instance that has been attached to the customers data within the CRM system.

The approach is based on the principles of a model driven architecture (MDA), i.e. during design time platform independent descriptions of processes, services and pieces of data are created. These models are used to create platform specific code that is processed during runtime.

9.2 Which Athena Services For the pilot, different services from the A projects and own services that have been especially

developed by CAS have been used. These are: • The CAS Instance Modeller and the CAS Instance Aggregator/Distributor for instance adaptation. • A6’s Semaphore tool and the CAS Instance Transformer for schema adaptation. • A7’s PIM4SOA meta model and the Jack Agent Platform for Process Adaptation • A2/A5’s tool suite (consisting of Maestro, Gabriel, Johnson and Nehemiah) for cross-organizational

business process mediation. The details on how these services have been used are described in the following section6.

5 Customer Relationship Management 6 More details can be found in Michael Klein, Ulrike Greiner, Thomas Genßler et al. Enabling Interoperability in the Area of Multi-Brand Vehicle Configuration. In Proc. of 3rd International Conference on Interoperability for Enterprise Software and Applications (I-ESA 2007). Madeira, Portugal, 28-30th March, 2007



9.3 How to use Services The integration of dealer and manufacturers is solved by a service-oriented architecture, which

allows manufacturers to hide most of their sensitive data behind a service interface and to communicate by exchanging XML based messages. To overcome the interoperability issues arising from this setting, in the pilot, the exchanged messages are transformed in three steps. Figure shows where and how the service from the A line and CAS have been used.

Dealer

Manufacturer 1

Offered Services

Manufacturer 2 Manufacturer 3

Instance Distributor/Aggregator

Schema Adaptor

Process Adaptor

Service Inte-grator

During design time• Set up platform

independent model

During run time• use model to process

data and a concrete platform

A7

A6 CASSemaphore Instance Transformer(as Axis handler)

PIM4SOA A7 Jack Agent Platform

CAS InstanceModeler

CAS Instance Distributor/Aggregator

Offered Services Offered Services

Dealer

Manufacturer 1

Offered Services

Manufacturer 2 Manufacturer 3

Instance Distributor/Aggregator

Schema Adaptor

Process Adaptor

Service Inte-grator


independent model



A7

A6 CASSemaphore Instance Transformer(as Axis handler)

PIM4SOA A7 Jack Agent Platform

CAS InstanceModeler

CAS Instance Distributor/Aggregator

Offered Services Offered Services

Figure 18: Services used for manufacturer integration

In the top most component, a message entering the service from the dealer is analyzed by the CAS Instance Distributor and routed to the set of manufacturers that need to process this request. In the inverse direction, i.e. when the results of the different manufacturers reach the component, the CAS Instance Aggregator comes into play: by applying metrics of similarity and equivalence, it tries to combine the different partial results to one meaningful integrated result. The Schema Adaptor in the middle layer is responsible for harmonizing the data models of the different manufacturers with the common data model of the dealer. Thus, the business objects extracted from the incoming messages are remodelled and put into the outgoing messages. The task of the Process Adaptor in the lower layer is to adapt the sequence of messages that is expected by a manufacturer system with the sequence that is sent out by the dealer. Thus, the processes of dealer and manufacturer will be harmonized.

All three services have been developed with a model driven approach (MDA). In a first step during design time, platform independent models have been created for each component. For the process adaptor, the A7’s meta model PIM4SOA (Platform Independent Model for Service Oriented Architectures) was used to define a connection between the processes of the dealer and manufacturer; for the schema adaptor, A6’s tool Semaphore was used to graphically map the entities and attributes of one data model to the corresponding entities and attributes in the other model; instance mediation support has been developed by CAS by creating a new modelling language (the CAS Instance Modeller). From these models, executables have been generated, which are used in a second step during run time to process the data on a concrete platform. For the process adaptor, the generated process transformations are executed as software agent on Jack, the agent platform used within the A7 project; for schema and instance adaptation, CAS developed own tools (the CAS Instance Distributor/Aggregator as well as the CAS Instance Transformer).



Dealer

Process Execution & Visualization

Customer 1 Customer 2 Customer 3

CRM System

Web Application

Web Application

Web Application


independent model



A2 MaestroA2/A5 Gabriel

A5 Johnson2

A2 Nehemiah

CAS

CAS CAS Configurator Web Interface

Figure 19: Services used for customer integration

Figure 19 shows the services that have been used for the customer integration. Again, it is based on a model driven approach relying on a set of ATHENA services for dealing with cross-organizational business processes (CBP) provided by the SAP tool set from projects A2 and A5. During design time, Maestro is used to model the private vending processes of dealer and customer. After that, the public parts from both of them are extracted and combined into one CBP. Moreover, it is indicated what data is transferred between both parties, i.e. which messages have to be exchanged, and how this data corresponds to the local data model. During run time, Gabriel and Johnson execute the processes, i.e. they keep track of the current state of each process instance, handle incoming and outgoing messages and integrate their payload data into the local data stores. Nehemiah executes the CBPs and provides a graphical visualization of them by showing the status of their steps in different colours. This view is integrated into the CRM system so that the dealer can directly keep track of the vending status of his various customers.

In the following, as an example how the services work technically, a stepping through a typical product finding process is sketched (more details on that can be found in Deliverable D.B5.4). The customer starts the process by entering the profiling in the web application. Here questions about the expected car type, its application purpose, price etc are asked. After the customer has given an answer to one of the questions, all manufacturers are contacted via a web service that returns the amount of car configurations that are suitable for the given set of restrictions. For example, the customer specified that the price of a desirable car should not exceed € 10,000, thus some manufacturers can provide models whereas others cannot. The results are also stored in the CAS Instance Distributor so that obsolete manufacturers are not re-queried again while the conditions are tightened. At the end of the profiling phase, a (small) set of concrete cars remains for selection. Note that the final set can still contain products of different brands and types so different web services have to be called. Their results are combined within the CAS Instance Aggregator.

After selecting one configuration, the phase of configuration is entered. This requires a finer grained interaction with the manufacturer. The customer and also the dealer have the possibility to add, delete and replace single elements of the product (e.g. add a climate control or change the colour of the car). Each change has to be verified by the corresponding manufacturer in order to guarantee a valid configuration. Moreover, the new prices (regarding package prices, special offers and so on) must be calculated. Differences in the data models and processes of the different manufacturers require the work of the schema and process adaptors. One typical difference in the data models is the use of business object oriented models versus the use of document oriented models. In a business object oriented model, web services are thought to represent remote methods and use complex, user-defined objects stemming



from the domain model of the manufacturer (like product, element, product plan, slot etc.) as parameters. In a document oriented model, web services are thought to receive, process and output documents, i.e. their parameters are documents containing data of primitive types (like e.g. ConfigurationDoc, AnalysisDoc). To mediate between messages stemming from different data models, during design time, a model of the mapping between classes and message types is created using A6’s Semaphore tool. During run, generated XSL transformations are used for the actual XML message transformation which is done in the CAS Instance Transformer. As the expected sequence of messages differs from manufacturer to manufacturer, mediation is necessary here, too. In the pilot, it is achieved by a PIM4SOA model that captures the mapping between the processes and Jack that executes this mapping.

Although the configuration phase operates with one product of exactly one manufacturer, it should still be possible to change from one manufacturer to another without losing the decisions that have been done so far. For example, it could be possible that the customer wants to convert his configured BMW into a VW to achieve a lower price but keep most the decision he has made, e.g. about the paint colour or the automatic climate control. Models of the similarity of elements (such as climate controls or colour) that have been developed during design time help to calculate equivalent configurations. Such similarity functions compare two elements of the given class and provide a similarity value from the continuous interval [0.0, 1.0]. To be in line with the general MDA approach of ATHENA, a simple language has been developed by CAS which allows to easily define such similarity functions.

After having finished the configuration of his car, the customer logs into an account and stores the car as new product. The product finding process now enters the cooperative phase where the main interaction between dealer and customer is performed. In a special messaging area of the web application, the customer can send and receive messages from the dealer, e.g. arrange an appointment for a test drive or a sales talk, request a binding offer etc. The exact process for this is modelled during design time using Maestro. During run time, on dealer side, it is handled by Nehemiah where the incoming messages are mapped onto objects in the CRM system (like appointments, addresses, offer documents and so on).

9.4 Guidelines and Experiences The services from the A line projects have been very helpful to set up the pilot. They could handle

many of the interoperability issues that had to be solved for this pilot. However, not all required services could be provided by ATHENA. To complete the pilot, CAS did own research and provided services in the area of schema mapping (e.g. “complex operations” for Semaphore, CAS Instance Transformer) and similarity comparison of instances (e.g. the CAS Instance Modeller/Distributor/Aggregator). In general, the functionality provided by the services often was not comprehensive enough. In practice, complex cases (like n:m associations, non-deterministic branch decisions etc.) are very common and should also be taken by into account. In future work, the prototypical services could be enhanced step by step to provide a full set of functionality for practical applications.



10 Future Work towards Enterprise Service Architectures and Platforms

One of the pilot builders made this concluding remark, “The functionality provided by the services often was not comprehensive enough. In future work, the prototyping services should be enhanced step by step to provide a full set of functionality for practical applications. “

Another stated, “What you do not design for you will never get, implying that interoperability must be designed for”.

A more coherent operational solution for supporting the intertwined processes of implementing an interoperability solution is thus needed. In section 3.3.1, we introduced approaches to Enterprise Service Architectures. Now it is time to revisit this idea, in order to outline directions for an operational platform for piloting, covering these services: • Piloting services, supporting the processes of

o Transforming as-is scenarios to to-be scenarios, utilising new technologies such as results from the action line A and B projects.

o Iterative refinement of to-be scenarios, e.g. to utilise improvements in the technologies and integration of results from the A projects,.

o Selecting specific scenarios for testing based on current to-be-scenarios. • Integration services, enabling composition and linking of technological solutions and current

systems as o Web services needed to execute test scenarios, o MDA services to exchange, verify and use data o MDA services to execute exchanged messages in work processes

• Testing services, facilitating continuous management and execution of test scenarios, including values monitoring and communications to suppliers,

• Prototyping services, supporting the adaptation to use-cases and user services, and providing guiding approaches and architectures as knowledge models to other industries. Some pilots, scenarios and test data are packaged as demonstrators.

10.1 A Model-Configured Service Oriented Architectures How should the above services be made available is the most useful way to each stakeholder and

role in the interoperability project? Projects A3, A5, A6, and A7 have enhanced the solutions for definition, composition, orchestration and management of services and Service-Oriented Architectures (SOA) and supporting IT and technical architectures. Extending this, focus should be on providing a solid service description and architecture seen from the SOA perspective. Operationally, these should be accessed through a service describing meta-models.

To enable users to compose, configure and manage their own services we have defined five layers of services in structures. Each layer uses services offered by the layers below, and users will apply services from all layers. Typically, each layer will provide more specialised services than the one below. In current services stacks, higher-level services are often composed by programming. The ESA, on the other hand, is designed to utilise process and service standards to enable model-configured, user-composed platforms and services (MUPS). This section describes a MUPS approach to piloting.

All layers are composed by using visual modelling techniques. The two lowest ESA layers are composed by software engineers, and the two upper by the users.



Figure 21: The layers of services in the Enterprise Services Architecture (ESA).

10.1.1 Generic Infrastructure Services At the lowest level, generic infrastructure services are offered by off-the-shelf software components.

For the model-driven piloting of ATHENA, the core ICT platform consists of the modelling and execution platforms developed and applied by A1-A8.

The categories of services offered by these platforms include: • Modeling – covering all from visual diagramming (UML) to AKM modeling • Visualization – creating role-specific as well as common views • Analysis – being able to perform many kinds of analysis • Storage of models, model constructs and related artifacts • Transactions and messaging to coordinate transactions • Concurrency control to avoid overstoring • Versioning of knowledge model structures • Work process, task-pattern and process and task execution • Rule modeling, execution and management • Dependency tracking and context preservation • Search facilities to recover data and information • Integration of data views, services, views and models • Privacy and security, to inspire trust and confidence • IPR mechanisms and services to facilitate sharing and team-working

Deliverable DA1.5.1 describes these services in greater detail.



10.1.2 Service Team Support A service team is a task force put together to develop applications and solutions. In the context of

piloting in ATHENA, the service team is responsible for prototyping the high-level services to be tested, as well as for instrumentation of the test environment. The basic team support services include • Work management, task definition, hierarchical breakdown and monitoring, • Collaboration support, e.g. shared workspaces, event notification and messaging, • Project planning and management, • User management and access control setup, • Service composition, reuse and management, • Model and meta-model management, knowledge management. • Dissemination and training services (cf. ATHENA B6).

Service providers develop and make services generally available, but customer users also require services and knowledge to be able to extend, compose, adapt and configure their own project and platform management services.

10.1.3 Model-Configured Application Services This layer contains a application services relevant for multiple industrial sectors. The ATHENA pilots

will define services at this layer which are to be tested. The details of the cases are described in other reports from B5. Piloting and testing is however an application service in its own right. In this context, the generic lower level services should be composed in a manner which supports the piloting and testing methodology (DB5.1). How the testing applications can be configured, will be described in the next chapter, where we will discuss further pilot modelling, integration, testing, execution and results management.

10.1.4 Industrial Solutions, Stakeholder and Business Services At this layer application, team and infrastructure services are customised to industrial sectors and

even to individual companies and stakeholders. Here the pilot applications should be generalised in order to ensure wider industrial impact. Often industrial solutions services will be informative and management oriented, while performance of high-volume core work processes is supported by more generic tools from the lower layers.

10.1.5 Community Services Community services extend the reach of industrial solutions beyond the individual companies

through organisations such as the EIC, and by extending the service platform with workplaces to involve academia and interest organizations in practical day to day project work. This means the gap between academia, government, financial institutions and industry can be bridged.

Industrial platforms can be extended to external actors as demonstrators for dissemination, for training, and for inviting other expertise in industrial enterprising. With traditional IT systems many sciences and scientific experts are locked out of the industrial arena. With AKM driven SOA this could change faster than imagined.

Reusable solution patterns may be abstracted into standards. The underlying services that facilitate this process include generalising and anonymising, in addition to training, dissemination and community management services which utilise a customised service team platform.

10.2 Services for Piloting, Testing, Integration and Prototyping As outlined above, services for use-case piloting and testing should be composed and managed by

users using visual modelling. This services model needs to be linked to the enterprise model of the pilot case, in order to facilitate business-driven, model-based customisation. This section outlines how the service architecture can be used to support customisation of the pilot case applications and solutions to be tested.

10.2.1 Piloting Services This section describes how the ESA supports the definition of as-is and to-be scenarios as well as

test cases, and how the overall piloting process can be planned and managed.



10.2.1.1 Supporting the Piloting Teams

The work of piloting teams (in Athenian called CATs – cross action line teams) was intended to be supported, coordinated and managed by platform and other teams, but this support was not as good as it ought to have been due to late availability of certain key results. The platform services were just not ready for deployment for supporting practical work, and the tasks of deploying and supporting users were grossly underestimated. The plan was to set up work areas for each team, and its members should be defined and given access to the work area. Additional services such as project planning, task management, content management, and page editing were also discussed.

10.2.1.2 Modelling

The first step in developing the pilots was to use some Enterprise Modeling tool to build an as-is- scenario, which should act as a baseline for the piloting experiment. The different use-cases chose different languages and tools for the modeling. In general all tools would allow the use-case teams to capture and harness the following enterprise knowledge aspects.

1. Process aspects – business hierarchy, common processes, and local work processes 2. Organization – a new form of service-team organization focusing mutual service provisioning

should be developed and put in place for networked enterprises 3. Product – industry is looking for ways of model-integration of the seven to ten different product

structures in use in most industries 4. Systems – future systems must be designed in a more holistic POPS approach 5. Decisions – decisions support and management depend on preserving context 6. Concepts – modeling languages must be extensible to support new concepts 7. Information – users need services to define and share data and develop logistics 8. Document – document management needs model-configured content management 9. Competences/Skills – C&S profiles are needed to match roles and resources 10. Location – context, semantics and identification schemes depend on loacation 11. Goal – goal modeling is an important view for work process performance 12. Requirement – requirements should be modeled as role views 13. Project – project models and models for portfolio management are needed is 14. Results -– products and services are not the only results or outcomes of work 15. Business Strategy – important for all activity to have clearly defined objectives 16. Market Analysis – customer, partner and competitor knowledge is key 17. Business Analysis – most enterprises need to perform many kinds of analysis Through meta-modelling, the individual use case piloting teams have extended the basic tool

languages with particular constructs for product portfolio management, collaborative product design, e-Procurement, supply chain management etc. Other modelling frameworks may also be applied. One should however make sure that the modelling tools have established links to the execution infrastructures that are to be tested, in order to simplify test case setup.

Anyone interested in trying out the Athena prototypes on a use-case pilot should follow this approach. Start by developing an as-is model has been constructed, analysis services should be applied to identify core interoperability problems. Then the contributions of the various action line A research projects to fix these problems should be identified. Specific technologies and services should be selected, and the modelling team should describe how users will apply the different services in the test case. Success criteria and metrics should be defined as part of the model (Goal and Results parts respectively) in order to make the test model complete.

10.2.2 Testing Services Testing includes verification that a system works according to its specification (the detailed test case

scenario), but more importantly validation that the technology solves real industrial interoperability problems. In a model-driven piloting methodology, the piloting model should provide traceability between the test case and industrial requirements, aiding validation. Open-ended experiments with real subjects are however needed in order to validate the assumptions that the technologies are based upon. The testing itself should be validated against performance criteria as described in DB 5.1.1.

While validation requires observation and interviewing, thorough verification demands instrumentation of the test environment. Questionnaires are insufficient for verification because they introduce a step of interpretation, and consequently a potential bias, between the activities to be performed and the measurements collected. The execution platform should thus provide ways of more



directly measuring the activities performed as part of the test, e.g. an event log capturing times, users and details of each action. The artifacts produced during the test execution, should also be accessible so that their characteristics may be measured and compared to the as-is baseline.

The test data collected needs to be managed, alongside the results of the case, which may be relevant for a case demonstrator to be packaged later. A standardized (or at least common) and structured way of documenting the results should be defined, and put in a clearly recognizable place of the test team work area in the Athena Collaboration Platform (ACP).

For real trials in the organization, the test subjects also need to be registered and given access to the technologies they are to use. This may be achieved by customizing the generic service team user management services.

10.2.3 Integration Services The MUPS approach advocated model-driven integration of services, both for piloting and for the

domain of the pilot cases. Given that we will have to execute test cases on a range of existing technology platforms, a model-driven approach will not be sufficient for all needs. The range of integration techniques provided and utilised by A projects, e.g. programming APIs, code generation from models, process choreography, semantic mediation, active model execution and peer-to-peer agent infrastructures, should all be tested. Hopefully the pilots will utilise the integrated platforms being assembled in the A projects, however, we will also need to interoperate with external design systems as part of the testing. In order to support model-driven integration, the ATHENA piloting platform should be able to import standard formats such as WSDL and BPEL and to link such descriptions to activities in the test scenario. The platforms should also be able to apply external systems during test case execution.

10.2.4 Prototyping Services There are different kinds of scenarios for prototyping, all from entire new use-case scenarios to

alternative scenarios to incremental improvements by adding or changing services, models and software components. Our prime focus is our selected test case scenarios

Prototyping is an established approach to pilot development, which can be performed using almost any development approach, platform and tool set. Such an iterative and incremental approach to development should be supported by services that handle multiple alternatives, configuration management of revisions and variants, including exchange of solution components.

Again, visual modelling approaches and interfaces to versioning and dependency tracking should be utilised. This should enable different solution packaging, e.g. with instrumentation for testing or with more descriptions and data for demonstration and training.

The solutions we will be able to offer here will be very much influenced by how we approach the various use-case solutions. If use-cases are not developed using an integrated ESA, supporting harmonised approaches, methodologies and families of solutions, then the knowledge models and operational solutions will not be repeatable as a flexible basis for extensive prototyping.

10.3 Architecture of Model-Configured The MUPS pilot platform envisions that each industrial user should define his/her own specific

environment to execute his/her own test scenario. This should be done by the piloting teams, through visual modelling.

A first step towards realising this framework will be to define work areas for each pilot team, and to populate these areas with rudimentary piloting, testing, integration, and prototyping services. Other tasks will involve the development of the ESA, and the integration of SOA test-beds or platforms in particular testing, wrapping and mapping services. The ESA architecture is illustrated in a simplistic view in figure 22 below.

The simplified architecture picture shows how the A1 MPCE architecture and the A5 & A6 Integrated Execution Infrastructure could fit together, where the A5 will be specifically focussed on services, customisable plan and service negotiation. Further details on how to achieve this integration has to be modelled on the system level, with a close attention to identifying software components and their interfaces.



Model generated workplaces

MPCE services &Active knowledge models

Model repositories

Legacy System A Legacy System B

Users

A5 & A6IntegrationExecution

Infrastructure

(w/InfrastructureServices)

Public/ExternalSystem/Service

Figure 22: The main structure and services of the Enterprise Services Architecture (ESA).



11 Conclusions

As a general conclusion of the usefulness of the Athena results one pilot builder stated; “The functionality provided by the services often was not comprehensive enough. In practice,

complex cases like many to many associations and non-deterministic branch decisions are very common and should also be taken into account. In future work, the prototypical services could be enhanced step by step to provide a full set of functionality for practical applications. “

Another pilot builder stated:” What you do not design for you will never get, implying that interoperability must be designed for”.

In the future systems will be designed by employing more services to involve stakeholders and support user interaction from the early stages, so we will increasingly be designing for interoperability, for supporting continuous team-learning, and life-cycle knowledge evolution and harnessing for effective if not automatic reuse. Still there will be a demand for services, as demonstrated by these pilots, to extend and adapt already deployed operational platforms, their systems and services.

The IT system providers will have to provide new approaches and methodologies to allow a wider variety of adaptable and extendable customer services for industrial users and partners to build their own operational solutions and workplaces. But for markets and application areas where stakeholders and users are not easily involved in operations or maybe not even available we will need to provide alternative approaches and methodologies for developing systems and operational solutions.

Certainly trying to implement interoperability in deployed traditional IT systems that have been in use for some time is not easy and will not give agile solutions or support design and services evolution. Current operational IT systems, sold off the shelf, suffer from a dramatic loss of stakeholder contextual knowledge in their life-cycle from specifications to delivery and to re-engineering or demolition. Service provisioning is a step in the right direction, but support for users to configure, adapt and manage their own services and workplaces are needed.

The delay in modeling the use-cases and scenarios made it more difficult to get partners to understand and contribute towards defining the overall architecture and platform for the piloting and integration of piloting and integration services, and eventually the testing and prototyping services. Thanks to the establishment of the Cross Action Line Teams (CATs) we in the end got good results in all six use-case pilots. Modeling was important in all use-cases. Also an overarching ESA platform and architecture should be further developed. This will facilitate piloting service development, composition, orchestration, use and management.

The pilots prototyped three types of operational solutions: 1. Global horizontal peer-to-peer systems, characterized by repeatable business objects and

clusters of services, where interoperability can be achieved by bottom-up resolution, model-configured services, model-mapped semantics, standards, and logistics alignment, prototyping and supported by the results of ATHENA projects A3, A5 and A6.

2. Collaborative business process systems, characterized by a service- oriented architecture middle layer, integrating services across various legacy systems, where interoperability is achieved by top-down model-driven architectures, standards and services, supported by ATHENA projects A2, A5, A6 and A7.

3. Collaborative product and process design (CPPD), characterized by process flows being designed as task-patterns, and related to add intelligence to product structures, interoperability is achieved middle-out, though model-configured, user-composed layered service architectures, supported by ATHENA projects A1, A6, and A8.

Most global, multi-national corporations have a need for all the three approaches. The common glue is a set of web-services for project portfolio management, services management, document management and more. We may denote it a common Enterprise Service Architecture, operated by a professional Service-Team organization with clearly defined roles.



12 References

1. ATHENA Deliverable DB5.1.1, Term of Reference for the Technology Testing Network, 2004. 2. ATHENA Deliverable DB5.4.2, Post Test Evaluation, 2007. 3. ATHENA Deliverable DA6.1, Specification of a basic architecture reference model, 2005. 4. ATHENA Deliverable DA5.2, Model and Specification of service description and usage as well as

advanced concepts, 2006. 5. ATHENA Deliverable DA1.3.1, Report on Methodology description and guidelines definition,

2005. 6. ATHENA Deliverable DA1.5.1, Collaborative Modelling Platform Specification, 2004. 7. ATHENA Deliverable DA1.5.2, Collaborative Modelling Platform – First Prototype, 2005. 8. ATHENA Work document WDA1.5.3, Integrated model exchange management in the MPCE

platform, 2006. 9. ATHENA Work document WDA1.8, POP* Framework revised, 2006. 10. ATHENA Deliverable DA2.5, Enactment of Cross-Organisational Business Processes, 2005. 11. ATHENA Deliverable DA6.4, Model-driven and Adaptable Interoperability Infrastructure, 2005. 12. ATHENA Deliverable DA7.2, ATHENA Approach to Business Document and Protocol

Management, 2007. 13. ATHENA Deliverable DA8.2, Guidelines and Best Practices for Applying the ATHENA

Interoperability Framework to Support SME Participation in Digital Ecosystems, 2007. 14. Rolfsen, Boell, Pronios, Knothe, Anastasiou, Elvesæter, Jørgensen: Model-generated

workplaces: An interoperability approach, I-ESA 07 Conference, Madeira, March 2007. 15. Solheim, Lillehagen, Petersen, Jørgensen, Anastasiou, Model-Driven Visual Requirements

Engineering, Requirements Engineering Conference, RE’05, IEEE Press, Paris, September 2005.



13 Glossary

The following list defines terms used in this document. Assessment: An action of applying specific documented assessment criteria to a specific software

module, package or product for the purpose of determining acceptance or release of the software module, package or product. (ISO 9126: 1991, 3.1)

Customer: Ultimate consumer, user, client, beneficiary or second party. (ISO 9004: 1987, 3.4) Defect: The non-fulfilment of intended usage requirements. (ISO 8402: 1986, 3.21) Features: Features are identified properties of a software product, which can be related to the quality

characteristics. (ISO 9126: 1991, 3.2) Functional Requirements: A functional requirement specifies what the system must be able to do, the

functions it should perform. Functional requirements are associated with specific functions, tasks or behaviours the system must support. This term is used at both the user requirements analysis and software requirements specifications phases in the software life cycle.

Functional requirements capture the intended behaviour of the system. This behaviour may be expressed as services, tasks or functions the system is required to perform [ATHENA]

Inspection: Activities such as measuring, examining, testing, gauging one or more characteristics of a product or service and comparing these with specified requirements to determine conformity. (ISO 8402: 1986, 3.14)

Level of performance: The degree to which the needs are satisfied, represented by a specific set of values for the quality characteristics. (ISO 9126: 1991, 3.4)

Liability (product/service): A generic term used to describe the onus on a producer or others to make restitution for loss related to personal injury, property damage or other harm caused by a product or service. (ISO 8402: 1986, 3.19)

Measurement: The action of applying a software quality metric to a specific software product. (ISO 9126: 1991, 3.5)

Methodology: A set of instructions (provided through text, computer programs, tools, etc.) that is a step-by-step aid to the user - [ISO 15704, 1999]

Nonconformity: The non-fulfilment of specified requirements. (ISO 8402: 1986, 3.20) NOTE -- The basic difference between `nonconformity' and `defect' is that specified requirements may

differ from the requirements for the intended use. (ISO 8402: 1986, 3.20) Non-Functional Requirement: A non-functional requirement specifies an aspect of the system other

than its capacity to do things. Examples of non-functional requirements include those relating to performance, accessibility, usability, etc. [ATHENA]

Pilot: The implementation of use case solutions in a real context of industrial users. Pilots are employed to test in a limited context the goodness of a use case solution before its extension on the whole enterprise reality. [ATHENA]

Piloting : is the best offered by providing guidelines approaches on how to solve, design and engineering applications and challenges that until now have been poorly or not at all solved. [ATHENA]

Prototype: Model on which business enterprise model and services are patterned and developed [ATHENA]

Prototyping : Activity performed on a model, regarding many aspects for many targeted groups of people. The prototyping can concern systems, modelling, model management, process analysis , work management methods, work execution [ATHENA].

Rating: The action of mapping the measured value to the appropriate rating level. Used to determine the rating level associated with the software for a specific quality characteristic. (ISO 9126: 1991, 3.7)

Rating level: A range of values on a scale to allow software to be classified (rated) in accordance with the stated or implied needs. Appropriate rating levels may be associated with the different views of quality i.e. Users, Managers or Developers. These levels are called rating levels. (ISO 9126: 1991, 3.8)

Recoverability: Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it. (ISO 9126: 1991, A.2.2.3)



Reliability: The ability of an item to perform a required function under stated conditions for a stated period of time. The term `reliability' is also used as a reliability characteristic denoting a probability of success or a success ratio. (ISO 8402: 1986, 3.18)

Replaceability: Attributes of software that bear on the opportunity and effort of using it in the place of specified other software in the environment of that software. (ISO 9126: 1991, A.2.6.4)

Resource behaviour: Attributes of software that bear on the amount of resources used and the duration of such use in performing its function. (ISO 9126: 1991, A.2.4.2)

Scenario: is a description of a user interaction with a system or alternatively can be defined as a Use Case instance. The scenario is a set of detailed activities [ATHENA].

Security: Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. (ISO 9126: 1991, A.2.1.5)

Software quality: The totality of features and characteristics of a software product that bear on its ability to satisfy stated or implied needs. (ISO 9126: 1991, 3.11)

Software quality assessment criteria: The set of defined and documented rules and conditions which are used to decide whether the total quality of a specific software product is acceptable or not. The quality is represented by the set of rated levels associated with the software product. (ISO 9000-3: 1991, 3.12)

Software quality characteristics: A set of attributes of a software product by which its quality is described and evaluated. A software quality characteristic may be refined into multiple levels of sub-characteristics. (ISO 9126: 1991, 3.13)

Software quality metric: A quantitative scale and method that can be used to determine the value a feature takes for a specific software product. (ISO 9126: 1991, 3.14)

Stability: Attributes of software that bear on the risk of unexpected effect of modifications. (ISO 9126: 1991, A.2.5.3)

Suitability: Attribute of software that bears on the presence and appropriateness of a set of functions for specified tasks. (ISO 9126: 1991, A.2.1.1)

Testability: Attributes of software that bear on the effort needed for validating the modified software. (ISO 9126: 1991, A.2.5.4)

Testing : Activity performed on architectures, components and solutions at all three level of the Enterprise Architecture.[ATHENA]

Test Scenario: A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement [ATHENA]

Test Procedure : is the step-by-step process needed in order to verify that the product meets all the interoperability requirements established [ATHENA]

TO-BE Scenario: Envisaged ideal situation in which Interoperability problems don’t exist. [ATHENA] Understandability: Attributes of software that bear on the users' effort for recognizing the logical concept

and its applicability. (ISO 9126: 1991, A.2.3.1) Usability: A set of attributes that bear on the effort needed for use, and on the individual assessment of

such use, by a stated or implied set of users. (ISO 9126: 1991, 4.3) Use Case: is a collection of possible sequences of interactions between the system under discussion and

its Users (or Actors in Business Processes), relating to a particular goal. A use case defines a goal-oriented set of interactions between external users and the system under

consideration or development. Use cases allow capturing functional requirements for a Business case. [ATHENA]

Validation: confirmation by examination and provision of objective evidence that specifications conform to user needs and intended uses, and that the particular requirements implemented can be fulfilled. The primary focus of validation is customer satisfaction. [ATHENA]

Validation (for software) is the process of evaluating software to ensure compliance

Documents

Deliverable Number: DB5.3 Users Guide to Athena ... · IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Piloting including Technology Testing Coordination and Pilot Infrastructure