Tekla Structures Model and MS SQL Server Synchronization

1. Executive summary

This application was developed to demonstrate capability of synchronizing Tekla Structures Models data to a commercial database such as MS SQL server or Oracle and being accessible via internet. Having model date stored in a SQL database allows one:

• To share model information remotely through web application and browser type application;
• To have more developers (e.g. web developers) developing applications with model information;

This solution was not available on Tekla Extranet. If you are interested in obtaining the program or need advise on developing your own tool please feel free to contact me.

See demo videos on YouTube

Part 1: Synchronizing model data to SQL server 

Part 2: Example web application to access and modify model date remotely

2. Introduction

We had received requests from clients who want to have a solution where they can exchange Tekla Model information with a relational database.  Although our XML export seems pretty sufficient to serve this demand but most clients still want to have a dynamic exchange capability, which is tailored to their in-house solution, rather plain XML files interchange. Clients from different segment all present similar interest for such a database solution including Steel, Precast Concrete and Contractor segments. Although ways of using a database are slightly varied from client to client, it still motivates to have a general solution for all instances and possibly specialization for each later.

This project and prototype is meant to be an interface or platform for more Tekla users to create their own extended application by using Tekla Structures. It is not an end-product because clients will use it in different ways. A database more likely will serve as an intermediate tier for data exchange, especially for web-based applications. In our TSRELDB (Tekla Structures External Relational Database Synchronization Toolkit) prototype, we actually demonstrate how one can write Tekla model information to various external databases such as Microsoft SQL Server, Access or a plain XML file. Relational database is engine and backbone that drives the entire eCommerce, financing and ERP/MRP/MIS bushiness.

2.1 DB Evolution and Trend in a Nutshell

It is good to have some basic knowledge about database prior to start. The following paragraph provides a brief background in the database evolution and history. There are two common misconceptions that need to be clarified:

The first misconception of database is directly thinking a commercialized relational database such as MS SQL Server or Oracle as the de facto term of 'Database'. In fact, database is a generic term for simple data storage. Commercial database e.g. MS SQL Server and Oracle are known as Relational Database (RELDB) where there exists another type of databases such as Object-Oriented Database (OODB) or a hybrid database system such as IBM DB2. Tekla Structures also contains a native database which is half relational and half object-oriented.

Database is simply a storage component where you need a management system on-top to manage information and transactions. This is known as Database Management System (e.g. RELDBMS or OODBMS). It is fair to say that part of Tekla Structures role is to perform a role as a DBMS of Tekla internal database (i.e. DB1).  

Underlying database in Tekla Structures is, one of many instances, of a proprietary database system. It is hard to classify whether it is purely a RELDB or OODB since it accommodates features from both sides. This is similar to IBM DB2 database, a hybrid database system. RELDB and OODBMS were competing intensively in the 80's. Most OODBs truned into a nitch market after big companies such as Microsoft and Oracle have successfully conquered the database market in late 90's. This led to a fact that 1) SQL becomes the de-facto interface to access a relation database and 2) most business, corporations, and enterprise databases are developed in RELDB. In fact, RELDB is very good to handle business and financial data where OODB is good in managing engineering and mechanical data for example geometry.

It is clear that RELDB will still be the mainstream database solutions in the next decade.  There is a trend where most RELDB are blending OODB features back into the RELDB (e.g. conforming to SQL 3 standard) because the success of OO programming language and hierarchical information such as XML. 

In short term, it seems unavoidable to have solution to integrate Tekla Structures with a RELDB since it has been widely used in most web-based eCommerce systems and incorporated in many ERP systems today.

The second misconception is not to think database separately to its front-end applications. Most MS Access users have this dilemma because its database is totally tied with its front-end functionality. It is the front-end application which defines the character and behavior of a product but not the database. 

Figure 1evolution of database in the last 3 decades

2.2 Customer Demands & Motivation

We have received several requests from customers to exchange model information in a relation database fashion e.g. a portable database file such as MS SQL Serve Express or MS Access file. Basically, demands are classifiable into two categories:

