Cen Workshop Agreement Cwa 14947

CEN CWA 14947

WORKSHOP March 2004

AGREEMENT

ICS 35.240.99

English version

European eConstruction Architecture (EeA) - Blueprint for an ICT System in Construction

This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement.

The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.

This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.

This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: rue de Stassart, 36 B-1050 Brussels

Ref. No. CWA 14947:2004 D/E/F CWA 14947:2004 (E)

Contents

Foreword...... 3 Introduction ...... 4 1 Scope...... 5 2 Normative References ...... 6 3 Definitions and abbreviations ...... 7 3.1 Definitions...... 7 3.2 Abbreviations...... 7 4 Methodology...... 8 5 The ICT Architecture...... 10 5.1 The Global ICT Architecture...... 10 5.1.1 Resulting Scope for ICT Architecture ...... 13 5.2 The ICT Architecture ...... 15 5.2.1 Knowledge Management Trend...... 15 5.2.2 Model-based Trend...... 17 5.2.3 Information Sharing & Object Orientation Trend ...... 19 5.2.4 Resulting ICT Architecture...... 21 5.3 ICT Architecture Component Characteristics...... 23 5.3.1 Open Standards Trend ...... 23 5.3.2 Web-based Trend...... 24 5.3.3 Ambient Access Trend ...... 26 5.4 ICT Architecture Key-Components...... 27 5.4.1 Language...... 28 5.4.2 Ontology...... 29 Bibliography ...... 30

2 CWA 14947:2004 (E)

Foreword

The present CWA contains the description of an ICT Architecture and it is based on the more global and generic CWA on an European eConstruction Framework. It provides a common, global ICT "blueprint" for the Construction industry sector (positioned in Figure 1).

The present CWA is the second of a set of five CWAs describing ICT in the construction industry and produced by the CEN/ISSS Workshop eConstruction:

1) European eConstruction Framework

2) European eConstruction Architecture

3) European eConstruction Metaschema

4) European eConstruction Ontology

5) European eConstruction Software Toolset

It aims at setting the scene for innovation in the Construction industry sector.

This CWA has received inputs from many sources consolidating a great amount of views and perspectives on ICT in Construction. Acknowledgements to input received from various European R&D activities: FP5 IST eConstruct, e-Cognos, OSMOS, Divercity, E-CORE-network [E-Core], ICCI-cluster, ROADCON-roadmap [ROADCON] and ProdAEC [PRODAEC].

The content of this CWA was endorsed by members of the CEN/ISSS Workshop in eConstruction. The endorsement round started on 12 November and was concluded on 14 December 2003. eConstruction Architecture Context & Scope

Industry (Sub)Sector

Buildings - residential - utility (offices) - industrial / technical Constructions

Construction Civil Infra etc. i.e. all non-Buildings

Urban Regions & Cities

Process Plants

Large Scale Engineering (LSE)

Ship Building

Figure 1: ICT Architecture Context

3 CWA 14947:2004 (E)

Introduction

In a world where ICT components and their underlying technologies come and go there is a need for some stability in the form of a logical ICT architecture. This architecture can serve as a backbone providing overview and transparency that is sustainable in time and can identify ICT components and the infrastructure needed for linking and integrating these ICT components in the right way (Figure 2). eConstruction Architecture An Architecture, What is it ?

ICT-oriented Blueprint A functional / logical view: no implementation details Things (“components”) and their Interrelations (“infrastructure”) gluing these things together

ICT Architecture “blueprint”

ICT Infrastructure ICT Components “glue”

Figure 2: ICT Architecture, Components & Infrastructure

One of the underlying assumptions/paradigms is that, like any other company, a software vendor has to concentrate on his core business/competence. He can be good in one or some ICT application type(s) but he cannot be best at everything. For an end-user this often means that his complete ‘ICT System’ will be assembled of software components (applications, tools, data bases, ...) coming from different vendors preferably communicating via non-proprietary interfaces based on open standards for flexibility.

