EMI: Engineering and Management Integrator

Abstract

The impact of systems engineering on program cost has been recognized for over a decade. From the very early stages, careful management of the relationships between the product design and the project plan is crucial to the success of any project that aims to deliver a defined product. Failure to closely manage the intricate web of resource constraints emanating from the two domains, the project scope and the product scope may lead to inadequate product performance or overruns in project schedule and budget. Identifying and managing the relationship between these two domains are at the heart of our challenge to combine project management (PM) and systems engineering (SE). We present a new approach, called EMI, which integrates SE and PM methodologies. These include the EMI mathematical foundation, implementation in architectural optimization and project management tools, and a detailed use case for development of the Doors Management System for commercial aircraft.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

“All programs…shall apply a robust Systems Engineering approach that balances total system performance and total ownership costs…” [1]. Meeting the required system specifications is one of the main challenges for systems engineers, whether chief system engineers or system engineers of a specific discipline. One of their objectives is to meet budget and schedule goals for the development and manufacture of the system and its subsystems. The ultimate goal is to provide a high quality product on time and within budget. Systems engineering (SE) and project management (PM) are two tightly intertwined domains, as stated in the Handbook of Systems Engineering and Management [2]. In contemporary practice, system engineers relate to the development and manufacturing costs that can be measured in work hours. However, when considering technological approaches, system engineers may choose state-of-the-art solutions without fully considering schedule and budget implications and constraints. In other words, they sometimes focus more on the product scope and neglect the project scope. System engineers make product-domain decisions that directly influence the project-domain, in which the project manager is responsible for multi-criteria decision-making (MCDM) on a daily basis. Analytic and simulation decision support tools can be of great value in such an environment.

Starting with the pivotal work of Forsberg and Mooz [3], many papers describe the need or conceptual framework for integrating SE and PM (see, e.g., [4–8]). Our work shows how this integration can be accomplished. This paper presents EMI, short for Engineering and Management Integrator, which combines SE and PM methodologies. Our contribution is in developing a practical mathematical model that combines SE architectural optimization and PM planning tasks. As part of our work, we implement this method using decision support tools, define a holistic engineering and management methodology, and demonstrate it for a typical product development.

The paper is organized as follows. We first describe the EMI mathematical foundation and methodology. We then demonstrate the methodology in a typical industrial use case involving the development of the Doors Management System (DMS) in a commercial aircraft using two state-of-the-art tools. The first tool is the Architectural Optimization Workbench (AOW), which deals with the architectural optimization (AO) aspects. The second is the Project Team Builder (PTB), which deals with the PM aspects. We show the limitations that arise when each tool is used on its own and how using EMI to integrate these tools can overcome the limitations and improve the results for finding an efficient DMS architecture. Finally, we summarize and provide directions for future research.

2 EMI Mathematical Foundation and Methodology

2.1 Project Time Management for Architectural Optimization

While PM has many aspects [9], in developing EMI we focus on the integration of time management and selection of the best system architecture. The mathematical model closest to the settings of AO is the Multi-mode Resource Constrained Project Scheduling Problem (MRCPSP) [10, 11]. In MRCPSP, project activities have several operational modes, each with its own duration and required set of resources. The activities have precedence constraints, and resources have a final capacity. An MRCPSP solution defines the mode in which each activity is executed and schedules the activities according to precedence and resource constraints. Solution procedures for MRCPSP include both heuristic and exact methods. In off the shelf MILP solvers, such as Cplex [12], the exact methods based on MILP formulation are capable of solving industrial size problems [13]. It is interesting to note, that the classical time-indexed formulation or its slight modification are usually the preferable options for solving real size problems with a few hundreds of periods [11].

