Deliverable Reference
WP
3 / Task
3000 / No.
D301
Status Draft/Issued/Revised
Issued / Rev.
1.0
Date
14 May, 1997 / Release to CEC
-

Classification : Restricted

WP3: Trends in PDIT Support

Task 3000: The Supporting Environment

ESPRIT 20876 - ELSEWISE

Editor:

Alastair WatsonUniversity of Leeds

Other Main Contributors:

Gerard SauceCSTB

Johan NeuteboomTNO

Jacques RossillolBouygues

Distribution / Draft / Issued / Revised
Date / 25-4-1997 / 14-5-1997
TW / *
BOU / *
HBG / * / *
SKA / *
BICC / * / *
CAP / * / *
CSTB / * / *
DSBC / *
ECI / *
ULeeds / * / *
RAM / *
RAKLI / *
TNO / *
TR / *
VTT / * / *
CEC

Document Control Sheet

Amendment Record

Revision / Status / Page Nos. / Amendment / Date / By
1 / Issued / Additions & final corrections / 14/5/97 / AW

Table of Content

1. Introduction1

2. Product Data Technology Standards3

2.1 What exists today3

2.1.1 Electronic Data Interchange (EDI)3

2.1.2 Standard EDI messages4

2.1.3 EDIFACT message structure6

2.1.4 ISO 10303 (STEP)6

2.1.5 The IAI Industry Foundation Classes9

2.1.6 OLE for Design & Modelling9

2.2 Barriers to LSE uptake11

2.2.1 Electronic Data Interchange11

2.2.2 Product Model Based Standards12

2.3 Trends and expectations13

2.3.1 Electronic Trading13

2.3.2 Open EDI and STEP14

2.3.3 Product Model Based Standards14

2.4 Relevance to LSE16

2.4.1 Electronic Trading16

2.4.2 Product Model Based Standards17

3. Communications Infrastructures18

3.1 What exists today18

3.1.1 Networking Technologies18

3.1.2 Communications Technologies19

3.1.3 The Internet and World Wide Web20

3.1.4 Other Sources of Digital Information22

3.2 Barriers to LSE uptake23

3.2.1 Networking and Communications23

3.2.2 The Internet and World Wide Web24

3.2.3 Other Sources of Digital Information25

3.3 Trends and expectations25

3.3.1 Networking and Communications25

3.3.2 The Internet27

3.3.3 intranets30

3.3.4 Other Sources of Digital Information30

3.4 Relevance to LSE30

4. Delivery Platforms32

4.1 What exists today32

4.1.1 Desktop Hardware32

4.1.2 Desktop Operating Systems35

4.1.3 Servers37

4.1.4 Portable Computers37

4.1.5 Distributed Objects38

4.1.6 Other Emerging Technologies40

4.2 Barriers to LSE uptake41

4.3 Trends and expectations42

4.3.1 Microchip Technology42

4.3.2 Disk Technology43

4.3.3 Desktop Hardware43

4.3.4 Desktop Operating Systems47

4.3.5 The Impact of Java and the NC48

4.3.6 Portable Computers49

4.3.7 Servers49

4.4 Relevance to LSE49

5. Summary51

6. Index53

1.Introduction

This document (D301) is one of a series of outputs from Work Package 3 of the eLSEwise project. The overall objective of the work package is to identify, and to critically evaluate, the key technologies in Product Data Information Technology (PDIT) which are likely to provide the tools to support and shape the LSE Industry in the future. The formal outputs from the work package are as follows:

Title / Scope
D301 / Appendix to D305:
“The Supporting Environment” / Product Data Technology Standards, Communications Infrastructures, Delivery Platforms.
D302 / Appendix to D305:
“Systems and Technologies” / Human Interface, Data Management, Knowledge Management, Virtual Enterprises.
D303 / Appendix to D305:
“Application Software” / What exists today, Barriers and Opportunities, Trends and expectations, Relevance to LSE
D304 / Appendix to D305:
“Applied Research Futures” / European IT Research projects and their future relevance to LSE
D305 / Main Report:
“Trends in PDIT Support” / Summery Work Package Report