The architecture in this CWA essentially provides on a global/generic (and moreover, modest) scale a reference for an overview of such a heterogeneous ICT system in its context.

4 CWA 14947:2004 (E)

1 Scope

This CWA describes an Architecture for ‘ICT in Construction’ or ‘Construction ICT’ or ‘eConstruction’, since Internet technologies form a key ingredient in this architecture. It defines in a coherent and consistent way relevant logical ICT components in ICT systems relevant for this scope being the topic Information & Communication Technology (ICT) in the context of the Construction Industry sector.

This architecture is fully based on the CWA1 (ICT framework) and can function as a reference of the basic entities (functionalities and data) for all stakeholders, not just researchers but also clients, owners, users, founders and the building industry parties themselves (architects, engineers, consultants, main/subcontractors, suppliers and their associated umbrella and service organisations).

As starting point we took the "Generic Tools" trend form CWA1 with its Sector Dependence dimension. We use it to clearly position the architecture in the area of "Construction" or more precise the "Construction Industry Sector" covering both the Buildings (residential, utility, technical, ...) and Constructions (roads, railways, bridges, ...) sub-sectors. The construction industry sector is seen as part of the more generic Large Scale Engineering (LSE) sector which is characterized by large, complex, often non-unique products designed and produced by multiple partners that have to work and communicate together intensively.

The architecture indicates from a logical (non-implementation) perspective relevant scopes like product life- cycle and supply-chain phase and essential key ICT Components & their integrating ICT Infrastructures. Examples of ICT components include (construction) product data repositories, (construction) ontology servers and associated services.

It is emphasized that implementation issues with respects to CASE and/or Implementation Platforms (Protégé, Microsoft .Net, Sun Java / One, Open Source approaches like Apache and mySQL) are not discussed here to keep the architecture logical and implementation-independent.

This CWA is deemed relevant for all those people involved in some way in decision making for Vision & Mission development, roadmaps and Strategy determination with respect to Construction ICT (Figure 3).

VisionVision && Use MissionMission

StrategyStrategy Emerging R&D Take-up

RoadmapRoadmap

Figure 3: Application areas for the ICT Architecture

5 CWA 14947:2004 (E)

2 Normative References

The following normative documents contain provisions which, through reference in this text, constitute provisions of this CWA. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this CWA are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

Data-oriented:

Standardisation

ISO 10303 - STEP Technology

ISO 10303-11 - EXPRESS

ISO 10303-21 - SPFF

ISO/DIS PAS 16739 IFC 2x Platform specification (by IAI)

ISO/DIS PAS 12006-3

IAI IFC 2x 2nd Edition

Functionality-oriented:

UN/EDIFACT-OASIS Electronic Business XML (ebXML)

Base ICT Infrastructure:

W3C (World Wide Web Consortium)

Current: URI (incl. URL), (X)HTML, Name Spaces, XML, XSD, XSL(T), XPATH Semantic Web (SW): RDF, RDFS, OWL (Lite, Descriptive Logic (DL) & Full variations) Web Services (WS): SOAP, WSDL, UDDI, BPEL4WS

IETF (Internet Engineering Task Force)

HTTP(s) TCP/IP (v4/v6) SMTP FTP

6 CWA 14947:2004 (E)

3 Definitions and abbreviations

3.1 Definitions

For the purposes of the present document, the following terms and definitions apply:

ICT Architecture A blueprint or overview for a complete ICT system covering from a logical perspective both the whole life-cycles and supply-chains (i.e. the comple "value-chain") for a construction product or service.

Product/Service Life-Cycle (PLC) Refers to the complete lifetime of a product/service from its earliest conception till its demolishment/non-provision. This PLC is decomposed in phases.

Supply Chain Refers to nested delivery of sub-product/services provided externally that make up (become part of) the constructed/assembled end- product. In Construction this chain is typically of the form: “Main Contractor, Sub-Contractor, Supplier” with potential extra intermediate transport and/or financial parties.