• A solution and data exchange interface through a relational database that can easily exchange information with client's ERP/MRP/MIS or eCommerce systems. A B2B integration is highly demanded. 

• A platform for many extended applications, mainly web-based applications that interact with a linked output database. This is more likely to be used in a B2C integration. 

3. Scope and Plan

Scope of TSRELDB aims to support an intermediate platform to integrate Tekla Structures with commercial database. We have less interest to customize front-end applications for clients at this moment. TSRELDB is considered an interface where clients can easily employ and tailor their front-end applications. There are more web/database application developers who can develop 3^rd party applications without having expertise in data structures of TS .NET API. In other words, application development will become more easy and available to developers who know simply SQL but not our .NET API. This hopefully can increase 3^rd party developments for a variety front-end/extended applications with Tekla Structures, and also reducing learning curve on Tekla Structures .NET API.

Since database solution is closely tied to World Wide Web, it actually opens alternative ways to integrate Tekla with our customers' and partners' in-house systems, triggering migration from file-base to dynamic database information interchange. Implication includes rethinking and reinventing possible business models in a long term.

We will discuss several use cases and potential integration methods to show how clients can utilize their benefit on incorporating with TSRELDB. In summary, the following list simply defines things that are included or excluded from TSRELDB.

Things are included:

• A simple server side application that synchronize TS Model Data to a database medium, e.g. a database or XML file
•  A late-binding like data schema that consists with four tables, 'Project', 'Transactions', 'Objects' & 'Properties'.

Things are excluded:

• Any programmability on the database side for example stored procedures, views, functions, etc. It assumes that customers will customize this programmability by themselves;
•  No trigger, index or other optimization have been added to the database schema;
• Tekla users who want to work collaboratively can use our multi-users feature on a domain network. The TSRELDB has no intention to replace this existing and good mechanism. It aims to support another type of client-server collaboration;

3.1 Potential Usage & Used Cases

MS .NET framework obtains great features to 1easy application development in web-based database driven application. Strength of MS .NET framework has been shown in many directions; especially in 1) incorporate with relational database integration and deploying 2) web-based. RELDB apparently serves as the backbone of most eCommerce Enterprises and ERP/MRP/MIS solutions.

Possible usages are described under following categories: 

1) Different Client-Server configurations

2) Integration with client's EPR/MRP/MIS and eCommerce Solutions

3) Interface to various handhold devices e.g. mobile phone, tablet PC, palm pilot, etc.

4) Other applications

 
3.1.1 Client-Server Configuration

There are several ways to configure usage of a database. Section 3.1.1.1, 3.1.1.2 and 3.1.1.3 shows different configuration of using the TSRELDB. Implication of configuration is really to see how TS is involved in various configurations.

3.1.1.1 Tekla Structures on both Server and Clients

Figure 2 TS on both client and server

Main concept in this scenario is to maintain a centric 'master' model where distributed clients read and write data to the master model. This is redundant to the existing multi-users feature but probably consuming less resource in terms of the network bandwidth. It is possible to integrate TERELDB into Tekla Connect under this scenario. TSRELDB is not meant to serve process of collaborative design simultaneously.   

3.1.1.2 Tekla Structures on Server only

The second scenario is to maintain similar master model in server where thin clients reside on client ends, for instance a web-browser client. This scenario is more adequate to management and not design tasks.  In other words, it is good for visualization, e.g. RFI editing and other construction management tasks.  Our prototype demonstration is implemented under this particular scenario.

Figure 3 TS on Server side and not client side

3.1.1.3 Tekla Structures on Clients only
 

Figure 4 TS on client ends but not on the server side

The third scenario is to have Tekla on multiple clients and none on the server side. It does not maintain a master Tekla model but a proxy that resides on the database server.  Each client will need rapid synchronizations to update their attributes to the proxy model. The proxy model then synchronizes with all clients. This requires better merging capability and concurrency control on the database side. 

3.1.2 ERP, MRP, MIS & eCommerce Integration

