1. Web services-based collaborative system for distributed engineering
Adam Pawlak
Paweł Fraś
Piotr Penkala *
Silesian University of Technology
Inst. of Electronics, Collaborative Engineering Group
Gliwice, Poland
also Evatronix SA
PRO-VE'08 9th IFIP Working Conference on Virtual Enterprises
Poznań, Poland,

2. Outline Collaborative engineering for distributed product development
Challenges in collaborative design
MAPPER project objectives and approach
MAPPER collaborative infrastructure
Requirements for distributed tool integration
TRMS - Tool Registration and Management Services
New TRMS architecture
Deployment of TRMS
Conclusions

3. Collaborative engineering
is an innovative method for product development which integrates widely distributed engineers for virtual collaboration.
[Cutkosky, MADEFAST, Communicat. of the ACM, Sept. 1996]
shared eng. data
real-time communicat.
interactivity
Distributed collaborative engineering
Concurrent engineering
A competitive marketplace dictates that this process of enterprise-wide engineering be performed in a rapid, yet safe manner. The efficiency of computers and networks today means businesses are able to simultaneously create, analyze, and modify designs, streamlining the engineering design process. This evolution is defined as collaborative engineering. [Bentley96]
Objective:
distributed design
of the optical seeker

4. Why collaborative engineering in electronics
Time to market vs design complexity is since „ever” the most significant factor for new product creation
Thus, increase of design productivity is one of the major objectives within the SoC domain resolved by:
Structured design methodology with IP design reuse
Designing on higher levels of design abstraction
Collaborative design is another approach allowing to increase design productivity of electronic systems with:
Easy and close collaboration of widely distributed engineers being experts in different domains and in different design flow phases
Controlled remote access to expensive design tools, etc.

5. Infineon’s pan-European distribution
Courtesy:Dr. Matthias Bauer, Infineon Technologies

6. Our motivation for collaborative design
Supporting integration of SMEs into complex design inter-organisational workflows

7. Selected Challenges in Collaborative Engineering
Establishment of an efficient collaborative engineering environment requires solving at least the following problems:
Collaboration with organisations protected behind firewalls
Data format conformity, etc.
Easy tool integration with standard support for:
Tool description
Design task description
Workflow description
Secure design data transfer
Support for human actors – engineers collaborative actions
Appropriate collaborative workspaces
Advanced synchronous and asynchronous communication
Dodatkowe wymagania:
- Akumulacja design patterns

8. SMEs collaboration perspective
In this work we take an SME perspective for companies distributed engineering collaboration towards a common product.

9. TRMS - Secure integration of distributed tools
Secure integration of distributed design tools was the reserch goal of the Collaborative Engineering group at SUT since ~2000
Architecture of TRMSv1 was the first result achieved withing the EU project ECOLLEG

10. E-COLLEG Tool Registration and Management Services
TRMS operation protocol:
a: tool registers with profile
b: user asks for tool with constraints
c: registry checks constraints and returns profile
d: user lunches tool with input and output
e: tool fetches input and processes output f: destination fetches output
This first TRMS solution was verified in design scenarios involving Polish partners and large companies, like: Infineon Technologies and Thales Optronique (former Thomson CSF).
Podaj publikacje, gdzie pisaliśmy o wykorzystaniu TRMSa.
Animation

11. MAPPER context
We have addressed our didributed colaborative design problem in the context of the EU project MAPPER
MAPPER - Model-based Adaptive Product and Process Engineering
FP IST-NMP-2 Project No

12. Problem statement for MAPPER
The core problems in the area of faster and more flexible design and manufacturing (agile engineering) concern:
Quick and inexpensive formation of networked manufacturing organisations;
Achieving concurrency in all operations;
Bridging the gaps between heterogeneous knowledge, processes, systems, services, and ways of working;
Support rapid reconfiguration of required processes and products to accommodate diverse and changing needs and opportunities;
New, cross-partner knowledge which continuously created and must be shared, executed on and managed.
The strong stress on knowledge representation and modelling.