Document D305 provides a concise overview of the overall results from the Work Package – particularly the opportunities for the LSE industry and the barriers to LSE uptake. More comprehensive results, with greater technical detail, are presented in the supporting Appendices. The Work Package has adopted a layered approach, with D301 providing the technology to support D302, and with both these supporting D303. By adopting the viewpoint of the research community, D304 may be regarded as an orthogonal check on the findings of the other Appendices. Although the coverage of the Work Package is wide, it cannot (and would not) claim to be complete and comprehensive – the domain is too wide! Judgement has been applied in selecting which areas of technology should be addressed, and to what depth. In all cases the criteria has been the expected relevance to the LSE industries.

The major output from eLSEwise Task 3000 (The Supporting Environment), document D301 is concerned with those technologies that provide support to higher-level systems and applications, and thus ultimately determine the form of the future IT solutions that can be offered to the LSE industries. This “supporting environment” has two distinct parts. Firstly, the universal IT infrastructure: networking, communications, and digital information sources together with the IT delivery platforms (hardware and operating system). Secondly, those Product Data Technology Standards which are directed specifically at, or which are directed towards, LSE. The objective of Task 3000 was to determine the probable character of this supporting environment by the year 2005[1], and to identify the implications for LSE. The methodology adopted has been to review current sources on what is expected in the near future, and to project from this to 2005. Given the pace of development in IT, and the strong market drivers, it is doubtful that meaningful predictions could be made beyond that date.

The scope of this document can be outlined in terms of the three main technical chapters:

  • Product Data Technology Standards: Those standards concerned with the structuring of information for digital exchange and sharing including: Electronic Data Interchange (EDI), ISO 10303 (STEP), the International Association for Interoperability’s Industry Foundation Classes (IFCs), and the Microsoft approved OLE for Design and Modelling).
  • Networking and Communications: That part of the universal IT infrastructure which lies behind the delivery platform – Networking and Communications technologies, the Internet and the World Wide Web, intranets, and other means of communicating digital information.
  • Delivery Platforms: That part of the universal IT infrastructurewith which the end-userinteracts – the hardware and operating system of desktop and portable platforms (including some consideration of servers). This chapter includes sections on distributed objects and other emerging technologies - such as voice input, Java and the Network Computer.

In each case the following issues are addressed:

  • What exists today?
  • What are the current barriers to LSE uptake?
  • What are the trends and expectations by 2005?
  • What is the relevance of this to LSE?

The report assumes the reader has some knowledge of computing and IT terminology, but efforts have been made to keep the language accessible to the none-specialist.

2.Product Data Technology Standards

2.1What exists today

2.1.1Electronic Data Interchange (EDI)

Electronic trading, by means of exchanging standardised EDI messages, is generally accepted and practised today in particular industry sectors such as transport, retail and health care. This is reflected in the set of internationally agreed standard messages which mainly support information exchange between the processes in these three sectors. The standard paper documents that were used in the past were simply replaced by their electronic counterparts. For that reason EDI is still strongly document oriented. Success depends on the presence of standards for the definition of the electronic messages. These messages must be computer interpretable in order to trigger consequential actions, which may be independently executed by the computer.

The standardisation effort was conducted under the auspices of the United Nations and resulted in a standard format for electronic documents called EDIFACT and in directories with standard messages, segments and elements.

EDI can bring many advantages to companies:

  • EDI service available 24 hours a day;
  • reduction of errors;
  • no human intervention;
  • message travels at the speed of light.

