Metis Modeling of Process Driven KBE

Ivar Marthinusen

Introduction: Modeling the world around us is part of human nature. We need to, and enjoy trying to see relationships between concepts and categorizing these concepts. Categorization of concepts and explaining the relationships can be done textually, but the visual processing unit in our brain is also quite advanced. In a matter of milliseconds, we are able to see patterns in images and graphs that would take a computer many seconds, if not minutes to analyze. Because of this, a visual model can be many times more powerful than a textual description, and it is this power we are trying to utilize when modeling in Metis. This paper describes one such model, that will visually explain the abstract concept of doing process driven Knowledge Based Engineering (KBE).

Background When enriching a computer system with knowledge to be used in solving complex problems, we are dealing with a Knowledge Based System or KBS. Use these systems in solving engineering problems, and you have entered the domain of Knowledge Based Engineering. Knowledge Based Engineering has for many year successfully been used to design product variations with up to 90% reduce in time to next product. My PhD thesis will examine if KBE also can be used for engineering processes, and not just products. Finally, when the process has been engineered, it will be much easier to engineer the structures needed to hold the process equipment in place.

Figure 1: An attempt to illustrate the difference between a product and a process. In the first image we have a typical angle bracket (product) designed in a typical CAD application. The second image is a simple flowchart illustrating the process of manufacturing such a product.

Being in the startup-up phase of this project, it would be quite interesting to try to model the process of engineering an oil and gas process. By doing this, I will get a clearer understanding of the complexity of the work ahead. In addition I will gain a better understanding of what capabilities the KBE framework needs, so that it can most easily aid the engineer in designing such oil and gas processes. For simplicity, I have chosen to model what a typical oil and gas platform design process will be like, and what this process needs in order to run properly.

Rationale The reason for the choice of case, is simple. I hope to gain a better understanding of what needs to be done in my PhD. Because of this, the primary user for this model will be me. At the same time, the model should also be readable by others wishing to look into my work. The next challenge is how do I evaluate the success of a model, who's only purpose is to give me a better understanding. For the secondary users, I can give them one minute with the model, and then see if they, from the model, understand what it is that I will be doing for my PhD. When it comes to my own goals I hope

1. As I model, I will come up with least 5 objects that I had never thought of before starting, but that became apparent during the modeling process.

2. I am left with a model or a view that can be useful in my PhD thesis.

3. I am left with an easy to understand way of looking at information flow in the final KBE framework.

If these three goals are met, the model will be a success to me as well.

Modeling Since I am modeling a process, the most natural choice for me is to use the MEAF template, and within that use the IDEF0 modelig language as the basis for my main process. The IDEF0 language provides a very formal way of looking at processes, where each sub- process has arrows going into it from each of the four sides representing input, output, controls, and mechanisms. Each sub-process can be looked at as a black box where an input is transformed into an output. The transformation is done via the mechanisms, and the process is controlled by the controls.

Figure 2: The building blocks of an IDEF0 process model. (Image source: Wikipedia) By using this modeling approach, I will always be forced to think about each of these four aspects for every single sub-model. Therefore, if an object is needed that has not yet been modeled, it will be modeled, and I will have uncovered a flaw in my original thinking. This in turn, will help me achieve my first evaluation goal.

Figure 3: A screenshot of the Platform design process as modeled in Metis.

I have generally chosen not to model the controls and mechanisms for the deepest sub processes, as these are mostly the same as for their parent process. When it comes to which part of the KBE framework each sub-process will need to do its work, I simply do not know yet. Since the model is meant for me, I have chosen not to add any yellow notes for extra information, as this clutters the model. Instead, all auxiliary information has been added in the properties dialog for each object. Also, the domains from which input, output, controls and mechanisms derive from have been modeled on the correct side of the platform design process for easier visualization. Figure 4: Screenshot of the entire model.

At the same time as I modeled my main process, the other domains grew naturally, as shown in Figure 4. An interesting note is that I have added a Measure of Effectiveness (MOE) in the goals, because it helps me evaluate the main goal. Although mostly everything else in this modeled is there to support the engineering process, the MOE and the vision has been added to evaluate the success of the process and is therefore related specifically to my PhD.

Changing the meta-model I have for the most part been able to use the modeling tools provided, without modifications. A few of them though, had to be modeled as a general connection.

1. From the KBE framework object to the Catalogs object, there was no option of an "is used by"-connection, as there was for every other object in the Knowledge Base domain.

2. From the KBE framework object to the Vision object, I wished to add a connection to show that the Vision is used to define the level of standard needed for the KBE framework to be considered a success. None of the suggested connections fit this description.

3. Since containers are not real objects in Metis, they also have no defined relationships. I did though want to show that all information in the Knowledge base uses the AML-modeling language, I therefore put a general relationship from the container to the AML-modeling language to show that it is stored in this way. It would be wrong to point an arrow to every object in the knowledge base as much of this information is not represented by AML-code originally. Views Several views have been created to facilitate in identifying the dependencies of some key objects.

1. Platform design process dependencies: This view shows what dependencies the main process has, and incorporates most of the model. It is interesting to note that the Platform design process is not depended on the AML-modeling language, or the Knowledge engineer

2. Process driven KBE framework dependencies: This view shows all the dependencies of the KBE framework. As we see, the framework is dependent on the AML-language, and the knowledge engineer. It is also interesting to note that the platform design goals of the project is closer related to a good platform design process, rather than a good framework. The KBE framework is though a good tool for measuring the MOE.

