Discipline differences in mental models: How mechanical engineers and automation engineers evaluate machine processes

Interdisciplinary collaboration frequently comes into play when existing problems cannot be solved by one discipline alone. However, the interlocking of contributions from different disciplines is by no means trivial. This exploratory study examines one foundation of successful teamwork, namely shared mental models. To this end, we compared the contents of mental models between members of different but interdependent disciplines who collaboratively solve knowledge‐intensive, creative tasks. Five automation and five mechanical engineers were recruited from a company that produces packaging machines. In semi‐structured interviews, participants reported their approach to evaluating the process behavior of a packaging machine, and their mental models were represented in concept maps. Quantitative analyses revealed that the maps of automation engineers were smaller than those of mechanical engineers. In qualitative analyses, the focus on different levels of abstraction and on contents from the two disciplines was examined. Automation engineers represented a large proportion of rather abstract machine functions, whereas mechanical engineers additionally represented the physical implementation of these functions. The disciplinary focus also differed in the sense that automation engineers mainly attended to automated machine processes, while mechanical engineers attended to both mechanical and automated processes. Overall, automation engineers' focus was narrower than that of mechanical engineers. We explain these results by considering typical tasks and reasoning processes in both disciplines, and discuss how shared mental models can aid the integration of different disciplinary perspectives, for instance, during Systems Engineering.

Interdisciplinary collaboration is both promising and challenging at the same time.Combining contributions from different disciplines makes it possible to find solutions to problems that could not be solved by any discipline alone.Such complex problems are characterized by a high number of interconnected but possibly nontransparent variables that change dynamically and relate to each other in (partially) unknown ways.In addition, multiple goals may have to be pursued that are not always known and may compete with each other (Funke, 2012).In engineering, for instance, the goals of low costs, fast development, and high quality typically cannot be achieved all at once (Bierhals et al., 2007).Interdisciplinary collaboration, however, comes with its own difficulties.Members of interdisciplinary teams might disagree about which goals to pursue, or they might agree on the overall goals but evaluate their importance differently.Other difficulties may be rooted in the training of the collaborators that typically focuses on disciplinespecific problems, their representation by discipline-specific models, and their solution by discipline-specific methods (Andersen, 2016).
Integrating these disciplinary perspectives is a challenge many teams face.
One particularly interesting concept regarding interdisciplinary teamwork is that of mental models.Mental models contain knowledge about the world as it is perceived by an individual, and these models substantially guide this individual's thinking, decisionmaking, and behavior (Rouse & Morris, 1986).Since mental models are also shaped by previous experience and training, it is plausible to assume that they differ between the members of interdisciplinary teams.However, most contemporary research does not thoroughly characterize similarities and differences in the mental model contents of different but interdependent disciplines.Specifically in the context of Systems Engineering, this hinders the development of tools and models that are able to integrate multiple disciplinary perspectives.
The present article compares the mental models of two disciplines that collaboratively solve the complex problem of machine design.In an exploratory study, we elicited the mental models of mechanical and automation engineers regarding the same task: evaluating the process behavior of a packaging machine.We compared both disciplines regarding their focus on different levels of abstraction and on their own discipline.Our results and the following implications are relevant both to researchers and practitioners, to psychologists and engineers: First, we show that experts' mental models are domain-specific.Psychologists should therefore choose methods that are able to elicit, represent, and analyze domain-specific differences in mental models.Second, we argue that integrating disciplinary perspectives in a Systems Engineering process is not self-evident.Rather, it requires an understanding of what these perspectives contain as well as a shared framework for depicting these contents.
The remainder of this article is organized as follows: Section 2 presents the theoretical and domain background from which the research questions were derived.More specifically, we describe the domain of discrete processing and the respective engineering tasks, review previous studies on mental models in interdisciplinary design teams, and describe a framework for analyzing the mental models of technical systems.Section 3 provides a description of our methodological approach.The results are reported in Section 4 and discussed in Section 5. Finally, Section 6 provides a conclusion of the present study.

| Discrete processing systems and their design
Machines in the discrete processing industry produce individual goods for mass consumption that typically consist of biogenic materials such as foodstuff (Majschak, 2018).While each production process entails specific requirements for the machines implementing that process, there are also some general domain characteristics that ultimately influence the demands put on the engineers designing the machines.Building on the comparison of the process versus discrete processing industries by Müller and Oehm (2019), some of these characteristics will be described next.
First, discrete processing plants usually consist of different types of machines.For instance, a chocolate production plant may combine a casting system for producing chocolate bars, a storage and transportation system for distributing them to subsequent machines, primary packaging machines for wrapping each chocolate bar, secondary packaging machines for putting several chocolate bars into carton boxes, and a machine for stacking many of these boxes onto pallets ready for transport.Within each of these machines, different processing steps have to be carried out.For instance, a machine for packaging single chocolate bars must transport the bars and position them correctly, add the packing material, join chocolate bars and packing material segments, and transport the packaged bars to the next machine.Depending on the product and customer requirements, engineers often design highly specialized machines that are custom-made for a specific production line.Second, machines in discrete processing typically operate at very high speeds (e.g., packaging up to 700 chocolate bars per minute)-with the caveat that faults typically occur more often as machine speed increases, thereby also increasing the downtime of the machine.To enable production at high speeds, engineers must ensure that the machine performs all processes with extraordinary precision.Third, discrete processing plants are usually influenced by environmental conditions such as temperature and humidity, which in turn interact with the products and may change their properties.During the packaging of chocolate bars, low temperatures in the production hall may cause the bars to become more brittle and thus more susceptible to the mechanical load placed on them during packaging (i.e., they will break more easily).On the other hand, higher temperatures may cause the chocolate bars to melt, which may lead to chocolate residue on transportation belts that changes the friction between the bars and belts.Due to the interactions between products, processes, and environment, engineers must anticipate different production conditions and enable the machine to react accordingly (e.g., ensure sufficient cooling of machine components).Fourth, even though the materials used in discrete processing are usually relatively cheap and do not pose a risk to human life, engineers must ensure that their machines meet high standards of safety and hygiene, especially in food processing.These global domain characteristics as well as the detailed requirements of a particular production process (e.g., number and vulnerability of products, type of packing material) form the boundaries for the design process.
During the design process, engineers must decide how the specific goals that the technical system is supposed to achieve can be realized by means of different functions (Bender et al., 2018).For instance, one function of the packaging machine is the transport of chocolate bars, which could be realized by using a robotic arm or a conveyor belt.Mechanical engineers decide which function principles can and should be applied in the current machine, in which sequence the different functions should be performed, whether several functions can be carried out together, and which mechanical components are needed to realize them.In sum, they are responsible for the design and layout of specific machine components up to entire packaging machines.Automation engineers enable the machine to adapt to changes in the production process.An example would be the adjustment of machine speed to the current product supply.This requires a suitable actor (e.g., servo drive), sensors that measure the product supply (e.g., photoelectric sensors), and the respective control software.Automation engineers are responsible for both the electrical engineering and the software engineering part.
Since the machine will eventually be used in a production environment and operated by humans, it is part of a Joint Cognitive System in which technical and human agents work together to achieve a common goal (Hollnagel & Woods, 2005;Romero et al., 2018).By making decisions about the design of the packaging machine itself, engineers inevitably shape the interaction between the machine, its process environment, and the operators.Thus, not only do automation and mechanical engineers have to integrate their contributions to design a functioning packaging machine, they also have to consider the requirements and capabilities of the future production environment and operators from the beginning of the engineering process (Elm et al., 2008).

