COMBINE 2: Project Up-date

COMBINE 2: Project Up-date

(November 1994)


Contents:

Task 1: Specification

Task 2: Concept Design

Task 3: Data Exchange System Development

Task 4: Integrated Building design System Development

Task 5: Actor Interaction Handler Development

Task 6: Acceptance Testing and Dissemination



Task 1-Specification

The system specification task is now complete. The objective of task 1 was to arrive at a specification of the proposed design system's functionality which would:

The task was undertaken in several stages.

  1. COMBINE 2 partners approached selected architectural and building services design firms to determine if they would be willing to become test sites for the COMBINE system.

  2. A questionnaire on work practices within the co-operating organisations was drawn up by the task leader UCG and administered by the COMBINE 2 partners.

  3. The results were analysed together with the organisations descriptions of their tools and a report produced for the second COMBINE 2 project meeting (M2) in May 1993 in Galway, Ireland.

  4. This report was commented on and a further task meeting was held. As a result, a second and final report was presented at the third project meeting (M3) in October 1993 at Newcastle-upon-Tyne, UK.

One issue which had not been satisfactorily resolved by M3 was that of modelling the flow of control in the design systems. A variety of approaches were explored including IDEF0, Jackson diagrams and various object-oriented modelling languages. Eventually, Technical University Delft came up with a formalism loosely based on Petri-Nets, named Combi-Nets, which answered the need. The output of Task 1, namely the specification and the Combi-Net models, are now being used by Tasks 3 and 4 to guide their design and implementation work.

TASK LEADER: University College Galway, Ireland



Task 2-Concept Design

Within this Task 2, conceptual modelling activities have been continuing at the three initial levels:

  1. Design Tool (DT)-level
  2. Integrated Data Model (IDM)-level
  3. Integrated Building Design System (IBDS)-level

DT-level

At the DT-level, DT suppliers have produced Aspect Models, conceptual models of their tool, using the ATLIAM editor. They are currently working on IDM subschemas, subsets of the Integrated Data Model, and on Mapping Tables, which describe the mapping between Aspect Model and Subschema.

IDM-level

At the IDM-level, current work concentrates on finalizing the so-called IDM+, an improved version of the COMBINE 1 IDM without scope extensions. An IDM+ subset was delivered by TNO-CIC in December 1993, describing models for spaces and enclosing structures and for geometry and topology. A draft version for space function was delivered by CSTB in February 1994. The remaining parts, dealing with site data, technical systems and performance data, are expected shortly. After completion of the IDM+, the model will be extended in scope and address issues such as the relationship between building and HVAC systems, building requirements, performance semantics and library structures.

IBDS-level

At the IBDS-level, dynamic aspects (or behaviour aspects) of product information is modelled. TU Delft has developed a Project Window modelling approach which currently serves as a baseline for IBDS modelling. In this approach three control levels are distinguished:

Level 1 represents the way in which COMBINE 1 dealt with product information flows. At level 2, control is limited to monitoring the sequence of events. UCG is working on two Project Window models aiming at this level. At level 3, control is extended to pre and post-conditions, meaning and purpose of activities, etc. This level is aimed at in a limited prototype in Task 5.

TASK LEADER: TNO-Computer Integrated Construction, The Netherlands



Task 3-Data Exchange System Development

This is a brief description of the current status of the Task 3 work on the Data Exchange System (DES) Kernel and its interfaces. The system structure of the DES comprises four components;

This holds a representation of one or more buildings that is shared by many different design tools. Considerable progress has been made on implementing the DEK. At the core of the DEK is an implementation of the ISO STEP part 22 SDAI n350 information model. All three SDAI schemas of this model have been implemented. These include the data dictionary schema, the session schema and the abstract data type schema. All building instances are held in the DEK in meta-representation (the structure of the model is stored as data); this allows the DEK to support multiple schemas and multiple views of the data.

The DEK has been implemented on top of a commercial object oriented database, ObjectStore and runs on UNIX and Windows platforms.

Off-Line Data Interaction Manager

The role of the DIMOFF is to provide an interface for design tools that exchange data with the DEK used by ISO STEP part 21 physical files. At present, data can be imported and exported, to and from, the DEK in accordance with the IDM schema. Work is currently underway to extend this facility to support exchange in accordance with sub-schemas of the IDM. In the present version a DIMOFF must be configured for each design tool for import functionality, although future versions will be generic for any design tool. Export is currently generic for any design tool.

On-Line Data Interaction Manager

The DIMON supports tools which can work interactively with the DEK; in particular, CAD tools which must exchange data with the DEK as the user works on the building design. It holds an early bound data model of the IDM in accordance with the C++ language definition and at present provides an interface with the DEK that allows the exchange of geometric and topological entities.

Versions of the DIMON are being configured to interact with both Microstation CAD and AutoCAD.

Data Exchange Toolkit

The DET provides the facility for off-line design tools to build interfaces onto the ISO STEP part 21 physical files produced by the DIMOFF. The DES-independent interface kit (IntKit) comprises an EXPRESS language parser, an SDAI implementation, a textual browser and a graphical browser. At present a first version of the interface kit is available, it supports the SDAI C++ functional binding specification.

Exchange Executive

The Exchange Executive (ExEx) is designed to be the IBDS-component that manages and monitors the flow of control over the sequence of design tool invocations. It has embedded in it shallow knowledge of the design process inside a Project Window (PW). For the process model, a special modelling method (CombiNet) is developed. The ExEx takes the project window descriptions and the input and output EXPRESS schema of a Design Tool and configures itself from these definitions. The CombiNet can then be evaluated by the ExEx. Future work lies in integrating the ExEx with the DES.