EDI is generally defined as “The electronic exchange of structured and normalised data between computer applications of parties involved in a (trade) transaction” . The initials EDI formally stand for Electronic Data Interchange, which (incorrectly) suggests a much wider meaning involving any form of data interchange in electronic form. The particular objective of EDI is to exchange electronic documents. It is thus not surprising that the definition of electronic messages only started after the completion of a standard layout for paper documents: the United Nations Layout Key for Trade Documents (ISO 6422), and the definition of an international trade dictionary: the Trade Data Elements Directory (ISO 7372). The same working party (Working Party on Facilitation of International Trade Procedures) of the United Nations Economic Commission of Europe (UN/ECE) developed the electronic variants for document exchange. This resulted in co-operation with US standardisation bodies into the world standard for the exchange of electronic trade messages: the EDIFACT standard.

EDI involves the following characteristics:

  • Transactions: This means that one party requests a service and the other party offers the service and receives payment for the service. It also means that both parties have a relationship supported by a business agreement.
  • Protocol: A transaction is not a single message sent from one party to another. In general a transaction will consist of a series of messages (order, change order, accept, reject). This means that from the start until the end, a transaction can be in different intermediate states.
  • Automated: As EDI messages are structured, a receiving application is able to interpret the message and perform the required “sequel actions”, without human interference.
  • Documents: The EDIFACT syntax was designed to describe the content of documents. For this reason the building blocks of EDIFACT are data segments and data elements. A message design describes what segments are relevant for a certain type of document and in what order and how many times they appear. It also reveals if the relationship between the different document segments is a one to many or a many-to-many relationship.
  • Structured data: To allow computers to interpret incoming data it is necessary to structure it according to strictly defined rules. The building blocks for EDIFACT are called data-segments. Each data-segment starts with a 3 letter tag to identify the segment and ends with a “-” character. Between these are data-elements, which are numbers and/or strings, separated by “+” and “:” characters. The data structure is flat: it is not possible to have segments within segments.
  • Automatic “sequel actions”: A computer that is able to interpret the incoming messages must also be able to take the required consequential actions. For example, if an order comes in for a certain item, then at least the receiving computer should send a confirmation, but it could also register the order and generate an invoice or a shipping order for transportation. Although this capability makes EDI particularly attractive, there is still a majority of companies that do not exploit it.

Within an EDI exchange between two parties, the underlying objective is to send data produced by application A to the other party where it is used as input to application B. Thus, if the first party wishes to send an order, the data produced by application A has first to be converted to the standard neutral EDIFACT format. This standard electronic order is then send to the other party. The receiving system uses its own conversion programme to decode the incoming file from EDIFACT to the in-house format. What automatic “sequel actions”, if any, follow depends entirely on how the receiving company has programmed its systems.

2.1.2Standard EDI messages

The UN/EDIFACT Standards comprise a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data, in particular that related to trade in goods and services between independent, computerised information systems. A distinction is made between batch EDI and interactive EDI.