| Shared mental models in interdisciplinary design teams
One key concept from research on efficient teamwork is that of shared mental models (Cooke et al., 2013;DeChurch & Mesmer-Magnus, 2010a;Mohammed et al., 2010).While the literature has not yet agreed upon one comprehensive definition of mental models, the understanding here is that they are organized knowledge structures used to understand system functioning and predict system behavior (Rouse & Morris, 1986).These knowledge structures are not static, but highly dynamic in three ways: They (a) can be used to mentally simulate different situations, (b) include information about causal relations in a system, and (c) can change over time and with experience (Jones et al., 2011).While many methods are available to elicit and represent expert knowledge (Shadbolt & Smart, 2015), concept mapping in particular has been used to assess mental models (Lin et al., 2016;Palmunen et al., 2021;Uitdewilligen et al., 2023).
Concept maps are node-link diagrams, with nodes representing the concepts and links representing relations between these concepts.As such, concept maps cover both the content and structure of mental models (DeChurch & Mesmer-Magnus, 2010b).In addition, concept maps can represent quantitative (e.g., associative strength) as well as qualitative aspects of relations (e.g., type-subtype or cause-effect relations) and thus provide detailed information about the mental models they represent.
Mental models are assumed to be one important basis not only for the reasoning and decision-making of individuals (Johnson-Laird et al., 2018), but also of teams.Mental models that are shared between team members facilitate performance and motivation (DeChurch & Mesmer-Magnus, 2010a;Kozlowski & Ilgen, 2006).
Mental models are especially important when the interdependence within the team is high and when the team task is rather knowledgeoriented instead of action-oriented (DeChurch & Mesmer-Magnus, 2010a).Thus, an engineering team designing a packaging machine (i.e., high interdependence, high knowledge-orientation) would be expected to benefit from a shared mental model.

Studies examining the antecedents of mental models in teams
indicate that sharedness is influenced by the behavior of team members (Boies & Fiset, 2018;Fisher et al., 2012;van den Bossche et al., 2011;Zhang & Wang, 2021), by specific interventions (Marks et al., 2002;Swaab et al., 2002), and by group composition (Fisher et al., 2012).Disciplinary background is an important dimension of group composition because expertise strongly depends on domain-specific knowledge (Devine & Kozlowski, 1995;Tricot & Sweller, 2014).Thus, it is reasonable to assume that experts from different disciplines differ regarding their mental models.For example, one robust finding from research on expertise is that experts categorize problems according to their deep structure, whereas novices focus on surface features (e.g., Chi et al., 1981;Hmelo-Silver & Pfeffer, 2004).If this deep structure differs between disciplines, experts will also rely on different mental models to represent and solve the problems they encounter.Shared mental models in interdisciplinary teams have, for the most part, been examined using action teams executing a clear task with well-defined operational standards and roles (Badke-Schaub et al., 2007).Such teams are typically found in military contexts, process control, or medical care.Studies with interdisciplinary medical teams have, for example, indicated that team members only share some aspects of their mental models.More specifically, team members may agree about the steps to be taken in a specific situation, but not about their relative importance or about which discipline is responsible for carrying them out (Blondon et al., 2017;Brown et al., 2017;Körner et al., 2016).Indeed, the shared mental model of a surgical team should include the same goal and process steps for all team members, and ideally also knowledge about when and by whom a specific task should be carried out.Conversely, for teams working on tasks that are less behavior-oriented and directive but instead require finding creative solutions to novel problems (as is the case for design teams), the aspects of who should do what at which point in time may be less relevant.
In one of the few studies examining shared mental models in design teams, groups of participants had to carry out either an architectural or an engineering task (Casakin & Badke-Schaub, 2015).
Verbal utterances from two meetings were categorized as being an expression of the task, process, or team cohesion model, and the authors found that in both types of teams, the task model was mentioned most frequently and the process model least frequently.
However, this study did not examine whether the disciplines had different mental models of the task, process, or team cohesion, and if they did, what these models looked like.To examine the influence of disciplinary background on team members' mental models in an engineering context, discipline-specific perspectives on technical systems must be represented in one framework.