We begin our methodology by adjusting MRCPSP to our AO needs. First and foremost, we synchronize the mode selection with the selected architectural components. Development projects are usually performed with preemptive schedules and part-time job intensity. This is especially true in matrix organizations, where technical units with domain expertise provide services to all running projects. Our model also supports variable period lengths. The total number of periods and consequently, model size, could be significantly reduced using longer period lengths for later periods, where having a detailed plan makes less sense. The model we developed, called AO-MRCPSP, is described below.

Sets: A—activities, $\varvec{IP}_{\varvec{i}}$—immediate predecessors of activity $i \in A$, $\varvec{M}_{\varvec{i}}$—modes of activity $i \in A$, R—resources, $\varvec{P} = 1 \ldots \varvec{T}$—periods, $\varvec{G}$—subsystem/components types. Parameters: w—the minimum work intensity if an activity is performed in a part-time, e—maximal extension of activity duration caused by preemption, $\varvec{p}_{\varvec{t}}$—duration of period $t \in P$, $\varvec{T}_{{\varvec{max}}} = \sum\nolimits_{t \in P} {p_{t} }$—time horizon, $\varvec{d}_{\varvec{j}}$—duration of mode j, $\varvec{r}_{{\varvec{jk}}}$—requirement of mode j for resource k, $\varvec{a}_{\varvec{j}}$—resource independent cost of mode j, $\varvec{h}_{\varvec{i}}$—subsystem/component type of activity i, $\varvec{n}_{\varvec{j}}$—subsystem/component type id of mode j, $\varvec{v}_{\varvec{k}}$—capacity of resource k, $\varvec{b}_{\varvec{k}}$—cost of resource k per time horizon. Decision variables: $\varvec{x}_{{\varvec{ij}}}$—binary variable for mapping activity $i \in A$ to mode $j \in M_{i}$, $\varvec{y}_{{\varvec{jt}}}$—continous variable for mapping mode j to period $t \in P$, ${\tilde{\mathbf{y}}}_{{\varvec{it}}}$—binary indicator that activity $i \in A$ is performed at period $t \in P$, $\varvec{s}_{{\varvec{it}}}$—binary wave variable that activity $i \in A$ started at period $t \in P$ or earlier, $\varvec{f}_{{\varvec{it}}}$—binary wave variable that activity $i \in A$ finished before period $t \in P$ or earlier, $\varvec{C}_{\varvec{i}}$—completion time of activity $i \in A$, $\varvec{C}_{{\varvec{max}}}$—completion time of the whole project, $\varvec{u}_{{\varvec{kt}}}$—utilization of resource k at period t, $\varvec{u}_{\varvec{k}}$—average utilization of resource k, $\varvec{A}$—total cost of activities, $\varvec{B}$—total cost of resources, $\varvec{D}$—total cost of project, $\varvec{q}_{\varvec{o}}$—type id of subsystem/component type $o \in G$.

$$ \begin{array}{*{20}c} {{\mathbf{AO}} - {\mathbf{MRCPSP}}} & {{\text{Minimize}}\left\{ {C_{max},D} \right\}} \\ {} & {{\text{Subject}}\,{\text{to}}} \\ \end{array} $$

(1)

$$ \mathop \sum \limits_{{j \in M_{i} }} x_{ij} = 1\quad \forall i \in A $$

(2)

$$ y_{jt} \le x_{ij} \quad \forall i \in A, j \in M_{i} ,t \in P $$

(3)

$$ w \cdot \tilde{y}_{it} \le \mathop \sum \limits_{{j \in M_{i} }} y_{jt} \quad \forall i \in A,t \in P $$

(4)

$$ \tilde{y}_{it} \ge \mathop \sum \limits_{{j \in M_{i} }} y_{jt} \quad \forall i \in A,t \in P $$

(5)

$$ s_{it} \le s_{i,t + 1} \quad \forall i \in A, t \in P|t < T $$

(6)

$$ f_{it} \le f_{i,t + 1} \quad \forall i \in A, t \in P|t < T $$

(7)

$$ s_{it} \ge \tilde{y}_{it} \quad \forall i \in A, t \in P $$

