Large-scale integrating projects _IP_

Document Sample
Large-scale integrating projects _IP_ Powered By Docstoc
					FP7-ICT-2009-5                                                           Integrated project proposal
30/07/09 v1                                                                                  SOA4IS


                       Large-scale integrating project (IP) proposal
                                                     ICT Call 5
                                                  FP7-ICT-2009-5


                                    SOA for Industrial Systems

Special arrangements apply for the preparation of proposal Part B in the Objective ICT-
2009.9.2 and ICT-2009.9.5. See Annexes 7 and 8 of the Guide for applicants




                                                       SOA4IS

Large scale integrating project (IP)
Date of preparation: 26 October 2009
Version number (optional): 4.5

Work programme topic addressed
1.2a: Service Architectures and Platforms for the Future Internet
- Open, scalable, dependable service platforms, architectures, and specific platform components
1.2b: highly Innovative Service / Software Engineering
- Service / Software engineering methods and tools
- Verification and validation methods
1.3a: Architectures and technologies for an Internet of Things
- Optimized technologies covering distribution of intelligence


Name of the coordinating person: Oliver Arafat
e-mail: oliver.arafat@siemens.com
fax: +49 (89) 636-45450

Participant no. *         Participant organisation name              Part. short            Country
                                                                        name
1 (Coordinator)       Siemens AG                                    SIEMENS           Germany
2                     Thales France SA                              THALES            France
3                     SAP                                           SAP               Germany
4                     TIE Nederlands b.v.                           TIE               Nederlands
5                     IBM                                           IBM               Israël
6                     INRIA                                         INRIA             France
7                     Universität Duisburg-Essen                    UniDue            Germany
8                     Universidad Politécnica de Madrid             UPM               Spain
9                     Claas                                         CLAAS             Germany

*Please use the same participant numbering as that used in Proposal submission forms A2




Proposal Part B: page 1 of 71
FP7-ICT-2009-5                                                                                                  Integrated project proposal
30/07/09 v1                                                                                                                                     SOA4IS


                                                                Proposal abstract

TODO: write the abstract.




                                                              Table of contents
SECTION 1.           SCIENTIFIC AND/OR TECHNICAL QUALITY, RELEVANT TO THE TOPICS ADDRESSED BY THE CALL .......... 4
    1.1 CONCEPT AND OBJECTIVES........................................................................................................................................... 4
       1.1.1 Context ........................................................................................................................................................ 4
       1.1.2 A section with no good title presenting the challenges and the answers ................................................... 5
            1.1.2.1           The Automation Pyramid....................................................................................................................................5
            1.1.2.2           Different constraints and SLAs in the various layers...........................................................................................5
       1.1.3  Technical Challenges ................................................................................................................................... 7
       1.1.4  Main Ideas Underlying the Vision ............................................................................................................... 8
       1.1.5  Technical Approach: the SOA4IS Architecture............................................................................................. 8
       1.1.6  Scientific and Technological Objectives ...................................................................................................... 8
       1.1.7  OLD: Project vision .................................................................................................................................... 10
    1.2 PROGRESS BEYOND THE STATE-OF-THE-ART .................................................................................................................. 11
       1.2.1  Description of the State of the Art ............................................................................................................ 11
       1.2.2  Differentiation between other related projects ........................................................................................ 11
       1.2.3  Contributions beyond the State of the Art ................................................................................................ 11
       1.2.4  Indicators for Measuring Progress ............................................................................................................ 11
       1.2.5  Impact for Measuring Progress ................................................................................................................. 11
    1.3 S/T METHODOLOGY AND ASSOCIATED WORK PLAN......................................................................................................... 12
       1.3.1  Overall strategy and general description .................................................................................................. 12
       1.3.2  Timing of work packages and their components ...................................................................................... 13
       1.3.3  Work packages list / overview .................................................................................................................. 14
       1.3.4  Deliverables list ......................................................................................................................................... 16
       1.3.5  List of milestones ...................................................................................................................................... 18
       1.3.6  Work packages description ....................................................................................................................... 19
            1.3.6.1           WPs linked to Activity 0: Project Management ................................................................................................19
            1.3.6.2           WPs linked to Activity 1: Transverse Technical Activities .................................................................................21
            1.3.6.3           WPs related to Activity 2: Technical Foundations of Industrial Systems ..........................................................24
            1.3.6.4           WPs related to Activity 3: Management of Industrial Systems.........................................................................28
            1.3.6.5           WPs related to Activity 4: Systems Integration Management ..........................................................................34
            1.3.6.6           WPs related to Activity 5: Impact on contemporary development techniques................................................36
            1.3.6.7           WPs related to Activity 6: Experimentation and Validation .............................................................................41
            1.3.6.8           WPs related to Activity 7: Exploitation and Dissemination...............................................................................48
        1.3.7 Risk assessment ........................................................................................................................................ 55
        1.3.8 Summary of effort ..................................................................................................................................... 55
2       IMPLEMENTATION ..................................................................................................................................... 56
    2.1 MANAGEMENT STRUCTURE AND PROCEDURES............................................................................................................... 56
       2.1.1 Project Management Organization and Structure.................................................................................... 56
       2.1.2 Consortium agreement ............................................................................................................................. 60
       2.1.3 Project Plan and Activity Management .................................................................................................... 60
       2.1.4 Meetings ................................................................................................................................................... 62
       2.1.5 Communications flow ............................................................................................................................... 62

Proposal Part B: page 2 of 71
FP7-ICT-2009-5                                                                                             Integrated project proposal
30/07/09 v1                                                                                                                              SOA4IS
     2.1.6   Deliverables and other project documents ............................................................................................... 62
     2.1.7   Risk Management and Conflict Resolution ............................................................................................... 63
     2.1.8   Quality Assurance and Configuration Control........................................................................................... 64
  2.2 INDIVIDUAL PARTICIPANTS ......................................................................................................................................... 65
     2.2.1   Thales ........................................................................................................................................................ 65
  2.3 CONSORTIUM AS A WHOLE ........................................................................................................................................ 66
  2.4 RESOURCES TO BE COMMITTED .................................................................................................................................. 67
3    IMPACT ..................................................................................................................................................... 68
  3.1 EXPECTED IMPACTS LISTED IN THE WORK PROGRAMME ................................................................................................... 68
  3.2 DISSEMINATION AND/OR EXPLOITATION OF PROJECT RESULTS, AND MANAGEMENT OF INTELLECTUAL PROPERTY......................... 69
4    ETHICAL ISSUES .......................................................................................................................................... 70




                                                                  Table of Tables


Table 1.1.a: Scientific & Technological Objectives .......................................................................................... 9
Table 1.2.a: Progress Indicators ...................................................................................................................... 11
Table 1.2.b: Impact Indicators ......................................................................................................................... 11
Table 1.3.a: Work Packages List ..................................................................................................................... 15
Table 1.3.b: Deliverables list ........................................................................................................................... 17
Table 1.3.c: List of milestones......................................................................................................................... 18
Table 1: Project Management Board ............................................................................................................... 58
Table 2: SOA4IS project reporting.................................................................................................................. 61




Proposal Part B: page 3 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                            SOA4IS


Section 1.   Scientific and/or technical quality, relevant to the
  topics addressed by the call
(Maximum length for the whole of Section 1 – twenty pages. This limit does not include the Gantt chart, Pert
diagram or tables 1.3a-e)


1.1 Concept and objectives


1.1.1 Context

Service orientation has shown its benefits in typical enterprise application integration scenarios that build on
composability, reuse, and integration. Now, SOA also enters industrial settings, because of the increasing
need to integrate with other systems and parties such as business applications, 3rd party suppliers and
different automation protocols.
Within in the scope of this project, the term "Industrial Systems" is referring to all systems containing
software and that are specifically used for industrial purposes. It is a broadly used term to portray holistic
solutions in a wide range of industrial settings that are often mission-critical, such as Water Management
Systems, Electric Power, Traffic Signals, Mass Transit Systems, Environmental Control Systems, and
Manufacturing Systems.
Below, we define the terms industrial solution and industrial system:
        Definition 1: An industrial solution is an integrated hardware/software solution that is, firstly, used
        in an industrial setting, and secondly, has at least one hardware and/or software component on
        every single layer of the automation pyramid (as introduced in section 1.1.2.1).
        Definition 2: An industrial system is comprised of an arbitrary number of hardware/software
        components that are part of an industrial solution excluding the ERP-layer.                                Comment [VGR1]: Why did you exclide the
                                                                                                                   ERP layer?


Industrial systems now face an increasing demand on 3 axes that are presented below:


                  Demand                                              Envisioned solution
   Cost reduction to resist to an ever-more       Better re-use of existing components or sub-systems even
    challenging competition                        in the lowest layers
   Increase agility of integration between        Develop agile integration mechanisms
    technical layers and business-oriented
    layers
   Adaptation to the end-user personality         Apply the Product-Line Engineering techniques at the
    and/or the environment                         lower levels


The static structure of industrial systems built on the model of the Automation Pyramid must be evolved to
face these challenges. By pushing successful Service-Oriented Concepts down to all layers of the
automation pyramid, SOA4IS will provide a foundation for cost-competitive service-based systems
with increased flexibility and adaptation capabilities. Instead of working in each layer with different
paradigms, industrial systems architects and engineers will build all layers of the system in a consistent end-
to-end approach, using services as core feature providers and workflows as choreographers and orchestrators.
This consistent approach will also ease validation of mission-critical systems and make them safer and more

Proposal Part B: page 4 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                       SOA4IS
compliant. The major expected outcome at the economy level is to favor exchanges and interactions between
the economy of embedded hardware and software and the emerging economy of cloud computing and
Internet of Services.


 The prime deliverable of the SOA4IS project will be:
     an architecture for a service-oriented system mixing hardware and software
     a tool-supported methodology to break down various software layers into services
     a reference, open-source framework implementation to provide the industry with utilities for
      building service-oriented systems
 The partners will demonstrate how this architecture supports the implementation of complex scenarios
 in various business domains, not exclusively from the software industry, that are not otherwise
 supported by current environments. In doing so, the partners claim to achieve significant quantifiable
 improvements in modularity, productivity, flexibility, quality and cost at all layers of the automation
 pyramid.



1.1.2 A section with no good title presenting the challenges and the answers

1.1.2.1 The Automation Pyramid
Due to the resulting complexity of the involved systems and technological processes, the industrial domain
established a hierarchical pyramid model, the so-called Automation Pyramid as depicted in figure 1. At the
top level, Enterprise Resource Planning (ERP) systems are responsible for high-level planning, stock
management, and order handling. Manufacturing execution systems (MES) control the production processes
in a plant, collect and archive Key Performance Indicators (KPI) and quality data. The next layer is about
Supervision, Control, and Data Acquisition (SCADA). It controls and monitors specific production
processes, which are running on the next lower level, and it collects the runtime data necessary for distilling
KPIs on upper layers. On the next lower level Programmable Logic Controllers (PLC) operate on actuators
and sensor data to actually run the physical production process. At the bottom is the field level containing
field buses and industrial communication networks.




                                          Figure 1: The Automation Pyramid
                                                                                                                  Formatted: Heading 4
1.1.2.2 Different constraints and SLAs in the various layers
Contemporary Industrial Systems often encompass software systems that run and interact through a variety
of (proprietary) communication protocols with different software systems on every layer of the automation

Proposal Part B: page 5 of 71
FP7-ICT-2009-5                                                     Integrated project proposal
30/07/09 v1                                                                         SOA4IS
pyramid, ranging from ERP, MES, SCADA, down to PLC. Furthermore, their application area is often in
very sensible domains such as atomic power plants where human lives are at stake in case of non-conformant
and erroneous behavior.
Apparently, different types of systems are used on different layers of the automation pyramid. Upper levels
of the pyramid are the domain of enterprise systems, which run on servers with a lot of resources. They are
transactional, throughput-optimized and usually driven by user interaction. On the lower levels of the
pyramid the domain gradually shifts to the embedded field, where systems have to cope with limited
computational resources, (hard) real-time constraints, and are usually driven by technical processes. These
characteristics of the industrial domain puts some unique challenges on the application development as non-
functional requirements such as availability or (hard and soft) real-time, and specific environmental
constraints such as limited computational resources, vary significantly between the various layers of the
automation pyramid and thus also vary within one single Industrial Systems. For instance, an industrial
solution for regenerative water energy plants has entirely different and sometimes even orthogonal non-
functional requirements and constraints on the layer that is responsible for the realization of the control
centre compared to the control devices for the gas turbine that are located on the lower levels of the
automation pyramid.
Different paradigms, different abstraction levels and varying non-functional requirements have lead to very
coupled and monolithic industrial solutions whose components are very hard to reuse and very hard to adapt
to new requirements as they are often (if not always) strongly coupled with other systems.
SOA4IS will develop a consistent and coherent methodology and appropriate technological foundations that
will allow to design and build industrial systems in a service-oriented manner on every layer of the
automation pyramid. In particular, SOA4IS will focus on new and existing development and modeling
techniques that are specifically suited for the different layers of the automation pyramid and also on how to
integrate and unify them to provide a consistent tool and modeling framework to build service-oriented
solutions.
Usually, Industrial Systems encompass a wide range of different hardware platforms with heavily varying
resource power and constraints, beginning from main frames with hundreds of Gigabytes of memory down
to Programmable Logic Controllers with only a few Kilobytes of memory. Consequently, there are usually
many different software platforms and solutions used in an Industrial System which were specifically and
isolated designed for a concrete hardware platform, resulting in a huge variety of strongly coupled and
different system interfaces and technologies used within a single Industrial System. As certain guarantees
about availability and predictability strongly depend on the according environment and thus change as a
function of the environment, components of contemporary industrial systems are often very hard to port to
other environments they were originally written for, thus dramatically lowering reuse. SOA4IS will
specifically address this portability challenge. As certain service level agreements are dependent on the
concrete underlying environment, it will also focus on self adapting services that automatically align their
service level agreement definitions to the capabilities of their hosting environment, thus increasing
portability. Additionally, SOA4IS will also define and develop new concepts and technological solutions for
constraint- and platform aware middleware platforms that will specifically address the challenge inherent to
the strongly heterogeneous system and application landscape of industrial solutions.
While most (if not all) research projects in the area of service-oriented architecture naturally only focus on
the software side, a holonic approach to tame the complexity and challenges of contemporary industrial
solutions must also explicitly address the hardware side. In particular, a true holonic service-oriented
approach implies to transfer these concepts also to the hardware domain in order to have the service-oriented
paradigm continuously applied on every layer including the field-level with controllers, sensors and
actuators. In contemporary industrial solutions, the hardware setup is completely static and does not provide
any means to be directly consumed as a service or to be integrated into a technical process. Usually, access
and integration means are only provided through a controller platform. SOA4IS will build the technological
foundations to enable to publish hardware as a service that can be consumed as a member of a service
composition and by software upper in the automation pyramid, especially technical processes. This will
allow to seamlessly integrate new hardware in a service-oriented manner, increasing loose coupling and
flexibility even on the hardware layer. Furthermore within this context, SOA4IS will also focus on new
service engineering methodologies and techniques with regards to hardware/software co-design. With
services becoming available also on chips, current services engineering practices have to be refined