3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply (any context in square brackets):

bcXML Building and Construction XML [EU 5th FP IST eConstruct project] CASE Computer Aided Systems Engineering CE Collaborative Engineering CEN Committee Européen de Normalisation DL Descriptive Logic variant [OWL] FP5/6 5/6th Framework Programme [EU] IAI International Alliance for Interoperability ICT Information and Communication Technologies IFC Industry Foundation Classes [IAI] IFD Industrial, Flexible and Demountable building, but also: International Framework for Dictionaries IETF Internet Engineering Task Force IST Information Society Technologies [FP5/6] OASIS Organization for the Advancement of Structured Information Standards OWL Ontology Web Language [W3C] PLC Product Life-Cycle [this document] SC Supply-Chain SLC Service Life-Cycle [this document] SPFF STEP Physical File Format (ISO 10303-21) [STEP] STEP Standard for the Exchange of Product model data (ISO 10303) SW Semantic Web [W3C] W3C World Wide Web Consortium WS Web Services [W3C] XML eXtensible Mark-up Language [W3C] XSD eXtensible Schema Definition (language) [W3C] XSL eXtensible Style Language [W3C] XSLT XSL Transformations [W3C]

7 CWA 14947:2004 (E)

4 Methodology

The architecture will be derived by systematically assessing a subset of the CWA1 framework dimensions. The top-level matrix of the framework (covering the "change level" and "innovation phase" dimensions) is considered as being beyond the architecture; it just identifies and positions the architecture itself.

Furthermore we assume that the trends and dimensions related to "impacts" and "business processes" change levels are too abstract to directly influence the ICT architecture. For these we assume an indirect link via the more tangible ICT-based trends and dimensions that support and/or enable the more high level business-oriented trends. Of these, the following ten trends and their associated dimension(s) are considered directly relevant to the ICT architecture: eConstruction Architecture CWA1 Framework (FW) Link

ICT Solutions •Generic Tools > Sector Relevance } Context •Collaboration > Product/Service Life-Cycle Phase > Supply-chain Party > Supply-chain Phase FW FW Scope Trends Dimensions > Discipline > Product Facet •Performance Driven > Concretisation State }

•Knowledge Management > Reusability Level •Model-based > Semantic Richness > Description Level Architecture •Information Sharing > Integration Strategy -ICT Components - ICT Infrastructure •Object Orientation > Data-Function Treatment }

ICT Enablers •Open Standards > Interoperability Level Essential Characteristics -ICT Components •Web-aware > Web Usage - ICT Infrastructure •Ambient Access > Access Factors } (no implementation issues)

Figure 4: The Framework trends & associated dimensions relevant for the ICT Architecture

One could say that a logical (implementation-independent) architecture should stick to the "ICT Solutions" part of the framework. Still we also address three ICT Enabler trends ("open standards", "web-aware", and "ambient access"). Although maybe (preferrably) invisible to end-users, we see them as essential key- characteristics for the components and the infrastructure in the architecture that contribute directly to the ICT Solutions that ARE visible to the end-user! To give an example: data sharing among a small number of people on a proprietary basis (say internally) can bring a lot of advantages but it really makes sense if one can share with potentially all people (using any ICT application). Therefore we treat Open Standards, the World Wide Web and Wireless Technologies as equally important for our architecture as the more user- oriented trends and associated dimensions.

8 CWA 14947:2004 (E)

Baseline Input: EU FP6 IST ROADCON ICT Architecture

In the European FP5 IST ROADCON project also a global (reference) architecture has been developed (Figure 5). We will check this view with the "framework-generated" version in this CWA. In other words we will use it as a kind of benchmark to see if we do not miss essential features that were already foreseen in the ROADCON project. eConstruction Architecture An Architecture, What is it ? Example ROADCON

