METHOD AND SYSTEM FOR INTEGRATED ANALYSIS

Abstract

A system and method of analysis, including, but not limited to: receiving raw data related to at least one project; receiving user preferences in at least one workflow, and determining metrics related to the, at least one project.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 13/029,826, filed Feb. 17, 2011, which is a continuation of U.S. patent application Ser. No. 12/461,557, filed Aug. 14, 2009, which, in turn, claims the benefit of U.S. Provisional Patent Application No. 61/174,365, filed on Apr. 30, 2009 and U.S. Provisional Patent Application No. 61/186,145, filed on Jun. 11, 2009, the contents of which are incorporated herein by reference in their entireties.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of an integrated analysis and design environment, according to an embodiment.

FIG. 2 is a flow diagram illustrating a design advisor method, according to an embodiment.

FIGS. 3A-5 are charts illustrating metrics, analysis, and logic associated with the design advisor method of FIG. 2.

FIGS. 6A and 6B illustrate building metrics associated with reports produced by the design advisor method of FIG. 2, according to an embodiment.

FIGS. 7A and 7B are charts illustrating a bioclimatic report produced by the design advisor method of FIG. 2, according to an embodiment.

FIGS. 8A-10L illustrate various components of workflows, according to an embodiment.

FIG. 11 is a flow diagram illustrating an intelligent room groups method, according to an embodiment.

FIGS. 12A-12E illustrate a model merge method, according to an embodiment.

FIG. 13 is a flow diagram illustrating a smart templates method, according to an embodiment.

FIG. 14A-14H illustrate bioclimatic logic, according to one embodiment.

FIG. 15 is a system diagram where an integrated analysis and design environment can be utilized, according to an embodiment.

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

The present disclosure relates to utilizing workflows (or processes) for the purposes of user guidance, productivity, project management, quality assurance and error reduction in computer software. In some embodiments, navigation of workflows and supporting technologies can be employed. For example, in software for the thermal simulation of buildings, the workflow for a goal can involve many complex steps. The present disclosure describes technologies that actively manage how users approach and navigate workflow(s) to a desired goal with the stated benefits. FIG. 15 is a high level system diagram, illustrating at least one client 110 and at least one server 115 communicating (e.g., remotely) with at least one integrated analysis and design environment 100 over at least one network 105. It should be noted that the at least one integrated analysis and design environment can reside, in part or in full, at the client 110, the server 115, or separate from both, or any combination thereof. FIG. 1 is a high-level block diagram of an integrated analysis and design environment 100, according to an embodiment. The integrated analysis and design environment 100 is a virtual environment that includes a wide range of functional components that can share data via a shared model 120. The integrated analysis and design environment 100 is a flexible, integrated system for building performance system assessment. It can enable comparison and evaluation of alternative design strategies, from concept to completion and beyond. The integrated analysis and design environment can evaluate and help maximize the sustainable potential of a building throughout its lifecycle. The integrated analysis and design environment 100 can also interact intelligently with external software products (e.g., computer aided design (CAD), building information modeling (BIM)-importing geometry). For example, both Autodesk REViT and Google Sketchup models can be imported and the integrated analysis and design environment 100 can process the geometry to determine rooms in the Google Skethup model.

The modules of the integrated analysis and design environment 100 can be accessed at several levels of user access suited to user ability and market deployment: virtual environment (VE) Pro 115 can provide full access. VE Gaia III can provide detailed access, VE Toolkit 110 can provide limited access; and VEWare 105 can provide minimal access (e.g., freeware). The integrated analysis and design environment 100 can also include an index comparison module 165 and additional indices 170 that can connect to other modules via the shared model 120. The index comparison module 165 can be configured to generate, different indices (e.g., a climate energy index and a building energy index) and/or to compare such indices. The additional indices module 170 can be configured to generate indices, for example, based on other aspects of climate not already present as a module, such as, but not limited to, wind and water.

The integrated analysis and design environment 100 can include: a shared model 120, a solar module 125, a daylight module 130, an energy module 135, a cost module 140, an egress module 145, a mechanical and electrical design (M&E) module 150, a computational fluid dynamics (CFD) module 155, a value module 160, a climate module 127, a materials module 126, and a builder module 121.

The integrated analysis and design environment 100 can follow a shared process using the shared model 120: geometry can be created, data can be assigned (e.g., BIM), and analysis can be carried out. For example, within the integrated analysis and design environment 100, a user may use the shared model 120 to create geometry. Apache can then be used to add data (e.g., BIM), such as constructions and activities, and Suncast can then be used to analyze solar information. The Suncast results can also be used through feed back as a precursor to Apache for thermal simulations. Data from Apache simulations can then provide the starting data for a CFD simulation (and so on). This can result in better productivity and holistic design.