The most prominent use case of TSRELDB is to connect client's in-house database, in other words, establishing a link between two database systems. Figure 5 Illustrates this basic integration where B2B integration bridges two database systems. Front-end client is part of the ERP system that handles resources, supply chain, delivery and inventory managements. TSRELDB is an adequate solution for Tekla clients who are part of an ERP supply chain.

To derive meaningful and mandatory information from one system to another relies on a mapping process or known as views. There are professional mapping tools, for example the Microsoft BizTalk is a mapping middleware that allows interchange between databases. Altova, a a leading XML toolkit provider, has similar product for XML mapping named MapForce.  Clients who want to adopt TSRELDB may need to derive their mapping scheme.

Figure 5 B2B integration platform for ERP, MRP, MIS & eCommerce solutions

3.2 Interface to diverse devices

TSRELDB provides an additional tier to Tekla Model by deploying a commercial relational database.  It is very common and easy to write applications that operate on handhold devices and read data from a database. In spite of a web-browser client application, it is possible to write clients on diverse handhold devices such as Windows CS for cellular phones or tablet PC.

Figure 6  an intermediate platform for diverse handhold devices integration

3.2.1 Other Applications
 

Model Information Archive and Rollback

TSRELDB records each transaction time where it is possible to perform a rollback function. For example, write all properties and UDAs back to particular date and transaction.
 

Alternative Change Management Storage

It is fairly easy to perform comparison on a large set of data in relational database. TSRELDB provides alternatives to one to tailored properties and attributes that will be caught in c round trip data exchange. In other words, one can define what is classified as a "change" in a more dynamic and expandable fashion without hard coded and persistent classifiers in current.

3.2.2 Summary

Scenarios and usage listed above are basic examples of how to utilize TSRELDB. We believe more clients will be interested to link Tekla from to their in-house database solution through database integration. The required expertise of database and web programming is extremely lower then knowing Tekla .NET API. You may look at this database integration interface as a wrapper interface to Tekla .NET API.

3.2 Acknowledgement 

Special thanks to Stacy Scopano and Andy Dickey from Tekla Inc.

4. Video

5. Glossary & Abbreviation

TS - Tekla Structures

RELDB - Relational Database

TSRELDB - Tekla Structures Relational Database Synchronization Toolkit

OO - Object-oriented

OODB - Object-oriented Database

RELDBMS - Relational Database Management System

OODBMS - Object-oriented Database management System

MS SQL Server - Microsoft SQL Server

SQL - Structured Query Language

SQL3 - SQL standard Version 3

ERP - Enterprise Resource Planning

MRP - Manufacturing Resource Planning

MIS - Manufacturing Information System

B2B - Business to Business

B2C - Business to Customer

XML - Extensible Makeup Language

LINQ - Language Integrated Query

關於BIM

BIM（Building Information Modeling） 一詞的由來

誰是第一個提出BIM這一詞的人現在很難分辯，Wikipedia上說該詞由AutoDesk Phil Bernstein 所提並非不可能，但很難據體的查證 。 就我個人所知Jerry Laiserin應該是第一個提出BIM這一詞的人，起碼我和我的指導教授Chuck Eastman(BIM Handbook 的作者 )以及Georgia Tech同儕都這樣認為。Jerry原為BIM Handbook發起人兼作者之，因家中突然有事所以臨時退出編輯僅為該書撰序。因為BIM Handbook後來的廣大發行，所以一般都認為Chuck是提出BIM這一詞的人。但Chuck 所提出的Building Product Model 可以視為BIM前身之一，其它影響該觀念成形的有同時期ArciCAD 的Virtual Building。有關這部份請參考Wikipedia 或BIM Handbook不在贅述。

過度的消費及行銷

BIM這一詞在美國已經被過度消費，加上軟體廠商（當然包含敝公司啦）的大肆渲染下已成為濫殤。 軟體廠商很努力的把自身產品與BIM劃上等號，深怕趕不上這波動而失去商機。許多AEC (Architecture, Engineering & Construction) 從業人員也競相標榜自己為BIM 專家。就我多年的經驗及專長，感覺有必要在這裡釐清一些不必要的誤解。