| Rasmussen's abstraction hierarchy as a framework for categorizing the contents of mental models
Each technical system can be represented on different levels of abstraction (Bennett, 2017;Naikar, 2017;Rasmussen, 1985).This abstraction hierarchy describes the purposes, functions, and physical components of a system that are linked via means-end relations.The purposes are placed on the highest level and the physical components on the lowest.The functional levels in between specify how the physical components are connected to the purposes (i.e., which physical components carry out which functions that in turn make it possible to fulfill the purposes).While the exact number of abstraction levels is variable and should be adapted to fit the constraints of the system at hand (Vicente & Rasmussen, 1992), the original abstraction hierarchy proposed by Rasmussen (1985) consists of five levels: functional purpose (i.e., intended function of the system), abstract function (i.e., flow of energy and mass), generalized function (i.e., functions independent of concrete physical implementations), physical function (i.e., physical processes and components), and physical form (i.e., physical appearance of components).By only looking at those components that are functionally connected to a certain goal, suitable courses of action for an occurring problem can be identified, while all other components can be ignored (Vicente & Rasmussen, 1990).Accordingly, individuals can move up and down the hierarchy to better understand and cope with the complex system at hand.By moving up, one can better understand why a certain component or function is implemented, and by moving down, one can track which functions and components are needed to achieve the purpose of the system (Vicente & Rasmussen, 1992).
Empirical research shows that people are better at interacting with technical systems and diagnosing faults if information is provided on all levels of abstraction (Ham & Yoon, 2001;Vicente et al., 1995), while information on the functional levels seems to be especially relevant (Janzen & Vicente, 1998).Moreover, if information is missing on some levels of abstraction, people actively seek it (Burns, 1999;Hall et al., 2006).Abstraction hierarchies can therefore also be used to describe what aspects of a technical system people attend to.In the present study, the abstraction hierarchy is used to assess the extent to which the mental models of engineers from different disciplines focus on different levels of abstraction.

| Present study
What distinguishes the mental models of people with different professional backgrounds that collaboratively solve knowledgeoriented, creative tasks in an interdisciplinary engineering context?While previous studies of mental models in (interdisciplinary) teams have largely focused on determining the amount of overlap between individuals' mental models, existing differences can only be interpreted in a meaningful way when researchers also specify which aspects are shared and which are not.Therefore, the present exploratory study aims to shed light on the specific contents of mental models in an interdisciplinary context.The participants were automation and mechanical engineers from a company that produces packaging machines.In this article, we aim to answer the following questions: Do automation and mechanical engineers differ in their perspectives on a packaging machine, and if they do, in what ways?Do they rely on comparable levels of abstraction when evaluating the process behavior of the machine?To what degree do they assume a systems engineering perspective, also representing contents relevant to the respective other discipline?And how can these findings be used to enhance the Systems Engineering process?
In the present study, mental models were elicited using semistructured interviews in which participants were asked to imagine a packaging machine for wrapping chocolate bars during production, and to describe how they would proceed to evaluate the process behavior of the machine.Speaking in terms of Hollnagel et al. (2006), we aimed to assess work as imagined-not as defined by management, but from the engineers' point of view.Using a hypothetical scenario aimed to elicit an inspection of the machine based on participants' mental machine model.It should also be noted that this task (i.e., judging machine behavior) does not correspond to engineers' common, collaborative design activities.However, we chose this task as it poses the same question to both disciplines, thereby making it possible to investigate differences in mental models that are not just an inevitable consequence of performing different subtasks during the elicitation procedure.We used an open concept mapping task for representing the mental models, meaning that neither content nor structure of the map was predefined.This open approach was chosen for two reasons.First, the very aim of this study was to accurately represent mental models to identify similarities and differences between the two engineering disciplines without imposing a certain structure or content on participants' mental models.Second, since there were no previous studies comparing mental models between automation and mechanical engineers (let alone in the context of a packaging machine), there was no set of suitable concepts or relations to draw on.The resulting concept maps were analyzed quantitatively as well as qualitatively and compared between automation and mechanical engineers.
Due to the exploratory nature of the study, no specific hypotheses were formulated.However, we anticipated disciplinary differences in the mental models that are in accordance with the discipline-specific tasks of automation and mechanical engineers in the context of designing packaging machines.More specifically, we expected automation engineers to focus on the interaction between processes within the current machine and other machines of the same production line, and on how these interactions are influenced by the general functioning and the specific measurements of sensors.
In contrast, we expected mechanical engineers to focus more on the functioning of distinct machine components and their condition.
Thus, automation engineers were expected to pay more attention to the abstract functions and processes of the machine, while mechanical engineers were expected to attend to rather specific physical aspects of machine functioning.In addition, we expected the mental models to include more concepts related to participants' own engineering discipline (i.e., for an automation engineer to focus more on the discipline of automation engineering and for a mechanical engineer to focus more on the discipline of mechanical engineering).

| Participants
Ten engineers (five automation engineers and five mechanical engineers) were recruited from a company that produces packaging machines for confectionery goods, all of whom had previous experience with the packaging machine used in the study.All participants were male and between 28 and 63 years old (M = 47.20;SD = 11.21).Their professional experience varied between 3 and 32 years (M = 20.00;SD = 9.89) and their tenure at the company between 2 and 32 years (M = 15.90;SD = 11.42).Participants reported that they are usually conducting between 0.4 and 10 process observations per year (M = 3.47; SD = 3.03).
The demographic information is summarized in Table 1.

| Materials
For the elicitation of mental models in the first interview, participants were located in the technical center of the company.Since participants stood directly in front of the packaging machine that was considered in the present study, a natural cue was provided.To allow the reader to better understand the data derived in this study, the structure and functioning of the packaging machine will briefly be described.This machine is used to wrap around 700 chocolate bars per minute in an envelope fold.To accomplish this purpose, the machine takes over chocolate bars from the previous production stage and transports them on conveyor belts.On these belts, the chocolate bars are accumulated (i.e., positioned side by side) and then separated again.During the separation process, the bars need to be positioned in a specific manner so that the machine can wrap them without destroying them.Before the actual wrapping takes place, the packing material (usually consisting of aluminum foil or cellulose film) also has to be fed to the machine.The packing material is unwound from large reels, but before it can be used to wrap the chocolate bars, it has to be cut into small segments.Then, one chocolate bar and one packing material segment are injected into the packing head that completes the folding in several stations.Finally, correctly wrapped products are discharged and transported to the next production stage, while faulty products are rejected.As all interviews were conducted during the COVID-19 pandemic, the authors were connected to the participants via video call.During the first interview, participants were equipped with a mobile phone and filmed the specific areas and parts of the machine they attended to.The second interview was conducted via video call as well, but participants were either on-site or at home and used their computers.All interviews were recorded with participants' consent.