The model builder module 121 can be configured to construct detailed three-dimensional (3D) models, share data between applications or modules, and/or import computer automated design (CAD) data from, for example, Sketchup and REViT, or by green building extensible markup language/drawing exchange format (gbXML/DXF).

The solar module 125 can be configured to minimize or maximize the effect of solar gains, visualize the impact of a building around it and establish the implications of right-to-sunlight, generate supporting visual, graphical, and numerical data, and/or animate the movement of the sun through a building.

The egress module 145 can be configured to develop a design that allows people to move freely throughout and avoid bottlenecks, evaluates alternative escape routes in the event of an emergency (e.g., a fire), and/or simulates and assesses different elevator or lift options.

The M&E module 150 can be configured to speed up duct and/or pipe sizing, assess alternatives and make adjustments quickly and easily, and/or free up design time by automating the design of mechanical and electrical systems.

The CFD module 155 can be configured to simulate airflow, ensure optimum ventilation in a design, produce detailed comfort predictions for different areas of a room, assess strategies such as ventilated facades, for example, and/or visualize results and communicate such results with graphics.

The daylight module 130 can be configured to test the look and performance of different lighting designs, including prediction of light levels, maximization of daylight, minimization of glare, visualize ambiance for different configurations, and test Leadership in Energy and Environmental Design (LEED) daylight rating.

The value module 160 can be configured to perform efficient and multidisciplinary value studies, including providing a common interface to all those involved in a project, evaluation of a wide range of design parameters and comparison of different options, and identification of best value solutions.

The cost module 140 can be configured to predict initial and lifecycle costs, including preparation of customized capital cost estimates and calculation of operating costs of a building throughout its lifetime.

The energy module 135 can be configured to maximize the potential of green strategies like natural ventilation, heat recovery, night cooling, heat pumps, and mixed mode systems, calculate heat loss and gains, thermal loads, and carbon emissions, simulate the impact of internal and external airflow, optimize artificial light control, model HVAC plant and control systems, assess feasibility and performance of renewables, comply with energy conservation legislation, and perform Architecture 2030 Challenge benchmarking.

The climate module 127 can be configured to review, compare and analyze weather files (historical or synthetic or predicted) anywhere globally, produce metrics, trend data, and summarize results from such an analysis. The module can also be configured to set location and weather file information for the purposes of simulation within the VE.

The materials module 126 can be configured to summarize the total materials data contained in the model, individually or by material group. The materials data may include weight, volume and other information related to material properties (e.g., data from the manufacturing, distribution and disposal of the material (e.g., embodied energy, embodied water, pollutants, byproducts or alternatives)). The materials data is used for comparing options, optimizing design decisions, and reviewing lifecycle issues.

As sustainable building design and the software that supports such design become more diverse and complex, it is helpful to actively manage how users approach and navigate issues and how they interpret the software results. The integrated analysis and design environment 100 can include the following to facilitate management: a workflow navigator module 180, a design advisor module 175, an intelligent room groups module 185, a model merge module 190, and a smart templates module 195. These modules can enhance and enable the integrated analysis and design environment 100 to provide greater productivity, reduce user error, provide smart reuse of data, allow direct and immediate navigation of complex issues, workflows and processes, and derive understanding, that is sometimes not possible from traditional analysis environments.

Building analysis software often produces results that require significant interpretation by the user. The more diverse the building design, the more complex interpreting results can become. The breadth of building design also means many skilled people may be needed to produce an integrated or holistic result. This can be difficult to achieve and often is not performed in a timely manner. The integrated analysis and design environment 100 can help in interpreting results more effective, timely, and/or in an integrated manner.

DESIGN ADVISOR. The design advisor module 175 can be configured to produce metrics for a building design (e.g., building energy use intensity kwh/m² yr, glazing area % of wall area, heating load w/m², fresh air rate L/s.m², surface area to volume ration, etc.), can use intelligent and automated analysis to identify metrics and patterns in data (e.g., peaks, averages, trends, range testing, coincidence of variables, selected metric(s) value testing, etc.), can perform logic that processes and interprets metrics into conclusions, and can include a report generator that dynamically compiles metrics and conclusions into an effective and readable narrative. The story or narrative can have context, hierarchy, and multiple reinforcement of key messages via a number of different media (e.g., text, tables, dynamic user adjustable tables, charts, diagrams, images, videos, cartoons, etc.) to ensure the message is received by a wide range of users.

FIG. 2 is a flow diagram illustrating a design advisor method, according to an embodiment. It should be noted that the various processing steps described below can be automated using the functionality provided by the workflow navigator module 180, for example. At 205 in flow chart 200, the elements of a building, including model data such as occupancy data, construction data, system data, usage data, weather data, or data from model merge technologies or from BIM models (e.g., ReviT, Sketchup), for example, can be obtained. At 210, a building model can be defined. At 215, simulation of the building model can be performed. For example, thermal simulation, daylight simulation, and/or water simulation can be performed for the building model. At 220, simulation results can be produced. It should be noted that some metrics associated with the building can be derived directly from the input data while other metrics are derived from simulated or calculated results.