Proposal Part B: page 6 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                      SOA4IS
regarding the partitioning of functionality and answering the question which services will be realized in
software and which ones on hardware.
There are a number of requirements that require breaking up the static structure of industrial systems and
replacing conventional programming paradigms with the service paradigm. Reasons are manifold: Industrial
systems steadily grow in size and complexity due to increasingly challenging customer requirements and
advancements in computational power. Simultaneously, there is a huge demand for (cost) efficiently building
and adapting industrial systems to ever changing customer requirements. Furthermore, complex use cases
increase the demand for integration between the different layers. The increased complexity requires location
transparency of control and supervision functionality within a system to support engineering processes,
which asks for a better integration and portability of functions between different layers or kinds of devices
within a layer. Last but not least, flexible markets and cost pressure demand rapid re-configurability and
updatability of system parts (without compromising safety and other industrially relevant NFRs). These
requirements motivate service orientation for all layers of the automation pyramid, in particular with an
increasing number of product variants and individual product customizations in mind. Within this context,
SOA4IS will assess current development techniques such as product line engineering, service engineering,
and verification and validation techniques with respect to which extent they meet these new challenges
inherent to industrial solutions and systems. It will assess, redefine and extent contemporary development
techniques mentioned above in order to provide a solid development basis to realize an implement industrial
solutions and systems in a service-oriented manner.


However, there are a number of challenges that up to now prevented SOA to enter the lower levels of the
industry automation domain:
     Service busses and call indirection impedes performance, e. g.
             o Protocol conversion overhead
             o Wordy wire formats
     Monolithic legacy SW
             o Communicating via shared memory
             o Hard-coded, invariant NFRs
             o Long-living APIs (> 10 years)
     Service lookup considered harmful
             o Compile-time configuration assumed
             o Start-up time constraints
     Memory footprint (<1MB for many, <10KB for some devices)
     …


Consequently, service platforms, which will have to be run on all these different kinds of devices, have to
shield the differences to integrate the services on the various layers, their programming models, and manage
the quality of service properties available on the device. So far, constraints in individual industrial domains
led to many different software platforms being developed for the individual domains and separate layers of
the automation pyramid. In order to benefit from service-orientation, we need a better integration of the
software while retaining the ability to tailor services and platforms to the domain’s characteristics.
Traditional engineering methodologies and platforms do not provide the required support to handle the
challenges mentioned above. The development of an open, scalable service platform for the specific needs
and challenges of industrial systems as described above and according techniques and methodologies for the
service-oriented building, integration and testing of highly critical systems is the main focus of SOA4IS.


1.1.21.1.3      Technical Challenges

Give an overview of the ideas that will be further elaborated in section 1.1.3. This should give the reader a
quick and great overview of the “what is this project”.


Proposal Part B: page 7 of 71
FP7-ICT-2009-5                                                           Integrated project proposal
30/07/09 v1                                                                                SOA4IS
1.1.31.1.4          Main Ideas Underlying the Vision

Detail the ideas that were described in section 1.1.2


1.1.41.1.5          Technical Approach: the SOA4IS Architecture

Give an overview of what an IS would be once the SOA4IS concepts applied. Each concept should appear
and explicit its role and the advantage it provides.
THE BIG PICTURE IN SHORT FOR THE CONSORTIUM:
We have moved towards the following big picture:
       -    At the bottom of the pyramid, hw- or sw-enabled service engines running data-oriented or technical,
            constrained services
       -    Some of them might include compositions
       -    On top of this, Technical Processes are run on TPM engines that might be distributed or run from a
            grid
       -    On top of this, Business Processes from the enterprise layer (thus running on servers, or in a
            grid/cloud) integrate technical processes to fulfil their mission (TPM are seen as a business partner in
            a typical BPEL script)
       -    Pervasive to the lower layers is the need for constraints (resources and time). All WP dealing with
            low layers will have to take this into account
       -    System monitoring is performed using low-level services. If needed an adaptation layer is run (at all
            levels) to adapt the system to environment changes (either physical environment, or constraints
            modifications, or customer, …)


1.1.51.1.6          Scientific and Technological Objectives

Id         S&T Objective              Description

I          Global System Architecture

           Definition of target       Background.
           reference architecture
I.1                                   Scope of Objective.
           for Industrial Service-
           Based Systems              A few lines + a bullet list of precise objectives

II         Technological Foundations

                                      Background.
           Models taking into
II.1       account resource and       Scope of Objective.
           real-time constraints
                                      A few lines + a bullet list of precise objectives

                                      Background.
           Ensuring Predictability
II.2       and Safety of mission-     Scope of Objective.
           critical Systems
                                      A few lines + a bullet list of precise objectives

II.3       Exposing hardware as       Background.


Proposal Part B: page 8 of 71
FP7-ICT-2009-5                                                         Integrated project proposal
30/07/09 v1                                                                              SOA4IS
Id      S&T Objective               Description
        Services
                                    Scope of Objective.
                                    A few lines + a bullet list of precise objectives

III     Management of Industrial Systems

                                    Background.
III.1   Monitoring Technology       Scope of Objective.
                                    A few lines + a bullet list of precise objectives

                                    Background.
III.2   Self-adaptation engine      Scope of Objective.
                                    A few lines + a bullet list of precise objectives

IV      Business and Technical Processes Management

                                    Background.
        Technical  Processes
IV.1                                Scope of Objective.
        Management
                                    A few lines + a bullet list of precise objectives

                                    Background.
        Business and Technical
IV.2    Processes Integration       Scope of Objective.
        Enablement
                                    A few lines + a bullet list of precise objectives

                                    Background.
        Current development
V                                   Scope of Objective.
        techniques
                                    A few lines + a bullet list of precise objectives

                                    Background.
        Product           Line
V.1                                 Scope of Objective.
        Engineering
                                    A few lines + a bullet list of precise objectives

                                    Background.
V.2     Service Engineering         Scope of Objective.
                                    A few lines + a bullet list of precise objectives

                                    Background.
V.3     Verification & Security     Scope of Objective.
                                    A few lines + a bullet list of precise objectives

                                 Table 1.1.a: Scientific & Technological Objectives




Proposal Part B: page 9 of 71
FP7-ICT-2009-5                                                        Integrated project proposal
                                                                                                                      Comment [VGR2]: Note: I am volunteerily
30/07/09 v1                                                                               SOA4IS                      ambitious in this part, and surely this needs to
                                                                                                                      be amended, but I believe this is how we wll
1.1.61.1.7       OLD: Project vision                                                                                  debate from the real outcome oft he project.


The concept of the project is to build “open, scalable service platforms” for critical systems where key
business, nation infrastructure or life is at stake. We believe that by using services at all software layers, from
the business perspective down to the individual chips on devices, we can build more scalable industrial
systems. Opening them to third-party services, where they are historically closed mostly for safety reasons,
will enable new forms of cross business usages.
Still, as we are conscious that these systems have a huge need for compliance, safety and dependability, we
will also provide novel support for verification and validation, using methodologies and formal methods that
have not yet been applied to service architectures.                                                                   Comment [VGR3]: I am adventurous here, a I
                                                                                                                      have no firm idea of existing SOTA. Support
To achieve these objectives, we will use the following strategy:                                                      needed from INRIA please.

1. Provide a consistent set of languages, meta-model and tools to model, specify, verify and validate
industrial systems. We will build on results from the COMPAS project, from past experience from
consortium partners, and from abstract patterns identified in NEXOF-RA.                                               Comment [VGR4]: Talking about INRIA here,
                                                                                                                      that’s for you Eric
2. We will apply our modelling methodology iteratively in an MDE fashion down to the embedded layers.
Our meta-model(s) will take into account specific constraints that will identified before as well as during the
course of the project.
3. The project will provide a framework that enables implementation of the modeled systems, including
generation of safe code, ie code that can be statically verified and validated, including against compliance          Comment [VGR5]: Or even prooved, if you
rules. Pervasive use of workflow languages and engines will be supported, and we will adapt the language as           feel comfortable with it
needed.
4. The framework will integrate smoothly with existing architectures like SCA, and must provide runtime
support to execute the software even on embedded chips.
In the course of this project, the pervasive stance will be service orientation. We believe that using service
orientation, with probably different, but compatible paradigms at different levels (for example functional
orientation and data orientation) will enable new forms of business and will open to innovation critical
systems and in particular their embedded parts.                                                                       Comment [VGR6]: Also I think we could talk
                                                                                                                      about how elevating the level of abstraction pf
TODO: add our position about real-time.                                                                               the hardware can facilitate exchanges, re-use or
                                                                                                                      partial re-use oft he offered services and the
                                                                                                                      integration into higher level processes




Proposal Part B: page 10 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS


1.2 Progress beyond the state-of-the-art

The fundamental challenge in the design of complex industrial systems, as outlined in Section 1.1, is the


1.2.1 Description of the State of the Art

Give a description of the SOTA in the following fundamental aspects of our project:
        Embedded systems architecture
        Technical Services Management
        Monitoring
        Product-Line Engineering
        Security and reliability


1.2.2 Differentiation between other related projects



1.2.3 Contributions beyond the State of the Art



1.2.4 Indicators for Measuring Progress

Target outcome      Project Level                                          Collaboration
                                                                           Activities
                    Target                                     Achieved    Target     Achieved

Title of            Qualification of the outcome in a few
expected            points.
outcome


                                       Table 1.2.a: Progress Indicators


1.2.5 Impact for Measuring Progress

Impact              Project Level                                          Collaboration
                                                                           Activities
                    Target                                     Achieved    Target     Achieved
Title of            Qualification of the outcome in a few
expected            points.
impact


                                         Table 1.2.b: Impact Indicators


Proposal Part B: page 11 of 71
FP7-ICT-2009-5                                                         Integrated project proposal
30/07/09 v1                                                                               SOA4IS


1.3 S/T methodology and associated work plan
                                                                                                                       Comment [VGR7]: I’ve made a fresh start
                                                                                                                       from the structure proposed by Stuart. I have
                                                                                                                       many work packages, some of which can be
1.3.1 Overall strategy and general description                                                                         merged surely. I prefer having too many WPs
                                                                                                                       and then regrouping them. I’ve tried to keep 1
                                                                                                                       essential topic per WP. I’m surely wrong on
The definition of the SOA4IS activities and work packages (WPs) has followed a methodology for the                     some points, feel free to correct mistakes or
definition of work packages that complies with the following rules:                                                    missing points.
                                                                                                                       Comment [VGR8]: I’ve made a fresh start
Each major challenge identified in section 1.1 has been mapped into a RTD activity (A1, A2, A3, A4, A5).               from the structure proposed by Stuart. I have
Each objective in the same table has been mapped into a WP within the corresponding RTD Activity.                      many work packages, some of which can be
                                                                                                                       merged surely. I prefer having too many WPs
A dedicated Activity (A6) has been defined which will be dedicated to Experimentation and Validation                   and then regrouping them. I’ve tried to keep 1
                                                                                                                       essential topic per WP. I’m surely wrong on
activities. This activity is carried out in parallel to activities A1 to A5 and will provide. It has been structured   some points, feel free to correct mistakes or
into several WPs, each one devoted to the experimentation and validation of a prototype application based on           missing points.
technologies developed in activities A1 to A5 Each of these prototypes is associated to a real-life scenario
provided by industrial partners. The experimentation activities will provide feedback to RTD activities along
the course of the project.
An additional Activity (A7) has been defined to deal with the Exploitation and Dissemination of Results.
This activity comprises WPs devoted to the analysis of the market and the promotion, based on this analysis,
of the results of the project to the scientific community, the standardization committees and the industrial
community.
A standard Activity (A0) dedicated to Project Management has also been defined.
Activity and Work Package leaders have been selected by their proven track record of excellence in the area
they have been chosen to lead.




                                          A1 – Transverse Activities




                                 A2 – Technical
                                  Foundations


          A0                                                     A5 - Impact on               A7
        Project                                                      current             Dissemination
                                 A3 – System
      Management                                                 Development             & Exploitation
                                 Management
                                                                  Techniques


                                 A4 – Systems
                                  Integration




                                      A6 – Experimentation & Validation



                                    Figure 2 - Relationship between Activities

Proposal Part B: page 12 of 71
             FP7-ICT-2009-5                                                                                                                                               Integrated project proposal
             30/07/09 v1                                                                     SOA4IS
             The relationship between the different Activities is shown on Figure 2. Note that the Exploitation and
             Dissemination will promote both the core technologies developed in SOA4IS as well as the implementation
             of these technologies in real-world scenarios.


             1.3.2 Timing of work packages and their components

             The project will run across a period of 36 months. This duration is considered appropriate in order to fulfill
             the objectives of the project. Below is the Gantt Chart corresponding to the project.
             TODO: project Gant Chart


          Months         1       2       3    4       5      6       7       8        9    10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
                                         Release of architetcure specification                                                                            Release of design and open specification reports
                                                                                   Release of software prototypes and scientific reports




                       global reqs and
                         architecture
                                                   Design                                                                 Design                                                                             Design
                                                                                                                                                                      Implementation                                                   Implementation
                                                                                  Implementation
     activity of R&D partner
                                                                                                                            Experiment support                                                                Experiment support

some companies typically
                                                           efforts are higher during first
participate in both kind of activities                                                                                                                more stable versions are released (bugs fixed and minor enhancement
                                                           part of experiment (fixing      initial version is released
through two separated teams                                                                                                                           implemented after first phase of experiment)
                                                           bugs, providing assistance, for experimentation
                                                           …)




                                                                                                            feedback                           feedback                              feedback                        feedback
     activity of integrator partner                                                                 (integrator perspective)               (user perspective)                (integrator perspective)            (user perspective)




                          global reqs and architecture                   scenario                                                                               scenario
                                                                                             experiment                                                                             experiment
                                                                         definition                                       scenario integration and              definition                                  scenario integration and
         a prototyped scenario is developed using technologies released at tasks in          preparation                                                                            preparation
         research WPs. Technologies are here experimented from the perspective                                           experimentation (involves                                                         experimentation (involves
         of a solution integrator. Bugs and enhacements are reported.
                                                                                                                           technology validation)                                                            technology validation)
                                                                                                                                                                         evaluation                                                      evaluation
                                                                                 Release of report on scenario defintion                                                      Release of report on evaluation and conclusions
                  the prototyped scenario is validated with assistance from final users.                                                       Release of report on integration and experimentation
                  Technologies are experimented from the perspective of the final
                  user. Bugs and enhacements are reported.




                                                                                                          Figure 3 - Life Cycle of Activities
             Figure 3 presents the expected lifecycle of the project activities for R&D partners and for integrator partners.




             Proposal Part B: page 13 of 71
FP7-ICT-2009-5                                                           Integrated project proposal
30/07/09 v1                                                                                    SOA4IS