3. Engineer dependencies: This view shows the immediate neighbors to the Platform designer (user of the KBE framework), and therefore also what he needs to care about.

4. Knowledge base users: A view showing what objects in the model directly use information from the knowledge base.

5. Process tree: Shows the different sub-processes in a tree structure, rather than a folder structure. Figure 5: An example of a view. In this case, the Knowledge base users view.

Relationship matrix I was interested in seeing what process creates outputs to other processes, and what processes needs input from previous processes. I therefore chose to list all sub-processes on both axes, and see what relationships were present. I used the option "hide interfaces" to make the list less cluttered. Now it is easy to see that for example Route connections is dependent on two other processes for input, and creates output for one other process, while Weight and vibration analysis does not need input from any other process, and just provides output for one other process.

Figure 6: Relationship matrix showing the relationships between different processes. Note the symmetry due to both axes being equal.

Relationship to Enterprise Architecture The PhD project is just a first step. If successful, the goal is of course to make this KBE framework commercially viable. There are two options. One is for a major oil and gas company to implement this framework, another is to start up a company in Norway that develops KBE software and services and sells this to other companies. It is the second option that will be explored in this section, as this gives the most flexibility

The product being developed in the PhD will be state-of-the art when finished, but it will not stay this way for very long. It is therefore important to have a vision and a strategy for updating the framework in line with the ever changing world around it, and it is here Enterprise Architecture is important. TOGAF is probably the most relevant for our KBE framework, as it works very similarly to the way KBE software works. TOGAF is based on a continuum of architectures going from the very general to the very specific. In the same way, a KBE framework is a tool that helps create a very generic class of products, and that, with the help of an engineer can create a range of unique products. Not only that, but both like to refer to themselves as "architectures." In the TOGAF architecture, the model created in this paper can be looked at as input to the preliminary model, because it contains many of the aspects that are needed today. There will however also be other aspects of an organization that needs to go into this preliminary model, one of the more important ones being the organizational structure of the people and roles in our specific enterprise. The model also needs to be aligned with another model for knowledge acquisition as this will also be a key aspect of the new enterprise, but that is not covered by my PhD

Once this preliminary model has been created, the cyclical process of designing and refining our enterprise architecture can begin. Evaluation of the architectures created can be voiced, and put into future requirements, such that the enterprise architecture will continually evolve into what the enterprise currently needs. In this way, the enterprise will not be stuck in the past.

Figure 8: The TOGAF cyclical model (Source: Class slides)

Evaluation As with most exercises, the full usefulness of this model was not realized until after it was done, and while I did write down some evaluation criteria before starting, these were not the criteria I found to be most useful.

1. Did I come up with at least 5 more modeling objects? Both the Actor domain, the vision, and the MOE came up during the modeling as things I had not thought of before. The real discovery however were in the connections within the process. I had always imagined the process to be linear, but iterative. Modeling in IDEF0 however, forced me to think more clearly about the needs of every sub-process, and there were plenty of times I realized the output from the previous sub-process was not the input of the next sub-process. Hence, these two sub-processes could go in parallel. I also realized there were some processes that needed input from two previous sub-processes. 2. Am I left with a model or a view that can be useful in my PhD? Yes, or at least with modifications. The model, and some of the views are really helpful in explaining some aspects of the PhD. I especially liked the simplicity of the Engineer view. When it comes to Metis however, it suffers from readability. I don't think the developers of the software has heard of anti-aliasing, and it is all really reminiscent of old Soviet buildings. Sure, it works, but it doesn't look pretty. With Soviet building, at least their function is still valid, but the clue with modeling is to invoke the visual processing unit of your brain, and models created in Metis simply do not do that. This is not just my opinion, but I showed the Engineer view to five people who knew nothing about my project, and they gave up trying to understand it before even trying. When showing the same model on a piece of paper, it was much clearer to every one of them. That being said, I asked both the other PhD candidates I am working with, and my supervisor about how the model looks, and they all really liked the way it was organized.

3. Am I able to see information flow more clearly? Yes, and no. It is now quite easy to see that all information (or knowledge) is used by the KBE framework itself, and not by the user of the framework. Using the IDEF0 modeling way however, I did find it hard to keep track of what knowledge is being used where. I have four arrows, from four different sources going into the main process as controls, and I have three arrows coming out of this control to the different sub-processes, but I have no control over what information is flowing which way after they all converge on this control arrow. A possible solution to this could be to color code the arrows like shown in figure 7. Currently, the only way to check this is to check the controls for each sub-process, and see what it needs. Figure 7: Proposed solution to seeing how information flows, using color coding for the different sources.

Conclusion Given the results of the analysis, I would say the model has been successful. Although only 3 of the 4 goals indicated in the rationale was met satisfyingly, I also discovered one extra area in which the model has helped me understand the work to be done in my PhD that I did not think of beforehand. In addition to being a help and mental exercise for me in understanding my project more clearly, I have also discovered it can be more useful than expected in explaining to others what it is I am doing. As my PhD progresses, I hope it will be easy to update my model using Metis, so that it can evolve with new knowledge I gain in the PhD process. I shall also be extremely interesting to look at this original model when I am done with my PhD to see how many changes has been made along the way. It is only then that the model can truly be evaluated.