At 225, an analysis of the simulation results can be performed to produce metrics associated with the building (e.g., building energy use intensity kwh/m² yr, glazing area % of wall area, heating load w/m², fresh air rate L/s.m², surface area to volume ration, etc.). The simulation results can also produce patterns (e.g., peaks, averages, trends, range testing, coincidence of variables, selected metric(s) value testing, etc.) that, when analyzed, also contain metric information. The metrics can be associated with (and grouped into) climate information, natural resources information, urban design information, building form information, building thermal information, building light information, materials information, water information, and/or sustainability information.

At 230, conclusions can be derived from the metrics. Metrics can represent an intermediate stage in determining conclusions. A logic analysis can be performed on the metrics to derive effective and simple conclusions that can be accessible and easily understood. For example, if the building is not occupied at night, the external temperature drops sufficiently below the occupied set point at night, and the building has a thermally heavy construction, then the logic that can be derived is that night time purge ventilation is a possible strategy to reduce building cooling demand. At 235, a report generator can be used to process the logic output into an ordered narrative or story that is understandable by a wide range of users. The report generator can use visual communication devices such as charts, diagrams, pictures, and/or video, written communication in the form of a plain English narrative or story, tabular information that dynamically sorts itself based on direct user input, and/or contextual information that supports what is being communicated with background and range information.

FIGS. 3A-5 are charts illustrating metrics, analysis, and logic associated with the design advisor method of FIG. 2, according to one embodiment.

FIGS. 3A-3H show examples of metrics. FIG. 3A illustrates many types of metrics: climate, urban, building form, building thermal, building light, building water, and sustainability. FIG. 3B illustrates climate metrics derived from weather data files. FIG. 3C illustrates building form metrics and building thermal metrics. FIG. 3D illustrates building thermal metrics. FIG. 3E illustrates urban metrics. FIG. 3F illustrates building light metrics. FIG. 3G illustrates building water metrics. FIG. 3H illustrates sustainability metrics. As described above, the metrics can include directly derived metrics and processed metrics, such as climate classification, passive design responses, room form, and thermal mass, for example FIGS. 3A-3H illustrate a data hierarchy: group>sub-group>metric>climate metrics weather base metrics>max annual temperature. The metrics shown in FIGS. 3A-3H are examples of determined output from 225 in FIG. 2. Note these are just examples of groups, and that many other groups can be utilized.

FIGS. 4A-5 demonstrate how 230 of FIG. 2 can be produced, according to one embodiment. FIGS. 4A-4F illustrate an example of logic being used on derived metrics to determine conclusions. (Note that, in one embodiment, the information on FIGS. 4A-4F can be displayed in one chart.) In FIGS. 4A-4F, the logic (a pattern of metrics) is illustrated in the columns of the chart, with the outcome shown at the bottom of the chart (system filter 410 and notes 405 sections). Each predetermined pattern reflects a different climate (e.g., hot and humid 4A, hot and dry 4B, hot humid/cold winter 4C, temperate 4D, cold 4E and 4F) and are examples of how the logic process operates (i.e., how the model can be matched to one of these columns). The following properties can be considered: climate 440, building type 435, loads 430, usage 425, form 420, and construction 415. The outcome at the system filter 410 can indicate an interim conclusion that can then be used in the next stage in the chain of logic. For example, in the chart on FIG. 4A, the model can be first matched to the correct climate (e.g., section 440, 1A). Then, the model can be matched to a predetermined pattern in system filter 410 (e.g., if all the conditions listed in column 1A are true, system filter 410 produces natvent YES). Colors can be used in FIGS. 4A-4F to represent different types of solutions. For example, green can represent natural vent solution, orange can represent mixed mode solutions, and red can represent air conditioning solutions. In addition, different types of patterns can be used to signify colors or different types of solutions. For example, green (e.g., natural vent solutions) can be represented by a diagonal lines pattern, orange (e.g., mixed mode solutions) can be represented by a crossbar pattern, and red (e.g., air conditioning solutions) can be represented by a vertical lines pattern. Notes 405 can allow notes to be added in.