1.3.3 Work packages list / overview

WP        Work package title                      Type of     Lead       Lead          Other       Person-    Start    End      Lead
No1                                               activity2   partic     partic.       partic.     months     month5   month5   Writer
                                                              no.3       short         no.3        4

                                                                         name

                                                 Activity 0: Project Management (Activity Leader: xxx)

WP0.1     Project Management                      MGT         1          SIEMENS                              1        36       SIEME
                                                                                                                                NS

                                         Activity 1: Transverse Technical Activities (Activity Leader: xxx)

WP1.1     Solution Architecture for Industrial    RTD         6          INRIA         1,2,3,4,               1        36       INRIA
          Systems                                                                      5,7,8

WP1.2     Alignment and Integration Planning      RTD         2          Thales        1,3,4,5,               6        36       THALE
                                                                                       6,7,8                                    S

                                   Activity 2: Technical Foundations of Industrial Systems (Activity Leader: xxx)

WP2.1     Hardware-based Services                 RTD         4          TIE           2                      4        36       TIE

WP2.2     Constrained Service Runtimes            RTD         1          Siemens       2,6,8,9                4        36       SIEME
                                                                                                                                NS

WP2.3     Service Composition Techniques          RTD         8          UPM           2,3,4,6                4        36       UPM

                                        Activity 3: Management of Industrial Systems (Activity Leader: xxx)

WP3.1     Monitoring of Industrial Systems        RTD         3          SAP           1,6,7                  4        36       SAP

WP3.2     Self-adapting Industrial Systems        RTD         1          Siemens       2,(3),4,               4        36       SIEME
                                                                                       (6),9                                    NS

WP3.3     Security                                RTD         2          Thales        7,(8)                  4        36       THALE
                                                                                                                                S

                                                 Activity 4: Systems Integration (Activity Leader: xxx)

WP4.1     Technical Process Management            RTD         1          Siemens       2,(3),4,6              4        36       SIEME
                                                                                       ,7,9                                     NS



1
        Workpackage number: WP 1 – WP n.
2
        Please indicate one activity per work package:
RTD = Research and technological development; DEM = Demonstration; MGT = Management of the
consortium; OTHER = Other specific activities if applicable in this call, including any activities to prepare
for the dissemination and/or exploitation of project results and coordination activities.
3
        Number of the participant leading the work in this work package.
4
        The total number of person-months allocated to each work package.
5
        Measured in months from the project start date (month 1).

Proposal Part B: page 14 of 71
FP7-ICT-2009-5                                                           Integrated project proposal
30/07/09 v1                                                                                   SOA4IS
WP4.2     Vertical Integration                    RTD         1         Siemens       2,3,4,6,               4   36
                                                                                      7

                                  Activity 5: Impact on Current Development Techniques (Activity Leader: xxx)

WP5.1     Product Line Engineering                RTD         7         Uni DUE       1,2,8                  4   36   UNIDU
                                                                                                                      E

WP5.2     Service Engineering                     RTD         1         Siemens       2,3,4,6,               4   36   SIEME
                                                                                      6,8                             NS

WP5.3     Verification & Validation               RTD         6         INRIA         (1),2,3,7              4   36   INRIA
                                                                                      ,8

                                         Activity 6: Experimentation and Validation (Activity Leader: xxx)

WP6.1     Hybrid Business Services                RTD         1         CLAAS         1,4                    7   36   CLAAS

WP6.2     Service    Marketplaces          for    RTD         1         SIEMENS                              7   36   SIEME
          Embedded Devices                                                                                            NS

WP6.3     Automatic Tramway                       RTD         2         THALES                               7   36   THALE
                                                                                                                      S

WP6.4     Business Activity Monitoring            RTD         3         SAP                                  7   36   SAP

WP6.5     On-chip Service Integration             RTD         4         TIE                                  7   36   TIE

                                                 Activity 7: Exploitation and Dissemination of Results

WP7.1     Market Analysis and Exploitation        RTD         2         Thales        1,3,4,5,               1   36   THALE
                                                                                      6,7,8,9                         S

WP7.2     Dissemination                           OTHER       8         UPM           1,2,3,4,               1   36   UPM
                                                                                      5,6,7,9

WP7.3     Standardization                                     5         IBM                                           IBM

          TOTAL
                                         Table 1.3.a: Work Packages List




Proposal Part B: page 15 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                   SOA4IS


1.3.4 Deliverables list

Table 1.3b:      Deliverables List


    Del. no. Deliverable name                                    WP no.                   NDissemi   Delivery
    6                                                                                     a-nation   date9
                                                                                          t
                                                                                           level
                                                                                          u8         (proj.
                                                                                          r
                                                                                          e          month)
                                                                                          7




                a)
                a)




6
         Deliverable numbers in order of delivery dates. Please use the numbering convention <WP number>.<number
of deliverable within that WP>. For example, deliverable 4.2 would be the second deliverable from work package 4.
7
        Please indicate the nature of the deliverable using one of the following codes:
        R = Report, P = Prototype, D = Demonstrator, O = Other
8
        Please indicate the dissemination level using one of the following codes:
        PU = Public
        PP = Restricted to other programme participants (including the Commission Services).
        RE = Restricted to a group specified by the consortium (including the Commission Services).
        CO = Confidential, only for members of the consortium (including the Commission Services).


9
        Measured in months from the project start date (month 1).

Proposal Part B: page 16 of 71
FP7-ICT-2009-5                                               Integrated project proposal
30/07/09 v1                                                                    SOA4IS




                                 Table 1.3.b: Deliverables list




Proposal Part B: page 17 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                   SOA4IS


1.3.5 List of milestones

Milestones are control points where decisions are needed with regard to the next stage of the project. For example, a
milestone may occur when a major result has been achieved, if its successful attainment is a required for the next phase
of work. Another example would be a point when the consortium must decide which of several technologies to adopt
for further development.
Table 1.3c List of milestones


Milestone Milestone                  Work         package(s) Expected date 10               Means                   of
number    name                       involved                                               verification11




                                              Table 1.3.c: List of milestones




10
     Measured in months from the project start date (month 1).
11
   Show how you will confirm that the milestone has been attained. Refer to indicators if appropriate. For example: a
laboratory prototype completed and running flawlessly; software released and validated by a user group; field survey
complet and data quality validated.

Proposal Part B: page 18 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS
                                                                                                                Comment [VGR9]: The participant listed in
                                                                                                                the section is for now the responsible fort he
                                                                                                                writing oft he proposal.
1.3.6 Work packages description

1.3.6.1 WPs linked to Activity 0: Project Management

Work package number         WP0.1       Start date or starting event:   M1                        End:    M36
Work package title          Project Management
Activity type               MGT
Participant number          1     2     3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE




Person-months per           X
participant


Objectives
This work package comprises activities related to the management of the project. The main objectives are:
       To establish an effective project management structure
       To encourage good interaction within the project and towards the EC
       To ensure compliance with project plans and that the project activities meet the appropriate quality
        levels
       To check and validate the correct scheduling of tasks
       To manage risks
       To perform overall legal, contractual, ethical, financial and administrative management of the
        consortium
       To co-ordinate Intellectual Property Right (IPR) and other innovation-related activities at the
        consortium level
       To manage science and society issues, related to research activities conducted within the project


Description of work
Task T0.1.1: Project administrative management
The main work will be to ensure the day-to-day management of the project and its progress; and report to the
project management committee and chair its meetings. The work package will work out a Project Quality
Plan (PQ Plan) and ensure its application. The PQ plan will give information and settle procedures that
define:
       To establish an effective project management structure
       Routines for progress reporting, quality control, documentation and decision-making.
       Routines for Project Plenary and Project Co-ordination Committee meeting with the objective of
        coordinating the project activities at all levels (work-package, project and external events)
       Routines and procedures for handling financial and legal matters towards EC and the individual
        Beneficiaries.
       Procedures ensuring than innovation related activities and IPR issues are professional handled

Proposal Part B: page 19 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS
Task T0.1.2: Technical management
This task is responsible for carrying out all the co-ordination, planning, management and control of project-
wide technical activities including the co-ordination of technical work between work packages. Day-to-day
technical management of individual work packages, including the co-ordination of work between activities
and sub-tasks of a work package is the responsibility of the WP leaders, with RTD effort allocated to that
WP. Additionally, this task will be responsible for monitoring the progress of the project against the
milestones listed in section 1.3.5.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Siemens will lead this work package and will contribute to task T0.1.1 by carrying out the
        coordination, planning, management and administration of non-technical activities
       XXXX will contribute to task T0.1.2 by helping in the coordination, planning, management and
        tracking against progress indicators of technical activities




Deliverables
     D0.1.1: Project Quality Plan (M2; 2,1 PM)
     D0.1.2: Project Activity Report, Period 1( M12; 2,5 PM)
     D0.1.3 Project Management Report, Period 1 (M12; 2 PM)
     D0.1.4: Project Activity Report, Period 2 (M24; 2,5 PM)
     D0.1.5: Project Management Report, Period 2 (M24; 2 PM)
     D0.1.6: Project Activity Report, Period 3 (M36; 2,2 PM)
     D0.1.7: Project Management Report, Period 3 (M36; 2 PM)
     D0.1.8: Final Report (M36; 2 PM)
     D0.1.9: Final Management Report for the full duration of the project (M36; 0,5 PM)
     D0.1.10: Final Activity Report for the full duration of the project. (M36; 1,6 PM)
     D0.1.11: Reporting questionnaires. (M36; 1,1 PM)




Proposal Part B: page 20 of 71
FP7-ICT-2009-5                                                              Integrated project proposal
30/07/09 v1                                                                                        SOA4IS
1.3.6.2 WPs linked to Activity 1: Transverse Technical Activities

Work package number            WP1.1           Start date or starting event: M1                     End:    M36
Work package title             Solution Architecture for Industrial Systems
Activity type                  RTD
Participant number             1     2     3      4      5     6      7     8  9
Participant short name
                               SIEMENS


                                         THALES




                                                                                           CLAAS
                                                                            UniDue
                                                                    INRIA




                                                                                     UPM
                                                              IBM
                                                  SAP


                                                        TIE


Person-months per
participant


Objectives
The objective of this work package is to define the overall guidelines to the project. This includes:
       To establish a clear state-of-the art of the project’s field, and to provide tools for it
       To define a consistent vision of the project objectives and concepts, shared and agreed by all
        partners, and to maintain and evolve it during the course of the project
       To specify the overall architecture of a Service-Based Industrial System and to define clear
        interfaces between the different layers
       To maintain and evolve this vision during the course of the project to adapt it to new challenges
        and/or emerging requirements
       To collect user requirements for SOA4IS based on use cases, partners and feedback from
        dissemination activities


Description of work
Task 1.1.1: State of the art
In order to share a same vision, the project consortium needs to share the same background. The goal of this
task is to collect those pieces of background that are relevant to the project, and make them available to the
consortium through a wiki for later usage. The addressed topics will include:
       Industrial domain background derived from the project case study
       Relevant academic knowledge for each work package
       Detailed statement of the problems yet to solve, from both academic and industrial sources, and their
        relevance to the project
These pieces of information will be collected by Activities 2 to 5 and contributed as an initial effort, but also
all along the course of the project.
Task T1.1.2: Build and maintain the vision
This task consists in ensuring that all partners share the same understanding of the project and work towards
the same goal. Il will build from the problems detailed identification collected in task T1.1.1 and provide the
overall objectives to the project, and the strategy of the project to solve these problems. A vision document
will be produced at the beginning of the project and will be amended as the project goes by, learning from
the knowledge gained in technical activities. This vision document will be in particular a guide to task T1.1.3
for defining the general architecture of service-based industrial systems.
Task T1.1.3: Service-Based System Architecture

Proposal Part B: page 21 of 71
FP7-ICT-2009-5                                                        Integrated project proposal
30/07/09 v1                                                                              SOA4IS
This task will focus on the specification of the general architecture, at a large, of a Service-Based Industrial
System. This architecture will be based on the project vision and will define the interfaces between low- and
high-level services, Technical Processes and Business Processes.
Task T1.1.4: Collect requirements for SOA4IS
This task consists in collecting requirements that will drive the research activities of the project.
Requirements will be elicited based on the analysis of the use cases, partner input, and solicited input from
dissemination activities. The purpose of this task will also be to elicit those requirements that the project will
not cover. .


Role of the partners:
Following is a short description of the role of partners involved in this WP:
       All partners will contribute user requirements input to task 1.1.4, and partners leading use case work
        packages (Siemens, Thales, SAP, TIE) will submit any requirement specific to their use case


Deliverables
     D1.1.1: state-of-the-art wiki, including domain glossary (M2: initial revision)
     D1.1.2: Case studies specification, initial revision (M3)
     D1.1.3: Requirements specifications, initial revision (M3)
     D1.1.4: Vision document and solution elements overview, initial revision (M3)
     D1.1.5: Case studies specification, reconsidered revision (M21)
     D1.1.6: Requirements specifications, reconsidered revision (M21)
     D1.1.7: Vision document and solution elements overview, final revision (M24)




Proposal Part B: page 22 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP1.2      Start date or starting event:   M6                        End:    M36
Work package title           Alignment and Integration Planning
Activity type                RTD
Participant number           1    2     3      4     5     6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per            X
participant


Objectives
This work package aims at ensuring that the different components developed in other work packages are
compliant with the reference architecture and complement each other to fulfil the SOA4IS vision. The work
will include close planning and tracking of the other development activities.
The work in this WP will proceed largely in parallel to the technical activities (A2, A3, A4 and A5) in order
to meet the time constraints of the project.


Description of work
Work in this WP is divided into several tasks corresponding to technical challenges that have been identified:

Task T1.2.1: Integration Plan (M6-M24)
The objective of this task is to create and maintain a live document to layout the integration points and
dependencies between the different work packages. It is the responsibility of each of the WP leaders to
periodically provide input to this document.
Task T1.2.1: Integrated Tool Chain
The objective of this task is to create and integrated tool chain based on existing tools compatible with the
Eclipse platform, which will be used as the base for the integration platform. This task will be performed
conforming to the integration plan to release periodic versions of the integrated tool chain.
Role of the partners:
Following is a short description of the role of partners involved in this WP:

   XXX will lead this Work Package
   All partners will participate to assure that the architecture is coherently designed, articulated and
    followed across the development and validation partners. Partners involved in WP producing tools will
    contribute with tools in their field of expertise.


Deliverables
   D1.2.1: Integration Plan (IR) – (M6, M12, M18, M24, M30, M36)
    This internal report will be produced 3 months after all WPs have started, will be updated to reflect
    status and new dependencies every 6 months
   D1.2.2: Integrated tool chain (P) – (M12, M24, M36)



Proposal Part B: page 23 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS
1.3.6.3 WPs related to Activity 2: Technical Foundations of Industrial Systems

Work package number          WP2.1      Start date or starting event:   M4                        End:    M36
Work package title           Hardware-based services
Activity type                RTD
Participant number           1    2     3     4      5     6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE


