Building the System Interface Management Environment for the Development of Complex System 1

Advanced systems have common characteristics of complexity as the level of their demanded emergent capability and the resulting interfaces among their components increase. These characteristics make it difficult to manage the interfaces and the failure of the management can lead to the failure of development projects. This study proposes a model-based systems engineering approach to facilitate the interface management for an IPT environment. A demonstration of the proposed approach to the magnetic levitation railway development project is provided to identify and control interfaces.


INTRODUCTION
The state-of-art systems are evolving towards larger size and more complex interaction among subsystems.In other words, the management of interface has become difficult as the target system has an increasing number of internal or external interfaces.Management of system interface is very important for the development of system architecture.That is because inappropriate management of internal/external interface in system may lead to the failure or delay of system development (Lane, 2009;Han et al., 2014).In particular, the System of System operated through interaction of multiple systems involves participation of many project contractors for each system.These organizations have unique interface development environments which are difficult and consequently may cause conflict among organizations.
This study deals with the cases of interface management environment for the project preceding the magnetic levitation train project.
Problem statement: First of all, In this case, we can identify the problems mentioned earlier.Some organizations of companies and many research institutes which are participating in this project do not have clear in-house regulations pertaining to the interface management.In addition, the remaining companies and organizations that have enforced such regulations have different management environment.Therefore, it was necessary to create the interface management environment that will be used jointly by those organizations to help ensure success of the project.
Second, this project has some problem with the development process.As the development schedule did not take the design process into consideration, the interface control has become extremely difficult.Figure 1 shows the project program of each development organization identified in RFP of this project.While the system engineering contractor A.A generates the operational concept, contractor B.A undertaking the development of train system, one of the system components, determines the Specification.
Contractor C.B who develops the railway simultaneously carries out the detail design of this system.In that way, different processes result in extreme difficulty with interface and shape control for each contractor's outcomes and consequently, may lead to the re-design or fatal failure of system.
The purpose of this study was to provide a development environment for the Integrated Product Team (IPT) of each organization to carry out common interface management activities for the preceding research on magnetic levitation train project.

METHODOLOGY
System engineering process: In general, the development precedents can be found for commercial system development projects.The risk and operational burden can be mitigated significantly if the legacy architecture is reused.
Sage defined the product re-engineering as reconfiguration of conventional products' internal mechanism or functions into functional and nonfunctional form through the inspection, research, identification and modification of such internal mechanism or functions in order to apply new technology while achieving essential objectives of conventional products (Sage and Lynch, 1998;Sage and Rouse, 2009).According to the definition drawn by Sage, re-engineering means the product process that involves the sequence of forward-engineering, reverseengineering and re-engineering.Figure 2 presents a diagram of the re-engineering process.The reengineering process implements the net-engineering process that carries out the requirement definition process by identifying the needs and system concepts of initial stakeholders.In addition, the re-engineering process carries out reverse-engineering process that derives system requirements by analyzing the reference system.Finally, along with the requirements that have been derived in that way, the re-engineering process is implemented to carry out the solution definition process again by integrating the requirements that have been generated earlier.
While performing the re-engineering process, the interface obtains interface relationship between the system of reference system or sub-components in the process of reverse-engineering and is identified through the solutions definition process for the target system in the re-engineering process.The interface, which has been identified by implementing the re-engineering process in the aforesaid way, is managed through CASysE Tool.CASysE tool: Currently, many system engineers are using the 'Computer Added System Engineering Tool' to perform the Model-Based System Engineering design and many related cases can be found (Do and Cook, 2012;Bonanne, 2014;Matar et al., 2014;Scheeren and Pereira, 2014;Góngora et al., 2015).MBSE presents reasonable alternative systems through the modeling and simulation from various viewpoints at system level and the response to the vast amount of information by using the computational support tool, thereby reducing the number of prototypes that are created.Moreover, MBSE can ensure traceability for various requirements ranging from stakeholders' requirements to system validation requirements and increase productivity of works.The system design data, built into database, can facilitate the use and reuse of information related to the existing system in the development of similar systems In this regard, the use of system engineering computational support tool (CASysE Tool) will facilitate system engineering process implementation ranging from the analysis of requirements to the realization of system architecture.Using this tool, the magnetic levitation train project provided simultaneous development environment of many developers and particularly, interface management environment.In this study, the Cradle of 3SL Co was used as the tool.
Then, to build the integrated interface management environment that uses the computational support tool, the definition of schema is required which defines the data elements, relationship among such data elements and attributes of the elements.
Figure 3 presents the schema built for the identification and control of interface in this study.The following Chapter describes the re-engineering process that has been explained above and the interface identification and control activities using the computational support tool that supports the interface management environment within the re-engineering process.
Case study: Magnetic levitation (maglev) transit system: In this Study, we discuss the cases of magnetic levitation (maglev) transit system project.Magnetic levitation train system makes the vehicle levitate at some height over the track and has the system operation concept different from that of existing railway system (Han et al., 2014).Rail system has high maturity architecture and therefore the use of legacy architecture can be used when developing new systems.This case involved application of re-engineering process to reduce development effort and cost and used the light train system as legacy system.The re-engineering process will be introduced in the following section.
Figure 4 presents the diagram of physical architecture of magnetic levitation train system that reuses the architecture of conventional train system.As the vehicle is changed to magnetic levitation train, new requirements have arisen for the form item of other 6 systems that interact with this subsystem.The functions of magnetic levitation train system are realized through complex interactions between subsystems.Therefore, strict and rigorous management is required to resolve the interface problems arising from the change in the form items of each subsystem.