TASK LEADER: University of Newcastle, United Kingdom


Task 4-Integrated Building design System Development

Task 4 is entrusted with the responsibility of producing two of the three integrated building design systems which are to be created and subjected to field test and evaluation by the COMBINE project.

System 1

The first of the systems will be aimed at architectural practice. It will be constructed by taking the Intergraph based architectural CAD tool being developed by Technical University Delft and linking it by means of the Data Exchange Kernel and the On and Off line Data Interaction Managers (see Task 3 section of this newsletter for details) to the following applications:

All these applications will have data exchange interfaces for communicating their inputs and outputs to the Off-line data interaction manager. These interfaces will be built using the Data Exchange Toolkit. The Task 4 team leader, CATERU - University College Galway, has responsibility for overseeing the production of these interfaces and providing the development teams with the data files which will be used to test the interfaces before the availability of the completed system. The operation of all these tools will be controlled by an "Exchange Executive" (see Task 3) specially configured for the system. The job of the exchange executive is twofold:

  1. After each tool places data into the kernel, it must determine which tools are permitted to operate next. This helps to maintain the consistency of the design data in the kernel.

  2. To determine which tools need to be re-run as a result of the changes just made.

The operation of the Exchange Executive is controlled by a Petri-Net like model (Combi-Net) called a "Project Window".

System 2

The second system is aimed at building services engineers and is designed to assist them in their design work. This system is similar to the first except in that it contains a number of different tools, and the control model loaded into its Exchange Executive is necessarily different. As before, the system is based around a CAD tool - an AutoCAD based HVAC ductwork CAD package being developed by CATERU - University College Galway, linked in the same manner as before to the following applications:

TASK LEADER: University College Galway, Ireland



Task 5-Actor Interaction Handler Development

Task 5 is concerned with the construction of a knowledge-based design tool interaction handler or IIBDS (intelligent, integrated building design system). The intention is that the IIBDS will coordinate designer-to-designer, designer-to-application and application-to-application transactions, against rules which describe the purpose of a given design session.

At the present time, this work is addressing the 'shallow' control issues relating to design tool sequencing and interaction. This includes both user-to-user (e.g. cooperative working) and user-to-design tool (e.g. user decisions on design tool sequencing) transactions.

In the near future the focus will shift to the issue of 'deep' control where knowledge is introduced in relation to design purpose so that design tool use is constrained within a specific design session. For example, if a comfort assessment design tool returned "warm_uncomfortable", while a lighting tool returned "inadequate_daylighting", then some inferred constraint may be placed on the permissible modifications to the fenestration.

Within Task 5 a rapid prototyping approach is being employed by which the different possibilities for transaction handling are being examined and the outcome used to drive IIBDS evolution. To direct this line of enquiry, a Project Window (PW) has been elaborated which comprises several design tools chosen to offer significant design appraisal capabilities while representing a realistic mix of interactions.

The PW incorporates the management of design tools for CAD, energy, lighting and constructional compliance against the following storyboard:

To construct the IIBDS, various technologies are being harnessed, including a central 'Blackboard' to store the various transactions and transmit these onwards to the clients on a need-to-know basis. Two of these clients, concerned with user and design tool knowledge handling, operate on the basis of an automatic translation of Petri Networks to Prolog Predicates. This means that design tool sequencing, and knowledge relating to design intent, can be introduced without any modifications to the IIBDS. The next stage is to use this facility to introduce design knowledge so that the scope of the design tools can be controlled as a function of the evolving state of the design and its changing performance.

TASK LEADER: ESRU-University of Strathclyde, United Kingdom



Task 6 - Acceptance Testing and Dissemination

The activities of Task 6 have begun to expand since the last newsletter. Present activities include:

The dissemination of information to interested parties continues with this, the second newsletter. Newsletter No. 3 will be available around Christmas. A full colour brochure giving an outline of what the project is about is also to be published which aims to inform a more general audience in the engineering and architectural world of COMBINE. All those on the present distribution list will receive a copy automatically

Acceptance Testing

A very important part of Task 6 has also recently begun. In the final phase of the project the delivered COMBINE system will be placed in several professional offices around Europe. A number of commercial architectural and engineering practices have shown an interest in co-operating in carrying out field tests of the delivered system on projects which have already been or are about to be completed.

The objective of subjecting the delivered COMBINE 2 system to acceptance testing is multi-dimensional . The main focus will be on those functions which assist in the design process of a building project and on the manner in which they enable the designer to optimise the building design in terms of energy, design time and cost. Testing will encompass those functions which are directly related to the design process and which will be used by the test site partners in undertaking the design process on their selected buildings.

At this stage, COMBINE 2 partners who are to be involved in the acceptance testing of the delivered COMBINE system are actively seeking support to help finance what is essentially a costly but very necessary part of this project. UCD is also in the process of producing an Acceptance Testing Specification which will set out guidelines by which testing of the COMBINE 2 system will be carried out. Each test site will have individual characteristics and needs and, therefore, a specification is being created to allow a degree of flexibility in the setting-up and the carrying-out of the testing procedure.

Acceptance testing will be scheduled for the final two months of the project, finishing around the end of the summer 1995. A final seminar will be organised to demonstrate to those interested the results of COMBINE 2 and to review the overall project.

TASK LEADER: Energy Research Group, University College Dublin, Ireland