13. Challenges in collaborative design
Concurrency in all operations, increasing design efficiency and decreasing time-to-market.
Quick and inexpensive formation of networked design organisations.
Processes and products should be rapidly reconfigured to accommodate diverse and changing needs and opportunities.
Change management across the entire design chain requires coordination of individual changes and support for iterative adjustments. Collaborative product, process and service engineering must thus be managed and performed across networked organisations.
Integration of tools of remote groups of engineers with adequate for industry solutions for: security, distributed inter-organization workflows, and remote administration of users and tools.

14. The Vision of MAPPER
In 2015, agile design and manufacturing companies can inexpensively form collaborative networks and quickly adapt to market demands.

15. Scientific and technological objectives of MAPPER
O1: Reconfigurable visual enterprise models of products, processes and other enterprise aspects;
O2: Participative engineering methodologies, enabling joint product and process design, interdisciplinary and inter-organisational collaboration throughout multiple product life-cycles;
O3: Customisable work environments for different stakeholders, roles and tasks;
O4: Secure collaboration platform, enabling enterprises to access each others engineering tools and product data in an open, yet secure manner;
O5: To develop and assess three industrial use-cases, and to validate the overall MAPPER approach:
- automotive industry (Fiat) and automotive components supplier (Kongsberg Automotive, SWE, N, PL)
- electronics industry (IP components supplier, Evatronix, PL)
O6: To ensure early and continuous exploitation of results.

16. MAPPER approach
Integrate enterprise modelling, human-centred methodologies, collaborative customisation, and secure, distributed tool invocation, into an open, visual, holistic, and reconfigurable collaboration platform
Standard-based Interoperability Framework
Customisable
work
environments
Participative methodology
Reconfigurable models
Secure service integration platform

17. Participative engineering methodology
A method of engineering involving personnel from several areas, possessing different knowledge and skills, responsible for performing various roles in an engineering process.
This methodology aims at integrating product, process and service engineering and have the components:
Networked manufacturing enterprise modelling
Formation and operation of sustainable collaboration
Inter-organisational learning
Multi-project portfolio management
Zwiększają efektywność działań wytwórczych poprzez wspieranie zintegrowanego planowania, zarządzania i wykonywania zadań inżynierii rozproszonej i partycypatywnej.
Wspierają innowacje i systematyczne ulepszanie organizacji firmy poprzez dostarczanie usług dla definiowania, planowania, zarządzania, realizowania, adaptowania i powtórnego wykorzystywania zadań.
Umożliwiają uczenie się z byłych doświadczeń na poziomach organizacyjnym, zespołowym oraz indywidualnym.
Ma to być osiągnięte poprzez gromadzenie, oszacowanie i powtórne wykorzystywanie modeli oraz ich konfiguracji w trakcie ich wykonywania (ang. execution).
Dostarczą usługi i konstrukcje do wspierania wszystkich głównych celów modelowania firm i tworzenia rozwiązań.

18. Reconfigurable models
Active knowledge modelling
An approach used to construct live networked manufacturing enterprise models.
AKMs describe the relevant resources, aspects, views, methods and rules to externalise and facilitate knowledge-driven, adaptive collaboration and learning.
Visual modelling and visual scenes.
Visual modelling as a more powerful representation means for sense making: in using systems and in modifying systems.

19. What’s AKM - Active Knowledge Modelling
Co to jest AKM:
Model jest tworzony przez użytkowników realizujących zadanie
Modele są dostępne w czasie realizacji (execution time)
Wsparcie dla ewolucyjnego współbieżnego modelowania i realizacji
Identyfikacja wiedzy o firmie i budowanie konsensusu
Pro-aktywne uczenie i budowanie zespołu
Wsparcie socjalne i organizacyjne
Dlaczego różni się od innych strategii
Wzorniki są adaptowalne lub tworzone w czasie modelowania
Wspiera modelowanie jako wielowymiarowy proces
Umożliwia stosowanie różnych perspektyw
Wspiera ewolucję języków modelowania i projektowania
AKM musi być wsparty zintegrowaną platformą do modelowania
i realizacji modeli
Strategie i metodologie muszą być adoptowalne

