Presentation is loading. Please wait.

Presentation is loading. Please wait.

Web services-based collaborative system for distributed engineering

Similar presentations


Presentation on theme: "Web services-based collaborative system for distributed engineering"— Presentation transcript:

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!


Download ppt "Web services-based collaborative system for distributed engineering"

Similar presentations


Ads by Google