BIM並不是科技而是一種流程（process）

BIM 是一個總體的稱謂，其中的「M｣ 是Modeling 而非Model。軟體廠商希望用Model（名詞）主要是因為可以將其產品直接標籤為BIM。

BIM 的組成包含了「使用者 + 軟體 + 流程｣

它是一個由以上三者之間共同組成的概念，你很可能是其中的一項的專家，但很難同時成為所有三項的專家。舉例來說，一個精於工程流程的專家很可能同時也是某一軟體的資深或高階的使用者，但他專精於軟體開發的可能性卻是極少的。使用者是使用者而開發是開發，角色是非常不同的。專家的定意就是對課題的通盤瞭解，也就是所謂的know-how，因此光是熟練於使用很難成為真正BIM專家。

BIM的流程是沒有標準答案

它會因案件 (例如Bid-and-Build or design build) 、公司流程、組織而不同。 通常牽涉到使用數個以上的軟體以及某種程度的客製化。很多企業認為花了大錢買軟體就可以解決一切其實是錯誤的觀念，BIM是一種認同及長期性的投資及開銷，它的獲利在於減少工程中錯誤及衝突，增加不同單位間資訊交換的效率。如果大環境還停留在2D圖面為主時，單獨實踐BIM很難看出會有結構性的改變。

團隊的組成

營建團隊與電子、航太、或造船業最大的不同在：

1. 團隊的組成多為平行單位的合作而非上下游產業的垂直整合。航太工業中業主（例如波音）可以強勢主導所有下游廠商生產線的設置，包含所使用的軟體、及整合界面 (例如其777的設計生產過程由747 的18年縮短為5年，這我另外寫一篇報導)。營建業團隊在發包型工程中因為多是平行的關係加上業主多不強勢主宰所有細部流程，因此整合地方式與其他工業不同。
2. 團隊的成員組合因案而異 - 發包型工程團隊成員合作期間較為短暫。必須於短時期內配合對方的系統、流程、及始用軟體。

這樣的團隊組的方式影響了許多層面，包含了過程中需要使用較多的專業軟體，也牽涉到較繁雜的資訊交換。 一般使用者以為IFC可以解決其中的資訊交換其實是錯誤的觀念，關於IFC 我會另外說明。

單一件軟體很難滿足及涵概整個建物生命週期中所有項目

BIM所含概的範圍很廣通常概分為(分類的方式沒有一定) ：

• Preconstruction – Design (CD, DD, CD), Estimating, Bidding, Detailing, Pre-fabrication ( pre-assembly), etc.
• Construction – Fabrication (CNC, robotic welding and manufacturing), Field Operations (Layout, surveying), Project Management (Cost, scheduling, RFIs, reporting,…)
• Post Construction – Submittal, Inspection, Facility Management, etc.

從以上的分類而言，光是其中要使用軟體就不計其數。除此之外，由於專業分工越來越細 既始是建築師也只能掌握一部分的流程。對建築師傳統以來扮演的協調者角色有一定程度的影響。

軟體開發是百分之百的市場導向

軟體開發就像程式本身一樣完全符合邏輯而且是百分之百的市場導向。近年來因營建軟體市場 (尤其是建築師及技師使用的軟體) 已經相當飽和。在競爭激烈下加上利潤空間很小，所以均轉向開發營造廠或業主為主的軟體。這其中的利潤遠大於軟體廠原來專營的市場。在工程中由於營造廠或業主掌握較多的資源，所以自然的成為銷售目標。就以一套10000美元的軟體來說，賣給造廠或業主的可能性遠大於賣給建築師及技師。不同於日韓營建體系一條鞭的上下整合，台灣與美國的發包制度系統比較相像。因此業主或承包商對BIM軟體的投資可以在較短時間或該工程內回本，但對複委託的建築師及技師而言，因為工程中業務執行款項百分比之分配較少（5％～10%，羨慕吧）加上通常不是最大受利者所以在意願及執行上較緩慢。但不少大型建築師及技師事務所確實體會到BIM長期帶來的好處於是將採用BIM轉化成為提升自身品牌行銷(Marketing) 及提供較優勢之客務以超越競爭對手。美國越來越多的公部門和業主在工程合約中開始加入BIM的規範。但因為相對費用每有相對提昇所以對許多中小型事務所而言是非常吃力的要求。這點爭議牽涉到對現有發包制度的重新定位，但趨勢而言是不可避免的。