Person-months per                                     X
participant


Objectives
The purpose of this work package is to build the technological foundations to enable to publish hardware as a
service that can be consumed as a member of a service composition (as researched in WP2.3) and by
software upper in the automation pyramid, especially Technical Processes (as of Activity 4). This includes:
       TO BE COMPLETED
    


Description of work
TO BE ELABORATED.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       TIE will lead the work package


Deliverables
    




Proposal Part B: page 24 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS

Work package number          WP2.2       Start date or starting event:   M4                        End:    M36
Work package title           Constrained Service Runtimes
Activity type                RTD
Participant number           1     2     3     4     5      6     7    8    9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE
Person-months per                       X
participant


Objectives
The purpose of this work package is to develop service runtimes that are compatible with the constraints that
embedded systems must endure. This includes:
       To define a service component architecture that takes into account time and resource constraints
       To implement a framework for exposing data-oriented services in a constrained environment
       To use the relevant patterns from NEXOF-RA and to apply them to constrained environments


Description of work
                                                                                                                 Comment [VGR10]: I’m not comfortable with
Task T2.2.1: Architecture patterns                                                                               this one. We (Thales) want to do it, but I think
                                                                                                                 this task could also be merged with WP24
The purpose of this task is to refine abstract patterns coming from NEXOF-RA and adapt/refine them to the        (which would thus be renamed Architecture
specificities of the embedded domain. This will include in particular to see                                     patterns and come before this one)
                                                                                                                 Comment [VGR11]: I’m not comfortable with
Task T2.2.2: Component Architectures Evaluation                                                                  this one. We (Thales) want to do it, but I think
                                                                                                                 this task could also be merged with WP24
State of the art and comparison with respect to service characteristics elaborated in Activity 5.                (which would thus be renamed Architecture
                                                                                                                 patterns and come before this one)
Task T2.2.3: Component Architecture Specification
Development of reference component architecture with the associated meta-model.
Task T2.2.4: Framework implementation
This framework will include tools and platforms enabling the design and the assembly of components and
composites, for the construction of the service-oriented architecture of industrial systems. This framework
will examine the integration with some existing technologies based on new standards such as SCA.
Role of the partners
Following is a description of the role of partners involved in this WP:
       Thales will contribute to all tasks


Deliverables
     D2.2.1: Architecture patterns system
     D2.2.2: Component Architectures evaluation report
     D2.2.3: Component Architecture specification
     D2.2.4: Framework implementation




Proposal Part B: page 25 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP2.3      Start date or starting event:   M4                        End:    M36
Work package title           Service Composition Techniques
Activity type                RTD
Participant number           1     2    3      4    5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per
participant


Objectives
The purpose of this work package is:
       To implement engineering techniques and software artifacts that enable the static and/or dynamic
        computation of the SLAs of a low-level service composition (especially when real-time services are
        involved)
       To define how services at low level will communicate together
       To implement a prototype middleware software to enable services communication
       To define how to compose data-oriented services


Description of work
Task T2.3.1: Composition SLAs
The purpose of this task is to define models to describe how the composition of low-level, resource- and/or
time-constrained services reflects on the SLA of these services. Attention will be paid to the static and/or
dynamic computation of the composition’s SLA, but also to how the involvement of a service into a
composition can affect its SLAs.
Task T2.3.2: Data mash-ups
Service mash-ups are an emerging technique to produce new interfaces from the composition of services that
had not been initially designed to co-operate. The purpose of this task is to apply the same techniques to data
fusion algorithms, using data-oriented services. This task will focus on:
       Static description of data mash-ups
       Software to run these mash-ups
       Dynamic composition at runtime
Task T2.3.3: Communication middleware
This task will implement how services at low level will integrate with services at high level. This integration
will be based on the SOA paradigm and rely on a SOA prototype middleware for enabling an agile
communication between services (including Grid and Cloud computing oriented technologies).
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Thales will contribute on tasks T2.3.2 and T2.3.3 by providing data mash-ups specification and
        communication middleware



Proposal Part B: page 26 of 71
FP7-ICT-2009-5                                             Integrated project proposal
30/07/09 v1                                                                  SOA4IS
Deliverables
     D2.3.1: SLA model specification
     D2.3.2: Data mash-up language and runtime
     D2.3.3: Prototype service communication middleware




Proposal Part B: page 27 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS
1.3.6.4 WPs related to Activity 3: Management of Industrial Systems

Work package number         WP3.1      Start date or starting event:   M4                         End:    M36
Work package title          Monitoring
Activity type               RTD
Participant number          1    2     3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE


Person-months per
participant


Objectives
The main Objective of this work package ensuring predictability and reliability of distributed, hosted and
cloud based systems industrial systems on all level of the system pyramid based on system monitoring and
robust system reconfiguration applying validation and testing methodologies during runtime.
[Objective 3.1.1] Automated and human system landscape monitoring]
The execution of Industrial Systems needs to be monitored to ensure continuous service delivery and quality.
The increasing complexity and size of industrial SOA systems requires new ways of combined human and
automated monitoring and system adaptation/reconfiguration. Therefore the work package develops a
methodology and tools for monitoring, controlling and adopting Industrial SOA-based systems to changing
system landscapes.
[Objective 3.1.1.1] Human monitoring – SOA control centers]
Control centers are known concepts for monitoring industrial plants such as energy plants. SOA enabled
system increase the level detail and control and thus the potential to support engineers in monitoring large
scale industrial systems. For example future energy networks with distributed energy production and
consumption are expected to be bigger - in terms of nodes producing energy such as solar collectors - and
more     intelligent    -    in   terms    of     node     a)    using    and      b)    producing     energy.
The increase complexity and size of nodes monitored SOA enabled industrial systems that lead to more
means of controlling and adapting industrial systems requires new concepts for friendly system monitoring
and advanced control and adaptation that scaling for allow levels of the production pyramid, including the
“high level” processes down to “low level” sensors. In addition system adoption and reconfiguration needs to
save so the overall process and system remain robust. Therefore validation / testing and simulation tools need
to become available for system engineers. (details described below)
[Objective 3.1.1.2] Automated monitoring – Complex Event Processing]
As the expected size and complexity of SOA enabled industrial systems is increasing, intelligent automation
will be required to support engineers monitoring the systems. Automation method aggregates information
from lower system levels, trigger system adoptions steps or in case of “exceptions” inform engineering about
issues via a control center. Flexible and adoptable automation and 24x7 system availability will be ensured
by combining methods from Complex Event Processing and SOA based systems to allow research on
automated adoption (e.g. reconfiguration …) based on events and event processing.
[Objective 3.1.2 ] Ensure system robustness]
Besides the need for high quality software the overall system must be robust during runtime and when it
evolves to support new requirements. This can be archived by testing, system validation and simulation that
are addressed in this Work package. Well know and proven methods from lower level hardware engineering
in testing validation and simulation will be leveraged to and combined with method from ERP.



Proposal Part B: page 28 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS
[Objective 3.1.2.1] Ensure system robustness – Testing and validation]
To ensure the overall system robustness, SLAs and methods from development time testing and validation
described in WP?? need to be used when adopting. Especially when (re-) designing industrial system lower
machine and sensor level hardware are very often designed to a detail level that supports validation and
testing thru simulation before the hardware is finally produced or configured. Also higher level services such
as ERP is certainly tested before it is released to customers. However those assets currently remain used after
development finishes, while there is a huge potential to contribute to the overall system robustness during
system reconfiguration at runtime. SOAIS will investigate development assets from each abstraction level
that are also useful for system adoption to retrieve patterns and develop methods on how to use them for
system monitoring and adoption. Tools will be developed and integrated into monitoring environments for
human and automated adoption.
[Objective 3.1.2.2] Ensure system robustness – System Simulation]
Simulation of industrial systems is especially important for system engineers when reconfiguring industrial
system to understand if changes solve a problem or reflect new requirements before applying the changed to
the real system. Again simulation tools are available from lower hardware levels, but also on ERP level that
are currently isolated while combining them may results in more realistic simulations. For example a
combining higher level process simulating with uses lower level services simulation via service interfaces
gives a more realistic picture of the overall system. Tools will be developed and integrated into monitoring
environments for human and automated adoption.


Description of work
Task T3.1.1: Monitoring
The purpose of this task is to investigate existing monitoring and control center practices as well as the use
case form WP12 to elicit requirements for service monitoring tools and service monitoring control centers.
TODO: put more here
This task aims at designing and developing a tool suite for monitoring and managing of services and
processes across the different layers of the automation pyramid. This task will too provide support for the
interpretation of provenance information. The tool suite will provide real time monitoring and management
of services and processes at different levels of abstraction, spanning from the technical details (at
infrastructure level) to higher-level information (at business level). The tool suite will be enhanced with and
will provide the contextual information (e.g., QoS), so as to better support the adaptive management and
traceability of the overall service delivery taking into account aspects such as user preferences, service
provenance, service policies and service level agreements.
       PEL UCD contributions:
       Low Overhead monitoring for SOA
       Adaptive/Dynamic monitoring
       Tracing Distributed Services in adapting systems landscapes
       Technology independent monitoring for Services containing various technologies
       Service Design Extraction/Reverse Engineering/Model Extraction from Tracing service component
        interactions
Task T3.1.2: System landscape adoption
The goal of this task is to find patterns for adapting system landscapes. TODO: put more here

                                                                                                                  Comment [AS12]: If we keep simulation
Task T3.1.3: : Landscape integrity testing (and simulation)
                                                                                                                  Comment [AS13]: If we keep simulation
The goal of this task is to define methodology that supports Landscape integrity testing (and simulation) for

Proposal Part B: page 29 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                        SOA4IS
service-based industrial systems. Based on the findings on testing from WP 25 test patterns to ensure the
integrity of service-based systems in case of adoption will be indentified and ways of applying those tests
when adopting the system landscape will be researched.
PEL UCD contributions:
       Simulation of services in adapting systems landscapes
       Performance testing and verification for service based industrial systems
       Reliability testing techniques for service based industrial systems
Task T26.4: Event processing for adoption automation
While manual monitoring and adoption of system landscapes is researched in Task 26.1 this tasks focuses on
possibilities for automated issue detected based on advances event processing technologies that lead to
automated landscape adoption based on results from Task 26.2 and Task 26.3
PEL UCD contributions:
       Automatic problem detection in adapted Services using Expert Knowledge
       Design antipatterns
       Low level performance issues
       Memory Issues
       Tuning Issues
       Log Errors
       Real Time Event Correlation and Symptom Matching of Known Issues
       Use of Data Mining techniques for automatic identification of patterns of interest in Service event
        data


Role of the partners
Following is a description of the role of partners involved in this WP:
    


Deliverables
       D3.1.1: Report of results from T3.1.1
       D3.1.2: Report of results from T3.1.2
       D3.1.3: Report of results from T3.1.3
       D3.1.4: Report of results from T3.1.4
       D3.1.5: Prototype(s)




Proposal Part B: page 30 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP3.2        Start date or starting event:   M4                      End:    M36
Work package title           Self-adapting Industrial Systems
Activity type                RTD
Participant number           1     2      3     4      5     6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per
participant


Objectives
TODO: describe objectives linked to self-adaptation, in their unique specificities for industrial systems.




Description of work
Task T3.1.1: Monitoring
    


Role of the partners
Following is a description of the role of partners involved in this WP:
    


Deliverables
       D3.2.1:
    




Proposal Part B: page 31 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                          SOA4IS

Work package number         WP3.3               Start date or starting event:           M4            End:    M36
Work package title          Security
Activity type               RTD
Participant number          1     2             3     4     5      6       7        8        9
Participant short name
                             SIEMENS


                                       THALES




                                                                                             CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                SAP


                                                      TIE
Person-months per
participant


Objectives
One of the key aspects of industrial systems is that they are often mission-critical. Sometimes it is because
human lives are at stake (transportation system, tomographs, scanners, …), sometimes they provide key
national infrastructure missions (signaling systems, nuclear plants, …), sometimes they are key to successful
business (automated factories, automatic mail routing systems, ERP systems, …).
Historically much of these systems have been closed. As the use of the SOA paradigm is expected to bring
increased re-use of components and services from third-party partners, it is essential to provide a robust
security framework to protect those systems from the new threats that will be introduced by this opening to
the world.
The purpose of this work package is to:
       Identify the new threats (and not the existing ones) that service-based industrial systems will be
        facing and describe them in a consistent fashion. These threats may be external to the systems but
        also internal, coming from their very structure.
       Qualify the risks and rate them to allow comparing them
       Provide answers to the most important threats
       Provide a secured infrastructure in support for service-based industrial systems




Description of work
Task T3.3.1: Identify the threats
The purpose of this task is to build a catalogue of risks and threats induced by the comprehensive use of the
SOA paradigm in all layers of an industrial system. Typically, systems like SCADA operate in a closed and
controlled environment. This task will have to enumerate and describe the new threats that the service
orientation brings. For each threat, the catalogue will provide the following items:
       Name and description
       Qualification
       Threat level
       Known existing remedies, be they partial or not
Task T3.3.2: Security patterns
Based on the threats identified in task T3.3.1, but also on architectural patterns referenced in the NEXOF-RA
project, this task will elaborate new patterns of architecture to answer the threats and risks of industrial
systems. Some of these patterns will be implemented.                                                                Comment [VGR14]: TODO: elaborate



Proposal Part B: page 32 of 71
FP7-ICT-2009-5                                                       Integrated project proposal
30/07/09 v1                                                                            SOA4IS
Task T3.3.3: Role-based Access Control
The usage of services and business processes is highly correlated with the notion of role. In a collaboration
(business process, service composition, …) each partner plays one or more roles, and in critical systems it is
vital to:
       Assess the identity of the partner
       Provide a flexible yet secure way of associating roles to identities
       Map granted authorizations with roles.
This task will study and implement the necessary infrastructure to provide these services, based on the
LibertyAlliance specifications for identity management and on the Role-Based Access Control for roles and
authorization management.
A survey will be led first to evaluate the needs for role management in the lowest layers, based on the results
of Activity. An RBAC infrastructure will then be setup in support for the Case Studies. For this particular
aspect, we intend to reuse results from the PERMIS project, which delivered an implementation of the X.509
framework.


Role of the partners
Following is a description of the role of partners involved in this WP:
       Thales will lead the work package and contribute to all its tasks


Deliverables
       D3.3.1: repository of threats with their rating and classification
       D3.3.2: Collection of security patterns
       D3.3.3: RBAC survey
       D3.3.4: RBAC implementation




Proposal Part B: page 33 of 71
FP7-ICT-2009-5                                                                Integrated project proposal
30/07/09 v1                                                                                          SOA4IS
1.3.6.5 WPs related to Activity 4: Systems Integration Management

Work package number              WP4.1       Start date or starting event:   M4                       End:    M36
Work package title               Technical Business Processes
Activity type                    RTD
Participant number               1    2      3     4     5      6     7    8    9
Participant short name
                                 SIEMENS


                                           THALES




                                                                                             CLAAS
                                                                              UniDue
                                                                      INRIA




                                                                                       UPM
                                                                IBM
                                                    SAP


                                                          TIE


