Auckland w78 conference (day 2) (updated)¶

Second day of presentations. (First day here )

Updated: it now includes the full day (I added the rest on friday 2 may). Andreas Dieckman: information management in an architecture department

Healer heal thyself. How to manage information in an architecture department at the university. Basically: how to build an intranet for the department. Partly an effort at building an on-line community. The first users were very positive, as there were enough things that could be done handily over the internet.

One of the questions at the end of the presentations was "is the use mandatory or is it a service that is provided?". The answer was "service". The only force that's applied is the part of the system you use for handing in your assingments. If you're too late you need (digital) permission from your teacher to be able to hand it in.

Udo Meissner: Network-based fire protection planning

The presentation was about fire resistance calculation using agents and ontologies, which seemed to work quite well. They used IFC as their building model, which also worked satisfactory.

It was really a trend at this conference to hear many mentions of "IFC". People just using it and finding it well usable. Especially striking is that at this conference and at a recent ECPPM conference there were civil engineers that started to use IFCs for their civil engineering stuff because there's nothing comparable in their world. They find IFC reasonable easy to adapt and extend. In my opinion this bodes well for IFC.

Observed was a technology evolution: algorithms (data processing) -> data (data exchange) -> objects (algorithms+data, product models) -> distributed objects (network based co-operation) -> agents (mobile objects, pro-active co-operation).

Nash Dawood: genetic algorithms for multi-constraint scheduling

Current building practice suffers from non-ideal planning for the actual construction phase. Especially a lack of integration between the actual building and the up-stream supply management.

A constraint is a restriction or limit on actual operation:

• Contract (time, cost, quality)
• Physical (dependency, site layout, etc.)
• Resource (availability of)
• Information (availability of)

Multi-constraint scheduling therefore is a trade-off of the above regarding both time and cost.

As there are so many possible solutions, all this info was put into a database for a prototype application. A so-called genetic algorithm was used to generate an optimal solution. A genetic algorithm tries some random combinations, takes the most promising ones, tries to mix them a bit, tries some more small random mutations, etcetera, ending up in an evolutionary way with a reasonably optimal solution.

Anders Ekholm: design as problem handling

On-line pdf version

Very nice paper, taking an theoretical, scientific view on the design process. His research is still work-in-progress, but I already appreciate this snapshot!

Originally the generic idea for a designer to do was that a designer should slowly enhance his design by adding more and more properties. This is only one of the ideas around. That's why Anders started from scratch by looking at the theories in place behind the scenes. Design can be seen as idea and knowledge development.

Design requires:

• substantive knowledge (knowledge about the subject matter)
• methodological knowledge (how to go about doing things)

He aims at a technological approach at design instead of the "traditional" art approach. Traditional, the scientific approach includes the following:

• Ontology (our understanding/view on the objects and properties of this field of science)
• Epistomology (knowledge)
  • Sensory/motorical knowledge (riding a bicycle)
  • Perceptual knowledge (seeing)
  • Conceptual knowledge (rules of chess, composition of a building)
• Semantics
• Ethics

A problem is a conceptual object with three parts:

• Presuppositions
• A generator (hints at solutions)
• The/a solution

There are three axis on which to look at problems:

• synthesis vs. analysis (Does the problem need to be analysed or can you plug together existing solutions by synthesising)
• routine vs. research (Is it a routine problem or is research needed?)
• cognitive vs. practical

What I've written above is a list of bits and pieces, read his paper for the full picture.

rest of the day added 2003-05-02 below

----------------------------------------------------------------------

Rodney Steward: IT impediments for SMEs

SMEs (small and medium enterprises) aren't as proficient in IT as the bigger ones. The Boss has to know everything himself, including IT (and financing; and management; and personell management; and...). SMEs have a lot of advantages, but are not so good at marketing, financial, innovation, management. Research mostly aims at the big fish, not the SMEs.

There are a number of impediments:

Strategic planning

You've got to deal with owner-managers. The owner is the boss and overall manager. Every individual manager is different and has his own capabilities. No approach will fit all individual bosses with individual skill sets.

Financial and generic management

The biggest problem is that the boss hasn't got much time for this. Mostly less than 5 hours a week. I mean, there's real work to do...

Marketing and "human resource management"

You're lucky if the owner knows how to deal with this. There is also very limited employee training. And if an employee learns a lot, there is no possibility of gradual improvement up the corporate ladder: there are only a few functions available in the small company and you're either a common worker or the one and only company specialist, so no gradual job improvement but big leaps. Lastly, marketing: it's mostly ad-hoc advertising. We need more work now, so we'll advertise now.

Operational

There is lack of money. Most SMEs aren't cash cows. The boss mostly fails to manage markets, personell, fincances, prices in an organised and well-researched manner. Also there isn't much acknowledgement of technical changes.

IT implementation

There is lack of system knowledge and lack of training with IT implementation. The boss probably calls in his smart nephew to install the modem and the internetconnection. He is unsure about the benefits IT brings.

The supply chain is fragmented (limited interoperability between the various applications). There is also a big resistance to change with the owner typically being from the pre-IT era. Lastly there is a lack of resources, both monitary and regarding skilled personell.

The future work of his research will be to figure out how to deal with this.

Reinout: Perhaps the difficulty of getting applications accepted and installed by the SMEs can serve as a positive indicator for webapps. Applications that are directly usable from an internet browser. The only thing needed at that moment is a smart nephew to install the modem!

Choudhury - time/cost relationships for residential construction in Texas

They gathered data on 55 Texan residential house building jobs: the time it took to complete and the total costs. These were offset against eachother in a graph and they turned out to be dependent on eachother.

The generic formula used was that of Bromilow: Time = factor1 x Cost^factor2. This formula has been verified multiple times in different countries and every time it turned out to be a pretty reasonable approximation. Figuring out factor1 and factor2 from the 55 avaible building projects led to Time = 18.96 x Cost^0.39, with Time in days and Cost in 1000US$.

The formula isn't the whole story, but it's a good 75% approximation. In principle every contractor should be able to take his own personal data and use it to calculate his personal formula and use it for future time/cost estimations.

Volker Berkhahn - Recognising objects in scanned drawings

Very nice presentation about recognising objects in scanned drawings. Which lines are the walls, which are just static, which are hashing, etc. The info was mostly in pictures, so I'll refer to his paper

Michael Spearpoint - ifc fire

He used the ifc model for his fire protection work. The objects in IFC are described at a relatively high level, but IFC allows you to add your own property sets. Which he did for his fire protection needs. It seemed to work quite well.

Reinout: One of the presentations that used IFC and turned out to be quite happy with it. IFC seems to be pretty much accepted as the standard building model. I haven't seen any alternatives at this conference and nobody complains loudly about IFC.

Nabuyoshi Yabuki - ifc for concrete bridges

IFC is intended for buildings. But, just as at last years ECPPM conference, a civil engineer with something completely unrelated to buildings turns up and uses IFC. At ECPPM it was someone who used it for roads, this one used IFC for prestressed or reinforced bridges. There apparently isn't a thing in the civil engineering world that matches IFC, though it isn't intended for use by the non-building part of civil engineering!

IFC seems pretty adaptable to other usages.