我們可以把軟體使用於BIM的方式分成兩極，一頭是單純使用。你可以買一套軟體加一點訓練然後就開始使用。這種模式使可以減少你需要付給軟體商的固定客服及生級費用。 另一頭則是類似顧問公司型式的軟體服務，這種模式通常需要付出較多的客服及顧問費用。就像一般財務投資組合一樣，你必須審慎的考慮你的軟體組合，如果你的預算中包含開發經費則另外要考慮到軟體的客製化能力。

在McGraw Hill 2009發表的BIM白皮書（http://bim.construction.com/research/FreeReport/） 統計了2009年不同營建專業對BIM的實踐，並預測了2010的發展。該報告中推斷BIM在所有營建相關的行業中，營造廠對BIM將會在2010有最大的發展及實踐 。這個預測其實滿準的，美國ENR前400大的建築營造廠 (不包含石化廠及重工業的營造廠例如Bechtel and Fluor) 像 Sakansa、Turner、 Black & Veatch、 DPR、 Swinerton、Barton Malow、 都已內設BIM系統整合單位，並且已逐漸的將BIM融入內部企業生產流程。除此之外，BIM Handbook （包含已發行的二版）中多數案例皆屬於「新整合流程｣相關的主題。除了內設系統整合單位，外包的顧問公司例如Gafari則提供系統整合或Lean Construction 的專業服務。

McGraw Hill Smart Market Report

不是具體的主題所以不適用於學術研究

BIM 不是一個非常具體的研究課題所以請慎選你研究的主題。就以喬治亞理工與史丹佛為例，前者偏科技與工程中資料訊息的整合，後者偏新流程的實踐與分析。你的研究主題通常可能與某一科技之使用或流程細項有關。舉例來說，科技類主題包含了資料交換、資料庫、語義學、認知、參數化資料交換、設計模擬分析(e.g. Code Checking)　等等而非BIM本身。主題以流程為主的則有著名的4D CAD。

喬治亞理工最近剛成立的Digital Building Laboratory 有對不同BIM軟體之參數化(parametric) 進行比較　(需註冊)

• http://bim.arch.gatech.edu/
• http://www.dbl.gatech.edu/

史丹佛的CIFE (http://cife.stanford.edu/)

問題與意見

我會對以上每一項在進一步分析說明(這可以是一整學期的課程)，如果你對任何一項有意見或疑問或需要某一主題的說明，歡迎你電郵給我逐一的如果有問題請不吝指教。

我個人曾參予不同領域對BIM 的推廣包含National BIM Standards, AGC BIM Forum, AISC (eCommerce Summit, CIS/2 Workshops), BuildingSmart, BuildningSmart IFC2X3 certification process), AIA Building Connection, etc.

  　

Link Manager- BuildSite and Tekla Structures Integration

About this project

This project started from simply adding external hyperlinks to Tekla Structures model object so links were reusable in the model. Ad-hoc attributing is a common feature in many BIM, 3D or parametric systems in current.  It allows user to attach additional information to model objects that enriches semantics and usages of native objects with greater customizability. 

From a simple macro, we started to get more demands from users for a managerial UI (User Interface) to manage external hyperlinks. Most users wish to obtain a “Document-Centric View” to organize documents and links, sort of a hierarchical grouping mechanism. This is quite common whereas most 3D BIM are geometry centric, meaning information are organized and displayed purely in a 3D object fashion. This is certain because nature of the application and service it provides.  However, from a collaborative perspective, more and more tasks require views from multiple perspectives such as document organization or view of schedules. A typical example is the 4D CAD where one needs to visualize information from both temporal and physical views. This therefore becomes a primary change from previous macro to a more coherent solution.