| Procedure
First, a semi-structured interview was conducted by the authors with each participant separately between October 2020 and March 2021.
After demographic data were collected, the participant stood in front of the packaging machine and was asked to imagine he was at an actual production hall where this machine was running.His task was to give the customer an assessment of the process behavior of the machine.The interviewers also provided some information about the production environment (e.g., that a storage system automatically supplied the packaging machine with chocolate bars).Each participant was then asked to freely talk about what he would examine and how he would proceed to evaluate the process behavior.The interviewers interrupted the participant as little as possible and only if there were any comprehension issues or need for more detailed information (e.g., about the conditions under which a certain check would be carried out).If the participant stopped talking, the interviewers asked whether there was anything else he would examine, or if he would have been able to give the customer an assessment of the process behavior of the machine after having checked everything that he had talked about.When the participant confirmed this, the interviewers asked him to approximate how often he had to evaluate the process behavior of a machine as part of his typical work.The duration of the first interview varied considerably between 10 and 65 min, with the average interview lasting about 27 min.
From the interview recordings, transcripts were created and used to extract concepts as well as relations between those concepts.This second interview was conducted about 1-2 weeks after the first one.Each participant was informed that concepts could be added or discarded at any time and was asked to report any changes he would like to make regarding the content or structure of the concept map.The concept map was then shared via screen sharing and discussed consecutively.Before proceeding from one branch to the next, the interviewers explicitly asked whether the participant would like to make any changes or add new concepts.After the entire concept map had been reviewed and the participant had approved of the whole concept map, the interview was concluded.
The duration of the second interview varied even more than that of the first, with the shortest interview lasting 35 min and the longest lasting 154 min.On average, the second interview lasted about 83 min.
At the end of the data collection process, the validated concept maps were reviewed one last time to ensure comparability.This included some minor changes made by the authors, such as aligning the terms used to describe concepts or relations, and specifying these descriptions using the interview recordings.All concept maps are available at the Open Science Framework: https://osf.io/5e2b9/

| Analyses
Several analyses were conducted to assess the contents of the concept maps and will briefly be described next.However, it is important to note that due to the exploratory nature of this study, analyses were not strictly pre-planned.If not otherwise specified, the reported parameters were calculated using IBM SPSS Statistics (version 26).Tests for statistical significance were not conducted due to the small sample size.The categorization schemes used to analyze participants' focus on different abstraction levels and discipline contents are also available at the Open Science Framework: https:// osf.io/5e2b9/

| Focus on different levels of abstraction
To examine whether automation and mechanical engineers differed regarding the proportion of concepts on different levels of abstraction, the abstraction hierarchy (Rasmussen, 1985) was applied.Since this hierarchy represents a framework suitable to describe different types of technical systems, the number of levels as well as the specific contents on each level depend on the domain being modeled (Naikar et al., 2005).Table 2 contains the description of the packaging machine used for the present study in terms of the five original levels of abstraction.As the abstraction hierarchy is meant to describe a system independent of particular situations or faults, neither specific fault scenarios nor actions of operators, technicians, or participants themselves were included in this description.The system boundaries were set to exclude other machines of the production line as well as environmental factors (e.g., sunlight exposure or the temperature in the production hall).
All concepts were categorized as belonging to one of the five levels of abstraction, first by both authors together and a second time by a student assistant who had previously worked with the abstraction hierarchy but who had not taken part in any of the interviews conducted for the present study.Overall, 87.24% of all concepts were categorized in agreement.Incongruent categorizations were resolved for all cases through discussion.

| Focus on the discipline of automation versus mechanical engineering
To test whether automation and mechanical engineers differed with regard to their focus on their own versus the respective other discipline, a second categorization scheme was developed together with two mechanical engineers participating in the study.All concepts were categorized as predominantly belonging to either one discipline (automation or mechanical engineering), to both disciplines, or to neither discipline (see Table 3).While almost none of the concepts are exclusively relevant to one discipline or the other, some concepts influence one discipline more than the other or are influenced by one discipline more than the other.Therefore, the categorization of a concept as predominantly belonging to the discipline of mechanical engineering does not mean that there are no contact points to automation engineering, and vice versa.The system boundaries were set analogous to those used for the analysis of abstraction levels, with the addition that products and packing material were not categorized.
The second categorization scheme was applied by both authors independently, leading to an interrater agreement of 88.41%.
Incongruent categorizations were again resolved for all cases through discussion.

| RESULTS
Before reporting the results of the analyses described beforehand, some general insights into the structure and contents of participants' concept maps will be provided.The final concept maps contained an average of 58.60 concepts (SD = 19.19)and 68.00 links (SD = 22.66) for automation engineers, and 100.00 concepts (SD = 65.39) and 112.60 links (SD = 73.07)for mechanical engineers.The higher number of concepts and links in mechanical engineers' maps was mainly caused by two out of the five mechanical engineers (see Figure 1 for the number of concepts in each individual concept map).Overall, a large interindividual variance was observed.The smallest map contained 31 concepts and 37 links, while the largest map contained 189 concepts and 214 links.For illustration purposes, both of these maps are contrasted in Figure 2.
T A B L E 2 Description of contents and examples for the different levels of abstraction.

Functional purpose
• Goals and goal states of the system (e.g., packaging 700 products per minute) • Quality requirements (e.g., high quality of folding and chocolate bar) • Unwanted states that should be prevented (e.g., cracks in chocolate bars, production stops)

Abstract function
• General tasks and machine processes that must be performed to reach the system goals (e.g., moving of products, joining of chocolate bars and packing material segments, automated control of the engine)