Selection of legacy system:
The system that has the most similar operation concept is selected based on the needs and concept which have been defined from customers and stakeholders.Urban magnetic levitation train system has the operation concept which is the most similar to that of Lightweight Train (LRT) system.The selected system, which is the legacy system, can sequentially derive the physical-functional requirement architecture through the reverse-engineering process of re-engineering process.

Identification of LRT system interface:
The interface and physical hierarchical structure of system were verified through the related documents such as OCD, System Spec., URD, ICD, IDD, etc., of the lightweight train system which was selected as legacy system.LRT consists of 5 subsystems as shown in the Fig. 5.
As the physical hierarchical structure of these systems is clearly identified, the interface between them becomes clear.The identified interfaces are maintained in the new system, excluding the interfaces that are not affected by the physical components that will be changed or added in the re-engineering process and the interface that have become unnecessary due to such physical components.If the system requirements are finally identified after the functions are derived through physical hierarchical structure, the re-engineering process is implemented by integration with original requirements that have been obtained through netengineering process.
Figure 6 presents a diagram of physical hierarchical structure refined through the re-engineering process.Although the change cannot be figured out at the Lv.1 level, we can ascertain the functional/physical The area marked in red within each system block represents the change in physical components as compared to the reference system.The width of the area is proportional to the quantity of modified components.In addition, the width of the area is proportional to the quantity of internal/external interface of the system affected (which therefore requires the review by ICWG) by the change in components.
The interfaces that have been identified through aforesaid process are fed into the interface form presented in Fig. 7.This interface form includes the detailed description that specifies the name, scope and function of interfaces, along with the explanation of components targeted for interface and interface relationship among components.
In this study, we applied DSM to ensure easy representation of interfaces.It was found that this model was applied extensively for development as this model allows the interfaces between system components to be easily represented and understood.This study specifies the 4 types of definitions for interface category between components to apply DSM, as presented by Pimmler and Eppinger (1994).Scores were added, depending on the importance of energy exchange, information exchange, materials exchange, physical space and arrangement and interface among components.
The clustering which can be implemented through DSM provides powerful system integration analysis function (Pimmler and Eppinger, 1994;Smith and Eppinger, 1997;Rushton and Zakarian, 2000;Browning, 2001;Gorbea et al., 2008;Shamsuzzoha et al., 2010).However, this clustering is not dealt with in this study and was limited to the provision of input form enabling the input of the interface identified through template.
Figure 8 presents the image of input data retrieved through Query View.The input/output relationship between components can be verified through the following Query View.

Interface control:
The ICWG is organized when the interfaces obtained from reverse-engineering process and re-engineering process are incorporated into database.The purpose of ICWG is to resolved interface problems which are difficult to be resolved through simple engineer-to-engineer relationship.Figure 9 illustrates the interface management process.ICWG reviews and revises the identified interface requirements to enhance maturity.Moreover, ICWG reviews the effect of interface which may arise from the change in components and resolve problems.
In this study, we applied ICD preparation guideline specified in the Systems Development Life Cycle Guidance Document of the U.S. Department of Justice to provide the view for supporting the interface control   1.
The ICD presented in this document defines the scope of system (or components) that has the interface and describes the concerned operation scenario.Besides, the ICD can identify the interface relationship of the two system (or components) through operation scenario to derive interface requirements and specify the requirements for validation.In this study, the tracking relationship between elements described above is shown through the query view below.Figure 10 shows the query view for interface requirement In addition, the ICD presented in this document specifies the revision history.
In this study, we can ascertain the issues presented in the related ICD through the issues as shown in Fig. 11.
The complex system and magnetic levitation train development project should be pushed forward simultaneously with the development of railway system, communication system and other systems that support the magnetic levitation train chassis, as well as the development of magnetic levitation train chassis.Normal operation of the system can be assured only when no problem occurs in the interface between these systems.Thus, the integrated development team that develops each system should carry out interface management through cooperation with other organizations that develop interactive systems.The problem lies in the fact that it is extremely difficult to maintain undisrupted cooperative relationship when each organization of those teams has different interface management environment or does not have any interface management environment at all.Therefore, all organizations involved in the project needed to use common interface management environment.In addition, it was necessary to support simultaneous development activities of the integrated development teams that carry out development in this organization and many organizations.We presented the measures for identification and control of system interface by using the computational support tool in order to achieve the objectives described above.More specifically, we developed the procedures for identification and control of interface, schema and the view for the implementation of tasks.

Fig. 7 :
Fig. 7: Interface form hierarchical structures that have been changed due to the integrated requirements as the level becomes lower.The area marked in red within each system block represents the change in physical components as compared to the reference system.The width of the area is proportional to the quantity of modified components.In addition, the width of the area is proportional to the quantity of internal/external interface of the system affected (which therefore requires the review by ICWG) by the change in components.The interfaces that have been identified through aforesaid process are fed into the interface form presented in Fig.7.This interface form includes the detailed description that specifies the name, scope and function of interfaces, along with the explanation of components targeted for interface and interface relationship among components.In this study, we applied DSM to ensure easy representation of interfaces.It was found that this model was applied extensively for development as this model allows the interfaces between system components to be easily represented and understood.This study specifies the 4 types of definitions for interface category between components to apply DSM, as presented byPimmler and Eppinger (1994).Scores were added, depending on the importance of energy exchange, information exchange, materials exchange, physical space and arrangement and interface among components.