Conference PaperPDF Available

INTEREST project - EP 25584 - Final review meeting

Authors:
  • Free Thinker @Moorea

Abstract

The INTEREST project, i.e. Esprit Proposal N°: 25584, stands for INTEGRATED ENVIRONMENT FOR DURABILITY & RELIABILITY DESIGN SUPPORT TOOLS. This project aims to develop a prototype integrated information system for the design and structural integrity analysis of metallic components, in a distributed business environment. The intention is to produce a major improvement in the sharing, exchange and flow of information between systems and engineers engaged in durability and reliability studies. The primary business objectives will be: - To improve the quality of the product assurance process so that it is work-flow enabled and thus repeatable and auditable, in accordance with ISO 9000; - To reduce design lead-time by around 5 % on a typical new automotive model through a reduction of around 30% in failures on prototype cast, forged and sheet material parts. The main result of the study will be the delivery of a prototype software system which will be commercialized within 1 year following the completion of the project. The system will be developed primarily to satisfy the requirements of the automotive industry although it will be generally applicable to all stress-bearing mechanical parts manufactured in large batches. The innovative basis of the system will be a new, workflow enabled, structural integrity assessment process and support tools which exploit: - Previous knowledge and ‘best practice’ through co-operative working with suppliers. - A single conceptual data model, based on STEP, which will include geometry, materials, fabrication, loading, analysis results and allowable stress data derived from mechanical testing. The model will enable this data to be accessed as if it were stored in a single database, even though it may be distributed across different systems. - A workflow control system for auditing durability and reliability processes for mechanical parts. - System architecture and its implementation on AIT-IP, with flexible access to STEP entities by means of engineering objects providing application specific views of distributed repository data over an Internet/Intranet. This will involve object sharing technologies such as JAVA.RMI, CORBA and COAST. The key inputs will be the core data model for engineering analysis that has been developed by the GEM project (ESPRIT 8894) supporting interoperability between the emerging data standards; STEP Application Protocols 209, 214, 223 and 229; and the AIP Integration platform (AIP-IP, ESPRIT 22148) with enhancements from the RiseSTEP project (EP20459) and OPAL (EP20377).
INTEREST project
Review report
12 th
November 1999, Brussels
Patrice Poyet
CSTB
BP 209
06904 Sophia Antipolis Cedex
poyet@cstb.fr
Introduction to the Review by Janardan Devlukia
It is reported by Janardan Devlukia that the major activity has been focused on system
development and on the integration of key elements within the overall framework. A
‘demonstrator’ has been developed to demonstrate the communication links and the
technical transactions happening between distributed teams engaged in the design of a
complex mechanical component such as a crankshaft for an automotive engine. A
‘story-board’ was prepared to illustrate a typical design scenario. The scenario, i.e. the
story-board, covers and illustrates various critical aspects of the project, including the
"Interest Processes" addressed, the "Interest System Elements" involved within the
frame of the design development of a crankshaft. The Interest Processes addressed are
related to the specification, development, and testing of a mechanical component. The
route followed by the scenario is well identified, made visible and is based on a non
co-located team. The project manager submits the job to a team leader who goes to a
design engineer and finally to the design analyst. Sensitivity studies can be only
performed when the detailed analysis is performed. As far as the "Interest System
Elements" are concerned, the importance of linking to the legacy systems is stressed
(where past experience is stored). The practice advisor is important to put into
working practice the knowledge gained from past experience. The workflow manager
maintains an audit trail from where the process stands. The tool manager supports the
repeated run of the sensitivity studies.
The interest demo is based on a scenario of the type "Initiate / develop a mechanical
component" where all steps are logged so that they can be traced back, and listed in
the delivery of a job description. The following steps have been listed:
- Step A: this initiates the process ;
- Step B: a hierarchical structure about how the components are stored is
proposed and the crankshaft requirements lead to preliminary definition of the
geometry ;
- Step C: a sensitivity study, determining how sensible to material changes or to
geometry changes is the design ;
- Step D: the Best Practice Advisor (BPA) is an important module (define mesh
size, etc.) in that a lot of expertise is required to perform sensitivity analysis ;
- Step E: aims to accept sensitivity study, then a sensitivity result is delivered ;
- Step F: the sensitivity study is then complete ;
- Step G: evaluate proposed changes.
This overall picture seems appropriate as far as testing and benchmarking the
INTEREST architecture is concerned. Beyond the development of this simulator
system, INTEREST as embarked on further integration of a host of components,
including a Virtual Engineering Repository (VER), the Best Practice Advisor (BPA),
the Workflow Management System (WfMS) and a Tool Management System (TMS)
with advanced capabilities (a CORBA-based TMS, a POET based VER
implementation, a Job Description System (JDS) linked to the WfMS, etc.).
Furthermore, closer definition of interfaces between the BPA, VER and WfMS have
been defined.
Conformity of Work to the Technical Annex
The work so far conforms to the technical annex and the review has enabled the
review team to assess progress on the Virtual Repository (D2201), on the
Development Tools (D2302), the Reliability Assurance Toolbox, the information
gathering and search techniques for the Best Practice Advisor, i.e. BPA (D3301,
D3302), the implementation of the Virtual Engineering Repository, i.e. VER (D4101),
the development of the Tool Management System (D4401) and the Workflow
Management System (D4501). The corresponding deliverables are accepted.
Furthermore, various presentations were made during the review, including progress
report on the BPA by Chris McMahon (Bristol), report of experience from workflow
implementation by MIS, report on the VER implementation by Dave Brown from
CEDAR, assessment of tools by Michel Defourny from SAMCEF, GUI design
considerations and Tool Management System again by SAMCEF, update on
reliability design against fracture by Heinz Bargmann from EPFL, and finally an
update to the project's policies with respect to Data security by Dave Brown. All
presentations were extremely informative, with high quality presentations, foils and
accompanying materials.
With respect to the Best Practice Advisor, it is reminded that it is essentially a help
system that provides contextual support, the context being taken from the workflow
manager or from a separate indication context. Two main tasks have been addressed,
i.e. first collecting documents and references from scientific literature on fatigue
design advice, second the assessment of techniques and mechanisms for handling
large piece of data. Information and search techniques (word search, hierarchical
decomposition, no-zero-match search, dynamic context-sensitive content generation)
have been explored and represent the main part of the work done. The connection of
the BPA to the VER appears now as an important task on which the project should
focus, given that the VER must be populated, made accessible through an interface, a
component structure must be developed, BPA pages must be associated with
component data and a GUI must be developed. Of course it must be made possible to
retrieve BPA information from the VER, e.g. by traversing relationships within the
VER data structure, by comparing geometric features, by comparing all of the
attributes including numerical values and ranking them by importance value, etc.
From what is presented, it is possible to confirm that progress made on all parts of the
development, that the basic structure of the BPA is now available, that the integration
of the BPE within the VER is currently a high priority, that the development of close
match techniques seems promising. Of course, further population of the BPA is
required and it is reminded that the system will start to be useful when companies will
refuse access to it or will ask fees for its usage !
The Job Description System (D4501) is an important part of the project endeavours
and its implementation is underway, using Java, XML, on going work currently
encompassing the integration with the VER, the integration with the workflow
system, the integration with the BPA and finally the integration with the TMS. The
work-plan organisation reflects the demo framework, with three major phases, i.e.
- Phase 1 functional analysis and concept definition phase ;
- Phase 2 design phase (technical design, etc.) ;
- Phase 3 Prototype phase.
The Job Description File (JDF) is what remains from the running of the system with
a:
- Data logging View (JDF audit trail)
- Data exchange view (data exchange between different components)
- Data presentation view (presentation from various systems)
Questions remain with respect to the possible links between ERP/PDM systems and
Job Description System. It is suggested that these be addressed and that conclusions
be reported in future documents and presentations.
Implementation of the Virtual Engineering Repository (D4101) takes speed,
including the database development and implementation, the requirement analysis, the
conceptual design, the implementation design and the physical design. As a
preliminary step, the development of a core data model for integrated systems in the
form of an express schema has been undertaken (D2201), assessing the suitability of
existing models by means of a large survey. As far as the implementation of the VER
is concerned, various alternatives have been envisaged. EPM and Step tools most
closely match the requirements as they provide Java bindings to the persistent storage,
but some reservations have appeared such as the proprietary technology of EPM's
systems, plus the fact that other projects are dubious about using SDAI interfaces to
RDBMS and that it is an expensive technology as compared to other Case based tools.
A rationale is given by the project to provide justification to the switch to UML (e.g.
full object-based system implementation, OMT is the only OO standard, etc.).
Nevertheless, the review team feel a little bit uncomfortable about the way the
Express-G diagrams are being mapped to UML models in a manual way. Formal
equivalence is certainly not guaranteed. The project is asked to address this question
and to come up with a secure and reliable means of mapping the original EXPRESS-
G specification to UML models.
The development of the Tool Management System (TMS) (D4401) has been led by
SAMTECH. A comprehensive assessment of available "off-the-shelf" tools has been
performed based on :
- Requirements (web environment, support for collaborative workflow,
implementation support and compliance with WfMC) ;
- Tool categorisation (production workflow, admin workflow, collaborative
workflow) ;
- Comparisons (Metro has been chosen for various reasons (collaborative
workflow, founding member of WfMC, web based, excellent local support)..
Boss Quatro from SAMTECH meets many of the TMS requirements (besides the
parametric analysis feature capabilities), but need extensions like CORBA client /
server system capacities to be used in heterogeneous environments, these
improvements being under consideration. Enhancements of Boss Quatro for the
INTEREST project are underway, including a tool builder, a tool wrapper (graphical
selection of part of the net, registration as template - re-usable in other sessions), and
the possibility of execution in batch mode (persistence of data is required, saved in
one B4O status file). Data security is also an important issue to be considered by the
INTEREST consortium and a comprehensive survey of the problems has been made
including various aspects as eavesdropping, data misuse, process corruption, replay,
masquerading, repudiation, mis-routing, session hijacking and a list of mechanisms
like SSL, TLS, SET, PGP, Kerberos (authentication based on encryption key
exchange) have been considered.
A complete study of Reliability design against fracture and fatigue (D3201) is also
provided by the project, but the work done has appeared very generic to the review
team. It is suggested to clarify how the work - pretty general - has been tailored to the
INTEREST project specific needs, to clarify usage that the consortium intends to
make of the work and especially of the modules delivered by EPFL.
As far as the status of the deliverables is concerned, apart from D3202 lead by Fisher
for which a recovery plan with commitment to deliver in three month time is expected
and from D3301 which is delayed as well the project has made good progress. It is
also noticed that work related to the BPA and VR is three months late and that
negotiation and consultation for the selection of tools lead to delays for D4101.
Therefore, the Project Manager is asked to provide an additional table summarising
the status of all deliverables and to annex this page to the progress report.
The deliverables presented have been approved.
The Periodic Progress Report (PPR) is also accepted.
The review team again has appreciated the development of the web site and the
completeness of the material available, including all deliverables in electronic format
which is a real plus.
Project Management and Co-ordination
The Project Management appears satisfactory and seems to succeed to involve all
partners in a productive manner. Participation from Fisher must be secured and a
report on progress made should be sent to the Commission.
Activities related to standards
Even though the consortium has reported that STEP did not seem to be any longer
central to the work envisaged, the project is again encouraged to consider what STEP
could bring at various levels (e.g. conceptual for integration activities, implementation
for deployment). Mapping procedures from EXPRESS models to UML models are
also requested.
Plans for Industrial Exploitation of Results
Various presentations are made with respect to exploitation activities. Emphasis is
naturally given to commercial companies.
SAMTECH develops and markets products (not too much emphasis is put on
services). At the beginning of the project a single product was anticipated. Today, the
project results are made of several components hard to maintain. The TMS is one of
the key interest of SAMTECH with the BPA. But the BPA has been developed by a
University and the question is whether the university will envisage to continue
supporting it. The question of how the BPA could be used for other fields is raised
and should be answered, knowing that SAMTECH could be interested to maintain
and market the BPA in other application domains than the automotive industry. For
example, SNECMA could be one the potential users, and discussions have been on-
going with the methodology department and they were interested in the BPA. B4O is
exploited as a product coming out of several EC projects. OPTIM has lead to the first
versions of B40 with further improvements like 2D + 3D optimisation (MODSYSS)
and the number of customers has increased up to 70. Mainly large customers like
SNECMA, ABB, SOLAC and these are also CATIA users and B4O has been used
within this context. New customers anticipated by SAMTECH could be sub-
contractors of the large ones they have today, but the company also envisages to go to
other market segments, including the automotive industry. SAMTECH could be
complementary from CEDAR and IMS has there is some regional attachment to the
markets. Problems arise with respect to the maintenance of the entire system which is
spread across companies, i.e. SAMTECH is involved in the TMS+BPA, CEDAR in
the VR, and IMS in the Workflow modules. the hot line service is certainly something
difficult as a minimum knowledge in each component is required. First level service
could be provided by a given partner.
MIS presented their "thoughts on exploitation". A fairly general presentation is given
suggesting to identify what can be sold, to identify who will maintain, etc. It is
considered that potential sources of revenues can be based on licensing of the entire
system or on parts of the different tools. Consulting services can be envisaged by
selling the Interest framework. Important recommendations are to:
- Identify INTEREST within an engineering e-service partner programme ;
- To clarify the market position (aimed at CAE and CAD/CAE integration
where current integration aims at CAD/PDM) ;
- To position INTEREST as a CA/E-business solution chain ;
- To foster partnership with leading PDM vendors PTC/windchill,
SDRC/metaphase, IBM/enovia, MatixOne, LMS, CoCreate, WME.
As a general comment, exploitation strategies still appear patchy as off now, some
companies having clearer views and more direct access to the market. The need for a
global vision with visible synergy throughout the consortium is needed. It is again
suggested that some exploitation “champion” take the lead and would come up with a
synthesis.
Update of Synopsis
Not necessary.
Plans for Dissemination of Results/Web site
The web site has already been mentioned and is considered as an excellent
contribution from the project.
Synthesis of Reviewers’ Technical Comments
The project has reached a stage where populating the BPA and the VER are of great
importance to the overall project success. Involvement of application departments at
end-user companies is key at that stage, studying the business process within and
between companies entering partnership and ensuring that data confidentiality be
guaranteed at all stages, with appropriate authentication mechanisms. There are also
key questions around the BPA system, especially in the sense that it enables
companies to capitalise on intangible assets, of specific importance as they are often
the basis of companies showing strong "goodwill" with high potential for strong
leverage on emerging markets. The related issue is to determine how much effort
should be invested in the BPA, and this depends on how much value it is expected to
have for the end-user companies (in that case Rover and Porsche). Procedures being
also part of the intangible assets of the companies, the TMS (and related workflow
capabilities) should also prove relevant in that sense. Exploitation plans are still
sketchy and should be improved, based on how the various components
aforementioned show value to the end-users design and analysis departments.
Technical Report
Full-text available
Ce document n'engage en rien le CSTB et ne reflète que les vues de son auteur principal. La mission logicielle telle qu’elle a été définie s’intéresse à un certain nombre de questions fondamentales qui ont toutes un impact sur la capacité du CSTB à agir en qualité de concepteur, développeur, producteur, éditeur et vendeur de logiciels. Bien que de nombreuses relations existent entre ces grandes questions, il a été pour des raisons de clarté de la présentation utile de les aborder de manière séparée, le lecteur devant conserver à l’esprit qu’elles sont souvent intimement liées. Par exemple, il ne saurait être question de politique technique sans s’intéresser aux dispositions organisationnelles qui peuvent être prises pour en garantir la bonne exécution, ou encore d’une stratégie technique qui ferait fi des réalité du terrain du point de vue du parc matériel et logiciel des utilisateurs ou de considérations commerciales lors du déploiement des produits en faisant des hypothèses fortes sur les capacités d’équipement des clients, etc. Ainsi les questions sont interdépendantes, et agir sur l’une sans mesurer les effets ou les conséquences sur les autres est de peu d’utilité. C’est probablement la complexité de chacun des sujets que nous allons aborder, couplée à leurs inter-relations qui rend l’activité logicielle difficile. La politique technique est une question essentielle. On y abordera des thèmes comme la mesure de la pertinence d’une solution technique, les conséquences en termes de productivité, de cohérence entre les développements entrepris dans différents départements du CSTB, d’interopérabilité et pérennité des développements logiciels par l’adoption de langages et de plate-formes de développement préférentiels, de la mise en œuvre de bibliothèques de composants logiciels réutilisables, de la documentation systématique et standardisée selon des normes de l’entreprise, de maintenance corrective et adaptative, etc. Le champ est immense et si le CSTB peut s’enorgueillir de posséder divers métiers celui du logiciel en tant que tel ne lui est finalement pas vraiment naturel. Les questions de responsabilités préoccupent la Direction du CSTB, à juste titre, compte tenu des conséquences importantes que peuvent avoir un usage erroné ou tout simplement hors des limites prévues d’un logiciel. Ceci est particulièrement vrai compte tenu des capitaux engagés dans des opérations de construction ou de TP, les erreurs, et malfaçons engendrés par voie de conséquences ou autres problèmes se soldant généralement par un impact financier important voire considérable et des délais, lesquels engendrent eux-même en retour des pénalités. Les hypothèses de modélisation et les techniques de résolution numériques, doivent être explicitées et comprises des utilisateurs qui doivent s’engager à décliner la responsabilité des concepteurs selon des modalités sur lesquelles nous reviendront par la suite. Au titre de la portée juridique interviennent également les questions de protection des logiciels, des droits qui leurs sont attachés et du transfert de ces droits aux utilisateurs, avec toutes les limites qu’il convient d’imposer pour diverses raisons, ne seraient-ce que celles de responsabilité qui viennent d’être exposées. Les processus décisionnels et la logique économique doivent être bien maîtrisés et la décision de la diffusion d’un logiciel doit être prise en parfaite connaissance de cause des implications sur les autres activités. On peut en effet parfois penser que la mise à disposition d’un outil logiciel sophistiqué auprès des utilisateurs finaux pourrait être de nature à diminuer les montants de contrats obtenus lorsque ces derniers s’appuyaient sur la mise en œuvre d’un logiciel propriétaire assez sophistiqué pour justifier de dispenser des prestations. Nous reviendrons par la suite sur ces arguments, et sans en dire davantage, nous avons tendance à penser que la diffusion du logiciel – si elle est faite correctement et que les utilisateurs peuvent s’appuyer sur l’éditeur en fonction que de besoin – peut au contraire augmenter les volumes d’affaires. Ce point de vue sera argumenté par la suite. La diffusion suppose des organisations et des démarches spécifiques tant pour le développement que pour la promotion et la commercialisation dans un contexte où la connaissance de l’évolution rapide des technologies informatiques reste un investissement permanent et où la cible commerciale est souvent mouvante. Il ne suffit pas de remplir un service que l’on a pu identifier à un moment donné et qui correspond à un besoin clair d’une population d’utilisateurs, encore faut-il que les conditions de la cible n’aient pas changées entre le moment où le chantier est lancé et celui où la commercialisation s’opère. Ce genre de problème s’est déjà malheureusement rencontré, ne serait-ce pour l’illustrer que dans le cas où l’utilisateur ne veut plus – par exemple – d’une solution utilisant des données en local, même si elles sont fréquemment mises à jour sous forme de CDs, mais où il souhaite pouvoir déporter ce coût vers le fournisseur en se connectant par internet à ses serveurs. Dans ce cas, même si le besoin est fonctionnellement satisfait par la solution proposée, le contexte technique ayant suffisamment changé et ce de manière assez rapide pour qu’une migration devienne difficile, il est alors très dur de commercialiser le produit qui rate sa cible. De ce point de vue, les étapes d’investissement doivent être contrôlées régulièrement, et les décisions doivent se fonder sur une analyse du type espérance de gains sur risque en tenant compte de la connaissance du marché, de la concurrence, d’un business plan, etc. Bien sûr et on le comprend aisément de ce qui vient d’être rapidement évoqué, le CSTB a tout intérêt à mettre en place des partenariats pour s’appuyer sur des spécialistes de ces diverses questions. Enfin, une mission comme celle-ci, conduite sur une durée de temps très limitée, n’aura permis que de survoler l’ensemble des questions qui se posent et d’offrir un panorama nécessairement un peu rustique de nombre de sujets qui mériteraient d’être approfondis. Acceptons en l’augure.
ResearchGate has not been able to resolve any references for this publication.