| ceXML - an XML vocabulary for building and civil engineering: Master thesis | ||
|---|---|---|
| Prev | Chapter 2. Current state of communication in the building and construction industry | Next |
Already some initiatives have tried to facilitate electronic communication: IFC (Industry Foundation Classes, the section called Industry Foundation Classes (IFC)) which is specific to the building and construction industry, STEP (STandard for the Exchange of Product model data, the section called Standard for the exchange of product model data (STEP)) and EDI (Electronic Data Interchange, the section called Electronic Data Interchange (EDI)), with the last two being more generic approaches. These three initiatives are introduced in the following three sections.
The STandard for the Exchange of Product model data (STEP) constitutes a standard way of dealing with product data. The STEP standard is very strict. The fact that testing for conformance to standard is build into the standard testifies of it's solidity. A detailed outline of the inner workings of STEP can be found in Appendix B.
Practically, STEP is used by the major players in the automobile, shipbuilding, oil drilling and airplane manufacturing business. They prescribe STEP to their selected suppliers, which they are able to do by means of their sheer size. Given the limited use they get out of it, the software is too expensive for small companies (like many building and construction companies!), since it doesn't add much in the sense of additional profits. The variety of contacts, suppliers, goods, one-off deals etc. is simply too big to achieve economy of scale on a sufficient large number of them to warrant using a standardised STEP product exchange with an expensive software package.
IFC (Industry Foundation Classes) is a counterpart of STEP, especially for the building and construction industry. It is meant for representing electronically things that occur in a constructed facility, both physical things like doors and floors and abstract things like organisation, space, cost. Everything is divided into classes. A class describes common characteristics of a range of similar things. For instance, a class can describe load-bearing things like floors, bridges, elevators. It concentrates on the load-bearing characteristics those things have.
Classes can describe both physical objects (like a bridge) and abstract attributes etcetera (like the costs). So, multiple classes together can provide the information associated with one physical object. Attributes added to a class help to describe the object further, like length and height of a bridge.
Relationships also are defined in IFC (in data). For instance, a light bulb is operated by a switch. Relationships are important in defining object behaviour in ways that mimic the behaviour of the real world artifacts.
To provide more useful and controlled access to the objects, interfaces are defined. For each useful viewpoint, an interface is provided. For instance, from the architectural point of view , the shape and location should be accessible. And from the cost viewpoint, information about the costs, maintenance frequency, etc. is useful.
IFC is quite usable, but - as is the case with STEP - the effort and costs of using IFC software seem too large for the small companies, because of the same reasons.
EDI (Electronic Data Interchange) is the structured exchange of data between applications in different companies [Raman, 1999]. The data is transmitted using pre-defined codes in one big unreadable string (that is, not readable by humans). It is used by many of the largest companies to link to their suppliers, replacing paper work orders, documents, confirmations, etc. By allowing computers to talk to each other without human intervention, the communication rolls along with fewer errors and human mistakes. Garbage in, garbage out can be prevented in this way.
Communication between computers needs to be done in codes, at least that's the EDI viewpoint. In EDI the standard set of codes (provided by EDIFACT, Electronic Data Interchange For Administration, Commerce and Trade) is used for the common, generic usage. A lot of companies have made their own code tables, extending EDIFACT, to suit their specific needs. Since both communicating sides need to understand what is communicated, openness about the product data is needed. Many times so-called EAN (European Article Number) numbers are used when indicating products. These EAN numbers are the numbers used on barcodes.
The current practice in EDI shows that it is mostly used by big companies who prescribe their EDI messaging to their suppliers. Because EDI has to be integrated pretty well with the background inventory system and similar systems, this excludes (again) the many small businesses. Only if a lot of them get together and come up with a common system, it is feasible.
All these initiatives are now trying to map their systems into xml vocabularies, but using the same system with a new XML overcoat will not change the system itself, though it may make it more accessible. The system itself, however, is not available to facilitate cheap and easy access to information.