•• User interfaces: Human •• 2D ––3D 3D ––4D 4D ––nD nD interface •• Context awareness Project ~ •• Mobile & ubiquitous access Virtual •• Visualisation / simulation Enterprise Applications, Examples: systems & Inhouse ModelModel basedbased Inhouse •• Bidding Model applications Knowledge data repositories CompanyCompany XX DB applications DB •• CAD, CAE •• CRM •• Decision Extra-enterprise support links & interfaces CompanyCompany YY TransactionTransaction managementmanagement •• ERP Company Z •• Facility mgt •• MIS Inter-enterprise MIS communication bcXML, IFC, Internet, SOAP, ... standards Examples of services: Acces control, •• Best practices inter-enterprise APIAPI APIAPI APIAPI •• Collaboration support coordination •• Document mgt •• e-Commerce •• Learning support Docu- Inter-enterprise Docu- ModelModel TrustTrust ExampleExample:: •• Legal support: mentment server service ProductProduct authentication, services server server service authentication, server catalogcatalog authorisation ... •• Model checking •• Negotiation

Shared data & Trusted third party Trusted third party •• Partnering Basic inter-enterprise Basic Basic inter-enterprise Basic collaboration platform collaboration knowledge platform collaboration •• Product data libraries Optional web services e.g: repositories Optional web services e.g: Documents & files Project/Product Model Evidence & Rights Intelligent Objects •• Workflow support

Figure 5: The ROADCON View

In the next chapter we will introduce both the scope for the architecture and the ICT Architecture itself by accessing the relevant framework dimensions from [SPICE CWA1].

9 CWA 14947:2004 (E)

5 The ICT Architecture

5.1 The Global ICT Architecture

We use the five dimensions of the Framework's "Collaboration" trend to identify the big (scope) picture:

• (Construction) Product/Service Life-cycle Phase

• Supply-chain Party,

• Supply-chain Phase,

• Discipline, and

• Product Facet.

We want to cover the ICT Architecture the whole life cycle of construction products or services from Conception by the client via Feasibility, Design and Build processes till the actual Operation corresponding to the original conception by the client. With this we also determine the broad scope of our information requirements that cover the description of the products and services for different subsequent concretisation states (kind of levels of determination): as-needed (describing the process of the end-user it will enable: transport, living, working, caring, ...), as-required (from a solution type viewpoint: road, residential building, office, hospital, ...), as-proposed (designed), as-delivered (realized) and as-current when in use. This situation is depicted in Figure 6. eConstruction Framework Collaboration Trend /3

Conception Design Build Operation

As-required As-proposed As-realized As-current (As-delivered)

Learning

Re-usable Re-usable Re-usable Re-usable Knowledge Knowledge Knowledge Knowledge

Figure 6: Collaboration over the life cycle

10 CWA 14947:2004 (E)

