A theory for the systems engineering process

A Theory for the Systems Engineering Process Louwrence D Erasmus Gerd Doeben-Henisch Graduate School of Technology Management University of Pretoria Pretoria, 0002 South Africa Email: [email protected] Department of Intelligent Systems University of Applied Sciences Nibelungenplatz 1, 60318 Frankfurt am Main Germany Email: [email protected] Abstract—A theory for describing the systems engineering process using formal mathematical structures is presented in this paper. This abstraction of the systems engineering process makes it possible to concentrate on the operations and structures involved in the process without the distraction of the narrative word. An important aspect in the formulation of this theory is the inclusion of people as part of it. Further development of the theory will lead to the implementation of the mathematical description in simulation software to study the dynamic characteristics of and interaction of people with the systems engineering process as well as systematically validating the theory through empirical studies. I. I NTRODUCTION The engineering of systems [18] and the management of the process [19] to achieve that is addressed in the subject area of systems engineering [5], [4]. This makes the subject of systems engineering falling in the field of engineering as well as management sciences as noted in [17]. Currently, no theories are known in systems engineering that are based on the dual character of the the subject, i.e. a strong mathematical foundation combined with management theory. This paper proposes a theory to enable the development of mathematical models describing the systems engineering process. In future, this theory should be expanded to include the management of the process over an entire system life cycle to address the broader topic of the engineering of systems. In this paper, the term ’theory’ is used in the tradition of philosophy of science as treated by the structuralist programme [6], [27], [2], [3], [15]. In the structuralist program a theory is a mathematical structure containing sets, relations, and some axioms. Doeben-Henisch et.al. [13] made a first attempt to apply this theory concept in describing an engineering process. This is a more formal form of treating research compared to the current research practice in systems engineering which includes the usual case studies [8], the proposed quasi-scientific methods with an experimental group and control group [26], or the usual empirical studies as performed in management science [28]. The current research practice describes strong or weak statistical correlations between parameters based on hypotheses derived from descriptions [8] and without formal mathematical models. There are three possible aspects to a research project in engineering and technology management [8]: 1) Testing of existing theories, models and methods. 2) Application of existing theories, models and methods to a new problem. 3) Construction of new or improved theories, models and methods. The current agenda for the development of the intended theory is first to achieve the testing of existing theories, models and methods in systems engineering through simulation that are validated with empirical measurements from systems engineering practice. These validated models can then be used to study the dynamic characteristics of the systems engineering process. A. Process context The scope of systems engineering activities in [9] consists of three main activities, i.e. systems engineering process, development phasing and system life cycle integration. This paper focuses on the development of a mathematical theory for the systems engineering process. The other two activities are not addressed here but the mathematical formalisms for development phasing and system life cycle integration should be addressed in future work. Further, the results of interactions between the activities (baselining, life cycle planning and integrated teaming [9]) should also be treated as mathematical formalisms in future. If all these identified mathematical formalisms would be combined a theory for Systems Engineering or Systems Engineering Management can be formulated in terms of the model presented in [9]. In a simple form, the systems engineering process consists of four subprocesses, i.e. requirements analysis, functional analysis and synthesis with the support of the systems analysis subprocess [9]. International standards [19], [18] and discipline handbooks [4], [5], [22] have augmented the four subprocesses with refinements to the main subprocesses and further description of implementation, verification, validation, support and management processes to achieve the engineering of systems. II. P REVIOUS FORMALISM A first formalism for an engineering process has been done in [13] as per Figure 1. The elements in this figure are characterized as follows [13]: Fig. 1. The general structure of the behaviour model MS−R can be described as a sequence of combined states hz0 , ..., zf i. A combined state z is defined by the driving task set Γ, the participating surfaces of the user called user interface (UI), the intended system interface (SI), and the assumed environment interface (EI), thus, zi ∈ Z ⊆ Γ × IN T FU × IN T FS × IN T FE . A state change from a state zi to a state zi+1 is caused by an action αi ∈ ACT ⊆ Z × Z. Every sequence p of states for which it holds that (zi , zi+1 ) ∈ αi is called a usage process or short behaviour of the behaviour model. The complete set of all possible behaviours of MS−R is described by the generating function δ that maps a start state z0 into the possible usage processes ending in the final states or goal states. A complete behaviour model MS−R can then be defined as Selected Elements of the Engineering Process “The process starts with a problem P of a stakeholder. Through a communication process the systems engineer translates P into a behaviour model MS−R 1 that represents the complete expected behaviour of the system to be designed: requirements : P −→ MS−R (1) It is a known problem that this communication includes the semantic gap problem which is rooted in the communication between the stakeholder and the engineer and the inherent difficulty to clarify the meaning of the terms used during the communication [12]. Based on MS−R , the systems engineer develops during the design a system model MSYS which has to be verified: design : MS−R −→ MSYS verif ication : MS−R × MSYS −→ V (2) (6) where GF ⊆ Z is a set of goal states which shall be reached starting with the beginning state S. The constraints induced by the systems engineering process challenge the systems engineer to specify the required properties of a system in terms of its observable behaviour, including the interactions with the users and the environment.” A nontrivial aspect of this modeling is the interpretation of the task set Γ at least by the user U . This presupposes that a single task τi ∈ Γ is given as some string written in some language LΓ which can be interpreted by the user U . Usually is this interpretation not part of the behaviour model. But with regard to training and testing of users it could be necessary to include a complete specification of the language LΓ as well as their intended interpretation I by the user. The semantic of the language LΓ has as its domain of reference the complete behaviour model MS−R . (3) The MSYS is converted into a real system MSYS∗ which again has to be validated. Validation is realized as a measurement process: implementation : MSYS −→ MSYS∗ MS−R = hΓ, IN T ERFE/U/S , Z, ACT, δ, S, GF i (4) validation : P × MS−R × MSYS∗ 7−→ V (5) where V is a set of validation values indicating the correlation between the behaviour model MS−R and the system model MSYS . The process to convert P (in the non-symbolic space) into formalized requirements MS−R (in the symbolic space) and the symbolic system model MSYS into the real system MSYS∗ cannot be fully automated, because full automation is restricted to the symbolic space. The challenge of relating symbolic and non-symbolic spaces with each other also occurs during validation, when non-symbolic objects are compared with a symbolic description [12]. 1 The S − R index reminds one of the stimulus-response paradigm from the experimental behaviour sciences (cf. [25], [7]). III. C ONSTRUCTING THE THEORY The previous formalism for the description of the engineering process above is not sufficient. Terms used in it are still restricted to primary objects of the systems engineering process (i.e. problems, behaviour models, design models, etc.) but the main actors of this process, i.e. the stakeholders and discipline experts, are not included. To rectify this critical oversight, the formalism must be expanded. This expansion is treated in the following subsections. A. The formalism The main difference between the current proposed formalism and the previous formalism is the inclusion of the main actors of the systems engineering process, i.e. the stakeholders S and the different discipline experts E. Additionally there can be different kinds of knowledge encoded in documents2 D as well as support systems A used as enablers in the systems engineering process. The original requirements operator in (1) is extended to 2 Document is used in the widest sense of the word. • actors, objects, events, and actions which is commonly understood as the systems engineering process. Another mapping will be introduced incrementally into a defined simulation process, which in turn should be sufficiently similar3 to a real-world systems engineering processes. B. The semantics Fig. 2. Semantics of the formalism for the systems engineering process requirements : S × E × A × D −→ P × MR (7) where the symbol MR means functional requirements MF and non-functional requirements MN F with the behaviour models MS−R assumed to be equivalent to MF , thus MR = MF ∪ MN F (8) Thus, the problem description P together with MR are the products of the requirements analysis subprocess. The enablers for the process is the stakeholders, experts, support systems and additional documents. With a similar argument, the operators in (2) and (4) are expanded: design : implement : E × A × MF −→ MS (9) E × A × MS × MN F −→ MS∗ (10) Here MS replaces the previously used MSYS . Based on these formalizations one can introduce the theory for the systems engineering process as Σ(x) iff hS, E, A, D, P, MR , MS , MS∗ , ρ, δ, ιi (11) where the operators are abbreviated as follows: The above formalism of the theory gets its meaning from the underlying empirical processes of real-world engineering. This includes a multitude of complex phenomena. Some of these phenomena include: 1) The main actors of the systems engineering process, i.e. stakeholders S and the discipline experts E. 2) Besides the discipline experts E one has to assume an additional set of support systems A. 3) There are different kinds of knowledge sources indicated in the theory as documents D used by the actors and support systems. 4) Usually there is not one but multiple processes and subprocesses active at a time. 5) The processes can be distributed over many physical or logical locations. 6) Processes can execute synchronously or asynchronously, periodically or aperiodically. 7) Processes can execute in parallel or sequentially. 8) Process can execute iteratively. 9) Different kinds of communication exists between processes. 10) Human communication processes are mostly mediated through languages which have open meanings embedded in open grammars. 11) The actions of humans are based on internal mental models which are the outcome of individual learning processes. 12) Human behaviour is influenced by internal motivations/ emotions/ drives as well as physiological states. From this it can be concluded that the human factors of the stakeholders and discipline experts play a major part in the outcomes and performance of the systems engineering process. The interfaces between subprocess, the humans and support systems along with the embedded communication implied them are therefore fundamental to the systems engineering process. IV. R ELATIONSHIP ρ := δ := ι := requirements design implement But, for turning (11) into an empirical theory, one has to provide a mapping (called semantics) from these formulas into the intended domains. This will be achieved twofold: • A mapping will be introduced incrementally from the formal parts of the theory into a real domain of those WITH CURRENT PRACTICE The requirements mapping described in (7) corresponds to the requirements loop described in [9], while the design mapping in (9) corresponds to the design loop in [9]. The requirements loop consists of the execution of the requirements analysis and part of the functional analysis subprocesses [9]. The design loop consists of the execution of part of the functional analysis and synthesis subprocesses [9]. 3 The definition of being sufficiently similar will be addressed in the future The implementation mapping described in (10) is in the past not described as part of the systems engineering process. The result of the systems engineering process is a data pack [19], [9] that specifies the necessary products and processes to be implemented during the manufacturing and test process [19]. In [18], though, is the implementation subprocess described as part of the technical processes in the life cycle for the engineering of systems which should not be confused for the systems engineering process. A. Requirements Loop The requirements loop is described in [19] by the requirements analysis subprocess (PRA ) that implicitly executes the functional context analysis subprocess (PF C ) as well. If PRA + − is assumed to consist of two processes (PRA and PRA ) that precedes and follows PF C , then requirements = + − PRA ◦ PF C ◦ PRA Fig. 3. The requirements analysis subprocess transforms the problem of the stakeholder P into functional requirements MF , including functional performances, and non-functional requirements MN F , including the life cycle quality factors [19]. B. Design loop The design loop is described in [19] by the functional decomposition (PF D ) and synthesis subprocesses (PS ) and can be expressed as: design = PS ◦ PF D Human-Factors Engineering Example (12) (13) During the functional decomposition subprocess PF D , the functional behaviour models in MF are further decomposed into a functional architecture in MS to make it possible to define alternative subfunction arrangements and sequences, their functional interfaces and their performance requirements [19]. A systems analysis is performed in order to select a balanced set of subfunctions and to allocate performance requirements in MF to subfunctions to assure that the preferred functional architecture satisfies the system requirements [19]. During synthesis (PS ), the functional architecture in MS is translated into a design architecture in MS that provides an arrangement of system elements (hardware, software or people), their decomposition, internal and external interfaces, and design constraints [19]. A preferred design solution is selected from a set of alternatives based on the associated cost, schedule, performance and risk implications using the systems analysis subprocess for assessing design alternatives. C. Example Human Factors Engineering Figure 3 illustrates the formal structure of a behaviour model MF as part of the general theory Σ which describes the intended outcome of the functional requirements analysis. As described in the common human machine interaction (HMI) literature [10], [20], [21], [14], HMI is part of the requirements and design process for exploring the optimal parameters of the intended system interface with regard to the intended users and their tasks (including environmental factors). While this paradigm is well known and discussed in numerous publications it should be realized that within the intended systems engineering theory Σ this HMI-view should also be applied on the acting engineers themselves. In the primary view of the Σ-theory the systems engineering experts E, the stakeholders S, and even the supporting systems A are the ’users’ which interact with each other in an engineering environment. Their task is the developing of a new system and the systems engineering process should be supported in this. This includes that the engineers as the main actors need an appropriate mental model which enables them to find the adequate solution. The above mentioned simulation dimension (see also Figure 1) can be viewed from the perspective of the acting experts and stakeholders. The simulations have to support these actors and should be smart and adaptive to be able to give advice when needed. Future expanded version of the Σ-theory will include an additional ’user interface’ to the whole process for the management aspects of the systems engineering process. V. C ONCLUSION In this paper a programme for the development of a structuralist theory is presented for the engineering of systems. An important aspect in the formulation of this theory is the inclusion of people as part of the systems engineering process. Although assumptions are made to simplify the initial formulation of the theory, it can be appreciated that the engineering of systems is a complex topic that needs this theory. Further work still needs to be done to bring the theory closer to current practice. A research programme will be formulated based on this theory and the programme status will be reported on the website http://www.os-pe.org in the Internet. Empirical research into practices used in industry will also be used to calibrate the theory. Further development of the theory will also be undertaken to address the identified short comings and simplifying assumption pointed out in this paper. Some of the models can be implemented with stock and flow models as used in the systems dynamics arena [23]. In general the models can be implemented on the OKSIMO simulator platform [11], [24] as the formulation of the theory in this paper is compatible with the underlying theory of the OKSIMO simulation platform. It is the intension also to cooperate with the development team of OKSIMO to make simulations of the theory in this paper possible. This theory for the engineering of systems is a contribution for a better understanding how to establish a theoretical basis for systems engineering and engineering management. R EFERENCES [1] Alexander, I.F. & Stevens, R.; Writing Better Requirements. AddisonWiley, 2002. [2] Balzer, W., Empirische Theorien: Modelle, Strukturen, Beispiele, Wiesbaden (Germany): Friedr.Vieweg & Sohn, 1982 [3] Balzer, W.; Moulines, C. U.; Sneed, J. D., An Architectonic for Science, Dordrecht (NL): D.Reidel Publishing Company, 1987 [4] Blanchard B.S., System Engineering Management, Wiley, 4th edition, 2008. [5] Blanchard B.S. & Fabrycky W.J., Systems Engineering and Analysis, Prentice-Hall, 5th edition, 2010. [6] Bourbaki, N., Theorie Des Ensembles, Paris: Hermann, 1970 [7] Bower, G.H; Hilgard E.R. Theories of learning, 5th. ed., Prentice-Hall Inc., 1981 (with a german edition: Theorien des Lernens, Vol.1+2, 5th. rev.ed., Stuttgart (Germany): Klett-Cotta, 1983, translated by Aebli, H.; Aeschbache , 1983, 1984) [8] Bus, A.; Research Guide For Post-Graduate Students. Issue 18. Graduate School for Technology Management, University of Pretoria, South Africa, 2007. [9] Defense Acquisition University; Systems Engineering Fundamentals. Defense Acquisition University Press, Fort Belvoir V.A., USA, 2001. [10] Dix, A.; Finlay,J.E.; Abowd,G.D.; Beale, R.: Human-Computer Interaction. Pearson Education, 2003, 3rd.ed. [11] Doeben-Henisch, G.; The planet Earth simulator project - a case study in computational semiotics, AFRICON, 2004. 7th AFRICON Conference in Africa, Publication Year: 2004 , Page(s): 417 - 422 Vol.1 [12] Doeben-Henisch, G.; Wagner, M. Validation within Safety Critical Systems Engineering from a Computational Semiotics Point of View, In: IEEE Africon2007 Intern.Conference, Windhoek (Namibia), Sept.2007 [13] Doeben-Henisch, G.; Bauer-Wersing, U.; Erasmus, L.; Schrader,U.; Wagner, W. Interdisciplinary Engineering of Intelligent Systems. Some Methodological Issues, part of the ’Proceedings of the International Workshop Modelling Adaptive And Cognitive Systems (ADAPCOG 2008)’ , Joint Conferences of SBIA’2008 (the 19th Brazilian Symposium on Artificial Intelligence); Salvador (Brazil) Oct-26 - Oct-30, 2008. As chapter in the E-Book: Angelo Loula & João Queiroz (Eds.), ADVANCES IN MODELING ADAPTIVE AND COGNITIVE SYSTEMS, URL: http://www2.uefs.br/graco/amacs/ [14] Dumas, J.S.; J.E.Fox, Usability Testing: Current Practice and Future Directions, In: Sears, A.; Jacko, J.A. (Eds.): The Human-Computer Interaction Handbook. Fundamentals, Evolving Technologies and Emerging Applications., New York - London: Lawrence Erlbaum Associates, Publ., 2008, 2nd.ed., pp.1129 - 1150. [15] Erasmus, L.D. The Formulation and Evaluation of a Neuron Model Based on Biological Neurons, PhD-Thesis, Potchefstroom: North West University, 2007 [16] Graduate School of Technology Management. Online: http://www.up.ac.za/gstm (Accessed on 24 March 2011). [17] INCOSE, Systems Engineering Hanbook - A “How to” guide for all engineers. Version 2.0 International Council on Systems Engineering, July 2007. [18] ISO/IEC 15288:2007, System Life Cycle Processes. International Organisation for Standards, Geneva, Switzerland, 2007. [19] ISO 26702:2007/IEEE Std 1220-2005, IEEE Standard for Application and Management of the Systems Engineering Process. International Organisation for Standards, Geneva, Switzerland, 2007. [20] Lauesen, S.: Task Descriptions as Functional Requirements, in: IEEE Software 2003, March/April, pp. 58-65. [21] Lauesen, S.: User Interface Design. A software Engineering Perspective. London et al:Pearson - Addison Wesley, 2005. See also the Webpage with additional Material: http://www.itu.dk/ slauesen/SorenUID.html [22] Martin, J.N., Systems Engineering Guidebook, A Process for Developing Systems and Products. CRC Press, Boca Raton, USA, 1997. [23] Morecroft, J. Strategic Modelling and Business Dynamics: A Feedback Systems Approach. John Wiley & Sons, 2007. [24] Open Knowledge Simulation Modeling. Online: http://oksimo.inm.de/ (Accessed on 24 March 2011). [25] Skinner, B.F., Science and Human Behavior, New York et al: The Free Press, 1953 [26] Sparrius, A. Is system engineering a cargo-cult science? INCOSE SA Conference Proceedings, Pretoria, South Africa, August 2010. [27] Suppe, F. (Ed.), The Structure of Scientific Theories, 2nd. ed., Urbana: University of Illinois Press, 1979 [28] Valerdi, R. and Davidz, H. L. (2009), Empirical research in systems engineering: challenges and opportunities of a new frontier. Systems Engineering, 12: 169–181. doi: 10.1002/sys.20117