Model-Based Collaborative Design in Engineering

Model-Based Collaborative Design
in Engineering
Hilda Tellio˘glu
Institute of Design and Assessment of Technology
Vienna University of Technology, Austria
[email protected]
WWW home page: http://media.tuwien.ac.at/index.php?id=7
Abstract. This paper is about understanding and analysis of ways
of model-based collaborative design in engineering. Models help engineers in overcoming complexities and to create a common understanding about processes and products. Organizational, commercial, technical
and process-based circumstances have impact on models and modeling
practices. Based on ethnographic studies in a distributed real work environment, several modeling practices are identified and described: 1)
modeling to visualize several important issues, 2) modeling to support
collaboration and coordination, 3) modeling to support system engineering, and 4) models triggering automated actions. Before concluding the
paper, we discuss some interesting points we found in our investigations
and try to provide a base for a collaborative engineering approach.
Keywords: Collaborative design, visualization of cooperative work, cooperative engineering.
1
Introduction
System engineering is a collaborative process with several interdependencies between tasks and participants. It is embedded in organizational, economic, technical and collaborative context. How to deal with the complexity of interdependent
tasks can be supported by several mechanisms. Such support for core engineering activities can either be provided by integrated development environments
or by isolated tools like editors, compilers, linkers, test scripts, messaging and
modeling tools, or common information spaces. Additionally, certain standards,
conventions, notations or rules can be established to unify design practices and
help to communicate design principles and values within and across teams. The
impact of organizational settings like the size of the design team, the size of the
project, structures for decision making in an enterprise, agreements with and
distribution of work among partners, etc., are important issues to consider in
introducing modeling into engineering.
In a European STREP project called MAPPER1 (Model-based Adaptive
Product and Process Engineering) (IST-016527) we2 investigated technological
and methodological possibilities to support designers in collaborative engineering, which involved participative engineering methodologies to enable joint product and process design, interdisciplinary and inter-organizational collaboration
throughout multiple product life cycles.
We carried out an ethnographic study[6] in one of the industrial partners, we
call in this paper Beta. We visited Beta three times to observe participatory the
workplaces, meetings and design sessions, what we recorded as video and audio
files. We interviewed in-depth some the key actors. Additionally, we gathered and
analyzed Beta’s artifacts like documents, source code, test reports, simulation
results, project plans, charts, organization diagrams, and models of different
kinds. This qualitative study resulted among others in field visit and validation
reports [5].
Beta provides IP (Intellectual Property) cores since 1997, VHDL and Verilog
model development services as well as hardware and software development for
microcontroller-based systems. In our ethnographic study at Beta, we identified
the problem of missing of a radically new collaborative engineering approach that
engineers need to face challenges in design and manufacturing of modern electronic systems in respect to their complexity and constraints in time-to-market.
In this paper we suggest a solution space for Beta by showing the role of models
and modeling to develop a different approach to collaborative engineering.
In the next section we will describe modeling in collaborative design by illustrating four different types of models used at Beta: 1) models to visualize several
important issues, 2) models to support collaboration and coordination, 3) models to support system engineering, and 4) models triggering automated actions.
Before concluding the paper, we discuss some interesting points we identified in
our analysis.
2
Models in Collaborative Design
By definition, a model is a representation of reality that helps to better focus
on specific aspects of the considered reality. Models are both descriptive and
generative in the sense that they describe what is observed by the model creator
and that they support the construction or modification of a construct in the
reality. When engineering processes are model driven, models are used as primary
artifacts throughout the whole life cycle.
Besides the research on enterprise modeling [4], some research has been done
about the different levels of models created in manufacturing [9]. They distinguished between paper-based, table-based, non-executable and executable models. They showed that it is possible to integrate product models with process
models, however due their complexity it is not always easy to deal with them
1
2
http://mapper.eu.org/
The project group consisted of Hilda Tellio˘
glu, Ina Wagner, Gianni Jacucci and Gian
Marco Campagnolo.
during daily work. Sometime it is not enough to have only visualizations of
objects-in-design. So, a mechanism of interaction must be established around
common models to facilitate collaborative design and engineering. Active knowledge models (AKM) try to implement this requirement.3 They are based on user
knowledge about business realities, which is not always the case in other conventional model-driven architectures. In this paper, we do not focus on knowledge
management features of AKM, but rather on their active use by collaborating
actors. Active models can be actively used during the operation of the system.
The representation of the model is available to users at runtime. They are dynamic and reconfigurable, so tailorable for their users, and influence the behavior
of the underlying computerized system [2]. AKM can also be used as executable
formal models to manage design workflows. This supports (semi-)automation of
design processes when executed.
In collaborative engineering processes at Beta we could identify and study
the following types of models:
– Models to visualize several issues that are relevant for collaboration, like
the organizational and temporal structure of a project, the collaborating
partners and their suppliers, roles and responsibilities in these collaborations.
– Models to support collaboration and coordination between actors involved in
the engineering process: These formal or informal executable models mainly
created by Beta’s employees build the base of workflow systems established
between distributed groups.
– Models to support system engineering which are created during the engineering process: These are formal, non-executable models, supported by a range
of computer systems. They have been established in design, development
and manufacturing for a long time.
– Models triggering automated actions during the engineering process, like simulation and testing: These formal executable models help to reduce errors
in engineering, enable consistent reproduction of tests and simulations by
avoiding human error. By enabling remote access to collaborators, articulation and coordination of work are supported.
In the following sections we would like to show some ethnographic evidence
to these different types of models.
2.1
Models to visualize several issues
Before Beta and its partners could start modeling their cooperation in USB design, they needed to think about several other issues. First of all, they tried
to model their own company with human and non-human resources to achieve
a common understanding of their organizational structure. The main tool the
product manager at Beta was using to model the organization was a mind
3
AKM is based on a visual externalization of knowledge model of enterprise aspects
and views that can be operated on, viewed, analyzed, simulated, and executed by
authorized users.
mapper. Some organizational charts were connected to mind maps to create an
overview of issues related to organizational structure like relevant information
about products, people, customers or decisions made.
With an organizational design game, we4 managed to move the employees
from marketing and engineering departments Beta to think about their organization and about its improvement. We setup a workshop for two days where
two groups had the opportunity to model the company in several steps. For the
workshop we had chosen three important questions (as results of our analysis of
ethnographic study earlier at Beta [5]: How to acquire a business management
culture and construct a community of practice? How to change from being sophisticated contractors to a profitable brand? How to transfer knowledge and
design to the market?
By using an organizational game kit, Beta’s employees tried to build their
organization out of building blocks of different colors and shapes. Additionally
they used figurines, stickers, and pencils to enhance and modify the shared representation of the company. Two groups delivered completely different models
(Figure 1).
Fig. 1: Differing organizational models created by using organizational game kit: On
the left much more hierarchical with the CEO on top (created by engineers), on the
right much more networked, flat but with more difficulties and gaps in communication
(created by marketing people).
2.2
Models to support collaboration and coordination
After an initial, informal specification of the USB IP component design that was
agreed upon by cooperating companies and their customers, each participant
firm defined its design workflows as AKM with IDEF5 notation. Besides showing the interfaces to other workflows, these AKM-based workflow spanned over
specification, development, verification, and product preparatory phases. Next,
4
5
The group was composed of Gianni Jacucci, Hilda Tellio˘
glu and Ina Wagner.
ICAM Definition Language.
actors responsible for particular design phases in the design flow were identified,
technologies for components manufacturing and tools to be used were decided.
The design flow represented as a visual model (Figure 2) comprises sets of
design tasks performed at three geographical locations, at A, B, C. The design object is a mixed-mode component. Design processes are split among the
team members, taking the engineering competences into account, in such way
that an analog design takes place at A, a digital design at B, and a board-level
testing at C. The model shows also a wide spectrum of information related to
the current shared product, namely information on: the internal organization of
involved companies (e.g., company structure, locations, human resources, staff
competence skills), the available IT infrastructure (e.g., design automation, administration, and office tools), the current project organization (e.g., project
responsibilities), the detailed structure of the common product, and the project
plan (e.g., management and design workflows). These details are not illustrated
in the figure.
Fig. 2: A view of a part of the design processes distributed into three locations (A, B,
C): AKM in IDEF notation of “Design and Verification” process.
2.3
Models to support system engineering
System engineers use several models to design their products by showing their
components, interfaces and data flows, to communicate open issues and important properties of product components, to discuss uncertain points of product
definition, to visualize the simulation results, and to show dependencies between
products or product parts. Engineering practices and tools used regularly shape
these models. Engineers at Beta used almost for everything mind mappers (Figure 3). Sometimes the product manager inserted AKM models to the mind maps.
This enabled easy access to model images within the project context.
Fig. 3: Mind maps created to model products by showing their main properties explicitly.
In case of misunderstandings or uncertainties, engineers were used to draw
a model of the object-in-attention on a flip chart or a pin wall. These ad-hoc
created models were temporal and not persistent. On the other hand, simulation
results were communicated within and across the teams. The results needed to be
very detailed and complete. They were analyzed, interpreted and then compared
with previous results, and used to improve the product design.
2.4
Models triggering automated actions
There were several workflow-based systems established at Beta. Firstly, they
used a platform called TRMS (Tool Registration and Management Services) to
support remote invocation of tasks embedded in sequential workflows [2]. We
found 18 workflows with five to six tasks each. The aim was to support distributed design between A, B, and C. Figure 4 shows an example flow with
TRMS. By selecting the buttons, processes could be started and repeated. Completed tasks were visualized as such, so that engineers were aware of the status
of the workflow execution.
Based on the process and organization models of collaborating partners A
and C, cooperation models were created. These were mainly AKM views showing
links between the tasks carried out at different sites.
Finally, they created configurable virtual workplaces (CVW) as model-based
work environments generated for specific users by considering their role and
cooperation paths to others in the project. Each user could access his or her
current tasks by using the CVW as an entry point (Figure 4, right).
3
Discussion
It is obvious that models can help engineers in design and production [3] [7] [8].
They visualize several issues like problems, misunderstandings, points of attention, responsibilities or task dependencies locally or globally in the network. They
Fig. 4: An example workflow with TRMS (left) and configurable virtual workplace
(CVW) as desktop for a user (right).
help engineers to overcome complexities, deal with complex processes and artifacts. This involves structuring and re-structuring, composing and decomposing,
creating overview and detailing, establishing stability (of concepts, structures,
processes, methods, approaches, features of products) and exploring new things
(like methods, tools, approaches, etc., otherwise no further development or innovation are possible).
Beta’s engineers started with modeling their own company to create a common understanding, then continued to link their tasks with processes of partners.
They have established workflows to support their collaboration, added detailed
product models to their workflows and based on that created automatically configurable virtual workplaces. All these models span from organizational, to commercial, technical, workflow- or coordination-related levels. By means of models,
Beta’s engineers tried to handle the complexity at these different levels.
These different types of models are complementing each other. They are applied at different points of time, they serve for different purposes, they do not
need to be deterministic, complete, or integrated. As system designers of modeling environments, we first have to understand when and why modeling is applied
by engineers. Ethnographic studies give us insights. Not everything in a work
environment can benefit from modeling and models. If we want to introduce
modeling into an engineering team, we have to answer the important question
of what to model in the first place.
In modeling, organizational principles and strategies guide the abstraction of
organizational entities (systems being modeled by abstraction, like products, organization of human resources, processes and interactions between units). Beta’s
engineers and marketing people were very much influenced by the current status
of the company at the market and in relation to its cooperating partners. This
could be observed in the organizational models created by using organizational
game kit.
Another influence on modeling is the way of thinking. Applying the objectoriented approach determines the way how objects and system actions are iden-
tified by modelers: For each of the identified objects computational objects can
be created. For each system action a symbolic operation can be defined. Organizational strategies can be concentrated on objects “viewing a large system as a
collection of distinct objects whose behaviors may change over time” or on “the
stream of information that flow in the system, much as an electrical engineer
views a signal-processing system” [1][p.218]. This shapes the structure of task
dependencies or work flows.
4
Conclusions
Design objects as we have seen in engineering of IP cores are complex, their
parameters are multifold, dependencies between parameters are temporal, sometimes they must be modified because of changes in some parameters or in
features of products. It is a dynamic process. A model is the right semantic
(re)presentational artifact for this type of complex relations.
Models used at Beta are of different types: executable or non-executable
AKM models, product models for simulation and testing, workflow models to
support collaboration between distributed design and production teams, mind
map models to support the re-organization of the enterprise, etc. They are all
necessary and needed for different purposes. Models help to capture organizational (organizational game kit, mind maps, organizational charts, AKMs), economic (product and process models with simulation support), technical (UML or
AKM product models, simulation models) and collaborative (workflows, CVWs,
TRMS workflows) context and to create a common understanding in and across
organizations. Identifying the sinful use of models at Beta and understanding
its impact on design processes brings us further in developing a new collaborative engineering method, which is based on models. Further work is needed
to create, document, and evaluate the collaborative methodology in engineering
environments.
References
1. Abelson, H., Sussman, G. J., Sussman, J.: Structure and Interpretation of Computer Programs.
MIT Press, 2nd Edition (1996)
2. Fras, P. et al.: Deliverable D15. Report on Collaborative Design Process Model, Analysis, and
Evaluation. Version 1, April 3rd (2008)
3. Curtis, B., Kellner, M.I., Over, J.: Process Modelling. Communications of the ACM, 35, 75–90
(1992)
4. Fox, M. S., Gruninger, M.: Enterprise Modeling. American Association for AI, 109–121(1998)
5. Jacucci, G., Tellioglu, H., Wagner I.: Report Field Visit at Evatronix. MAPPER, Model-based
Adaptive Product and Process Engineering, IST/NMP Project, 016527 (2005)
6. Jordan, B.: Ethnographic workplace studies and CSCW. International Conference on the Design
of Computer Supported Cooperative Work and Groupware Systems, Sch¨
arding, Austria (1993)
7. Kaindl, H., Carroll, J.M.: Symbolic Modelling in Practice. Communications of the ACM, Vol. 42,
28–30 (1999)
8. Tellio˘
glu, H., Campagnolo, G.M., Jacucci, G.: Use Context of Modelling in Model-Based Adaptive
Product and Process Engineering. Proceedings of the Sixth International Conference on Computer Science and Information Technologies, CSIT 2007, September 24-28, Yerevan, Armenia,
287–291 (2007)
9. Tellio˘
glu, H.: Practicing Modelling in Manufacturing. Proceedings of the International Conference
on Model Based Systems Engineering (MBSE’09), Herzeliya, Haifa, March 2-5 (2009)

Download Report