Building Maitenance Management Templates - DOC

Document Sample
Building Maitenance Management Templates - DOC Powered By Docstoc
					                              Progress Report

Project Number:                            INCO-DC 97-2496

Title:                                     A Workflow Management System for the
                                           Maritime Industry
Project Acronym:                           MARIFlow

Report No: 4                  Year:2000             Month: September

Reporting Period Under Review: March 15, 2000 – Sept.15, 2000
Contract start date: Sept. 15, 1998       Contract termination date: Dec.15, 2000

Names of editors and/or authors and their organisations:

Prof. Dr. Asuman Dogac
Dept. of Computer Eng.
Middle East Technical University
06531, Ankara, Turkey

Report Preparation Date: September 15, 2000

Report Version: V 7

Classification: Public

Executive Summary

MARIFlow project has started on the 15th of September 1998. The work
accomplished during the first 18 months of the project is presented in Progress
Reports No 1, No 2 and No 3. As a summary, first six months of the project consisted
of the Work Package No 1, which included tasks related to the requirement analysis
and the system architecture design. Requirements analysis of the application domain
(Deliverable 1.1) and a detailed specification of business process scenario
(Deliverable 1.2) are produced during this time as well as a simple prototype has
been implemented to get a better understanding of the general design concepts. This
prototype provided the base for a detailed system design and for the system
development. This prototype did not include all of the functionality of the system, but
some basic components such as cooperating agents, guard-based workflow

enactment and message passing between different agents in the system were
implemented. Within the second reporting period (Progress Report 2), a detailed
design of the system has been completed (Deliverable 1.3), and an extended
prototype based on a distributed architecture with cooperating agents has been
implemented (Deliverable 2.1). Task and worklist managers of the agents have also
been implemented. The interfaces necessary to invoke tasks or sub-processes in
other companies’ domains (probably on different platforms) have been designed.
 During the third reporting period, a comprehensive reliable communication
    mechanism is developed through persistent queues for reliable message passing
    and integrated to the system (Deliverable 2.7). All the messages, including
    MARCA-to-MARCA messages, mails, documents, etc. are transmitted through
    persistent queues, in a transactional manner. Security component of the system
    is developed (Deliverable 2.5) and integrated to the prototype (Deliverable 2.7).
    Apart from this, configuration files of the system are made secure using
    encryption methods and the messages are exchanged in communication
    infrastructure in encrypted form. Furthermore an extensive failure mechanism is
    developed and integrated to the system (Deliverable 2.7). Logging mechanisms
    are introduced for this purpose so that the execution of the workflows can be
    tracked. If some unexpected error occurs, the Compensation Activities defined
    through the Process Definition Tool for that workflow are executed to undo the
    effects of the terminated activities of workflow instances. The deliverable 2.4 has
    been completed and released. This deliverable is
 the result of joint work between HU and ETHZ and is a comprehensive analysis
    of the problem of data consistency and execution guarantees in workflow
    management systems. The deliverable includes an extensive related work
    section and the results of Task 2.4. These results include a formal model for
    concurrency control and execution guarantees in process based interactions and
    a description of the implementation of these ideas as part of the prototype
    developed at ETHZ. As part of
 Task 2.3, the first release of the ETHZ prototype has been completed. For Task
    2.6, the procedure of converting the representation of certificates provided by
    SZAG in MARIFLOW QALITY subset format into the Extensible Markup
    Language (XML) representation required by GL are provided.
        Within this reporting period the following achievements have been

          The system is installed at partners’ sites and tested over the Internet. The
           bugs encountered are fixed. The details of testing are provided while
           describing the progress in Task 3.2.

Within task 3.1 the two software systems developed by METU and ETHZ,
respectively have been deployed at the industrial partners' sites. Experiences gained
during these installations as well as a number of tests were documented. For each
components of those workflow systems the following steps have be tested
successfully: installation, configuration and customization, execution and
maintenance (including updates). Functionality available to the end user and usability
of the tools was investigated. After successful installation and proper configuration
multiple tests were executed corresponding to the different phases in the life cycle of
a workflow: definition, enactment (execution), monitoring & analysis, and co-
ordination and communication to check that the installation works as expected.