Generalized function
• Specific functions realizing the abstract functions in the current machine (e.g., product accumulation, separating the packing material by cutting) • Descriptions of optimal functioning or malfunctioning (e.g., steady product flow, detection of products, piling up of chocolate bars)

Physical function
• Physical components carrying out the generalized functions (e.g., product feed, packing head, accumulation belt, print image centering sensor) • Products and packing material (e.g., chocolate bars, wrapping foil)

Physical form
• States of products, packing material, or machine components (e.g., scratches, wrinkles, indentations, missing screws) • Measurements and sensory perceptions representing system states (e.g., measured position of the dancing arm, vibrations of the engine) T A B L E 3 Description of contents and examples for the discipline-related categories.

Automation engineering
• Components relevant for or mainly affected by automated control processes (e.g., sensors, electric cabinet, dancing arm) • Processes regulated by automated control and their correct functioning (e.g., product accumulation, gaps between products, machine speed) • Electronic signals (e.g., sensor signals) • Electronic settings (e.g., zero point of basic machine)

Mechanical engineering
• Mechanical components and processes that remain mainly unaffected by automated control processes (e.g., packing head, protective hoods, injection, folding process) • Condition of machine components (e.g., maintenance condition, wear and tear, belt tension, temperature) • Product behavior mainly affected by mechanical components and processes (e.g., chocolate bars positioned at a right angle on the accumulation belt)

Both disciplines
• System states that affect or that are influenced by automated control as well as mechanical processes (e.g., product abrasion, rejection of faulty products, movement of products, machine stops, packing material change) • Quality requirements and indicators (e.g., folding quality, centering of the print image, fractured chocolate bars)

Neither discipline
• Concepts outside of the system boundaries (e.g., environmental factors, operators, using the handwheel) • Areas of the machine that are not further specified (e.g., product feed, packing material unwinding, packing station) SCHMIDT and MÜLLER | 527 Regarding the concept map contents, several topics occurred across concept maps and disciplines: (a) product quality, (b) steps of the packaging process, (c) machine condition, and (d) long-term behavior of the machine.The proportion of concepts associated with each of these topics, however, differed between the disciplines (see Table 4).Automation engineers' concept maps contained more concepts related to the packing material unwinding and packing material change, whereas mechanical engineers' concept maps contained more concepts related to the processes of folding and discharging, as well as the cleaning and maintenance condition of the machine.

| Focus on different levels of abstraction
The categorization of concepts as belonging to one of the levels of the abstraction hierarchy revealed differences between automation and mechanical engineers' concept maps on the levels of abstract function, generalized function, and physical form (see Figure 3).More specifically, automation engineers' maps contained a higher percentage of concepts on the levels of abstract function and generalized function, showing that they focused more on the functional aspects of the machine (e.g., feeding process or product accumulation).
Conversely, mechanical engineers' concept maps contained a higher percentage of concepts on the level of physical form (e.g., wear and tear or cleanliness of specific machine components).The percentages of concepts on the levels of functional purpose and physical function F G U R E 1 Number of concepts in participants' maps.
F I U R E 2 Examples of two concept maps.To provide a visual impression of the concept maps resulting from participants' descriptions, the largest as well as the smallest concept map are contrasted.Readable versions of each concept map are provided at https://osf.io/5e2b9/.
were comparable for automation and mechanical engineers' maps.
These concepts described the overall goals of the packaging machine (e.g., producing high-quality goods and preventing production stops) and the physical components of the machine (e.g., product feed area or specific sensors).Interestingly, differences between the two disciplines not only arose regarding the proportions of concepts on the different levels of abstraction but also regarding the contents that were most frequently mentioned on each level (see Table 5).
Automation engineers showed a clear focus on automated functions and the components needed to realize these functions.Mechanical engineers, on the other hand, represented automated and mechanical processes as well as electronic and mechanical components.

| Focus on the discipline of automation versus mechanical engineering
The categorization of concepts as predominantly belonging to the discipline of automation engineering, mechanical engineering, to both, or to neither discipline revealed that automation engineers' maps contained a higher percentage of concepts relevant to their  F I G U R E 3 Mean percentage of concepts on each level of abstraction, with error bars representing standard errors of the mean.
T A B L E 5 Contents that were mentioned most frequently on the different levels of abstraction (starting with most frequent in each cell).

Level of abstraction engineers Mechanical engineers
Functional purpose products, folding quality Quality of chocolate quality of packing material, machine stops

