3 ms·
> consider whether the reliance on comprehensive digital modelling might be in any way to blame for the delays? Maybe. 3D models have been used to design and p
by neRok 5y ago
> consider whether the reliance on comprehensive digital modelling might be in any way to blame for the delays?
Maybe. 3D models have been used to design and plan projects for over 20 years now (I've been in the industry in Aus for >15 years), and so the bulk of the models are not at fault here (because if these design models were the delay, the construction would also be delayed, but the article suggests it wasn't). But when you want to go to the next level (digital twin), and start modelling every individual light-bulb, tracking it and making it function as part of a "smart system", then things will take a lot longer.
But actually, the article says;
> Despite the huge amount of construction work that has already been completed, many aspects of Crossrail do not yet have an agreed-upon final design. That’s because the complexity and uncertainty involved in building large underground structures means that detailed “fit out” designs are begun only after it’s fairly clear how the space will look.
This boggles my mind. I don't see how it couldn't all be completed at the start. The physical design should have a few flexibilities baked in, so that if the tunnel ends up a meter out of place, or the rail centerline is 200mm off target, the design should be able to absorb it with minimal re-work.
But regardless of the physical layout, they could have mocked up a model beforehand that contains all the necessary "virtual" components. They would have known what rooms/etc were required, roughly how many entities were needed per space (eg, 4 chairs, 1 table, all with data tags). Then when you have a better idea on the physical layout, you can arrange the virtual components properly.
So yes it's possible that trying to be too fancy was a major factor in the delays. I haven't worked in a professional software engineering environment, but I get the impression that at a high-level, construction engineering has similar traps and pitfalls. Just like when coding, engineers/modellers do come across problems with their initial design, and then have to face the choice of implementing significant work-arounds, or "refactor" to something different.
- p_l 5y agoA big issue with digging under London is that you never know what you'll find
- 7952 5y agoI have worked on major construction projects and a complicating factor is the sheer number of different disciplines involved. Teams work with their own systems and maintain their own state and then inexorably get out of sync. In computing this kind of thing is understood at a more fundamental level. You have locks, transactions, branches, merges, continuous integration etc. These same problems exist when designing a major project but are not understood. Information systems exist but seem to have shocking data models designed by committees. Existing software and experience is then transposed on top of this information system. But the engineers don't have expertise in data and are using software from another age that makes "drawings". Adding a live "as built" component to that is just asking for trouble.
- neRok 5y ago> But the engineers don't have expertise in data The story might be different elsewhere, but here it is draftsman that make the 3d models and all the associated data, and to do get a job in the industry only requires 1 year of vocational education. To put it bluntly, these aren't the smartest people.
- 7952 5y agoAnd you get one more place for people to get out of sync. One more excuse for why engineers don't need to understand their own fundamental tools.