Person-months per
participant


Objectives
The purpose of this work package is to bring workflows to the lower levels of the automation pyramid. We
call these workflows technical processes in opposition to business processes, because we claim that these
processes will be more data-oriented or control-oriented than business oriented: they model complex service
choreographies necessary for the system to fulfill a technical mission that is itself used in higher–level
business functions. The main objectives are:
       To develop a meta-model for modeling technical processes, in particular modeling time and resource
        constraints
       To implement engines to run these models by all suitable means:
              o   Interpretation
              o   Code generation
              o   Distribution


Description of work
Task T4.1.1: Technical Processes Meta-model
This task will focus on the modeling of Technical Processes. A meta-model will be derived from existing,
standard meta-models like BPMN or BPEL. One of the main purposes of this task will be to integrate model
elements for hardware as a service, to take into account the data orientation and to model time and resource
constraints. Attention will be paid to the compatibility between this meta-model and the one developed in
Activity 5, in particular partners will ensure that the formal validation requirements are taken into account.
Partners in this task will also work on meta-model-based transformations in order to generate architectural
and deployment artifacts (thus bridging process definitions with the execution infrastructure) and also to
transport data to the monitoring framework (WP3.1).
Task T4.1.2: Modeling environment
The purpose of this task is to extend existing, Eclipse-based modeling environments (such as the Eclipse
SOA environment) to be able to use the meta-model developed in task T4.1.1.
Task T4.1.3: Runtime choreography
The objective of this task is to implement a concrete runtime for executing technical processes on embedded
devices. Different techniques will be experimented:
       Embedding a workflow engine in a chip or its firmware. This will be done in collaboration with
        WP2.1.
       Enable the distribution of a BPEL execution, supported by Grid oriented technologies. The

Proposal Part B: page 34 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                       SOA4IS
       application of such a feature for a large number systems involved in the embedded domain will be
       studied
       Generating code to target devices


Role of partners
Following is a description of the role of partners involved in this WP:
    


Deliverables
     D4.1.1: Technical Processes Meta-Model (R)
     D4.1.2: Technical Processes Modeling Tools (P)
     D4.1.3: Execution Infrastructure Report (R)
     D4.1.4: Execution Infrastructure Prototype (P)




Proposal Part B: page 35 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP4.2        Start date or starting event:   M4                      End:    M36
Work package title           Vertical Integration
Activity type                RTD
Participant number           1     2      3      4    5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per
participant


Objectives
The purpose of this work package is to study the suitable techniques to integrate high-level business
processes (ERP or enterprise processes) with low-level technical processes.


Description of work
TODO: ELABORATE


Role of partners
Following is a description of the role of partners involved in this WP:
    


Deliverables
    


1.3.6.6 WPs related to Activity 5: Impact on contemporary development techniques

Work package number          WP5.1        Start date or starting event:   M4                      End:    M36
Work package title           Product-line Engineering
Activity type                RTD
Participant number           1    2       3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE




Person-months per
participant


Objectives
The purpose of this work package is to adapt current product-line engineering techniques that have been
successfully applied in the enterprise domain in the field of industrial systems.
    


Proposal Part B: page 36 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS
Description of work
Task T5.1.1: Variability Engineering Methodology
The purpose of this task is to develop means for analyzing and specifying service variability points in the
context of Industrial Systems. As many projects have already produced successful contributions to this
domain in the field of enterprise and B2B applications, this task will focus on the necessary adaptations for
the context of Embedded Product Lifecycle Engineering.


Role of the partners
Following is a short description of the role of partners involved in this WP:
    




Proposal Part B: page 37 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP5.2       Start date or starting event:   M4                       End:    M36
Work package title           Service Engineering
Activity type                RTD
Participant number           1     2     3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per                      X
participant


Objectives
The purpose of this work package is to define service engineering assets that are specific to the field of
Industrial Systems. This includes:
       To define methods and techniques to break down low-level functionalities usually implemented in
        firmware or hardware into services
       To establish a typology of the services that can exist at low level
       To develop an integrated meta-model for services modeling at all levels of the automation pyramid


Description of work
Task T5.2.1: Service Engineering Methodology
The purpose of this task is to identify new assets of methodology suitable to the engineering of services for
Industrial Systems. This includes extending existing software/hardware co-design techniques to be distribute
service functionality between hardware and software, based on operational requirements like the need for
reconfiguration, the need for performance and other requirements that will be identified as part of this task
Task T5.2.2: Holistic Services Meta-Model
The purpose of this task is to specify and implement a meta-model (M2) for modeling services in a uniform
and consistent way at all levels of the automation pyramid. This meta-model will especially incorporate
constraints specification elements for real-time constraints (communication time boundaries, execution time
limits, etc.) and resourced constraints (memory footprint, CPU load, etc). These constraints will be used in
particular in Activity 2 to compute dynamic SLAs.
This meta-model will be derived from existing meta-models such as SoaML, that is used in enterprise
services modeling, or the MARTE UML profile, used in real-time system modeling.
Task T5.2.3: Tools
This task will implement the tools needed to exploit the meta-model defined in task T5.2.2. These tools will
be based on existing tools compatible with the Eclipse platform, e.g. interoperability and/or integration with   Comment [ 15]: Why are we only focusing on
the toolset developed in the Eclipse SOA Tooling Platform will be considered, as well as with some BPM-          the Eclipse platform? IMO, this is too restrictive.
oriented Eclipse design tooling (BPMN, BPEL, ).
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Thales will contribute on task T5.2.2 by providing quality attributes and constraints related to time
        and resource constraints




Proposal Part B: page 38 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS

Work package number          WP5.3       Start date or starting event:   M4                        End:    M36
Work package title           Validation and Verification
Activity type                RTD
Participant number           1     2     3     4       5    6     7    8    9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE
Person-months per
participant


Objectives
One of the key characteristics of Industrial Systems is their need for predictability and reliability, especially
when human lives are at stake. The purpose of this work package is to develop a tool suite and associated
methodology for validating Industrial SOA-based systems, using complementary techniques, ranging from
formal verification to testing.
Validation methods rely on design-time specifications, which encompass functional and behavioral
descriptions, as well as contractual requirements (including real-time constraints). The challenge here will be
to extract from existing state-of-the-art formalisms the parts that are relevant to the project, some coming
from the services area (e.g. SoaML, BPMN…), others from the embedded system world (typically Marte),
and to integrate them in a coherent and useful manner..
Formal verification is the most abstract method for assessing reliability. For SCA-based applications, it can
be used to prove statically that service components behave correctly, that their assembly is correct, deadlock
free, or even to check safety and liveliness properties (derived from contracts or from functional user
requirements). For embedded application, it ensures also predictability of the system components behavior,
including their real-time constraints. Existing tools from both communities will have to be adapted and
integrated to deal with SOA Industrial systems.
Formal verification is always conducted on an abstract version of the system, not on its concrete
implementation. It is usually complemented by testing, that is able to assess the compliance of the
implementation with the specification. Test generation can be automated, based on the same specifications as
verification.


Description of work
Task T5.3.1: Modeling formalisms and Indicators elicitation
The purpose of this task is to define a formalism integrating the synchronous and real-time constraints of the
embedded layer with the service oriented contracts of the business level. It will also identify the relevant
indicators to assess the quality and predictability of an Industrial SOA, relying on the Quality of Service
attributes identified in WP5.2. The possibility to extract relevant parts of MARTE and adapt them to SoaML
or BPMN should be explored.
Task T5.3.2: Verification methodology and tools
The goal of this task is to define a verification methodology for service-based industrial systems. Based on
our experience with distributed component-based applications (from the outcome of the GRIDCOMP
project) and with the modeling of embedded systems (MARTE), we shall extract the non-functional
properties and real-time constraints attached to the embedded layer and feed them into adequate verification
tools (TimeSquare, Vercors). The results from the verification should then be brought back into the service
layer model
Task T5.3.3: Test methodology

Proposal Part B: page 39 of 71
FP7-ICT-2009-5                                                       Integrated project proposal
30/07/09 v1                                                                             SOA4IS
The goal of this task is to define a test methodology for service-based industrial systems. Based on past
experience on testing, we will refine existing techniques and adapt them to the constraints of Industrial
Systems. In particular, this task will focus on identifying test patterns to ensure the reliability of service-
based systems.
Task T5.3.4: Automated test generation
The purpose of this task is to generate tests based on the meta-model developed in extend, research and
formalize the concepts of contracts developed in Activity 2 to support the automatic generation of tests,
taking into account the following aspects:
       Norm compliance and variation of norms/compliance level between countries
       Functional Coverage of the generated tests
       Reliability insurance
                                                                                                                    Comment [I16]: [OR] We have a lot of
Task T5.3.5: Simulation at design-time                                                                              experience in developing cost-effective
                                                                                                                    simulation techniques. This supports mainly unit
This task focuses on extending and reusing existing strategies in the field of HW programming, to the level         tests. It would be interesting to apply these
of service programming. The task will produce or extend existing tools to simulate critical parts of the            techniques to this domain. Another interesting
systems to be modeled at design time. Particular focus will be put on ensuring the global reliability and           topic to investigate would be whether such
                                                                                                                    techniques could assist during design.
resilience of the system.
Task T5.3.IBM.1: Test space modeling and reduction
The goal of this task is to provide techniques to assist in identifying important aspects of service-based
industrial systems that should be tested. Formal methods provide an essential solution for targeted parts of a
system but cannot provide a solution for the entire system. Such methods need to be complemented with
testing techniques. Unfortunately, the complete space of tests is prohibitive. We shall build on our
experience in test design and enhance our existing functional coverage and combinatorial test design
techniques and tool (FoCuS) to address the problem of test space modeling and reduction for service based
industrial systems.
Task T5.3.IBM.2: Testing for scalability
The goal of this task is to develop techniques for cost-effective simulation that would enable testing in
isolation of important software components of service-based industrial systems. We shall build on our
experience in creating SSS (smart system simulation) technologies for the embedded systems domain. This
task will also generalize and define SSS methodologies that are applicable to the service-based industrial
systems domain.
Task T5.3.IBM.3: Measuring the coverage of service guarantees
The goal of this task is to develop technologies and methodologies for testing service guaranties that can
change as a function of the environment (e.g., the type of network connections). We will explore the use of
our functional coverage technology to assist in defining the space of all possible service guaranties states test
them
Role of partners
Following is a description of the role of partners involved in this WP:
       Thales will contribute to task T5.3.1 and T5.3.4 by designing constraints for compliance and
        contributing to the automated test generation software


Deliverables
    




Proposal Part B: page 40 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS
1.3.6.7 WPs related to Activity 6: Experimentation and Validation

Work package number          WP6.1        Start date or starting event:   M7                       End:    M36
Work package title           Scenario – 1: Hybrid Business Services
Activity type                RTD
Participant number           1     2      3     4     5      6     7    8    9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE


Person-months per
participant


Objectives
This WP provides use cases dealing with the integration of high-level business processes in the field of
harvesting and forage with low-level information originated at on-field equipments. It exploits the
integration architecture developed in this project, the complex event processing infrastructure and the
dynamic reconfiguration facilities.


Description of work
Task T5T6.1.1: Scenario Definition(M7-M12) (M19-M24)
$$$$ Include here general information about the use case context. I put a very general description here.
Today’s information technology provides efficient and powerful mechanism to integrate complex business
flows including software and human interactions. In the field of harvesting, this includes processes such as
creating a bill for a harvesting session, collecting statistics about the activities or monitoring and organizing
storage.
However, the processes described above present the following challenges, that SOA4IS aims at resolving:
    Automation of backend business processes by collecting and integrating information from on-board
      systems
    Integration of context information to deal with the lack of permanent network cover
    Use of on-board workflows to deal with the optional or necessary human interaction


Two scenarios will be studied:
    Bill creation: harvesting machines collect information based on sensors like GPS antennas and send
       data to the backlog, where the bill for harvesting is automatically created
    Machine communication: machines on field exchange their position and status in order to optimize
       the harvesting and storage process. Data is sent to the backend to prepare the storage and optimize
       harvesting tasks


Task T6.1.2: Integration and Experimentation (M10-M18) (M22-M30)
The main objectives of this task are:
       $$$$ Describe the main tasks that will be performed to use the results of the project
Task T6.1.3: Evaluation and Conclusions (M19-M24) (M31-M36)
Describe the main parts of the project that your Use Case will evaluate, and the impact of the conclusions in
your domain of application.


Proposal Part B: page 41 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                            SOA4IS
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Siemens will lead the Work Package and will contribute by designing the scenarios and the relative
        experiments; and testing and validate meaningful concepts.
       Claas will provide the baseline technology and will contribute to all the tasks by helping in the
        scenario definition and in the integration and evaluation of the experiment


Deliverables
   D6.1.1 Scenario–1 Hybrid business services: scenario definition (IR) (M12, M24)
   D6.1.2 Scenario–1 Hybrid business services: integration and experimentation (D) (M18, M30)
   D6.1.3 Scenario–1 Hybrid business services: evaluation and conclusions (R) (M24, M36)




Proposal Part B: page 42 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP6.2        Start date or starting event:   M7         End:                 M36
Work package title           Scenario – 2: Service Marketplaces for Embedded Devices
Activity type                RTD
Participant number           1     2      3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per            X
participant

Objectives

Describe the objective of this work package in a few sentences, introducing the main concepts that will be
demonstrated by this use case.


Description of work
Task T6.2.1: Scenario Definition(M7-M12) (M19-M24)
Describe your scenario and its main challenges it brings.
Task T6.2.2: Integration and Experimentation (M10-M18) (M22-M30)
Describe the main expected steps to realize your Use Case and how this will integrate into the whole project
implementation.
Task T6.2.3: Evaluation and Conclusions (M19-M24) (M31-M36)
Describe the main parts of the project that your Use Case will evaluate, and the impact of the conclusions in
your domain of application.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Siemens will lead the Work Package and will contribute by designing the scenarios and the relative
        experiments; and testing and validate meaningful concepts.


Deliverables
   D6.2.1 Scenario–2 Service marketplaces for embedded devices: scenario definition (IR) (M12, M24)
   D6.2.2 Scenario–2 Service marketplaces for embedded devices: integration and experimentation (D)
    (M18, M30)
   D6.2.3 Scenario–2 Service marketplaces for embedded devices: evaluation and conclusions (R) (M24,
    M36)




Proposal Part B: page 43 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS

Work package number          WP6.3        Start date or starting event:   M7                       End:    M36
Work package title           Scenario – 3: Automatic Tramway
Activity type                RTD
Participant number           1     2      3     4     5      6     7    8    9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE
Person-months per                       X
participant

Objectives

The objective of this WP is to design and develop a scenario in order to experiment and validate concepts
that the SOA4IS project will provide, illustrating how the technologies developed in the activities can be
applied to a real life application. It will focus in particular on the component technology, the definition of
workflows and the security technology.



