Volgende: Conclusions Omhoog: Case studies Vorige: Using Ontologies and bcoWeb: Inhoudsopgave
This section presents a showcase that demonstrates the feasibility of the bcoWeb and illustrates the reasoning behind the most important conclusions drawn in chapter 6: building a bcoWeb improves BC's value adding performance; national differences matter, so it should be done (at least start) on a national, not international, scale10.1; BC web services are essential in getting BC's building process innovation going.
Some of the most important stakeholders in a typical overpass project are governmental bodies, authorities, the general public, main contractors and subcontractors, road designers, structural engineers, cost calculators, knowledge providers, etcetera. The case will show that many of them can join into the project in an earlier phase and in a more flexible and economically attractive way than currently feasible.
Each stakeholder has its own view on the construction project. The general public is not interested in most of the purely technical data. People living in the area are more interested in the level of noise to be endured during construction, or the traffic flow to and from their homes or work, etc. Figure 8.6 shows imaginary integration of semantic data with google maps (`imaginary' meaning that it is example data; this kind of data coupling is made routinely with google maps, see [121] for an example).
 |
An interest group's knowledge database accesses the data of an environmental planning group that provides them with a continuously updated GIS view. This view is transformed into a 4D view of the project and a good sound level estimate based on, for instance, the drilling method used for the foundation piles. This is a completely different view from the CAD view of the designer.
In order to make these views more effective, the environmental planner's GIS data should also be brought on a higher (semantic) level including objects like `building', `neighborhood', `parcel', `greenery'. These object definitions should be entered in the bcoWeb.
In the opening stage of the design and decision-making process the project road designers, for example using MOSS (figure 8.7), produce a gradual refinement from a broad concept to a more detailed design. Ontology data concerns for example objects like `road radius', `road section', `gradient'.
Contractors and subcontractors retrieve a description of the project in terms of bcoWeb Ontology data. Their tools are able to understand that input without any problem and are immediately ready to do the calculation required. Among themselves and their partners they communicate using objects like `contract', `budget', `bulldozer', `time-slot'. Definitions of these objects are again collected in a separate part of the bcoWeb.
Especially important for this case is the ability to plug in cost knowledge, as infrastructural projects often have a sizable political and budgetary component. Ideally, a reasonably accurate cost estimation has to be available in every stage. The estimate will be less accurate in the early stages and more accurate in the final design stage, but the level of accuracy can itself be provided along with the financial figures.
The case10.2 will be described in a chronological order. Figure 8.9 shows the basic structure of a bcoWeb Ontology for overpasses (and potentially other road crossings and bridge-like structures). Figure 8.10 shows the Dutch and English content in the bcoWeb interface.
It is interesting to note several national differences here. When traveling abroad by car it is apparent there are differences in road construction, like: highway exits, crossroads construction. Britain's roundabouts (see figure 8.8). The Netherlands have roads with a pile foundation in certain areas of the country to keep the road from sinking away in the mud. You won't find American-style wooden tressle railway bridges in Europe. In Indonesia houses are constructed with bamboo. Norway's triple glazing insulation won't have much use in hot climates. Differences stemming for example from national differences in soil, elevation and curvature, climate, legislation and culture should all be taken as a fact.
Differences like above make it infeasible to create one single Ontology. If certain parts can be shared, it will be in a highly focused area. In highly international industries like oil drilling, there is of course a much better chance of internationally feasible Ontologies. Note though that it are exactly industries like this that already have existing (STEP-based) solutions, see section 3.3.1.
 |
 |
Assumed is a political or technical wish for a new or improved road crossing. In the future BC process, bcoWeb can start assisting the process already in this stage by providing input to a decision support system. BcoWeb is organised around a demand-supply distinction or, phrased differently, a question-answer distinction. The demand for a road crossing is coupled with possible solutions like overpass or level crossing. A bcoWeb interface like in figure 8.10 is more of an internal look in the underlying data, the intention is for the data to be used in existing or new end-user applications.
 |
At this point in the process, an initial cost estimation is desired to provide feedback to the designer and the (political) Client. The only real data available is the wish for an overpass (the assumed desired solution) with some basic traffic engineering data like the needed number of traffic lanes and some basic situational data like the length of the span required to cross the lower road.
As described in chapter 4, web services allow an elegant way of handling this. Via the web, your application can connect with an intelligent automatic service provider elsewhere--gaining access to specialised knowledge. Instead of building detailed cost knowledge into each and every application, one single cost knowledge web service can provide it in one go for every application.
Figure 8.11 shows how this process could play out. Spreadsheets are a common way to slowly gather, create and build up knowledge of a data-oriented nature. The figure shows a spreadsheet such as created by the bouwdienst for gathering information on cost estimations for early-stage overpass projects.
This generated valuable knowledge can then, by an IT expert, be turned into a web service--increasing knowledge integration, as the knowledge can now be used by a number of other projects, also outside the bouwdienst. The knowledge transfer that can be achieved with printing booklets or writing papers is quite limited. With such a web service, however, the knowledge can be applied directly and broadly.
The web service filters out the correct properties for the overpass and calculates--based on the spreadsheet--the price. This price can then be shown in, for instance, the object tree application. This is not the only option, as the web service can also be used by the financial department to get a running tally of the projects currently in the opening phase.
This is a web service of the kind that you see in many on-line examples: it receives information, calculates something and returns the value. Currently, the bouwdienst is creating spreadsheets to capture cost and estimation information, but without a system to tie it to. In the envisioned future it is normal to have and to make such data available over the Internet. Knowledge management applications assist in structuring information and in gathering available information. This can already help within a single company or government department, but it really shines when connecting companies with knowledge institutes (like TNO, CSTB, CSIRO), suppliers, legislators and so on.
How? In the envisioned future, it is as natural for cost estimation data to be available to your CAD-package as it is now to Google [122]. As a provider of cost knowledge, the easier your customers can use your data, the better for your business. Current practice is to deliver a stand-alone application to your customers in which they have to re-enter all their project data. Double work. In the future scenario, you can put your cost information on-line. Of course with password protection, as your service has real value to your customers--meaning paying customers in this case.
As a knowledge provider, you have a better and easier way of serving the customers. The provider of, for instance, the project management application also has an advantage. He can integrate your (and others') downloadable cost knowledge directly into his project management application, making it a more valuable tool for his customers. A win-win situation by reducing the friction in the market and thereby increasing the market's size.
In the overpass scenario, the first cost estimation will likely come from the internal knowledge from the bouwdienst itself. Once you go deeper into the technical details, generic BC cost estimation services take over.
With the choice for an overpass made, the next phase of the project starts. On the design level, choices must be made for the next level of detail, where bcoWeb again can lend a hand. We've got the question/demand for an improved road crossing; we've made the choice for an answer/supply of an overpass; next come the the subparts, which are questions again. An overpass consists of a foundation, supports, and so on. So we want a foundation, we have a demand for a foundation.
Important for building process innovation is that bcoWeb allows more parties to join in earlier. Instead of throwing a bundle with a fixed design over the constructor's wall, the constructor can tie in earlier in the process. BcoWeb is distinctly less strictly sequential than the traditional process.
Switching back and forth from demand to supply back to demand is a simple, elegant solution. It is also easy to follow. And every time, more participants can join in the project. BcoWeb provides, for the solution `overpass', the various subparts as additional questions that need to be answered. There is a constant interaction from demand to supply to demand and back again. It is beneficial for the project to include the possibilities (and prices) offered by suppliers further down the line now that that has become a possibility.
Likewise, now that the lower levels are accessible through bcoWeb, information provided by knowledge institutes or internal best-practice databases can already be used to effect on the higher levels. A recent research's results, added to the internal knowledge database, might show a better chance for project success for underpasses compared to overpasses due to being less intrusive in the landscape. An underpass solution, ruled out initially because of cost reasons, might thus receive attention anyway.
There is a need for new kinds of contracts and forms of co-operation to enable this kind of integration. A bcoWeb-like approach provides the technical possibility; the legal and social framework must be in place, too, to reap the full benefits.
Contrast bcoWeb's enabling of participation with normal information structuring solutions like classifications. In classifications, `static' data is ordered; bcoWeb's structuring mechanism is much more actively involved in the process, it is more `dynamic' in nature. Instead of a one-hierarchy-fits-everything approach, bcoWeb allows for differences in detail level and an incremental build-up of project data.
Another way of stating the difference between the current classification approach and bcoWeb: classifications order documents or CAD-layers, but they don't support the whole process. `Support' is intended in its literal sense, here. The intention of classifications is to order information--for instance CAD drawings into layers of about the same size and importance--in order to keep the drawing manageable10.3. This subdivision, however, has nothing to do with actively supporting and improving the whole BC process itself.
For the overpass project, iterating between supply/demand or question/answer eventually yields a tree-like information structure. This can be supported by integrated project management applications or by, for instance, a focused web application. Behind the scenes, the bcoWeb data is available to both by means of a simple data download.
 |
An object tree application like in figure 8.11 can be used for a further detailing of the initial `overpass' choice. Iteratively, you can build up a tree view of your project. You are totally free to create your own subdivision, but bcoWeb contains the knowledge of common subparts for solutions. So when you tie, for instance, the toplevel `overpass' object to the bcoWeb overpass, you have bcoWeb's knowledge of common subitems at your disposal. This is company-internal knowledge or you can use a common database. Knowledge institutes offer attractive and well-designed libraries of common solutions. Also, Contractors can create small libraries with their innovative solutions--leading to improved supply integration.
As individual smaller bcoWeb Ontologies can so easily be integrated into the whole, a likely source of those Ontologies might become clear: cooperation within a single sector of the industry. (In Dutch: branchevereniging). Within a single sector, there will be a single focus and a mostly consistent agreed-upon vocabulary that makes creating a bcoWeb Ontology feasible. It gives the sector a good opportunity to tie in to the whole structure and to provide added value to their Clients.
In the application, the suggested or possible subparts for the overpass are shown, allowing the design expert to make his choices (or to allow subparts of his own). Since the data is computer-readable, all sorts of decision or design support systems are possible. For a subpart `foundation', multiple solutions are shown like `surface foundation' or a `depth foundation'.
The depth foundation solution, in turn, consists of multiple subparts for which a design decision must be made: the foundation support and the piles. The piles are illustrative for the strength of bcoWeb's emphasis on computer-readable data. There are numerous kinds of piles with different strengths and weaknesses. These strong and weak points can be captured in a decision support system to be coupled with the design tool. Piles that are screwed instead of (noisily) driven can make a certain design much more politically acceptable as the irritation caused by the construction work's sound can be lowered significantly. See image 8.12.
 |
Essential to grasp here is that the general public's input can be used (or enforced) much earlier in the process. A good designer will keep the public's wishes in mind at all times; the new process makes it more explicit, makes it more quantifiable. Of course, not all the general public's wishes can or should be granted. Perhaps a bcoWeb system can make the trade-offs as a whole more explicit, improving the decision making process's transparency and acceptability.
 |
Apart from the design and the technical data, there is also contractual data, legal data, organisational data. This is mostly associated with the Specification. In the future, a Specification takes on a much more active role. A `smart' specification application continually collects project data, keeping up with the various changes and readily produces a traditional specification on the fly. Increasing the height of a building from four to five stories in the design drawings? The Specification application knows that that means that you have the legal obligation (at least in the Netherlands) to add an elevator.
The big `smart' Specification application's advantages are its flexibility and the fact that it is a real semantic Specification: it has knowledge about Specifications, it is not just a paper representation. Specifications used to be mostly paper-based, making them expensive and hard to make, so this was only done at the end of the design phase. Change is no longer expensive and no longer so error-prone, now a bcoWeb compliant `smart' system means that the data is well-structured. A bcoWeb Specification ensures that the right information is available: for everyone, always, everywhere. It is easy to mis-lay a section or two of Specification text when copy/pasting inside a Word document, but automatic Specification checkers will not give you a chance to err in bcoWeb. Just like changing some walls in a CAD package is easy and cheap, just so is changing a bcoWeb Specification. Also the fact that the `smart' Specification application is able to directly access the CAD data undoubtedly will result in substantial reduction of cost of failure.
Flexibility--non-rigidity--also means you can slowly build up the info to be contained in it. Early on in the overpass construction, order-of-magnitude contractual data are added. Perhaps one should say `initial ideas on the type of contract' instead of `contractual data', but that is something to be decided by the project itself. If, bcoWeb-desired, the Specification is available on-line in this early stage, potentially interested Contractors can pre-select projects on the contractual details in the Specification.
 |
The further the overpass project evolves, the more details can be added to the Specification (figure 8.14). The big advantage is that these details can be added the moment the decision is made. So the actual designer gets to make the decision whether a certain quality class is needed--not the maker of the paper-based Specification, traditionally only made right at the end of a project. The drawing-related parts are made with the designer of that part at least close at hand, but in the old paper-based process it is hard to reliably store that temporary knowledge reliably. This either means that duplication of effort (through thought work being re-done by the Specification specialist) or a sub-optimal Specification (for instance demands for quality being set too high or too low). Duplication of effort is costly; likewise work that is delivered to a quality standard that is too high or too low.
What follows from all the above is that the new-style Specification and its creator (a `smart' Specification application) has a more central place than paper-based Specifications. A paper-based Specification derives its central place from the legal and contractual weight accorded to it. A bcoWeb Specification has, probably, the same legal and contractual weight, but is in addition a valuable source of well-accessible information.
The case shows the advantages of bcoWeb for BC, the way in which it strengthens BC's value adding performance and attractiveness. bcoWeb allows many stakeholders to get involved earlier on in the process. Many currently static processes and documents, like Specifications, can take on a much more dynamic and active role in the whole process. `Smart' applications, like `smart' Specification applications, will be able to access data, information and knowledge provided by others.
The build-in focus on demand and supply allows various problems in BC's process to be tackled. Demand and supply between the Client and the Contractor or the Client and the designers, between the Contractor and the subcontractors and the suppliers. Also with regard to knowledge, either knowledge from internal departments accumulated from earlier projects, knowledge institutes and subcontractors or knowledge provided by the stored data in the project database or the Specification.
bcoWeb's use of `smart' applications and web services allows available knowledge to be used more broadly, making knowledge more sellable and therefore more valuable and more attractive to generate--which is good for innovation. When simple web services, documents and programs can access each other's data, improved cooperation and effectiveness will be the result. Data integration currently costs money, making the whole less than the sum of the parts. With `smart' applications and web services, the costs are lowered and new opportunities open up.
 |
