Airplane Design Process

Standard Part Selection

— Input to the OMG Workflow Evaluation

Workgroup —

Christoph Bussler
The Boeing Company — Applied Research and Technology
P. O. Box 3707, M/S 7L-70
Seattle, WA 98124 — 2207
U. S. A.

E-Mail: Christoph.Bussler@pss.boeing.com
Phone: [1] (425) 865 — 4576
Fax: [1] (425) 865 — 2964

18th February 1998

Introduction

Airplane design relies on standard parts. Instead of designing parts individually

according to his design needs, a design engineer is asked to reuse existing parts as
much as possible. This improves the overall airplane design process since standard
parts are readily available, are tested, are of high quality and easy to order from
suppliers. However, when designing a new airplane, when deriving a new model of a
base design or when re-designing an airplane based on a customer's requirements, the
situation might arise that no standard part is available which suits the specific
requirements. In this case either a new part has to be designed and built or an existing
standard part has to be modified.

The following process describes the selection of a standard part according to given
requirements. If the search fails, an exception process is started which results in a
new part, either as re-design or modification of an existing part or as a completely
new design.

The description of the process serves as input to OMG's workflow evaluation group
for assessing the current Workflow Facility submissions.

Basic Information System Infrastructure

It is assumed that two groups work together. One group consists of design engineers
who do airplane design. The other group is responsible for standard parts and consist
of standard part engineers (or standard engineers for short). Design engineers contact
the standard parts group to select standard parts, to ask for modification of parts or to
ask for the design of new standard parts.

Both groups run their own workflow system and it is assumed that both systems are
from different same vendors, i. e. they are heterogeneous with respect to each other.
Both WFMS are autonomously administered with the exception of common
workflow type and common workflow instance interfaces. Common type and
instance interfaces exist because certain workflow instances cross the group's WFMS
boundaries. A workflow instance which is started on one WFMS and continued on
another WFMS is called a distributed workflow instance.

The different portions of the type definition of distributed workflows are maintained
locally on those WFMS which can execute the respective parts of the distributed
workflow. The type definitions of distributed workflow instances depend on each
other in such a way that the change of one’s interface affects other workflow types. It
is assumed that the involved WFMS can notify each other about the type changes, i.
e. they are aware of each other not only on a workflow instance level but also on a
workflow type level.

The design data the design engineers work with and the standard parts data of the
standard parts group are partitioned. This means that each group maintains their data
locally within their own information infrastructure. Consequently, data which cross

2
 the group's boundaries through distributed workflows have to be "shipped" across the
groups by the WFMS or other mechanisms.

Standard Part Selection

When a design engineer is in need of a standard part, he discovers that as part of his
work. Since his design work takes place in context of a design workflow instance, the
discovery happens within one of his workflow steps. When he is in need of a
standard part, he dynamically (i. e. ad-hoc) creates a workflow step within the
standard parts group's WFMS to select a standard part. The ad-hoc creation is
necessary since a design engineer might be in need of a standard part at any time.
This requires that it must be possible to search for one at any time. The discovery of
such a need is not predictable, i. e. cannot be defined as a fixed portion of the overall
design workflow type.

Once the design engineer created the search step in the standard parts group's WFMS,
it launches a search facility for searching standard parts. The design engineer either
succeeds with the search or he fails. If he succeeds, the standard parts number is
transferred back to his workflow step, i. e. the one which he started the search step
from. If he does not succeed, a failure is reported back to his workflow step.

Exception: Standard Part (Re-) Design

If a design engineer is not able to find a standard part, he most likely asks for the
modification of an existing part according to his needs or he asks for a completely
new part. In addition to the type of request he has to the standard parts group (i. e.
modification of existing part or new part), he has to supply the specific requirements
for the part to be defined.

Furthermore, one of the requirements is that the standard part group checks the
criteria which the design engineer used to search for a part. This is necessary since
due to the huge amount of available parts, the design engineer might miss a part due
to lack of overview. To improve the process, the standard parts group does the search
again, based on their knowledge of the set of available parts. It might be the case that
they find a standard part which suits the needs of the design engineer so that no
modification is necessary at all. To achieve this, the search facility mentioned earlier
returns the search criteria as additional result parameter. This allows the automatic
routing of the criteria through the workflow system to the standards engineers
performing the search again.

Independent of the design engineer's suggestion of modifying a standard part or

