MODEL BASED SYSTEMS ENGINEERING (MBSE) IN DEVELOPMENT PROJECTS: A FRAMEWORK FOR DEPLOYMENT

Transcription

1 MODEL BASED SYSTEMS ENGINEERING (MBSE) IN DEVELOPMENT PROJECTS: A FRAMEWORK FOR DEPLOYMENT MR PHILIP STEYN* Graduate School for Technology Management University of Pretoria, Pretoria, South Africa u @tuks.co.za PROF LEON PRETORIUS Graduate School for Technology Management University of Pretoria, Pretoria, South Africa Leon.Pretorius@up.ac.za ABSTRACT Projects continue to suffer schedule and cost overrun. One cause of this is the conflicting relationship between systems engineering and project management. The inherent nature of systems engineering is to work towards achieving requirements through an iterative process of design influencing and design change. Because of the unpredictable nature of this iterative process, projects are prone to failure. This is because the project management process cannot account for the unpredictable systems engineering process impact. The purpose of this paper is to highlight the research done on the constructive and proactive deployment of design methods to improve the performance of systems engineering within the development project environment. Research is underway as part of a PhD project to further defines the relationship between MBSE deployment and effective project execution in a complex design and construction environment. For the purpose of the research presented in part here design methods such as Systems Thinking, MBSE, Axiomatic Design, Agile Design will be collectively referred to as Structured Design methods. This is because they share a number of the key attributes beneficial to an optimized design process and successful project execution. Structured Design methods follow a predefined methodology with the objective of reducing risk and the number of unplanned design iterations. The research project reported on here in part will attempt to obtain empirical evidence to support these observations first through literature research then research questionnaires, interviews, case studies and system dynamic modelling. A framework for evaluating the deployment of structured design methods in development projects will be put forward as an artefact of the research project. Design science research will eventually be used to evaluate this framework. The framework presented for proactive deployment of structured design methods within a development project is based on a model based systems engineering methodology and incorporates a systems thinking approach. The research findings is expected to give guidance to systems engineering practitioners on how to assess structured design methods considered for implementation in development projects. The paper provides novel approach to the deployment of structured design methods. Page 1 of 12

2 Key words: Deployment Structured design; Model based systems engineering; Framework; * Corresponding author. INTRODUCTION Projects continue to suffer schedule and cost overrun. One cause of this highlighted by Wessels (2012)is the conflicting relationship between systems engineering and project management. This is also emphasised by Martin when he elaborates on the conflicts between systems engineering and project management (Martin, 2000). Martin also focuses on the differences between systems engineering and regular engineering. The inherent nature of systems engineering is to work towards achieving requirements through an iterative process of design influencing and design change. The integrated approach as part of a systems engineering process to achieving requirements is also addressed for cases where technology and projects become increasingly complex (Rochecouste, 1996).Because of the unpredictable nature of this iterative process, projects are prone to failure. The unpredictability of new product development projects is also highlighted by Fernandez and others when they focus also on the issue of tight planning and coordination in such cases (Fernandes et al., 2009). This is because the project management process cannot account for the unpredictable systems engineering process impact. (Wessels, 2012) The purpose of this paper is to highlight the research done on the constructive and proactive deployment of design methods to improve the performance of systems engineering within the development project environment. Related work by Componation et al. (2009) and Elm et al. (2008) reported on studies of effectiveness of systems engineering and project performance in general. Research by the author is underway as part of a PhD project to further define the relationship between MBSE deployment and effective project execution in a complex design and construction environment. In the next section the research methodology is explained there after the deployment framework is introduced. This is followed by a section on the development of the deployment framework. The deployment framework is further elaborated regarding the systems engineering domains it includes. The paper then considers a case study of a major power industry development project to demonstrate the utilisation of the deployment framework. Aspects observed such as constructive and destructive iterative design cycles, the role of constructive design methods to support / induce constructive iterative design cycles and examples of constructive design methods are discussed. Systems dynamic modelling is also introduces as method of evaluating the impact structured design methods. RESEARCH METHODOLOGY For the purpose of the research presented in part here design methods such as Systems Thinking(Flood, 2010, Forrester, 1999, Forrester, 1994), MBSE(Estefan, 2007) as part of the field of Systems Engineering (Oosthuizen et al., 2016, Holland, 2015), Axiomatic Design(Guenov and Barker, 2005), Agile Design(Ferreira et al., 2007, Conboy et al., 2015) Page 2 of 12