FIG. 5 is an example of a second stage of logic being used on metrics, according to one embodiment. This example uses the result from FIGS. 4A-4F to derive an additional set of outcomes. This example demonstrates the application of chained and patterned logic and the outcomes that can be produced from a design advisor, according to one embodiment. In this example, the outcomes are the rows that cross the line, which are filtered by the outcomes from FIGS. 4A-4F, and the secondary properties 525 in FIG. 5. The rows can include natural systems 515, mixed mode systems 510 and vent/air conditioning systems 505. The outcome can be a number of results. In this in example, the outcome is potential HVAC systems suitable for this model and climate. Once the data of FIGS. 4A-4F are applied,.and the line in FIG. 5 is used as the load (i.e., how much cooling needed for every square floor area in the building—derived from the model), cooling options which would work can be derived. In this example, any of the cooling options with the line through them would work. These cooling options would show up to the user as possible options. Note that, as in FIGS. 4A-4F, the colors in FIG. 5 can represent different types of solutions. For example, green (e.g., 515) can represent natural vent solution, orange (e.g., 510) can represent mixed mode solutions, and red can represent air conditioning solutions (e.g., 505). Note also that additional information properties 530 can be factored in. In addition, the following properties/categories can be taken into account: air alone mostly handles load 535, passive cooling as vent rates too high (discomfort) 540, activing cooling as vent rates too high (discomfort), fresh air 550, headroom 555 and climate type A 560.

FIGS. 6A, 6B, 7A and 7B illustrate how 235 of FIG. 2 can be produced, according to one embodiment. FIGS. 6A and 6B illustrate building metrics associated with reports produced by the design advisor method of FIG. 2, according to an embodiment. In this example, the report produced can include building model form, dominant aspects of design and metrics that relate to building shape, windows, room form, dimensional metrics, and thermal response metrics. The report can provide message reinforcement via repeated information using different visual and textual outputs. The building metrics report can be similar to a climate report, except building data can be utilized. FIGS. 6A and 6B illustrate information textually and in a visual format. 605 illustrate the office space of interest and generic properties. 610 illustrates size of space of interest, and where glass is situated (in the example it is south and west dominated). 615 illustrates how many rooms are within 7.5 meters of the window and how many rooms are three or four sided. This can help determine if a room is able to be ventilated. Thus, FIGS. 6A and 6B demonstrates how 235 of FIG. 2 can be produced, in one embodiment.

FIGS. 7A and 7B are charts illustrating a bioclimatic report produced by the design advisor method of FIG. 2, according to an embodiment. In this example, the report produced can include the type of designs that may be considered based on weather and climate. The report is configured using themed chapters to produce a story or narrative with a natural order and hierarchy. Such configuration can allow a very high density of interpreted information to be presented in a concise manner. The climate analysis can include statistics of weather files. The bioclimatic analysis can perform a set of rules and checks, using bioclimatic advice logic, to create a set of recommendations based on the weather data.

FIGS. 14A-14H are charts illustrating bioclimatic advice logic, according to one embodiment. The bioclimatic logic can produce the bioclimatic report of FIGS. 7A and 7B. For example, in 1405, the various sections (e.g., climate, latitude, summer, winter, wind patterns, precipitation, and misc. issues) can have test logic that produces certain output. For example, if cooling degree days (CDD) is greater than heating degree days (HDD), and the climate is dominated by summer, the design must minimise cooling energy. In 1410, design directions and test logic is provided. For example, various logic for design priorities are listed in 1410. For example, for a short summer that is maybe uncomfortable, a Mahoney stress analysis method is used for the warmest 6 months. It should be noted that where the logic refers to Mahoney, those of ordinary skill in the art will see that this is a specific analysis method defined by Mr. Mahoney and generally referred to as Mahoney tables. See, for example, Koenigsberger et al, Manual of Tropical Housing and Building: Climatic Design, (India: Orient Longman 1973), which is herein incorporated by reference.

WORKFLOW NAVIGATOR. Software sometimes requires users to find their own navigation route among features. For example, in building analysis software this can cause very complex software architectures. While manuals and wizards may be available, these are generally insufficient or do not provide specific information, which can cause users of such complex and diverse software to use the software below its full capabilities and productivity. The workflow navigator 180 can be configured to integrate real world design workflow, quality assurance, user guidance, productivity, project management, error reduction and end goals in order to provide a clear workflow that can operate concurrently at the level of perspective, at the detail task at hand, and to enable parallel tasks.

The workflow navigator 180 can allow for the integration of guidance directly with actions in the software, for the integration of direct actions with specific resources, to encourage good practice modelling and analysis, and to produce auditable quality assurance.

The workflow navigator 180 can be configured to perform a workflow navigator method that can include creating a hierarchical workflow tree that can change dynamically, both in entirety or conditionally, as choices are made by the user. The workflow items can direct users, allow data input, and can trigger actions in the software, some of which maybe very complex and change later or subsequent items in the workflow. The workflow items can provide immediate and direct guidance (because they are part of the interface) and directly fink into specific help resources. Users can check off workflow items as they are completed, can add comments, and can add a date/time/user stamp. Workflow item completion can unlock later actions for use. Items in the workflow can be elemental or can appear in a single instance, such that the state of any element can be current regardless of where the user maybe in parallel workflows. Together, the workflows, the comments, and/or the checks, for example, can create a quality and/or project audit system that can be directly generated from the work at hand.

