Sort of announced at this years YII 2017. See 'Digital Workflows for the Digital City', about 23 mins in.
I wonder how much is different or new, compared to vanilla Aecosim.
How much integration is there with OpenRail ConceptStation, the new OpenRail Designer, OpenRail Components Center, Station and Platform Design and Analysis and Construction Sequencing etc?
Potentially very exciting news for Aecosim users.
1. Aecosim uses the Data Group System, but I think OR CS, OR D, OR CC etc will probably be on Items. Will Aecosim SD be used as the test bed for a move to Items? Ditto for F&P to Element Templates?
2. Parametric modeling: I suspect that the parametric modeling tools in OR ConceptStation are based on OpenBridge Modeler, while OR Designer is probably based on OpenRoads Civil Cells' constraints/rules-based modeling and Roadway Designer's parametric sections. I wonder if the parametric tools can be adapted to support more non-bridge or roadway design elements. Civil Cell's view-dependent display handlers being one possible tech transfer opportunity. Parametric Content Modeler to be based on OBM? I can see the rules/constraints-based approach used by CivilCells and OpenRoads being used to design tunnels without too much additional work. In conjunction with GC?
There might even be an opportunity to adapt some of OpenRoad's terrain modeling tools for use by landscape architects... that will be part of any station / corridor design team. Context Capture, Lumen RT / Vue are already waiting in the wings for those essential landscaping renders and animations for stakeholder approvals and public examinations.
3. Signaling and signage / wayfinding design. This is a big deal for station design. It would be good to see if Aecosim SD can provide some tools here. Signaling, OHLE and other railway systems elements will probably be done in OR Designer / Power Rail, using a library of Functional Components stored in OR CC. Station signage and info screen design will usually be done by the architect/wayfinding consultant; but I can see this also being modeled in OR Designer. The OR Designer user would just activate or exchange to the architectural model and move or mod the element, verify the problam is solved and return to his model.
I suspect that the linear track view-based animation tools developed for OR Designer would be easily transfered to Aecosim. Actually, it would also be good to allow Aecosim users to borrow Descartes' advanced sections and synchronised view tools... without having to load Descartes fully as a Companion. A lot of the design will be based around verifiying sightlines, CCTV camera coverage being one example. Descartes' 3d photo browsing and retrieval system would be pretty helpful to have.
4. Pedestrian flow: This is the key driver for station design. Maybe Bentley should talk to Legion, and create an ISM or bridge app between Aecosim and Legion. Probably a great opportunity for cloud-based processing. ProjectWise Legion Services? Legion models take a lot of time to set up and run. It would be good to be able to make this much less painful. Ped modeling is currently very / too expensive. Aecosim Pedflow Simulator? This kind/level of modeling is not normally needed for most building types, typically only for transport, sports and other assembly-type buildings. OTOH, means of escape/ life safety design being a lot easier and prescriptive, can be provided as a byproduct. Vectorworks, a much more modest app, and Simtread seems to have managed it?
5. Common Design Elements for stations: Vertical Circulation Elements (escalators, stairs, lifts), AutomaticTicket Gatelines (ATG) and screens/balustrades, gates and doors, Cable Management Systems (CMS), signage etc could used as spur to update the existing tools in Aecosim. Both ArchiCAD and Revit have released major improvements to their stair/railing tools, for example. Time for a shot in the arm for these tools in Aecosim. Car parking design via SITEOPS?
6.??
Hi Dominic,
Thanks for your observations, lot's of exciting stuff on the way, I've flagged this post with the product managers.
Marc
...bump. Apparently, to be released imminently.
“We’re going to imminently release a new application called Station Designer based on AECOSim to be used for detailed station and platform design.”
Hopefully, Bentley will take this oppurtunity to fine tune its approach to Element Handlers or whatever it uses to manage (hopefully, not just block) different apps working on the same info. There are already conflicts when OpenRail users try to manipulate elements that have been 'touched' by Aecosim... and presumably vice-versa.
One of Bentley's key selling points is its large range of apps that can offer a common data/modeling/analysis etc environment. Having elements 'zombiefied' by other apps in the Bentley family is embarassing.
Watch this space....
ASD: it looks like Promis.e and BRCM will replace BBES, and OpenRail is so close to OpenRoads, SUDA/SUE will easily replace the PH side of BBME on the alignment / permanent way. It would also make sense for OpenBridge Modeler to be used for any elevated track structural design.. replacing BBSS?
ABD is aimed at miscellaneous or left-over elements like acoustic walls, lighting, railing and stairs, concrete 'profiles', bollards, gantries etc. But how would this be done in practical terms outside of the station/shaft or 'building-oriented' sites where the user will probably be using something like OBM or OR as the primary modeling app? It would probably be better to include some 'railing and stairs' or 'concrete profile' tools in OBM instead of forcing the user or another user to use ABD. You will need to parametrically constrain the railings etc to the alignment anyway. OBM already has some re-booted Functional Component modeling tools. ABD's PCS is on its way out. It would be good to update BBSS' analytical modeling tools using OBM tech?
OpenRail\Roads has some impressive corridor modeling tools that carve into surveyed terrain models based on parametric cross section templates. When designing within this altered topography... to model 'concrete profiles' parapets, access portals etc it would be good to have some of this functionality in ABD to allow users to locally 'boolean' or 'perforate' the modified terrain model created by the corridor modeling app. The OR terrain model would be Ref attached and perforated or otherwise modified by an element in the active ABD model, on loading. When the OR modeler Ref attaches the ABD file, it does the same.
OLE elements would probably be modeled in Promis.e to keep the electrical calculation model intact. But, the masts and gantries will need to follow the track alignment. You will not want to mod one discipline and wait for another to follow on then reporting back the problems.. in a stop-go clash detection workflow type fiasco. Ideally, both elements would need to be 'active' in the same session... ABD-style.
It would be good to consolidate the separate toolsets like ABD currently allows a 'master modeler' to use electrical, mech, structural and architectural tools in the same session. Activating and exchanging between models should be seamless. Better yet, if Mstn could implement multiple active Refs :-) Alternatively, something that would allow an ISM-type check-in/out workflow would be good. i.Model 2.0 tech?
Data reporting: ABD U3 can now report on Items as well as DGS info in the model. It would be good to extend this to the other 'companion' apps like Promis.e/BRCM, SUE/SUDA, OpenRoads/Rail, OBM etc.. so that all companion models can be read each other's info without having to wait on i.Model conversions.
Drawing production: is pretty key. ABD's BV functionality covers a lot more ground that the other verticals. BV's have unification, view-dependent cells, Drawing Rules for single/double-line re-symbolisation, centre-lines, auto-annotation etc based on ABD's F+P and DGS, It would be good to enable ABD's BV tool to read Element Template and other feature info coming in with the OpenRail/Road models. This should then allow ASD (or Promis.e ABD mode, for example) to be the documentation workhorse.
I wonder if Aecosim Energy Simulator (AES) should also be 'customised' for station design... Aecosim Station Simulator (***)? :-)
Crossrail has set up an interesting website to encourage knowledge transfer. I suppose it will be useful for Crossrail 2, if there is any money left in the kitty after accounting for HS2.
Underground stations have quite specific HVAC systems... tunnel venting / platform smoke clearance, draft relief, under/over-platform extract, intervention route pressurisation, equipment room cooling, retail smoke extract etc in addition to the more normal accommodation-related systems that you would find in say above ground office buildings.
One particular area that could do with some AES / Hevacomp support is the intervention route pressurisation system, which will normally include the stair and lift cores; and needs to be designed to BS EN 12101-6 in the UK.
Due to the nature of the problem, there is a prickly link between the architectural design (layout of the shaft, connecting corridors and number and size of doors) and the HVAC system design (location and side of grilles, ducts and risers, fans etc) that is prone to problems. The shafts and corridors tend to be tightly hemmed in and the larger the volume the harder the pressurisation system will need to work resulting in bigger more problematic installations.
AES, being tightly linked to ABD should be able to automatically extract volumetric infomation from the architect's model. Each wall and door will have a leakage rate (and area) and this should be able to feed the engineers calcs (Excel?). Maybe the existing Hevacomp/Netsys engine can be used to model the shaft and corridor volumes, as well as any risers, as big semi-leaky 'ducts' (complete with the appropriate friction properties) and the doors as 'diffusers'?
A working digital model would be indispensible to developing balanced solutions, and avoiding the inefficient stop-go, trial and error, scatter gun process that we typically endure as whatever is proposed will need to be pushed through the engineers calcs manually before we know the results days if not weeks later.
Combine that with the fact that the pressurisation system will share the same space with many other MEP systems (and restrictions like door opening forces, acoustics and maintenance access) and a log jam is pretty much assured. There are only so many interns or off-shore bods you can throw at the problem, so some kind of digitisation seems to be the only way out.
Bentley internal hackathon?