Collaborative Design and Manufacture: Information Structures for Team Formation and Coordination

Abstract

Our interest here lies in supporting important, but routine and time-consuming activities that underpin success in highly distributed, collaborative design and manufacturing environments; and how information structuring can facilitate this. To that end, we present a simple, yet powerful approach to team formation, partner selection, scheduling and communication that employs a different approach to the task of matching candidates to opportunities or partners to requirements (matchmaking): traditionally, this is approached using either an idea of ‘nearness’ or ‘best fit’ (metric-based paradigms); or by finding a subtree within a tree (data structure) (tree traversal). Instead, we prefer concept lattices to establish notions of ‘inclusion’ or ‘membership’: essentially, a topological paradigm. While our approach is substantive, it can be used alongside traditional approaches and in this way one could harness the strengths of multiple paradigms.

1 Introduction

The first couple of decades of the twenty-first century have seen many Original Equipment Manufacturers (OEMs) in high value industries, such as the automotive and aerospace sectors, significantly streamline their supply chains, developing strategic partnerships with a reduced number of Tier 1 Suppliers, devolving to them key responsibilities for procurement and management of other suppliers. OEMs were motivated primarily by a need to rationalise adminstrative burden and to promote agility in response to increasing technical complexity of products and ever shortening product lifecycles. As such, traditional hierarchies have evolved into much flatter organisational structures, where interaction is dynamic and opportunistic, membership fluid, and decision-making decentralised. Unfortunately, these flatter structures have led to more complex coordination and collaboration procedures, posing challenges for small- and medium-sized enterprises (SMEs) to enter contemporary supply chains. It would be beneficial for SMEs to find a means of increasing visibilities to promote inclusion in contemporary supply chains: one possibility is for them to form clusters of complementary expertise so that they leverage appropriate market opprtunities. Subsets of partners from a cluster would pool resources—according to availability, capacity and requirements—to form a short term, dynamic partnership (an agile partnership) to respond as a single entity to a specific business opportunity.

A typical opportunity is when an OEM publishes an invitation to tender for a technical system or module, e.g., an interior. Timely response to this by an agile partnership requires rapid coordination of product development activities such as preliminary conceptual design of appropriate subsystems and (conceptual) integration of the resulting specification, among (potential) partners from the cluster. Automated support could accelerate this coordination and improve response to opportunities. Thus, our motivating research question was: How can we enable quick assembly and informed coordination of agile partnerships in highly distributed, dynamic manufacturing environments?

Essentially, the problem of assembling an agile partnership is one of matchmaking: identifying requirements and locating suppliers to fulfil these. Traditionally, this is approached using either an idea of ‘nearness’ or ‘best fit’ (metric-based paradigms); or by finding a subtree within a tree (data structure) (tree traversal). Here, we present an approach that uses concept lattices and rests on notions of ‘inclusion’ or ‘membership’: essentially, a topological paradigm.

Our intention here is to present the approach and outline its applications; we defer a critical comparison with alternatives and discussion of how to integrate with traditional approaches to another work. The paper is structured as follows. In Sect. 2 we briefly summarise the initial and current research contexts for the work; in Sect. 3 we introduce key elements of the formal apparatus and we briefly outline our approach; and in Sect. 4 we provide some simplified examples. We close with some concluding remarks in Sect. 5.

2 Research Context

The initial research context for the work here was in the automotive sector; in particular, working with SMES forming collaborative clusters known as Networks of Automotive Excellence (NoAEs) [5,6,7]. Membership of these NoAEs is fluid, with partners participating in a number of networks; interaction is dynamic and opportunistic, and decision-making is decentralised. Subsets of partners within an NoAE pool resources, forming short-term, dynamic alliances to respond as a single entity to opportunities in appropriate markets [5]. In these contexts, the responsibility of OEMs is shifting from purchasing and supplier management to brand positioning and design for assembly; convening such networks through Tier 1 Suppliers [6].

