This workshop was the second of a series initiated by CFTAG to study the computing needs of research groups funded by The Engineering Board of SERC. The workshop was attended by delegates from academia and industry and represented both engineering and computing interests.
This is a report of the second of a series of four workshops set up by the Computing Facilities Technical Advisory Group (CFTAG). The aims of the workshop series are to assist CFTAG in identifying the computing needs of research groups funded by the Engineering Board of SERC, to consider whether appropriate software or hardware is currently available in the commercial market to meet the perceived needs, and to discuss steps which can be taken by CFTAG to assist the research community by increasing their awareness of existing opportunities or by encouraging new commercial developments.
The second workshop of the series was concerned with software for the support of database systems, and was held at Cosener's House, Abingdon, from December 3 - 5, 1987. It was attended by 43 delegates, 19 from academia (representing both computer science and engineering interests), 11 from industry and 13 from Rutherford Appleton Laboratory. All the delegates came by invitation and an important objective in issuing invitations was to obtain a reasonable balance between academics and representatives of industry, between consumers and producers of software, and between computing and engineering expertise.
The time available was divided approximately equally between a series of lectures and discussions in four parallel working groups.
The lectures were designed to provide background material and support for the working groups. They were well received and a number of useful points emerged directly from the lectures. They will simply be listed briefly as the main focus of this report is placed on the final recommendations of the workshop.
Professor Stocker (UEA) gave an overview of current database practice, indicating areas where users must make policy decisions, and describing some outstanding problems.
Mr M Wallis (RTI Ltd) described the development of INGRES as a commercial implementation of the relational database model, and outlined the features (now and forthcoming) of INGRES/Star, the distributed version of the system.
Professor M Atkinson (Glasgow) considered the special characteristics of engineering data and suggested new features, not available in current database management systems (DBMS), which the engineering community would be likely to need.
Dr T W Olle (consultant) in a talk based on very wide experience spoke of the practical design considerations required in specifying large databases.
Dr R P Jones (Warwick) and Mr A J Holt (Lucas) described their collaboration on CAD for automotive control systems - a very good example of the benefits and problems arising for research teams in the areas covered by the workshop.
Dr C J Angus (Prosys Technology) described projects undertaken by his company in engineering consultancy, including very impressive work on PRODABAS, an advanced tool for information management with a very rich set of data structures and associated operations.
Dr Chalmers (STC) spoke on the development of a data model for use in an industrial environment, a talk which identified the use by engineers of models for data transmission as distinct from the data design aspects more commonly discussed by computer scientists.
Finally Dr K G Jeffery (RAL) summarised the features of existing commercially available DBMS and reviewed a number of aspects of engineering practice which had by then emerged in working group discussions.
The delegates were divided into four working groups to provide the maximum opportunities for discussion, and to concentrate attention on four important aspects of database use and support. The four areas identified for this purpose were:
The groups had about 10 members each and met three times before presenting their reports as the closing session of the workshop.
At their first meeting each group was given a list of eight questions to focus their debate:
Before the final group sessions, Professor Atkinson followed up these questions by suggestions that each group should report possible actions in relation to three timescales:
(Matters raised in several groups are reported only once, except where they differ)
Engineering data does not fit neatly into the modelling schemata as developed by the database community. However engineers have found a practical need to transmit data from one form of CAD system to another, e.g. from a design system to a finite element analysis system and back again. Thus data interchange formats have been designed which are a form of modelling. Examples are EDIF (Electronic Data Interchange Format), and CAD*I for mechanical data. The formats which have been used differ widely and translation between related formats has been difficult. Languages are now being developed to describe these concepts better, such as EXPRESS and the Esprit project AIDA an attempt to define a standard modelling language.
To undertake modelling for design as used by computer scientists, engineers need database systems which encompass more complex physical or conceptual objects, such as a crankshaft or a matrix. A joint evaluation by engineers and computer scientists of the PRODABAS package would be worthwhile. An alternative might be STROBE, a language developed with Alvey funding.
Engineers also need a better environment for modelling. Present CAD systems often hide the database from the user and thus it cannot be used in other applications. It was suggested that the concept of a specialist engineering workstation should be extended from control engineering to mechanical and electronic CAD. This would need a database at its heart and easy interfaces to other design tools.
Engineers have not been accustomed to the use of design tools in the early stages of a project. The use of tools such as AUTOMATE could be expected to encourage people to think more clearly about the structure of a problem as well as providing good documentation of the design. Some training courses (at a cheaper price than commercial rates) would be useful.
Five aspects of interfacing with databases were identified:
It was recognised that in several of these areas there was overlap with others of the working groups. The group surveyed existing products and compared them against the facilities being sought for each interface.
Although SQL was acknowledged to be inadequate for engineers, it is widely available and in use. Experience in the high energy physics community showed that standardisation on SQL would provide a platform for file and program interchange through the SQL DML/DDL interface even if sites used different DBMS.
In some cases non-SQL products have been chosen for projects because they offer different functionality needed by the project. These products should be studied in more detail to see whether SQL vendors can and should be persuaded to include the new features in their future releases.
The success achieved by the Warwick University/Lucas joint project was cited as an example of the benefit which can be obtained from consultation with the Information Management Group at RAL. Opportunities for wider exchange of information on database problems and database technology should be encouraged.
Engineers have generally made little use of project management (PM) tools, but the broad structure of their projects has much in common with commercial projects - work breakdown structure, resource estimation, plan/ scheduling and monitoring. PM tools should be seen as supplementing other tools which may already be employed such as database software, a query language, a mailer or an expert system.
NCC has been studying PM tools and advantage should be taken of their knowledge. Other information should be sought from projects supported by SERC, Alvey, Esprit etc., and a 1-day project presentation could be arranged. A small number of PM tools should then be chosen for use in pilot projects. Since the packages vary widely in scope and cost, the selection should reflect different types, needs and potential. PMW, PROMPT and ARTEMIS (in increasing sophistication) might form a suitable set. The pilot studies must of course be followed by appropriate seminars/workshops.
In view of the widely varying engineering data environments, in many of which current DBMS are inapplicable, the group decided that they should consider data administration, looking at a wider context than DBMS alone. It was recognised that this meant that their discussions might overlap with those of other groups, for example project management. However it also shows that the issues of data or database administration cannot be clearly separated from questions about database use. What is needed ideally is a database which can be used as a means of storing the meta-data about program and data relationships - this could be described as a "control database".
The traditional model of data implied by the traditional database schemata is inappropriate for engineering applications. Ideas and techniques taken from process control may be useful in developing a new approach, in which the database is seen as a dynamic structure (which may interact with other data sources) and the DBA is analogous to a control engineer.
Besides the usual "system administration" tasks such as back-up, user control etc, a number of necessary characteristics can be readily identified:
The group agreed that a demonstration control database should be established, using a current relational DBMS and fourth generation language tools. This should be able to manipulate a conceptual dictionary, and automatically update a data dictionary. Its tools should include version control, access control, a documentation facility, and data distribution management.
There was also discussion of a number of current products which have some objectives in common with the control database PRODABAS, PS/Algol and METIS. It could be useful to evaluate their DBA facilities on a user trial basis.
On the theme of education more generally, this group, like others, recommended a series of seminars on the use of databases in engineering, and the establishment of a consultancy service, probably based on RAL, to give help with project management using control databases.
It was agreed that there is no DBMS currently available which can provide all the facilities required for engineering applications. Specifically, they do not permit the definition and manipulation of complex objects such as matrices (except by breaking them down into atomic components), nor do they provide adequate support for version control and other temporal aspects. In engineering applications, complexity of data is typically more troublesome than contention over access, and transactions are lengthy rather than frequent. Thus they do not match well with the most efficient and highly optimised aspects of commercial DBMS.
Despite these strictures it was universally agreed that the engineering community should not attempt to develop its own DBMS. Any such attempt would be likely to prove costly, ill-judged, repetitive of previous development, difficult to support and very probably unproductive.
Instead, efforts should be made to alert existing research teams in computing to the characteristics of engineering databases, and attempt to influence the directions of development to take account of the needs of engineers as a consequence of these characteristics. PROBE and POSTGRES were cited as examples of current DBMS research projects which offer some of the facilities sought by the workshop.
There was also general agreement on the need for education within the engineering community to give more awareness of the scope and benefits for engineering projects of modelling tools, project management tools and database administration tools as commonly used for commercial databases. This educative process could be informed by arranging for trial use of software for some selected projects.
Finally, on broad policy, it was accepted that existing standards should be adopted as much as possible to maximise the ability of the community to profit from the interchange of data and, at a very different level, of expertise. It was recognised that this will mean adopting standards, such as the SQL query language, which are not ideal. Just sufficient flexibility of practice should be permitted to allow the community to become aware of promising new developments, and consider adopting them as standards if appropriate.
To support the needs of engineers for efficient data interchange between one form of modelling and another, close attention should be paid by CFTAG to the development of Esprit's AIDA and to its data interchange products. Further projects of this nature could be encouraged through participation in standardisation activities.
Geoff Lambert of RAL undertook all the detailed planning of this workshop, and gave invaluable advice and help to the Chairman of the organising committee. Cosener's House provided very comfortable accommodation. The convenors of the working groups and their rapporteurs carried out difficult tasks most willingly, and did a great deal to focus the very diverse interests and wide-ranging debates within their groups.
Their summaries were of the greatest value to the author in drawing up this report of the workshop.