To date over 125 standard EDIFACT messages have been defined (of which about half are still in the standardisation procedure). Eleven of the messages, which start with the prefix “CON”, are specifically designed for the building and construction industry:

  • CONDRO Drawing organisation message: Describes the general (project) organisation and structure, valid for a complete project or environment. Its aim is to acquaint the participant of a project with the existing organisation, the computer environment used, the agreed conventions for structuring/naming the transferred data and, in subsequent use, to announce any changes to the above-mentioned agreement.
  • CONDRA Drawing administration message: Describes a parallel non-EDI exchange of a set of engineering/CAD files. CONDRA gives additional administrative information about these files; for example, their nature, a list of their contents and technical information necessary to interpret them. The EDI message itself does not carry any engineering or graphical information. Such information is transferred within files written in existing standard graphical exchange formats or native formats, referred to within the CONDRA message as external file reference to identify each of these files.
  • CONAPW Advice on pending works message: Used during the design, building and maintenance stages to communicate with organisations about existing and planned services in the vicinity of the works. Enables a contractor who intends to start works to advise public authorities and water, gas, telephone, electricity distributors of his intention, and to request them to send back plans or information in any form concerning existing networks. The first two messages may be used in conjunction with CONAPW to allow graphical and other information to be conveyed.
  • CONRPW Response of pending works message: This message is a reply to a CONAPW message and enables service providers to respond to a contractor giving details of any services and networks at the location where construction work is to be undertaken. The first two messages may be used in conjunction with CONRPW to allow graphical and other information to be conveyed.
  • CONITT Invitation to tender message: A structured description of a Bill of Quantities used during the pre-contract tendering process. Initially used by the client’s representative to send the competing main contractors the applicable Bill of Quantities. May also be used subsequently to issue any amendments, or be used in turn by the main contractor to issue subsets of the Bill of Quantities to competing subcontractors. The receiving software must interpret the message, which bears no relation to the traditional paper document. It addresses both the size and indexing of such documents by effective grouping and indexing of work items and the use of standard items to avoid repletion. The message is based on universal practice and is not dependent on the type of business or industry.
  • CONTEN Tender message: Used by a main contractor or subcontractor, after the receipt of an invitation to tender (CONITT) message, to submit a tender - a commercial offer to execute the project work defined by the Bill of Quantities included within the invitation to tender.
  • CONEST Establishment of contract message: A structured description of a Bill of Quantities used after the completion of the tender process. Initially used by the client’s representative when the contract is agreed to issue the applicable Bill of Quantities to the main contractor, and subsequently to issue any amendments.
  • CONQVA Quantity valuation message: Advises another party about the progress of work performed (against groups of work items) during a specific time period, or since the start of the project. Typically used between the main contractor and the client's representative to submit progress details. The message can also be used between other parties. The message allows for the inclusion of “new” items of work.
  • CONPVA Payment valuation message: Advises another party about the value of work performed (against groups of work items) during a specific time period, or since the start of the project. Typically used between the main contractor and the client's representative during the process of approving the value and payment for work completed. The message can also be used between other parties. The message allows for the inclusion of “new” items of work.
  • CONWQD Work item quantity determination message: A justification of the work item quantities given in another messages that describes the work items or their progress valuations. Typically will be used between a contractor and the client's representative or other partners within the construction process, to substantiate the quantities associated with specific sections of work.
  • CONDPV Direct payment valuation message: The instruction by the contractor to the party responsible for payments, to pay the subcontractors for work completed. This message is designed to be used to support the business process of communicating the value of progress against groups of work items which make up a construction project

Other more general EDIFACT messages like the electronic invoice “ORDERS” and the electronic invoice “INVOIC” can be (and are) used in the building and construction area. The UN issues a new version of the EDIFACT message directory twice a year.

2.1.3EDIFACT message structure

EDI messages are very generically defined. To make them computer interpretable, codes must be used to identify parties, articles and locations. Currently the EANCOM implementation guidelines are widely use to achieve this.

In EANCOM messages, an EAN standard article number identifies each product and an EAN location number identifies each party. The EAN identification numbers are unique and recognised worldwide. Their use means trading partners do not have to maintain complex cross-references for each trading partner's internal codes.

EANCOM also provides a logical sequence of messages used in business. Trading companies jointly agree on messages adapted to their needs. Standard messages available in EANCOM can be divided into the following categories:

  • Master Data Messages: Containing data which rarely changes such as product measurements, names and addresses.
  • Commercial Transactions Messages: Covering the general trading cycle from quotation request to remittance advice including purchase order, transport and logistics messages.
  • Report and Planning Messages: Allowing the exchange of general trading reports, including forecasts on delivery, sales and stocks, to allow partners to plan for the future.
  • General Messages : May be used to send data for which no specific standard message exists.

EAN has established an international committee of EDI experts: the Communication Systems Committee (CSC). Its main objective is to monitor the development and maintenance of the EANCOM standard in accordance to user needs and requirements identified in specific project teams. In construction the EAN coding system is mainly used for standard building components between supplier and wholesaler. The connection in the supply chain between wholesaler and contractor is not established yet, although some initiatives are exploring this field. It is more complex because of different product specifications, which cannot be translated into standard products with unique identifying codes.