Description of work
Task T6.3.1: Scenario Definition (M7-M12) (M19-M24)
This task will handle the design of the scenario. The scenario is described from the point of view of the
system integrator. This allows capturing information about requirements for the SOA4IS conception.

The scenario illustrates a typical highly-complex System-of-Systems (SoS) that can be found in the domain
of transportation. A tramway is made of many sub-systems that perform various tasks: controlling the
different parts of the equipment (wheels, brakes …), displaying information to the travelers, discussing with
the on-track equipments and sensors, sending information to and receiving instructions from the traffic
regulation system. Each sub-system is very different from the other and has an architecture that is dedicated
to the task it performs.

A very important aspect is the integration of the various sub-systems. They work at various level of
abstraction and must integrate with various internal and/or external services, which raises the following
challenges:
     Real-time data management: Inner sensors and on-track equipments such as red/green lights emit
        data that the vehicle must handle real-time. There can be a huge discrepancy in the throughput and
        occurrences of such events, but various controller sub-systems must treat this information quickly
        and reliably. Additionally, data, from various sub-subsystems must be fused and sent to the vehicle
        controller and/or to the traffic regulation system.
     Asynchronous events integration: automated transportation vehicles must talk with regulation
        algorithms at the transportation network level. These regulation processes include complex
        regulation workflows that must be handled by the vehicle.
     On-board Information System: in addition to the technical services, a transportation vehicle also
        includes an information system that is able to display next station information and other information
        useful to travelers. This system must integrate with the track’s information system and with events
        inside the vehicle.
     Limited resources: some sub-systems (such as controllers from the MES layer) have limited
        computation and memory resources and cannot embed a workflow interpreter such as a BPEL
        engine. Novel solutions must be found to embed workflows in such devices.



Proposal Part B: page 44 of 71
FP7-ICT-2009-5                                                       Integrated project proposal
30/07/09 v1                                                                          SOA4IS
Service-Oriented integration techniques such as Enterprise Service Busses have been successfully applied in
the domain of ICT, but there are no such techniques for on-board systems that take into account the need for
real-time data management, the constraints of embedded devices and the fusion between low-level and high-
level data.
Task T6.3.2: Integration and Experimentation (M10-M18) (M22-M30)
This task consists of integrating the SOA4IS technology into the use case. The main objectives are:
       To model the SoS behavior using the meta-model developed in the modeling activity. Particular
        focus will be put on modeling workflows at various levels in the automation pyramid, modeling
        services showing data-orientation and real-time constraints.
       To identify relevant service attributes that can be used in the modeling of compliance constraints,
        especially attributes that can vary with the environment in which the tramway is deployed, and
        construct formal compliance validation from these attributes.
       To implement the modeled services using the component architecture developed in the SOA4IS
        project. One of the key objectives will be to study how this component architecture permit to unify
        the architectures of various sub-systems.
Task T6.3.3: Evaluation and Conclusions (M19-M24) (M31-M36)
This task will handle the validation tests, and the assessment of their results with respect to the objectives of
the project and the identified requirements. Feedback and status are reported to the technical work packages.
Also this task will show how the SOA4IS technological research areas could be applied to a real market
scenario. Relevant results will impact the SoS modeling environment used by Thales and will drive
innovation in the way various sub-systems can be integrated into a complex SoS.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       Thales will lead the Work Package and will contribute by designing the scenarios and the relative
        experiments; and testing and validate meaningful concepts.


Deliverables
   D6.3.1 Scenario–3 Automatic Tramway: scenario definition (IR) (M12, M24)
   D6.3.2 Scenario–3 Automatic Tramway: integration and experimentation (D) (M18, M30)
   D6.3.3 Scenario–3 Automatic Tramway: evaluation and conclusions (R) (M24, M36)




Proposal Part B: page 45 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP6.4        Start date or starting event:   M7                      End:    M36
Work package title           Scenario – 4: Business Activity Monitoring
Activity type                RTD
Participant number           1     2      3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per                               X
participant

Objectives

Describe the objective of this work package in a few sentences, introducing the main concepts that will be
demonstrated by this use case.


Description of work
Task T6.4.1: Scenario Definition(M7-M12) (M19-M24)
Describe your scenario and its main challenges it brings.
Task T6.4.2: Integration and Experimentation (M10-M18) (M22-M30)
Describe the main expected steps to realize your Use Case and how this will integrate into the whole project
implementation.
Task T6.4.3: Evaluation and Conclusions (M19-M24) (M31-M36)
Describe the main parts of the project that your Use Case will evaluate, and the impact of the conclusions in
your domain of application.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       SAP will lead the Work Package and will contribute by designing the scenarios and the relative
        experiments; and testing and validate meaningful concepts.


Deliverables
   D6.4.1 Scenario–4 Business Activity Monitoring: scenario definition (IR) (M12, M24)
   D6.4.2 Scenario–4 Business Activity Monitoring: integration and experimentation (D) (M18, M30)
   D6.4.3 Scenario–4 Business Activity Monitoring: evaluation and conclusions (R) (M24, M36)




Proposal Part B: page 46 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP6.5        Start date or starting event:   M7                      End:    M36
Work package title           Scenario – 5: On-chip Service Integration
Activity type                RTD
Participant number           1     2      3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per                                     X
participant

Objectives

Describe the objective of this work package in a few sentences, introducing the main concepts that will be
demonstrated by this use case.


Description of work
Task T6.5.1: Scenario Definition(M7-M12) (M19-M24)
Describe your scenario and its main challenges it brings.
Task T6.5.2: Integration and Experimentation (M10-M18) (M22-M30)
Describe the main expected steps to realize your Use Case and how this will integrate into the whole project
implementation.
Task T6.5.3: Evaluation and Conclusions (M19-M24) (M31-M36)
Describe the main parts of the project that your Use Case will evaluate, and the impact of the conclusions in
your domain of application.
Role of the partners
Following is a short description of the role of partners involved in this WP:
       TIE will lead the Work Package and will contribute by designing the scenarios and the relative
        experiments; and testing and validate meaningful concepts.


Deliverables
   D6.5.1 Scenario–5 On-chip Service Integration: scenario definition (IR) (M12, M24)
   D6.5.2 Scenario–5 On-chip Service Integration: integration and experimentation (D) (M18, M30)
   D6.5.3 Scenario–5 On-chip Service Integration: evaluation and conclusions (R) (M24, M36)




Proposal Part B: page 47 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS
1.3.6.8 WPs related to Activity 7: Exploitation and Dissemination

Work package number          WP7.1      Start date or starting event:   M1                         End:    M36
Work package title           Market Analysis and Exploitation
Activity type                RTD
Participant number           1    2     3      4    5       6    7    8    9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE


Person-months per
participant


Objectives:
   Systematic analysis and continuous monitoring of market situation and trends
   Definition of market strategy and rollout plan
   Definition of individual exploitation plans
   Feedback of adjustments to project plan if necessary



Description of work

Task 7.1.1: Market analysis, monitoring and strategy (M1-M36)
The project partners commit to plan the application of the relevant results of this project in their activities or
use them in order to enhance their worldwide competitiveness, to strengthen their product portfolios and to
broaden their network of customers.
This task includes an extensive market analysis to understand the areas in which SOA4IS products and
services can compete in the marketplace. This analysis is undertaken to obtain a deep insight into market
segmentation and market trends of SOA4IS-related technologies. We analyze possible economic benefits and
impact of the expected research results (e.g. through surveys). A SWOT analysis based on input from the
partners in the project is carried out to identify potential internal Strengths and Weaknesses, and external
factors including Opportunities and Threats.
An ongoing monitoring of the market throughout the project lifetime shall guarantee that evolving market
trends and changing customer requirements are considered. This task further yields a recommended market
strategy and rollout plan, identifies market roles and business delivery processes, and defines target market
segments to be addressed.

Task 7.1.2: Definition of exploitation plan (M1-M36)
Exploitation is recognized as the key enabler for the success of the SOA4IS project. Hence all partners of this
intended project are aware of and committed to the exploitation of the project results. It is the principle of all
exploitation activities to use research results to create value within all participating organizations and thus to
improve their competitive advantages. Hence, this task aims at preparing the transfer of the technology
developed in SOA4IS to the project partners and to other academic and industrial partners that could gain
technical, commercial and research benefit from the project results. Relations to relevant standardization
organizations need to be established and maintained to allow for a submission of maturing results to them.
In order for the exploitation to be effective, an integrated approach will be necessary, combining experience
and expertise from the development department and solution management, and the involvement of a user base


Proposal Part B: page 48 of 71
FP7-ICT-2009-5                                                       Integrated project proposal
30/07/09 v1                                                                            SOA4IS
represented by the consortium partners. An integral part of this exploitation task, the SOA4IS use cases (see
Activity 6) which will serve as validation points throughout the project lifetime.
This task also includes the continuous analysis of transfer opportunities and the evaluation of the
advancement of the research results against the user requirements/needs throughout the project. If necessary
the required adjustments to the project plan are communicated in order to ensure the best possible outcome.
Role of the partners:
Following is a short description of the role of partners involved in this WP:

   XXX will lead the Work Package.

   All the partners will contribute to both tasks.



Deliverables:
   D7.1.1: Market analysis and exploitation plan (IR) - (M6, M12, M24, M30)




Proposal Part B: page 49 of 71
FP7-ICT-2009-5                                                            Integrated project proposal
30/07/09 v1                                                                                      SOA4IS

Work package number          WP7.2       Start date or starting event:   M1                       End:    M36
Work package title           Dissemination
Activity type                OTHER
Participant number           1    2      3     4     5      6     7    8    9
Participant short name
                             SIEMENS


                                       THALES




                                                                                         CLAAS
                                                                          UniDue
                                                                  INRIA




                                                                                   UPM
                                                            IBM
                                                SAP


                                                      TIE
Person-months per
participant


Objectives
The purpose of WP7.2 is to promote SOA4IS to the wider community, to seek their engagement and so
involve them in the discussion of how to ensure SOA4IS has utmost impact. The goal is to define and
execute the dissemination and exploitation activities that ensure that SOA4IS results achieve a strategic
positive impact in employing the research results both inside and outside the project’s consortium. It will
solve the need for awareness and garnering interest/activity from a larger number of stakeholders and to
ensure that the wider market is aware of the SOA4IS activity and the subjects that it promotes. It will also
address the important aspects of exploitation by the Beneficiaries and the realities and a roadmap for
exploitation. The success of the technologies provided by SOA4IS involves several perspectives, including
industrial adoption (user perspective), consolidation of a European research community (scientific
perspective), development of standards, open platforms, tools and services (tool vendors and consultants),
etc.



Description of work
Task T7.2.1: Dissemination
       Dissemination will be made through the classical forms of website, newsletters as well as through
        activities such as the creation of papers/conferences and other publications. In turn these
        dissemination activities will facilitate the necessary discussion between the SOA4IS consortium and
        the wider world which will enable different perspectives and ideas to be explored within the main
        project and ultimately lead to better results.
       The disseminated results will then provoke discussion and feedback which will lead to project
        approach adaptation and possibly changes in the way the standards-oriented information is discussed
        with the sectors and wider communities
       Website. A website will be established which will assist in the dissemination/discussions tasks as
        well as for managing SOA4IS internal resources
       Publish project results through articles and papers at conferences and in international journals.
        Demonstrate the SOA4IS approach at conferences and workshops.
       Incorporate the project research issues and results in the academic Beneficiaries training activities
        such as student projects.
       To explore and encourage future research collaboration a SOA4IS roadmap will be developed The
        SOA4IS roadmap will be derived from knowledge and deliverables gleaned during the project.
        Obviously SOA4IS is a time-limited project which can potentially point to further complementary or
        augmented activities. The roadmap will enable an important element of discussion on furtherance
        activities




Proposal Part B: page 50 of 71
FP7-ICT-2009-5                                                        Integrated project proposal
30/07/09 v1                                                                             SOA4IS
Task T7.2.2: Exploitation
This task will include to:
       The Beneficiaries believe their interest is in the exploitation of the work for their own purposes. For
        example, the sector/generic communities/associations involved will be able to further evangelise and
        provide created materials, vendors/consultants will learn from the real-world touch of users and the
        academics will be better able to tailor their researches to the aims of these communities. Academics
        will support the creation of new or existing startups and entities, which will contribute to the
        maturation of some innovative technologies, as developed and extended in SOA4IS, and facilitate
        their adoption by the market. The commercial Beneficiaries will be able to exploit their share of the
        investment Also via website, workshops, and liaisons as above.
       Exploitation activities of Beneficiaries will be examined. It will focus on the following main areas:
              o   Products – how to exploit the core utilities as products
              o   Services – how to exploit the services in an SaaS model
              o   Standards – how standardization could be further engaged to take advantage of the results
              o   Know how – how utilize in other projects/organize the knowledge gained
       Open Source Strategy: The Beneficiaries will study the benefits of reusing and extending Open
        Source components, technologies and middleware, compliant with standards existing in the fields of
        embedded software, SOA and BPM. Partners will analyze existing software components from other
        projects and initiatives that might be of relevance for SOA4IS. If such components are easy to reuse
        and have enough quality they will be included within the integration of components in the associated
        WPs of this work plan. This will be reflected as part of IPR issues of the project.
Task T7.2.3 : Collaboration with other projects
Apart from SOA4IS-focused activities, this task will take care of the coordination with NESSI and the so-
called NESSI Open Framework.
This task will integrate contributions between SOA4IS and other ICT projects under the following WP
objectives: “Service and Software Architectures, Infrastructure and Engineering”, 1.2a: “Service
Architectures and Platforms for the Future Internet”, 1.2b: “Highly Innovative Service / Software
Engineering”, 1.3a: “Architectures and technologies for an Internet of Things”
Collaborations with some Open Source initiatives will be considered (such as the Eclipse SOA initiative, the
OW2 Local Chapter Europe,).
Task T7.2.4 : Standardization effort
This task aims at providing a link between research activities and ongoing standardisation activities. It
has the following two major objectives:
       Ensuring that established and emerging standards in the areas of embedded and industrial systems,
        SOA and BPM are taken into account appropriately by the project.
       Contributing to ongoing standardisation activities by providing experience feedback regarding
        standards used by the project and by participating in the development of new or updated standards.
By achieving these two objectives, this task is directly contributing to maximizing the impact of SOA4IS.
TODO: include the list of organizations we want to target and the list of things to push to standardization
       the GCM (Grid Component Model) by the ETSI TC-GRID group. This standard encompasses:
        deployment definition, application resources definition, Architecture Definition Language, GCM
        application API. It provides an efficient virtualization artifact for developing and deploying
        component/service-based applications on grids, clouds, or ad-hoc networks. GCM is developed as an
        extension of the Fractal component model, that itself has strong links with SCA.
       The OASIS SOA Technical Committees, including standardization activities around SCA (SCA-*


Proposal Part B: page 51 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                            SOA4IS
       TCs), SOA End-to-End Resource Planning (SOA-EERP TC), WSBPEL TC
       The OMG SOAML and BPMN
       …


