Context

RAM (Reliability, Availability and Maintainability) Modeling and Simulation (M&S) is a confluence area between:

• Hard skills as process or mechanical engineering, required to understand what is the modeled plant and process about, and
• Softer skills on IT, required for creating and running models using software tools.

This forces a good modeler to push the borders of what is possible in at least two directions at the same time:

• First, a modeler needs to figure out what is a good way to solve an identified performance restriction, teaming to discover creative alternatives from a plant configuration or some other business-related point of view, and
• Second, a modeler needs to figure out how the myriad of creative ideas collected, are going to be implemented in the model using the resources or language provided by the simulation tool (RBDs, F/STs, etc).
• As an excitement bonus, everything has to be assessed for today before 4:00 pm (so we save 1 hour for the slides).

Modeling a Industrial Asset requires a language.

Language (by Merriam- Webster): the system of words or signs that people use to express thoughts and feelings to each other.

Figuring out the way to use the modeling language to represent alternatives may seem almost obvious when the thing to test is the pervasive case of assessing redundancy levels, as this is a functionality readily available in every (decent) RAM modeling tool. Luckily RAM M&S exercises are not that boring anymore. More and more clients demand business performance figures instead of restricted calculation of the R, the A and the M. In such situations the task of using current modeling languages to represent base cases and alternatives may become a real challenge.

Questions like:

•  What is the best mix of operational modes for taking advantage of typical variable cost of energy during the day?, or

• Is it cost effective to buy an additional boiler when considering all the variable sources of heat by the process while producing our set of products?

remain in the field of holistic and business oriented natural to RAM Analysis (because both question relates performance to money), but may also get us in a really uncomfortable position as modelers because just using RBDs (Reliability Block Diagrams), FTs (Fault Trees) and flow networks is quite cumbersome to represent concepts as energy efficiency.  

Not buying it yet?

Similar challenges appear when question asked by our clients, require the model to “decide” during simulation time. Mimicking the way an operator would behave checking multiple technical and business variables and conditions before deciding on the appropriate action to perform with the plant, is not something an RBD + conditional logic would do nowadays. Decisions, as happen with energy flow, energy efficiency, coordination of operational modes and complete management of the state of the model are not concepts existing in the languages proposed by traditional reliability modeling methods, and that’s a shame, because such are the very basic building block of every plant and each operational strategy around the world.

How to get more realistic?

Let’s take some breath to back some ideas from another industry which is not that far to RAM simulation, the computer graphics. I just hope your geekness level is high enough so you feel comfortable with this example.

In the old days, drawing a line in computer screen, was almost as a painful geometry class in elementary school. Drawing a line required to do the code to turn-on each pixel, one by one, in certain direction. Drawing a flat horizontal line at a certain vertical position using that low level language approach would require to code something like:

vPos=100
For xPos= 1 to 1000
               plot_point (xPos, yPos)
Next xPos

When the only resource you have is this low level statement : “plot-point”, this chunk of code will reward your eyes with a monochromatically-ugly horizontal line. You may imagine how cumbersome this gets if you want to add angles, colors, shapes, zooming and movement. Inevitably you had to add, by yourself, all the math required to pic the precise pixel to lit.

Now imagine all the work required to create a video game with that. You’ll be inevitably restricted on how (un)interesting a video game would be when working graphics in that manner. Welcome to 70’s Space Invaders

Let’s jump 30 or 40 years.  You can visit OpenGL Wikipedia pages if you want to see what would the heaven look like for a 70’s video game programmer. OpenGL is a “high level cross-language, cross-platform” application program interface for rendering 2D and 3D graphics that may be “understood” by other software but also by computer hardware (actually Graphic processors). The humble point still exists in OpenGL, but next to it there’s a full bounce of “primitives” (polygons, lines, line-loops, quads, matrix of vertices, etc), a three-dimensional space to locate all of them (instead of the 2 dimensional space invaders’ space) and complex behaviors to illuminate, morph, rotate and visualize three-dimensional shapes with texture.

All of this is ready to be used in an “open and inter-operable” way to each video and game developer around the world. Now welcome to Avatar, Halo and the CGI parkour classes by Assassin’s Creed trailer.

If you ask an unsuspecting pedestrians about the difference between Space Invaders and last Halo 5, they may use a beautiful word. “Now images look more realistic” and being realistic is exactly what we are eager for when doing RAM Modeling and Simulation.

Now, seriously, how to get more realistic?

RBDs, Fault Trees and flow networks have been and will be tremendously useful for representing an immense amount of process plants; and I stress this just to make sure I’m not going to be taken by sacrilegious, but the absence of a popular, beloved, fun and standardized high level cross-language, cross-platform way for describing the most natural elements in process plants as operational modes, energy, efficiency, simulation-time decisions and much more high level concepts may well be preventing us to provide more realistic depictions of the future.

 A good starting point to check whether this rebirth of RAM is going to be a possible goal or at least an exciting challenge may be to visit the SysML specification website by the OMG, or perhaps review the architectural concepts behind OpenCL (no, is not the same than OpenGL) or some other sources, no matter how crazy they look like.  At the end FTAs are at least 50 years old, so for sure somebody may had figure a better way to make more efficient and realistic description of performance dependencies in process plants.  

It would be really interesting to see if readers have found [thrive_2step id=’749′]promising examples[/thrive_2step], so eventually we, as modelers, may visualize and show plant performance in a way as interesting as the next CGI-generated trailer of a Sci-Fi movie.

…Be good and keep alive!

Jorge