20. AKM model of a distributed collaborative design realised by two SMEs
AKM in Electronic Design Domain
Figure 1 presents an example of an IP component development process represented as a visual active knowledge model.
The active model comprises a set of hierarchical visual objects that represent the processes of specification, development and productization (product preparation), the definition of information technology (IT) infrastructure, company organisation charts, design data and engineering knowledge structure

21. Why active models ?
Representation must be available to the users of the information system at runtime
Model must influence the behaviour of the underlying computerised system
Model must be dynamic and reconfigurable, users must be supported in changing the model to fit their local reality, enabling tailoring of the system's behaviour
Refer to Active Knowledge Modelling at:

22. Secure service integration platform
Basic services needed for collaborative enterprise modelling and execution
Modelling services
Model execution services
Collaboration services
Secure tool integration services
Secure services-based collaboration platform that enables companies to access shared engineering tools and data on products in a user and secure collaboration friendly way is the goal.

23. Customizable work environments
User interfaces integrating all the software and information needed to perform a particular task
Packaging functionality according to the user needs and expectations
Customisation and contextualisation
Flexible work environments adaptable for various partners, roles and tasks
The collaborative platform should enable companies offering (e.g. design) solutions and their customers to commonly adapt and configure their work environment

24. Collaboration infrastructure
Needed to support networked manufacturing between heterogenous enterprises.
Includes information and communication technology
Integrates services in the platform
Enables sharing of representations of partner’s technical capabilities and resources

25. MAPPER collaboration infrastructure
Tworzona jest w oparciu o cztery środowiska:
METIS (AKMii) (Troux Technologies)
Customisable shared workspaces from CURE (Univ. Hagen)
Synchronous collaboration services developed at FhG/IPSI (Concert Chat)
TRMS – Secure Tool Integration Services (PŚ)

26. Layers of Services on Top of AKM MAPPER approach towards CWE -2-

27. Requirements from MAPPER
AKM - Active Knowledge Model paradigm
Services context from MAPPER
Integration within MAPPER collaborative platform
Profound requirements engineering process
SourceS of requirements:
– Evatronix and advICo engineers
Reflections from the SUT R&D team
Ethnografic fields studies at companies sites done by social sciences experts

28. Figure of MAPPER integration platorm

29. Requirements modelling as AKM
Requirements from Evatronix modelling in METIS
Social scientists were performing ethnographic field studies. Observations and conclusions were assembled in reports that were provided as additional requirements to research & technology teams working on the collaboration infrastructure

30. TRMS development path TRMS 1 TRMS 1.1 TRMS 1.2 TRMS 2 2003 2005 2006
E-Colleg result
application
ANTS transport mechanism
partial firewall crossing
TRMS 1.1
initial version for MAPPER
application
own transport mechanism
no firewall crossing
2003
TRMS 1.2
developed in MAPPER
applet
own transport mechanism
service-based functionality
2005
2006
TRMS 2
new architecture
application
http/https transport mechanisms
firewall crossing
2007

31. TRMS - Secure integration of distributed tools
Architecture of TRMSv1 – ECOLLEG result

32. TRMS 1.0 Result of the E-Colleg project Application version
Limited functionality in the firewalled networks (with ANTS transfer mechanism)
User authentication with keys
Implemented internal security mechanisms

33. TRMS 1.1 (initial version prepared for MAPPER)
Application version
No ANTS transfer mechanism
ANTS replaced with own developed transfer solution (no firewall crossing, it is not sufficient for pilot 3 needs)
Applied in pilot 2 deployment phase (middle 2007)

34. TRMS 1.2 Developed for integration within MAPPER infrastructure
New Web services developed
Applet version
Limited security level and functionality but easier to be integrated
Integration with Metis environment

35. TRMS 2.0 motivation
Based on experiences with versions 1.x in E-Colleg and MAPPER projects
User requirements from Evatronix engineers
Limitations of the previous versions
Integration needs of MAPPER e-team