FIG. 8A is a flow diagram illustrating user selection of appropriate workflow, according to an embodiment. In 805, user preferences are accepted. For example, a user can select from a list of available workflows, such as, but not limited to, those illustrated in FIGS. 10A-10L, which list many examples of workflows. In 810, user preferences are applied. For example, one or more selected workflows, such as the one in FIG. 9A, can be loaded and displayed. The workflow(s) can be taken in part or in full from the list of workflows in FIGS. 10A-10L, or the user can create or add in a new workflow. In 815, the workflow is navigated. For example, the user can work through the work flow, step by step, taking notes, making decisions, triggering actions, entering data and checking off the action item for each item. The user can jump backwards and forwards in the workflow or change workflows at will.

FIG. 8B is a flow diagram illustrating a workflow navigation 815 for a selected workflow, according to an embodiment. In 825, a workflow is selected. For example workflow 1, workflow 2 or workflow 3 can be selected. If workflow 1 is selected, the tasks A, B, C, and D can be performed, according to 830, 832, 834 and 836 in order to produce an outcome in 838. If workflow 2 is selected, the tasks A, E, F, G, and P can be performed, according to 840, 842, 844, 846, and 848 in order to produce an outcome in 850. If workflow 3 is selected, the tasks A and T can be performed according to 860 and 862 in order to produce an outcome in 864.

Various objects and nodes can be used as part of a navigator for the workflow navigator method. Objects can be divided into dialogue objects, action objects, and macro objects for the purposes of browsing and/or grouping. Objects can be broken down to access individual actions (e.g., to create sequential baseline model as show in 970 of FIG. 9A). In an appropriate navigator creation tool, the objects and/or nodes can be dragged and dropped to define a navigator specification or can be further edited when required. The objects can evolve as navigator scripts are developed.

A navigator can be configured to provide direct and context linked guidance, proven workflow, tutoring, access to features, combined and automated functionality (e.g., macros configured to automate repetitive tasks), and/or conditional functionality. A navigator can be configured to provide flexibility, de-mystify the modelling process (e.g., illustrate order, access, and user confidence), to produce an outcome or solution, output measurable solutions, indicate productivity gains, reduce error, provide quality assurance (e.g., record), and/or add additional value to that provided by the VE Toolkit 110, for example.

The navigator technology can also be configured to support: navigator component content transfer (e.g., transfer to other navigators such that the same components in different navigators show the same status), model variant management, user libraries (e.g., constants, profiles, openings, templates, gains, air exchanges, and systems), starter models, and/or embodied energy data (e.g., construction database).

FIG. 9A is a screenshot of a working navigator operating via a graphical interface 900, according to one embodiment. 910 is a drop down list of navigators for selection. 920 is a notes icon, where a user can add a comment. 930 is a date/time stamp. 940 is a user stamp. 950 are toggle icons, which can expand and/or collapse a workflow tree and show and/or hide date/time user stamps. 960 is a help hyperlink icon. 970 is a tree first level group entry. 975 is a tree second level group entry. 980 illustrates how completed items can be coloured (e.g., green). The workflow tree in this example uses three depths, however more or less depths may be used.

FIG. 9C illustrates an example of how to read workflow diagrams, according to one embodiment. Four examples types of navigators are presented: base navigators, module specific navigators, special navigators, and customized navigators. Base navigators may be multi-purpose navigation tools for the VE which are part of the base Gaia (e.g., model creation navigator). These navigators may be provided free with the Gaia product. Module specific navigators may be module specific navigators (e.g., navigators for ApacheSim or Radiance). These navigators may be tied to a module license and may be thus paid for as part of the module cost. Special navigators may have added functionality that are purchased (e.g., PRM for Sustainable Cities). This category may include tutorials that are tied to paid for training. These navigators may have a license and an associated cost. Customized navigators or manufacturers navigators may be purchased or free. They may be distributed by IES or third parties.

FIG. 9B is a chart illustrating examples of workflow navigators (by title) grouped by type & overall logical order, according to an embodiment. Workflows can be grouped or organized according to workflow type (e.g., complete, build, data, built form analysis, simple analysis, detail analysis, result interrogation, bespoke (customized), tutorials) so that a navigator selector 950 associated with the navigator specified in FIG. 9A can offer a hierarchy (e.g., solutions) at a variety of scales that can be readily understood and easily navigated by a wide range user. The navigator selector 950 can include full navigators, part navigators, and complete navigators, build navigators, data navigators, build form navigators, simple analysis navigators, detail analysis navigators, result interrogation navigators, bespoke (customized) navigators, tutorial navigators, and additional navigators. The full navigators can include application selectors (e.g., product functional modules, product bundles), complete workflows that provide full design processes based around large scale workflow needs (e.g., concept design, detailed design). Part workflows can be specific tasks that are carried out as part of larger workflow made of sequential use of part workflows (e.g. build, data, analysis, etc.). Bespoke and tutorial tasks can be recognizable tasks. These can be workflows that are smaller than full workflows but include full design processes that are self-contained (e.g., how to model a zero carbon house, how to create a model, etc.). Corporate workflows that can be commissioned by clients are full workflows for standardised corporate quality assurance (QA) based modelling. The full navigators can include part workflows and any customized elements tied together into a whole. The number of full navigators can be controlled and/or limited.