An exploitation plan for the project has been drafted focusing at potentially
exploitable results. It shall be refined soon after the prototypes have been installed
and are usable for the sample processes. Based on real measurement, more
detailed cost-benefit calculations may be presented.

Contacts established with other related projects:

1. ENHANCE - Enhanced aeronautical concurrent engineering
Contact: Jaques Spee (M.I.S. Organisatie-ingenieurs b.v.),
This ESPRIT project is developing a demonstrator for workflow of engineering
data. STEP Application Protocol ISO 10303-233 has been chosen for a
standardized description of data. It is specific to engineering data to have a
version history enabling tracing of changes. The tool will mainly support a
predefined scenario in which the number of participants for a certain role may
System architecture:
   user interface layer
   communication layer (CORBA)
   server layer
Practically, the system shall link a number local workflows. In order to achieve
this link, it is essential to have all workflows described in standardized
description language. For this purpose, an XML binding of the WFMC model
is used. Working in a decentralized mode, there is no central database
holding WF information. No workflow co-ordinator or manager is required,
once the consortium has been set up. They claim to support dynamic
modifications of the workflow definition. The status of an individual activity can
characterized as blocked, enabled, in process, published, committed.
According to their security concept, encapsulation of information isn't
supported, i.e. all data and activities are exposed to every participant. The
usage of corporate firewalls has not been considered yet.

2. MARVIN - Maritime Virtual Enterprise Network (ESPRIT EP29049)
Contact: Clemens Odendahl (IWI, Uni. Saarbrücken),: Odendahl@iwi.uni-

