Each and every industrial machine on the factory floor gets personalized care from a combination of people and software. Both human eyes and digital algorithms are continually looking at how machines are “feeling” by observing metrics collected from different parts of each machine. Each machine even has a personal ‘diary’ where you can both look back to see all the changes the device has undergone throughout it’s life, as well as the current health of the machine. Watch the video and read the blog post to take a look at the complex software needed to care for such machines.
Customer’s problem
The sad truth is that machines will break down if not maintained properly; however preventive maintenance can avoid unscheduled outages to replace a broken part. It turns out that machines tell you about being “sick” long before they “die,” simply by vibrating differently. Every machine with moving parts vibrates, and the symphony of sound from a machine is comprised of individual components each playing their own melody. This melody has a rhythm to it, and while it may change over time as elements interact with other parts, it also reflects the microscopic changes that are the results of ordinary wear and tear. Maybe you’ve seen a railroad engineer go down a line of train coaches, knocking on the wheels with a hammer along the way – A lifetime of knowledge and training has given this engineer the ability to differentiate between the sound of good wheels and those that are in need of replacement. This operation is the precursor of modern-day preventive machine maintenance.
Unlike the train engineer, using sound to determine the condition of the wheels, today we are able to use software to create a visual representation of a component and identify the precise potential issue before it ever comes to light. “Modernize our legacy workstation-based machine modeling software with a modern web-based version.” Such was the challenge from one of our customers, a large US-based engineering company, who wanted to both improve their existing software tools and integrate different information sources. As a team of US and European architects and designers, we met with the customer to go through use case scenarios and flush out a Proof of Concept (POC). The POC would work through visualization and mechanical modeling challenges and supply the required research to define the scope and mitigate the risk of full-scale implementation.
Figure 1 — User interface of the graphical editor
The DB Best approach
In response, DB Best developed an application in JavaScript for modeling abstract models, actual models and display of operational data in the context of visual models. Our design goals included minimizing any unnecessary visual distraction and using the available screen space for relevant information only. As you can see in the above image, we have recreated a turbine engine in our editor. The program that we have created is a simple-to-use but incredibly powerful graphical editor that will be able to highlight any major issues with the turbine before they come to pass. The genius of our program lies not in its complexity but its simplicity. The user interface of our editor does not betray the fact that we are able to utilize a three-tier architecture: the SQL Server database, a web server providing REST API, and a rich JavaScript application.
When building our web-based graphical editor, we created a program that is as easy to learn as ‘drag-and-drop,’ because it is. Our editor is a WYSIWYG (What You See Is What You Get) program that allows users to quickly and effortlessly create an entire model onto a canvas and configure each part with their specific text and number values. As the user adds parts to the model, they snap to and connect to each other to inform the the user about, for example, the consequence of having a small gear attached to a big gear, which could result in a lower rate of revolutions per minute. With every single piece of machinery, users are able to determine just what parts will fit in which engine and how it will impact the engine as a whole.
The core idea of the graphical editor
When creating our graphical editor, we knew that we would be tackling a number of major obstacles but the biggest revolved around how we would be able to create the graphical representation of the complex machines. Simply drafting and importing the end product, an engine that was also a massive composite of interwoven parts and technologies, would be unable to provide the necessary customization that we envisioned. Therefore, much like in real life, we re-created each and every tiny part of the engine and built it from scratch.
Unlimited possibilities for a modeling tool
Why not use an off-the-shelf powerful CAD application for this purpose? – That should always be the first question. The tradeoff in our case is people skills and application focus. A general-purpose CAD application is necessarily much more sophisticated than is needed and will require a more trained engineer and provide an interface which is much richer but also more distracting, with details that are irrelevant to the purpose at hand. We only need to model to a certain level of detail – beyond that, there is no return on the design investment. We need a domain focused application that does everything we need and nothing more.
This software will model machines “caught in the wild” to capture what parts exist and what parts are monitored to provide the engineers with sufficient context to schedule maintenance and watch for problems. But how do we make a modeling tool that can represent any machine we may encounter in the future? We must limit the scope. Let’s consider rotating machines. A rotating machine has one or more axles, usually referred to as “shafts” by the engineers, and parts attached to those axles. A motor has pistons driving a shaft and a turbine has blades in a pressure section driven by steam. Those machines are “drivers” as they produce the torque which a “driven” machine can turn into work. The only mechanical parts of the machines we care about are the ones that will “talk” to us and require intervention before their end of life.
Using classes and instances
Parts and pre-made smaller machines used for modeling, come from a library that is maintained by an engineer who can envision what is likely to be re-used. We call these reusable parts “classes” and their use “instantiations” where the pattern of the class is realized. But in common language, we are creating general patterns of things that can be tailored later. We define the attributes of all the parts such as dimensions or typical ranges of operation without specifying values of how much or how far. Then when we realize the pattern to model a real machine, we enter the numbers. Figure 2 shows a behind the scenes model of the data structure that corresponds to a machine with multiple parts.
Figure 2 — Model of the data structure
From a data management perspective, we need to consider: what happens if you modify a class after you have created an instance based on that class? – Do we propagate those changes into the instances or do we effectively create a new version of the class? We decided to think of classes as “stamps” which closely resembles actual machine model, except attribute values are not yet filled out. The difference between a class and an instance is in how much detail is filled out. Creating an instance from a class is a matter of copying. Changes to an existing class creates a new version of the class.
Making complex things look simple
Figure 3 — The third angle projection
From a visualization perspective, we are dealing with three-dimensional models because we model three-dimensional (3D) machines. This could get complicated quickly and bears on the earlier discussion of using commercially available solutions. Modeling in 3D requires training that is mostly wasted on the goal. We, therefore, decided to provide two dimensional (2D) projections of the machines which will give the engineer the necessary clues to the 3D position of a part or a sensor. Internally the software knows about 3D, but it reduces the complexity for the user to a 2D experience. This corresponds to typical machine documentation which provides 2D projections for many purposes. As an example of projection, see Figure 3 with the third angle projection used in America.
To reduce the need for detailed drawing functionality inside of the modeling software, we decided to leverage ready-made drawings from other sources. We use scalable vector graphics (SVG) drawings to accommodate any resolution and bitmap photographs to show real-world representations like a “skin” on top of a technical drawing. This gives the user the ability to pull back the cover of the machine to expose the internals which may be needed to understand where parts and sensors are placed. See Figure 4 and for an example of the difference.
Figure 4 — Different examples of representation of objects
Taking advantage of the Internet of Things
Finally, a use case required the placement of a machine drawing inside the machine “diary” with actual data superimposed on the model. In the machine “diary” the engineer can observe both historical and near-real-time metrics for the monitored part of the machine. This is an Internet of Things (IOT) solution where broad scale device data collection is made available just where and when it is needed. For this functionality, we are proposing web sockets to propagate data to the web page embedded control.
This project tapped into a broad range of skills from data modeling to design to usability and is an excellent example of the capabilities of the versatile DB Best application development team.