Part workflows can include specific tasks which, when combined sequentially by the a user, provide a rich and flexible route through the majority of modelling activities to goals/outcomes (e.g., geometry creation, making and assigning constructions, simulation, making and using profiles, results analysis, etc.). For example, the manner in which the workflows are named and grouped in FIG. 9A forms a macro order. All workflows can be made of elemental components from a code library, for example. Tutorials can include partial workflows that echo, support, and/or add persistence to training courses.

FIGS. 9D-9J illustrate schemas for multiple workflow navigator examples, according to one embodiment. For example, the specifications in FIGS. 9D-9J detail to developers what a specific workflow does, how it goes together, and what actions are required.

FIGS. 10A-10L illustrate another example of a working navigator, according to one embodiment. FIG. 10A illustrates a user interface, according to one embodiment. FIG. 10B illustrates the user interface with the drop down menu of navigator workflow options 1005, according to one embodiment. FIG. 10C illustrates a climate navigator 1015 that has been chosen, according to one embodiment. FIG. 10D illustrates the climate navigator 1015 with user notes 1020. FIG. 10E illustrates the climate navigator with the climate metrics 1025 chosen and a climate report 1099 generated, according to one embodiment. FIG. 10F illustrates the climate navigator with the time/date/user stamps 1030 utilized, according to one embodiment. FIG. 10G illustrates a model data navigator 1035 and model data 1098, according to one embodiment. FIG. 10H illustrates the model geometry navigator 1035 with the location and weather item 1040 (completed in the previous climate navigator 1015) already completed. This illustrates how navigator components can be kept up to date in all workflows as workflows are changed. FIG. 10I illustrates the model geometry navigator 1035 after progressing through the workflow sections checked off (1045) (e.g., can be in a color such as green) so the user can minimise the groups to see progress and required actions. FIG. 10J illustrates a sustainability navigator 1050 and sustainability report 1097, according to one embodiment, where a generated report can be produced including a dynamic “video” of the daylight results and a dynamic table of the results. FIG. 10K illustrates a water navigator 1055 and water report 1096, where a generated report of water simulation is produced including charts and result details, according to one embodiment. FIG. 10L illustrates a LEED navigator 1060 and LEED analysis report 1095, where a generated report can he produced including a dynamic “video” of the comfort results, a dynamic table of the results, and the credits likely to be achieved with the design, according to one embodiment.

INTELLIGENT ROOM GROUPS. Building analysis software can utilize a great deal of data that defines properties (e.g., thermal, light, water), the use of spaces (e.g., occupancy, activities) and how the building is actually used (e.g., occupation, openings and HVAC systems). Researching, generating, and assigning this data can constitute a very significant portion of modelling time. Intelligently grouping and/or ordering spaces in a building design, such as choosing proper spaces and making group wide data assignments, can be useful in reducing modelling time.

Similarly, viewing the results that are produced by simulations can take considerable time as interpretation requires the review of many combinations of spaces at a number of scales and against numerous output conditions and tests. By providing combinations of spaces or conditions that are dynamic and can be created quickly and accurately during model definition, during data assignment or following simulation, significant productivity gains can be achieved.

The intelligent room groups module 185 can be configured to support an intelligent room groups method in which spaces in a model can be automatically ordered and/or grouped. A user can define or pre-select a strategy to automatically process the model data and geometry and automatically place spaces in an appropriate grouping. The groups can include, for example, building floors, building departments, same space function, same properties (e.g., space size, thermal weight, glazing area, hvac system) and orientation.

There can be multiple grouped room strategies in any one model. The user defined or pre-selected strategy can be simple, such as a strategy based on space size, or can include a fairly complex pattern, such as a strategy based on space and name string combinations or on space property data, such as an hvac system.

For the analysis of the results, the intelligent room groups module 185 can use a user defined or pre-selected strategy to automatically process the model results and automatically place spaces in an appropriate room group so that they can be seen together or identified quickly in visual output. The groups can include spaces that exceed a threshold(s) (e.g., temperature, CO₂, comfort), or that meet a certain requirement (e.g., energy compliance), or that have a complex combination of several conditional tests (e.g., room temperature exceeds 25 degrees Celsius for more than 5% occupied hours and exceeds 28 degrees Celsius for more than 1% occupied hours), or that involve results of post processing (e.g., pattern analysis-diurnal temperature swing trend, comfort analysis).

