Chapter 3: Literature Study
3.2 Systems Engineering
As mentioned in the previous chapter, SE is an approach currently used for the realization of D&C projects in the construction industry. In this chapter the basis of the SE methodology is explained, including all main processes within. This is done to get a clear view of how the projects are generally organized. Afterwards, in paragraph 3.3 and 3.4 the role of interface and configuration management within the SE literature is explored and practical guidelines are evaluated.
3.2.1 What is Systems Engineering?
System Engineering is an approach to systematically organize complex projects and has been introduced especially for D&C projects in construction. After the use of SE in the telecommunication industry and other sectors, SE has become a much used standard in the construction sector (Rijkswaterstaat, 2009). According to The International Council on Systems Engineering (INCOSE) SE can be defined as:
‘An interdisciplinary approach and means to enable the realization of successful systems. Systems engineering
considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.’
It is an interdisciplinary approach which contributes to develop and realize successful systems. With SE not only the technical requirements are met but it also strives to meet all the interests of involved stakeholders (Rijkswaterstaat, 2009).
For the implementation of System Engineering in the construction sector the NEN-ISO/IEC 15288 “Systems and software engineering - System lifecycle processes, 2008” is often used as guidance. Out of this standard more standards have been developed for the implementation of SE in the civil engineering industry. Examples of these guidelines are INCOSE’s Handbook “Systems Engineering Handbook, a guide for system life cycle processes and activities” and in the Dutch construction sector the “Leidraad voor Systems Engineering binnen de GWW-sector” developed by Rijkswaterstaat and Prorail and “SE-Wijzer Handleiding Systems Engineering voor BAM Infra” developed by the Koninklijke BAM groep.
The most common model used in these handbooks is the V-model in which the processes of system engineering are explained step by step, see Figure 7. The emphasis of the V-model is on the relation between the integration, verification and validation of the system (right part of the V-model) and the requirements and design of the system (left part of the V-model).
14
Technical University of Delft Ballast NedamFigure 7: V-model (Stevens & Brook, 1998).
The left path of the V-model represents the requirement analysis and the design phases and the right path represents the integration phases. To each design phase corresponds a verification phase. For instance, the design of components is verified by the components test, the subsystem design is verified by the subsystem test and so forth. The left path of the diagram includes decomposition of requirements and creation of system specifications in a design. Those processes (decomposition and creation) are achieved by breaking up a system in subsystems in order to reduce its complexity, and to allow several design teams to work independently. For this purpose, the left branch of the diagram describes decomposition where each design level gives more functional and architectural details than the previous one. The right path of the V-diagram corresponds to integration and verification, which is the construction phase where components are merged together into sub- systems and ultimately, into the final system.
Left side v-model
The client formulates a list of functional requirements and puts the request out on the market. The contractor, who is responsible for both the design and construction phase, has to come up with a design which complies with these requirements. In order to prove that the requirements are met, a verification plan has to be formed and executed during the process development. The design process consists of different stages, before the tender a conceptual design is realized in where the broad design is displayed. When the client rewards the project to the contractor, the conceptual design will be further detailed into a preliminary design and ultimately a detailed design. Each phase consists of more detailed drawings of the project.
15
Technical University of Delft Ballast NedamFigure 8: System Breakdown Structure
Decomposition
Within systems engineering, the design procedure consists of decomposing the complex system into a set of sub-systems, which may be further divided into components. The systems engineering approach for product development will ultimately decompose the design effort down to a point where individual teams of engineers will have the task of designing a component, which is a small portion of the overall system that is manageable for the given development schedule. These individual teams of engineering have different backgrounds such as structural, mechanical and electrical and usually work separately from each other (Zummo, 2010). The decomposition is usually done with a System Breakdown Structure (SBS), see Figure 8. The SBS is a tree of components which form sub-systems and eventually the system. Every layer of the tree consists of more details. By decomposing a system, components are formed which are easier to manage and could be designed by one design team. These components increase the overview of the project. Usually two types of divisions, or a combination of these, are used for the decomposition. One of these divisions is geographically, in which the system is split up in sub-systems based on physical areas and locations. This approach is used to increase the visibility and coherence of the system. The other way of breaking down is by dividing the system into parts based on the engineering disciplines. In this way it is easy to assign the several design teams to their part of the job. However, the risk of this classification is that the coherence of the system gets too little attention leading to interface problems (BAM, 2008). The classification and the level of detail of the SBS, largely determines the amount and type of internal interfaces which the project has to deal with. Since the complexity of a system is related to the pattern of the relationships between the components, the classification of this SBS should not be underestimated.
All components in the SBS have a specific ID number and will deliver a design document (i.e. drawings) ready for construction. The more components there are, the more formal documents have to be developed and the more interfaces exist between the components. On the other hand, if the sub-system is not decomposed enough components derive which are disorderly and hard to allocate to an individual team of engineers. A balance has to be found in here. The SBS is purely used to split the project in manageable parts of which the scope is clear and to make sure that nothing will be left out of the project.
All components derived in the SBS make part of the final system and can be designed by individual design teams. However, these components also have to complement each other to form the total system. As said,
16
Technical University of Delft Ballast Nedam most components have some kind of relationship or interface with each other. These interfaces have to be recognized and taken care off as soon as possible in order to integrate the designs successfully.Right side v-model
Next to the SBS, a Work Breakdown Structure (WBS) will be developed, which is derived from the SBS. This WBS is a scheme of all work packages which has to be executed in order to construct the project. The WBS shows the hierarchy of all work packages. Each work package is a package of related activities on behalf of an object with a defined input and output. By using these work packages a connection is created between content, time and money. By executing these work packages, components and sub-systems are integrated into the final system. That is why this right side of the V-model is also defined as System Integration.
System Integration is the term used for the integration of all components and sub-systems in the construction phase leading to the final system. The system integration process represents the first time that fully engineered components and subsystems are linked to one another to perform as a unified functional entity, see Figure 9. However, despite the best plans and efforts, the integration of a system containing newly developed elements is almost certain to reveal unexpected incompatibilities (Kossiakoff, et al. 2011). It is even said that the iterative aspect of design and the associated rework is fundamental to any complex system (Browning, 1998).
Figure 9: System Integration (Eppinger, 1997)
Integration consists of linking components and sub-systems together which could expose faults at their interfaces. Failures in high levels of the right path of the V-model strongly delays the product development process. Problems at the system level are hard to solve because they involve the entire system and, consequently, it is a multidisciplinary problem that is linked to the conceptual design phase. These problems can be of physical nature as well as of functional nature. To solve these problems the design often has to be (partly) adapted. These unexpected incompatibilities show the importance of an early detection of possible design failures to avoid these time consuming iterations.