(8)

$$ f_{it} \le 1 - \tilde{y}_{it} \quad \forall i \in A, t \in P $$

(9)

$$ \tilde{y}_{it} \le f_{{i^{{\prime }} t}} \quad \forall i \in A,{i^{\prime}} \in IP_{i} , t \in P $$

(10)

$$ \mathop \sum \limits_{{j \in M_{i} }} \mathop \sum \limits_{t \in P} y_{jt} p_{t} \ge \mathop \sum \limits_{{j \in M_{i} }} x_{ij} d_{j} \quad \forall i \in A $$

(11)

$$ \mathop \sum \limits_{t \in P} \left( {s_{it} - f_{it} } \right)p_{t} \le e\mathop \sum \limits_{{j \in M_{i} }} x_{ij} d_{j} \quad \forall i \in A $$

(12)

$$ C_{i} = T_{max} - \mathop \sum \limits_{t \in P} f_{t} p_{t} \quad \forall i \in A $$

(13)

$$ C_{max} \ge C_{i} \quad \forall i \in A $$

(14)

$$ u_{kt} = \frac{1}{{v_{k} }}\mathop \sum \limits_{i \in A} \mathop \sum \limits_{{j \in M_{i} }} y_{jt} r_{jk} \quad \forall k \in R, t \in P $$

(15)

$$ u_{kt} \le 1\quad \forall k \in R, t \in P $$

(16)

$$ u_{k} = \frac{{\mathop \sum \nolimits_{t \in P} u_{kt} p_{t} }}{{\mathop \sum \nolimits_{t \in P} p_{t} }} $$

(17)

$$ B = \mathop \sum \limits_{k \in R} u_{k} v_{k} b_{k} $$

(18)

$$ A = \mathop \sum \limits_{i \in A} \mathop \sum \limits_{{j \in M_{i} }} x_{ij} a_{j} $$

(19)

$$ D = A + B $$

(20)

$$ \mathop \sum \limits_{{j \in M_{i} }} x_{ij} n_{j} = q_{{h_{i} }} \quad \forall i \in A $$

(21)

$$ x_{ij} ,\tilde{y}_{it} ,s_{it} ,f_{it} \in \left\{ {0,1} \right\}\quad 0 \le y_{jt} ,u_{kt} ,u_{k} \le 1\quad C_{i} ,C_{max} ,A,B,D \ge 0 $$

(22)

The total project duration and cost are common objective functions in Eq. (1). Moreover, any piecewise linear function of decision variables could be added to the set, for example, the utilization range of critical resources to smooth their usage. Constraints (2)–(3) ensure exactly one mode for each activity. Constraints (4) define minimal part-time intensity w if activity i is performed during period t, for example, 50 % to allow working on two activities at most. Note, only one $y_{jt}$ can be positive. Constraints (5) connect mode continuous performance to an activity binary indicator at period t. Constraints (6)–(9) ensure correct behavior of wave functions when activity i starts and finishes (because of objectives and other constraints, $s_{it}$ and $f_{it}$ try to become 1 as late and as early as possible, respectively). Constraints (10) ensure precedence relation, allowing activity i to start only after all its predecessors have finished. This constraint could be relaxed to $\tilde{y}_{it} \le f_{{i}^{\prime},\,{t+1}}$ to allow simultaneous execution of an activity with its predecessors for rough resource allocation (e.g., in later long periods). Constraints (11) ensure activity i is performed long enough to be completed. Effectively, these constraints imply that the project should be completed before T _max . Constraints (12) restrict the total time activity i has started but not finished yet to e times its nominal duration $d_{j}$. Constraints (13)–(14) calculate activity and project completion time, respectively. Activity start time could be calculated similarly using $s_{it}$ instead of $f_{it}$. Additional constraints could be added to the earliest and latest start and completion times. Constraints (15)–(17) calculate resource unitization and constrain it according to the available capacity. We allow variable resource capacity over periods in our implementation. Constraints (18)–(20) calculate the cost of resources, B, the cost of activities, A, and the total project cost, D, respectively. Constraints (21) relate the PM model with AO, ensuring that activities connected to some subsystem/component choose the same subsystem/component type as AO. Constraints (21) define domain of decision variables. AO-MRCPSP can incorporate time and resource buffers. Dummy activities without required resources (i.e., $r_{ik} = 0$ for all k) before integrating activities and before activities that request critical resources represent time and resource buffers, respectively.