36. TRMS 2.0 architecture
The main component of TRMS is the GTLS server. It is responsible for management of elements of the environment. GTLS is also responsible for the security policy of the whole environment, registration of user activities and of access to tools, maintaining statistics, identification of an intruder attack. GTLS, as the only component of the TRMS environment should be accessible from the Internet. In such case, GTLS plays a role of a broker and a temporary repository in a communication between a Client Application and Tool Servers.
A relational data base is used as the main data repository for GTLS. DB contains information on users and their privileges, TSs, registered tools, and workflows.
Figure 1 - General architecture of the TRMS environment
GTLS has been implemented as a set of Web Services (Apache AXIS). Selected Web services have been shortly characterised below.
Administration
The administration services are responsible for registration and modification of data on users and their privileges, elements of the system, as well as, information on accessible tools and machines that make them available.
User and Server Authentication
Login to GTLS is the first task a user is expected to do upon invocation of the Client Application. User authentication is performed then. As soon as a user/designer logs in, a new session is created and a user receives its key. Tool Servers are authenticated automatically upon their invocation.
Task Management
Each tool that is expected to be accessible over the network needs to be registered and placed in the task queue. Registration involves determination of necessary data for tool invocation, like: tool name, complete path to tool location, and information on the Tool Server on which the tool resides (as well as additional data on the tool: its description, author, creation date). Registration can be conducted by a user with appropriate privileges. The task queue constitutes a set of refined task instances that comprise in addition to information on the tool, also data on the particular refinement (status and information on messages that result from tool invocation, like std output, std error).
Workflow Management
A workflow constitutes a set of tasks that are in the task queue. The current implementation supports sequential workflows.

37. GTLS Global Tool Lookup Service
Responsible for management of elements of the environment and security policy
GTLS is the only TRMS component accessible from the Internet
Communication broker Client – Tool Invoker
GTLS plays a role of a broker and a temporary repository in a communication between a Client Application and Tool Servers.
GTLS cooperates with SQL data base
DB contains information on users and their privileges, TSs, registered tools, and workflows.
(Design) data management
Implemented as a set of Web Services (Apache AXIS).
The main component of TRMS is the GTLS server. It is responsible for management of elements of the environment. GTLS is also responsible for the security policy of the whole environment, registration of user activities and of access to tools, maintaining statistics, identification of an intruder attack. GTLS, as the only component of the TRMS environment should be accessible from the Internet. In such case, GTLS plays a role of a broker and a temporary repository in a communication between a Client Application and Tool Servers.
A relational data base is used as the main data repository for GTLS. DB contains information on users and their privileges, TSs, registered tools, and workflows.
Figure 1 - General architecture of the TRMS environment
GTLS has been implemented as a set of Web Services (Apache AXIS). Selected Web services have been shortly characterised below.
Administration
The administration services are responsible for registration and modification of data on users and their privileges, elements of the system, as well as, information on accessible tools and machines that make them available.
User and Server Authentication
Login to GTLS is the first task a user is expected to do upon invocation of the Client Application. User authentication is performed then. As soon as a user/designer logs in, a new session is created and a user receives its key. Tool Servers are authenticated automatically upon their invocation.
Task Management
Each tool that is expected to be accessible over the network needs to be registered and placed in the task queue. Registration involves determination of necessary data for tool invocation, like: tool name, complete path to tool location, and information on the Tool Server on which the tool resides (as well as additional data on the tool: its description, author, creation date). Registration can be conducted by a user with appropriate privileges. The task queue constitutes a set of refined task instances that comprise in addition to information on the tool, also data on the particular refinement (status and information on messages that result from tool invocation, like std output, std error).
Workflow Management
A workflow constitutes a set of tasks that are in the task queue. The current implementation supports sequential workflows.

