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?
Thanks for your observations, lot's of exciting stuff on the way, I've flagged this post with the product managers.
...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?
Great introductory vid on Legion, which could grow into being one of the core 'analytical' tools that would help make ASD stand out and make it worth the additional charge.
Pedflow is a core aspect to any building design that has mobility as its raison d'être... so it will be pretty exciting to see how ASD will integrate Legion... and for that matter Synchro.
One problem with Legion is that (I think) is that the 'obstructions' or building elements that form part of the model are static. Maybe, Synchro could be used to define the dynamic obstructions like entrance gates and emergency vehicles that would show up in fire etc. The station operational staff would model their crowd control or evacuation plan using Synchro, and the results fed into Legion for analysis / verification.
A lot of pedflow modeling is based on fairly static assumptions, as required in standards, which may not turn out to be the worst / best case or even realistic given the site-specific circumstances.
What would be really sci-fi is if this could be done in real time. The station operations staff would be able to tap into the system, who would know how many passengers would be enroute on trains, and have good idea via CCTV (automatic input into a live Legion model via AI-based image recognition) how many passengers are in the station making their way out/in. They would then be able to 'game' some scenarios in advance to decide on the best course of action.
If the compute power is not there yet, you could still work on historical data and 'profile' the problem down to give staff informed recommendations on what to do. Pertubation or degraded service during AM peak... PM peak.... event peak... evacuation with selected points blocked or cordoned off for maintenance etc etc on your Night Tube station.
When modeling evacuation, pedflow is also influenced by other 'tenability' factors. The main one being visibility impairement / temperature due to smoke, which of course is also dependent on 'obstructions' and other 3d elements that would be provided by ASD.
It would be good to be able to tie the whole 'cause and effect' chain of events together using Synchro; with Legion for pedflow, PyroSim or SimCenter etc for the smoke modeling, acoustics and the various MEP analytical tools into single federated model.
And within it all, LumenRT could be used to visualise the sequence of events. E-on seems pretty good at doing clouds, so it should be able to import the smoke plume data from the CFD app. Lighting levels would be modeled easily given the Aecosim MEP tools, and I suppose you could superimpose the acoustic STI heat map on the model so that you could select any of the 3d people moving through the animation and get an STI reading (before/after the impulse fans kick in for example). And Legion's passenger behaviour algos could be modified to react to the temperatures generated by the CFD apps.
Since Legion simulates each passenger (dot on plan, animated 3d actor in perspective view)... it should also be possible to use the model to optimise the wayfinding / signage and CCTV positioning. This would be another unique selling point for ASD. Signage and wayfinding is a prettty big part of station design.... very difficult to get right. Especially given that so much will be 'interim' or 'temporary' in character.
One of the interesting things mentioned in the vid is the incorpoartion of station related components via Component Center.
Obviously, if the components can be imbued with some 'semantic' or IFC-type information, this would help to cut down the amount of manual guesswork and clean-up that the pedflow modeler will suffer; and make iterative modeling a reality (not just hype, as it is today). Quick and assured transfers would help make the process more bi-directional, so that the pedflow model(er) can also start to influence and inform the physical architectural model... providing 'tight design loops' as mentioned at YII.
I hope that Aecosim's Spaces would also be incorporated into the Legion mix. Dynamic modeling is still pretty expensive and time consuming. Many designs still rely on static calculation in the early stages based on LU/NR etc standards. And there will be areas of the station that will never really be dynamically modeled.
Spaces could be enhanced to include entry/exit points. Spaces can already gather and collate objects withing its footprint/volume. It should be easy to capture door object on the perimeter and automatically set up a graph/spreadsheet to capture the availabe gateway widths and their separation distances. Any ticket gate line turnstiles within the Space would also be easy to sort within the graph by interogating their spatial relationships in plan.
The Space would also be able to provide floor gradient information that would inform the pedflow calculations.
Stair Spaces should be able to interogate the Aecosim stair objects within them and extract the relavent parameters like travel distance and escape/opening widths. You would then be able to model obstructions fairly easily by flipping a door parameter to 'shut' and model the results. Omitting one of the escape routes is a standard check in many countries.
The pedflow relationship graph should also be editable as a visual 'adjacency' graph, and allow any fine tuning.
Spaces+ should also help simplify the model to allow automatic maximum travel distance calculations between designated points. This is a pretty common, tedious and repetitive calculation for both station and airport design. 'What is the maximum distance from the furthest car park stall to the XYZ' or 'What are the distances between airbridges etc' A lot of this will be subject to standards in employers requirements that will need to be addressed.