Furthermore we want to address the construction-typical supply-chain partners on different levels as identified by the framework that interact in different ways: clients who are just shopping around retrieving information on what the market can offer them and clients that actually decided on (specialist) sub-contractors for services (external building tasks) and suppliers for building products/materials ("of-the-shelf" articles") (Figure 7). eConstruction Framework Collaboration Trend

Supply-chain Party (“buyer-supplier” levels) Client (of a “construction”) • Industrial Customer • Consumer

• At distance • Participative Procurement Main-contractor Sub-contractor & Supplier Provision

Figure 7: eCommerce Parties in the supply-chain

This way the architecture covers different levels of provision/procurement including all discovery activities and publication activities with respect to product and service data and all transactions needed for the actual fulfilment (ordering, order confirmation delivery, transport, reception, billing and payment).

11 CWA 14947:2004 (E)

Along with the different levels of actors we can identify different interests with respect to information and functionality that correspond to the Concretisation State dimension of the framework supporting the "Performance-driven" trend (Figure 8). In the ICT Framework we identified several ways to handle black boxes and white boxes (the black boxes opened up): very generic/flexible and more specific and customized towards the construction industry. The latter approach is actually chosen for the architecture (Figure 8). eConstruction Framework Performance Driven Trend

Concretisation State (=“Level of Determination”) Capability (global functional abstraction) Facility (identification solution-type) Element (functional abstraction) Part (concrete; make or buy) •Task (when you make it yourself) – Recipe (“information”) – Human Labour (“energy”) – Product/Material (“mass used in Part”)

Resources – Equipment (“mass reused”) •Service (when you buy it, “subcontract”)

Figure 8: From abstract to concrete

It means that we want to address in the architecture these types of information “from abstract to concrete” explicitly. In doing so we improve greatly the transparency of information and knowledge since the different layers can be seen as a kind of protocol steps supporting/implementing each other but still minding their own concerns independently.

12 CWA 14947:2004 (E)

5.1.1 Resulting Scope for ICT Architecture eConstruction Architecture Context & Scope: Total Life-Cycle & Supply-Chain

as-current Procure Client Conception Operation (buy) [Capabilities] LC Phases

as-required as-realized Contractor Project Management [Facilities] Design as-proposed Build [Elements] [Parts] [Tasks] Sub-Contractors [Services]

Suppliers [Products/Materials]

SC Party Provide [Concretisation State] Project Support (sell)

Shopping around & SC Phases: Fulfilment Decisions / Information

Figure 9: Scope ICT Architecture

13 CWA 14947:2004 (E)

The general idea behind this architecture scope is that in principle all relevant actor types whatever their role in the life-cycle and/or supply chain is covered and eventually enabled/supported by ICT logically identified by this architecture (Figure 10).

Completeness

Figure 10: Covering all actors interests

In construction we see a functional integration of interrelated disciplines (Figure 11) for several product aspects. Clearly the smooth collaboration of all disciplines involved in different life-cycle and supply-chain phases working on different product facets is not a trivial objective but the identified trend is really showing clearly the way to go. eConstruction Architecture Context & Scope - All Stakeholders Interests

Design Discipline Management Modelling Checking (like strength or regulations) Cost Estimation Time Scheduling Construction Planning

Product Facet Aesthetical Functional Spatial

Figure 11: Disciplines and Product Facets Involved

14 CWA 14947:2004 (E)

5.2 The ICT Architecture

5.2.1 Knowledge Management Trend

This trend is fuelled by the fact that for construction projects typically no information is reused and all information is (re)invented. The idea is to split all information explicitly in project-dependent and project- independent domains where the latter functions as a kind of knowledge database covering all corporate/company knowledge. One step further is the reuse of knowledge beyond the company. Good examples are resource databases like the ones containing Supplier and (specialist) Sub-contractor information (Figure 12). eConstruction Framework Knowledge Management Trend

Reusability Level No reuse of information Reuse of Project information + Reuse of Company information (over/beyond projects) + Reuse of Resource information (over/beyond companies) • Of Market/Domain ... • Clients, Competitors, Partners, Subcontractors, Suppliers

Figure 12: Reuse beyond projects and beyond company boundaries

In the architecture we will find a clear distinction between "project information", "internal company knowledge" and "external resource knowledge" and corresponding Project Servers, Company Servers and Resource Servers (Figure 13).

15 CWA 14947:2004 (E)

eConstruction Architecture Knowledge Management

Resource Information Human Labour

Capabilities Facilities Elements Parts Services Products/Materials

Equipment

Company Information Services Capabilities Facilities Elements Parts or Tasks Recipes

Human Labour

Products/Materials

Equipment Project Information Services Capabilities Facilities Elements Parts or Tasks Recipes

Human Labour

Products/Materials

Equipment

Figure 13: Enabling reuse of information and knowledge

16 CWA 14947:2004 (E)

5.2.2 Model-based Trend

For the Model-based trend as introduced in Figure 14 we assume that in our architecture the primary information/knowledge is fully model-based where we distinguish between primary information/knowledge and derived information/knowledge. From this primary and derived model-based information/knowledge non- model-based information (paper references, 0D, 1D, 2D/3D explicit shape representations etc.) can be further derived (static or life) and/or attached (Figure 15). eConstruction Framework Model-based Trend /1

Semantic Richness Dimensionality Analogue (Paper) ‘noD’ Digital • Pixels (Fax, Scan, Digital Photo) 0D • Documents & CAD Drawings (Vector Graphics) 1D, 2D/3D • Model-based nD

Reducing the need for human interpretation

Figure 14: Getting on the same level of understanding…

eConstruction Architecture Model-based: Different levels of semantic richness

Primary Model-based

Base Derived Model-basedBase Model-basedModel- based Derived Linked Non-Model- based* References to Paper

* Documents (0/1D) & Drawings (=“explicit shape representations”) (2/3D)

Figure 15: As Model-based as possible

17 CWA 14947:2004 (E)

Major sub-trend for “model-based” is the explicit handling of instantiation by introducing the concepts of “definition” and “specification” as two main types of description. For the latter a further distinction is usually made between reusable type specifications corresponding to catalogue items from a supply side (or requests for them from a demand side) and occurrence specifications (placed types in space/time) which form together the actual facility models (like building models). This important notion will be addressed explicitly in the architecture (Figure 16). eConstruction Architecture Model-based: Different levels of description

Descriptions

DefinitionsDefinitions Ontologies

SpecificationsSpecifications Types Types Catalogues

Occurrences Occurrences Models

Figure 16: Three kinds of Descriptions

18 CWA 14947:2004 (E)

5.2.3 Information Sharing & Object Orientation Trend

These trends are enormously boosted by the current Internet developments. The internet makes it possible to store all needed information/knowledge in one logical place (often) referred to as a Project or Product model and access this info with minimum client-side requirements (just an internet browser) from any internet-based device. Of course this does not imply that all information should be in one physical place, it could be physically distributed but logically linked (Figure 17). eConstruction Framework Information Sharing Trend

Integration Strategy Data/Functionality Management Data/Functionality Exchange (“STEP interpretation”) • Data Transfer – Point-to-Point – Shared Syntax – Shared Semantics • Data Sharing – Indirect - merging – Direct – low-level API* • +Functionality Sharing – i.e. “object” sharing – Server-Based Computing (SBC)

*RPC, COM, CORBA, RMI, SOAP

Figure 17: Star topology for communication

19 CWA 14947:2004 (E)

For the ICT Architecture we will assume an ambitious scenario where we have a mix of object (integrated data/function) management and object (integrated data/function) sharing (Figure 18). eConstruction Architecture Information Sharing & Object Orientation (combined)

Object Management • handling meta-data • incl. derived and associated documents and drawings • for all project/company/resource information Object Sharing

ICT Applications covered via functionality aspect of (“intelligent business”) objects.

Figure 18: Objects managed and handled

20 CWA 14947:2004 (E)

5.2.4 Resulting ICT Architecture eConstruction Architecture Resulting Architecture

Object Management Object Sharing

D D Resource T T O O

D D Company T T O O

D D Project T T O O

Figure 19: Combining the dimensions

The above architecture is derived in case we treat all relevant dimensions completely orthogonal. It is not easy to see that some “choices” can be made about the interdependencies:

1) Model-based Object Management (and no derivations here) only,