In conjunction with a newer UI of Link Manager, we combined the BuildSite integration in the same solution since their functionalities quite overlapped.

BuildSite is an online manufacturers, products, material documentations and reseller information for building construction. Quite like an online “Yellow Page” on steroid. It is applicable for contractors’ submittal process. Contractors can find mandatory documents of inspections, material tests, manufacturer guarantee and other useful information for submittal. It also serves as a search engine that allows contractors to find products, manufacturers, and reseller information from particular product category.  It supports different “categorizations” including master unit format and soon believe to support OminiClass classification.

For more information about BuildSite please see>>

Integration Highlight

For user’s to select BuildSite information in runtime, a light Web Browser is therefore incorporated into the application. It parses an underlying XML file returned from a BuildSite URL query. Parsed contents, especially hyperlinks (HTML) that linked to a document file such as a PDF file are then displayable to users for selection. All links are bind to nodes in an underlying XML file that serves as a live database. User can manage multiple links tailored to their needs.

The following video is a general introductory of Link Manager:

Result and Future Work

Intention of creating Link Manager was to create a prototype to collectively generate a specification that can be incorporated into main product one day. At an application architecture level, I used this opportunity to outline a fundamental module to support generic association that is applicable to many other tasks e.g. the 4D CAD tasks.

Acknowledgement

Special thanks for Andy Dickey who manages the partnership of BuildSite and Hannu Lindberg who collectively manages all users’ aspects and feedbacks.

Reference

Presentations

• BuildSite Tekla Structures Integration  1.5MB (.ppsx)
• Link Manager 1MB(.ppsx)

Use Cases

Link Manager has been adopted in several commercial projects since then. Here are a few use cases

• BIM Based handover and facilities (.pdf)
• BIM Based handover and facilities(Tekla Web Site)

Book Review- The Imperial Cruise by James Bradley

I recently finished reading a book called “The Imperial Cruise A secretes History of Empire and War, written by James Bardley.

History has always been my hobby since ever. I spent some time in modern Japan history and found this book which gives a fresh perspective of a particular era in modern Asian history, a time around the period of late 19^th. Author’s opinion and perspective is quite interesting, at least not from a conventional Westerner viewpoint. The entire story is tied to a single diplomatic corps authorized by President Teddy Roosevelt (26^th president of US). Teddy sent his daughter, Alice Roosevelt, a celebrity figure at that time like Jacky in the 60’s and his secretary of defense William Taft (27^th president of US) on a diplomatic tour to Asia. The corps stopped at Hawaii, Philippine, China, Japan and Korea. Taft had carried a secret mission to sign a secret treaty with Japan Empire to not intervene US annexation of Philippine and in exchanging to allow Japan “have” Korea. This was done secretly without having any consensus from congress and crumbling Teddy’s heroic figure today. Remember that Teddy is one of the four greatest US presidents on top of the Mountain Rushmore. 

How a single incidence can affect the entire regional modern history, and later resulting 10,000 US soldiers died in the pacific theater during WWII. The author also explains the ideology behind America expansion, aka “Chasing the Sun”, towards West, and conflicts/massacres to native people along the progression towards West. Blood was shed almost with no exception from early Native Americans, native Hawaiians, Philippines, and 19^th Chinese immigrants. I recommend you to read this book especially if you have Asian heritage. Maybe I shall translate this book.

My next book review is “Morning of Fire” by Scott Ridley. A book about two US ships sail from Boston to Pacific during early 17th century. The voyage to establish new trade routes and ventures following famous captain Cooks great expedition.

Workflow Manager Phase I – Tekla Structures and Meridian Prolog Integration

About this project

This is another integration product started from 2010. The goal is to link Tekla Structures, a 3D Construction and Structural BIM, with Meridian Prolog Converge, a total construction project management system.

• To learn more about Meridian >>
• To learn more about Tekla Structures>>

Meridian Prolog is a project management software that manages documents and workflows including, drawings, submittals, RFIs, punch list and inspection, meeting minutes and other construction related documents. Meridian is now part of the large Trimble umbrella solutions due to earlier acquisition. Tekla and Meridian had assigned a partnership agreement to develop a closer integration for their joined users. The project started not until 2010 after the agreement was assigned.