The defined or pre-selected strategy can also be applied specifically to existing groups to provide compound outcomes.

FIG. 11 is a flow diagram illustrating an intelligent room groups method, according to an embodiment. At 1105 of flow chart 1100, a space is defined based on, for example, occupancy, constructions, activity, HVAC systems, space geometry, materials usage, and/or water usage, for example. At 1110, an ungrouped building model can be provided based on the information from 1105. The ungrouped building model is such that there is no hierarchy as to the rooms or buildings (at a large scale). In urban models (multiple buildings) or large buildings, with many different types and configurations of rooms, a lack of room hierarchy in the analysis can be an serious issue. At 1115, one or more groupings are defined for the model. Either a manual or an automated grouping process can typically group rooms into a number of basic and concurrent groupings such as floor, room type, size, and HVAC system, for example.

At 1120, a group model is produced in which one or more hierarchies are defined with respect to the buildings and rooms. Establishing a room hierarchy allows users to quickly identify physical patterns or make selections by groups for various purposes, including data assignment, for example. At 1125, a simulation of the model can be performed. The simulation can produce unsorted data that can be analyzed in various ways.

At 1130, an analysis stage grouping can be performed. The manual and/or automated grouping process can be used to group rooms after the simulation into one or more advanced concurrent groupings based on, for example, overheating, comfort, compliance, hours unmet, daylight level, and/or checks. At 1135, an analysis and inspection can be performed. By having the rooms grouped, a user can perform assessments, spot trends, and draw conclusions effectively and accurately. The design advisor (see above) can also utilize room grouping to produce metrics. The user can also perform further groupings to refine the analysis. At 1140, a report generator can be used to produce automated reports based on results from the analysis and inspection at 1135.

MODEL MERGE. FIG. 12A is a flow diagram illustrating a model merge method, according to an embodiment. Model merge can be used when a previous model can be used (with some tweaks if necessary) and merged it into current design so important data from a working model can be merge into a new design (e.g., for an architect). Prototypes can be templates (not requiring any geometry or building data) about certain characteristics (e.g., what a classroom is and how it is used). A user can use prototypes to save many kinds of data and bring it into a new model (e.g., for a school). To start a project, a user could choose between a model merge or a prototype so that previous data can be utilized to streamline the project. A user could also use a prototype in part to save favorite constructions. So if a particular room or window design is helpful, a user can pull it in.

FIG. 12B illustrates a process of model merge flow, according to one embodiment. In 1221, new space definitions (e.g., new model geometry) can be received. In 1222, a user can select merge parameters (e.g., how to match buildings, rooms using name, size, etc). In 1223, a user can select existing models. In 1224, existing space definitions (e.g., templates, systems, constructions, profiles, materials, water, grouping, etc.) can be received. In 1225, analysis can match new buildings and/or spaces to existing buildings and/or spaces. In 1226, a user can confirm matches and data to merge. In 1227, a carry out model merge analysis can be done to apply existing data to a new model on a room by room basis. In 1228, the new model is now populated with existing data.

FIG. 12C illustrates a process of prototype (query) flow, according to one embodiment. In 1241, a user can selects a prototype model. In 1242, the user can query grouping in the prototype model (e.g., what groups/names used). In 1243, the user can ensure buildings and/or spaces in the new model are named in accordance with the prototype model.

FIG. 12D illustrates a process of prototypes (load) flow, according to one embodiment. In 1261, the user can receive new space definitions (e.g., new model geometry or part of). In 1262, the user can select a prototype model. In 1263, the user can select prototype parameters (e.g., what data to load, whether to just load or load and apply). In 1264, the user can receive prototype space definitions (e.g., templates, systems, constructions, profiles, materials, water, grouping, etc.). In 1265, analysis can group new buildings and/or spaces to prototype format. In 1266, the model prototype analysis can be carried out to apply prototype data to the new model on a room grouping basis. In 1267, the new model is now populated with prototype data.

FIG. 12E illustrates a process of prototype (export) flow. In 1281, current space definitions (e.g., geometry and space definition data or part of) can be received. In. 1282, the user can select prototype parameters (e.g., what data to save such as full prototype—templates, systems, constructions, profiles, materials, water, grouping etc or just constructions). In 1283, the user chooses a prototype name. In 1284, the model prototype analysis is carried out and required data is filtered from current model (e.g., as selected above but excluding geometry). In 1285, the prototype model can be saved.