2) For object management a clear 1-to-1 link with the “level of description’,

3) A bit more flexible relationship in case of Object Sharing (allowing local company-specific definitons and the other way round company-independent type specifications.

21 CWA 14947:2004 (E)

This would result in the next figure.

eConstruction Architecture Resulting Architecture: Choices Made

Object Management Object Sharing

DD Resource T

D Company T T

Project T O O

Figure 20: Combining the dimensions orthogonally

22 CWA 14947:2004 (E)

5.3 ICT Architecture Component Characteristics

5.3.1 Open Standards Trend

The general assumption is that there will never be one ICT Vendor who can deliver all software functionalities in the best possible (optimal) way. Each vendor has to concentrate to be good in his core business/expertise/competence. As a result, a complete ICT system will always be multi-vendor, consisting of software modules from different vendors. These different software modules address however for a large part the same kind of information hence have to communicate about the same objects.

Assuming further the application of external software (not in-house developments only) for the right critical mass, it is not difficult to see that agreements on communication between software components is vital on a scale larger then a specific company. Especially in construction where projects always involve external communication, open standards are therefore crucial.

What kind of openness is actually needed depends heavily on the actual integration scenario and the level of intelligence (Figure 21). Earlier at the “Information sharing trend”, different ambition levels were introduced. When combined with the “Intelligence trend” openness reaches in an even wider scope of requirements i.e. standard (or just ways to describe and/or represent) APIs and higher-level distributed functionalities such as Web Services. Essential Characteristics Open Standards

Rationale All ICT Vendors have to stick to their core business/competence (too) No one ICT-Vendor can deliver full optimal (broad/best) ICT solution to the end-user Always multi-vendor solution (“best-in-class ICT Application portfolio”) requiring open communication for integration. ”One-stop-shop” scenario is doomed. Need for Open ICT Infrastructures based on Open ICT Standards and Technologies Open Standard: explicit and agreed on a certain scale

Examples: W3C Ontology Web Language (OWL) IAI IFC2x2 / ifcXML CEN/ISSS eConstruction Workshop CWAs ISO 10303 STEP BAS LexiCon / STABU LexiCon [NL]

Figure 21: Between Open and Closed

Depending on the scenario you have to agree one form of syntax, semantics or both for information, functionality or both. Defining these things in a neutral way is exactly the goal of many standardization initiatives in ICT for construction.

The wider the scale of agreement the better. That’s why an international standard is preferred above a say European or even national standards. However, international standard take a long time to develop (need a lot of consensus) and are no guarantee for a good standard (often too much democracy resulting in bad compromises). In that sense there will always be a mix of national, European and worldwide standard with interoperability problems of their own.

23 CWA 14947:2004 (E)

5.3.2 Web-based Trend

Luckily we do not have to start from scratch for exchanging information and knowledge, the backbone for storage and communication is already in place in the form of the web (on top of the Internet). Currently it serves mainly human communication but its next generation, often referred to as the "Next Generation Internet (NGI)" or “Semantic Web (SW)” will connect not only humans but also ICT applications and all web- based devices running this software in a model-based way (Figure 22).

In the future we will see a mix of manually developed precise and automatically generated (from raw content) less-precise ontologies. Together they will form the basis for better computer interpreted support for all information/knowledge workers. eConstruction Framework Web-based Trend

Web Awareness Propriatory Base ICT Infrastructure Web-enabled Web-based (traditional, syntax only) “Semantic Web”-based (incl. semantics)

24 CWA 14947:2004 (E)

The Semantic Web is a typical data-driven development that seems perfectly complementary towards the more functionality-driven Web Services developments (UDDI, WSDL, SOAP) (Figure 23). More information on web services can be found at [WSI] that recently agreed on a Basic Profile Version 1.0 (RFC2616- HTTP1.1, RFC2965 HTTP states, XML1.0SE, XSD, SOAP1.1, WSDL1.1, UDDI 2, security standards like SSL3.0 + specific extensions). Essential Characteristics Web-aware

Peer-to-Peer (P2P) Central Server-based World Wide Web (WWW) SYNTAX + SEMANTICS (representation only) (Model-based)

DATA XML/XSD (Data-Oriented) HTML Semantic Web (SW) (XML/RDF/RDFS/OWL)

+ FUNCTIONALITY (Object-Oriented) “Web Services (WS)” Semantic Web Services (SWS)

- “Under Construction” -

Figure 23: Future Base ICT Infrastructure

25 CWA 14947:2004 (E)

5.3.3 Ambient Access Trend

Ambient access means that people and/or ICT applications can always have reliable (i.e. anytime in the right quality) and fast communication from any place (“universal”) to any other place: “unlimited range” or wide area). The different access "factors" are summarized in Figure 24 . Essential Characteristics Ambient Access

