| 항목 | 내용 (답변) | 관련 정보 | 답변 |
|---|
| 인터페이스 | - 활용시스템에서 촬영요구 시스템으로 전달되는 <촬영 주문>의 형식은 정의되었는가? 기존 K3 의 ICR 과 동일한가?
| 제안서 III-5 | - 컨텐츠는 정해지지 않았음. 기본적으로 항우연과 동일하다고 생각하면 됨
|
| 인터페이스 | - 촬영요구 시스템에서 운용관리 시스템으로 전달되는 <촬영계획>의 형식은 정의되었는가? 기존 K3 의 ICP 와 동일한가?
| 제안서 III-5 | - 컨텐츠는 정해지지 않았음. 기본적으로 항우연과 동일하다고 생각하면 됨
|
| 기능 - 촬영요구 시스템 | - 촬영요구 시스템에서 주문 관리 및 촬영 가능일 계산 기능을 수행해야 하는 것인가?
- 1회성이겠지?? 촬영계획 생성 전에 꼭 해야 하는 것인가??
- 촬영 가능일 계산의 경우, 촬영요구 시스템에서 관리되는 주문에 대해서 최적화하여 계산하면 되는 것인가?
- 촬영요구 S/W 에서 구현되어야 하는 사항인가?
| 제안서 III-6 | - 요구사항 만족을 위해 들어간 개념
- 상세 설계 시에 개념 상세화를 해야 함
- 1회성이 맞음
|
| 기능 - 운용관리 시스템 | - L0F 에 대한 표준영상 생성 및 정사영상 생성 확인은 DB 기반으로 이루어져야 함
| 제안서 III-7 | |
| 기능 - 운용관리 시스템 | | 제안서 III-7 | - 단순 프로그램 실행 개수 정도
- 제대로 되지 않았을 경우, 알람 정도
|
| 기능 - 위성정보수신 시스템 | - L0F 를 수신할 때, MWD 를 자동 수행? 아니면 L0F 수신 확인을 할 때, MWD 자동 수행? MWD 자동 수행의 의미가 무엇인지 잘 모르겠음
| 제안서 III-8 | - KARI 에서 L0F 를 수신 받으면 수신이 종료된 후에 MWD 를 자동으로 실행해 주는 것
|
| 인터페이스 | - 촬영주문은 누구에게서 전달되는가? 형식은 무엇인가?
| | |
| 기능 - 촬영요구 S/W | - ICPS 의 주문 관리 기능을 그대로 이용해도 무관?
| 제안서 III-44 | - 무관함. 현재 안은 ICPS 에서 사용하던 주문 관리 모듈을 그대로 사용해도 됨
|
| 기능 - 촬영요구 S/W | - OAS 의 주문 분석 기능을 그대로 이용해도 무관?
- Pitch Tilt Angle 고려해야 하나?
- Scene 단위의 편집을 지원해야 하나?
| 제안서 III-46 | - 현재의 안은 그러함
- 실제 운영에 따라 개념 자체가 통째로 바뀔 수 있음
|
| 인터페이스 | - <촬영요구> 의 형식은 무엇인가? MSS <-> ICPS 사이의 인터페이스와 동일한 것인가?
- <촬영요구> 를 ICPS 로 전달하는 별도의 인터페이스가 필요한가?
- ICPS 에서 관련 기능에 대한 수정이 필요한가?
| 제안서 III-50 | |
| 기능 - 촬영요구 S/W | - 승인된 촬영 계획에 대한 확인을 촬영요구 S/W 에서 확인해야 하나? ICPS 에서 확인해야 하나?
| 제안서 III-53 | - 현재 KARI 에는 본 운영 개념이 없음
- MT 를 받아서 MT 에 기록된 수신을 받지 못했을 경우, rejected 촬영 계획이라고 봐야 할 것 같음
- MT 인터페이스 필요
- MT 에는 촬영/수신 정보가 모두 존재함
- Daily Operation
|
| 기능 - 위성정보수신 S/W | - L0F 처리는 FTS 에서 수행하고 별도의 모니터링 S/W (including Playback MWD) 만 존재하면 될 듯 함
| 제안서 III-55 | - 수신 상태 확인 GUI 때문에 FTS 로 퉁 칠 수 없음
|
| 인터페이스 | - L0F 를 전달받을 때, RHCP/LHCP 병합된 데이터를 받을 지, 각각의 데이터를 받을 지 정의 필요
- KARI 에서 Push? 위성정보수신 S/W 에서 Pull?
| 제안서 III-55 | |
| 기능 - 위성정보수신 S/W | - L0F 수신 상태의 경우, DIS 에서 Trend Chart Data (binary) 를 전달해 주지 않는 한, Trend Chart 를 도시할 수 없음
| 제안서 III-55 | |
| 기능 - 위성정보수신 S/W | - 본 S/W 에서 L0F 에 대한 L1R/L1G 영상 생성 여부까지 확인을 해야 하나?
- 운용관리 시스템에서 수행해야 하는 것 아닌가?
- 기능의 중복이 있어 보임
- 본 S/W 에서는 L0F 에 대해서 L1R/L1G 생성 요청 PGR 생성 여부만 확인하는 것이 맞아보임
| 제안서 III-56 | - 빼도 상관 없음. 생성 요청까지만 보여주면 됨
|
| 용어 | - 표준 영상이 L1R/L1G 인가? 아니면 L1R 만인가?
- 정사 영상이 L2 인가?
| 제안서 III-59 | - 표준 영상 - L1R/G (PMS 산출물)
- 정밀 정사 영상 - L1R+, L1G+, L2 (정밀 영상처리 시스템 산출물)
|
| 기능 - 위성정보수신 S/W | - L1R 생성 후, L1G 를 즉시 생성하려면 본 S/W 에서 PMS WO 의 상태를 모니터링 해야 함
- 정사영상
| 제안서 III-59 | - 현재의 안으로 갈 지, 중간 단계를 추가할 지 나중에 고민이 필요함
- 어떤 시스템에서 해야 할 지도 나중에 고민해야 함
|
| 인터페이스 | - 정사영상생성 시스템으로 데이터를 전달하는 주체가 FTS 가 나는 것이 맞나? 아니면 PMS Server 가 직접 전달하는 것이 맞나?
| 제안서 III-62 | |
| 기능 - 저장관리 S/W | - 본 S/W 에서 Catalog 를 검색?
- 지도가 존재해야 하는 것인가?
- 웹으로 개발해야 하는가?
| 제안서 III-78 | - 검색 기능이 있는 것이 맞음
- 지도 존재해야 함. 2D/3D
- 단순 검색 및 관련 데이터 제공 기능만 있음
- 저장할 구성정보가 필요함
- 웹은 본 과제에서 개발하지 않음!!! 모두 윈도우즈 어플리케이션!!!
|
| 인터페이스 | - 저장관리 S/W 에서 활용시스템으로 위성 정보를 전달?
- 주문정보까지 본 S/W 에서 검색?
- 왜 이렇게 된 것인지?? ㅡ.,ㅡ
| 제안서 III-79 | - 전달하는 것이 맞음
- DB 를 기반으로 검색해야 함
|
| 기능 - 운영관리 S/W | - 사용자의 기능 권한을 동적으로 할당해 줘야 하나?
- 만약 그렇다면 기능의 단위를 결정하기 위해서는 사용자에게 문의가 필요하나? 아니면 내부적으로 결정하면 되나?
| 제안서 III-84 | |
| 기능 - 운영관리 S/W | | | |
| 인터페이스 | - 운영관리 S/W 에서 인터페이스를 담당하는 FTS 는 사용하지 않는 것인가?
| 제안서 III-94 | - 인터페이스는 FTS 로 가는 쪽으로 설계하면 됨. 바뀌어도 되고...
|
| 환경 | - 위성정보수신/저장관리/운영관리 시스템 이중화는 어떻게 할 계획인가? 솔루션을 사용하나? 직접 구현하나?
- ROSE-HA 솔루션의 경우, 공유 저장소가 필요함
| 운영개념 분석 및 정리 - 26, 29, 31 | |
| 기능 - 운영관리 S/W | - GPS 시각동기화의 경우, 서버와 로컬의 시간 차이가 일정 이상일 경우만 하는 것인가? 무조건 수행하면 되는 것 아닌가?
| 운영개념 분석 및 정리 - 111 | |
| 기능 - 기반관리 S/W | - 방역관리 백신업데이트의 경우, 수집 시스템에서 직접 수행하는 것인가? 백신 프로그램의 업데이트를 사용하는 것이 아닌가?
| 운영개념 분석 및 정리 - 124 | |
| 기능 - 저장관리 S/W | - Catalog 검색을 위해서 3D Map 까지 있어야 하는 것인가?
| 분석보고서 - 25 | |
| 환경 - 저장관리 S/W | - 저장용량 계산에서 CAS-1 에 대해서만 계산하는 것이 맞나? 아니면 CAS-2 까지 고려해야 하는 것인가?
| 분석보고서 - 28 | |
| 기능 - 운용관리 S/W | - GPS 시각 동기화 상태를 시각화해야 함. 본 S/W 를 웹으로 개발할 것이라면 공통모듈에 본 기능과 관련된 웹 모듈을 추가했으면 함
| 분석보고서 - 29 | |