The AO-MRCPSP formulation above has several beneficial properties. Allowing preemption and part-time intensity help relax regular MRCPSP constraints and remove the need for binary indicators per mode per period. In this setting, event-based formulations [14], usually most applicable for large projects, are less attractive since preemptions require more events. In addition, the model is not very sensitive to the number of modes—most variables and constraint sets are per activity, not per mode. Probably the most important property of AO-MRCPSP is that it requires a relatively small number of periods, which is the most sensitive and problematic parameter of time-indexed formulation. Currently, standard optimization packages, such as Cplex [12] can handle up to a few hundreds of periods. If each period represents a week, our model optimizes a multi-year plan. During AO, a rough estimation is required with a lot of uncertainty regarding later stages of the project. The period lengths could be adjusted accordingly, further reducing the model size. For example, in our use case we apply bi-weekly periods.

2.2 AO-MRCPSP in Architectural Optimization

To incorporate the aspect of architectural optimization into EMI, we relied on two preliminary works. The first is the concise modeling [15] extension of SysML [16] to specify architectural alternatives and system constraints. Concise modeling combines regular SysML diagrams that define architectural topology (e.g., components multiplicity and connections rules), with associated data tables called catalogs for block subclasses and inventories for part multiplicities. Using concise modeling, AO assumes that all parts are a priori optional, and divides all attributes into either parameters determined by data tables or SysML model values, or variables optimized during AO. For example, when outlined by catalog stereotype, the RDC block has an associated catalog table listing several RDC options and their relevant parameters (weight, power, etc.). These options could include different technologies, such as optical or copper cables, that should be synchronized with the PM choices of appropriate activities in their modes. The optimization process is responsible for finding concrete architecture alternatives that conform to the topology, driven also by a predefined set of system or subsystem attributes called design objectives, and constraints grouped by different types of analysis, called analysis viewpoints. Analysis viewpoints help calculate the system variables or define their feasible region for architectural optimization, considering concerns such as cost, weight, reliability, timing, resource allocation, and power and data distribution. The second preliminary work [17] defines the concept of pluggable analysis viewpoints, demonstrating its ability to specify design objectives as a library of reusable assets. The pluggable viewpoints are based on the concept of classification-by-property [18], in which the computational semantics for the sets appearing in constraints is specified according to different properties of the domain elements. Masin et al. [17] demonstrate that applying classification-by-property principles creates robust analysis libraries that remain resilient to system evolution during product design, and enables Lego type interoperability between different system analyses. An adaptation of AO to PM is straightforward using the methodology for pluggable analysis viewpoints: the AO-PM formulation below just adds “analysis viewpoint” AO-MRCPSP to other viewpoints, where constraints (25) are similar to (21) applied to subsystem/component catalogs.

$$ \begin{array}{*{20}c} {{\mathbf{AO}} - {\mathbf{PM}}} & {{\text{Minimize}}\,Original\,objectives,\,Objectives\left( 1\right)} \\ {} & {{\text{Subject}}\,{\text{to}}} \\ \end{array} $$

(23)

$$ \begin{array}{*{20}c} {Original\,architectural\,constraints} \\ {{\text{Constraints}}\left( 2\right)\text{--}\left( { 2 2} \right)} \\ \end{array} $$

(24)

$$ Subsystem /component\,type\,synchronization\,constraints $$

(25)

2.3 EMI Methodology