The project is developing an agent based system called Maritime Enterprise
Integration Tool (MEIT) to facilitate and co-ordinate the interaction and co-
operation of companies building up a virtual organization to carry out the
mission of repairing a ship in the shortest time possible.
System architecture:
   communication layer (Agent2Agent, Agent2User, Agent2System; using
    WWW, Java)
   networking layer (TCP/IP, RMI)
   processing layer     (database     management      component,     reasoning
In the beginning, a workflow is modeled as extended Event Process Chain
(eEPC) using the ARIS toolkit. Based to this model, program code is
generated for a number of agents automatically. Each agent has to fulfil a
predefined role, the (role specific) knowledge based process logic is stored
using the KQML language. Creation, configuration and maintenance of agent
specific knowledge bases is mainly a manual process. The reasoning
component, which is also part of an agent, is implemented in Java Expert
System Shell (JESS) and CLIPS. An object-oriented system called Jeevan is
used for database management. For role-specific communication between
agents they temporary grant access to their database for specific activities. A
specialized agent (administrator agent) is responsible for registration of new
users and provision of agent templates. The database of this agent can be
considered as database of the workflow engine. Currently there is no
monitoring tool yet.
Corporate firewalls haven't been considered since all agents running on the
same server. Furthermore, for upload and download of data dedicated port
numbers are used. Access is controlled by IP address numbers.
The complete service shall be provided in a single place by, e.g., Web Service
Provider, no local installations will be required at client site.
3. SEANET The product data interchange for the maritime information
society (ESPRIT)
Contact: Tim Turner (Lloyds Register),
The objective of this project is to create the virtual-enterprise-wide, internet-
based product data management (PDM) system that will enable all maritime
enterprises to take full advantage of STEP standardization.
A system is developed interconnecting a number of different PDM systems in
order to support seamless exchange of data between those systems. A basic
requirement for this exchange is that all participating systems have interfaces
to both STEP P21 and XML files.
The flow of activities is modelled in IDEF-0 and converted to a XML
representation based the WFMC standard using a system component called
GLOBE. This model is then deployed on a special web server, having many
functions of a workflow engine like execution of activities, sending messages
and acknowledgements. It also supports monitoring. Each partner in the
scenario has to operate its own PDM server. The architecture doesn't support

corporate firewalls, therefore all servers have to run in public areas.
Encryption is an optional feature for data transfer.
Every participant has copy of the global workflow definition tailored to his local

Project Meetings:

       Three project meetings have been organized during this period:

       1. March 31 2000, Hamburg

            Manegold              --      SZAG
            Helmut Pelka          --      SZAG
            Uwe Langbecker        --      GL
            Siems                 --      GL
            Markus Lehne          --      BALance

       2. May 15-16, 2000, Hamburg.

            Asuman Dogac          --      METU
            Gustavo Alonso        --      ETHZ
            Markus Lehne          --      BALance
            Uwe Langbecker        --      Germanischer Lloyd
            Yusuf Tambag          --      METU
            Amaia Lazcano         --      ETHZ
            Markus Steinbiss      --      Balance
            Uwe Rabien            --      Germanischer Lloyd
            Helmut Pelka          --      Salzgitter AG

       3. July 20, 2000, Bremen.

            Markus Lehne          --      BALance
            Uwe Langbecker        --      Germanischer Lloyd
            Yusuf Tambag          --      METU
            Gustavo Alonso        --      ETHZ
            Amaia Lazcano         --      ETHZ

WORK Progress Overview

        In this section, for each task that was active during this reporting period, first a
short description of the objective of the task is presented, followed by the description
of the achievements and responsibilities of the partners.

TASK 2.3 Availability and Scalability


Implementation of final architectural design for scalability and availability. As an
extension to this task, ETHZ will explore the use of the WISE engine as a centralized
alternative to the system being designed at METU. A prototype system will be
developed and, using this prototype, several ideas related to scalability and
availability will be explored.


The prototype has been completed (deliverable 2.3), and it is currently being tested
(deliverable 3.1). See these deliverables for more information on the prototype and
the test results achieved so far.


        Following table summarises responsibilities and achievements of partners in
this task:

        Responsibility                    Partner                       Status
      Implementation of                    ETHZ                       completed
     alternative prototype

   Task responsible:           ETHZ
   Involved partners:          ETHZ, GL, BAL


   Deliverable 2.3:            Availability and   scalability report            (Document
                               deliverable) and software prototype               (Prototype
   Responsible:                ETHZ
   Due date:                   Month 24 (September 15, 2000)

TASK 3.1 Implementation of the Quality Chain


       First prototype being in use at the end users with dummy data exchange,
which includes test data (dummy data) preparation, module and system
configuration, bilateral/multilateral scenario and intra-organisational connection
implementation, and testing of authentication and authorisation module.


Within task 3.1 the two software systems developed by METU and ETHZ,
respectively have been deployed at the industrial partners' sites. Experiences gained
during these installations as well as a number of tests were documented. For each
components of those workflow system the following steps have be tested
successfully: installation, configuration and customisation, execution and
maintenance (including updates). Functionality available to the end user and usability
of the tools was investigated. After the tools had been installed and configured
properly, multiple tests were executed corresponding to the different phases in the
life cycle of a workflow: definition, enactment (execution), monitoring & analysis, and
co-ordination and communication to check that the installation works properly.
         Further questions were of interest, e.g., whether multiple instances of a
component could run at the same site, or even on the same machine and what are
potential sources of conflicts. It will be addressed which of the components can run
independently and what dependencies are inherent. In terms of usability the number
of redundant entities during configuration and the explanatory texts for the input fields
were investigated.
The installations were generally tested under different operating systems, in
particular under SOLARIS 2.6, Linux and Windows NT. Tests included both, client
and server installation. Installation and configuration was done component-wise,
determining who needs to install it, where and what are the necessary prerequisites.
For any workflow system to be used in production there is a strong requirement for
security. This problem is tackled by a number of measures. First of all mechanism for
message encryption has been developed and implemented within task 2.5 of this
project. As this solution is based on asymmetric encryption, it requires handling, i.e.
generation, distribution and storage of public and private keys for all participants
involved in the workflow.
As the use of corporate firewalls is get standard practise, it is necessary to assign
dedicated TCP/IP ports for communication. These ports can be customised and
controlled. Usual practise is to limit access to a port as far as possible. The following
questions were considered:
 Which ports are needed for which communication?
 Are the other workflow participants always connecting from the same machine?
 If yes, the IP number(s) of those machine(s) need to be supplied.
 Are these IP addresses visible to the outside world?
 Is it intended to use the same port used for incoming and outgoing
In order to define a workflow one needs to define its elements: actors, variables,
process information and activities. For both prototypes similar, but not identical test

cases have been chosen. The test cases expose a level of increasing complexity,
focusing at particular functionality of a component to be demonstrated. For all test
cases, textual workflow definition were documented in the deliverable.
For prototype 1, bilateral exchange of a simple document, trilateral exchange of a
modified document and document roundtrips were tested. For prototype 2, a series of
tests both bilateral and multilateral were executed with a single server was installed
at ETHZ involving ETHZ, BAL and GL. Different tests were executed, varying the
size of transferred documents. Since the performance of a running process depends
on how many process instances are being executed by the workflow server at that
particular moment, we have tried to determine how long it takes for our document
transfer process to finish if several instances are started simultaneously.


        Responsibility                 Partner                     Status
    Preparation of test data       GL, BAL, SZAG                 Completed
         (dummy data)
      Configuration of the         GL, BAL, SZAG                 Completed
Implementation of a bilateral      GL, BAL, SZAG                 Completed
      Implementation of a          GL, BAL, SZAG                 Completed
     multilateral scenario
 Implementation of the intra-      GL, BAL, SZAG                 Completed
  organisational connections
   Test of the authentication      GL, BAL, SZAG                 Completed
   and authorisation module
    Task responsible:         GL
    Involved partners:        GL, BAL, SZAG

   Deliverable 3.1:          First prototype in use at the end users with dummy data
   Responsible:              GL
   Due date:                 Month 20 (May 15, 2000).

TASK 3.2 Tuning, Testing and Optimization of the System


       After the delivery of the first prototype, testing and tuning will need to be
performed continuously to ensure the industrial strength of the system. This will
require the tuning of most components as the system is tested as a whole in a real
environment. The task will include the test of the implemented systems by the
developers with real data as opposed to dummy data.


        Extensive tests have been carried out with respect to various aspects of the
two prototypes. Workflows of different complexity were defined. A large number of
process instances were running simultaneously and over a relatively long period of
time. Performance and load issues were investigated. Tests were run both in a local
mode, but also over the Internet. While most of the tests conduiceted for prototype 1
were interactive, prototype 2 was operated mainly in a passive mode, i.e. user
interaction were not required in this phase.


      Responsibility                  Partner                      Status
    Testing of a bilateral         METU,GL, BAL                  Completed
    Testing of multilateral        METU,GL, BAL                 In progress

   Task responsible:          BAL
   Involved partners:         METU, GL, BAL, SZAG, ISISAN, ETHZ, Hebrew

   Deliverable 3.2:           Improved modules and interfaces
   Responsible:               BAL
   Due date:                  Month 27 (December 15, 2000).

TASK 3.3 Providing Continuous Feedback to the System
Design and Development


       Formal and informal user test reports and continuous feedback to the system
design and development, and practical test of modules and systems in a real
environment operated by the users. Use of the prototype in production.


During this reporting period, a number of practical tests have been carried out for
various releases of both prototypes. Feedback on both system was provided mostly
in terms of bug reports during the testing. Also potential extensions, i.e. "nice-to-
have" features were reported. Details of tests are available from the web, see e.g., but a more extended version is contained
in Deliverable 3.1. "Real" end users from the respective production departments have
been introduced to the system. Their comments were taken into account during the
development of new releases. Network connections have been established for
Hannover office of GL and software is currently being installed enabling remote
usage of the system in a test mode.
Simultaneously, efforts are underway aiming at the release of data from production
for usage inside the project.


      Responsibility                Partner                         Status
  Practical test of modules  GL, BAL, SZAG, ISISAN               In progress
    and systems in a real
  environment operated by
 Usage of the prototype in a GL, BAL, SZAG, ISISAN               In progress
       real production
    Providing continuous     GL, BAL, SZAG, ISISAN               In progress
 feedback to system design
      and development

   Task responsible:         SZAG
   Involved partners:        SZAG, GL, BAL, ISISAN


   Deliverable 3.3:          Formal and informal test reports.
   Responsible:              SZAG
   Due date:                 Month 27 (December 15,2000).

TASK 3.4 Final Code Release


       Delivery of final system to the users


        The code release has started with development of the second prototype.The
implemented prototype has been revised and modified to include all of the system
functionalites and has been installed at industrial partners’ sites. This system is
currently being tested and modified according to the bug and maitenance reports
from the companies, and final version of the code will be released after realizing the
necessary modifications.


      Responsibility                  Partner                       Status
   Final system delivery to     METU, ETHZ, Hebrew               In progress

   Task responsible:          METU
   Involved partners:         METU, ETHZ, Hebrew


   Deliverable 3.4:           Final system delivered to the users.
   Responsible:               METU
   Due date:                  Month 27 (December 15, 2000).

TASK 4.1 Administrative Management


       Preparation of financial reports include:

       a)     Periodic Cost Statements (PCS)
       b)     Consolidated Cost Statements