3 will be collectively referred to as Structured Design methods. This is because they share a number of the key attributes beneficial to an optimized design process and successful project execution. Structured Design methods follow a predefined methodology with the objective of reducing risk and the number of unplanned design iterations. The research project reported on here in part will attempt to obtain empirical evidence to support these observations first through literature research then research questionnaires, interviews, case studies and system dynamic modelling. A framework for evaluating the deployment of structured design methods in development projects will be put forward as an artefact of the research project. A Design science research method(conboy et al., 2015)will eventually be used to evaluate this framework. INTRODUCING THE DEPLOYMENT FRAMEWORK This paper presents a framework for deployment of structured design methods proactively within a development project based on Model based systems engineering methodology and incorporating a systems thinking approach. The framework was derived from the conceptual model presented in the next section. The framework is also consistent with models presented by Erasmus and Doeben-Henisch (2011)and Long and Scott (2011). Table 1 illustrates a high level extract from this framework for the first two life cycle phases of a typical development project. Table 1: Extract from Framework for deployment of structured design methods Table 4at the end of article contains the complete framework. The framework is built around three system engineering domains namely Requirements, Design and Execution. The following sections explain the basis and development of this framework. FRAMEWORKDEVELOPMENT The deployment framework is derived from the conceptual model presented in Figure 1. The three perspectives of the system defined in the conceptual model: Requirements, Design and Execution, are mapped as the three parallel systems engineering domains of the framework. The framework is then mapped across the system life cycle phases from Requirements definition to Disposal. (INCOSE, 2015). Each system engineering domain, life cycle stage combination is then elaborated to give content to the framework. Complex design and construction environment Page 3 of 12

4 Client..Designer (s) Proje ct Goal Design Methods Design Baseline Contr actor (s) Figure 1: Conceptual model for deploying structured design methods the model presented in Figure 1 is founded on the principle that the system design, if considered to be an integrated system model, should be able to communicate the necessary information relevant to each stakeholder s perspective. (Long 2011) The following key aspects can be observed from the model in Figure 1 to demonstrate congruence with the principle above: I. The default perspective is suggested to be looking straight down on a conical shape like a hill, the project goal (ie integrated system meeting all requirements) being the highest point of the hill. There are also perspectives from each stakeholder. This represents the holistic or systems view as well as each stake holder s perspective of the same system design. II. The stakeholders (eg. client, designer and contractor) are aligned to the same goal although approaching from different perspectives. This is one the fundamentals of MBSE, to communicate various stakeholders according to their different perspectives. III. The three main domains of development are Requirements, Design and Execution. They are closely integrated to each other. The interface between domains is defined by a design baseline. The baseline between requirements and design domains will be the Requirements baseline. That between the design and execution domain the Design baseline. Between the execution and requirement domain the Validation baseline. IV. The framework represents a system towards dynamic equilibrium. That means the stakeholders are moving progressively towards the project goal centre of the model. If there is disruption eg unexpected change or obstacle effort needs to be applied to ensure that the stakeholders arrive at the intended goal. If not Page 4 of 12

5 successful the eventual end point will be somewhere off centre meaning the project was not entirely successful. For example there is some cost or schedule over run. V. Within this framework structured design methods are deployed to support the progression towards the project goal and are selected based on the characteristics of the design and construction environment. VI. The achieved goal during the project life cycle is reflected through the combination of the virtual and actual plant. MBSE provides a means to represent and communicate the virtual plant to all stakeholders throughout the project life cycle. SYSTEM ENGINEERING DOMAINS The three systems engineering domains used in the deployment framework represent three different perspectives to the system, which also aligned to the stakeholders perspectives introduced in Figure 1.Each domain represents the system life cycle and can be described in its own right. REQUIREMENTS DOMAIN The Requirements Domain focuses on the evolution of requirements through the project life cycle. It starts off with user requirements but then evolves through functional requirements, construction requirements and operating and maintenance requirements. The objective of this domain is not to explain how those requirements will be met rather to maintain a complete requirements definition throughout the project life cycle. This domain also focuses on the verification of requirements being met through the resulting design solution. DESIGN DOMAIN The Design domain is concerned with developing and documenting an executable design solution. The design evolved from a logic design through basic design, detailed design, as built design, as commissioned design and handed over design. The design is baselined at each stage in the design domain through a set of design documents or design data. EXECUTION DOMAIN The execution domain converts the design information into a virtual or physical plant model. Early stages are focused on virtual models, first logic models then architectural models, while later stages focus on physical plant being constructed, commissioned and handed over. The virtual and physical plant models also serve as a basis for validating the plant in its operating domain. BACKGROUND OF THE CASE STUDY As a case study the framework has been used to map out the dominant iterative design cycles resulting from design changes during project execution. The authors utilised design change data obtained from a major power industry project. Over the last 10 years nearly10,000 design changes were recorded on this project. The design changes recorded in the last three years ( ) were analysed during this case study. Page 5 of 12