I started prototyping the integration in mid 2010. Main challenge of this project falls into technological differences between the two systems. A 3D BIM versus a relational database and web-based software.  Meridian Prolog provides customizable integration through its web-services API to its back-end relational database. Figure 1 shows the integration scenario for the first phase prototyping. Scope of the exchangeable information was restricted only to RFI in the first phase. The intention was to build a robust and easy scalable foundation and possibly progress into other services in later phases, meanwhile to gain understanding and master the Prolog Web Service API.

Figure 1 Integration architecture

Andy Dickey, business manager of the construction unit in Tekla US, sees potentials towards expanding such tool in supporting diverse workflows. The tool was therefore renamed as “Workflow Manager (WM)”. The first beta prototype of WM was released in late 2010 to a few selected testers to gather feedback and usability testing. Fred Cardena, a long time Tekla Structures user and industry expert, who now worked for Meridian tested the WN and provides valuable feedbacks and suggestions for future improvement.


Current Status

The current WM prototype is available only for Tekla Structures 16.1. It is in the middle of a full upgrade and renewing. Current WM prototype allows users to:

• Associate a Prolog RFI to selected Tekla model objects;
• Allows Tekla Structures users remotely modify existing RFI in Prolog Converge;
• Enable browsing RFIs from selected projects, and portfolios from Meridian Prolog;

To know more about the features in WM, please watch the following introductory video. It will provide a brief overview of WM.

Highlights

Meridian API has a quite good structures and namespace hierarchy, from my perspective, in comparison for many APIs that I have been worked on. It is nicely wrapped into .NET and web service. Since it runs on a relation database i.e. MS SQL Server, it allows one to attach documents or BLOB (Binary Large OBject) to existing information objects. Information objects for example a RFI or a submittal document. Hence, it is possible to store additional metadata or attributes e.g. an XML file, to particular information object. This allows us to store a XML file that contains a list of GUIDs from associated 3D model objects to any information object.

The solution requires static connection to the connected Prolog Converge and its database. Speed of fetching data from the source depends on user’s internet bandwidth. Hence, a two tiers data fetching process was adopted to avoid unnecessary operations. In the RFI example, the first fetching process simply reads all RFIs headers (metadata) and displayed to users. Once an RFI selected by users, it will then launch the secondary fetching process to read more detail information of the selected RFI from the server.

Achievement

Things I have learned and used in this project:

• Meridian Prolog Web Services API
• Tekla Structures Open .NET API

Acknowledgment

Special thanks to Meridian, Fred Cardena, Tekla Inc., Andy Dickey and Hannu Lindberg.

Reference

Video
Tekla Structures Workflow Manager - Integration with Meridian Prolog Converge

Layout Manager- Integration between Trimble LM80 and Tekla Structures

About this project

Layout Manager is created to integrate with on-site layout equipments. Layout equipments are widely used in current construction sites. The term "Layout" (放樣) sometime is confused with "Surveying" (測量), which mostly serves site preparation or civil projects. There are usually three different types of measuring equipments used in a construction site: 1) site-preparation, 2) layout, and 3) leveling and alignment.

The Layout Manager project started after the establishment of Tekla and Trimble partnership in 2008. The scope was to explore possible way to integrate construction site Layout technology, including both hardware and software, with a 3D construction management application. The integration is a directly link between Trimble Layout SDK and Tekla Open API. Trimble Layout SDK is a set of DLLs that enable to read and write layout information between hardware device and partner applications. A prototype was quickly released during the time of Tekla Structures 15.1.  The first testable alpha version, called Layout Manager, went out in 2009 as an extended application that runs on Tekla Structures 16.0. The extended application lasted through several versions and finally being incorporated into Tekla Structures in 17.0.   

Layout Manager allows you to: 