Administrative project management tasks progressed in accordance to the Technical
Annex. A financial report was prepared according to the guidelines based on
individual Periodic Cost Statements from each partner. After double checking against
the previously submitted Task Level Summary reports, a Cost Statement Summary
was compiled and submitted to the Commission. Upon release of the new payment
the shares were distributed among the project partners. Not all costs items were
approved as submitted, therefore further communication with the Commission was
necessary. Additional cost details (person names, exchange rates) were collected
and provided to the Commission. For the running period, new data from TLS were
Assistance was provided to the technical manager for organisation of technical
meetings and workshops. An overview of resources in the project was prepared and
made available.


      Responsibility                    Partner                   Status
  Periodic Cost Statement                 GL                     Achieved
    Consolidated Cost                     GL                    Not started
    Statement Delivery

   Task responsible:          GL
   Involved partners:         GL

TASK 4.2 Technical Management


       Co-ordination of Requirements and Specifications, Systems Development,
Project Milestones and Deliverables, End Users and Developers. This task also
includes delivering Periodic Management Reports, 6-monthly.


      Three Periodic Management Reports have been released within first 18
months of the project. Systems development, project milestones, deliverables and
end users and developers have also been co-ordinated within this period.

      Responsibility                 Partner                    Status
       Co-ordination of              METU                    In progress
     Requirements and
 Co-ordination of Systems            METU                    In progress
  Co-ordination of Project           METU                    In progress