Everywhere Fast Reliable / Secure

Wired PSTN > ISDN > xDSL / Cable > Optical ?

Wiresless ? GSM > GPRS > UMTS > ? WiFi g > WiFi n > ... > WiderFi > ? ?} Bluetooth > UltraWideBand (UWD) > ?}

Figure 24: Factors determining the level of access

For this trend, wirelessness (UMTS, WiFi, Bluetooth) plays an increasingly important role. We want to be able to access our info while on the move not connected via any wire, via the most appropriate device (mobile phone, laptop, PDA, TabletPC, etc.).

For the architecture it means that all information/knowledge should be accessible from anywhere in a fast (beyond broadband) and reliable (always) and comfortable (wireless) manner.

26 CWA 14947:2004 (E)

5.4 ICT Architecture Key-Components

For this architecture we identify two key components:

• A Language (“Meta-schema”), and

• An Ontology.

Especially these two components should comply to the essential characteristics defined in the previous section:

• Web-aware

• Open, and

• Accessible.

The Languages and the Ontologies are discussed in details respectively in CWA “European eConstruction Meta Schema” and CWA “European eConstruction Ontology”. Software implementations for the actual development (CASE tools) or usage (platforms) are beyond the scope of this architecture. These issues will be discussed in CWA 5. Here we will just indicate how these components fit in the overall architecture.