In one embodiment, model data can be organized into an object-based hierarchy based on multiple levels. For example, a building level can be used in which users can apply a smart template to a whole building model or to many buildings in an urban model. For each building type (e.g., office, school, house, etc.), the smart template can define the typical space types involved. Smart templates can be grouped and stored in prototype files. Prototype files can save all or part of the definition data in a model (e.g., templates, systems, constructions, profiles, materials, water, grouping, etc.).

In another example, a space level can be used in which users can also apply a smart template to a space or spaces within a model. Each space type can define properties of that space type, such as occupancy profiles, lighting profiles, and heating and cooling set points, for example. This information can be referenced from elemental databases.

The assignment of data can be automated such that in an urban model a relevant building template can be assigned to a building. Within each building type, an appropriate space template (e.g., office, corridor, we, etc.) can be assigned to each space.

Assignments and revisions that occur during the model's lifecycle can be cascaded through the hierarchy and can be automated using the functions supported by the model merge module 190 (e.g., a new model geometry is supplied and the user wishes to transfer the data from a previous model to the new geometry). Moreover, model data assignment automation can be based on simple sensible geometry naming or space parameters such as area or volume. Such an approach can allow the use of software from a very wide range of users and the process can be carried out by less costly staff. The use of smart templates can prove particularly valuable at early stages when is important to produce variation analysis and fundamental decision making both quickly and accurately. The smart templates module 195 can be configured to support the use of smart templates.

SMART TEMPLATES. FIG. 13 is a flow diagram illustrating a smart templates method, according to an embodiment. Smart templates can be a data hierarchy that permits application at many scales and facilitates automation.

In one embodiment, multiplexing can be applied in order to view and edit the smart template data (or any other hierarchical data). Thus, for example, if there is an urban model with many buildings (e.g., 10 offices, 300 houses), the user can apply template data (e.g., temperature, occupancy) using smart templates at the macro level using identifiers such as house and office to apply a specific dataset to each building type. In addition, each of the offices or houses can be represented by a stack of cards, and each card can contain a copy of the applied template data for each house. Multiplexing allows the user to globally edit any single data element en mass through the stack of cards (e.g., changing the temperature globally for all houses and/or for all offices). This multiplexing can be applied to buildings or any other repetitive data hierarchy (e.g., office, school buildings).

Referring to FIG. 13, at 1305 of flow chart 1300, a building type (e.g., house, school, office) can be determined for a building design and an associated building template comprising of a set of space templates can be assigned to the building based on the building type. At 1310, a space type (e.g., office, corridor, wc, etc.) can be determined in the building design and an associated space template (from the set of templates within the building template) can be assigned based on the space type. At 1315, space properties (e.g., occupancy and activity, HVAC systems, lighting, constructions, water usage, and opening) referenced in the space template can be assigned for each space template. At 1320, elemental components (e.g., constructions, profiles, activities, gains. LZCT (low or zero carbon technologies), profile set points, reflectances, materials, appliances, opening definitions) can be referenced from the space properties and an associated space template can be populated from such elemental components.

For example, a user may create an activity, such as PC equipment heat gain 10 w/m^2, that is referenced from a smart template called Main office, which in turn is part of a group of smart templates that make up a building template called Office 2006 standards, climate group 3. The activity may reference an elemental component, such as a profile that sets out at what times the activity occurs (e.g., when it is ON, hourly, daily, weekly, etc., throughout a year)

The workflow navigator, intelligent room groups, model merge, smart templates and design advisor technologies can work together providing automation, typically driven by the workflow navigator to deliver the stated goals (guidance, productivity, QA etc), example:

Commencing with new model geometry, the user may use a workflow navigator to guide and automate the process of populating a model with data. This can involve applying a prototype to the geometry. The prototype can utilize intelligent room groups to group spaces and assign data using smart templates. The workflow navigator can then guide and automate the process of simulation, analysis and reporting using the design advisor. The user may choose to utilize a full navigator (i.e., start to goal, concept design) or many part navigators (e.g., chosen sequentially from build, data, analysis, and interrogation categories) to meet the user's specific needs and goals. At all stages the design advisor can be called to automate the filtering, summarizing and reporting of information and results.

While various embodiments have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments. Thus, the present embodiments should not be limited by any of the above-described embodiments.

In addition, it should be understood that any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed methodology and system are each sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the steps listed in any flowchart may be re-ordered or only optionally used in some embodiments.

Further, the purpose of the Abstract of the Disclosure is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract of the Disclosure is not intended to be limiting as to the scope in any way.

Finally, it is the applicant's intent that only claims that include the express language “means for” or “step for” be interpreted under 35 U.S.C. 112, paragraph 6. Claims that do not expressly include the phrase “means for” or “step for” are not to be interpreted under 35 U.S.C. 112, paragraph 6.

Claims

1. A method of analysis, including, but not limited to:

receiving raw data related to at least one project;

receiving user preferences, in at least one workflow; and

determining metrics related to the at least one project.