한재중 : 20211220 SIIS RID 회의

항목	내용
GS Infrastructure 보안 관련	자체 구축할 소비자에게 이정도 해야 한다라는 가이드 필요함 배포 시에 보안에 대한 가이드 준비하기로 함 cloud 를 사용하더라도 cloud service 에서 제공하는 보안/백신서비스를 구축해야 함
Orbit Reservation Time Limit?	Slot Access Key Programming 을 할 수 있을 때여야 함. 현재로서는 이 정도의 러프한 limit 을 생각하고 있음
촬영/수신계획 수정의 유연성	slot access key programming 이 되기 이전에 (위성에 데이터를 올리기 전에) 지상에서 마음껏 수정 작업 진행 가능함 물론, orbit slot publish 에 있어서 꼬임이 있을 수 있는데 그 부분은 MRCS 가 제어/보장해줘야 함
API 의 필요성	위성영상 고객의 입장에서는 위성을 따지지 않고 특정 플랫폼에서 모든 위성 영상을 검색할 수 있어야 할 것임 REST API 를 제공하는 것이 우선순위가 높아야 한다고 생각함 EOB Platform 에서는 외부에 우리의 API 를 제공하는 것이 현재는 규정되어 있지 않아서 부문장은 현재 API 의 우선순위를 낮게 생각하고 있는 것임 현재 본 요구사항은 EOB Platform 을 생각하는 것이기 때문에 부문장 생각에 API 제공은 시스템 요구사항으로 정의될 필요가 없음. deliverable 이기 때문임. 배포의 관점에서 SOW 이라고 생각함 API 를 제공하고 받기 위한 기능을 위해서 해당 내용까지 식별이 되어야 함 우리 시스템의 외부 서비스와 어떻게 인터페이스 할 것이냐를 정의해야 함 오히려 현재 up stream 이 모호하기 때문에 더더욱 설계에 고려해야 한다고 생각함
요구사항 flow down (break down)	부문장 생각 요구사항 정의는 상위 요구사항을 기반으로 정의가 되어야 함 그렇게 하지 않으면 하위 요구사항에서는 모든 필요하다는 것을 할당할 수 있기 때문에 범위가 발산할 수 있음 그렇기 때문에 가능하다면 상위 요구사항으로부터 break down 해야 한다고 봄
Stream???	Down Stream?? Up Stream?? EOB Platform 에서는 영상을 잘 팔아보자 보다는 팔 수 있는 영상을 최대한 고품질로 만들어보자?? SIIS 입장에서는 commercial 로 가기 위해서 설계가 안 되어 있으면 나중에 commercial 로 갈 때, 이런 저런 제약 사항이 발생할 수 있음. KOMPSAT 의 경험
UIS 의 요구사항 구체성?	김문규 대표는 현재 요구사항이 너무 구체적이라고 생각하고 있음 UIS 를 현재 요구사항에서 날려버릴까? UIS 를 없앤다기 보다는 요구사항 정의의 범위를 본 회의에서 논의할 필요가 있음
영상 품질 자동 검증 방법	위성 운영 초창기에는 config 를 통해서 관리 추후에는 고객의 주문에 따라 주문 별로 품질의 레벨을 결정할 수 있어야 함 정지궤도쪽 (GT5) 에서 개발한 내용 (허웅 시연) 을 기반으로 품질 결정을 할 수 있도록 하면 될 듯 함 현재 SIIS 에서는 자동으로 영상 품질을 측정하고 있지 않음 영상 품질 확인을 위해 ENVI/PCI 등을 통해 영상을 직접 띄운 다음, 체크리스트를 기반으로 운영자가 직접 확인을 하고 있음 Auto Delivery Check 를 주문에 대해서 받고 check 되어 있으면 QA 하지 않고 바로 배포 uncheck 이면 QA 수행 후, QA 만족하면 배포
영상 제품 배포	Imaging Order 는 MPPS 에서 수행? Product Order 는 PMS 에서 수행? 어쨌든 배포는 UIS 가 담당해서 하는 것 아닌가?
Monitoring Target	현재 STP GS 에서는 MPPS 에서 주기적으로 촬영할 Target 을 관리함 그리고 MPPS 에서는 IO Target 도 처리함 UIS user 가 Monitoring 주문을 입력하는 방법은 없음 그런데 SIIS 에서는 그런 주문이 오고 있음 어떻게 처리???? Monitoring 주문을 Single IO 로 생성해서 처리하도록 할 수 있음 → SIIS 에서는 원하지 않음 IO 를 계층적으로 나눠야 할 수 있음 → SIIS 가 원하는 것 → Monitoring Order 개념을 추가 Monitoring Order 같은 IO 를 1회 이상 촬영하는 주문
촬영 Pass 지정 촬영 주문	사용자가 촬영할 Pass/시간을 결정하는 주문은 매우 보편적인 상황임. 해당 기능에 대한 지원이 필요함 시스템적으로 자동 처리를 기반으로 시스템 구성을 한다면 자동화에서 선점여부, 촬영 기회 Top Priority, 구름 조건 제외 등으로 제공 가능함
PMS 인터페이스 (IO)	GS Operation 에 보면 IO 의 AOI 와 겹치는 해당하는 L0 를 받으면 자동으로 영상제품 처리해서 UIS 로 전달한다고 되어 있음 5.3.6. Image Data Receiving and Processing Flow If the received image data covers any IOs, PMS generates the corresponding Image Products and transfers them to UIS, together with the updated Order Status. UIS notifies the readiness of the ordered products to the users (i.e. IO originators) automatically by e-mails, such that the users can download the image products. The updated Order Status is also provided to MPPE(Terminal) for confirming the completion of the imaging, downloading, and product generation of the planning for the corresponding IOs. 그런데 Level-4 Requirement 를 보면 UIS → PMS 는 PO 만 존재함 STPRQ.IRPE.PMS.20000 를 보면 PMS 는 DIS 로부터 전달된 L0 Product 로부터 L1R/L1G 를 생성해야 한다고 되어 있음 PMS 는 어디에서도 IO 를 받고 있지 않음 UIS to PMS Interface 에 IO 추가해야 함 or DIS → PMS 로 전달되는 L0 Product 에 관련 Imaging Order ID 가 모두 기록되어야 함!!! (상세 설계에 꼭 반영 필요!!) 이 경우, 영상이 Imaging Order AOI 를 커버한다기 보다는 L0 Product 에 기록된 Imaging Order ID 를 이용해서 UIS 로 제품을 전달한다고 해야 함