| What is the content of automation and mechanical engineers' concept maps?
Several disciplinary differences became apparent in the concept maps of automation and mechanical engineers who evaluated the process behavior of a packaging machine.Automation engineers generated smaller concept maps with fewer concepts and links, and they mainly focused on automated processes, especially on the processes of feeding products and packing material to the machine.That is, for the most part, they observed the processes leading up to the packaging process, but then stopped once they reached that process.Hence, when only looking at automation engineers' concept maps, one could easily get the impression that the actual packaging process is relatively unimportant for the process behavior of the packaging machine.This is in line with our expectations and corresponds to automation engineers' task of compensating for variations in the delivery of products and packing material to ensure a steady supply, thereby allowing the machine to operate at a consistently high speed.
Their focus on automated processes was confirmed by examining the levels of abstraction each concept map.Compared to mechanical engineers, automation used a higher proportion of concepts that dealt with general machine processes (i.e., level of abstract function) and whether the specific functional worked properly (i.e., level generalized function).
On the lower levels of abstraction, automation engineers focused on electronic machine such as sensors, sensor signals, and electronic machine settings.Thus, they almost considered those physical components that were needed to ensure the correct functioning of automated processes, while largely disregarding mechanical processes.Similarly, more than half of the concepts in automation engineers' maps were related to their own discipline (i.e., automated control processes and their functioning).In contrast, only 10% were concerned with those processes, components, and product behavior that remain largely unaffected by automated control processes.In sum, it can be stated that when evaluating the process behavior of the machine, automation engineers assumed a quite narrow focus.
For mechanical engineers, a different picture emerges.On average, mechanical engineers' concept maps contained a higher number of concepts and links (even though this difference was largely driven by two participants).Mechanical engineers showed a broader focus than automation engineers in the sense that they considered all machine processes, albeit to differing extents.One process only considered by mechanical engineers was product discharging (i.e., transferring wrapped products from the current machine to the next production step) which is, in fact, largely determined by mechanical components.Two other aspects that were more prevalent in mechanical engineers' concept maps were the cleaning and maintenance condition of the machine.This is Percentage of concepts related to their own, the respective other, or both disciplines, with error bars representing standard errors of the mean.
interesting because the causes for these states can be found in both mechanical and automated processes.For instance, chocolate residue can accumulate on the guideways or belts (both mechanical components), but it may do so either because products grind along a projecting edge between two guideways (i.e., caused by mechanical settings) or because the belt speed is too high, leading products to collide and leave chocolate powder on the belt and guideways (i.e., caused by settings of the automation algorithm).It seems that mechanical engineers were more aware of the fact that the condition of machine components can be a valuable source of information for assessing how the process behavior of a machine is influenced by both mechanical and automated processes.The analysis of levels of abstraction confirmed the focus on the condition of machine components (i.e., more concepts on lower levels).Since the machine consists of many different components, this led to mechanical engineers' concept maps being more branched than those of automation engineers.The proceeding and results for this additional structural analysis were not reported here but are available at the Open Science Framework: https://osf.io/5e2b9/.In addition, mechanical engineers did not focus as much on their own discipline as did automation engineers.Almost half of concepts in engineers' concept maps were related to both disciplines, and as much as 20% were related to components and processes falling into the area of expertise of an automation engineer (remember that only 10% of concepts in automation engineers' maps were related to mechanical engineering).In sum, mechanical engineers had a broader focus when evaluating the process behavior of the packaging machine, meaning that they considered not only mechanical, but also automated processes.This suggests that they were more aware of the fact that both mechanical and automated processes are tightly coupled to each other and to the process behavior of the machine.

| How can differences between automation and mechanical engineers' mental models be explained?
The first reason can be found in examining the development of collaboration between the two disciplines.Historically speaking, machines used to be not automated at all, and were therefore only developed by mechanical engineers.With advances in automation technology, individual process steps became more and more automated, and automation engineers became increasingly important for developing packaging machines.In the present sample, this historical development still shapes the collaboration between the two disciplines in the way that the first phases of the design process are mainly carried out by mechanical engineers, whereas automation engineers join in later.Thus, when making choices regarding machine construction, mechanical engineers have to keep in mind how automated processes may influence mechanical processes and components, and vice versa.If mechanical engineers are not able to accurately predict the consequences of their design choices on the automation of processes, the machine cannot be automated optimally in later phases of the design process.An automation engineer's influence on decisions made early during the design process is rather limited.This could explain why in the present sample, automation engineers largely disregarded the mechanical aspects of the packaging machine.In addition, in the company participants were recruited from, the responsibility for a packaging machine as a whole lies in the hands of mechanical engineers, whereas automation engineers are only responsible for "their share" of the machine, namely the automated processes.This matches the status quo of a sequential mechatronic engineering process (Kübler et al., 2018).
The second reason specifically relates to the typical tasks of automation and mechanical engineers, and the different levels of abstraction needed to carry out these tasks.Automation engineers accompany the commissioning process of a new packaging machine after it has been delivered to a customer.This is because the software regulating the automated processes can be prepared to a certain extent beforehand, but the finetuning has to be carried out under real production conditions.Similarly, when a machine is not functioning optimally, automation engineers usually travel to the customer and adjust the automation software to better match the production conditions.Therefore, automation engineers must represent the goals of the system and how the different functions work together to achieve these goals.As long as the mechanical processes work correctly, their physical implementation does not have to be represented in an automation engineers' mental model.If faults occur on these lower levels of abstraction (e.g., machine components being damaged or not working properly), mechanical engineers are typically called to examine the machine.In order for them to identify the causes of these faults, it is not sufficient to only represent machine components and their condition (i.e., lower levels of abstraction), because they may be influenced by more than one function on a higher level of abstraction.The concept maps in the present study suggest that mechanical engineers are better able to represent all levels of abstraction, because they know more about the physical components of the machine and how they relate to system functioning.Automation engineers can represent the functions themselves and the implementation of automated functions, but not mechanical functions and their implementation.

| How can shared mental models enhance the Systems Engineering process?
The ability to integrate perspectives from multiple disciplines poses a central challenge for the engineering of complex production systems (Feichtinger et al., 2022).One solution that is frequently proposed is exchanging the sequential mechatronic approach for a model-based Systems Engineering approach (Kübler et al., 2018).Instead of different disciplines constructing certain parts of the system separately from each other, this approach aims to use a common system model from the beginning of the process.The mental representation of this common system model corresponds to the shared mental model of the engineering team.However, is it necessary that the mental system model is the same for all team members?
Overlaps between mental models are typically interpreted as enabling team members to integrate their respective contributions, and many studies argue that mental model similarity is a key requirement for team success (e.g., Lim & Klein, 2006;Mathieu et al., 2000;Nakarada-Kordic et al., 2016).Yet, meta-analytic evidence supports the notion that mental models do not necessarily need to be similar, but they do need to be compatible with each other (DeChurch & Mesmer-Magnus, 2010a).In the context of Systems Engineering, this would require a shared language and the integration of technical artifacts from different disciplines (Kübler et al., 2018).
The present study has shown that the abstraction hierarchy can be used to depict the perspectives of different engineering disciplines in one unifying framework.Moreover, a myriad of studies has successfully used the abstraction hierarchy to describe varying technical systems (e.g., Bennett et al., 2023;Friedrich et al., 2022;Rouse et al., 2017;St-Maurice & Burns, 2017).We therefore argue that the abstraction hierarchy could be used to guide the modeling activities in Systems Engineering.Other technologies, such as the description of production environments with ontologies, may also be able to provide a common ground for integrating information from different perspectives (Müller et al., 2021).
5.4 | How did the methods applied influence the type of mental model measured?
Since there are no standard methods for eliciting, representing, and analyzing mental models, researchers may have to develop methods that are appropriate for their specific research question and situation.
On the one hand, this yields great potential to accurately reflect mental models as context-dependent knowledge structures, but on the other hand, it calls for caution and a self-critical analysis of one's own approach.In this regard, we need to consider the following questions: Did the methods applied in the present study actually elicit and represent the mental models of our participants?And if they did: Which aspects of a mental model were covered and which were not?
What might the mental models have looked like if other methods of elicitation and representation had been used instead?
To answer the question of whether the methods used here actually allowed for the elicitation and representation of mental models, we will revisit the definition of mental models that was introduced at the beginning of this article.According to Rouse and Morris (1986), mental models are organized knowledge structures used to understand and predict system behavior.Since the task used for mental model elicitation required participants to report what they thought to be relevant to the functioning of the machine, the contents elicited should inherently be related to understanding and predicting system behavior.The structural aspect of mental models was covered by choosing concept maps as a representation method.
At the beginning of this article, the previously stated definition was expanded by characterizing mental models as dynamic.Following the reasoning of Jones et al. (2011), dynamic knowledge can be used for mental simulation, includes causal relations, and changes over time.
Since some concept maps included If-then relations and causal relations, they do in fact seem to represent dynamic knowledge.
While the present study was not designed to reveal changes in mental models over time, the concept maps were clearly influenced by participants' previous experience.This became apparent when participants reported checking specific "problematic areas" of the machine, namely processes or parts that had contributed to malfunctions or deviations in the past.It is therefore plausible to assume that future experiences would be incorporated into the mental models as well.One criticism about the operationalization of mental models used here might be that participants were asked to talk about what they would do to evaluate the process behavior of the machine (i.e., describing a procedure) instead of simply asking them about influences on the process behavior (i.e., describing relevant variables and their relations).However, other studies examining mental models have also asked participants to indicate their approach to a given task (e.g., Blondon et al., 2017;Loch et al., 2019).Depending on the task and on how familiar participants are with it, they may find it easier to report their proceeding instead In the present study, participants reported their individual approaches to solving a specific task and therefore, the mental models would most likely represent task models.Since the task focused on observing and checking the process behavior of the machine, it is possible that participants did not include aspects that they consider relevant to the process behavior but that might just not be observable or measurable.Other aspects might not have been included because they would be covered by another colleague and hence, be part of the team model.
All in all, the mental model elicited in the present study should be understood as a mental model of the task.As the elicitation method specifically focused on observing and checking the process behavior of the machine, it is likely that the mental model largely contains information about known and measurable relations between process, machine, and environment.et al., 2001).It is therefore plausible to assume that differences between automation and mechanical engineers would not have been as pronounced if a more constrained concept mapping task had been applied.