27 CWA 14947:2004 (E)

5.4.1 Language

The Language is nothing more than an agreed approach for describing the things on the different ‘description levels’ as identified in the framework. It should be able to handle both definitions and specifications (types and occurrences) for construction-related capabilities, facilities, elements, parts, products/materials and services. In this definition ISO 12006-3 (ISO-PAS]) is just a partial solution for the definition level; IAI IFC ([IAI-IFC]) a partial solution for the bottom two specification levels; and W3C OWL ({W3C-OWL]) a more generic solution for all three layers including their interrelationships. In CWA 3 this situation is addressed further. Key Components Language (“Meta-schema”)

Standard Language for

Definitions

Type Specifications

Occurrence Specifications

Candidate: W3C OWL Fullfills the essential characteristics Open Web-aware Ready for Wireless

Figure 25: A Language for all description levels

28 CWA 14947:2004 (E)

5.4.2 Ontology

Having a Language determined/harmonised is one thing. Trying to harmonise the result of applying it is another. Currently many initiatives have their own language to describe their own ontologies. In fact we have two camps: one that says that you should not try to have people agree on one ontology (the language is already hard enough to agree upon) and the other camp who believes in the holy grail of having one worldwide neutral ontology. Typically the truth is somewhere in the middle: partial ontologies will automatically receive agreement as soon as they prove useful and are easily reused (a kind of evolutionary approach). In CWA 4 this situation is addressed further. Key Components Ontology

Actual harmonized set of definitions Expressed in the Standard Language Instantiation delivers specifications Types (catalogues) Occurrence (models, i.e. “Placed Types”)

ONTOLOGYONTOLOGY

Figure 26: Ontology as set of interrelated definitions

29 CWA 14947:2004 (E)

Bibliography

The following material, though not always specifically referenced in the body of the present document (or not publicly available), gives supporting information.

- CWA European eConstruction Framework (EeF), CEN, February 2004

- ROADCON 52: "Construction ICT Roadmap", EU 5th FP IST Roadmap project ROADCON.

- WSI: The Web Services Interoperability Organization, http://www.ws-i.org/.

- ISO-PAS: http://www.icis.org/tc59sc13wg6/index.htm

-IAI-IFC, http://www.iai-international.org/iai_international/

-W3C-OWL: http://www.w3.org/2001/sw/