38. GTLS (main) web services
Administration
Administration services are responsible for registration and modification of data on users and their privileges, elements of the system, as well as, information on accessible tools and machines that make them available.
User and Server Authentication
Upon user/designer logs in, a new session is created and a user receives its key. Tool Servers are authenticated automatically upon their invocation.
Task Management
Each tool that is expected to be accessible over the network needs to be registered and placed in the task queue. Registration involves determination of necessary data for tool invocation.
Workflow Management
A workflow constitutes a set of tasks that are in the task queue. Current implementation supports sequential workflows.
GTLS has been implemented as a set of Web Services (Apache AXIS).
Selected Web services have been shortly characterised below.
Administration
The administration services are responsible for registration and modification of data on users and their privileges, elements of the system, as well as, information on accessible tools and machines that make them available.
User and Server Authentication
Login to GTLS is the first task a user is expected to do upon invocation of the Client Application. User authentication is performed then. As soon as a user/designer logs in, a new session is created and a user receives its key. Tool Servers are authenticated automatically upon their invocation.
Task Management
Each tool that is expected to be accessible over the network needs to be registered and placed in the task queue. Registration involves determination of necessary data for tool invocation, like: tool name, complete path to tool location, and information on the Tool Server on which the tool resides (as well as additional data on the tool: its description, author, creation date). Registration can be conducted by a user with appropriate privileges. The task queue constitutes a set of refined task instances that comprise in addition to information on the tool, also data on the particular refinement (status and information on messages that result from tool invocation, like std output, std error).
Workflow Management
A workflow constitutes a set of tasks that are in the task queue. The current implementation supports sequential workflows.

39. Tool invoker Responsible for: Fetching of input data
Program invocation
Dispatching of console messages
Sending of results
Constant connection with GTLS isn’t required
Client mode

40. Client application Two versions: Tiny vs. Fat Client (adminstrator)
Constant connection with GTLS isn’t required (one may invoke a design task and switch of the client application)

41. TRMS 2.0 new functionality versus versions 1.x
Support for work in the networks with NAT and firewalls Communication is always initiated by either tool servers or client applications. Tool server (tool invoker) polls for a job to do.
Support for long jobs
Client app can be switched off during the job execution on a tool server.
Actual job status and output results are available during the consecutive log-in.
Support for a sequential workflows
Next task is executed under the control of GTLS after the previous one is over.
Access to console output messages of the invoked tool
A number of users can access and control the execution of a task

42. Used technologies Java SE 6 Apache Tomcat 5.5 (lub 6)
Apache AXIS 1.3 (lub 2)
Hibernate
HSQL (MySQL, PostgreSQL)
appframework, jdesktop

43. TRMS 2.0 achievements (technology and architecture)
New TRMS architecture is based on Web services thus supporting (MAPPER) integration with other Collaborative Working Environmnts
Both applet and application versions are available
Secure transmission channel, optional
encoding using keys
Transfer based on standard https or http protocols
Deployed in MAPPER pilots 2 and 3
(intra-) and inter-company distributed
tool integration
New architecture developed (old terminology kept)

44. Security Secure transmission channel Optional encoding using keys
Level of user privileges (unix, xwr, group)
Bezpieczny kanał transmisyjny
Opcjonalnie szyfrowanie za pomocą kluczy
Poziom uprawnień użytkownika (unix, xwr, grupy)

45. TRMS 2.0 plans
Extend functionality and user interface (e.g., user awareness, event notification service)
Development of a more advanced workflow management system

46. USB PHY design challenges in MAPPER
TRMS deployment
USB PHY design challenges in MAPPER
Experts were needed from two different designers’ worlds: analogue and digital
The design environment is distributed (2 companies, 3 locations)
Problems with interoperability of current design tools (different domains, different file formats)
We have chosen USB PHY design process as a technical base for MAPPER experiments because:
The USB design comprises basically two main and principally different parts, namely the analog and digital ones. Both advICo and Evatronix have profound experience in designing ones part (advICo the analog part and Evatronix the digital one) and very limited knowledge on the partner’s part. Distribution of a workload among both companies that was based on an optimal partition of designed components according to ones competence and resulting in transceiver comprising parts well matching each other was a hard task.
Another challenge was due to a distance between both companies, and also two branches of the Evatronix company. This makes it difficult to have direct discussions and also experiments with the partners tools which are needed for the verification of the full design. (Here support came from e.g. deployment of the CURE environment.)