6 Figure 2: Trend of design iterations during project life cycle The graph in Figure 2demonstrates the trend in design iterations during the life cycle of the project. There are distinct periods evident during the life cycle. I. Period 1: project start, initial design II. Period 2: major integration III. Period 3: Consolidation and convergence This trend represents a largely reactive approach. This is further emphasised by mapping the dominant types of design iterations against the framework in the next section. ANALYSIS OF DOMINANT ITERATIVE DESIGN CYCLE Table 2demonstrates the application of the framework to map out the iterative design cycles observed during the development project case study. Table 2: Mapping of observed iterative design cycles Page 6 of 12

7 The observed design iterations where classified in three broad categories: I. Design Errors (A) II. System Integration (B) III. System Improvements (C) Design Errors where further decomposed into detailed design errors (A1) and functional design errors (A2). The mapping done here is not exhaustive and only done to illustrate the utility of the proposed framework to understand the nature and consequence of design changes resulting in iterative design cycles. The design iterations classified as A and C are considered to be destructive as they essentially revert back to a prior life cycle phase. Design iterations classified as B is considered to be constructive as it takes place in the same life cycle phase. CONSTRUCTIVE VS DESTRUCTIVE ITERATIVE DESIGN CYCLES The reactive trend of iterative design cycles are considered to be destructive as the iterative design cycle tend to have larger cost and time impact (eg rework) as well as causing secondary changes. A conservative estimate would be that each reactive design change causes at least one secondary design change. An ideal state would be where proactive iterative design cycles could lead to the elimination of reactive design cycles at a lower cost and time impact. Reactive design iterations are one of the main causes of conflict between systems engineering and project execution as from a project management perspective these reactive iterations are eroding project value. ROLE OF DESIGN METHODS TO SUPPORT/INDUCE CONSTRUCTIVE ITERATIVE DESIGN CYCLES (CONSTRUCTIVE DESIGN METHODS) The case for front end engineering is well known, the principle being that major issues during project execution can be avoided with sufficient upfront engineering(steinert and Jablokow, 2013). This also holds for methods such as MBSE. The focus now shifts to understanding which design methods should be employed to achieve a meaningful benefit. There is a myriad of methods to choose from and not all will have the desired effect. Page 7 of 12

8 When analysing the framework presented in Table 2 with respect to the destructive or reactive iterative design cycles A and C observed, the need and place for proactive iterative design cycle brought about by constructive design methods becomes apparent. Table 3 demonstrates the introduction of constructive design methods to induce proactive iterative design cycles. Table 3: Introduction of constructive design methods If constructive design methods were to be introduced they are expected to result in constructive design iterations that can be mapped on the deployment framework by the arrows D, E and F as indicated in Table 3. The objective of these induced design cycles will be to minimise the reactive design cycles A1, A2 and C. SYSTEMS THINKING APPROACH The principle of proactive design iterations can also be demonstrated through a Systems Dynamics approach. Steyn (2017) expanded on a systems thinking approach to, with the use of system dynamic modelling, describe the relationship between conflict and project stress. Figure 3 illustrates how a causal loop diagram can be constructed that includes the influence of constructive design methods on the observed reactive design iterations. Page 8 of 12

9 Figure 3: Causal loop diagram for the effect of constructive design methods. EXAMPLES OF CONSTRUCTIVE DESIGN METHODS Constructive design methods should be selected based on their potential for delivering a desired outcome. For example the appropriate constructive design method for resolving physical interface issues during construction could be 3D modelling. This is typically what was observed in the design cycles denoted as B in Table 2. On the other hand logic design issues are best resolved early through the use of Executable Functional Block Diagram (EFBD). This will be a candidate method for inducing proactive design iterations denoted D in Table 3. Design improvements can be identified early through utilisation of axiomatic design principles and tools such as design matrices to identify coupled designs. This will be a candidate method for inducing proactive design iterations denoted E in Table 3. The objective of this case study is not be explicit about which constructive design methods to use but to point out that there is a logical framework for selecting the appropriate method to suite a desired outcome. It is even possible that completely new methods may be derived that are more suitable than existing methods to achieve a specific outcome in terms of the desired proactive iterative design cycles. EVALUATION OF METHODS The framework presented here also provides the opportunity to evaluate existing design methods in the context of the observed reactive iterative design cycles. This may lead to findings such that the existing methods are exercised at the wrong point the project life cycle; are not achieving the desired result; are the wrong method ect. Applying this reasoning the case study for instance reveals that insufficient effort is spent of verifying integrated logic design early in project life cycle. The methods used are not able to identify complex interface design issues resulting in design changes during construction and commissioning phases looping back logic design. FINDINGS Page 9 of 12

