Simple but structured interdisciplinary knowledge containers can help companies keep, transfer, apply engineering expertise
By Carlos M. Delgado, P.E.
Engineering companies competing in the global economy face many challenges. One such challenge is the need for the industry’s highly specialized, aging workforce to transfer knowledge to those replacing them as they enter retirement. Knowledge transfer practices help satisfy this need, although implementing such practices can be a challenging and complex process for companies. Using “engineering objects,” also called easy-to-use knowledge containers, can help engineering companies face these challenges in a simple but interdisciplinary coordinated manner.
Common issues in performing engineering work
- Not capitalizing on previous work – It is common to see engineers invest time developing systems from scratch instead of reusing parts of a past successful project. While this is more common among entry-level engineers, newly hired seasoned engineers could be making similar mistakes by using their previous job’s standards instead of using the current company’s standard. In both scenarios, chances are engineers have to redo work according to the current company standards.
- Investing excessive time for applicable examples – Past projects were not intended to be libraries for future use. Therefore, in order to reuse past project sections, engineers must spend time investigating the context of these past systems to decide if these projects should be reused, modified, or avoided.
- Learning from past mistakes – Learning from past mistakes is good, but it is optimal to learn from well defined, usable standards. Global competitiveness, higher expectations, and shorter deadlines force engineers to do more work and complete it faster, leaving little time to sharpen tools or create new ones.
- Getting bored – It is common practice to assign repetitive or boring tasks to entry-level engineers or interns. These tasks have a high margin of error and can discourage young people from pursuing a career in engineering.
- Losing the knowledge of our most talented people – David W. DeLong’s book Lost Knowledge: Confronting the Threat of an Aging Workforce discusses this:”
“You would have to have been living on the moon over the last few years not to know that baby boomers are fast approaching retirement age … lots of them have built up a tremendous amount of knowledge about how things work, how to get things done, and who to go to when problems arise. In some cases, this practical knowledge will be extremely hard to replace because it has been developed in an era of unprecedented technological and scientific advances …
“Leaders who fail to confront this threat will increasingly be held accountable for jeopardizing the future viability of their organizations. In the long term, you cannot compete effectively in the knowledge economy unless you are serious about knowledge retention.”
Four concepts have been considered in this engineering objects idea due to their positive effect on how work is done in the engineering industry. While these concepts cannot be fully applied to the idea, it is possible to learn from their positive aspects.
The engineering objects idea considers the use of best practices and procedures as recommended in total quality management (TQM), the object concept of object-oriented programming (OOP), the importance of having a usable system from the usability concept, and the need for knowledge transfer practices and tools from the knowledge transfer concept.
The idea: Engineering objects
This idea promotes a coordinated interdisciplinary engineering effort to build an effective, user-friendly knowledge database. This database will allow dynamic knowledge transfer where engineers will obtain knowledge “on the way” and where the company’s specialized knowledge will be kept.
Figure 1 - Knowledge containers in an expert’s brain
Knowledge sponges. To visualize the idea of engineering objects, imagine the brain of an expert is filled with knowledge containers where the substance in every container represents knowledge about a specific real device. As depicted in Figure 1, every container has a shaped top orifice that allows access to the substance. An engineering object is a shaped “sponge” that passes through the shaped container’s top to get the precious substance: “knowledge” of a specific real device as it is depicted in Figure 2. The shape of the sponge represents the name of the real device that needs to be standardized. If all companies’ experts call every specific real device by a standard name, engineering objects will be able to preserve specialized knowledge of every specific device. As a sponge keeps liquid in its cells, the engineering object will keep many types of information: diagrams, control strategies, and program code in related documents called digital layers. Preserving knowledge and best practices in a reusable and intuitive way facilitates knowledge transfer in every engineering discipline and between disciplines.
Figure 2 - Knowledge sponges
Representing the real object. One of the most common problems when working with different engineering disciplines is naming real devices like pumps, valves, and gates. A simple pump, when it is not well defined, could have different meanings between disciplines creating incompatibilities when assembling the final system. A pump for the electrical discipline could require a soft-starter, a start-delta starter, or perhaps a variable frequency controller. The same pump for the automation discipline could have a different requirement in terms of the number and type of field signals; controlling the pump via the soft starter requires fewer signals than controlling it using a variable frequency controller. Therefore, if the pump was not well defined at the design phase of both engineering disciplines, problems can occur during the implementation or installation of the system.
Using engineering objects, the real physical object like a pump or valve will have a common name and be represented by a compounded object or a collection of different engineering disciplines’ objects compatible with each other.
A detailed example. In the example of a simple centrifugal pump PC001 as shown in Figure 3, all disciplines will identify the pump with the generic name, but in addition, it will have its own “modifier” for each discipline.
The automation object could be called PC001-I001, representing a pump that has one digital output for the start command and two digital inputs for running and remote operation. In this case, the automation modifier is “I001,” which will be part of the final engineering compound object.
Figure 3 - Complete defined object with modifiers
As shown in Figure 4, this automation object will have layers of information including : input and output (I/O) requirements, control descriptions, human machine interface (HMI) and programmable logic controller (PLC) tag databases, HMI dynamic symbols, computer aided design (CAD) symbols, and PLC code. Compatibility with other disciplines’ modifiers is also important. In this case, the object is compatible with E012 (electrical) and M011 (mechanical) modifiers.
Figure 4 - Layers of automation information
As shown in Figure 5, the electrical object could be PC001-E012, similar to the automation object; this object will have layers of electrical information including: type of starter, power, voltage, phases, and electrical diagram. Here this object is compatible with the other disciplines modifiers: I001 (automation) and M011 (mechanical).
Now the mechanical engineering object could be PC001-M011, which could contain information about nominal capacity, capacity curves, and coupling. It is compatible with the other disciplines’ modifiers I001 (automation) and E012 (electrical).
Figure 5 - Layers of electrical information
Finally the complete name of this engineering object, which contains all disciplines modifiers is: PC001-I01-E012-M011.
This name starts with the main identifier PC001 plus the modifiers of every involved discipline (Figure 3).
This simple representation indicates a reference to a centrifugal pump type 1 in all involved disciplines. Every discipline modifier provides more specific reusable information for the respective discipline. For example, the automation modifier I001 tells the automation team that we are going to reuse the I001 HMI symbol and PLC code library to control this pump.
If the modifier does not exist, then the modifier must be created in the main object repository and then be used in the specific project, enriching the knowledge database. In this way, knowledge is captured and preserved.
Engineering methods or superior engineering objects. There will also be superior objects or methods that work with or use the basic engineering objects. For example, in Figure 6, an automation method called “lead/lag/follow automatic sequence” (I-mLL03) controls three basic centrifugal pumps in function of a wet well level, user level set point, and starting sequence order. This is an example of a superior automation object or an automation method. This method is compatible and able to command the I001 automation objects, giving life (by means of automatic sequence) to the assigned centrifugal pumps.
Figure 6 - Superior object or method
After defining a sizable core of engineering objects, more involvement can take place in defining more methods or superior objects, preserving the most specialized engineering knowledge.
Engineering objects deliverables per discipline. The engineering objects in the same discipline will have similar or compatible layers of properties (documents), allowing us to join these compatible layers that belong to different objects to produce basic specifications and engineering documents for the entire project per discipline. An example of produced documents for the automation discipline could be: control narratives, I/O list, PLC code, PLC database, HMI objects, and HMI control popup screens for all devices in the project. Similar examples can be done for the electrical and mechanical disciplines.
A note on other disciplines: Although other engineering disciplines, like architectural, structural, heating, ventilation and air conditioning (HVAC), and plumbing, have not been mentioned, chances are the concept of engineering objects can also be applied for these disciplines.
Current industry trends
In the automation industry, there is an increasing trend of new products that propose objects usage, offering templates or development environments to produce objects that can be reused. Even though this effort is focused primarily on the automation discipline, it could help with a multidisciplinary approach of engineering objects. For instance, HMI or SCADA objects can contain many layers of information for the automation objects, but not all. Other layers of information for the automation objects would include PLC programs, P&ID diagrams, and I/O list.
In engineering development companies, it is becoming more common to see 3-D and 4-D modeling tools used. These tools help the multidisciplinary team improve design coordination and construction execution. By automating the discovery of interferences between multidisciplinary 3-D objects, costly in-field corrections can be avoided. The 4-D (3-D + time schedule) modeling helps the construction effort by showing the interrelation between the schedule’s critical route and the 3-D progress of the project.
What is new in the engineering objects idea?
The goal behind this idea is to create an interdisciplinary, highly usable knowledge transfer database. Based on standardization of the real devices names between disciplines and extended names in every discipline (modifiers), it would provide an easy-to-use objects standard repository while keeping key engineering knowledge in the company.
HMI/SCADA object-oriented development systems can help provide some layers of information, but not all that are needed. The engineering objects must contain layers of information, not only about HMI symbols or dynamic graphical symbols for a specific HMI/SCADA manufacturer, but also for a broad range of manufactures that are used in the company. Also, PLC program code for commanding the objects in different PLC brands and languages will also be involved in this approach.
3-D and 4-D modeling tools are very useful for coordinating between disciplines, but also it needs a coordinated organization for naming objects in order to make the system easily re-usable. 3-D and 4-D tools provide some repositories (types of files) that can be linked to the different 3-D objects but not all. A successful 3-D and 4-D model design and construction project would not have sufficient success as a knowledge transfer tool if the names of multidisciplinary objects have not been well defined for use in future projects.
It is clear more than just IT tools are necessary to build a good knowledge transfer database. Primarily, it is necessary to invest time organizing and standardizing. It is also necessary to have common names for calling the real devices between disciplines, and specific names for every discipline objects or modifiers and methods. Ideally, every discipline should invest time specifying its own objects, considering their interrelationship and compatibility preventing incorrect usage and duplication.
Implementing engineering objects
The engineering objects implementation can start standardizing real devices names through an interdisciplinary effort. After all disciplines settle on common and unique names (codes or acronyms), then every engineering discipline will produce their own object modifiers considering compatibility to the real devices and between other discipline modifiers as well. Simple but structured operative system folders are enough to start collecting the information. The object’s information layers will contain different kinds of digital file formats. The piece of information for a specific layer should be standardized to be easily used, allowing copy and paste functionality to any specific device in our current project.
Figure 7 - Example of engineering object folder
Engineering objects’ future
With this structured information, it is only a matter of time to develop coordinated and compatible tools to auto-generate repetitive parts of the engineering project development process. It will be common to see an engineer inserting engineering objects to a digital whiteboard from a corporate engineering knowledge repository and receiving an automatically generated base project where the engineer will focus on completing the complex and critical parts of the project instead of getting bogged down with repetitive and time consuming tasks.
Every time a new engineer plans to use an object from the engineering knowledge repository, he or she will benefit from the knowledge transfer (learning) “on the way” of the company’s best practices.
The project directories will look different than they have in the past. Not only will they show documents in different formats, but the directories will show which objects were used in every project. Now, in addition to the projects directories, there will be a new tree directory containing the engineering knowledge transfer repository, which will contain all disciplines objects.
Engineering objects are virtual interdisciplinary representations of real engineering devices. The engineering knowledge is kept in the objects’ properties layers, allowing us to use these objects as knowledge transfer media. All levels of engineer will easily learn their company’s standards and best practices while reviewing and adopting the objects. In conclusion, engineering objects will retain the knowledge within a company with a high level of usability and functionality.
ABOUT THE AUTHOR
Carlos M. Delgado, P.E., (firstname.lastname@example.org) has 16 years of industrial automation experience, and he currently is a senior automation engineer at CDM Smith. Delgado is control systems professional engineer, and he holds a master’s degree in electrical engineering - control systems, from Northeastern University in Boston.
Related ISA Training and Publications