| Limitations and avenues for future research
While some of the conceptual limitations regarding mental model measurement have already been discussed in the previous section, some methodological limitations also need to be considered.First, the study was conducted with a small sample of five automation and five mechanical engineers.Since one main objective of this study was the assessment and analysis of mental models in a realistic work context, all participating experts had to be familiar with this context, namely one specific type of packaging machine.In the company the participants were recruited from, no more experts met this criterion and therefore, the sample size could not be increased further.
Nevertheless, the present study is based on a considerable amount of data, as a total of 793 concepts were extracted from the expert interviews and subsequently analyzed in depth.
Second, a large interindividual variability (in terms of interview duration and concept map scope) was observed, most likely because the task used for eliciting and representing mental models had only few constraints.While all of the engineers participating in the present study had some experience with the specific packaging machine, they still differed regarding the extent of work they had put into this machine, the extent to which they had observed it in real production contexts, and the extent to which they had been responsible for its overall development.Thus, it is reasonable to assume that at least some of the observed variability represents true variability in our participants' mental models.Based on the data presented here, it is, however, not possible to rule out that these differences might also have been influenced by other participant characteristics, such as general response tendencies or the overall interest in the study.In addition, it is impossible to differentiate between knowledge and awareness of knowledge.For instance, a participant might not report that he would check the packing material change because he may not think that the packing material change is relevant for the process behavior.However, it could also be that the participant simply does not think of it at this moment, or that he does not know how exactly the packing material change is related to the process behavior and therefore, he does not mention it at all.To differentiate between knowledge and awareness of knowledge, future studies could apply a more standardized approach.For example, participants could be provided with different functions and components of the machine and be asked about their relevance to system functioning.While this approach would presumably lead to less interindividual variability, the resulting mental models would not represent what participants independently perceive to be relevant for process behavior.
Third, the present study did not include any measurement of performance and therefore cannot answer the question of which parts of a mental model are most important for accurately evaluating the process behavior of the packaging machine.Similarly, no measure of mental model accuracy was included.Even though all participants were highly qualified engineers (albeit with varying experience), it is possible that the observations they reported were differing in their meaningfulness for the process behavior of the machine.Nevertheless, capturing the content of mental models in detail allows us to establish reasonable assumptions about the expert's performance.
As, for example, automation engineers in our sample did not pay attention to the packaging process itself, we can assume that they would have more trouble identifying a fault in this process step.
Similar hypotheses can be derived from the mental models and tested in future studies.
Finally, even though the experts were engineers designing packaging machines, they did not carry out a design task in the present study but instead evaluated the process behavior of an existing machine.In real production contexts, these influences exceed the machine itself and also include upstream and downstream process steps, environmental conditions, and operator behaviors.
These aspects are highly relevant to the design of socio-technical systems (Kozlowski et al., 2015) and should therefore be considered in future studies examining the relation between mental models and system design.More specifically, it would be important to examine whether designers' mental models include other agents in Joint Cognitive Systems, such as operators and technicians, their cooperation with each other, and with the technical system.

