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.
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).
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:
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.
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.
He aims at a technological approach at design instead of the "traditional" art approach. Traditional, the scientific approach includes the following:
A problem is a conceptual object with three parts:
There are three axis on which to look at problems:
plug togetherexisting solutions by synthesising)
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
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:
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!
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
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.
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
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.
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.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):