Role of partners
Following is a description of the role of partners involved in this WP:
    




Deliverables
       D7.2.1 Dissemination strategy
       D7.2.2 SOA4IS Web Site
       D7.2.3 SOA4IS Publicity and Branding material
       D7.2.4 Collaboration activities
       D7.2.5 Dissemination activity reports
       D7.2.6 Exploitation Strategy and Plans
       D7.2.7 Service scenarios and Business models
       D7.2.8 IPR Management plan
       D7.2.9 Standard specifications and contributions to standard bodies (OASIS, OMG,.)
       D7.2.10 Standardization Activity reports




Proposal Part B: page 52 of 71
FP7-ICT-2009-5                                                             Integrated project proposal
30/07/09 v1                                                                                       SOA4IS

Work package number          WP7.3        Start date or starting event:   M12                      End:    M36
Work package title           Standardization
Activity type                OTHER
Participant number           1     2      3     4     5      6     7    8     9
Participant short name
                              SIEMENS


                                        THALES




                                                                                          CLAAS
                                                                           UniDue
                                                                   INRIA




                                                                                    UPM
                                                             IBM
                                                 SAP


                                                       TIE
Person-months per
participant


Objectives:
The training activities will focus on the following objectives:
   To produce a set of training and demonstration materials and courses aimed at introducing the SOA4IS
    architecture and models to the European service providers and consumers
   To organize training sessions for the various communities involved in the project on a national or
    regional basis and on different industrial sectors, especially for SMEs
   To propose general training sessions for potential users both on a national or regional basis and on
    different industrial sectors, especially for SMEs
   To develop training modules, for courses in universities and engineers schools.
As a result , the training activities will firstly create generic modules designed for a various number of
application sectors and for potential service companies; secondly, the training activities will serve to create a
critical mass of trained technical professionals able to efficiently disseminate know-how about the SOA4IS
technology across Europe.


Description of work
The work package comprises the following tasks:

Task T7.3.1: Development of training and demonstration material (M12-M36)
This will include general presentation of the objectives and the contents of the SOA4IS project and
introductory tutorials on the SOA4IS architecture. For example this may include the following topics: service
definition, technological and economical aspects, deployment of technical processes and integration with
business processes, etc.

Task 6.4.2: Internal Training Sessions (M12-M36)
Organization of specific training sessions for the communities involved in activities 3 to 5. Search sessions
will concern approximately 10 technical communities and probably at least 200 people. This activity need to
have specific infrastructures for training (training rooms – experimental platforms…)

Task 6.4.3: External training sessions (M12-M36)
These sessions address a large spectrum of potential users, including industry and service companies
involved in the different sectors represented by the case studies and other potential user communities, putting
an emphasis on delivering training sessions to SME service providers. These activities will be performed in
strong relationship with the dissemination activity in order to increase the impact of both activities.




Proposal Part B: page 53 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS

Role of the partners:
Following is a short description of the role of partners involved in this WP:
    


Deliverables
       D.7.3.1: Training Material (R) – (M18, M24)
       D.7.3.2: Training Sessions Summary (IR) – (M24, M36)




Proposal Part B: page 54 of 71
FP7-ICT-2009-5                                                    Integrated project proposal
30/07/09 v1                                                                         SOA4IS




1.3.7 Risk assessment

TODO: describe any significant risks, and their associated contingency plans.


1.3.8 Summary of effort

Table 1.3e      Summary of effort
A summary of the effort is useful for the evaluators. Please indicate in the table number of person months
over the whole duration of the planned work, for each work package by each participant. Identify the work-
package leader for each WP by showing the relevant person-month figure in bold.
     Partic.    Partic. short WP1       WP2       WP3       WP4     WP5    WP6    WP7     WP8    Total
     no.        name                                                                             person
                                                                                                 months
     1          Siemens
     2          TAS
     3          TAC
     4          SAP
     5          IBM
     6          INRIA
     7          UniDue
     8          UPM
     9          CLAAS
     Total




Proposal Part B: page 55 of 71
FP7-ICT-2009-5                                                  Integrated project proposal
30/07/09 v1                                                                       SOA4IS


2         Implementation

2.1 Management structure and procedures

SOA4IS follows standard and well proven project management methods:
     Clear definition of activities, work packages and tasks
     Precise definition of deliverables being the results of the tasks
     Assignment of responsibilities to activities, work packages, tasks and deliverables
     Collaboration of partners based on commitment
     Milestones as measurable quality gates clearly defined by the related deliverables, time and
      cost.
     Stringent cost and performance controlling
In respect of the geographically distributed participants, one of the main risks is the co-ordination.
Therefore we will start from the beginning with a project management plan implementing clear
reporting procedures to ensure an efficient project time, quality and cost control, as well as full
visibility for the EC.
                                                                                                         Formatted: Justified, Space Before: 24 pt,
                                                                                                         After: 12 pt, Outline numbered + Level: 3 +
                                                                                                         Numbering Style: 1, 2, 3, … + Start at: 1 +
2.1.1 Project Management Organization and Structure                                                      Alignment: Left + Aligned at: 0" + Indent at:
                                                                                                         0.5"
To ensure a fast decision making flow the project uses a flat organization structure. The Figure 4
represents the project management organization and shows also the decision flow of the Project.



                                 Steering   Committee

      Representative             Representative              Representative
        Partner 1                  Partner 2                   Partner n


                           Project Management Board

                                 Project Manager         Project Admin

       Lead Partner 1             Lead Partner 2             Lead Partner n



     Activity 1
    Work Package       1     Activity 2
                            Work Package 2                                n
                                                                Work Package n
                                                                Activity




Proposal Part B: page 56 of 71
FP7-ICT-2009-5                                                Integrated project proposal
30/07/09 v1                                                                     SOA4IS
Figure 4: SOA4IS management organization


At strategic level, the Steering Committee will act as decision making body for the project. Each
partner will nominate one executive representative to the Steering Committee that will be chaired
by the executive representative from the coordinator. Each member of the Steering Committee will
have due authorisation to discuss, negotiate and decide on actions proposed by the coordinator or to
accept recommendations made by the bodies within the frame of its responsibilities. Decisions
taken by the Project Management Board will be based on consensus, i.e. motions and documents
etc. are considered approved if there is no consistent dissent. If consensus cannot be reached the
Project Manager will be charged to escalate the decision to the Steering Committee.
The decisions of the Steering Committee will be binding to all parties for:
    The final approval of the periodic and the final report prior to the submission to the EC,
    All budget-related matters,
    The acceptance of new parties as well as the exclusion of parties,
    The structure and restructuring of the work-packages,
    The alteration of the Consortium Agreement,
    The premature completion / termination of the project, and
    The designation of the trustees in accordance with this Consortium Agreement
In the remaining cases, the Project Management Board (see below) has the authority to make
decisions.
The members of the Steering Committee will be named at project start.
At operational level (day to day work), there will be a Project Management Board composed of the
coordinator's project manager and the Lead Partners of the other members of the Consortium. This
Project Management Board is responsible for implementing the decisions of the Steering
Committee.
The Project Management Board shall be responsible for:
    Supporting the Coordinator in fulfilling obligations towards the EC,
    Ensuring that all work meets the requirements,
    Co-ordinating the performance of activities,
    Deciding about activity organisation, prioritisation, and planning
    Approving the progressively refined work plan
    Monitoring the project results
    Organising the regular project meetings and workshops
    Reviewing and proposing to the Steering Committee budget transfers in accordance with the
     contract and the implementation plan,
    Proposing changes in work budget and participants to the Steering Committee,
    Deciding on the periodic and final reports for approval by the Steering Committee prior to its
     submission to the EC,
    Approving deliverables

Proposal Part B: page 57 of 71
FP7-ICT-2009-5                                                 Integrated project proposal
30/07/09 v1                                                                      SOA4IS
     Agreeing on press releases and joint publications by the parties with regard to the project, and
     Agreeing on procedures and policies for dissemination of knowledge from the project.
The composition of the Project Management Board is shown in Table 1:


No     Partner        Name                                 Role
1                                                          Coordinator
2                                                          Partner
3                                                          Partner
4                                                          Partner
6                                                          Partner
7                                                          Partner
8                                                          Partner


                                 Table 4: Project Management Board

The Project Management Board assumes overall responsibility towards the Steering Committee for
liaison between the parties for analysing and approving the results generated in work packages.
Panels can be established by the Project Management Board to deal with specific issues or
problems, e.g. technical, technology or scientific panel, financial panel, and exploitation or
dissemination panel.
Each member of the Project Management Board is responsible for keeping the mailing lists up-to-
date with respect to membership within her/his own organisation.
The Project Manager of the project is Franz Kudorfer (Siemens, CT SE 3, Munich) who is
nominated by the coordinator. He is responsible for the overall management of the project, ensuring
the smooth development of the project and providing an interface between the project and the
outside world. The Project Administration is done by Siemens staff. The Project Manager is
responsible for:
     Project coordination and administration: general project administration, contractual issues
      interfacing with commission and dissemination.
     Technical coordination: overall technical coordination of the project, flow of information
      between different activities, responsible of subdivision of activities and monitoring their
      progress.
The coordinator will be the single point of contact between the EC and the Consortium. In this
function the coordinator shall:
     Sign the contract with the EC,
     Collect from all parties the cost and other statements for submission to the EC,
     Prepare, with the support of the members of the Project Management Board, the reports and
      project documents required by the EC, and




Proposal Part B: page 58 of 71
FP7-ICT-2009-5                                                 Integrated project proposal
30/07/09 v1                                                                      SOA4IS
    Ensure prompt delivery of all reports, software and data identified as deliverable items in the
     contract or requested by the EC for reviews and audits, including the results of the financial
     audits.
The Project Manager is authorised to execute the project under the control of the Project
Management Board and shall report and be accountable to the Steering Committee. The Coordinator
is responsible for the following tasks and functions:
    Overall management of the project with the support of the Project Management Board, if
     necessary, and
    Chairing the Project Management Board and the Steering Committee, and
    Preparation of the meetings and decisions of the Steering Committee and the Project
     Management Board.
    Organizing regular full project workshops
    Officially releasing project deliverables.
    In crisis situations, contacting the Steering Committee and lead persons of the partners.
    To the extent that serious concerns regarding the financial soundness of one or several parties
     exist, the coordinator has the authority to require the appropriate letter of comfort to prove
     that the corresponding party is able to fulfil their financial obligations with regard to the
     contract and this agreement. Until this is provided, the coordinator is entitled to refuse the
     disbursement of the financial contributions of the EC to this party.
    Furthermore, the Coordinator has the right to retain any payment if a party is late in
     submitting or refuses to provide deliverables.
    If one or more of the parties is late in submitting of project deliverables, the Coordinator may
     submit the other parties' project deliverables to the EC.
The coordinator will be responsible to assure that each party hereby undertakes with respect to other
parties all reasonable endeavours to perform and fulfil, promptly, actively and on time, all of its
obligations from the proposal.
Each of the other partners will nominate a lead for representing their entity.


Each activity has an Activity Leader, who is responsible for the technical work within his/her
activity. The activities are separated into work packages and tasks.
The Activity Leaders
    Participate to the planning within the activity
    Respond that the tasks in concern shall be performed,
    Participate in the reporting procedure as delivering the status reports to the project manager
     every three months.
    Co-ordinate the flow of information between the activities.
Activity meetings are arranged by Activity Leaders as needed. The responsibility for each work
package is defined in the Full Project Plan. Each task is part of a work package. The Work Package
Leaders are responsible for co-ordinating issues that surpass the tasks.




Proposal Part B: page 59 of 71
FP7-ICT-2009-5                                                 Integrated project proposal
30/07/09 v1                                                                      SOA4IS
2.1.2 Consortium agreement

The relationship between all contractors will be fixed in a Consortium Agreement (planned to be
implemented prior to contract signature) based on the following principles:
    In order to have a management system applicable through all phases of the project, a
     reasonable approach is to have a straight, clear and direct management and organization
     protocol at all levels. This is particularly relevant given the challenging financial and
     industrial policy constraints. Therefore, in order to have clearly assigned responsibilities, to
     avoid any friction and to progress as per the project plan, the responsibilities and authorities
     of the project managers and the team members will be unambiguous.
    The partners will be bound by the consortium agreement of the project, in which their roles,
     responsibilities and mutual obligations will be defined for the project life.
The project has very well defined objectives and tasks for each of the partners, having been
allocated specific responsibilities to each of them. Nevertheless, the management procedures have
to include provisions for the case of dispute among partners. Adoptions of decisions at activity level
to solve dispute are preferred. However, the Steering Committee of the Consortium will take
decisions in an ultimate stage. Any partner is entitled to report directly to the Steering Committee on
any issue, which might have created a dispute among partners at any level of the consortium
structure. The decisions by the Steering Committee will pursue consensus among partners, but in
case of vote, a weight vote might be necessary. These points will be duly included in the
Consortium Agreement of the project that will specify the rules to apply for conflict resolution
within the Steering committee and also within the Project Management Board. This will assure that
everything is equally understood by all parties and avoid shadow areas.


2.1.3 Project Plan and Activity Management

To facilitate the organisation and management, the project is structured in activities, which together
comprise the project. This structure is approved by the Steering Committee based on the work
breakdown structure provided with the work plan in the proposal.
A Project Plan will be produced identifying the different phases of the project, tasks to be
developed and the resources involved for each activity, and highlighting the formal milestones,
expected results and associated costs issues. This project plan will be kept up to date as the work
progresses and will be updated monthly.
Each WP Leader will be responsible for the organisation of work and outputs of the WP and for the
timely solution of any problems that may arise.
Activity leaders will be responsible for ensuring that Work Package Leaders under their aegis
organise the work of work packages in collaboration with the partners involved. This will include
definition of the lowest level of tasks or sub-activities for individual partners.
All Work Package Leaders will report to the Activity Leader and keep him informed of all Work-
Package-level events and decisions. The Activity Leaders will collect all information and present
the progress, issues and results of their activity at the consortium meetings.
Responsibility for overall planning will be delegated to the Project Manager and hence for detailed
planning to the Activity and Work Package Leaders as appropriate.
A Project Handbook will be produced at project start that contains the project plan, the risk
management plan, the quality assurance plan and the configuration management plan. It will be the


Proposal Part B: page 60 of 71
FP7-ICT-2009-5                                                     Integrated project proposal
30/07/09 v1                                                                          SOA4IS
basis for all project monitoring and reporting tasks and will be updated yearly and on major re-
planning of the project.


