중립파일 기반의 조선소 시뮬레이션 환경에 관한 연구

An Approach for Construction of Shipyard Simulation Environment based on Neutral File Format

  • cc icon
  • ABSTRACT

    In shipbuilding, the scheduling system is susceptible to sudden changes and thus it turns to be difficult to predict the differences between schedule and production records in advance. A computer-based simulation is commonly utilized to overcome the discrepancies occurred in estimating workloads and resulting processing times. The main drawback of this simulation-based solution is its limited applicability because, in most cases, each shipyard requires specific and customized simulation environment. By standardizing the planning data of the midterm scheduling system, as proposed in this paper, the efficiency of the current simulation model can be enhanced. To present an alternative approach, this paper begins with the analysis of the complex planning data structure of several shipyards and then proceeds to construct a standard data structure based on the neutral format. An interface application is developed for the data transaction and simulation in on-line environment. As a result, a simulation-based production management of shipyards can be achieved by the efficient prediction of planning and scheduling.


  • KEYWORD

    선박건조 , 생산계획 , 시뮬레이션모델링 , 표준화 , 중립파일포맷

  • 1. 서 론

    오늘날 한국의 조선 산업은 중국의 성장과 일본의 재도약, 그리고 세계 경제 불황 및 저유가 등 다양한 요인으로 생존에 많은 어려움을 겪고 있다. 이러한 환경에서 경쟁력 확보를 위해 플로팅도크 탑재, 육상건조 등 다양한 공법의 혁신을 달성해 왔으며 선주의 요구에 대해 유연하게 대처할 수 있는 다각적인 노력을 기울여 왔다. 하지만 생산관리 측면에서 보면, 생산계획 시 반영 되어야 될 요소가 자주 바뀔 뿐만 아니라 계획 담당자가 현장의 프로세스를 정확히 파악하지 못하여 계획과 실적의 괴리가 수시로 발생하고 있다 (Lee, 2013). 또한 조선소의 선박건조는 주문생산방식을 기반으로 하고 있기 때문에 건조 기간 동안 선주의 요구로 설계 변경이 자주 발생하는 등 다양한 변수에 노출되게 된다 (Lee, et al., 2013).

    다품종 선박이 동시에 건조되는 현 생산환경에서, 수학적으로 생산계획을 최적화 한다는 것은 현실적으로 불가능하다고 할 수 있다. 이러한 생산관리 체계의 개선을 위한 새로운 방법론의 하나로 디지털 생산 개념의 공장 시뮬레이션을 통한 다양한 연구가 이루어져오고 있다. 조선소에서는 일반 제조업에서와 같이 선박에 대한 시제품 제작이 불가능하기 때문에 항상 설계와 계획에 대한 충분한 검증을 수행하는데 한계가 존재하고, 충분한 검증이 이루어지지 않은 계획은 건조 실적과의 괴리를 피할 수 없다. 현재 국내 조선소들은 일정계획을 수립함에 있어 실제 생산 환경을 반영치 못한 비효율적인 일정계획을 수립하여 불필요하게 생산비를 낭비하고 있는 현실을 인지하고 있으며, 이를 극복하고자 개별적으로 생산계획을 구축하는 프로그램들을 만들어 사용하고 있으나, 산출되는 생산계획이 올바른 기능을 하지 못하고 있는 상황이다 (Kim, et al., 2012). 이러한 문제를 해결 하고자 컴퓨터 프로그램을 이용하여 선박건조 과정을 시뮬레이션을 수행함으로써, 건조 활동 이전에 계획을 검증하고 계획/실적 동기화 달성에 기여하고자 하는 노력의 일환으로 시뮬레이션 기반의 선박 건조기법이 소개되었다 (Han, et al., 2008).

    Woo (2005)는 2000년도 초반에 국내 S조선소의 디지털 조선구축을 위한 모델링 프로세스를 정립하고 현업에 시뮬레이션 서비스를 제공할 수 있는 방법론과 내업에 대한 사례를 제시하였고, Song, et al. (2009)은 선체블록조립 공장 최적화를 위해 시뮬레이션 기반 관리 시스템을 구축하고 이를 이용한 레이아웃 설계와 생산계획 수행에 대한 사례를 발표한 바 있다. 또한 시뮬레이션 기반 생산관리를 위한 KPI(Key Performance Index)에 대한 연구도 수행되었는데, Woo and Song (2014)의 연구에서 경영학 이론을 선택적으로 조합한 시뮬레이션 기반 생산관리 시스템구축 가이드라인이 제시되기도 하였다.

    하지만 이러한 연구들의 한계점 중 하나는 조선소별로 차이가 있는 개별 시스템들의 데이터와 정보를 효율적으로 시뮬레이션 시스템에 연계시키지 못한다는 것이다. 특정 조선소에 시뮬레이션 기반 생산관리 시스템을 구축하기 위해서 해당 조선소의 관련 데이터를 분석한 후 이를 시뮬레이션 목적과 유형에 적합한 형태로 변환하는 작업은 지나치게 많은 공수를 요구하게 된다. 즉 대상 조선소가 달라지면 유사한 사전 작업이 반복적으로 수행되어야 하기 때문에, 시뮬레이션 수행을 위한 전처리에 지나치게 많은 노력이 소요된다는 근본적인 약점을 가지고 있다.

    본 연구에서는 조선소별로 상이한 형태와 데이터 관리 시스템에 대한 신속한 인터페이스 구축을 위해, Nam, et al. (2015)의 선행 연구에서 제안하고 있는 자료구조의 기본 구성을 유지하면서 세부 속성을 수정함으로써, 복수 조선소 시스템과 인터페이스되어 시뮬레이션을 가능하게 하는 자료구조를 제안한다. 또한 전처리와 함께 시뮬레이션 프로그램에 대한 원격 모듈 기능을 포함하여 시뮬레이션이 동일 환경에서 수행될 수 있는 어플리케이션 개발과정을 소개한다.

    2. 조선소 생산계획 정보 분석

    선박건조를 위한 생산계획 정보는 생산계획을 관리하고 실행하기 위한 목적을 지니고 있다. 일반적인 제조업은 설계가 완료한 후 생산에 필요한 계획을 세우고 이 과정에서 생산계획 정보를 수립한다. 하지만 다양한 크기를 가진 수많은 부재와 블록을 조립하는 조선소의 경우, 생산계획 정보를 계층별로 구분하여 관리하고 있어 일반 제조업과 판이한 성격을 가진다.

    일반적인 조선소의 생산계획 정보는 기본적으로 Table 1과 같이 5단계로 구분될 수 있으나, 조선소 규모에 따라 일부 계획을 생략하거나 다른 계획과 통합하는 경우가 있다 (Lee, 2007).

    조선소의 생산계획은 그 구성요들이 복잡하게 얽혀있기 때문에, 시뮬레이션을 활용하기 위해서는 구성정보들을 체계적으로 분류 하는 것이 중요하다. 조선소의 생산계획에서 널리 사용되는 WBS(Work Breakdown Structure) 코드는 산출물에 기초하여 프로젝트 전체 범위를 조직하고 정의하는 분할된 프로젝트 컴포넌트 계층구조로 볼 수 있다. 현재 국내조선소에서는 이와 같은 WBS 코드를 사용하여 일정 계획 및 리소스 할당을 수행한다.

    본 연구에서 참조하는 WBS 코드 구분 및 작업과의 상관관계는 Table 2와 같이 정리될 수 있고, Table 3을 통하여 WBS 코드 구조분석에서 구분한 각각의 생산 코드에 대한 세부 정보를 확인한다.

    3. 엔지니어링 정보 표준화를 위한 계획정보구조 정의

    시스템 구현을 통한 효과적인 시뮬레이션 결과를 산출하기 위해서는 작업 계획 수준에 따른 계층 세분화와 해당 작업에 적용되는 블록 및 부재의 정의가 동시에 이루어지는 것이 중요하다. 본 연구에서는 앞서 소개된 WBS 코드에 근거하여, 중일정을 대상으로 생산 작업 단위에 따른 계층화를 시도하였으며, Table 4에 보이듯이 시뮬레이션 시스템에 효율적으로 적용가능 하도록 단위 작업에 따라 process, work type, work package, work order로 구분하였다. 재정비된 구분결과를 Table 5의 Type1에 따라 구분해보면, 호선-선각-조립 단계까지 plan, 블록조립 단계까지 work type, 대조립 단계까지 work package, 블록심출 단계까지 work order라 정의할 수 있다.

    블록 및 부재에 관한 데이터는 Table 5에 보이듯 크게 3가지 종류로 구분될 수 있다. 이를 통하여 최종 탑재를 위한 블록과 해당 블록이 생성되기까지의 각각의 조립블록 및 부재들의 계층관계, 그리고 해당 블록 및 부재의 규격 정보를 확인할 수 있다. 먼저, Type 1은 상위 블록을 나타내는 데이터로서 조립/부재의 데이터를 통하여 여러 가지의 조립블록 및 부재로 구성된 것을 보여준다. Table 5에 포함된 조립/부재 데이터 앞에 ‘*’ 표시로 구분되어 있는 것은 여러 개의 부재로, 그렇지 않은 경우는 최소한의 부재로 구성됨을 의미한다. 또한, 조립 데이터는 조립/부재의 데이터들이 구성되는 것으로 Type 2의 조립블록이 Type 1의 조립블록을 이루는 하나의 구성요소임을 나타낸다.

    마찬가지로 Type 2의 조립블록 역시 여러 개의 블록 및 부재로 구성되는데, 여기서 Type 3의 조립블록이 Type 2의 조립블록을 구성하는 하나의 블록임을 확인할 수 있다. 최종단계인 Type 3의 조립/부재 데이터들은 모두 ‘*’ 표시가 없는 데이터로 최소한의 부재들만으로 이루어졌음을 나타낸다.

    4. 생산계획 정보 통합구조 설계

       4.1 통합구조 설계

    서로 다른 규모와 구조를 가진 세 조선소의 생산관리시스템데이터(Table 6 ~ 8)를 대상으로 그들의 일정 정보를 통합하기위하여, 개념스키마의 정의를 활용하여 전체 데이터베이스의 개념을 정의하고 구조를 설계하였다.

    우선 시뮬레이션을 위해서 생산시스템의 데이터로부터 시뮬레이션 모델로의 전환을 위한 중립형식 문서인 XML 기반의 계층구조로 이루어진 각 데이터를 정의하였다. 데이터베이스 구조의 기초를 XML문서를 통해 구현함으로써, 사용자가 데이터베이스의 수정을 요구할 때, XML문서만 수정하여 데이터베이스의 수정이 가능하도록 한다.

    4.1.1 프로세스 스키마 정의

    최상위 계층인 프로세스 정보는 Fig. 1과 같이 정의되었다. 중립구조에서 최상위 일정 정보는 중일정 단계로 정의되는데, 이 단계에서는 호선 번호와 블록 번호 아이디가 필수 사항으로 들어간다. 여기서 아이디는 앞서 정의한 sector 분류에 해당하는 부문으로 해당 블록의 부분 분류를 나타내고 있다. 착수일(start date)와 종료일(finish date)는 하위 공정들의 가장 빠른 날과 가장 늦은 날로 정의된다.

    Fig. 2에 보이는 work type 정보는 대공정 분류에서 내려온 하위 공정 정보까지 나타내는 구조를 가진다. 여기서 work type 정보를 Fig. 2와 같이 정의한 이유는, ID와 Hull Number 부분을 A, B조선소가 공통적으로 사용한다는 것을 염두에 두고, 코드 길이가 다를지라도 나타내는 일정 수준이 동일하기 때문에 ID 부분과 호선번호를 공통적으로 사용할 수 있기 때문이다.

    Fig. 3의 WorkPackage 정보는 일일 작업 계획의 상위 단계정보를 나타낸다. 이와 같이 설계된 구조에서 A, C조선소의 데이터가 함께 관리될 수 있다. ID 부분은 앞서 정의한 Table 4에서 work stage까지의 정보로서, C조선소 WOP의 ID로 할당하였고 이후 중복되는 WOD 코드를 필터링하여 가장 빠른 착수일과 가장 늦은 종료일을 정의하도록 하였다. 이를 통해 A조선소와 C조선소의 WOP 수준 데이터를 하나의 중립구조로 통합할 수 있게 된다.

    Fig. 4의 WOD는 최하위 일일 작업 정보까지 나타내는 정보로서, 그 구조는 A, C조선소의 정보를 참조하여 정의되었다.

    4.1.2 Product 스키마 정의

    제품(product)에 해당하는 블록과 부재 데이터 경우, 호선과 블록에 대한 ID가 필수적으로 포함되어야 한다. 블록은 계층 구조로 구성되기 때문에 상위 단계의 블록에 대한 ID가 포함되어야 조립 공정 구현이 가능하게 된다. 부재 역시 상위 부재 번호가 필수적으로 포함되어야 한다. 그밖에 물리적인 크기와 무게에 대한 속성을 공통적으로는 포함하게 된다. Fig. 5는 이러한 블록과 부재의 속성을 보여주고 있다.

    4.1.3 Resource 스키마 정의

    Fig. 6에 도시된 리소스 구조는 필수 정보로 장비 ID를 포함한다. 다만 향후 공간에 대한 제약 요건은 리소스보다는 프로세스에 종속될 가능성이 크기 때문에, 본 연구에서는 리소스를 구성할 때 공간 요소는 고려하지 않는다.

    리소스 구조에는 주로 장비에 해당하는 물리적인 크기, 무게 및 속도에 대한 속성 등이 포함되도록 하였다. 해당 속성 중 설비의 능력에 대한 속성으로 정의된 speed는 운송 설비의 경우에는 이동 속도로 사용되고, 생산 설비의 경우에는 단위 시간당 생산 능력으로 사용된다.

    5. 시뮬레이션 관리 어플리케이션 개발

    앞서 설계된 데이터 구조를 기반으로 실제로 조선소의 계획 데이터에 대한 전처리를 수행하고 시뮬레이션을 가능하게 하는 어플리케이션 개발하였다. 이를 위한 데이터베이스 구조는 Fig. 7과 같고 물리적 구조를 데이터베이스로 구현한 테이블 구성은 Table 9와 같다.

       5.1 어플리케이션 요구사항 정제

    개발 어플리케이션의 목적은 이기종 조선소 생산관리 환경에서 입력 정보를 생성하고 생성한 입력 정보를 바탕으로 시뮬레이션을 수행하는 것이다. 어플리케이션 개발을 위해서 우선 사용자의 요구사항을 기반으로 한 유스케이스 분석이 선행되어야 한다. Table 10과 같은 사용자의 유스케이스를 기반으로 프로그램의 설계 진행 방향이 결정된다. 그리고 이러한 유스케이스는 Fig. 8과 같은 구조로 어플리케이션의 엑터와 함께 다이어그램으로 표현된다. 유스케이스는 데이터베이스 생성, 시뮬레이션 설정 및 실행, 데이터입력, 데이터소스 선택, 시뮬레이션 데이터 선택 및 수행의 총 5단계로 구성된다. 여기에서 엑터는 사용자(user), DB, Quest 로 구성되고, 시스템영역(system boundary)은 중앙에 위치한 박스부분과 같이 구성되며, 이 영역이 어플리케이션 구현을 통해 실현되는 부분이다. 여기에서 QUEST는 시뮬레이션 모델이 생성되고 시뮬레이션이 수행되는 단계로, 상용 DES(discrete event simulation) 솔루션으로 적용되었다.

       5.2 어플리케이션 설계 및 구현

    유스케이스 실현을 위하여 MVC(model, view, controller)구조를 기반으로 설계를 진행하였다. 여기에서 모델은 시스템 간 전달되는 정보, 뷰는 화면 즉 사용자가 직접적으로 컨트롤할 수 있는 사용자 환경, 그리고 컨트롤러는 시스템의 주요기능을 구현하는 관리자 역할을 각각 의미한다. 각 유스케이스에 대한 시퀀스 다이어그램 작성을 통해 모델과 뷰 그리고 컨트롤러에 대한 세부설계를 진행하게 된다.

    일례로 Fig. 9는 유스케이스 ID4에 대한 시퀀스 다이어그램을 보이고 있다. 사용자는 주 화면에서 데이터베이스 소스를 선택한다. 데이터베이스 소스는 DB와 XML이 있으며, 각 소스 내부는 WOP, WOD 테이블 등으로 나누어져 있어 목적에 적합한 데이터의 선택이 가능하도록 한다. 시뮬레이션 목적에 해당하는 일정을 시뮬레이션의 객체인 블록에 연계시키는 기능이 포함되어 있다. 다음으로, 데이터 소스를 선택하면 해당 소스의 테이블들을 반환해주고 테이블을 선택하고 나면 해당 공정 리스트들을 반환해준다.

    어플리케이션을 구현하기 위하여 컴포넌트기반 개발방법론(CBD: component based development)을 활용하였고, 그 결과물로 Fig. 10의 컴포넌트 다이어그램이 작성되었다. 시스템의 비즈니스 컴포넌트 모델은 비즈니스 퍼사드 레이어, 비즈니스 컴포넌트 레이어, 데이터 액세스 컴포넌트로 이루어져 있다. 퍼사드는 시스템의 진입점 역할을 수행하며 비즈니스 컴포넌트로부터 상속을 받는다. 비즈니스 컴포넌트 레이어에는 비즈니스 로직과 프로세스를 담고 있는 비즈니스 컴포넌트가 놓이게 되며, 데이터 액세스 컴포넌트는 데이터저장소에 접근하여 데이터의 입출력 처리를 담당한다. MVC 구성 중 컨트롤러역할을 하는 부분은 DataBaseMgr, InputShipyardDataMgr, SimulationMgr로 구성되어 있으며, 이 컴포넌트들에 대한 실직적인 접근을 위해서는 시뮬레이션 퍼사드를 경유한다. 비즈니스 컴포넌트 레이어는 3개의 인터페이스로 구성된 3개의 비즈니스 컴포넌트를 가지고, 데이터 엑세스 컴포넌트 레이어는 1개의 데이터 엑세스 컴포넌트를 가진다. MVC 구성 중 앞에서 언급하였듯이 정보를 담당하는 부분인 모델은 DTO(data transfer object)라는 비즈니스 객체를 통해 시스템 내부에서 정보를 전달한다. 각 DTO의 내부 객체는 앞서 설계된 DB 정의와 동일하게 이루어지도록 하였다. 마지막으로, MVC 구성 중 뷰에 해당 하는 사용자 인터페이스는 설계 과정에서 첫 번째로 언급되었던 요구사항 분석과 유스케이스에 대한 분석 이후 도출되는 정보를 바탕으로 설계되었다. Table 11에서는 개발 대상 어플리케이션의 컴포넌트들 중 가장 중요한 시뮬레이션 메니저 컴포넌트에 대한 세부 기능들이 보이고 있다.

       5.3 어플리케이션 개발 결과

    개발된 어플리케이션은 Fig. 11에 보이는 기능을 수행한다.

    어플리케이션 요청에 따라 조선소 계획 시스템으로부터 원형계획 데이터를 가져오면서 데이터베이스의 테이블을 생성하고, 이를 인터페이스 시키는 작업으로 시작된다. 동시에 표준 스키마를 기반으로 조선소 데이터 처리를 통해 시뮬레이션이 가능한 형태로 변환한다. 그리고 시뮬레이션의 목적에 부합하는 매개 변수들을 설정한 후 시뮬레이션 엔진과 인터페이스를 통해 시뮬레이션을 수행하고, 그 결과를 확인하는 순서로 진행된다. 이러한 절차에 대한 어플리케이션 수행 내용이 Table 13에 보인다.

       5.4 어플리케이션 검증

    본 연구에서 개발된 어플리케이션에 대한 검증을 위하여, 중립구조 설계에 고려된 3개의 조선소 데이터를 사용하여, 시뮬레이션 모델 생성에 대한 테스트를 진행하였다. Table 12에서는, 3개 조선소 데이터에 대하여 해당 모델에 제품 및 공정 정보가 적합하게 로딩되는지를 테스트하여, 어플리케이션의 작동 유효성을 검증하는 내용을 보이고 있다.

    6. 결 론

    본 연구에서는 국내 3개 조선소 생산계획 데이터를 통합할 수 있는 중립구조를 제안하였다. 실제 시뮬레이션용 데이터로 변환을 위해 일정정보, 제품정보, 리소스정보의 통합을 수행하였으며, 이를 시행하기 위한 변환 모듈을 개발하였다. 또한 모듈을 통해 획득된 입력데이터를 바탕으로 시뮬레이션을 수행할 수 있는 별도의 어플리케이션을 개발하여 변환 모듈과 통합하였다.

    결과적으로, 복수 조선소의 상이한 데이터를 한 틀로 표준화하고, 원격으로 QUEST에 생성 및 구동시키는 어플리케이션을 개발함으로써, 시뮬레이션 프로그램에 대한 이해도가 다소 떨어진다고 하더라도 손쉽게 시뮬레이션을 수행하고 평가할 수 있는 도구를 제공하였다. 그 결과 시뮬레이션 기반의 일정계획 검증을 통해 조선소 생산관리 경쟁력 향상에 기여할 수 있을 것으로 기대한다.

  • 1. Han S.D., Ryu C.H., Shin J.G., Lee J.K. 2008 Implementation and Applications of Simulation based Digital Shipyard [Journal of CAD/CAM Engineers] Vol.13 P.18-26 google
  • 2. Kim H.Y., Nam J.H., Lee J.H., Lee P. 2012 Construction of data structure for simulation system of shipbuilding midterm scheduling [Conference of Society of CAD/CAM Engineers] P.69-72 google
  • 3. Lee D.G. 2013 Study on the PPR3-S information-based neutral model and system for integration and extension of shipbuilding production planning simulations. Ph.D. Thesis google
  • 4. Lee J.H., Lee P., Yoon K.W., Nam J.H. 2014 Quality Verification of Legacy Data of Manufacturing Information System to Improve Results of Shipyard Manufacturing Logistics Simulation [Journal of the Society of Naval Architects of Korea] Vol.51 P.510-520 google doi
  • 5. Lee J.M. 2007 Integrated process and measurement framework for planning production of large shipyards. Ph.D. Thesis google
  • 6. Nam J.H., Lee J.H., Woo J.H. 2015 Construction of Standardised Data Structure for Simulationof Mid-term Scheduling of Shipbuilding Process [International Journal of Computer Integrated Manufacturing] google
  • 7. Song Y.J., Lee D.K., Choe S.W., Woo J.h., Shin J.G. 2009 Simulation-based Capacity Analysis of a Block-assembly Process in Shipproduction Planning [Journal of the Society of Naval Architects of Korea] Vol.46 P.78-86 google doi
  • 8. Woo J.H. 2005 Modeling and simulation of IndoorShop system of shipbuilding by integration of the product, process, resource and schedule information. Ph.D. Thesis google
  • 9. Woo J.H., Song Y.J. 2014 Systematisation of Ship Production Management and Casestudy for Ship Block Assembly Factory [International Journal of Computer Integrated Manufacturing] Vol.27 P.333-347 google doi
  • [Table 1] Planning and scheduling for shipbuilding
    Planning and scheduling for shipbuilding
  • [Table 2] Typical WBS structure
    Typical WBS structure
  • [Table 3] Description of production codes of WBS
    Description of production codes of WBS
  • [Table 4] Refined WBS structure
    Refined WBS structure
  • [Table 5] Data types for blocks and members
    Data types for blocks and members
  • [Table 6] Selected planning data of shipyard A (with Indoor block assembly process)
    Selected planning data of shipyard A (with Indoor block assembly process)
  • [Table 7] Selected planning data of shipyard B (with outdoor block construction process)
    Selected planning data of shipyard B (with outdoor block construction process)
  • [Table 8] Selected planning data of shipyard C (with cutting process)
    Selected planning data of shipyard C (with cutting process)
  • [Fig. 1] A process structure in top level
    A process structure in top level
  • [Fig. 2] A work type structure
    A work type structure
  • [Fig. 3] A work package structure
    A work package structure
  • [FIG. 4.] A work order structure
    A work order structure
  • [Fig. 5] A product structure
    A product structure
  • [Fig. 6] A resource structure
    A resource structure
  • [Fig. 7] Logical schema structure for database
    Logical schema structure for database
  • [Table 9] Table list for application implementation
    Table list for application implementation
  • [Table 10] Usecase design
    Usecase design
  • [Fig. 8] Usecase and actor diagram
    Usecase and actor diagram
  • [Fig. 9] Sequence diagram for usecase 4 (data source selection)
    Sequence diagram for usecase 4 (data source selection)
  • [Fig. 10] Simplifed component diagram
    Simplifed component diagram
  • [Table 11] Functions of simulation manager component
    Functions of simulation manager component
  • [Fig. 11] Application data flow diagram
    Application data flow diagram
  • [Table 13] Application operation sequence
    Application operation sequence
  • [Table 12] Validation of developed application
    Validation of developed application