The current research context has enlarged to include Industry 4.0 initiatives in aerospace and related industries. DIGICOR (https://www.digicor-project.eu/) is developing a collaboration platform, tools, and services to facilitate the set up and coordination of a production network; these are informed by case specific governance tools and procedures for collaboration, knowledge protection, and security [2]. The platform aims to provide seamless connectivity to existing automation solutions, smart objects, and real-time data sources across the network; this will enable manufacturing companies and service providers to create and operate collaborative networks across the value chain. A key aims is to foster the integration of non-traditional, small, but innovative companies into the complex supply chain of large OEMs. DIGICOR governance rules aim to significantly reduce the burden of setting up collaborative networks and shorten the time to jointly respond to business opportunities.

3 Preliminaries

We briefly introduce some of the formal apparatus underpinning our approach.

3.1 Formal Concept Analysis

Formal Concept Analysis (FCA) [4] is a powerful, elegant method of analysis which identifies (conceptual) structures within data sets. The qualifier formal typically precedes many of the terms in the vocabulary of FCA to emphasise that these are mathematical notions, which do not necessarily reflect everyday use of the terms. We shall dispense with the qualifier here for convenience.

Table 1. A simple context for the planets; after [3].

Definition 1 (Context and Concept)

A context is a triple (G, M, I), where G is a set of objects, M is a set of attributes and $I\subseteq G \times M$ is an incidence relation. We write gIm for $(g,m)\in I$. Let $A\subseteq G$ and $B\subseteq M$. Define $A^\triangleright = \{m\in M \mid gIm, \forall g\in A\}$, then $A^\triangleright$ is the set of attributes shared by all objects in the set A. Similarly define $B^\triangleleft = \{g\in G \mid gIm, \forall m\in B\}$, then $B^\triangleleft$ is the set of all objects possessing the attributes in the set B. These maps are called derivation operators. A concept of the context (G, M, I) is a pair (A, B), such that $A^\triangleright =B$ and $A=B^\triangleleft$. The extent of the concept (A, B) is A and the intent is B.

Definition 2 (Concept Lattice)

Denote the set of all concepts of a context $\mathscr {B}(G,M,I)$, or simply $\mathscr {B}$ where the context is clear. Define a partial order, $\le$, on $\mathscr {B}$ as follows: $(A_1,B_1) \le (A_2, B_2) \Leftrightarrow A_1 \subseteq A_2 \Leftrightarrow B_1 \supseteq B_2$. Then $(\mathscr {B},\le )$ is called the associated complete lattice of concepts, or simply concept lattice, of the context (G, M, I).

We illustrate the basics of FCA through a simple example. Table 1 illustrates a simple context for the planets (objects) of the solar system, categorising these according to a number of attributes such as size, distance from the Sun and whether a planet has a moon. Consider the set $\{$Mercury, Venus$\}$. The attributes of this set are $\{$Mercury, Venus$\}^\triangleright = \{$size-small, distance-near, moon-no$\}$. and the pair $(\{$Mercury, Venus$\}, \{$size-small, distance-near, moon-no$\})$ is a concept of the simple context of Table 1, since $\{$size-small, distance-near, moon-no$\}^\triangleleft = \{$Mercury, Venus$\}$. Now consider the set $\{$Mercury, Venus, Earth, Mars$\}$. The attributes of this set are $\{$Mercury, Venus, Earth, Mars$\}^\triangleright = \{$size-small, distance-near$\}$. The pair $(\{$Mercury, Venus, Earth, Mars$\}, \{$size-small, distance-near$\})$ is a concept of the simple context of Table 1. Moreover, since $(\{$Mercury, Venus$\}, \{$size-small, distance-near, moon-no$\}) \le (\{$Mercury, Venus, Earth, Mars$\}, \{$size-small, distance-near$\})$ the former is a subconcept of the latter.

We can provide pictorial representation of the concepts of our context and their interrelations using a Hasse diagram [3]; see Fig. 1¹. The concept lattice is read in the following way: objects accumulate from the bottom upwards; and attributes accumulate from the top downwards. For example, the concept at the node marked distance-near includes {size-small, distance-near} as attributes and {Me, V, E, Ma} as objects. The concept lattice for a given context provides a direct manner in which to identify whether a relationship exists between two given concepts; and further, clarifies the nature of this relationship. For example, the concept lattice for a given context allows us to identify the immediate subconcept (respectively, superconcept) of any two concepts of a given context.

Fig. 1.

A concept lattice for the planets from Table 1; after [3].

3.2 Galois Connection

Once information about a domain is structured in concept lattices, we can use Galois Connections to interrelate different concept lattices, or even different concepts in the same lattice. A Galois Connection is a pair of “opposite” functions between two partially ordered sets, often powersets, which respects the orders in the sets [1].

Definition 3 (Galois Connection)

Let $(X,\sqsubseteq _X)$ and $(Y,\sqsubseteq _Y)$ be partially ordered sets. A Galois Connection between the two sets is a pair of maps $\alpha : X \rightarrow Y$ and $\gamma : Y \rightarrow X$ such that, for all $x\in X$ and $y\in Y$,

$$\begin{aligned} \alpha (x) \sqsubseteq _Y y \Leftrightarrow x \sqsubseteq _X \gamma (y) \end{aligned}$$

(1)

We denote the Galois Connection between X and Y by $(X,\alpha ,Y,\gamma )$.

Definition 4 (Closure Operator)

Let $(X,\sqsubseteq _X)$ be a partially ordered set. A closure operator on X is a map $c: X\rightarrow X$, such that, for all $x, y \in X$, c is

• Extensive, i.e., $x \sqsubseteq _X c(x)$;

• Monotonic, i.e., $x \sqsubseteq _X y \Leftrightarrow c(x) \sqsubseteq _X c(y)$; and

• Idempotent, i.e., $c(c(x)) = c(x)$.

Accordingly, any element $x\in X$ is called closed if and only if $x = c(x)$. We refer to the structure which results from the application of a closure operator to a poset as a closure system or simply closure.

Amongst the many interesting properties of a Galois Connection is that the consecutive application, the composition, of the two “opposite” functions constitutes a closure operator; that is it “collects” upwards, preserves the order and two applications produce the same effect as one.

Lemma 1

Let $(X,\alpha ,Y,\gamma )$ be a Galois Connection between two partially ordered sets, $(X,\sqsubseteq _X)$ and $(Y,\sqsubseteq _Y)$. Then (composing from left to right) $\alpha \gamma : X \rightarrow X$ defines a closure operator on X and $\gamma \alpha : Y \rightarrow Y$ defines closure operator on Y. (See [3] for proof.)

3.3 Galois Connections and Concept Lattices

Recall the derivation operators from Subsect. 3.1 used to establish a relation from sets of objects to sets of attributes (shared by these objects) and vice-versa. These can be thought of as; are in fact functions on the powersets of objects and attributes. The lemma below shows that these constitute a Galois Connection between the two powersets.

Lemma 2

Let (G, M, I) be a context. Recall the derivation operators $^\triangleright : \wp (G) \rightarrow \wp (M)$ and $^\triangleleft : \wp (M) \rightarrow \wp (G)$. Then $(\wp (G),^\triangleright ,\wp (M),^\triangleleft )$ is a Galois Connection between the posets $(\wp (G),\subseteq )$ and $(\wp (M),\supseteq )$. (See [4] for proof.)

Any powerset and its dual are complete lattices [3], so we have that $(\wp (G),\subseteq )$ and $(\wp (M),\supseteq )$ are complete lattices. Thus, we can combine the results of Lemmas 1 and 2.

Corollary 1

Let (G, M, I) be a context. Recall the derivation operators $^\triangleright : \wp (G) \rightarrow \wp (M)$ and $^\triangleleft : \wp (M) \rightarrow \wp (G)$. Then $^{\triangleright \triangleleft } : \wp (G) \rightarrow \wp (G)$ is a closure operator on $(\wp (G),\subseteq )$ and $^{\triangleleft \triangleright } : \wp (M) \rightarrow \wp (M)$ is a closure operator on $(\wp (M),\supseteq )$.

Remark 1

(Notation). We write simply $\wp (G)$ for $(\wp (G),\subseteq )$, when it is clear that the partial order is the usual subset inclusion; and we write $\wp (M)^\partial$ for $(\wp (M),\supseteq )$. We denote the closures of these under the compositions of the derivation operators $\overline{\wp (G)}$ and $\overline{\wp (M)}^\partial$, respectively.

For a particular context, (G, M, I), the actions of these closure operators, $^{\triangleleft \triangleright }$ on $\wp (M)^\partial$ and $^{\triangleright \triangleleft }$ on $\wp (G)$, generate the concept intents and extents, respectively. Moreover, the structures of the closure systems induced on $\wp (M)^\partial$ and $\wp (G)$ are identical; and these structures are co-located in the concept lattice, $\mathscr {B}(G,M,I)$. Informally, we can think of the closure operators as removing redundancy:

• $^{\triangleleft \triangleright }$ removes from $\wp (M)^\partial$ (sub)sets of attributes that do not combine to describe an object. For example, size-large and distance-near do not apply in tandem to any of the planets in Table 1. Thus, {size-large, distance-near} $\in \wp (M)^\partial$, but {size-large, distance-near} $\not \in \overline{\wp (M)}^\partial$.

• $^{\triangleright \triangleleft }$ removes from $\wp (G)$ (sub)sets of objects that have no attributes in common. For example, Mercury is a small planet, near the sun without a moon, whereas Jupiter is a large planet, far from the sun with at least one moon. Thus, these share none of the attributes in Table 1 and are conceptually distinct and should not appear together in the extent of any concept. Hence, {Mercury, Jupiter}$\,{\in }\,\wp (G)$, but {Mercury, Jupiter}$\,{\not \in }\,\overline{\wp (G)}$.

3.4 Observations

FCA identifies those objects which are indistinguishable under a given incidence relation to a particular set of attributes: indistiguishable objects belong to the same element of the associated closure (and comprise the extent of the related concept). For example, Mercury and Venus are indistinguishable using the attributes of the context in Table 1; thus, they are identified as the same “element” in the closure.

Different attribute sets will give rise to different closures: in particular, subsets will give rise to substructures. In FCA, a context derived from another by considering only a subset of attributes (or objects) is called a subcontext [4]. For example, the lattice in Fig. 2 derives from a subcontext of Table 1 that considers only attributes for size and distance; and ignores presence or absence of a moon. Again, the lattice derives from closures on the associated power sets². When we use the subset of attributes (from the subcontext), we see that Mercury and Venus are still indistinguishable from each other, but now, Venus is also indistinguishable from these; thus, they are identified as the same “element” in the new closure, which is a coarser system. Of course, all of the information of the sub-lattice is actually contained in the full lattice; however, identifying a subset attributes of interest and using these to project onto a sub-lattice makes the relationships and indistinguishable elements much clearer (as redundant information is removed); and indeed, more visible. This becomes more valuable as the number of objects and attributes increase. This means that for a given context, we can use subsets of attributes to explore more directly the interrelationships of objects from different perspectives; and visualise these. This is essentially what we do when we use lattices to match suppliers with requirements, coordinate meetings, etc., as illustrated in Sect. 4.

Fig. 2.

Concept lattice for a reduced context of planets.

4 Application

We provide some (simplified) examples of how the approach can be applied in the aerospace industry to facilitate team formation for responses to invitations to tender (Subsect. 4.1), to coordinate meetings (Subsect. 4.2), to identify membership of project subgroups and identify key interactions of team members (Subsect. 4.3).

4.1 Invitations to Tender

An Invitation to Tender is a formal invitation made by an OEM to suppliers to make an offer, i.e., propose terms, for the supply of specific goods or services. Typically, an ordinary aerospace tender includes a statement of requirements that clarify expectations of suppliers, specify products and services needed and identify volumes, time frames and key dates. An OEM will only consider tenders from suitably qualified partnerships and demands will usually address:

• size of partners, reflected in capacity and turnover constraints;

• systems capabilities, reflected in standards and certifications, such as ASD 9100, ISO 16949 and NADCAP;

• proximity to the place of assembly; and nowadays

• a commitment to corporate social responsibility.

An OEM may also require that a submitting partnership has a working history (thus, that partners are trusted by each other and are not new entrants to the cluster).

It is a simple matter to construct a context that allows us to characterise the suppliers (objects) in our cluster using relevant descriptors (attributes); Fig. 3 shows a simplified context for ten suppliers (S1, $\dots$, S10) characterised using attributes relating to these descriptors (Min-Turnover, Min-Capacity, Trusted, New, ASD 9100, ISO 16949, NADCAP, Proximal and Min-CSR). We read the lattice as usual: the white labels collect upwards and the grey labels collect downwards. Here, a “concept” indicates which suppliers fulfil various requirements captured by subsets/combinations of the attributes. This provides information which can be invaluable for coordinating for tenders. Moreover, manipulating the lattice and projecting onto sub-lattices according to different subsets can reveal which suppliers meet certain criteria more directly.

Fig. 3.

A concept lattice for suppliers

Fig. 4.

A concept lattice for suppliers

Suppose that the OEM requires that the partnership has a sound working history and has stipulated minimum capacity, NADCAP capability, locating within a specific proximity and appropriate CSR certification. By collapsing the full lattice to an appropriate sub-lattice (for subcontext of attributes: Min-Capacity, Trusted, NADCAP, Proximal and Min-CSR), see Fig. 4, we see immediately that only suppliers S1, S6 and S7 are suitable partners for the tender (from the current set). Of course, we have made a number of simplifications here: we have not, for example, considered whether the expertise of these three would be sufficient. It is more likely that the ten suppliers would be for a particular aspect of the tender, the same aspect, and that our projection onto a sub-lattice would be used to identify potential candidates. We may then select one from these three or ask the three to coordinate on that aspect of the tender: this would build redundancy into the supply chain, if the tender were accepted, thus fostering resilience.

Table 2. A simple context for a fuselage interior.

4.2 Coordinating Meetings

Consider the following (extremely) simplified subset of interior features of a fuselage for an airliner: chairs, windows, vents, internal panels, lighting systems and (overhead) lockers. Table 2 combines these with a relevant (again, extremely simplified) subset of service providers—Paneller, HVAC Supplier, Upholsterer, Lighting Specialist, Fixture Systems Provider, Seating Specialist, and Specialist Glass provider—into a context which gives rise to the concept lattice in Fig. 5. Again, we read the lattice with white labels collecting upwards and grey labels accumulating downwards. Here, a “concept” indicates which suppliers associate, i.e. have an interest in or contribute expertise necessary for a particular feature or set of features. This provides information which can be invaluable for arranging meetings. For example, we can infer from the node carrying the label “Windows” that the interests of the Specialist Glass Supplier and the Paneller coincide and that it is only these two that need to meet to finalise the relevant specifications. Thus, we know that we shall need to coordinate meetings between these two for purposes of discussing the Windows. We can also see that no single supplier needs to meet about every feature, as the lowest node in the lattice has no object (supplier) associated with it. Moreover, We can also see that no single feature requires the input of every supplier, as the highest node in the lattice has no attribute (feature) associated with it. Of course, we can draw these conclusions quite easily from the context; however, this would become increasingly difficult as a context enlarges.

Fig. 5.

A concept lattice for fuselage suppliers

4.3 Project Subgroups

As the complexity of a product or technical system increases, the more convenient it is to have formal subgroups working on different aspects of development. Projecting the full concept lattice of Fig. 5 directly onto the sub-lattices deriving from the subcontext generated for a particular feature makes directly clear those suppliers who must be part of the subgroup. For example, Fig. 6 shows directly who is needed for the Light System Project Subgroup.

Fig. 6.

A concept lattice for the light system subgroup

Fig. 7.

Meetings and subgroups for the HVAC supplier

Finally, selecting those features for relating to a specific supplier and projecting the full concept lattice of Fig. 5 directly onto the sub-lattice deriving from the relevant subcontext reveals essential interactions, specifically subgroups and meetings, from the perspective of that supplier. For example, Fig. 7 shows directly the interactions of the HVAC Supplier. Interestingly, every feature that requires the expertise of the HVAC Supplier requires that of both the Paneller and the Fixtures Provider; however, we cannot infer the converse.

5 Concluding Remarks

We have reported on investigations into information structuring to facilitate the automation of important, but routine and time-consuming activities of agile partnerships operating within highly distributed, collaborative environments. These explorations are grounded in the domains of Networks of Automotive Excellence and Industry 4.0 initiatives in aerospace. We have outlined how a synthesis of mathematical notions provides a simple, yet powerful approach to facilitate inter alia partnership formation; the selection of working groups from partnerships; and the scheduling of workshops and subgroup meetings, identifying the subject matter for these. We believe that our approach is innovative in that we re-think the problem of matching candidates to opportunities or partners to requirements; we frame this as a topological notion of set membership rather than taking traditional metric-based or tree traversal approaches, which, while effective, can be computationally expensive and time-consuming. Our aim is not to challenge established methods; rather, our intention here has been to present the approach and outline its applications to provide food for thought and to stimulate discussion. Thus, we defer a comparison with alternatives and in-depth critique to another work.