| CONCLUSION
In the present study, two different disciplines-automation and mechanical engineering-were compared to identify and characterize differences in mental model content.Experts from automation and mechanical engineering were asked to evaluate the process behavior of a machine which is influenced by both mechanical and electronical aspects.The people evaluating it should ideally know about all of these influences, independent of their own disciplinary background.
While the mechanical engineers from our sample did in fact apply a mechatronical approach, the automation engineers primarily focused on electronical influences.In addition, automation engineers focused on higher levels of abstraction, while mechanical engineers focused on lower levels of abstraction.We argue that this finding can plausibly be explained by considering the typical work tasks in both disciplines and therefore, that the differences found in this study likely represent true disciplinary differences between automation and mechanical engineers.We also found large differences regarding the overall size of the mental models, suggesting that some participants had a lot more knowledge about the process behavior than others.
Previous research shows that successful teams use transactive memory systems for storing and retrieving their knowledge (Yan et al., 2021), and externalizing knowledge structures can be a first step toward establishing such systems.
To ensure that team members' communication and work are based on common ground, interventions such as cross-training (Cooke et al., 2003;Kozlowski & Ilgen, 2006;Marks et al., 2002), question-asking (Cash et al., 2017)  While mental models should be shared among team members to some extent, we also postulate that a complete overlap of mental models is not feasible for most knowledge-oriented teams, especially those composed of people from different disciplines.Hence, team members must develop skills that allow them to communicate and integrate their contributions across disciplinary boundaries.To develop tools for this integration process, it is not sufficient to rely on technological advances, such as the development of specific programming languages or simulation tools.Instead, we need to understand the contents that team members communicate about (e.g., contents that are specific to one's own discipline) and which levels of abstraction are used to do so (e.g., predominantly high levels of abstraction compared to low levels of abstraction).Examining different disciplinary perspectives and describing them in a shared framework is the first step toward integrating discipline-specific expertise for complex problem solving.
Concept maps were originally constructed using the open-source program VUE(Tufts University, 2015)  and later also transferred to yEd(yWorks GmbH, n.d.).There was no predetermined set of concepts or relations to be extracted from the interviews.For every observation reported by participants, a new concept was added to their map.If several observations dealt with the same topic, they were subsumed into one branch.The wording of both concepts and links was retained from participants' utterings, thereby reducing the researchers' influence on the concept maps.To ensure that the concept maps constructed by the researchers accurately represented participants' observations and checks of machine functioning, a validation interview was conducted with each participant.
own discipline than did mechanical engineers' maps (M = 54.91,SD = 15.60 for automation engineers; M = 35.41,SD = 13.64 for mechanical engineers; see Figure 4).Respectively, automation engineers' maps contained a lower percentage of concepts relevant to the other discipline (M = 11.04,SD = 3.36 for automation engineers; M = 21.04,SD = 10.98 for mechanical engineers).The T A B L E 4 Mean percentage of concepts concerned with different topics.
Abstract function Packing material change, automated control processes Packaging process, process behavior of packing material, long-time behavior of machine Generalized function Product accumulation, functioning of sensors, packing material unwinding Product accumulation, material unwinding, process Physical function Electronic components, areas of the machine Mechanical components, areas the machine, components Physical form Sensor signals, electronic settings, maintenance condition Maintenance condition, abrasion/cleanliness, mechanical settings SCHMIDT MÜLLER | 529 proportion of concepts relevant to both disciplines was comparable between automation and mechanical engineers' concept maps (M = 34.05,SD = 13.96 for automation engineers; M = 43.56,SD = 7.38 for mechanical engineers).5 | DISCUSSION How do mental models differ between the members of interdisciplinary teams that regularly engage in knowledge-intensive, creative collaboration?The goal of the present study was to scrutinize the mental model contents of automation and mechanical engineers whose job it is to jointly develop and produce packaging machines.Previous studies assessing mental models in interdisciplinary work teams have mainly focused on determining the amount of sharedness between individuals' mental models.In contrast, the present study examined what contents are actually represented.To this end, an exploratory approach was chosen: Mental models were elicited via semi-structured interviews in which five automation engineers and five mechanical engineers were asked to evaluate the process behavior of a packaging machine for chocolate bars.Mental models were then represented using an open concept mapping task.Finally, the contents of these concept maps were compared between the two disciplines.In the first two discussion sections, we will briefly summarize the results and relate them to typical tasks of automation and mechanical engineers, respectively.Next, we will reflect on how shared mental models can aid the Systems Engineering process, and on the influence of our research methods on the results.We close the discussion by considering the limitations of the present study and deriving avenues for future research.
of describing what variables are relevant and how they are related in a rather abstract way.In sum, the mental models elicited in the present study appear to correspond to the understanding of mental models applied here.This ensues the second question: Which aspects of a mental model were covered and which were not?Badke-Schaub et al. (2007) introduced a typology containing five types of mental models specifically for design teams: (a) a task model containing information about the task as well as the equipment and technologies used to carry out this task, (b) a process model containing information about how the task should be handled in the team (e.g., problem solving strategies), (c) a team model containing information about other team members' abilities and responsibilities, (d) a competence model that is based on the first three models and refers to the perceived competence of the whole team, and (e) a context model that contains background knowledge (e.g., organizational aspects of the company).
and use of the cognitive collaborative model(DeFranco et al., 2011) can be applied.Even though the present study did not aim to develop an intervention for improving mental model sharing, we have found that the data are a starting point for further work in this direction.More specifically, we have integrated the representations of individual team members' mental models into a sum model that shows all aspects mentioned by the experts, independent of their discipline (available at https://osf.io/5e2b9/).In our cooperation with the engineering company, this sum model is currently developed further to represent interactions between the packaging machine and the respective production context.Such a model may not only be useful for fostering understanding between automation and mechanical engineers designing new packaging machines, but also between departments, such as research and development, service and maintenance, or sales.
Demographic and job-related variables.
Finally, various methods for mental model elicitation and representation are available and therefore, the mental models in this study might have looked different if other methods had been applied.