EMI methodology focuses on the integration of System Architecture Synthesis with Project Time Management. In most MBSE and PM methodologies, both tasks are relatively independent, performed by different people using different tools. EMI defines what information is transferred between the tools to implement the AO-PM model and obtain a holistic system architecture and project plan.

The initial information comes from the SE team to define system-related data such as subsystems, subsystem options, and performance goals. Then, the PM team defines project activities including precedence between activities, alternative modes, and required resources. The PM data is incorporated with other viewpoints considered during the design space exploration (DSE) for MCDM. The selected Pareto optimal solutions are transferred to the PM team for detailed analysis. If the results are satisfactory, the project can start. Otherwise, the PM team should update project parameters, especially the adjusted resources capacities, activity and resource buffers, and mode durations. New architectures are then found by the AO-PM model. The whole process is shown in Fig. 1. EMI can be used as a pre-project fuzzy front-end stage [19] in the early planning stages of the project or during the project. Each usage requires slight modifications in the suggested process, for example, customer interaction in fuzzy front-end or re-iteration to address system and environment changes during the project. Although we distinguish between SE and PM, in practice, the teams could be interdisciplinary.

Fig. 1

EMI process

3 Demonstration of EMI Methodology

3.1 SE and PM Tools

In this section we briefly describe two state-of-the-art tools for SE and PM that we use to demonstrate the EMI methodology. System engineers are typically responsible for creating alternative architectural solutions according to all requirements and goals, and for choosing the best one. However, the ever-increasing complexity of systems, strict design constraints, conflicting goals, and many other factors make the process of finding optimal designs extremely difficult. The common means to achieve system goals is to build optimization models for the set of specified architectures and find the best one using suitable optimization software tools. Unfortunately, this approach is highly labor-intensive because each architecture solution created by the engineer requires a separate optimization model created by an expert. This issue is resolved by the Architectural Optimization Workbench (AOW) described in [15, 17], and [20]. In the AOW, the system engineer can rapidly create the necessary system architecture, satisfying all functional and technical constraints needed to achieve the specified goals. Using standard SysML with the concise profile described above, the system engineer can model the composition rules (also known as architectural patterns, or templates) of the required functional and physical system structures and relations inside (data flow, energy flow, etc.) and between them (potential mapping between functions and physical components). In Rational Rhapsody [21] this approach immediately allows linking the functional models to the requirements in DOORS. The potential physical components are imported from a library, along with geometrical data, if relevant for the use case. Currently, AOW is integrated with MS Excel [22] and Pacelab Suite [23]. The optimization goals are specified as SysML constraints or Parametric Diagrams [20]. The tool uses all the inputs above to automatically generate a mathematical optimization program in OPL language [24] and the IBM Cplex solver. The AOW can be extended to produce optimization models in other languages, such as AMPL [25], to use with other solvers. Since there are multiple and usually conflicting goals, the optimization finds diverse Pareto optimal solutions (solutions where no goal can be improved without adversely affecting another). This is the maximum that can be done automatically before the final human decision. The results of the optimization are back-annotated into the SysML tool for the engineer to review. The AOW interface enables: importing and editing of the data, adding constraints and objectives, and managing the optimization runs, including viewing the results, and exporting them to the follow-on processes.

Our second tool, the Project Team Builder (PTB) is an integrated decision support system designed to support new product development teams during the project [26–32]. PTB combines simulation and case study approaches. Each case study is a new product development project performed under schedule, budget, and resource constraints, in a dynamic stochastic environment. The details of these case studies are built into the simulation, and all the data required for analysis and decision-making is easily accessed by the user interface. Random effects simulate the uncertainty in the environment, and decisions made by the user cause changes in the state of the simulated system. PTB supports a model-based approach for translating the voice of the customer into the project scope. A database is built into the PTB to support decision-making, post factum analysis, and backtracking. A friendly GUI enables a typical user to learn how to use the PTB within an hour. The PTB combines classical PM domains such as scheduling of activities with management of requirements. It offers a module for managing system requirements that supports the process of selecting alternative designs to determine system performance. The simulator allows the generation of project scenarios that include stochastic activity duration, resource capacity, and costs. Based on the input, the simulator offers a forecast for the project cost, schedule, and the product quality.