47. Evatronix and advICo workflows
Each company has well defined own design flow
advICo Design Flow
Component specification
Development
Verification
Industrial partners of Use Case 2, both Evatronix and advICo, have well established development processes in their competence domains of electronic circuit design.
Although, the realization of USB PHY component requires expertise both in analogue circuit design (which advICo masters) and in digital circuit design (which is the Evatronix’ field).
This project was, however, a great challenge for both companies, because it required very close collaboration to get a one common product made of different but perfectly compatible building blocks.
In this case none of partners has deep knowledge in the other’s design field and the companies have never collaborated before.
The questions arising at the beginning of the common project were:
- how to plan collaborative activities to reach a successful project finish
- what a common design methodology to apply to develop a correct complex component as a result of two independent design processes
Product preparation

48. Distributed design and verification between advICo and Evatronix
Integration of USB PHY digital and analogue design flows was a problem
advICo
Design
Flow
Evatronix
Analog and Digital Block integration
To face a challenge of collaborative design of a USB component companies decided to apply a model-based approach delivered by MAPPER.
We used METIS modeling tool to develop a visual representation of design processes. First, we modeled independent design flows at Evatronix and advICo. Then, we combined the developed flows to create a common model of a joint digital-analog design process.
Thanks to the active use of a model we managed to optimize the flow in order to increase efficiency of the process realization (in terms of time and cost).

49. Active Knowledge Model of common USB PHY design flow
To face a challenge of collaborative design of an USB component we decided to apply a model-based approach delivered by MAPPER.
We used METIS modeling tool to develop a visual representation of design processes. First, we modeled independent design flows at Evatronix and advICo. Then, we combined the developed flows to create a common model of a joint digital-analog design process.
Thanks to the active use of a model we managed to optimize the flow in order to increase efficiency of the process realization (in terms of time and cost).

50. Pilot 3 USB-OTG-PHY design coverage
Integration &Verification of whole USB PHY design was a scope of the Pilot 3
After combining the initially separate design flows and developing the joint process we analyzed the model from the point of view of the design methodology. We discovered several issues possible to be improved.
In particular, we have noticed what we called the USB PHY long analog simulation problem. One of the objectives of this presentation is to show how we applied MAPPER infrastructure to deal with the simulation issue. An experiment validating our approach to this case was part of Pilot 3.
A digital part of a USB component developed at Evatronix is transferred to advICo where a process of integration begins.
One of the most important steps in this integration is circuit simulation in the analog signal domain. Typically, the analog simulation is a lot of longer than the digital one. This is a factor that heavily influences overall project duration. It is usually solved by use of high performance but very expensive hardware equipment, if the company can afford it.
We decided to take another approach to resolve this problem and shorten the development time. We applied MAPPER tools to support, and partially replace, time-consuming analog simulation by less accurate but very fast digital simulation.
To do so analog designers at advICo were enabled to control simulation and to access its results though the MAPPER infrastructure. It allowed to do faster and two-step verification of the circuit. First, the rough results of digital simulation can be screened out and then a detailed analog simulation to test specific behavior can be performed.

51. Pilot 3 Distributed design and verification between Advico and Evatronix
Demo

52. Pilot 3 infrastructure
For the pilot 3 the following infrastructure was deployed:
At SUT were installed the following tools:
For the first – CURE server which has been used as an interface for the users
For the second – main TRMS server
And – CVS server which is used as a file repository
At Evatronix, the TRMS tool server was installed which is connected to the Evatronix machine which can perform the digital simulations
At Advico the TRMS tool server was installed which is connected to the Advico machine which allows viewing the digital verification results

53. Pilot 3 – step1 – Digital design + tests
1) Evatronix develops the USB PHY digital code, prepares tests for this component and writes verification results to the VCD files. These files show USB PHY behavior on the analog-digital interface. They can be used as a point of reference during integration both USB PHY parts (D+A) for checking correct behavior of integrated parts.
2) Evatronix verification results are written to the CVS. Also advICo has access to this CVS.
3) The descriptions of these tests are available in the CURE system. => Digital Tests

