Scenario Services is a cloud based service that allows engineers to run engineering design simulations on the cloud. There are three types of use cases, representing a specific Solution Type in Scenario Services:

• Optioneering Solutions involve designing multiple options (or Scenarios) of the same engineering model (such as a designing a specific bridge) and manually comparing performance of these scenarios to attain the best design. Scenario Services offers tools for comparing the performance of multiple scenarios.
• QA Solutions are used to compare results produced by two versions of a software. The same set of models are run on both versions and differences in design results are highlighted when the difference exceed a pre-set threshold.
• Optimization Solutions (not offered in first version of Scenario Services) involve automatic parametric generation of different scenarios by varying a set of “decision variables” to attain one or more “objectives”.

Definitions and concepts

• CONNECTed Project is a project created by an Organization administrator or Project administrator using Bentley CONNECT portal or desktop interface. Note that Scenario Services does not offer ability to create or manage CONNECTed projects. However, a Scenario Services Solution must be associated with a CONNECTed project. A CONNECTed project is not limited to Scenario Services, but can contain other services such as PW Transmittal service, Project Sharing service, Content Services and so on.
• Solution refers to a specific problem the user is trying to solve, such as designing a hospital building, or designing a stadium with curved roof. There may be three types of Solutions: Optioneering, QA, Optimization.
• Scenario represents a specific configuration or option of an engineering model, which will be compared with other configurations. For example, a plant building model with less number of bays but more bay width can represent one scenario; and another model with more bays but less bay width can represent another scenario. A scenario is “run” using a specified type of Cluster on the cloud. We shall use the term “job” and “scenario” interchangeably in this document. 
• Cluster refers to a group of virtual machines on the cloud together performing a specific set of tasks – such that the whole cluster behaves as a single machine, providing increased redundancy and reliability. In Scenario Services, machines in a cluster have the same hardware and OS configuration. Scenario Services mainly uses two types of clusters: Default Cluster, Dedicated Clusters.
• Solution Template, Discipline, Application and Version: Solution Templates determine the exact computational workflow to be used to run a Design Simulation job. In other words, Templates tell Scenario Services which specific executables need to be run and in what sequence. Template also determines the type and number of Inputs needed to run these executables and outputs that are produced by these executables. Note that output of an executable can be taken as Input for the next executable.
• Storing Results: Scenario Services must “prepare” data so these are readily (and persistently) available for comparison, visualization or downloading. SPS runs engineering analysis and design tasks on the cloud using Virtual Machines (or Nodes). These Nodes are transient in nature, i.e. these are taken down after a specific job is done. Therefore, results produced by the application must be moved to a permanent storage from where user can access it later.
• Currently Scenario Services uses two strategies to store results. The results, which need to be compared or visualized, are stored in Azure tables, formatted in a way that is optimized for quick retrieval and display. The raw output files produced by the application are stored as-is on Azure Blob allowing the users to download these files later on demand.
• Users must specify which comparison results and which output files will be needed in future. All other data are lost once the Scenario run is completed.
• Performance Indicators: Performance Indicators are used to evaluate the overall performance of an engineering model. For example, in a tall building, the Story deflection will be one Indicator. The engineer will try to minimize the story deflection. Utilization Index, which denotes how effectively material is used in a model, may be another Indicator. The engineer will try to maximize the Utilization Index. User needs to evaluate a group of such Indicators needs to arrive at the most optimal design.
  Note that Performance Indicators are retrieved from the results produced by the application and stored in tables for easy retrieval. Sometimes a bit of data mining is needed to produce an indicator. For example, in a structural model, to get the number and length of all W12x26 beams, individual beam number and lengths need to be added up. This type of data mining or post-processing is done by the “wrapper” application for the specific discipline and forms an integral part of a Scenario run. Scenario Services does not perform any type of data mining at this point.
• Detailed Input/Output Data: Detailed Data harvested from application outputs, typically used in QA solutions to compare results between two application versions. 
  Example for a structural model will be nodal deflections for specific load combinations. This result set may store Node number, Nodal coordinates, load combination number and deflections for three axial directions.
• App Output Files: These are the result files produced by the application(s) and stored as-is in Blob storage so these can be retrieved later on demand. For example, STAAD.Pro produces .anl file, which contains the basic analysis steps and some output tables, .bmd file contains the bending moment values of members. User may download these files for post processing using desktop version of STAAD.Pro.