Monitoring activities involving the interaction of the project with other projects will be under the
responsibility of the Project Manager as the first point of contact, who may delegate this
responsibility to a team drawn from one or more project partners as appropriate.
Reporting will be done through progress reports to be submitted by each partner to the coordinator.
The coordinator will consolidate these into an overall interim report for the project. A periodic
report to EC will be issued every year. The last periodic report will be the final report for the
project. The reporting process to EC follows the EC document "Project reporting in FP6" from
October 2004. If a similar document for FP7 will be published before project start, the respective
rules will be applied.
The reporting is summarized in the following Table 5.


 Type                Content                                from              to                 period
 Progress Report     progress of Activities                 partner           coordinator        6 month
 Interim Reports     project status, risks, problems        coordinator       EC                 6 month
 Periodic Report     Periodic     activity    report coordinator              EC                 1 year
                     Executive             summary
                     Dissemination plan
                     Periodic management report
                     Periodic     report      on       EC
                     contribution records
                     Interim reporting questionnaire
                     on workforce statistics
 Final Report        Publishable final activity report      coordinator       EC                 project
                     Final dissemination plan                                                    duration

                     Final management report
                     Final EC contribution report
                     Final reporting questionnaire on
                     workforce statistics
                     Final socio-economic reporting
                     questionnaire


                                 Table 5: SOA4IS project reporting

Supplementary reports and other data may be delivered on request of the EC.
Additionally there will be technical notes and working papers by all participants as required.




Proposal Part B: page 61 of 71
FP7-ICT-2009-5                                                 Integrated project proposal
30/07/09 v1                                                                      SOA4IS
2.1.4 Meetings

Meetings of the Steering Committee will be held every 6 months upon invitation of the coordinator.
In these meetings, the Steering Committee shall consider the report of the Project Management
Board, receive and approve the accounts for the past (financial) year, approve the budget and
project plan for the next (financial) year and decide on changes in work shares as well as acceptance
of new parties or withdrawals or exclusion of parties. These meetings are considered for the
strategic guidance of partners and of the project itself. The first meeting of the Steering Committee
(Kick-off Meeting of the project) will take place at the latest one month after the coordinator has
signed the contract. Additional meetings will be called for critical policy issues and consensus if
necessary. If suitable, preferably video or telephone conferences shall be held instead of physical
meetings.
The steering committee meeting will be responsible for:
    Establishing joint planning and reviewing progress against the project Objectives and
     Deliverables.
    Ensuring that any necessary remedial action is taken.
    Controlling overall project budgets.
The Project Management Board will at least meet quarterly on invitation of the Coordinator.
There will be official periodic review with the EU representatives. The consortium will make
benefit of the official periodic review with the EU to meet up after the review in order to define the
next steps.
The minutes of all formal meetings that involve project representation (including steering
committee meetings, Activity and inter-Activity meetings, inter-project meetings, clustering) will
be promptly generated by the chairman of the meeting and distributed to all partners.


2.1.5 Communications flow

There is a mutual agreement for information exchange between all the partners participating in the
project.
    Electronic mail is the chosen way for day-to-day communication for exchange of documents
     and news.
    A project reporting mechanism will be put in place allowing all participants to report online
     and to monitor project progress.
    A Web server will be set up to deposit the history of the project (deliverables and documents
     related to the project), as a forum to bring ideas and keep trace of the suggestions, and to store
     news.
    A public Web server will be set up to present the project and to publish on-line all public
     deliverables. This will also serve as a reference ground and managerial tool for the EU to
     assess on-line the progress of the work.


2.1.6 Deliverables and other project documents

The coordinator will establish a project database for internal reports, deliverables, publications and
relevant reports.

Proposal Part B: page 62 of 71
FP7-ICT-2009-5                                                Integrated project proposal
30/07/09 v1                                                                     SOA4IS
Deliverables will be generated by the designated WP/activity teams under the responsibility of the
WP leader, who will be charged with ensuring that a deliverable is prepared correctly and on time,
either by himself or by another appointed editor.
At the beginning of each WP activity generating a deliverable, the WP leader will issue, after
discussion with the activity team:
    an overall Scope description
    an agreed contents list including clear outline descriptions of each section allocated to a
     designated contributor
    a timetable of delivery of contributions to the editor by each partner
    an allocation of editing responsibilities.
At least one complete draft deliverable will be prepared, at least one month before the planned
delivery date and distributed to all partners for review before a defined date. Approval of the final
version will be by consensus of all partners by the defined date, before issue to the EC.
Other documents (conference papers etc.) representing the results of project work must be offered       Formatted: prop_text

for comment and approval through consensus of all partners before a defined date in advance of
publication.


2.1.7 Risk Management and Conflict Resolution

Successful projects do not rely on the absence of problems but in 'foreseeing' and managing the
risks so that when problems occur they can be resolved and overcome.
Risk management requires identification, analysis, control and recording of risks, highlighting of
the consequences and the appropriate management actions. Risk management is a balance of
judgement so that the risks are minimised without over-emphasising the potential problems.
Controlling the risks will help to manage the project to achieve properly the objectives on time and
to budget.
The experiences in managing complex and international projects allow SOA4IS partners to identify
the following main areas of possible risks:
    Financial – deterioration of the economic situation of a partner, that impose a stop or an
     unacceptable reduction of all activities;
    Key resources availability – abandon of the participation to the project of resources with key
     roles.
Various combinations of these main negative factors could also happen with the effect to increase
the phenomenon.
In any case, the corrective measures will be to distribute to the remaining partners the activity not
fulfilled or to subcontract them to a third party, or a combination of the two. The corrective
measures will be chosen after an evaluation of their impact and relevance on the project. In this
sense, if needed, risk assessments methods will be applied in order to minimize possible deviations
from the expected results and schedule.
Risk management will be an integral part of project management and will be included in every
project report of Table 5.




Proposal Part B: page 63 of 71
FP7-ICT-2009-5                                                  Integrated project proposal
30/07/09 v1                                                                       SOA4IS
Regarding conflict resolutions, discrepancies occurred during the development of the project tasks
must be anticipated and reported immediately to the WP Leader. The WP leader will try to solve the
conflicts and will communicate every incidence to the Project Manager.


2.1.8 Quality Assurance and Configuration Control

The quality of the main results of the project in terms of deliverables or other project documents
will be ensured using the procedures below.
The quality assurance principles adopted for all the project activities are as follows:
      Define a Quality and Configuration Management Plan as a part of the Project Plan to
       establish standards, methods and procedures for all phases of the project, e.g. a common
       document format for deliverables will be agreed and employed.
      Ensure adherence to these standards and methods.
      Address quality assurance tasks to the Activity and Work Package Leaders
All project documents will be placed under configuration control starting from the beginning of the
project.
For the concrete implementation of project management, risk management, quality assurance and
configuration management a Project Handbook will be set up (see deliverable D10.1.1)




Proposal Part B: page 64 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                            SOA4IS




2.2 Individual participants

(Maximum length for Section 2.2: one page per participant. However, where two or more departments within
an organisation have quite distinct roles within the proposal, one page per department is acceptable.
The maximum length applying to a legal entity composed of several members, each of which is a separate
legal entity (for example an EEIG), is one page per member, provided that the members have quite distinct
roles within the proposal.)


For each participant in the proposed project, provide a brief description of the legal entity, the main tasks
they have been attributed, and the previous experience relevant to those tasks. Provide also a short profile of
the individuals who will be undertaking the work.




2.2.1 Thales

Brief Description of the Organisation
Thales is a global electronics group serving professional markets in three areas: defense, aerospace and
security. Its activities include prime contracting for large-scale programmes, complex system architecture,
and the supply of equipment and systems and related support services. Thales engineers draw on a solid
foundation of generic and dual civil/military technologies focused on real-time management and distribution
of information.
The distinctive characteristic of Thales’ businesses is its international dimension both in terms of the markets
it serves and the countries of operation. With industrial operations in nearly 30 countries, Thales is pursuing
a unique multi-domestic strategy, which is of key relevance in defense markets. This strategy is designed to
provide the group with the local presence it needs to serve both civil and military customers effectively
anticipate demand and propose the right technical solutions at the right price to meet their requirements.
Thales recently opened an industrial research Lab where very strong technical skills are available in a variety
of different area (security, architecture, infrastructure, semantic and Open Source).
Relevant Experience
Thales is strongly involved in several FP6 and FP7 projects such as COMPAS, PERMIS, DiVA, and has
solid experience in leading large IP projects. The company is also leading the definition of security patterns
in the NEXOF-RA project. Thales is also heavily involved in the NESSI ETP.
Role in the Project
A main expertise area of Thales is to model and set up secure information systems, in both civil and non-
civil environments. Accordingly, Thales will be involved in the Service Engineering and Security activities.
Thales has also solid expertise in the realization of embedded architectures and communication middleware
for mission-critical distributed systems, and will thus be involved in the realization of the service component
architecture.
Short Profile of Key Personnel
TODO




Proposal Part B: page 65 of 71
FP7-ICT-2009-5                                                     Integrated project proposal
30/07/09 v1                                                                          SOA4IS




2.3 Consortium as a whole

(No maximum length for Section 2.3 – depends on the size and complexity of the consortium)


Describe how the participants collectively constitute a consortium capable of achieving the project
objectives, and how they are suited and are committed to the tasks assigned to them. Show the
complementarity between participants. Explain how the composition of the consortium is well-balanced in
relation to the objectives of the project.
If appropriate describe the industrial/commercial involvement to ensure exploitation of the results. Show
how the opportunity of involving SMEs has been addressed


i) Sub-contracting: If any part of the work is to be sub-contracted by the participant responsible for it,
describe the work involved and explain why a sub-contract approach has been chosen for it.
ii) Other countries: If a one or more of the participants requesting EU funding is based outside of the EU
Member states, Associated countries and the list of International Cooperation Partner Countries12, explain in
terms of the project’s objectives why such funding would be essential.
iii) Additional partners: If there are as-yet-unidentified participants in the project, the expected
competences, the role of the potential participants and their integration into the running project should be
described. (These as-yet-unidentified participants will not be counted in the minimum number of participants
for the eligibility of the proposal).




12
     See CORDIS web-site, and annex 1 of the work programme.
Proposal Part B: page 66 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS




2.4 Resources to be committed

(Maximum length for Section 2.4 – two pages)


Describe how the totality of the necessary resources will be mobilised, including any resources that will
complement the EC contribution. Show how the resources will be integrated in a coherent way, and show
how the overall financial plan for the project is adequate.


In addition to the costs indicated on form A3 of the proposal, and the effort shown in section 1.3 above,
please identify any other major costs (e.g. equipment). Ensure that the figures stated in Part B are consistent
with these.




Proposal Part B: page 67 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                            SOA4IS


3        Impact
(Maximum length for the whole of Section 3 – ten pages)




3.1 Expected impacts listed in the work programme

Describe how your project will contribute towards the expected impacts listed in the work programme in
relation to the topic or topics in question. Mention the steps that will be needed to bring about these impacts.
Explain why this contribution requires a European (rather than a national or local) approach. Indicate how
account is taken of other national or international research activities. Mention any assumptions and external
factors that may determine whether the impacts will be achieved.




Proposal Part B: page 68 of 71
FP7-ICT-2009-5                                                   Integrated project proposal
30/07/09 v1                                                                        SOA4IS




3.2 Dissemination and/or exploitation of project results, and management of
    intellectual property

Describe the measures you propose for the dissemination and/or exploitation of project results, and how
these will increase the impact of the project. In designing these measures, you should take into account a
variety of communication means and target groups as appropriate (e.g. policy-makers, interest groups, media
and the public at large).


Describe also your plans for the management of knowledge (intellectual property) acquired in the course of
the project.




Proposal Part B: page 69 of 71
FP7-ICT-2009-5                                                        Integrated project proposal
30/07/09 v1                                                                              SOA4IS



4         Ethical Issues
(No maximum length for Section 4 – depends on the number and complexity of the ethical issues involved)


Describe any ethical issues that may arise in their proposal. In particular, you should explain the benefit and
burden of their experiments and the effects it may have on the research subject. The following special issues
should be taken into account:


         Informed consent: When describing issues relating to informed consent, it will be necessary to
         illustrate an appropriate level of ethical sensitivity, and consider issues of insurance, incidental
         findings and the consequences of leaving the study.


         Data protection issues: Avoid the unnecessary collection and use of personal data. Identify the
         source of the data, describing whether it is collected as part of the research or is previously collected
         data being used. Consider issues of informed consent for any data being used. Describe how
         personal identify of the data is protected.
         Use of animals: Where animals are used in research the application of the 3Rs (Replace, Reduce,
         Refine) must be convincingly addressed. Numbers of animals should be specified. State what
         happens to the animals after the research experiments.
         Human embryonic stem cells: Research proposals that will involve human embryonic stem cells
         (hESC) will have to address all the following specific points:
                 the necessity to use hESC in order to achieve the scientific objectives set forth in the
                  proposal.
                 whether the applicants have taken into account the legislation, regulations, ethical rules
                  and/or codes of conduct in place in the country(ies) where the research using hESC is to take
                  place, including the procedures for obtaining informed consent;
                 the source of the hESC
                 the measures taken to protect personal data, including genetic data, and privacy;
                 the nature of financial inducements, if any.
Identify the countries where research will be undertaken and which ethical committees and regulatory
organisations will need to be approached during the life of the project.
Include the Ethical issues table below. If you indicate YES to any issue, please identify the pages in the
proposal where this ethical issue is described. If you are sure that none of the issues apply to your proposal,
simply tick the YES box in the last row.


Notes:
1. For further information on ethical issues relevant to ICT, see annex 5 of the Guide for applicants
2. Only in exceptional cases will additional information be sought for clarification, which means that any
ethical review will be performed solely on the basis of the information available in your proposal.




Proposal Part B: page 70 of 71
FP7-ICT-2009-5                                                      Integrated project proposal
30/07/09 v1                                                                           SOA4IS


ETHICAL ISSUES TABLE

                                                                    YES      PAGE
     Informed Consent
          Does the proposal involve children?
          Does the proposal involve patients or persons not
            able to give consent?
          Does the proposal involve adult healthy
            volunteers?
          Does the proposal involve Human Genetic
            Material?
          Does the proposal involve Human biological
            samples?
          Does the proposal involve Human data collection?
     Research on Human embryo/foetus
          Does the proposal involve Human Embryos?
          Does the proposal involve Human Foetal Tissue /
            Cells?
          Does the proposal involve Human Embryonic
            Stem Cells?
     Privacy
          Does the proposal involve processing of genetic
            information or personal data (eg. health, sexual
            lifestyle, ethnicity, political opinion, religious or
            philosophical conviction)
          Does the proposal involve tracking the location or
            observation of people?
     Research on Animals
          Does the proposal involve research on animals?
          Are those animals transgenic small laboratory
            animals?
          Are those animals transgenic farm animals?
          Are those animals cloned farm animals?
          Are those animals non-human primates?
     Research Involving Developing Countries
          Use of local resources (genetic, animal, plant etc)
          Impact on local community
     Dual Use
          Research having direct military application
          Research having the potential for terrorist abuse
     ICT Implants
          Does the proposal involve clinical trials of ICT
            implants?
     I CONFIRM THAT NONE OF THE ABOVE ISSUES
     APPLY TO MY PROPOSAL




Proposal Part B: page 71 of 71

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:10/16/2012
language:Latin
pages:71