54. Pilot 3 – step 1
1) Evatronix develops the USB PHY digital code, prepares tests for this component and writes verification results to the VCD files. These files prepared in Evatronix show PHY behavior on the analog-digital interface. Originally written to test digital part, they can be used as a point of reference during integration both PHY parts (D+A) for checking correct behavior of integrated parts.
2) Evatronix tests are written to the CVS. Also advICo has access to this CVS.
3) The descriptions of these tests are available in the CURE system. => Digital Tests

55. Pilot 3 – step 2 – Integration of both PHY parts
4) During integration of both PHY parts, when there is a need, advICo , using CURE portal, can find suitable test case with proper PHY behavior, download this test, and check it using browser of VCD files. Using this VCD browser for checking design behaviour is much faster then simulations in the analog simulator.
[run view]
After observations of digital verification results, advICo can simulate in the analog simulator only small part of whole waveform.
5) If Advico notify any discrepancy between PHY behavior in the digital simulator and after integration in the analog simulator, it can:
a) If there is a bug in the analog part, Advico fix it.

56. Pilot 3 – step 2
4) During integration of both PHY parts, when there is a need, advICo , using CURE portal, can find suitable test case with proper PHY behavior, download this test, and check it using browser of VCD files. Using this VCD browser for checking design behaviour is much faster then simulations in the analog simulator.
[run view]
After observations of digital verification results, advICo can simulate in the analog simulator only small part of whole waveform.
5) If Advico notify any discrepancy between PHY behavior in the digital simulator and after integration in the analog simulator, it can:
a) If there is a bug in the analog part, Advico fix it.

57. Pilot 3 – step 2 Digital waveform view
I would like to show you what is the difference between viewing in analog and digital simulators.
Here we can see the digital waveform.

58. Pilot 3 – step 2 Analog waveform view
And here we can see the analog waveform

59. Pilot 3 – step 3
b) If there is a wrong behavior in digital part, Advico request Evatronix for digital code correction (see diagram).

60. Pilot 3 – step 3
b) If there is a wrong behavior in the digital part, Advico requests Evatronix for digital code correction (see diagram).

61. Pilot 3 – step 4
6) If existing test cases do not decide where is a problem (in digital or analog), Advico can:
a) correct existing test case - using TRMS, Advico can invoke digital simulator at Evatronix with changed test case parameters, to re-generate VCD file
[gen]
b) request Evatronix for new test case (to check newcase in the PHY behavior), or for correction of existing test case.
7) Return to the point 2

62. Pilot 3 – step 4
6) If existing test cases do not decide where is a problem (in digital or analog), Advico can:
a)correct existing test case - using TRMS, Advico can invoke digital simulator at Evatronix with changed test case parameters, to re-generate VCD file
[gen]
b) request Evatronix for new test case (to check newcase in the PHY behavior), or for correction of existing test case.
7) Return to the point 2

63. CURE interface
Obecnie użytkownicy korzystają ze zintegrowanego interfejsu jakim jest CURE
Currently, users can use TRMS services using CURE interface. This interface is quite simple but as I mention before – it didn’t require any additional effort from end users to setup this interface, and it can be used almost everywhere where internet access is.

64. CVW interface
AKM zaproponowało również wykorzystanie swojego CVW jako interfejsu użytkownika. Dawałby on dodatkowe możliwości użytkownikowi, jednak z powodu zakończenia projektu MAPPER zanim integracja i pełna weryfikacja projektu USB PHY dobiegła końca interfejs CVW nie został wdrożony.
AKM proposed us to use CVW as an user interface. This interface was initially tested at Evatronix. It could give the additional possibilities to the end users.