Milestones and Deliverables
Co-ordination of End-Users           METU                    In progress
       and Developers
 Periodic Progress Report            METU                    In progress
    Final Report Delivery            METU                    In progress

   Task responsible:          METU
   Involved partners:         METU

TASK 4.3 Dissemination of Results


       Dissemination of the project results to a widest audience possible through
publications and workshops.


A project web site has been set up by the project leader.

Individual web pages have been setup by various partners (e.g., …)


       Responsibility                  Partner                          Status
        Deliverables             METU, GL, BAL, SZAG                 In progress

    Task responsible:          METU
    Involved partners:         METU, GL, BAL, SZAG

Information dissemination activities

The following publications related with the MARIFlow project are realized within this
reporting period:

   Dogac, A., Tambag, Y., Tumer, A., Ezbiderli, M., Tatbul, N., Hamali, N., Icdem, C.,
    Beeri, C., “A Workflow System through Cooperating Agents for Control and Document
    Flow over the Internet”, in Proc. Of the Intl. Conf. on Cooperative Information Systems
    (CoopIS ’00), Israel, September 2000.

   Dogac, A., Tambag, Y., Tumer, A., Ezbiderli, M., Hamali, N., “An Agent-based
    Workflow System for Inter-enterprise Business Processes”, in Proc. of European
    Commission’s eBusiness and eWork Conference and Exhibition, Madrid, Spain, October

   U. Langbecker, M. Lehne, G. Alonso; "How to support material certification as
    virtual business process", Proceedings of the International Conference e-business
    for Industry, London, June 20-22, 2000

   U. Langbecker; "How to support material certification as virtual business
    process", 3rd WONDER MAR Public Workshop, Copenhagen, May 26, 2000

   U. Langbecker; "Möglichkeiten zur elektronischen Unterstützung der
    Materialzertifizierung" (in German), workshop of the Association of German
    Mechanical Engineers (VDMA), Hamburg, July 4, 2000
   M. Lehne, "quality certificates through co-operating agents via internet , an inter
    company workflow service for the maritime industry", Conference
    daratechMarine2000 , January 24-26, 2000 in Houston Texas

A number of presentations of project results were given by the project partners at the
WONDER MAR workshop, to the German Association of Mechanical Engineers
(Maritime branch) and at the International Conference on "e-Business for Industry".

                                                           DELIVERABLES TABLE

