* 폰트가 지원되지 않아 다운로드 받아 내용 보시길 추천합니다. 본 강의자료는 2017년 우리나라 함정공학계(조선소, 연구소, 방위사업청, 기품원, 국과연, 해군 등) 전문가 105명을 대상으로 하였던 함정시스템공학 강의자료 일부입니다. (관련 동영상: https://tinyurl.com/y6js7wo5) 강의는 총 17개 unit으로 구성되었으며 이론강의 후 다음시간은 실습의 순차적 강의방식으로 진행되었습니다. 강의 구성은 아래와 같으며 중간에 누락된 unit은 공개제한되는 자료(사내 자료)이므로 양해 바랍니다. Unit3 - SE General Unit4 - SE Exercise Unit5 - NSSEF General Unit6 - NSSEF Example Unit7 - Requirement analysis Unit8 - Requirement analysis practice Unit9 - Architectural design Unit10 - Architectural Design Practice Unit11 - Analysis of Alternative (AOA) general Unit12 - Trade-off study practice Unit14 - Technical Performanxce Measure (TPM) Unit15 - System Requirement Review (SRR) Process Unit16- SRR Outputs Appendix - SE worksheets * 강의자료 관련 문의사항은 jwpark1@gmail.com로 연락바랍니다.

1. Naval Ship Systems
Engineering Framework
Application Example
함정시스템엔지니어링 프레임워크 적용 例
Unit 6
박진원

2. * 2017 Naval Ship Systems Engineering Day at Hyundai Heavy Industry, Ulsan, South Korea, Jan. 19-20 2017
2
함정시스템엔지니어링 프레임워크 적용 例
중점사항
• 요구조건 분석 例
• 아키텍처 설계 例
• 설계 실행 例
• 통합 例
목 표
• NSSEF 실제 적용 例題 설명으로 실제 함정
설계시 시스템엔지니어링 적용방안 모색

3. Systems Engineering Process Model
3

4. Systems Engineering Technical Flow
44

5. Problem domain: a Hybrid Propulsion System
5

6. 요구조건 분석
Task 1.0

7. 7
▸ 요구조건 분석 (Requirement Analysis)
목 적 : 설계자들이 요구조건을 제대로 이해하고 있는지? (ROC/TLR/Spec. => 체계요구조건)
활동중점 : 요구조건 식별 및 분석, 설계개념 및 방안 수립, 요구조건 안정화
프로세스
방 법 : WBS/SOW 작성, SWOT/KANO 분석, RAM/RVM/RTM/RD 작성, KPP/TPM 정의 및 관리
도 구 : 스프레드 시트(Excel), CASE tool (Cradle, Doors, Mentis, CORE 등)
산출물
• 업무분할구조(WBS) 및 업무기술서(SOW)
• 요구조건 다이어그램(Requirement Diagram)
• 요구조건 분석/검증/추적 매트릭스(RAM, RVM, RTM)
• 요구조건 정의시트(Requirement Definitioin Sheet)
• 컨텍스트 다이어그램 또는 유즈케이스 다이어그램 등
요구조건 분석 아키텍처 설계 설계 실행 통 합

8. ▸ Task 1 : 요구조건 분석(Requirement Analysis)
요구조건 분석 아키텍처 설계 설계 실행 통 합
8
• ROC : 최대지속속력, 항속거리, 00식 추진체계, 추진기관, 순항속력 등
• TLR : 추진기관, 감속기, 발전기, 조수기, 배전반, 분전반, 공기압축기, 통합기관제어체계, 유수분리기 등
• 탐색개발사양서 : 운용/정비용이, 국내.외 유사실적함 발전추세 등을 고려하여 적합한 추진체계를 검토하
여야 한다. 획득비용 및 함 수명주기 간 운용유지비용을 비용대 효과를 분석하고 필요시 검토결과를 설계
에 반영한다. 배전계통은 방사성 배전방식과 구역 배전방식을 검토하여 적합한 배전방식으로 설계되어야
한다. 소화 및 침수상황에 효율적으로 대처할 수 있도록 손상제어체계, 자동손상통제장치 등의 최적(안)을
제시하고 설계시 반영한다.
Task 1.1 : 요구조건 수집 (ROC, TLR, 탐색개발사양서 등)

9. Task 1.2 : 원 요구조건 세분화(Requirements Cascading), ROC-TLR-Spec.
• ROC/TLR/사양서 등 수집된 원 요구조건을 수준에 따라, 문장별 관계에 따라 계층화(Cascading)하여 정리 필요
• 각 요구조건간의 관계를 명확히 하고 각 요구조건이 독립적으로 이해될 수 있도록 정의되어야 함
• R : ROC 요구조건 식별자, T : TLR 요구조건 식별자, SP : 탐색개발사양서 식별자 (단, 조선소 관리기법에 따라 조정 필요)
요구조건 분석 아키텍처 설계 설계 실행 통 합
9

10. Task 1.3 : 원 요구조건 계층화(Requirements Diagram), ROC-TLR-Spec.
• Powerpoint, Visio 등 드로잉 S/W 또는 조선소에서 운영 예정인 CASE 도구(Cradle 또는 CORE) 작성 도출 가능
• 요구조건의 수직, 수평 계층적 관계를 확인하고 누락된 요구조건이나 중복된 요구조건을 확인 가능
요구조건 분석 아키텍처 설계 설계 실행 통 합
10

11. Task 1.4 : 요구조건 평가(Requirements Evaluation), Requirement Analysis/Verification Matrix
• 요구조건 분석항목(12가지) : 시스템 특성에 따라 추가 또는 생략 가능함
구분 기 준 확인사항
문장
확인
명확성
(Clarity)
요구조건의 표현이 명확한지?
정확성
(Correctness)
요구조건의 내용이 진리나 물리법칙 등에 위배되지는 않는지?
타당성
(Feasibility)
요구조건이 주어진 예산과 일정 내에서 구현 가능한지?
설계독립성
(Focus)
요구조건이 시스템 하부 수준의 구체적인 설명방법에 대한 제약을 포함하는지?
완전성
(Implementability)
요구조건 정의에 있어 필요한 기술적 제약 사항들에 대해 빠짐없이 정의되었는지?
불확실성
(Unambiguous)
요구조건의 문장이 정량적이지 않고 불분명하게 기술된 부분은 없는지?
유일성
(Singularity)
하나의 문장이 단일한 의미만을 갖고 있는지? 복수개의 의미를 갖고 있지는 않은지?
검증가능성
(Testability)
요구조건을 검증할 수 있는 방법이 존재하는지?
추적가능성
(Traceability)
요구조건이 시스템 개발 전 단계에 걸쳐 양방향(수평/수직) 추적이 가능한지?
집합
확인
중복성
(Multiple)
같은 의미를 갖는 요구조건이 2개 이상 존재하지 않는지?
연결성
(Connectivity)
서로 연계성을 갖는 요구조건 문장들끼리 연결이 확보되었는지?
상충
(Contradiction)
두 개 이상의 요구조건이 서로 상충되지는 않는지?
요구조건 분석 아키텍처 설계 설계 실행 통 합
11
“V.V.I.P.”

12. • 원 요구조건 분석 매트릭스 例 (Requirement Analysis Matrix)
• 예제 작성을 위한 개략 분석결과로 분야별 설계팀 미팅 또는 이해관계자 회의체를 통해 체계요구조건 문장별 분석 필요
• 위험관리요소 및 기술성능측정(TPM) 도출시 활용 가능 (불명확 요구조건, 기술적 실현가능성 低, 중복 요구조건 등)
• 전산기반체계공학 도구(Cradle, Mentis, Doors)를 이용하여 상기와 같은 필드(컬럼) 정의 가능하며 시스템 설계 특성
에 따라 요구조건 분석항목은 조선소에서 적의 조정 필요
요구조건 분석 아키텍처 설계 설계 실행 통 합
12

13. • 체계요구조건(안) 검토 시트
* 조선소 자체 검토사항으로 분석결과는 CASE S/W에 입력, 설계 全 기간에 걸쳐 추적 관리 필요하며 체계요구조건 정의시트 작성 위한 기초로 활용
요구조건 분석 아키텍처 설계 설계 실행 통 합
13

14. • 체계요구조건(안) 검증 매트릭스
* 조선소가 도출한 각 체계요구조건(안)마다 “무엇을, 어떻게, 언제” 검증할 것인가에 대해 검토하여야 함
* 필요한 경우 체계개발 SE기술검토, DT/OT까지를 포함하는 범위를 SRR시 검토한다면 후반기 P-TEMP 및 TEMP 작성
위한 소요시간 감소 가능함. 성공적인 SRR 수행은 함정획득 전체순기 감소에 획기적으로 기여 할수 있음(모호성 최소화)
요구조건 분석 아키텍처 설계 설계 실행 통 합
14

15. * 요구조건 정의 시트는 CASE S/W에 별도의 파일로 링크되어 관리되어야 하며, SRR시 보류된 안건은 SFR 수행 전 별도로 확정하여야 함
요구조건 분석 아키텍처 설계 설계 실행 통 합
15
Task 1.5 : 체계요구조건(안) 정의(System Requirements Definition)
15

16. 아키텍처 설계
Task 2

17. ▸ 아키텍처 설계 (Architecture Design)
목 적 : 설계자들이 기능과 물리적 요소들을 제대로 분해, 분석 및 조합하였는지?
활동중점 : 기능아키텍처 및 물리아키텍처 작성, 맵핑 매트릭스 작성
프로세스
방 법 : 공리설계(독립/정보공리), 기능아키텍팅, 물리아키텍팅, 기능맵핑 (*문법 참조 : MND-AF)
도 구 : CORE/Cradle/Powerpoint/Visio/Excel
산출물
• 기능아키텍처, 물리아키텍처
• 요구조건-기능 맵핑 매트릭스, 기능-물리 매트릭스
• 설계대안(복수 또는 현재 해결책)
요구조건 분석 아키텍처 설계 설계 실행 통 합
17

18. Document-Based Design
요구조건 분석 아키텍처 설계 설계 실행 통 합
18

19. 요구조건 분석 아키텍처 설계 설계 실행 통 합
Task 2, 아키텍처 설계 흐름
• Task 2.1.1 : 개략시스템 구상 (실적함 자료, 요구조건 분석결과 등 참조)
19

20. 요구조건 분석 아키텍처 설계 설계 실행 통 합
• Task 2.1.2 : 기능분해(Functional Decomposition)
20
Top-level

21. 요구조건 분석 아키텍처 설계 설계 실행 통 합
21
Third-level functions
Third-level

22. 요구조건 분석 아키텍처 설계 설계 실행 통 합
22
Fourth-level functions
Fourth-level

23. 요구조건 분석 아키텍처 설계 설계 실행 통 합
23
Functional Architecture

24. 요구조건 분석 아키텍처 설계 설계 실행 통 합
Task 2.2.1 : 기능모델링(Functional Modeling)
• Level 1 기능모델링
24
Level 1 - Fn.0

25. 요구조건 분석 아키텍처 설계 설계 실행 통 합
25
Level 2 - Fn 2.0
• Level 2 Fn.2(추진/전력 기능)

26. 요구조건 분석 아키텍처 설계 설계 실행 통 합
26
Level 3 - Fn 2.1
• Level 3 Fn.2.1(전력 생산)

27. 요구조건 분석 아키텍처 설계 설계 실행 통 합
27
Level 4 - Fn 2.1.2
• Level 4 Fn.2.1.2(디젤원동기 구동)

28. 요구조건 분석 아키텍처 설계 설계 실행 통 합
28
Level 2 - Fn 2.1.2.2
• Level 5 Fn.2.1.2.2 (디젤엔진 공기흡입)

29. 요구조건 분석 아키텍처 설계 설계 실행 통 합
* 각 체계요구조건별 기능분석이 누락된 부분이 없는지 식별하여 추가 설계 행위를 시스템엔지니어는 도메인 엔지니어에게 정보 제공
=> 설계루프간 체계요구조건(안) / 기능간 사상 지속 수정/최신화/확인 필요
* 각 체계요구조건(안)별 Level 3 수준의 기능 정의가 분명히 되었는지에 대해 요구조건 대비 기능정의 현황 정리 필요
• Task 2.2.2 요구조건-기능 사상(Reqmts-Functions Mapping)
29

30. 요구조건 분석 아키텍처 설계 설계 실행 통 합
Task 2.3 : 물리모델링(Physical Modeling)
30
Physical Architecture

31. 요구조건 분석 아키텍처 설계 설계 실행 통 합
• Task 2.3.2 기능-물리 사상(Functional-Physical Mapping)
31
* Task 2.2.2를 통해 모델링/정제된 기능(Function) 대비 누락된 장비(Component)는 없는지 확인

32. 요구조건 분석 아키텍처 설계 설계 실행 통 합
• Task 2.3.3 설계대안 인자(Design alternatives drivers) 도출 : 기능분해/분석 및 물리아키텍팅 과정에서 도출됨
32

33. 설계 실행
Task 3

34. ▸ 설계 실행 (Design Implementation)
목 적 : 비용-성능-일정 측면 최적의 대안을 도출하였는가?
활동중점 : 아키텍처 산출물 이용 대안 수립, 분야별 대안분석 통한 최적대안 도출
프로세스
방 법 : Design Structure Matrix, AHP, UFM, Pugh Matrix 등
도 구 : Excel, Export Choice, JMP/Minitab/R/Python 등
산출물
• 최적설계 대안 도출
요구조건 분석 아키텍처 설계 설계 실행 통 합
34

35. Task 3.1 대안절충 연구(Trade-off of Design Alternatives)
요구조건 분석 아키텍처 설계 설계 실행 통 합
Task 3.1.1
국내외 사례 조사
Task 3.1.2
고려사항 도출
Task 3.1.3
대안분석
평가기준 도출
기술 자료
대안분석
평가기준
Task 3.1.4
평가기준
가중치 평가
Task 3.1.5
최적 설계대안
선정
최적 대안
REF
Task 4.0 통합
35

36. 요구조건 분석 아키텍처 설계 설계 실행 통 합
• Task 3.1.4 평가기준(4개항) 가중치 평가
* 중요/중요하지 않음 : 비교대상과의 상대적 차이(비교대상을 포기할수는 없음)
* 매우중요/전혀 중요하지 않음 : 비교대상을 포기하더라도 반드시 고려해야 하는 항목
* 다수 대상 설문 조사시 기하평균을 적용하여 각 평가기준별 가중치를 얻을수 있음
* SRR 준비회의 또는 SRR 본회의시 검토위원 중심으로 쌍대비교 설문조사도 방법임(설계원도 같이)
<AHP를 고려한 설문지 작성>
36

37. 요구조건 분석 아키텍처 설계 설계 실행 통 합
<AHP 분석결과>
• 일관성 지수(Consistency Index)를 이용하여 쌍대비교의 일관성을 반드시 확인해야 함
• 일관성 지수는 0에 가까울수록 일관성이 크며, 0.1 이하이면 쌍대비교 설문결과의 일관성을 인정함
37

38. 요구조건 분석 아키텍처 설계 설계 실행 통 합
가중치(Weights)
0
0.075
0.15
0.225
0.3
평가기준
작전운용성 ROC만족 신뢰성 연동복잡성 중량_크기 정비성 가격
0.063
0.0890.089
0.1110.116
0.248
0.284
38

39. 요구조건 분석 아키텍처 설계 설계 실행 통 합
• Task 3.1.5 최적 설계대안 선정 : Pugh-Matrix Method
• 5점 척도 : ++(수, 5점), +(우, 4점), S(미, 3점), -(양, 2점), - -(가, 1점)
• 3점 척도 : +(양호, 3점), S(보통, 2점), -(불리, 1점)
39
* 선행 검토 : 최적 설계대안 정량화 분석 전 평가기준별 대안에 대한 자료조사와 기술검토후 근거 제시

40. 통 합
Task 4

41. ▸ 통합 (Integration)
목 적
방 법 : 요구조건/기능/물리 할당 검증, 보고서/도면 작성
도 구 : CASE S/W, Excel, MS words 등
산출물
• 요구조건-기능-장비의 누락없이, 중복없이 제대로 조합되었는지?
• 설계된 하드웨어/소프트웨어의 상향 통합(최적대안 조합)
• 요구조건 할당 시트 (Requirement Allocation Sheet)
• 보고서 및 도면
프로세스
요구조건 분석 아키텍처 설계 설계 실행 통 합
41

42. Task 4.1 요구조건 할당 : 요구조건-기능-물리(장비/체계 등)
요구조건 분석 아키텍처 설계 설계 실행 통 합
42
• Task 4.1.1 체계요구조건 재정제/구체화 (요구조건 분석-아키텍처 설계-설계실행 결과 환류 반영)
Task 4.1.1
체계요구조건
재정제/구체화
Task 4.1.2
요구조건-기능-물리
할당
Task 4.2.1
분야별 보고서
작성
체계요구조건
수정(안)
Task 4.2.2
분야별 도면
작성
요구조건 할당
매트릭스
* 설계진행간 추가된 체계요구조건은 ‘요구조건 분석-아키텍처 설계’ 활동(추가 수행)에 반영될 수 있도록 피드백 필요

43. 요구조건 분석 아키텍처 설계 설계 실행 통 합
43
• Task 4.1.2 체계요구조건-기능-물리 할당
* 체계요구조건 대비 누락된 기능 정의, 장비 정의 확인시 재 검토하고 ‘아키텍처 설계’에 피드백 필요

44. Task 4.2 공학설계
요구조건 분석 아키텍처 설계 설계 실행 통 합
44
요
구
조
건
분
석
아키텍처
설계
설계
실행
통합