1. Export model points to the field device so operator can easily mark points in field.  This is extremely applicable to work collaboratively between structural systems. For example marking precise anchor bolts locations in a concrete footing prior to pour. Then the steel column can be erected and bolted seamlessly to the anchor rods with great precisions. Other applications include positioning concrete formworks, MEP boxes, pipe-hangers and pipe routing and etc.
2. Bring field points into 3D model for validation and checking. Operators are allowed to check whether collected field points are aligning properly within the model which increases the overall precision and quality of job.

Trimble Total Station

Above figure shows the basic components of a total station. The left is the receiver station where you place it according to a known reference on field. An operator will take the pole (middle) and walk around on field for positioning. The receiver station will constantly sending out signals and capturing reflection from the pole which obtains a high accuracy optical reflector. The measured distance then will be displayable in the attached device. There are a wide arrange of devices that are available form the manufacturer, ranging from a mobile device to a tablet.

Figure 3 points where to embed MEP piping hanger screws on the slab formwork

Integration Highlights

Layout points and lines are likely being used in multiple scenarios. Scenarios such as previous positioning of anchor bolts, concrete formworks, and MEP equipments. A generic point and line is demanded to serve in different scenarios where specific properties are addable in an ad-hoc fashion later on. Hence, a simple parametric point and line object are created. The intention was for people to use these basics and further extending them to other parametric objects, aka Components in Tekla terminology. By nesting these parametric objects together, I foresee great flexibility and possibility to newer breeds of use-cases.  

In addition, a standalone browser and application is created to visualize and manage points and lines created by users. The point and line components together form the overall layout manager structure. As an example of extending the generic point to other scenarios, Tekla US office has created a custom component for concrete footings that automatically place points 1) to footing corners and 2) intersections between anchor bolts and top surface of the footing.

During the project period, Trimble Layout SDK leverages Windows ActiveSync and earlier Mobile 6.0 for synchronization. A minor impediment is that MS Mobile does not support direct copying files from a 64 bit machine to the device. Hence, this was absent from Layout Manager.  Current version of Trimble Layout SDK consists of three C++ native DLLs.

Lesson learned

In order to visualize layout points in Tekla Structures, I need to embed an explicit Part i.e. beam in the layout point component to resize it and reshape accordingly to different scenarios. Ideally, points ought to be displayed as a graphic object such as a coordinate tripod or a simple .dwg object.  Unfortunately, this was not available in the API at this moment. It causes some ambiguity in user’s reports and drawings.  

I have learned Tekla Structures API and Trimble SDK from this project.

Future work

Tekla has received a lot of feedbacks from users after rolling out the Layout Manager and overall contributing to a better integration solution in future. It requires enhancements on both sides. In spite of the users’ suggestions, I personally will like to see:

1. Incorporable with Geo-Spatial coordinate system: This is not a big challenge since Tekla already has the know-how from its X-City product.  This makes points translatable among conventional Cartesian coordinate systems versus Geo-coordinate systems. It is then possible to link with other Trimble solutions.
2. A remote and wireless synchronization:  This could be done by either Tekla Structures or Trimble. A ubiquitous synchronization process between points and possible receiver. There are many alternatives to approach.
3. Enhancements on the Trimble SDK is desired, for example GUID assignment, enable raising events while new points created or existing points modified, or project saved and closed.
4. Desired changes on Tekla Structures API:  incorporate graphic objects in the API. Graphic objects shall be persistent after view changes or redraw.

Acknowledgment

Special thanks to Trimble, Tekla Co, Tekla Inc., Hans Ehrnrooth, Stacy Scopano, Andy Dickey and Hannu Lindberg.

References

Videos

• Tekla Structures and Trimble LM80 - Part 1
• Tekla Structures and Trimble LM80 - Part 2
• Trimble Total Station
• Taking BIM to the Field with Tekla and Trimble LM80 - Part 1
• Taking BIM to the Field with Tekla and Trimble LM80 - Part2

Webinar

• BIM for the Jobsite webinar
• Tekla Structures for the Erector Webinar
• Structures Congress/North American Steel Construction Conference (NASCC 2010)

Documents

• Connecting Building Information Models to Robotic Total Stations