3.2 EMI Use Case with Doors Management System

To evaluate the benefits of our EMI methodology, we applied it to a use case involving the Doors Management System (DMS) for an aircraft. The DMS controls the latching and locking of doors in an aircraft. It communicates with the aircraft’s pressurized system and consists of sensors, actuators, controllers, data collectors, and an Avionics Full-Duplex Switched Ethernet (AFDX) network. Functional requirements define the system functions, such as sensing, latching, locking and controlling, and the data flow between them. The structure describes potential DMS topologies, and the geometry gives potential physical locations. Figure 2 shows the transition of a customer story to a concise model in which all requirements and design alternatives are formally defined. The system optimization criteria include system weight, cost, and power consumption. Marketing requires project completion within one year (48 weeks).

Fig. 2

From customer’s story to concise modeling

As a comparison to EMI, we applied the SE methodology to the design of DMS for commercial aircraft. The AOW takes into account the system design for the aircraft door sensors, remote data concentrators, controllers, actuators and related power cables, power and data distribution flow, and safety requirements while optimizing the results for weight, cost, and power consumption. The AOW found four Pareto optimal solutions, shown in Fig. 3a. Systems engineers prefer to focus on two solutions with weight less than 200 kg, and power less than 305 W.

Fig. 3

a AOW only Pareto frontier. b DMS development activity precedence diagram and Gantt chart. c PTB only Pareto frontier

We also applied the PM methodology to the use case using PTB. The project activity network for the DMS use case is shown in Fig. 3b. Project simulations run in PTB showed that none of the two architectures coming from the SE team could be developed in 48 weeks. By defining the benefit as a weighted sum of the weight, material cost, and power (with 25, 50, and 25 %, respectively), the PM team could approximate their values based on the available activity modes, and they found a completely different Pareto frontier, shown in Fig. 3c. Unfortunately, all the chosen architectures resulted in weight and power above the required threshold set by the SE team. In the next section, we applied EMI methodology, integrating both tools, AOW and PTB, for the DMS use case.

Using the EMI methodology for the same use case, we implemented AO-PM in AOW and provided data communication between AOW and PTB. The resulting Pareto frontier from AOW contains two solutions, as shown in Fig. 4a. Both were not on the original Pareto frontiers obtained by AOW and PTB. The first architecture transferred to PTB and passed all simulation tests (Fig. 4b) and was chosen for DMS development. Compared with architectures shown in Fig. 3, the chosen system has better chances for success since both the SE and PM teams have not compromised their objectives and constraints, and together found a well-balanced design architecture with a manageable design process.

Fig. 4

a AOW AO-PM Pareto frontier. b PTB Gantt and simulation the first design

4 Summary

The impact of systems engineering on program cost was recognized over a decade ago [33], suggesting that from the very early stages, careful management of the relationships between the product and the project is crucial to the success of any project that aims to deliver a defined product. Systems engineers are required, therefore, to apply science and technology, as well as technical planning, management, and leadership activities [34]. While the technical issues are related to the product domain, the managerial aspects reside in the project domain.

In this paper, we presented a new approach, called EMI, to integrate SE and PM methodologies. EMI defines what information is transferred between the tools to implement the AO-PM model and obtain a holistic system architecture and project plan. Our work includes the mathematical foundation for EMI, implementation in AOW and PTB tools, and a detailed use case of DMS development for commercial aircraft. EMI can be used in pre-project fuzzy front-end stage [19], in early planning stages of the project, or during the project.

For future research we suggest handling project uncertainty in activity durations and resource availability by robust optimization, to reduce the number of iterations between AO and PM tools.