10 The relationship between Systems Engineering and project execution is conflicting in nature. In an unconstrained environment this may eventually be resolved. In a constrained environment, however, the capacity to resolve conflict diminishes to the detriment of project performance. Structure design methods need to be geared to proactively deal with this potential for conflict. It is therefore possible to take a proactive approach by employing constructive design methods to induce proactive design iterations early in project life cycle to reduce the reactive design cycles typically observed. This can be accomplished through a deployment framework as illustrated in this paper. It is suggested that through thorough analysis of the observed reactive design iterations appropriate proactive design iterations can be identified and introduced at earlier phases in project life cycle. The consistent and early adoption of such a design management strategy will help reduce the project stress through avoidance of cost and schedule increases. RESEARCH LIMITATIONS AND IMPLICATIONS The research presented in this paper is limited to a case study of a major power industry development project in South Africa. The case study is however relevant and findings transferable to other areas because of the extended period over which data were collected and general nature of the observations. The research findings is expected to give guidance to systems engineering practitioners on how to assess structured design methods considered for implementation in development projects. ORIGINALITY/VALUE OF THE PAPER The paper provides novel approach to the deployment of structured design methods. CONCLUSION The framework presented here does provide a usable methodology for deployment of constructive design methods including MBSE within a development project. The relationship between constructive design methods and the desired outcomes are evident and suitability of existing design methods can be assessed. ACKNOWLEDGEMENTS REFERENCES Componation, P. J., Utley, D. R., Farrington, P. A. & Youngblood, A. D. Assessing the Relationships between Project Success and Systems Engineering Processes at NASA. IIE Annual Conference, Institute of Industrial and Systems Engineers (IISE), pp Conboy, K., Gleasure, R. & Cullina, E. Agile design science research. International Conference on Design Science Research in Information Systems, Springer, pp Elm, J. P., Goldenson, D., El Emam, K., Donatelli, N., Neisa, A. & Committee, N. S. E A Survey of Systems Engineering Effectiveness-Initial Results. Erasmus, L. D. & Doeben-Henisch, G. A theory for the systems engineering process. AFRICON, IEEE, pp Page 10 of 12

11 Estefan, J. A Survey of model-based systems engineering (MBSE) methodologies. Incose MBSE Focus Group, 25. Fernandes, A. A., Da Silva Vieira, S., Medeiros, A. P. & Natal Jorge, R. M Structured methods of new product development and creativity management: A teaching experience. Creativity and Innovation Management, 18, Ferreira, J., Noble, J. & Biddle, R. Agile development iterations and UI design. Agile Conference (AGILE), IEEE, pp Flood, R. L The relationship of systems thinking to action research. Systemic Practice and Action Research, 23, Forrester, J. W System dynamics, systems thinking, and soft OR. System dynamics review, 10, Forrester, J. W System dynamics: the foundation under systems thinking. Sloan School of Management, Massachusetts Institute of Technology, Cambridge, MA, Guenov, M. D. & Barker, S. G Application of axiomatic design and design structure matrix to the decomposition of engineering systems. Systems engineering, 8, Holland, O. T Model-Based Systems Engineering. Modeling and Simulation in the Systems Engineering Life Cycle. Springer. Incose Systems Engineering Handbook, Wiley, (San Diego). Long, D. & Scott, Z A primer for model-based systems engineering, Lulu. com, Martin, J. N. Systems Engineering is Not Just Engineering Or is It? A Critical Look at the Scope of our Profession. INCOSE International Symposium, Wiley Online Library, pp Oosthuizen, R., Swart, I. & Pretorius, L. An initial bibliometric analysis and mapping of systems engineering research. INCOSE International Symposium, Wiley Online Library, pp Rochecouste, H. Engineering Information Systems and the IEEE Std INCOSE International Symposium, Wiley Online Library, Steinert, M. & Jablokow, K. Triangulating front end engineering design activities with physiology data and psychological preferences The Design Society. Steyn, P. J., Pretorius, L Aspects of Systems Thinking and Model Based Systems Engineering (MBSE) in Project Management. 5th Annual System Dynamics Conference. Johannesburg. Wessels, A The Development of Complex Systems: An Integrated Approach to Design Influencing. Philosophiae Doctor, University Of Pretoria. Page 11 of 12

12 Table 4: Full Deployment framework Page 12 of 12