Project Number: INCO DC 97-2496                                Project Acronym: MARIFlow

Title: A Workflow Management System for Maritime Industry

Del. No.          Revision Title                                      Type       Classification Due Date           Issue Date
Deliverable 2.3            Availability and Scalability (Prototype)   Report and Restricted     September 15, 2000 Sept.15, 2000
Deliverable 3.1            Implementation of the Quality Chain        Report     Restricted     May 15, 2000       Sept. 12, 2000

                          DELIVERABLES SUMMARY SHEET

Project Number: INCO DC 97-2496

Project Acronym: MARIFlow

Title: A Workflow Management System for the Maritime Industry

Deliverable No: 3.1 Due Date: May 15, 2000        Delivery Date: September 12, 2000

Short Description: This document describes how the two prototype systems developed
in the project have been deployed at the industry partners' sites. Starting from the
system architecture, all components were installed and tested individually.
For each of the components installation, configuration and customization, execution
and maintenance had to be completed successfully before the system was functional.
After this, multiple tests were applied corresponding to different phases in the life cycle
of a workflow: definition, enactment (execution), monitoring & analysis. The systems
were tested on multiple platforms delivering good results. Prerequisites were analyzed
and sets of test data had been prepared and used in bilateral and multilateral
scenarios. Experience gained during these installations is described in the report. A
number of sample workflow which have been used for the test are provided. The annex
contains sample configuration files and workflow definitions.

Partners owning: GL
Partners contributed: BAL, SZAG, ETHZ, METU
Made available to: All

                          DELIVERABLES SUMMARY SHEET

Project Number: INCO DC 97-2496

Project Acronym: MARIFlow

Title: A Workflow Management System for the Maritime Industry

Deliverable No: 2.3 Due Date: Sept. 15, 2000        Delivery Date: Sept. 15, 2000

Short Description: After the modification of the technical annex, the goal of Task 2.3
became the development of an alternative prototype that could be used for the
scalability and availability tests required by the original Task 2.3. In doing this, we tried
to come up with a design that would be suitable for the different participants in the
certification process. The design was based on the WISE system, developed at ETHZ,
which was tailored to the concrete needs of MariFlow. The work in this deliverable has
involved a practical component (implementation of the prototype) and a
testing/deployment component (actual testing of the prototype by the industrial
partners. Some of the test results are also to be found in Deliverable 3.1). In both
cases, the work performed considerably improves the current state of the art. The main
conclusion of the initial experiments conducted as part of this task is that the WiseFlow
system satisfies the requirements specified at the beginning of the project in terms of
functionality, scalability, and availability. The most important of their requisites is that
the system should be able to support around 3.000 certifications per month. In spite of
the limitation imposed by the current configuration (of 20 process instantiations per
hour), the WiseFlow system proved to be able to execute that many processes in a
week. Thus, WiseFlow adequately answers the requirements of the industrial partners
as stated in earlier deliverables and has proven scalable and reliable enough to be
used in practical applications.

Partners owning: ETHZ
Partners contributed: GL, BAL, SZAG
Made available to: All

Planned Work for the Next Reporting Period

         The following is the list of tasks that will be active for the next reporting period.
The due dates of deliverables and the current progress related with the deliverables
that will be completed in the next reporting period are already presented in the previous

Work Package 3: Prototype Demonstrator

    Leader:            SZAG
    Duration:          Months 1-27

   Task 3.2: Tuning, Testing and Optimization of the System

    Duration:          Months 1-27
    Responsible:       BAL

   Task 3.3: Providing continuous feedback to the system design and

    Duration:          Months 1-27
    Responsible:       SZAG

   Task 3.4: Final Code Release

    Duration:          Months 9-27
    Responsible:       METU

Work Package 4: Management and Dissemination of Results

    Leader:            METU
    Duration:          Months 1-27

   Task 4.1: Administrative management
    Duration:       Months 1-27
    Responsible:    GL

   Task 4.2: Technical management
    Duration:        Months 1-27
    Responsible:     METU

   Task 4.3: Dissemination of Results
    Duration:       Months 9-27
    Responsible:    METU


Shared By:
Description: Building Maitenance Management Templates document sample