The Web App Approach to Simulation Democratization

(Image courtesy of EASA.)

We’ve written before about simulation democratization, the goal of putting the power of simulation into the hands of as many people as possible, be they analysts, designers, salespeople, or the Queen of England. One powerful approach to this problem is the technique of web applications. These are apps created for a very specific simulation problem, and they allow users of varying expertise to simply enter parameters and receive the correct output.

EASA is a software company that specializes in simulation web apps. They don’t just make bespoke web apps (though they will), they provide a tool that organizations can use to build web apps of their own. The concept is an interesting one, and we spoke with EASA’s Director of Business Development, Sebastian Dewhurst, to learn more about the pros and cons of this approach.

Low Code for Engineers

EASA (which stands for Enterprise Accessible Software Applications, though no one at the company actually uses that name) provides what’s known as a low-code development platform (LCDP). LCDPs allow users to develop applications with little or no coding required.

“You can think of EASA as a low-code application builder focused on engineers and scientists,” Dewhurst explains. “Whether it's running a MATLAB model, running a full-blown CAD FEA [computer aided design, finite element analysis] model, or generating a price for a highly engineered product where the pricing is defined in a complicated spreadsheet.”

Take the example of an engineering spreadsheet. A salesperson looking to quote a potential client may use Excel to calculate an estimate. He or she would know which cells to change and which cells to read, but may not know the details of the calculations. While this system works, it is unstable. For example, what if they’re using the wrong version of the spreadsheet? What if they accidentally change a crucial value and disrupt all future calculations? The lack of rigor in this procedure belies the importance of the spreadsheet and would be intolerable with other engineering software.

Now imagine taking that spreadsheet, with all of its data and calculations, and giving it to the user in a form that hides everything but the relevant input/output fields. Imagine also that this new form is powered by the spreadsheet, but doesn’t write anything to it. Finally, imagine this tool is centrally accessible in a single, cohesive version. In essence, this is what a web app can offer.

“That's essentially what EASA is. It's a wrapper technology,” Dewhurst said.

Of course, web apps built with EASA (called EASAPs) aren’t limited to Excel spreadsheets. The true power of the platform comes from its model agnosticism. EASA can leverage models in any database, spreadsheet, or batch processing application, including custom in-house programs. Dewhurst recalls the example of Hewlett Packard, which built an EASAP to save several decades-old DOS-based codes for calculating ink drop trajectories for its printers.

“They were looking at having to throw [the codes] away, because they just weren’t very usable,” Dewhurst said. “So what they did was they used EASA to build a GUI [graphical user interface] on top of that code, to essentially modernize it.”

What an EASAP Looks Like

To better understand what web apps have to offer, let’s go through a simple example of an EASAP. We’ll look at a structural analysis of a rectangular plate. The underlying model will be a text-based DOS program without a GUI.

Screenshot of the analysis code used to power the EASAP. (Image courtesy of EASA.)

We want to take this code and put a GUI wrapper on it to make it more accessible to more users. The final result runs in a web browser, and looks like this:

EASAP of the rectangular plate analysis. (Image courtesy of EASA.)

Rather than having to navigate the original text-based code, users simply adjust the relevant parameters: length, thickness, load magnitude, and plate material. Furthermore, we can add a picture of the scenario that updates based on those parameters.

(Image courtesy of EASA.)

Once we’ve submitted these parameters, we can easily view the results:

(Image courtesy of EASA.)

The EASA Platform

To go from the DOS code to the EASAP, we use software called EASAP Builder. To the uninitiated, EASAP Builder looks a bit intimidating. There’s a learning curve, but users need no knowledge of coding to build an EASAP. According to EASA’s Tim Valachovic, users typically go through six hours of training to familiarize themselves with the tool.

Screenshot of EASAP Builder. (Image courtesy of EASA.)

EASAP Builder is used to both configure the GUI of the web app as well as provide all the connections between the app and the underlying model, be it an Excel spreadsheet, MATLAB script, or in-house code. While EASAP Builder must be installed locally, all apps are published to the EASA platform where users can access them regardless of the underlying code. For example, users don’t need to have MATLAB installed on their computer to run an EASAP that leverages a MATLAB script. However, their organization must configure a compute server for MATLAB to work in tandem with EASA. Ditto for Nastran or any other licensed software.

Users of the EASAPs, of course, can be totally oblivious to these details. This is all they see on the EASA platform:

(Image courtesy of EASA.)

While these are all demo applications, users would see only the EASAPs that their organization had given them access to. They would simply click on an EASAP, fill in the inputs, and be able to save the results without affecting the underlying model (e.g., a spreadsheet).

“The nice thing about this is version control is assured,” Dewhurst said. “When somebody opens this up, they can save the result and go back and open it, instead of saving numerous instances of a spreadsheet to a local disk. What they're actually doing is saving that data into their own user space where they can easily retrieve it and share it with other people.”

When are Web Apps Necessary?

Though there are several advantages to creating a web app for a given process, such as centralized access, cloud computing and simplified interfaces, most processes simply do not warrant the conversion. According to Dewhurst, less than five percent of all simulation processes can benefit from being made into web apps. This small number of processes are those that have two specific properties:

“Is it a process that is repeatable? And is it a process that would benefit from being placed into the hands of a wider audience?” asks Dewhurst. “Those are the questions that we always ask when we're sitting down with a prospective customer. Because if the answer to both those questions isn't yes, then we can't help.”

This reflects what Dewhurst and other democratization proponents uphold as a core principal of the movement: Not every simulation can or should be democratized.

“The value isn't in trying to apply democratization to everything that you do in modeling and simulation,” Dewhurst said. “We believe that the vast majority of modeling and simulation should be left in the hands of the experts.”

But for those few processes that are suited to it, democratization can make all the difference.

“The vast majority of models that you build as a company are not suitable to be democratized. That doesn't mean, counter intuitively, that you shouldn't look at democratizing that small percentage that do lend themselves. Because the return on investment that you can get, even from that tiny slice of the pie, gets magnified massively once you apply democratization to it,” Dewhurst said.

To learn more about EASA, visit their website. For more information on democratization, read The Path to Simulation Democratization.