65. Distributed design and verification of USB PHY design at advICo and Evatronix Conclusions feedback from companies
METIS – models of each company design process allow to develop the best common design process for this special (from each company perspective) USB PHY design
CURE – As this interface didn’t require any additional effort from end users to setup it, and it can be used almost everywhere where the Internet access is available.
TRMS – possibility of invoking it just from web browser, implemented security, remote invocation of different design tools. All these features support automatisation of design processes. TRMS helped Evatronix/advICo to use design tools more efficiently. Finally, it accelerated designers’ work
METIS – opis postępowania(workflow) każdej z firm umożliwił następnie optymalne zaplanowanie/zaprojektowanie wspólnego workflow dla całego projektu USB PHY
CURE – poprzez to że jest to aplikacja wymagająca po stronie klienta tylko przeglądarki internetowej jest to idealne środowisko integrujące różne narzędzia, i dające dostęp do nich z praktycznie każdego miejsca na Ziemi
TRMS – możliwość uruchamiania go jako apletu z przeglądarki, a także system obsługi zabezpieczeń (secure transfers), umożliwia zdalne wykonywanie zadań (bądź też całych grup zadań) ściśle uprzednio określonych. Automatyzuje to proces projektowy – pomaga w lepszym wykorzystaniu posiadanych zasobów sprzętowych oraz znacznie przyspiesza prace projektowe.

66. Conclusions
The TRMS architecture based on web services has the following advantages:
Enables easier integration with other collaborative environments,
GTLS as a communication broker enables use of tools that are installed in local networks on machines that are not visible from outside,
The new architecture supports also tools that require long computation times,
The environment is robust enough for transient problems in accessing the network,
It reduces demand for a broad bandwidth in accessing the network, and speeds up the overall the environment,
The use of the standard HTTPS protocol enables control of the network traffic.
Further R&D related to TRMS includes enhanced workflow management system and improved support for engineering teamwork with both synchronous and asynchronous collaboration.
The presented TRMS architecture and its functionality fulfil requirements for a secure collaborative infrastructure. The TRMS infrastructure supports tool integration and management. In our opinion, TRMS is a solution for distributed cooperating engineers and gives them a possibility for a simple invocation of distant tools. Distributed engineering work will become much easier if engineers are able to cooperate in larger networks with many registered tools. Their work will be accelerated and thus work costs will be reduced. A registered tool will provide a service to distributed design engineers. It is expected that the overload due to tool installation and configuration processes will be reduced. Additionally, encrypted and digitally signed messages assure a high level of security in sensitive design information exchange. TRMS constitutes the infrastructure well tailored to distance-spanning engineering collaboration in complex distributed product design.

67. Acknowledgements Presented work has been commenced within projects:
E-COLLEG (IST ), as well as
VOSTER (IST ), as well as
continued in the
- MAPPER project (FP IST-NMP )
Wojtek Sakowski and Szymon Grzybek from Evatronix.
MAPPER partners are acknowledged for their R&D efforts in respect to the presented collaborative infrastructure.
Dr. Havard Jorgensen (AKM) Oslo, Norway)
Svein G. Johnsen, SINTEF, Oslo (Norway)
Dr. Frank Lillehagen (AKM, Oslo, Norway)
Prof. Kurt Sandkuhl, Jönköping University, Jönköping (Sweden)
Dr. Till Schümmer, FernUniversität Hagen, Hagen (Germany)
are addressed at MAPPER partners:
Håvard Jørgensen, AKM AS, Lysaker (Norway) Svein G. Johnsen, SINTEF, Oslo (Norway) Kurt Sandkuhl, School of Engineering, Jönköping University, Jönköping (Sweden) Till Schümmer, FernUniversität Hagen, Hagen (Germany) Peter Tandler, FhG IGD, Darmstadt (Germany)

68. Available books CCE’06, Prague AITPL cluster book with MAPPER
contribution
CCE’07, Kraków
Preliminary Workshop materials
Book published by
GI in Lecture Notes
in Informatics

69. More information on MAPPER
Joint Call 2 : FP IST-NMP-2 (October )
Topic: IST-NMP-1 : Integrating Technologies for the Fast and Flexible Manufacturing Enterprise
Run: – (30 months)
comprises:
TRMS demo
TRMS documentation
MAPPER project papers and demonstrations
Information Society Technologies (IST) / Nanotechnology and nanosciences, knowledge based multifunctional materials, new production processes and devices (NMP)
Thank you for your attention!