developing a new one, the standard parts group evaluates the situation itself. Based
on their assessment, a standard parts gets modified or a new part gets designed. In the
following only the process for modifying a standard part is discussed.

Standard Part Modification

To be precise, a standard parts does not get modified but a new part gets designed

3
based upon an existing standard part. The two parts are therefore related and the
standard parts data base keeps track of this relationship.

A standards engineer reviews the requirements of the design engineer. Based on the
review the standards engineer might contact the design engineer to ask for more
information, for clarification or for adjustment of requirements. This exchange
(which might be repetitive) has to be recorded within a database so that exchange has
to take place electronically. This is necessary for audit reasons as well as for being
able to follow the rationale of the discussion between the two engineers.

Not every standards engineer can work on any standard part. Basically, the standard
parts are divided up between the standard engineers. The assignment of workflow
steps has to take this relationship into consideration.

If the standards engineer has all the information he needs for the modification of a
standards part, he has to compose the rest of the current workflow instance which
results into a modified standard part.

>From a WFMS perspective, the standard part modification process in defined

incompletely, i. e. only up to the point when the standards engineer composes the
continuation. This asks for being able to define a partially specified workflow type
and being able to run that. Later on it gets defined completely, at instantiation time.
Basically the "missing" workflow type definition is supplied during the execution of
the workflow instance itself.

As soon as the standards engineer has defined the remaining workflow type, the
upcoming workflow steps (which are not yet instantiated) are scheduled with a
project management tool (PM). The PM tool schedules the workflow step against the
capacity of the involved standards engineers. The schedule is returned and serves two
purposes. First, the design engineer gets notified about the expected finish date of his
request for the modification of a standard part. Second, the WFMS instantiates the
workflow steps based on the schedule (which contains the start and expected end
dates).

Before the workflow instance is continued, the design engineer receives the expected
finish date and has a choice of either acknowledging the expected date or indicating
that he cannot wait until this date because it is too late for him. In this situation he
either can "cancel" the continuation of the workflow instance or restate his
requirements with the hope that the modification can be done faster. Of course, if he
restates the requirements, the standards engineer has to review them again and also
has to re-design the rest of the workflow instance again.

It can be assumed that sooner or later (maybe after several iterations) the workflow
instance gets continued (if it is not "canceled" completely) according to the PM
schedule. The workflow instance does everything required to modify an existing
standard. This might take a long time involving several steps. It is usually a complex
workflow. During the execution problems might come up which require
communication with the design engineer again, which in turn might require to re-
schedule. Based on this the design engineer might opt to "cancel" the workflow. At
any time a problem can come up and a workflow can be canceled.

4
 After certain workflow steps for modifying the standard part are finished, a parallel
workflow is started which looks at the new part's production possibilities. It is not
necessary that the standards modification is done completely before production plans
can be started. Basically, the modification and the production workflow run in
parallel. In order to synchronize the modification steps with the production steps,
both workflows have to communicate necessary information. For example,
production problems, new insights, refinement of modifications, etc. The
communication goes in both directions, i. e. from the modification workflow to the
production workflow and vice versa. Since both workflows are complex, the peer-to-
peer communication goes across the workflow decomposition hierarchy, i. e.
workflow at any level of hierarchy might produce data which has to be sent to a step
at any level of the other workflow instance.

At any time, one of the workflows can come to the conclusion that the modification
or the production is not possible. This must result into the "cancellation" of both and
a notification to the design engineer.

Since several hundred design engineers work at the same time, many modification
requests might be issued to the standard parts group. In fact, it might be that different
modifications relate to the same part standard. In this case the modification
workflows must be coordinated with each other so that the modification of the
standard of one workflow does not affect another workflow or in a consistent way.

Of course, human users are impatient and want to know the status of their request. A
design engineer however is not a workflow expert. He does not know about
workflow instances, data flow, etc. He knows modifications, life cycles of
modifications, parts, etc. If he looks for the status of one of his requests (he can have
several at a time of course), he needs a status response in his domain language, not in
the technical language of WFMS.

As said, a design engineer might have several request issued at the same time.
Whenever a communication takes places between him and standards engineers, it
must be very clear which modification of which part is discussed about.

General Remarks

The business functionality, i. e. the design and standards data are accessed through
legacy applications. This means that almost all workflow steps communicate with
legacy applications.

The use of a graphic notation was intentionally avoided to not indicate a specific
solution to the given scenario.