OpenFog Reference Architecture for Fog Computing

Data Centric Network 2018.08.01 16:31

OpenFog Reference Architecture for Fog Computing

OpenFog Overview

IoT (Internet of Things), 인공 지능, 가상 현실, Tactile 인터넷 및 5G 애플리케이션의 디지털 혁신은 우리가 일하고, 통신하고, 쇼핑하고, 즐기는 방식을 변화시키고 있습니다. 새로 연결된 공장, 가정, 커뮤니티, 자동차, 병원 등의 데이터는 2016년부터 1년에 1.1 제타 바이트 (또는 89 엑사 바이트)에서 2020년에는 2.3 제타 바이트 (또는 194 엑사 바이트)로 증가 할 것으로 예상됩니다. 현재의 "클라우드 전용" 아키텍처는 네트워크에서 이 데이터의 양과 속도를 따라 잡을 수 없으므로 이러한 투자로 생성 될 수 있는 가치가 감소합니다. 포그 컴퓨팅은 Cloud-to-Thing 에서 누락 된 링크를 제공합니다. 포그 아키텍처는 현재 인프라의 한계를 해결하기 위해 데이터를 생성하는 네트워크 에지(Edge)에 가까운 컴퓨팅, 스토리지, 통신, 제어 및 의사 결정을 선택적으로 이동하여 업무에 중요한 데이터 집약적 사용 사례를 구현합니다.

Fog 컴퓨팅은 다음과 같습니다.

클라우드에서 사물로 연결 (Cloud-to-Thing)되는 연속성에 따라 컴퓨팅, 스토리지, 제어와 네트워킹 기능을 사용자 근처로 분산하는 수평적이며 시스템 수준의 아키텍처

포그 컴퓨팅은 아키텍처의 구현이 네트워크 토폴로지의 여러 계층에 상주 할 수 있는 전통적인 클라우드 기반 컴퓨팅 모델의 확장입니다. 그러나 컨테이너화, 가상화, 오케스트레이션, 관리 효율성을 비롯한 Fog 확장 기능을 통해 클라우드의 모든 장점을 보존해야합니다. 대부분의 경우 Fog Computing은 Cloud와 함께 작동합니다. 오픈 포그 (OpenFog) 레퍼런스 아키텍처의 공통된 주제는 보안, 확장성, 개방성, 자율성, RAS (신뢰성, 가용성 및 보수 용이성), 민첩성, 계층 구조 및 프로그래밍 기능을 포함합니다.

포그 컴퓨팅은 종종 에지 컴퓨팅이라고 잘못 인식되지만 중요한 차이점이 있습니다. Fog는 Cloud와 함께 작용하는 반면, Edge는 Cloud를 제외하고 정의됩니다. Fog는 계층적이며 Edge는 작은 수의 레이어로 제한되는 경향이 있습니다. 추가적으로 포그는 컴퓨팅, 네트워킹, 스토리지, 제어 및 가속기능 처리를 포함합니다.

Fog: 클라우드와 함께 작용, 계층적 구조, 컴퓨팅/네트워킹/스토리지/제어/가속기능 처리를 포함

Edge: 클라우드를 제외

오픈포그 컨소시엄은 개방 생태계를 통해 기술적 및 시장에 대한 폭 넓은 연합체를 적용 할 수 있습니다. 독점 또는 단일 공급 업체 솔루션은 공급 업체의 다양성과 생태계를 제한하여 시장, 시스템 비용, 품질 및 혁신에 부정적인 영향을 미칠 수 있다고 생각합니다. 오픈포그 (OpenFog) 레퍼런스 아키텍처가 활발한 공급 업체 생태계에 의해 완벽한 상호 운영 및 보안 시스템을 보장한다는 것이 우리의 의도입니다.

1 About Fog Computing and the Consortium

1.1 OpenFog Reference Architecture Overview

OpenFog 컨소시엄은 2015년 11월 ARM, Cisco, Dell, Intel, Microsoft 및 Princeton University에 의해 설립되었습니다. 컨소시엄은 선도적인 기술 및 네트워킹 플레이어, 포그 컴퓨팅 기업가 및 대학 연구원의 글로벌 회원 자격을 통해 혁신을 가능하게 합니다. 오픈 아키텍처 프레임워크를 통해 포그 컴퓨팅을 가능하게 합니다.

우리는 OpenFog 이사회와 OpenFog 기술위원회의 지침을 받습니다. 기술위원회는 컨소시엄의 모든 실무 그룹의 기술 집행 기관입니다. 이 그룹의 의장은 OpenFog 이사회의 투표로 선출되며 이사회에 직접보고합니다.

OpenFog 참조 아키텍처 (OpenFog RA)는 비즈니스 리더, 소프트웨어 개발자, 시스템 설계자가 포그 컴퓨팅에 필요한 하드웨어, 소프트웨어 및 시스템 요소를 만들고 유지 관리하는 데 도움을 주기위한 것입니다.

컨소시엄의 다양한 기술 작업 그룹은 참조 아키텍처의 다양한 측면을 담당합니다. 여기에는 통신, 소프트웨어 인프라 및 보안이 포함됩니다. Architecture Framework 작업 그룹은 이 문서와 컨소시엄의 다른 기술 자료를 만들고 유지 관리 합니다. 조사가 필요한 모든 새로운 기술 주제가 이 그룹에 지정됩니다. 각 그룹은 기술위원회와 이사회가 관리하고 승인합니다.

더 자세한 정보나 참여 방법은 www.openfogconsortium.org 를 참조하십시오.

2 Areas of Opportunity

2.1 OpenFog Reference Architecture Content

OpenFog RA는 OpenFog 컨소시엄과 기술 제휴 파트너가 작성중인 문서 세트의 일부입니다. 이는 포그 노드와 네트워크를 위한 시스템 아키텍처에 대한 중간 수준에서부터 높은 수준의 관점입니다. 미래의 문서는 테스트 베드 및 공식적인 요구 사항과 지정된 포그 요소의 상호 운용성을 포함하는 하위 수준의 세부 정보를 제공할 것 입니다. 향후 문서에서는 3 장에서 설명한 사용 사례도 구체화 할 것입니다.

OpenFog RA는 다음과 같이 나뉩니다.

  • 2장: OpenFog 컨소시엄의 사명을 설명하고 포그 컴퓨팅을 가속화할 계획을 설명합니다. 또한 OpenFog RA에 대한 개요도 제공합니다.
  • 3장: 포그 컴퓨팅을 볼 수 있는 몇 가지 유스 케이스를 제시합니다. 이 목록은 OpenFog RA가 개선됨에 따라 성장하고 발전 할 것입니다.
  • 4장: OpenFog 아키텍처의 필러를 설명합니다. 이것은 OpenFog RA의 기본 원칙 입니다.
  • 5장: 전체 OpenFog RA에 대해 자세히 설명합니다. OpenFog RA의 추상 아키텍처 설명 (AD; Architectural Description)을 보여줍니다.
  • 6장: OpenFog 아키텍처를 준수하면서 컨소시엄에 대한 내용을 기술합니다. 다양한 인터페이스에서 표준화를 추진하는 것이 우리의 의도입니다.
  • 7장: 다양한 유스 케이스에 적용되는 추상 OpenFog RA를 보여줍니다. 이것은 OpenFog RA의 각 측면과 성공적인 구현을 위해 무엇이 필요한지를 더 분명히 할 것 입니다.
  • 8장: 포그 컴퓨팅의 새로운 영역과 새로운 연구 기회가 포함되어 있습니다. OpenFog 회원사와 학술 단체는 OpenFog RA를 지속적으로 개선하고 있습니다. 시간이 지남에 따라 전체 아키텍처를 향상할 것 입니다.

2.2 The Internet of Things, Cloud and the OpenFog RA

Internet of Things (IoT)는 일상적인 객체와 장치를 서로 연결하고 클라우드 호스팅 서비스에 연결함으로써 비즈니스 변화를 주도하고 있습니다.

현재 배포 모델은 필수적인 클라우드 연결을 강조합니다. 그러나 이것은 실제 상황에서 실현 가능하지 않습니다. 다음은 모든 서비스에 대해 에지 장치를 클라우드에 연결하는 주요 문제 중 두 가지입니다.

  • 연결된 장치는 기하 급수적으로 증가하는 속도로 데이터를 생성하므로 인프라 에지에서 성능 및 네트워크 정체 문제가 발생합니다.
  • 성능, 보안, 대역폭, 안정성 및 기타 여러 가지 관심사가 있어 클라우드 전용 솔루션을 많은 사용 사례를 비실용적으로 만듭니다.

클라우드 전용 아키텍처 방식은 IoT의 예측 된 데이터 속도 및 볼륨 요구 사항을 유지할 수 없습니다. IoT 추진력을 유지하기 위해 OpenFog 컨소시엄은 논리적 측면에서 정보 처리 및 인텔리전스를 강조함으로써 인프라 및 연결 문제를 해결하기 위한 아키텍처를 정의하고 있습니다. 이 방법을 포그 컴퓨팅 이라고합니다.

클라우드 자체가 많은 구축에 중요한 역할을 할 수 있지만 포그 컴퓨팅은 기존의 폐쇄 형 시스템 및 클라우드 전용 모델에 대한 의존도를 변화하는 것을 나타냅니다. 포그 컴퓨팅은 전통적인 클라우드 기반 모델을 보완하고 확장합니다.

포그 컴퓨팅 모델은 컴퓨팅을 클라우드에서 에지로 더 가깝게 이동시키고, IoT 센서와 액추에이터까지 이동시킵니다. 이 새로운 모델의 컴퓨팅, 네트워킹, 저장 및 가속 요소는 포그 노드로 알려져 있습니다. 이들은 물리적인 가장자리에 완전히 고정되지 않은 동적인 시스템입니다.

2.3 OpenFog and Other Consortia

OpenFog 컨소시엄은 IIC (Industrial Internet Consortium), ETSI-MEC (Mobile Edge Computing), OPC-UA, OCF (Open Connectivity Foundation), OpenNFV 등 많은 IoT 및 기술 산업 동맹 그룹을 보완합니다. 시장 혼란의 중복을 피하기 위해 OpenFog 컨소시엄은 이러한 애플리케이션 영역 중 일부를 최적화하기 위한 노력을 강조하지 않고 대신 다른 이니셔티브에서 다루지 않은 수직 시장을 최적으로 제공하는 데 중점을 둡니다. 장기적으로는 이들 및 다른 기관과의 협업을 통해 에지 및 포그 구조에 대한 일반적인 관점에서 IoT 산업 전반에 걸쳐 더 많은 수렴을 유도 할 것입니다.

3 Use Cases for Fog

포그 컴퓨팅의 목표는 성능, 대기 시간과 같은 cross-cutting 관련 문제 및 포그 네트워크를 효율적으로 제어하는 것 입니다. 클라우드와 포그 컴퓨팅은 서로 상호 의존적입니다.

특정 기능은 자연스럽게 포그 노드에서 수행하는 것이 유리하지만 다른 것들은 클라우드에 더 적합합니다. 전통적인 백엔드 클라우드는 포그 컴퓨팅이 나타나면서 컴퓨팅 시스템의 중요한 부분으로 계속 남아 있습니다. 포그로 이동하는 작업과 백엔드 클라우드로 이동하는 작업의 세분화는 애플리케이션에 따라 다릅니다. 이러한 분할은 계획 될 수 있지만 프로세스의 로드, 링크 대역폭, 스토리지 용량, 장애 이벤트, 보안 위협, 비용 목표 등과 같은 영역에서 네트워크 상태가 변경되면 동적으로 변경됩니다.

OpenFog RA는 포그-클라우드 및 포그-포그 인터페이스를 가능하게 합니다. OpenFog 아키텍처는 다른 접근 방식에 비해 몇 가지 고유한 이점을 제공합니다. 이를 SCALE이라는 용어로 사용합니다.

  • __S__ecurity: 안전하고 신뢰할 수있는 트랜잭션을 보장하기 위한 추가 보안
  • __C__ognition: 자율성을 가능케하는 클라이언트 중심의 목표에 대한 인식
  • __A__gility: 공통 인프라에서 신속한 혁신과 저렴한 확장
  • __L__atency: 실시간 처리 및 사이버-물리적 시스템 제어
  • __E__fficiency: 참여하는 최종 사용자 장치에서 사용되지 않는 로컬 리소스를 동적으로 풀링

포그의 가치를 설명하는 간단한 사용 예 : 압력 및 유량 센서와 제어 밸브가있는 오일 파이프 라인을 고려하십시오. 모든 센서 판독값을 클라우드로 전송할 수 있으며 (아마도 고가의 위성 링크를 사용하여) 클라우드 서버의 판독 값을 분석하여 비정상 상태를 감지하고 명령을 다시 보내 밸브의 위치를 조정할 수 있습니다.

이 시나리오에는 몇 가지 문제가 있습니다. 센서와 액츄에이터 데이터를 클라우드로 전송하거나 클라우드에서 전송하는 대역폭은 매월 수천 달러가 됩니다. 이러한 연결은 해커의 위험에 노출 될 수 있습니다. 비정상 센서 판독값에 반응하는데 수백 밀리 초가 걸릴 수 있습니다 (이 때 주요 누설로 인해 상당한 양의 오일이 유출 될 수 있습니다). 클라우드에 대한 연결이 끊어 지거나 클라우드에 과부하가 걸리면 제어가 손실됩니다.

이제 로컬 포그 노드의 계층 구조를 파이프 라인 근처에 배치하는 것을 고려하십시오. 저렴한 로컬 네트워킹 시설을 통해 센서 및 액츄에이터에 연결할 수 있습니다. 포그 노드는 매우 안전 할 수 있으므로 해커의 위협을 줄입니다. 포그 노드는 밀리 초 단위로 비정상 상태에 반응하여 신속하게 밸브를 닫아 유출의 심각성을 크게 줄입니다. 포그 노드의 로컬 제어는 보다 강력한 제어 시스템을 생성합니다. 이 제어 시스템의 대부분 의사 결정 기능을 포그로 옮기고 때때로 클라우드에 접속하여 상태를 보고하거나 명령을 받는 경우에만 큰 제어 시스템을 생성합니다.

이 문서는 우리가 필러라고 부르는 포그 컴퓨팅의 고수준 속성 집합 (파이프 라인 제어 시나리오에서 설명 된 포그 이점 중 일부를 포함)을 설명합니다. 여기에는 보안, 확장 성, 개방성, 자율성, 신뢰성, 민첩성, 계층적 구성 및 프로그램 가능성이 포함됩니다. 이 문서의 뒷부분에서 이 모든 필러에 대해 자세히 설명합니다.

PaaS (Platform as a Service)는 고객이 일반적으로 응용 프로그램 개발 및 실행과 관련된 인프라를 구축하고 유지 관리 할 필요없이 웹 응용 프로그램을 개발, 실행 및 관리 할 수 있는 플랫폼을 제공하는 클라우드 컴퓨팅 서비스의 범주입니다. OpenFog RA는 특정 클래스의 비즈니스 과제를 해결하기 위해 Fog as a Service (FaaS)를 구축하는 데 필요한 인프라를 정의합니다. FaaS는 IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) 및 포그와 관련된 많은 서비스 구성을 포함합니다. 아래의 인프라 및 아키텍처 빌딩 블록은 FaaS가 어떻게 활성화되고 참조 아키텍처에서 확장되는지 보여줍니다.

OpenFog RA는 수직 시장 또는 애플리케이션에 적용 할 수 있도록 설계된 일반적인 포그 플랫폼을 설명합니다. 이 아키텍처는 운송, 농업, 스마트 도시, 스마트 빌딩, 의료, 접대, 금융 서비스 등 다양한 시장에 적용 가능하며 실시간 의사 결정이 필요한 IoT 애플리케이션에 비즈니스 가치를 제공합니다. 낮은 대기 시간, 개선 된 보안 및 네트워크 제약이 있습니다. 이 섹션에서는 몇 가지 구체적인 사용 사례를 살펴 봅니다.

3.1 Transportation Scenario: Smart Cars and Traffic Control

2016년에 사람은 평균적으로 매일 약 650MB의 데이터를 생성하고 2020년까지는 두 배 이상의 데이터를 생성할 것 입니다. 그러나 자율 차량은 LIDAR (light detection and ranging), GPS (global positioning system), 카메라 등의 조합으로 매일 수 테라 바이트의 데이터를 생성 할 것입니다. 스마트 자동차는 지능형 인프라와 결합 될 때 클라우드 전용 모델은 자율적 운송을 위해 작동하지 않을 것이 분명하고, 포그 컴퓨팅 접근 방식이 요구됩니다. 스마트 자동차와 교통 통제에서 우리가 묘사하는 많은 아키텍처 요구 사항은 선박/보트, 기차, 트럭, 버스 및 무인 비행기와 같은 다른 운송 영역에도 적용됩니다. 이 섹션에서는 스마트 자동차 및 교통 통제를 위한 포그 컴퓨팅의 기회를 강조하고 OpenFog RA가 요구 사항을 어떻게 처리하는지 설명합니다. 아래 그림은 OpenFog RA의 지능형 고속도로 적용에 대한 개요입니다.

스마트 카 및 트래픽 제어 유스 케이스는 여러 개의 포그 영역뿐만 아니라 여러 클라우드 도메인 간의 풍부한 상호 작용을 포함하는 포그 환경을 검토 할 수 있는 기회를 제공합니다. 무엇보다도 이 사용 사례는 다음을 입증합니다.

  • Element Management Systems (EMS), 서비스 제공 업체 (SP), 메트로 트래픽 서비스 및 시스템 제조업체 클라우드를 비롯하여 여러 포그 도메인과 여러 클라우드 도메인 간의 상호 작용
  • V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure) 및 V2X (vehicle-to-x) 상호 작용을 지원하는 모바일 포그 노드
  • 비슷한 (그리고 다른) 기능을 제공하는 다른 기관에 의해 소유되고 운영되는 다수의 포그 네트워크
  • 포그 노드들에 걸친 멀티 테넌시 (Multi-tenancy)는 여러 포그 네트워크를 통합하여 효율성을 향상시키는 기회
  • Single End-Point 장치에서 사용하는 개인 및 공용 포그 및 클라우드 네트워크

이 사용 사례는 계층적이고 분산된 포그 아키텍처의 이점을 보여줍니다. 위의 그림에서 볼 수 있듯이 시스템에는 여러 가지 유형의 센서 (및 액츄에이터)가 포함되어 있습니다.

도로 측 센서 (인프라) 및 차량용 센서가 포함됩니다. 이러한 센서는 다양한 시스템 (조명, 자동차 등)이 주어진 기능을 수행 할 수 있도록 데이터를 제공합니다 (예 : 차량 자율 주행). 또한 스마트 교통 시스템은 교통 신호, 게이트 및 디지털 신호와 같은 인프라의 일부를 제어하는 액츄에이터를 관리합니다.

차량은 클라우드와 자율 차량 또는 교통 제어 시스템에 서비스를 제공하는 포그 노드의 계층에 연결됩니다.

Fog computing nodes in the vehicle

이 유스케이스 예제에서 차량은 다른 포그 노드와 통신 할 수있는 모바일 포그 노드이며 V2I 상호 작용의 예입니다. 모바일 포그 노드는 다른 포그 노드나 클라우드에 연결할 수없는 상황에서 모든 필요한 차량 내 작업을 자율적으로 수행 할 수 있어야 합니다.

차량 포그 노드는 인포테인먼트, ADAS (Advanced Driver Assistance System), 자율 주행, 충돌 회피, 내비게이션 등의 서비스를 제공합니다. DSRC (Dedicated Short Range Communications), 셀룰러 (3G, LTE, 5G 등) 및 기타 네트워킹 기술은 차량을 상호간 및 인프라에 안전하게 연결합니다.

The Transportation Fog Network

교통 포그 네트워크는 포그 노드의 3 단계 계층 구조로 구성됩니다.

계층 구조의 첫 번째 수준은 인프라 포그 노드 또는 길가(roadside) 포그 노드입니다. 이 수준에서 길가 포그 센서는 길가의 카메라와 같은 다른 장치에서 데이터를 수집합니다. 포그 노드는 상위 계층에 연결할 수 없는 경우에도 자율 기능을 수행하는 것과 같은 로컬 작업에 대한 로컬 분석을 수행하여 빈약한 도로 상태에 대한 차량 경고, 속도 감속을 위한 자율 응답 트리거링을 제공합니다. 첫 번째 상호 작용 레벨의 데이터가 집계된 포그 계층 구조를 두 번째 및 세 번째 수준의 계층 구조 (이웃 및 지역 포그 노드)로 보내 분석 및 배포 할 수 있습니다. 일부 데이터는 동서로 분산되어 다른 인프라 노드에 사용 될 수 있습니다. 일반적으로 계층의 각 포그 계층은 계층 구조 수준에서 수직 응용 프로그램의 서비스에 추가 처리, 저장소 및 네트워크 기능을 제공합니다. 예를 들어 상위 계층은 데이터 분석 또는 대용량 저장 장치를 제공하기 위한 추가 처리를 제공합니다.

Traffic control systems

교통 제어 포그 노드는 스마트 신호등 시스템, 자치 관리자 및 클라우드 기반 시스템과 같은 다른 소스로부터 입력을 수신 할 수 있습니다. 교통 제어 시스템, 인프라 포그 노드 및 차량 사이의 데이터 흐름은 계층 구조의 모든 수준에서 필요한 데이터 및 제어 기능을 보장합니다.

스마트 자동차 및 교통 통제를 위한 OpenFog RA의 목표는 다중 공급 업체 생태계 내에서 실시간 기능을 최적화하는 개방적이고 안전하며 분산되고 확장 가능한 아키텍처를 보장하는 것입니다. 이 운송 예는 막대한 양의 데이터를 생성하는 자율적인 사물과 인프라의 복잡한 시스템을 보여줍니다. 우리는 이 사용 사례가 IoT, 5G, AI 및 기타 고급 시나리오에서 안전하고 효과적인 작업을 가능하게하기 위해 포그 컴퓨팅의 필요성을 강조한다고 생각합니다.

3.2 Visual Security and Surveillance Scenario

감시 및 보안 카메라가 전 세계적으로 배포되고 있습니다. 이 카메라는 재료, 사람 및 장소의 보안을 보장하는 데 사용됩니다. 또한 이 카메라는 대용량의 데이터를 생성 할 수 있어 단일 카메라의 경우 하루에 테라 바이트를 초과 할 수 있습니다. 저해상도 카메라용으로 배포 된 기존 클라우드 모델은 네트워크 전송의 가용성 및 비용 때문에 1080p 및 4K 카메라로 확장 할 수 없습니다. 또한 보안에 대한 결정은 카메라 또는 설치 위치에서 이루어져야하며 클라우드에서만 이루어질 수는 없습니다. 머신 비전은 가속기 및 하드웨어와 소프트웨어 모두에서 다양한 알고리즘의 동적 업데이트에 대한 주요 후보입니다. 이 카메라는 사람, 장소 또는 사물의 이미지를 캡처하고 의사 결정에 긴밀하게 결합되어 있으므로 카메라의 소프트웨어 및 하드웨어 자산에 대한 보안 수준이 높아야합니다.

스마트 시티, 스마트 홈, 소매점, 대중 교통, 제조 및 기업은 사람을 보호하고 무단 액세스를 식별하며 안전성, 안정성 및 효율성을 높이기 위해 카메라 센서에 점점 더 의존합니다. 대규모 네트워크에서 수집되는 시각적 (및 기타 센서) 데이터의 완전한 대역폭은 실시간 통찰력을 얻기 위해 모든 데이터를 클라우드로 전송하는 것을 비실용적으로 만듭니다. 특히 까다로운 응용 분야는 많은 사람들과 물체가 움직이는 high value에 대한 감시입니다. 공항에서 대형 카메라 네트워크를 제어하는 것이 이러한 응용 프로그램의 좋은 예입니다. 이 유스케이스는 구체적인 애플리케이션에 아키텍처를 적용하는 방법을 설명하기 위해 이 문서의 뒷부분에서 자세히 다룰 것 입니다.

교통 신호등에 카메라를 배치하고 원격 지역에있는 다른 카메라를 배치하는 등 도시 규모의 배치는 비디오가 네트워크 인프라에 적합 할지라도 수집 된 비디오를 업로드하기 위해 클라우드에 높은 대역폭으로 연결되지 않습니다. 이상 징후의 실시간 모니터링 및 탐지(건물 내부로의 진입자, 노인 추락, 제조 장비 고장)는 보안 감시 시스템에 엄격한 대기 시간 요구사항을 부과하며, 적시성 및 탐지 능력 모두 중요합니다.

또한 카메라를 이미지 데이터를 수집하는 센서로 사용할 때 개인 정보 보호 문제가 해결되어 이미지를 통해 사람의 신원을 알 수 없거나 기밀 상황 정보(예: 제조 공장의 지적 재산)가 무단으로 노출되지 않습니다. OpenFog RA 배포는 프라이버시를 유지하는 실시간, 대기 시간에 민감한 분산 감시 시스템을 구축 할 수 있는 기회를 제공합니다. 포그 노드를 활용하여 카메라 및 클라우드와 함께 위치한 포그 노드 간에 비디오 처리를 지능적으로 분리함으로써 오랜 기간 동안 수집된 데이터에서 실시간 추적, 이상 징후 감지 및 통찰력을 가능하게 합니다. 비디오 분석 알고리즘은 카메라에 가까운 포그 노드에 위치할 수 있으며 기존의 프로세서 또는 가속기에서 비디오 분석 알고리즘의 일부를 실행하는 포그의 이기종 프로세서 기능을 활용할 수 있습니다.

공항 유스 케이스의 시각적 보안은 이러한 모든 포그 기능이 성능, 안정성, 보안 및 효율성 목표를 달성해야 합니다. 여기에는 차량 탐지, 사람 탐지, 스마트 소매 및 비디오 분석을 통한 머신 비전이 포그 컴퓨팅에 포함됩니다. OpenFog RA의 응용 프로그램을 포함하여 더 자세한 내용은 7장의 자세한 분석을 참조하십시오.

3.3 Smart Cities Scenario

스마트 시티는 교통 정체, 공공 안전, 에너지 소비, 위생 및 공공 인터넷 연결 등 많은 문제를 해결하기 위해 기술을 사용하고 있습니다.

OpenFog RA는 스마트 시티 운영의 효율성과 경제적 현실을 더 크게 지원합니다. 위의 그림은 포그 컴퓨팅이 다음과 같은 스마트 도시에 영향을 미칠 수있는 다양한 측면을 보여줍니다.

  • 스마트 주차, 쇼핑 및 인프라를 갖춘 지능형 도시
  • 환자 치료 및 의료 제공을 위해 모든 측면을 연결하는 지능형 병원
  • 인프라 활용을 최적화하는 지능형 고속도로 시스템
  • 지능형 공장 및 소프트웨어 정의 산업 시스템
Connectivity

대부분의 현대 도시들은 도시 전체 커버리지를 제공하는 하나 이상의 셀룰러 네트워크를 가지고 있지만, 이러한 네트워크들은 종종 그들의 기존 가입자들의 요구를 간신히 충족하는 최대 대역폭과 용량을 가지고 있습니다. 이것은 스마트 시티에 계획되어 있는 많은 자치 서비스를 위한 대역폭을 거의 남겨두지 않습니다. OpenFog RA 구축과 5G 기술을 결합하면 이러한 문제를 해결할 수 있습니다. 포그 노드는 로컬 프로세싱 및 스토리지를 제공하고 네트워크 사용을 최적화할 수 있습니다.

Safety and Security

스마트 도시 계획에는 중요한 공공 안전 및 보안 요구 사항도 포함됩니다. 예:

  • 지역 네트워크는 민감한 트래픽 및 시민 데이터(예: 경찰 파견)를 운반하고 생명에 중요한 시스템(예: 최초 대응자 통신)을 운영합니다.
  • 비디오 보안 및 보안 감시 시스템은 의심스러운 상태 또는 안전하지 않은 상태(예: 유틸리티 네트워크 문제, 공용 공간의 무단 사용 등)를 캡처합니다.

스마트 자동차와 교통 체증 또한 스마트 시티의 최우선 과제입니다.

포그 컴퓨팅은 안전한 데이터와 분산 분석을 제공함으로써 스마트 시티의 공공 안전 및 보안 문제를 해결하는 데 중요한 역할을 할 것이다.

3.3.1 Smart Buildings

스마트 빌딩에는 온도, 습도, 점유, 도어 열기/닫기, 키 카드 판독기, 주차 공간 점유, 보안, 엘리베이터, 공기 품질 등 다양한 건물 운영 매개변수를 측정하기 위한 수천 개의 센서가 포함될 수 있습니다. 이러한 센서는 다양한 간격으로 원격 측정 데이터를 캡처하고 이 정보를 로컬 스토리지 서버로 전송합니다. 이 정보가 처리(분석)되면 필요에 따라 컨트롤러 구동 액추에이터가 건물 상태를 조정합니다.

이러한 처리 및 응답 중 일부는 매우 시간에 민감합니다. 예를 들어, 화재 사건에 대응하여 화재 진압 시스템을 켜거나, 권한이 없는 사람이 진입을 시도하는 경우 구역을 잠급니다. 시간에 민감한 것은 실시간 응답을 의미하며, 이는 인프라 장치와 근접하게 처리해야 합니다.

OpenFog RA 모델을 건물의 제어 계층으로 확장하여 각 건물 내에 다수의 스마트하고 연결된 공간을 만들 수 있습니다. OpenFog RA의 계층적 설계를 사용하면 각 바닥, 부속 건물 또는 개별 룸에 자체 포그 노드가 포함될 수 있습니다.

포그 노드가 다음을 담당 할 수 있습니다.

  • 응급 모니터링 및 대응 기능 수행
  • 건물 보안 기능 수행
  • 기후 및 조명 제어
  • 거주자가 스마트폰, 태블릿 및 데스크톱 컴퓨터를 지원할 수 있도록 하는 보다 강력한 컴퓨팅 및 스토리지 인프라 제공

로컬에 저장된 운영 기록을 집계하고 클라우드로 전송하여 대규모 분석을 수행할 수 있습니다. 이러한 분석을 기계 학습에 적용하여 최적화된 모델을 생성한 다음 실행을 위해 로컬 포그 인프라로 다운로드할 수 있습니다.

4 Pillars of OpenFog RA

OpenFog RA는 필러(pillars)라고 하는 일련의 핵심 원리에 의해 구동됩니다. 이러한 기둥은 참조 아키텍처의 정의를 이끌어내는 신념, 접근 방식 및 의도를 형성합니다. 이들은 시스템이 cloud-to-thing 연속체를 따라 데이터 소스 (사용자, 사물 등)에 더 가까운 컴퓨팅, 스토리지, 제어 및 네트워킹 기능의 분산을 제공하는 수평적 시스템 레벨 아키텍처의 OpenFog 정의를 구현하는 데 필요한 핵심 속성을 나타냅니다.

다음 절에서는 아키텍처의 각 필러에 대해 설명합니다.

4.1 Security Pillar

OpenFog RA가 지원하는 많은 IoT 응용 프로그램은 개인 정보 보호, 업무상 중요한, 심지어 생명의 주요 측면까지 포함합니다. 따라서 포그 네트워크의 모든 보안 손상은 심각한 결과를 초래할 수 있습니다. OpenFog RA는 이러한 기술을 추상화하여 IoT 장치에서부터 클라우드 및 포그 네트워크에 이르기까지 광범위한 보안 문제를 해결할 수 있는 컴퓨팅 환경을 유연하게 생성 할 수 있습니다.

OpenFog RA의 보안은 단일 규모의 아키텍처가 아닙니다. 오히려, 실리콘에서 소프트웨어 응용 프로그램에 이르기까지 포그 노드를 안전하게 하기 위해 적용할 수 있는 모든 메커니즘을 설명합니다. 비즈니스 케이스, 타깃 시장, 수직 사용 사례 및 노드 자체의 위치는 모두 해당 노드에 대한 일련의 요구 사항을 생성합니다. 그러나, 아키텍처에는 보안 실행 환경을 구축하기 위해 반드시 갖춰져야 하는 몇 가지 기본 부분이 있습니다.

보안 구현에는 개인 정보, 익명성, 무결성, 신뢰성, 증명, 검증 및 측정과 같은 다양한 설명과 속성이 있습니다. 다음은 OpenFog RA의 주요 속성입니다. 보안을 위한 기본 요소를 달성하려면 신뢰를 구축하기 전에 모든 스마트하고 연결된 "사물"을 검색, 입증 및 검증하는 접근 방식이 필요합니다.

OpenFog RA 요구 사항을 준수하면 안전한 엔드 투 엔드 컴퓨팅 환경에 OpenFog 구축을 보장할 수 있습니다. 여기에는 OpenFog 노드 보안, OpenFog 네트워크 보안, OpenFog 관리 및 조정 보안이 포함됩니다. 이를 통해 아키텍처와 디자이너는 애플리케이션에 사용되는 장치의 유형에 따라 높은 가치의 보안 및 개인 정보 문제에 집중할 수 있습니다.

특히 브라운필드 구축이나 보안 기능이 거의 또는 전혀 없는 소규모 디바이스 및 센서의 경우 오픈포그 노드가 오픈포그 컴퓨팅 계층 및 클라우드에 대한 장치의 첫 번째 보안 진입 지점의 역할을 할 수 있습니다.

OpenFog RA의 보안 기둥은 기본 구성 요소를 명확히 정의하는 것으로 시작합니다. 모든 포그 노드는 하드웨어 기반 불변 신뢰의 루트를 사용해야 합니다. 하드웨어 신뢰 루트는 전원을 켤 때 제어권을 받는 신뢰할 수 있는 하드웨어 구성 요소입니다. 그런 다음 신뢰 체인을 다른 하드웨어, 펌웨어 및 소프트웨어 구성 요소로 확장합니다. 그런 다음 신뢰의 루트는 인프라 내에서 그리고 인프라 전체에서 실행되는 소프트웨어 에이전트를 통해 입증할 수 있어야 합니다. 에지에 가깝기 때문에 안개 속 네트워크의 노드는 종종 액세스 제어 및 암호화의 첫 번째 노드 역할을 합니다. 즉, 상황별 무결성 및 분리를 제공하고 개인 정보 보호 관련 데이터의 통합을 제어해야 합니다.

FaaS 구현에서 더 복잡한 토폴로지가 만들어지면서 이 증명은 포그 노드, 다른 포그 노드 및 클라우드에 대한 신뢰 체인으로 이어집니다. 포그 노드가 동적으로 인스턴스화되거나 해체 될 수 있으므로 하드웨어 및 소프트웨어 리소스를 증명할 수 있어야 합니다. 신뢰할 수 없는 구성 요소는 포그 노드에 완전히 참여할 수 없거나 완전히 신뢰할 수 있는 데이터로 간주되지 않아야 합니다.

4.2 Scalability Pillar

확장성 필러는 포그 배치의 동적인 기술 및 비즈니스 요구를 해결합니다. 탄력적인 확장 성은 모든 포그 컴퓨팅 응용 프로그램 및 수직 계열을 가로 지릅니다. 포그의 계층적 속성 및 네트워크의 논리적 가장자리에 있는 포그의 위치에는 확장 기회가 추가됩니다.

  • 하드웨어 또는 소프트웨어 추가를 통해 개별 포그 노드를 내부적으로 확장할 수 있습니다.
  • 포그 네트워크는 포그 노드를 추가하여 동일한 수준의 포그 계층 또는 인접 수준에서 과부하된 노드를 지원할 수 있습니다.
  • 수요 지향 탄력적인 환경에서 포그 노드 네트워크를 스케일업 또는 스케일다운할 수 있습니다.
  • 포그 인프라로 스토리지, 네트워크 연결 및 분석 서비스를 확장할 수 있습니다.

포그 컴퓨팅 유즈케이스의 다양성 때문에 OpenFog RA는 수요에 따라 대규모 미션 크리티컬 구축을 통해 적절한 배포를 탄력적으로 확장할 수 있습니다. 이러한 확장성은 워크로드, 시스템 비용, 성능 및 기타 변화하는 비즈니스 요구에 적응하기 위해 포그 컴퓨팅 구현에 필수적입니다.

확장성은 포그 네트워크에서 여러 차원을 포함 할 수 있습니다.

  • Scalable performance: 확장 가능한 성능은 애플리케이션 성능 요구에 대응하여 포그 기능을 확장할 수 있습니다 (예: 센서 판독과 그에 따른 액츄에이터 응답 간 지연 시간 단축).
  • Scalable capacity: 확장 가능한 용량을 사용하면 네트워크에서 더 많은 애플리케이션, 끝점, "things", 사용자 또는 개체가 추가 또는 제거됨에 따라 포그 네트워크의 크기가 변경될 수 있습니다. 프로세서, 스토리지 디바이스 또는 네트워크 인터페이스와 같은 하드웨어를 추가하여 개별 포그 노드에 용량을 추가할 수 있습니다. 또한 소프트웨어와 다양한 종량제 라이센스를 통해 용량을 추가할 수 있습니다. 그 반대도 마찬가지 입니다.
  • Scalable reliability: 확장 가능한 신뢰성을 통해 결함 또는 과부하를 관리하기 위한 중복 포그 기능(옵션)을 포함할 수 있습니다. 또한 중복 포그노드는 대규모 배포의 무결성 및 신뢰성을 보장하며, 이는 안정성, 가용성 및 서비스 가능성(RAS)의 핵심입니다. 확장 가능한 안정성에 대한 하드웨어 및 소프트웨어 측면이 있습니다. 포그 네트워크의 안정성을 지원하는 확장 메커니즘 자체는 매우 안정적이어야 합니다. 가용성(신뢰성과 밀접한 관련이 있는 확장 수단)은 유사한 방법을 통해 확장됩니다.
  • Scalable security: 모듈(하드웨어 및 소프트웨어)을 기본 포그 노드에 추가하여 보안 요구 사항이 더욱 엄격해짐에 따라 확장 가능한 보안을 구현하는 경우가 많습니다. 확장 가능한 배포, 권한 액세스, 암호화 처리 용량 및 자동 보안 기능과 같은 기능은 확장 가능한 보안에 기여합니다.
  • Scalable hardware: 확장 가능한 하드웨어에는 포그 노드의 내부 요소 구성뿐 아니라 네트워크의 포그 노드 수와 관계를 수정할 수 있는 기능이 있습니다.
    • 프로세서는 보통 수준의 단일 코어 CPU에서 수천 개의 코어 또는 수백만 개의 게이트가 있는 특수 가속기 칩으로 확장됩니다.
    • 네트워킹은 단일 무선 또는 유선 인터페이스에서 많은 Gb/s의 총 용량을 가진 대규모 무선, 유선 및 광섬유 인터페이스로 확장됩니다.
    • 스토리지는 단순한 플래시 칩에서 대규모 플래시/회전 Disk 및 네트워크 연결 파일 시스템으로 확장할 수 있습니다.

이러한 리소스는 초기 배포에서 구성 할 수 있으며 필요에 따라 기존 모듈러 포그 노드에 추가 할 수 있습니다. 또한 단일 노드가 전체로드를 공식적으로 관리하는 네트워크의 위치에 포그 노드 배열을 추가하여 네트워크 수준에서 확장 할 수 있습니다. 하드웨어 스케일링은 또한 하향 방향 일 수 있는데, 특정 위치에서 더 이상 필요하지 않은 모듈 또는 전체 포그 노드의 전원을 끄거나 제거합니다 (더 높은 필요성이 있는 포그 네트워크의 다른 곳에서 재사용 될 수 있습니다).

  • Scalable software: 확장 가능한 소프트웨어 또한 중요하며 응용프로그램, 인프라 및 관리를 포함합니다.
    • 포그 관리 인프라는 수십 억 개의 스마트하고 연결된 thing을 지원하기 위해 수천만 개의 포그 노드를 효율적으로 구축하고 지속적으로 운영할 수 있도록 확장되어야 합니다.
    • 포그 네트워크 전체에 걸쳐 리소스의 파티셔닝, 균형 및 할당을 관리하려면 오케스트레이션을 확장할 수 있어야 합니다.
    • 포그 네트워크의 기능으로서의 분석은 특히 공격적인 확장 목표를 가지고 있습니다. 이는 분석 알고리즘이 용량 수요 증가에 따라 몇 개의 크기 확장 순서를 거쳐야 하고, 분석 알고리즘의 정교성이 지속적으로 향상되기 때문입니다.
    • 조합성 및 모듈성은 개별 하드웨어 및 소프트웨어 구성 요소 (수천 가지 유형 및 수백만 개의 인스턴스화에 번호가 있음)가 필요한 특정 응용 프로그램을 실행하도록 최적화 된 포그 네트워크로 조립되는 확장성의 중요한 측면입니다.

확장성을 통해 포그 노드는 비즈니스 요구사항을 해결하기 위한 기본 지원을 제공하고 초기 구축 및 장기적인 성공에 필수적인 FaaS에 대한 종량제 모델을 지원할 수 있습니다.

4.3 Openness Pillar

IoT 플랫폼과 애플리케이션을 위한 유비쿼터스 포그 컴퓨팅 환경의 성공을 위해서는 개방성이 필수적입니다. 독점적 또는 단일 공급업체 솔루션은 제한된 공급업체 다양성을 초래하여 시스템 비용, 품질 및 혁신에 부정적인 영향을 미칠 수 있습니다. 개방성 필러의 중요성은 역동적인 공급업체 에코시스템에 의해 지원되는 완벽한 상호 운용이 가능한 시스템에 대한 열망에서 강조됩니다.

기본 원칙으로서의 개방성은 포그 노드가 네트워크의 어느 곳에나 존재하여 네트워크를 확장 할 수 있게합니다. 이러한 개방성은 검색을 통한 풀링을 가능하게 합니다. 즉, 새로운 소프트웨어 정의 포그 노드를 동적으로 생성하여 비즈니스 임무를 해결할 수 있습니다. 보안 필러는 개방성 특성에 대한 공통 주제 및 요구 사항을 공유합니다.

  • Composability: 통합성은 인스턴스화시 애플리케이션 및 서비스의 이동성과 유동성을 지원합니다. 프로그래밍 가능성 필러는 합성 가능성의 추가 강조가 표시됩니다.
  • Interoperability: 상호 운용성은 컴퓨팅, 네트워크 및 스토리지를 안전하게 검색하고 실행 중 유동성과 이식성을 지원합니다. 시장은 한 공급 업체의 요소를 다른 공급 업체의 요소로 자유롭게 대체 할 수 있다는 합리적인 기대와 함께 활발한 공급 업체 생태계에 대한 요구를 명확하게 표현했습니다. 이것은 테스트 베드, FogFests (플러그 페스트), 표준화 및 개방 구현을 통해 해결됩니다.
  • Open communication: 개방형 통신을 사용하면 네트워크 에지 근처의 리소스 풀링과 같은 기능을 통해 유휴 처리 능력, 스토리지 용량, 감지 기능 및 무선 연결을 수집할 수 있습니다. 예를 들어, 포그 아키텍처에서 개발된 컴퓨팅 집약적 애플리케이션은 매일 저녁 가정 내 또는 대중 교통 시스템의 승객 사이에서 인근의 노트북, 시스템 및 셋톱 박스에 앉아 있는 수백 기가바이트의 용량을 활용할 수 있다. 이러한 컴퓨팅 리소스의 공개적 발견은 매우 중요합니다. 가장 가까운 곳에서 기능 작업을 수행하면 스택을 클라우드로 이동할 때 추가 네트워크 요금이 발생하지 않습니다. 우리는 네트워크 요금을 전송 비용으로 정의합니다.
  • Location transparency: 모든 노드 인스턴스의 위치 투명성을 통해 계층 내의 모든 위치에 노드를 배포할 수 있습니다. 위치 투명성은 네트워크 운영자 통제에 대한 대안을 제공한다. 스마트워치와 같은 IoT 디바이스는 캐리어 방식의 데이터 요금제가 필요함을 의미합니다. 각 항목 또는 소프트웨어 엔티티는 로컬 상태를 관찰하고 어떤 네트워크에 가입할지 결정할 수 있습니다. 포그 네트워크의 각 엔드포인트는 필요한 컴퓨팅, 네트워킹 및 스토리지 리소스에 대한 경로를 최적화할 수 있습니다 (해당 리소스가 포그의 계층 또는 클라우드에 있더라도).

4.4 Autonomy Pillar

자율성 필러를 통해 포그 노드는 외부 서비스 장애에도 불구하고 설계된 기능을 계속 제공할 수 있습니다. 이 아키텍처에서는 계층 전반에 걸쳐 자율성이 지원됩니다. 디바이스 또는 상위 순서 계층을 포함하여 배포 계층의 모든 수준에서 의사 결정이 이루어집니다. 클라우드 내 중앙 집중식 의사 결정만이 더 이상 유일한 옵션은 아닙니다. 네트워크 에지에서의 자율성은 로컬 장치의 인텔리전스를 의미하며, 비즈니스가 가장 합리적인 시점에서 비즈니스 임무를 수행하는 데 피어 데이터를 사용할 수 있습니다.

OpenFog RA는 다양한 기능의 자율성을 지원합니다. 운영(예: 백엔드 클라우드)을 위해 중앙 집중화된 엔티티에 의존하지 않습니다. 에지에 있는 대표적인 자율성 영역에는 다음이 포함됩니다.

  • Autonomy of discover: 자원 발견 및 등록. 예를 들어 현장에서 온라인 상태가되는 IoT 장치는 일반적으로 "phone home"을 수행하여 백엔드 클라우드에 이것이 살아 있고 관련 기능을 사용할 수 있음을 알립니다. 그러나 클라우드에 대한 업링크 네트워크를 사용할 수 없는 경우, 디바이스가 활성 상태로 전환되지 않도록 할 수 있습니다. 자율 포그 노드는 잠재적으로 디바이스 등록의 프록시 역할을 할 수 있으며, 백엔드 클라우드 없이 디바이스를 온라인 상태로 만들 수 있습니다.
  • Autonomy of orchestration and management (O&M): O&M(조정 및 관리)의 자율성은 운영 라이프사이클과 폐로를 통해 서비스를 온라인 상태로 전환하고 관리하는 프로세스를 자동화합니다. O&M의 자율성은 서비스 인스턴스화, 데이터 플로우 라우팅과 같은 서비스 주위의 환경 프로비저닝, 리소스의 상태 및 상태를 추적하는 등 다양한 작업을 수반합니다. 이러한 모든 조치는 프로그래밍 가능성과 정책을 통해 가능한 한 자동화되어야 합니다. 이 아키텍처에는 클라우드에 대한 실시간 의존도 또는 상당한 인력 투입 없이도 리소스에 대한 수요 급증을 처리하기 위해 설정된 자율적이고 확장 가능한 O&M 기능이 포함됩니다.
  • Autonomy of security: 보안의 자율성을 통해 기기와 서비스를 온라인으로 전환하고, 최소한의 포그 보안 서비스에 대해 자신을 인증하며, 이들의 설계 기능을 수행할 수 있다. 또한 이러한 보안 서비스는 향후 감사를 위해 레코드를 저장할 수 있습니다. 자율성을 통해 필요할 때, 그리고 클라우드 연결과 상관없이 이러한 작업을 수행할 수 있습니다. 포그 노드는 관리자의 개입 없이 바이러스 검사 알고리즘 업데이트, DoS(서비스 거부) 공격 결정 등과 같은 진화하는 보안 위협에 자동으로 대응할 수 있습니다.
  • Autonomy of operation: 운영 자율성은 IoT 시스템의 현지화 의사 결정을 지원합니다. 센서는 에지에서 자율적 작업의 기초가 되는 데이터를 제공합니다. 시스템 계층의 클라우드 또는 단일 위치가 의사 결정을 할 수 있는 유일한 위치인 경우 안정성을 보장하는 기능을 위반하므로 아키텍처가 운영 자율성을 보장합니다.
  • Cost savings: 비용 절감은 자율성을 위한 핵심 동기입니다. 오늘날 연결에는 비용이 듭니다. 네트워크를 통해 전송되는 데이터가 많을수록 네트워크 요금으로 인해 기업에 더 많은 비용이 발생합니다. 따라서 추가 비즈니스 통찰력을 위해 필요에 따라 적시 데이터 및 적시 데이터를 클라우드로 전송하며 네트워크 에지에 더 많은 프로세싱이 필요합니다. 예를 들어, 오일 리그가 초당 3만 개의 데이터 지점을 생성하는 경우 모든 데이터가 값비싼 위성 링크를 통해 전송되지 않아야 합니다. 로컬 및 포그 영역 분석 및 사전 처리는 중요하지 않은 데이터 포인트를 자동으로 필터링하고 다음 계층으로 전달될 미션 크리티컬 데이터 포인트를 추출할 수 있습니다.

포그 컴퓨팅의 핵심 요소는 데이터를 실행 가능한 지혜로 바꾸는 것입니다. 우리는이 DIKW라는 용어를 사용합니다. "수집 된 __D__ata는 저장되고 검색될 때 __I__nformation이 됩니다. __K__nowledge는 자율 사물인터넷(IoT)을 위한 __W__isdom을 가능하게 합니다." 이 원칙은 가장 가까운 곳에 자율적으로 의사결정을 내릴 수 있는 국지적 분석의 기초입니다.

4.5 Programmability Pillar

프로그래머빌리티 필러는 소프트웨어 및 하드웨어 계층에서의 프로그래밍 지원을 포함하여 고도로 적응적인 배치를 가능하게 합니다. 즉, 포그 노드 또는 포그 노드 클러스터를 다시 작업하여 운영 역학을 수용하도록 할 수 있습니다. 이 작업은 범용 컴퓨팅 또는 가속기 인터페이스를 사용하여 설명하는 프로그래밍 가능한 인터페이스 고유의 포그 노드를 사용하여 수행할 수 있습니다. 포그 노드의 프로그래머빌리티에는 다음과 같은 이점이 포함됩니다.

  • Adaptive infrastructure: 다양한 IoT 구축 시나리오와 변화하는 비즈니스 요구사항을 지원하는 적응형 인프라
  • Resource efficient deployments: 컨테이너화를 비롯한 다양한 기능을 사용하여 자원을 최대화하는 자원 효율적인 배치. 이로 인해 구성 요소의 이식성이 향상되고 프로그래밍 가능성으로 인해 핵심 설계 목표가 달성
  • Multi-tenancy: 논리적으로 분리된 런타임 환경에서 여러 테넌트를 수용할 수 있는 멀티 테넌시
  • Economical operations: 변화하는 요구사항에 맞춰 인프라를 조정할 수 있는 경제적인 작업
  • Enhanced security: 진화하는 위협에 자동으로 패치를 적용하고 보다 신속하게 대응할 수 있는 향상된 보안 기능

4.6 Reliability, Availability, and Serviceability (RAS) Pillar

안정성, 가용성 및 서비스 가능성(RAS)은 성공적인 시스템 아키텍처 전반에 걸쳐 상주하므로 OpenFog RA에서 매우 중요합니다. 하드웨어, 소프트웨어 및 운영은 RAS 필러의 세 가지 주요 영역입니다.

신뢰할 수 있는 배포는 정상 및 불리한 작동 조건에서 설계 기능을 계속 제공할 것 입니다. RAS 필러의 신뢰성은 다음 특성을 포함하지만 이에 국한되지는 않습니다.

  • 소프트웨어가 작동 중인 기본 하드웨어의 안정적인 작동을 보장하여 일반적으로 가동 시간으로 측정되는 안정적이고 탄력적인 소프트웨어 및 안정적인 포그 네트워크를 지원합니다.
  • 향상된 하드웨어, 소프트웨어 및 네트워크 설계를 사용하여 에지 게이트웨이에서 데이터 및 컴퓨팅의 가용성 및 무결성을 보호합니다.
  • 시스템 상태에 따라 하드웨어 및 소프트웨어에 대한 자가 복구 루틴을 시작하고 새로운 펌웨어/애플리케이션 및 보안 패치를 업그레이드하는 데 필요한 경우 자가 예측 및 적응형 자가 관리 기능.
  • 지원 및 장치 자가 최적화 및 복구를 간소화하여 고객 만족도 향상.
  • 새로운 하드웨어 및 소프트웨어 패치, 네트워크 재라우팅 등 예방 유지 보수 요청
  • 다양한 환경 조건에서 장치 드라이버 및 진단 도구를 포함한 시스템 구성 요소 테스트 및 검증
  • 알람, 보고서, 로그 등
  • 상호 운용성 인증 테스트 스위트를 통한 시스템 플랫폼 및 아키텍처 검증

가용성은 일반적으로 가동 시간으로 측정되는 지속적인 관리 및 조정을 보장합니다. RAS 기둥의 가용성은 다음 특성을 포함하며 이에 국한되지 않습니다

  • 업그레이드 가능성, 진단 및 안전한 펌웨어 수정을 포함하여 오케스트레이션, 관리 효율성 및 제어를 위한 포그 계층의 모든 수준에서 안전하게 액세스
  • 장애 격리, 장애 증상 감지 및 기계 학습을 통해 장애가 발생한 시스템의 평균 수리 시간인 MTTR (Mean Time To Repair)을 향상시켜 가용성을 높임
  • 시스템 전반에서 인터페이스를 사용할 수 있도록 지원하는 클라우드 기반 백엔드 개념
    • 다수의 장치에서 안전한 원격 액세스 (단일 콘솔이 아님)
    • 중복/복제 장치 (peer-to-peer) IoT 플랫폼
    • 엔드 포인트 센서/피어링의 메쉬 액세스 기능
    • 플랫폼의 원격 부팅 기능
      • BIOS (최저 수준 펌웨어)에서 계층 구조의 최상위 소프트웨어 (클라우드)까지 수정 및 제어
    • 지속적인 생산성을 위한 중복 구성 지원

포그 배치를 서비스하면 올바른 작동이 보장됩니다. RAS 필러의 서비스 가능성은 다음 속성을 포함하지만 이에 국한되지 않습니다.

  • 고도로 자동화 된 설치, 업그레이드 및 수리로 포그 컴퓨팅을 효율적으로 배치
  • 하드웨어 또는 소프트웨어는 자율치유되거나 다양한 제조업체가 서비스 제공
  • 유지 보수의 용이성
  • 시스템의 서비스 가능성:
    • 하드웨어, 소프트웨어, 애플리케이션, 네트워킹 및 데이터
    • 하드웨어 액세스/스왑 아웃 (구성 요소 상호 운용성) 용이
    • 로컬 또는 원격 및 실시간으로 소프트웨어, BIOS 및 애플리케이션을 쉽게 업그레이드
    • 대체/스왑 아웃 시스템에서 클라우드를 통한 시스템 구성 복제
  • 지속적인 생산성을 위한 중복 구성 지원

RAS는 열악한 환경 조건과 원격 위치에서의 OpenFog RA 배치에 특히 중요합니다. RAS의 측면이 아키텍처 전반에서 발견되는 이유입니다.

4.7 Agility Pillar

민첩성 기둥은 OpenFog RA 배포에 대한 비즈니스 운영 결정을 해결합니다. 사람이 IoT에서 예측한 규모로 생성된 데이터를 신속하고 건전한 비즈니스 및 운영 의사결정의 기초로 분석하는 것은 불가능합니다. 민첩성 필러는 이러한 양의 데이터를 실용적인 통찰력으로 전환하는 데 중점을 둡니다. 또한 민첩성은 포그 배치의 매우 동적 특성과 변화에 신속하게 대응할 필요성을 다룹니다.

OpenFog RA 배치에서 센서와 시스템에 의한 데이터 생성은 격동적이고 폭발적이며 종종 대규모 볼륨에서 생성됩니다. 가장 중요한 것은 데이터가 수집, 집계 및 분석되는 경우에만 생성되는 컨텍스트가 없을 수 있다는 점입니다. 데이터 분석은 클라우드 레벨에서 실행할 수 있지만, 이로 인해 지연 시간이 늘어납니다. 이상적인 접근 방식은 데이터가 의미 있는 컨텍스트로 변환되는 즉시 운영상의 결정을 내리는 것입니다. 아키텍처는 주어진 시나리오에 가장 적합한 데이터 생성에 가까운 컨텍스트를 생성할 수 있도록 합니다. 보다 전략적인 시스템 차원의 의사결정과 정책관리는 포그 계층 구조에서 한층 더 강화될 수 있습니다. 이렇게 하면 다른 OpenFog RA 필러에 설명된 대로 "네트워크 요금"이라고 하는 네트워크 종속성을 방지할 수 있습니다.

OpenFog 아키텍처 접근 방식을 사용하면 IoT 시스템 개발자가 의사결정 구성요소로 애플리케이션 배치를 최적화할 수 있습니다.

4.8 Hierarchy Pillar

컴퓨팅 및 시스템 계층 구조는 모든 OpenFog 아키텍처에 필요하지 않지만 여전히 대부분의 배포에서 표현됩니다. OpenFog 아키텍처는 부분적으로 OpenFog 계층 구조 필러로 인해 기존 클라우드 아키텍처와 보완됩니다.

OpenFog RA 컴퓨팅 리소스는 엔드 투 엔드 IoT 시스템의 기능 요구사항을 기반으로 하는 논리적 계층으로 볼 수 있습니다. 다루는 시나리오의 규모와 특성에 따라, 계층 구조는 물리적 또는 논리적 계층으로 배열된 스마트하고 연결된 분할된 시스템의 네트워크이거나 단일 물리적 시스템(확장성 필러)으로 붕괴될 수 있습니다.

스마트 시티의 빌딩 자동화를 예로 들면, 단일 사무실 단지를 관리하는 회사는 전체 포그 전개를 지역에 배치할 수 있습니다. 대규모 상업용 부동산 관리 회사는 중앙 집중식 시스템과 서비스에 정보를 제공하는 지역 및 지역 수준의 포그 구축을 분산시켰을 수 있습니다. 각 포그 노드는 자체(자율 필러)로 관리되는 시설의 중단 없는 운영을 보장합니다.

아래 그림은 컴퓨터 관점에서 IoT 시스템의 논리적 관점을 보여줍니다. 계층의 각 계층은 IoT 시스템의 특정 문제를 해결합니다.

Devices in the hierarchy: 센서와 액추에이터 장치는 물리적 것이며 모니터링 및 제어 계층에 의해 소비되는 원격 측정 데이터를 생성합니다. 이 계층은 모니터링되는 프로세스가 원하는 상태에서 벗어날 경우 원격측정법을 분석하고 작동 명령을 생성합니다. 프로세스라는 용어는 일련의 액츄에이터 설정에 따라 측정된 파라미터 세트로 표현된다는 추상적 의미로 사용됩니다. 도메인 문제에 따라 일부 시스템에는 액츄에이터가 없을 수 있습니다. 마찬가지로, 모바일 네트워크 가속과 같은 시나리오의 경우 핵심 기능은 모니터링 및 제어가 아닌 컨텐츠 전달을 가속화하는 것입니다. 반면에 건물 운영과 같은 시스템에는 거주자에 따라 HVAC 및 조명을 변경하는 액츄에이터가 있을 수 있습니다.

Monitoring and control in the hierarchy: 센서와 액추에이터는 프로세스 상태를 모니터링하고 제어하도록 프로그래밍된 마이크로컨트롤러에 연결됩니다. 프로세스 상태는 센서에 의해 측정되고 액추에이터에 의해 수정되는 일련의 매개 변수로 표시됩니다. 이 계층의 주된 책임은 센서 원격측정기의 상태 저장 검사를 통해 제어 논리를 실행하는 것이다. 여기에는 경보를 계산하고 이벤트를 생성하는 작업이 포함되며, 이는 기계 간 또는 사람의 개입을 통해 워크플로우를 트리거할 수 있습니다.

Operational support in the hierarchy: 운영 지원 계층은 스트리밍 원격 측정 분석 및 운영 지향 분석 저장을 담당합니다. 분석은 제어실 대시보드 및 모바일 애플리케이션과 같은 인터페이스를 통해 제공될 수 있습니다. 이 계층의 분석 범위는 좁습니다. 즉, 시스템이 담당하는 물리적 환경의 운영 측면에 초점을 맞춥니다. 이 계층은 드릴다운 내역 분석 및 스트리밍 분석을 결합하여 실시간 작업의 합성 사진을 일부 단기 내역과 결합합니다. 민첩성 필러는 계층 구조에서 스트리밍 원격 측정 데이터에 대한 복잡한 이벤트 처리를 구현하는 것으로 보입니다.

Surrogacy in the hierarchy: 포그 노드에서 복잡한 연산은 인접한 자원을 활용하기 위해 계층적 노드로 위임 될 수 있습니다. 스마트 안경과 같은 웨어러블과 관련된 가상 현실 작업을 고려하십시오. 정보 검색 및 컴퓨팅 작업 중 일부는 안경에서 수행 될 수 있는 반면, 계층 구조의 관련 요소 (예 : 스마트 폰)는 저장 및 연결 요구 사항을 처리 할 수 있습니다. 이 계층적 아키텍처는 이러한 모든 장치를 지능적으로 분리하여 동시에 활용할 수 있습니다.

Business support in the hierarchy: 이 계층의 주요 책임은 여러 시스템에 걸쳐 있는 IoT 작업의 전체 기록을 저장하고 분석하는 것입니다. 이는 IoT 운영 기록 시스템으로서, 규정 준수 및 기록 보존 정책에 따라 결정됩니다. 페타바이트 규모의 분석은 광업 통찰력, 비즈니스 계획 수립, 프로세스의 운영 효율성 비교, 교육 기계 학습 모델을 통한 운영 최적화 등에 도움이 됩니다. 또한 메타데이터 및 참조 데이터 관리, 비즈니스 규칙 관리 및 하위 계층의 운영 상태는 이 계층의 다른 측면입니다. 이러한 것들은 민첩성 필러에서도 볼 수 있습니다.

4.8.1 Hierarchical Fog Deployment Models

아래 그림에는 IoT 시스템의 계층화된 뷰에 의해 프레임된 다양한 도메인 시나리오에 대응하기 위해 구현된 포그와 클라우드의 조합이 나와 있습니다. 각 포그 요소는 동일한 기능적 책임을 수행하는 포그 클러스터의 계층을 나타낼 수 있습니다. 시나리오에 따라 여러 개의 포그 및 클라우드 요소가 단일 물리적 배포로 축소될 수 있습니다. 또한 각각의 포그 요소는 연결된 차량, 전기 차량 충전 및 폐쇄 루프 트래픽 시스템과 같은 사용 사례에서 피어 포그 노드의 메쉬를 나타낼 수 있다. 이 사용 사례에서 포그 노드는 상황별 인텔리전스를 교환하기 위해 안전하게 검색 및 통신할 수 있습니다.

그림의 1은 클라우드와 독립적인 포그 전개 계층 구조를 보여줍니다. 이 모델은 작업 시간대에 대한 낮은 이벤트, 규정 준수, 군사 등급 보안 및 개인 정보 보호, 특정 지역의 중앙 클라우드 사용 불가 등과 같은 이유로 클라우드를 사용할 수 없는 사용 사례에 적용할 수 있습니다. 예를 들면, 군대 전투 시스템, 드론 운영, 일부 의료 시스템, 병원, ATM 은행 시스템 등이 있습니다.

그림의 2는 의사 결정과 관련된 정보 처리에 사용되는 클라우드를 보여줍니다.이 클라우드는 시간 대 일에서 월간의 Event-to-Action 시간대를 가질 수 있습니다. 운영 중심의 정보 처리는 관리되는 인프라/프로세스에 가까운 포그 배치로 수행됩니다. 사용 사례로는 상업용 건물 관리, 상용 태양광 패널 모니터링 및 소매업이 포함됩니다.

그림의 3은 시간에 민감한 계산에 사용되는 로컬 포그 인프라를 보여 주는 반면 클라우드는 운영 및 비즈니스 관련 정보 처리의 균형을 위해 사용됩니다. 사용 사례로는 상용 UPS 장치 모니터링, 모바일 네트워크 가속 및 인터넷 가속을 위한 CDN(Content Delivery Network)이 있습니다.

그림의 4는 농업, 연결된 차량 및 원격 기상 관측소와 같은 사용 사례를 지원합니다. 이러한 유스 케이스는 포그 인프라 구축이 실현 불가능하거나 경제적인 환경 때문에 전체 스택에 대해 클라우드를 활용합니다. 장치 계층의 포그 노드는 안전과 관련된 제어를 위해 모니터링 및 제어 기능을 일부 수행 할 수 있습니다. 엔터프라이즈 시스템은 비즈니스 운영을 위해 클라우드와 통합됩니다.

그림의 1-3에 표시된 기능적 경계는 유동적이며 도메인별 솔루션의 아키텍처를 기반으로 다수의 조합으로 물리적으로 배치될 수 있습니다. 앞에서 설명한 것처럼 실제 구현에서는 여러 엔티티가 소유한 멀티 테넌트, 포그 및 클라우드 배포를 포함하는 여러 물리적 구현의 조합이 있을 수 있습니다. 다음 다이어그램은 이러한 모델을 보여 줍니다.

많은 용도가 위 그림에 나타난 바와 같이 발생할 것입니다. 여기에 표시된 3개 층의 포그 계층은 예시용입니다. 실제 포그 구축의 수준은 다소 높을 수 있습니다. 다른 수직적 애플리케이션 사용 사례는 포그 계층을 다르게 사용할 수 있습니다. 예를 들어, 스마트 시티에는 지역, 이웃, 거리 구석 및 건물 레벨에 포그 노드가 있을 수 있습니다. 스마트 공장에서는 계층이 조립 라인, 제조 셀 및 기계로 분류될 수 있습니다.

5 Reference Architecture Overview

OpenFog 참조 아키텍처는 이전 장에서 설명한 8개의 필러를 기반으로 합니다. 우리는 ISO/IEC/I 4 42010:2011 국제 표준을 이해관계자들에게 아키텍처를 설명하기 위한 지침으로 사용합니다. 이 표준은 IoT 전반에 걸친 공통 어휘를 통해 조직 간 기술 협력을 지원합니다. OpenFog RA에서 사용되는 공유 어휘는 다음과 같습니다:

  • OpenFog Architecture Description: 포그 노드의 인스턴스를 추상적으로 나타냅니다. 이것은 포그 컴퓨팅 가치 사슬의 이해당사자들을 다루기 위해 사용했던 여러 가지 관점을 종합한 것입니다.
  • Viewpoint: 관점은 시스템을 보는 방법입니다. 여기에는 Functional 및 Deployment 관점이 포함되지만 이에 국한되지는 않습니다.
  • View: 뷰는 아키텍처의 하나 이상의 구조적 측면을 표현한 것입니다. OpenFog RA의 현재 개정판에서 구조적인 측면은 소프트웨어 View, 시스템 View 및 노드 View 입니다.
  • Perspective: 관점은 아키텍처의 크로스 컷팅에 대한 것 입니다.

5.1 Functional Viewpoint

아키텍처의 기능적 관점은 주어진 시나리오를 만족시키기 위해 이해관계자들의 다양한 관심사를 다루기 위해 OpenFog 아키텍처 요소 및 뷰를 적용하는 방법을 보여줍니다. 선택한 각 시나리오는 포그 컴퓨팅을 위한 다른 측면과 시장 기회에 초점을 맞출 것입니다. 우리는 Architecture Description, 뷰 및 관점(Viewpoint) 이 시간이 지남에 따라 변할 수 있다고 기대합니다. 이러한 변화와 개선은 OpenFog RA의 테스트베드 및 적용에서 포그 컴퓨팅에 중요하다고 생각되는 여러 다른 시장에 이르기까지 추진되어야 합니다.

첫 번째 End-to-End 시나리오는 시각적 보안 시나리오입니다. 우리의 목적은 시나리오의 작동 방식을 정의하고, 그 측면과 관련된 다양한 테스트베드를 통해 아키텍처를 검증하거나 수정하는 것입니다.

5.2 Deployment Viewpoint

5.2.1 OpenFog Deployment Types

주어진 시나리오를 해결하기 위해 포그 소프트웨어 및 포그 시스템을 배치하는 방법 또한 매우 중요합니다. 완전히 상호 연결된 임베디드 시스템부터 대규모 클러스터 시스템에 이르는 많은 배치 유형이 있습니다. 선택한 배포 유형은 시나리오에 따라 다르지만 아키텍처의 주요 측면은 배포 유형에 관계없이 계속 표시됩니다. 그러나, 어떤 것들은 중요성이 커지거나 줄어들 수 있습니다.

5.2.2 N-Tier Fog Deployment

대부분의 포그 배포에는 대개 여러 계층 (N 계층)의 노드가 있습니다. 이 예에서는 간단한 식품 가공 공장을 사용하여 논리적 계층을 강화합니다. 포장 및 선적의 다음 단계로 이동하기 전에 식품이 처리되는 컨베이어 벨트가 있습니다.

  • 에지 노드는 일반적으로 센서 데이터 획득/수집, 데이터 정규화, 센서 및 액추에이터의 명령/제어에 중점을 둡니다.
    • 이 예를 사용하면 컨베이어 벨트에서 가장 가까운 포그 노드가 제품 오염을 방지하고 작동 안전을 보장하기 위해 감지에서 작동까지 1000분의 1초 미만의 정밀도로 작동해야합니다.
  • 다음 상위 계층의 노드는 데이터 필터링, 압축 및 변환에 초점을 맞 춥니 다. 또한 중요한 실시간 또는 거의 실시간 처리에 필요한 일부 에지 분석을 제공 할 수 있습니다. 진정한 네트워크 에지에서 멀어지면서 우리는 보다 높은 수준의 기계 및 시스템 학습 (분석) 기능을 보게됩니다.
    • 이전 예를 사용하면 이 계층이 약간 더 높은 수준에서 운영되어야 한다는 것을 쉽게 알 수 있습니다. 컨베이어 벨트와 주변의 다른 벨트가 더 효율적으로 작동하는지 확인해야 합니다. 이는 여전히 밀리초 단위의 지연 시간일 수 있습니다. 시나리오에서 요구하는 가장 낮은 계층과 중간 계층 사이의 기능 및 애플리케이션의 마이그레이션을 지원하는 것은 OpenFog RA의 핵심 요소입니다.
  • 상위 계층 또는 가장 가까운 백엔드 클라우드의 노드는 일반적으로 데이터를 집계하고 지식으로 전환하는 데 초점을 맞춥니다. 중요한 것은 경계에서 멀어질수록 실현 가능한 통찰력이 커진다는 것입니다.

Note: 일부 배치 모델에서는 네트워크 에지 노드 (예 : 감시 카메라의 비디오 분석)에 어느 정도의 분석이 위치 할 수 있습니다. 이는 네트워크 파이프가 처리를 위해 상위 센서 포그 노드로 원시 센서 데이터를 효율적으로 전송하는 데 비용이 많이 들지 않을 수 있기 때문입니다. 실제로 컴퓨팅산 기능이 커짐에 따라 하위 계층의 분석 기능이 커집니다. 이를 통해 시간이 지남에 따라 포그 설치의 지능이 전반적으로 향상 될 수 있습니다.

오늘날 기계 학습은 두 교육 모델에 대한 계산이 필요한 연구의 최전선에 있으며, 이러한 모델을 예측하거나 평가하여 가장 가까운 실시간 응답에 근접하게 합니다. 우리는 기계 학습을 이용하여 스마트 시티의 기차역에서의 운영을 최적화할 수 있습니다. 기차역에서는 점유, 이동 및 전반적인 시스템 사용을 모니터링하고 감지할 수 있었고 시간이 지남에 따라 인프라를 조정하여 가장 효율적으로 사용하는 방법을 결정할 수 있었습니다.

스마트 도시를 계속 사용하여 더 많은 건물을 포함시키고 서로 이야기하고 더 높은 통찰력을 얻기 위해 다른 계층을 사용함으로써 도시 블록을 보다 효율적으로 운영 할 수 있습니다. 건물 블록에서 학습하면 전체 도시를보다 효율적으로 만드는 방법에 대한 통찰력을 얻을 수 있습니다. 핵심 메시지는 진정한 네트워크 에지에서 멀어 질수록 운영 통찰력을 확보하고 전반적인 시스템 인텔리전스를 높일 수 있다는 것입니다. 또한 이러한 포그 노드간에 수평 및 수직으로 데이터를 마이그레이션하면 시스템 성능과 운영 기능이 향상됩니다.

5.2.2.1 How Use Cases Determine the Number of Tiers

포그 배포는 지정된 시나리오에 따라 대규모 및 소규모로 제공됩니다. 포그 배치의 계층 수는 다음과 같은 시나리오 요구 사항에 따라 결정됩니다.

  • 각 계층에 필요한 작업의 양과 유형
  • 센서 수
  • 각 계층의 노드 기능
  • 노드 사이의 대기 시간과 센서와 작동 사이의 대기 시간
  • 노드의 신뢰성/가용성

일반적으로 N 계층 환경의 각 레벨은 의미 있는 데이터를 선별 및 추출하여 각 수준에서 더 많은 인텔리전스를 생성합니다. 계층은 처리해야하는 데이터의 양을 효율적으로 처리하고 더 나은 운영 및 시스템 인텔리전스를 제공하기 위해 만들어집니다. 최상위 레벨에서 이것은 아래의 그림으로 나타낼 수 있습니다.

우리가 시간을두고 해결해야 할 중요한 측면은 각 레벨에서 실행되는 소프트웨어와 각 노드가 노드 간에 마이그레이션되고, 하드웨어 노드의 물리적 인스턴스화가 확장되며, 특정 시나리오의 요구 사항을 충족하기 위해 시간이 지남에 따라 변경되어야 한다는 것입니다. 이를 위해 소프트웨어뿐만 아니라 해당 소프트웨어가 실행되는 하드웨어도 해결해야 합니다.

5.2.2.2 Fog Node Uniformity

노드의 아키텍처 요소는 N 계층 포그 배치 내의 역할 및 위치에 따라 달라집니다. 앞에서 설명한 것처럼 에지 노드는 상위 수준의 노드보다 처리, 통신 및 저장량이 적은 상태로 설계될 수 있습니다. 그러나 에지에서 센서 데이터를 쉽게 사용할 수 있도록하는 I/O 가속기는 상위 노드에 맞게 설계된 I/O 가속기보다 훨씬 클 수 있습니다.

포그 노드는 메쉬를 형성하여 로드 밸런싱, 복원력, 내결함성, 데이터 공유 및 클라우드 통신 최소화를 제공할 수 있다. 구조적으로, 이를 위해서는 포그 노드가 포그 계층 내에서 상하(north-south)뿐만 아니라 가로 방향(피어 투 피어 또는 east-west) 통신할 수 있어야 합니다. 또한 RAS를 유지하기 위해 노드는 다른 노드의 서비스를 검색, 신뢰 및 활용할 수 있어야 합니다. 이전의 건물과 도시 예를 사용하여 다음 그림을 볼 수 있습니다.

각 건물이 연결되고, 각 지역이 연결되어 서비스 제공에 최적화 된 인프라를 제공합니다.

5.3 OpenFog Architecture Description

앞서 설명했듯이, 포그 컴퓨팅은 짧은 대기 시간과 안정적인 운영을 가능하게 하며 오늘날의 많은 새로운 시나리오를 해결하기 위한 지속적인 클라우드 연결 요구사항을 없애주기 때문에 매우 중요합니다. 또한 전체 시스템 인텔리전스 및 운영을 강화하기 위해 포그 노드를 부분적으로 또는 완전히 연결할 수 있는 방법과 원시 데이터 처리에서 멀리 떨어진 곳에서 시스템 전체 인텔리전스가 증가하는 방법을 설명했습니다.

다음 단계는 포그 컴퓨팅 연속체의 각 이해관계자에 대한 요구사항을 설명하는 것입니다. 여기에는 실리콘 제조업체, 시스템 제조업체, 시스템 통합업체, 소프트웨어 제조업체 및 애플리케이션 개발자가 포함됩니다. 또한 우리는 이 아키텍처가 다양한 이질적인 에지 기반 컴퓨팅을 조정하는 데 도움이 될 것으로 믿지만, 단일 언어 환경에서 잠재적으로 다른 작업을 수행할 수 있으므로 우리는 공통 기준을 가지고 멀티벤더 상호운용이 가능한 컴퓨팅에 대한 우리의 요구를 충족시킬 수 있습니다. OpenFog RA는 이러한 다양한 이해관계자 우려를 종합적으로 나타낸 것이며, 이를 뷰라고 합니다. 이러한 이해관계자와 관련 뷰는 성공적인 포그 기반 구축을 촉진해야 하기 때문에 확인되었습니다. 관점의 하위 수준으로 들어가기 전에 먼저 복합 아키텍처 설명을 살펴보는 것이 중요하다고 생각합니다.

추상적 아키텍처는 구조 설명의 측면에 있는 회색 세로 막대로 표시된 관점을 포함한다. 이러한 관점은 다음과 같습니다:

  • Performance: 낮은 지연 시간은 포그 아키텍처를 채택해야 하는 원동력 중 하나입니다. 여러 이해당사자 간에 여러 요구사항과 설계 고려사항이 있어 이를 충족할 수 있습니다. 여기에는 시간이 중요한 컴퓨팅, 시간에 민감한 네트워킹, 네트워크 시간 프로토콜 등이 포함됩니다. 이는 시스템 및 구축 시나리오에 영향을 미치기 때문에 우려되는 사항입니다.
  • Security: 엔드 투 엔드 보안은 모든 포그 컴퓨팅 구축 시나리오의 성공에 매우 중요합니다. 기본 실리콘이 안전하지만 상위 계층 소프트웨어에 보안 문제가 있는 경우(그 반대도 마찬가지) 솔루션은 안전하지 않습니다. 데이터 무결성은 현재 적절한 보안이 결여된 장치의 보안의 특별한 측면입니다. 여기에는 의도적인 손상과 의도하지 않은 손상이 포함됩니다.
  • Manageability: RAS, DevOps 등을 포함한 포그 배포의 모든 측면을 관리하는 것은 포그 컴퓨팅 계층의 모든 계층에서 매우 중요한 측면입니다.
  • Data Analytics and Control: 포그 노드가 자동으로 작동하려면 지역화된 데이터 분석과 제어가 필요합니다. 작동/제어장치는 주어진 시나리오에 따라 계층 내의 올바른 계층 또는 위치에서 발생해야 합니다. 항상 물리적 가장자리에 있는 것은 아니지만 상위 계층일 수 있습니다.
  • IT Business and Cross Fog Applications: 멀티벤더 에코시스템 애플리케이션의 경우 모든 수준의 포그 배포 계층에서 마이그레이션하고 올바르게 작동하는 기능이 필요합니다. 애플리케이션에는 또한 가치를 극대화하기 위해 배포의 모든 수준을 아우르는 기능도 있어야 합니다.

앞에서 논의한 바와 같이 OpenFog RA 설명은 주어진 포그 컴퓨팅 배치나 시나리오를 만족시키기 위해 사용되는 여러 이해관계자의 견해와 관점을 종합한 것입니다. 우리가 확인한 세 가지 보기는 소프트웨어, 시스템 및 노드입니다.

  • Software view: 아키텍처 설명에 표시된 상위 3개 계층에 표시되며, 애플리케이션 서비스, 애플리케이션 지원 및 노드 관리(IB) 및 소프트웨어 백플레인이 포함됩니다.
  • System view: 아키텍처 설명에 표시된 중간 계층으로 표시되며 하드웨어 플랫폼 인프라를 통한 하드웨어 가상화가 포함됩니다.
  • Node view: 프로토콜 추상화 계층 및 센서, 액추에이터 및 제어를 포함하는 그림에 표시된 하단 두 레이어에 표시됩니다.

Note: 포그 플랫폼과 포그 소프트웨어가 결합되면 전체 포그 노드가 생성됩니다. 하나 이상의 포그 노드는 주어진 시장 세그먼트 또는 시나리오에서 솔루션을 구성합니다.

그러나 OpenFog RA를 포함한 상위 수준의 아키텍처는 엔지니어, 설계자 및 비즈니스 리더가 각자의 특정 요구 사항과 주어진 시나리오에 포그 노드를 적용할 수 있는 방법을 이해하도록 돕기 위한 것입니다. OpenFog 컨소시엄의 목표는 포그 컴퓨팅에 대한 시장 부문(사용 사례)의 수와 비즈니스 가치를 높이는 것입니다. OpenFog는 이러한 시장 부문에 적용할 테스트베드를 만듭니다. 또한 이러한 테스트베드는 FogFests(플러그 페스트)를 통해 구성요소 레벨 상호 운용성을 높이고 출시 시간을 단축할 수 있습니다.

다음 절에서는 RA의 구조적 측면 (뷰)과 관점에 대해 자세히 설명합니다.

5.4 Perspectives (Cross Cutting Concerns)

포그 구현 전반에 걸쳐 크로스-커팅 관점이 사용됩니다. "크로스-커팅"은 아키텍처 계층을 가로지르는 기능을 의미합니다. 아래 그림은 포그 컴퓨팅 아키텍처의 5가지 크로스-커팅 관점을 보여줍니다.

5.4.1 Performance and Scale Perspective

포그 컴퓨팅이 클라우드 기반 애플리케이션 및 분석의 인텔리전스 일부를 네트워크 에지(또는 데이터 소스에 최대한 가깝게)에 가져올 경우, 전체 시스템의 성능(해당 시스템이 정의되는 방식)이 개선됩니다. 포그 컴퓨팅은 또한 시스템이 변화하는 트래픽 패턴에 더 잘 적응할 수 있게 해줄 것입니다. 즉, 성능 향상이 더 빠르게 이루어지며 비즈니스 사례 요구 사항에 더 적합하고 구체적입니다.

성능에 대한 또 다른 요구 사항은 한 영역의 개선이 보장된 서비스 품질이나 성능이 요구되는 다른 프로세스를 방해하거나 지연시켜서는 안 된다는 것이다. 포그 노드의 성능을 측정할 때 대개 처리량과 지연 시간을 살펴봅니다. 둘 다 전체 시스템에서 트래픽 유형 또는 클래스의 우선 순위를 지정하는 기능에 따라 달라집니다.

RA에서는 확장성과 격리를 지원하기 위해 가상화 기술과 컨테이너화 기술이 모두 포그 컴퓨팅에 사용됩니다. 이러한 최신 기술은 특정 애플리케이션 또는 서비스에 더 높은 우선 순위 또는 더 많은 리소스를 동적으로 할당하는 기능을 추가로 지원합니다. 예를 들어, 높은 우선 순위의 네트워크 트래픽은 네트워크 인터페이스, 컴퓨팅 요소 및 적절한 상위 계층 애플리케이션에 의해 표시하고 분류할 수 있습니다.

네트워크 대역폭과 로컬 스토리지에도 동적으로 높은 우선 순위가 부여될 수 있습니다. 예를 들어 트래픽 검사에 포그 노드를 사용하는 경우 CPU/메모리 우선 순위가 기록 저장 및 보존보다 높습니다.

5.4.2 Security Perspective

포그 컴퓨팅 인프라에서 엔드 투 엔드 보안은 클라우드와 네트워크 에지에 있는 것들 사이의 모든 것을 포함해야 합니다. 아키텍처에서 보안은 개별 포그 노드 하드웨어로 시작합니다. 노드가 신뢰할 수 있는 요소인지 확인하기 위한 적절한 보안으로 설계되지 않은 경우 신뢰할 수 있는 엔드 투 엔드 포그 컴퓨팅 인프라를 구축할 수 없습니다. 신뢰할 수 있는 포그 노드가 구축되면 노드 인프라 위에 안전한 포그 네트워크를 계층화하여 secure node-to-node, node-to-thing 및 node-to-cloud 통신을 위한 기반을 제공할 수 있습니다.

5.4.2.1 Trusted and Trustworthiness

신뢰할 수 있는 포그 시스템은 특정 장치에 지정된 보안 정책을 유지하는 책임을 지는 신뢰할 수 있는 요소의 사용에 의존합니다. 노드에서 하나 이상의 신뢰할 수 있는 구성 요소(하드웨어, 펌웨어 또는 소프트웨어)가 손상된 경우 노드와 더불어 시스템을 더 이상 신뢰할 수 없습니다. RA는 또한 시스템과 그 구성요소가 신뢰할 수 있는 방식으로 작동하는지 결정하기 위해 계층의 다양한 수준에서 과거 행동을 검사하여 행동을 포함한 신뢰할 수 있는 속성을 결정합니다.

정책은 어떤 상황에서 어떤 리소스에 액세스할 수 있는지 지정합니다. 그런 다음 정책을 구현합니다. 일부 정책은 노드의 하드웨어 및 소프트웨어에 포함될 수 있습니다. 다른 정책은 포그 관리 시스템에서 노드로 푸시될 수 있으며, 인증된 관리 또는 오케스트레이터 관리자가 추가, 변경 또는 삭제할 수 있습니다. 포그 배포의 각 계층은 아래 그림과 같이 보안이 필요합니다.

5.4.2.2 Threat Models and Threat-Based Design

포그 배포에는 위협 모델 및 해당 포그 노드에 대해 보호되는 자산의 가치에 따라 특정 설계에 구현되는 보안 보호 메커니즘이 필요합니다. 아키텍처에서는 공격자가 가장 취약한 진입 지점을 찾아 적극적으로 자산을 손상하려고 한다고 가정합니다. 목표는 위협 모델에 충분한 보안을 제공하고 필요에 따라 시간에 따라 보안을 업그레이드하는 것입니다. Error! R eference source not found. 포그 노드에 대한 위협 및 공격의 일부 (비 한정적인) 예를 나열합니다. 포그 환경에서 위협을 설계할 때는 각 뷰와 해결 중인 전체 배포 모델을 이해해야 합니다. 많은 포그 배포 환경에서 물리적 소유가 범위를 벗어나서 포그 플랫폼에 요구 사항을 더 추가한다고 가정할 수 없습니다.

단일 유즈케이스 수직 내에서라도 다양한 유즈케이스 모델을 사용하려면 다양한 유형과 보안 수준이 필요할 수 있습니다. 많은 다른 유형의 자산은 의도된 용도 및 위치에 따라 다른 수준의 위협으로부터 보호되어야 합니다. 자산에는 다음이 포함될 수 있습니다.

  • Information Technology infrastructure
  • Critical infrastructure
  • Intellectual property
  • Financial data
  • Service availability
  • Productivity
  • Sensitive information
  • Personal information
  • Reputation

Threat (위협): 자산을 손상 시키거나 보안 위반을 초래할 수있는 행동 (공격).

Threat model (위협 모델): 시스템이 방어하는 위협 유형과 고려되지 않은 위협 유형을 지정합니다. 위협 모델은 시스템, 사용자 및 잠재적 공격자에 대한 가정이 명확하게 지정되어야 합니다. 위협 모델은 보호 대상인 공격의 세부 사항을 설명 할 필요가 없습니다. 현장의 운영 시스템에 대한 공격만 고려해야 하는지 또는 내부자에 의한 개발 중 공격을 고려해야 하는지를 지정해야 합니다. 내부자 공격은 일반적으로 보호하기가 훨씬 더 어렵습니다. 설계자가 나중에 악용 될 수 있는 백도어를 만들 수 있기 때문입니다.

5.4.2.3 Confidentiality, Integrity, and Availability

포그 보안 관점에는 세 가지 기본 요소가 있습니다.

Confidentiality (기밀성): 권한이 없는 기업에 대한 비밀 또는 민감한 정보의 공개 금지.

Integrity (무결성): 감지되지 않고 보호된 데이터 또는 코드의 무단 수정 방지.

Availability (가용성): 필요에 따라 합의된 서비스 수준에서 인증된 엔티티에 서비스를 계속 제공할 수 있는 시스템의 기능. 가용성은 보안 측면에서 하드웨어 및 소프트웨어 장애 및 결함뿐만 아니라 서비스 거부와 같은 외부 공격을 고려해야 합니다.

5.4.2.4 Access Control

리소스(객체)에 대한 액세스를 해당 정보에 액세스할 수 있는 객체로만 제한하는 것이 중요합니다. 액세스 제어에는 인증, 권한 부여 및 계정 (AAA)이 포함됩니다.

  • Authentication (인증): "당신은 누구입니까?"라는 질문에 대답합니다. 인증은 사람과 기계 사이 및 기계와 기계 사이에 사용됩니다.
  • Authorization (승인): "당신은 무엇을 할 수 있습니까?"라는 질문에 대답합니다.
  • Accounting: 시스템에 구현 된 기록 관리 및 추적 메커니즘을 의미합니다. 여기에는 시스템 자원에 대한 액세스 추적 및 로깅이 포함됩니다.
  • Physical access: 권한있는 사람만 포그 하드웨어를 만지는 것을 허용하는 물리적 액세스 보안은 보안 메커니즘의 또 다른 측면입니다.
5.4.2.5 Privacy

프라이버시는 정보가 어떻게 사용되는지 결정할 권리가 있습니다. 기밀성은 비밀 또는 민감한 정보를 보호해야 할 의무입니다. 개인 정보는 데이터의 속성입니다. 포그 시스템은 사용자가 시스템에서 소유하고있는 데이터의 개인 정보 속성을 지정할 수 있어야 합니다. 멀티 테넌트(Multi-tenant) 시스템에서는 테넌트 간의 개인 정보 보호 및 공유 권한을 모두 지정해야 할 수 있습니다. 포그 시스템이 에지에서 분석 할 데이터를 캡처하는 경우 해당 데이터의 개인 정보도 배포시 고려해야 합니다.

5.4.2.6 Identity and Identity Protection

공개 키 암호는 인증 등의 장기적인 사이버 ID를 설정하는 데 사용할 수 있습니다. 공개 키 암호화에서 키는 각 사용자, 엔티티, 컴퓨터 또는 주제에 대해 일치하는 쌍(공용 키 및 개인 키)으로 제공됩니다. 개인 키는 해당 대상에서만 액세스할 수 있어야 하며 사이버 공간에서 대상의 디지털 ID를 나타냅니다.

해시는 잘 알려진 코드 모듈의 해시를 취하여 모듈을 식별하기 위해 (고유 글로벌 이름) 코드 모듈의 무결성을 확인하는 데 사용할 수 있습니다. 멀웨어에 감염된 동일한 코드 모듈은 ID 또는 해시 값이 다릅니다. 두 개의 코드 모듈 또는 데이터는 동일하지만 파일 이름은 서로 다르므로 동일한 ID를 가진 해시 값을 가집니다.

키 쌍의 개인 키는 디지털 ID와 같습니다. 예를 들어 앨리스의 개인 키를 사용하여 실행한 작업은 해당 사용자를 앨리스로 인증할 수 있습니다. 다른 사람의 디지털 신원을 보호하기 위해서는 개인 키가 비밀에 부쳐져야 합니다.

5.4.3 Manageability Perspective

많은 포그 컴퓨팅 배포에는 기계 비전과 관련 인간 유사 기능이 포함됩니다. 따라서, 그들은 다른 포그 서비스에 참여하기 위해 자율적으로 보고, 반응하고, 기억하고, 움직이고, 그리고 결정 할 수 있는 능력을 가지고 있습니다. 이 작업 범위에는 기존 정적 모델보다 높은 수준의 관리성이 필요합니다. 또한 포그 노드는 원격, 고정 및 비고정 조건, 환경적으로 가혹한 조건 등 다양한 위치에 배치할 수 있습니다.

포그 컴퓨팅은 기존 IT 및 OT 관리 시스템에 비해 관리 서비스 변화를 주도하고 있습니다.

5.4.3.1 Manageability Interfaces

포그 컴퓨팅을 위해 구축된 관리 인터페이스는 In Band(IB) 또는 Out of Band(OOB) 관리 인터페이스 또는 둘 모두를 지원해야 합니다. IB 또는 OOB 관리 용이성을 사용하는 데는 장단점이 있지만 일반적으로 가장 적합한 선택은 지정된 배포 시나리오에 따라 달라집니다. 그러나 두 가지 모두 자율적인 관리 수준으로 전환할 때 사용될 수 있습니다.

  • IB manageability: 이는 특정 시스템에서 실행되는 소프트웨어 및 펌웨어에 표시되는 관리성 인터페이스를 나타냅니다. IB 관리 인터페이스는 특정 하드웨어 노드에 있는 경우 시스템 서비스 프로세서(SSP) 또는 베이스보드 관리 컨트롤러(BMC)와 통신할 수 있습니다. 그러나 이것이 필수는 아닙니다. 일부 시나리오에서는 IB 관리성이 별도의 OS 스레드 또는 정기 서비스에서 실행될 수 있습니다. 많은 시스템은 주어진 시스템의 상태를 관리하기 위해 "하트비트"를 사용합니다. IB 관리 스레드가 하트비트를 전송하지 않는 경우 상위 관리 엔티티가 다시 시작되거나 서비스 시스템에 이 문제의 알람을 보낼 수 있습니다.
  • OOB manageability: 이는 호스트 운영 체제에서 실행되지 않는 관리 효율성 및 하위 시스템에 대한 관리 효율성 인터페이스를 나타냅니다. 이러한 관리 시스템은 일반적으로 모든 전원 상태에서 시스템을 유지 및 관리할 수 있는 개별 관리 시스템입니다. 특히, 포그 플랫폼의 전원이 꺼져 있고 소프트웨어가 호스트 플랫폼에서 실행되지 않는 경우에도 OOB 관리 인터페이스는 여전히 플랫폼과 통신하여 IPC에 의해 정의된 인벤토리 제어, 시스템 상태, 전원 BMC 등의 작업을 수행할 수 있습니다. OOB 관리는 특히 비즈니스 크리티컬 IoT 애플리케이션의 경우 보안상 잠재적인 이점을 제공합니다.
5.4.3.2 Management Lifecycle

심지어 가장 작은 포그 노드도 관리 라이프사이클을 갖습니다. 아래 그림에서는 관리 라이프사이클의 주요 구성 요소를 관리 측면에서 보여 줍니다.

모든 시스템에는 하나 이상의 관리 에이전트가 있습니다. 이는 개별 시스템 또는 소프트웨어 서비스로 구현될 수 있습니다. 관리 에이전트의 목적은 포그 노드의 각 요소가 관리 라이프사이클을 성공적으로 통과하는지 확인하는 것입니다. 자동화는 라이프사이클의 모든 단계에서 중요합니다. 대규모 포그 네트워크에 대한 인간의 개입은 비현실적이기 때문입니다.

Commission: 이는 포그 플랫폼 라이프사이클의 초기 단계입니다. 관리 엔티티를 위임하면 프로비저닝하기 전에 특정 작업이 필요합니다. 여기에는 식별, 인증서, 시간 보정 등이 포함됩니다. 또한 이 상태에서 관리주체는 다음을 반드시 수행해야 합니다:

  • 라이프사이클의 향후 단계에서 입증되고 신뢰할 수 있는 보안을 포함합니다.
  • RAS (신뢰성, 가용성 및 서비스 가능성)를 포함.
  • 신속한 데이터 수집 및 모니터링.
  • 제어가 가능하고 리소스에 대한 가시성이 제공되도록 오픈.

Provision: 관리 엔티티는 포그 노드에서 초기 수명을 시작할 때 등록해야 합니다. 여기에는 검색, 식별, 기능 광고, 신뢰 및 기능 배포가 포함됩니다. 또한 관리 엔티티는 프로비저닝 시 확장 가능해야 합니다. 그것은 다수의 상위 계층을 지원하는 능력을 가지고 있어야 합니다.

Operate: 포그 노드가 정상 작동 중인 경우 관리성 요구 사항에는 신뢰성, 가용성 및 서비스 가능성의 모든 측면이 포함됩니다.

Recovery: 포그 노드가 예상된 규범을 벗어나 작동할 때, 그것은 회복 능력에 있어서 자율적이어야 합니다. 자가 복구 및 복구 작업을 수행해야 합니다. 다른 포그 노드도 복구 작업을 지원할 수 있으며, 이는 아키텍처가 OOB 및 IB 관리성 인터페이스를 모두 정의하는 이유입니다.

De-Commission: 포그 노드의 많은 측면은 PII(개인 식별 가능 정보)를 가질 수 있기 때문에, 아키텍처는 하드웨어의 모든 측면을 청소하는 능력을 지정합니다. 여기에는 포그 노드 인스턴스를 해제하고 다른 배포에 다시 사용할 수 있는 기능이 포함됩니다. 또한 향후 애플리케이션이 이전 테넌트의 데이터에 액세스하지 못하도록 모든 비 휘발성(NV) 스토리지를 안전하게 삭제할 수 있는 방법을 제공합니다.

5.4.3.3 Management Layer

관리 수명 주기에 표시된 것처럼 포그 관리 계층에는 엔드포인트 디바이스의 자동 검색, 등록 및 프로비저닝과 같은 많은 책임이 있습니다. Discovery 서비스는 포그 인프라 내의 구성 요소를 찾고, 식별하고, 온보딩하고, 관리할 수 있는 효율적인 방법을 제공합니다. IB 및 OOB 검색 방법이 모두 사용됩니다. IB 서비스는 일반적으로 운영 체제나 소프트웨어 에이전트를 사용하여 검색됩니다. OOB 검색은 일반적으로 저전력의 시스템 상태 동안 유지 관리가 쉬운 무선, SMBus 또는 I2C 인터페이스를 통해 수행됩니다. 검색의 목적은 엔드포인트의 리소스를 완전히 이해하고, 상태 기준을 설정하며, 요소가 해제될 때까지 올바른 작동 상태를 보장하는 것입니다.

포그 노드에서 가장 일반적으로 사용되는 관리 측면은 시스템 소프트웨어 및 펌웨어 업데이트와 비정상 시스템 작동에 대한 원격 경고입니다. 포그 기반 시스템은 종종 가혹한 환경 조건이나 원격 환경 조건에서 작동하기 때문에 "Over The Air" (OTA) 펌웨어 및 소프트웨어 업데이트를 제공해야 합니다. 관리 계층은 이러한 업데이트를 담당합니다.

5.4.4 Data, Analytics, and Control

기존의 분석 방식은 더 이상 효율적이지 않으며, 경우에 따라서는 클라우드 모델에 기존의 센서를 사용하는 것도 불가능합니다. 이는 대규모 비즈니스 애플리케이션에 의한 추가 처리 및 분석을 위해 데이터 센터 또는 클라우드로 캡처, 저장 및 전송해야 하는 대량의 데이터 때문입니다. 비즈니스 및 기술 프로세스에 대해 깊이 들여다 볼 때 정보로부터 실질적인 비즈니스 지식을 창출하려면 보다 세분화된 데이터 요소가 필요합니다. 이러한 데이터 이동은 대부분의 기업과 기관에게 진화하는 비전입니다. 어떤 이들은 모든 사항에 관심이 있을 수 있습니다. 일부 사용자는 작업의 현재 상태를 이해하고 설명적 분석(무엇이 발생했는지 또는 무슨 일이 발생했는지 분석)을 원합니다. 다른 이들은 근본 원인 분석을 수반하는 진단 분석에 관심이 있을 수 있습니다. 예측 분석에서는 이전 분석의 모든 지식을 사용하여 프로세스 및 도구에 대한 다른 지식과 결합하여 어떤 일이 발생할지 파악합니다. 결국 기업은 프로세스를 자체적으로 최적화할 수 있도록 지원하는 Prescriptive Analytics에 관심을 가질 수 있습니다.

기업이 운영에 대해 더 많이 이해할수록 필요한 데이터, 컴퓨팅 및 데이터 리소스가 늘어납니다. 안개 컴퓨팅을 통해 여러 차례 보여주었듯이, 우리는 관련 데이터만 캡처, 저장, 분석 및 전송할 수 있는 도구를 보유하고 있습니다. 이는 상위 계층 데이터 센터 또는 클라우드 애플리케이션의 인텔리전스를 데이터 소스에 최대한 가깝게 내장함으로써 가능합니다. 즉, 데이터 소스와 비즈니스 인텔리전스 분석 응용 프로그램 간의 통합을 통해 "네트워크" 또는 "에지"가 소스의 데이터를 캡처하고 로컬 용도별 분석을 위해 처리하며 프로세스에 다시 작업을 전달합니다. 동일한 또는 다른 데이터 세트를 데이터 센터 또는 클라우드로 전송하여 "비즈니스 또는 운영 관련" 추가 처리를 수행합니다. 포그 계층적 특성은 이를 통해 분석 알고리즘의 여러 구성 요소가 서로 다른 포그 계층에서 작동할 수 있습니다. 이 문제는 해결되는 시나리오에 따라 올바른 계층에서 발생해야 하기 때문에 크로스-커트 문제로 간주됩니다.

위의 그림은 비즈니스 프로세스의 모든 요소에 걸쳐 데이터 교환과 오픈 데이터 교환의 통합을 보여줍니다. 이러한 통합과 교환은 비즈니스 인텔리전스 분석의 성공과 정확성을 위해 필요합니다. OpenFog 컨소시엄은 기업 내에서, 그리고 기업과 파트너 및 공급업체 간에 이러한 유형의 커뮤니케이션을 촉진하기 위해 보안 및 ID와 관련된 다양한 솔루션을 개발하고 발전시키고 있습니다. 비즈니스 인텔리전스는 잘 정의된 흐름, 안전한 경계, 다양한 데이터 처리 요소 간의 데이터 캡처 및 교환, 그리고 이를 모두 이해할 수 있는 데이터 과학에 의존합니다.

5.4.5 IT Business and Cross-fog Applications

포그 애플리케이션 및 서비스는 포그 계층 구조에서 다양한 수준으로 확장 및 상호 운용할 수 있는 유연성을 가져야 합니다. 이것은 멀티벤더 생태계를 가능하게 하는 포그 컴퓨팅의 근본적인 측면입니다. 또한 하나의 포그 노드가 수집하거나 생성하는 데이터는 계층의 다른 노드와 공유할 수 있어야 합니다. 아래 그림은 동에서 서까지 퍼지는 크로스 포그 응용 프로그램을 보여줍니다 (North-South로 확장 할 수 있음).

크로스 포그 애플리케이션에서는 스마트 객체 및 관련 데이터 모델을 이해하고 채택해야 합니다. 이러한 애플리케이션은 상호운용성 및 부가 가치 창출에 매우 중요합니다.

5.5 Node View

앞에서 설명한 것처럼 OpenFog RA 설명은 여러 이해관계자의 관점을 종합한 것입니다. 노드 뷰는 현재 아키텍처 설명에 사용되는 가장 낮은 레벨 뷰 입니다. 뷰포인트를 형성하는 데 관여하는 이해관계자는 칩 설계자, 실리콘 제조업체, 펌웨어 설계자 및 시스템 설계자에 대한 시스템입니다.

노드를 포그 컴퓨팅 네트워크로 전환하기 전에 다음 사항을 충족해야 합니다:

Node Security (노드 보안): 앞에서 설명한 것처럼 노드 보안은 시스템의 전체 보안에 필수적입니다. 여기에는 인터페이스, 컴퓨팅 등에 대한 보호가 포함됩니다. 대부분의 경우 노드가 레거시 센서 및 액추에이터의 게이트웨이 역할을 하므로 보다 높은 수준의 포그 기능에 대한 게이트웨이 역할을 하므로 보안 게이트웨이 역할을 할 수 있다. 노드 보안은 이 보기에 대한 수평 요구 사항과 수직 뷰로 표시됩니다. 이것은 실리콘에서 소프트웨어에 이르기까지 모든 단계에서 보안을 고려해야 하기 때문에 중요한 개념입니다.

Node management (노드 관리): 노드가 관리 중인 노드에서 제공하는 관리 인터페이스를 지원해야 합니다. 관리 인터페이스를 통해 시스템 관리 에이전트가 가장 낮은 레벨의 실리콘을 보고 제어할 수 있습니다. 동일한 관리 프로토콜을 여러 물리적 인터페이스에서 사용할 수 있습니다.

Network (네트워크): 모든 포그 노드는 네트워크를 통해 통신할 수 있어야 한다. 많은 포그 애플리케이션은 시간에 민감하고 시간을 인식하기 때문에 일부 포그 컴퓨팅 네트워크는 TSN(Time Sensitive Networking)을 지원해야 할 수 있습니다.

Accelerators (가속기): 많은 포그 애플리케이션은 특정 시나리오와 관련하여 가속기를 사용하여 대기 시간과 전력 제약을 모두 충족합니다.

Compute (컴퓨팅): 노드는 범용 컴퓨팅 기능을 가져야 합니다. 표준 소프트웨어(예: 쉘프 또는 오픈 소스에서 상용)를 이 노드에서 실행할 수 있어야 합니다. 이를 통해 포그 노드 간의 상호 운용성이 향상됩니다.

Storage (저장): 자율 노드는 학습할 수 있어야 합니다. 학습이 가능하기 전에 데이터를 저장하는 기능이 있어야 합니다. 이 노드에 연결되거나 내장된 스토리지 장치는 시스템 및 시나리오의 필요한 성능, 안정성 및 데이터 무결성 요구 사항을 충족해야 합니다. 또한 저장 장치는 미디어 상태에 대한 정보와 조기 경고를 제공하고, 자가 복구 속성을 지원하며, ID 기반 성능 할당을 지원해야 합니다. 로컬 컨텍스트 데이터, 로깅, 코드 이미지 및 노드에서 실행되는 서비스 애플리케이션에는 일종의 로컬 독립형 스토리지가 필요합니다. 로컬 하드 디스크, SSD 및 키 및 기타 비밀 재료를 위한 보안 스토리지와 같은 두 가지 이상의 스토리지가 필요한 경우가 많습니다.

Sensors, Actuators, and Control (센서, 액추에이터 및 제어): 이러한 하드웨어 또는 소프트웨어 기반 기기는 IoT에서 가장 낮은 수준의 요소로 간주됩니다. 이러한 노드 중 수백 개 이상이 단일 포그 노드와 관련될 수 있다. 이러한 장치 중 일부는 상당한 처리 능력이 없는 단순한 장치이며 다른 장치는 기본적인 포그 기능이 있을 수 있다. 이러한 요소들은 일반적으로 일정량의 연결성을 가지고 있으며 I2C, GPIO, SPI, BTLE, ZigBee, USB, 이더넷 등과 같은 유선 또는 무선 프로토콜을 포함합니다.

Protocol Abstraction Layer (프로토콜 추상화 계층): 오늘날 시장에 출시된 많은 센서와 액추에이터는 포그 노드와 직접 인터페이스할 수 없습니다. 프로토콜 추상화 계층은 이러한 요소들을 분석 및 상위 수준의 시스템 및 소프트웨어 기능에 이용할 수 있도록 포그 노드의 감독하에 이러한 요소들을 논리적으로 가능하게 합니다.

추상화는 IoT 사물 및 포그 노드 모두에서 멀티벤더 상호운용성의 핵심입니다. 잘 알려진 요소 간 인터페이스는 추상화 계층을 제공합니다. 공급업체가 지원하는 포그 아키텍처 요소의 메타 데이터를 공유할 수 있도록 하여 멀티벤더 데이터 상호 운용성과 서비스 컴포지션을 촉진합니다. 메타 데이터가 노출될 경우, 예를 들어 ICN(정보 중심 네트워크)을 사용하여 포그 노드 간에 데이터를 최적으로 라우팅하거나 소프트웨어 정의 네트워크(Software-Defined Networks)와 같이 동적 포그 토폴로지를 만드는 데 사용될 수 있습니다.

OpenFog RA의 향후 버전에서는 프로토콜과 추상화 계층에 대한 더 많은 세부 사항을 포함하는 "최소 가변 인터페이스"를 설명할 것입니다. 다음의 하위섹션은 센서, 작동기, 제어장치 및 이들의 인터넷 프로토콜 추상화를 제외하고 위에서 언급한 측면에 대한 더 자세한 내용을 포함하고 있습니다. IoT 디바이스 연결 및 보안 문제에 대한 자세한 내용은 보안 부록을 참조하십시오.

5.5.1 Network

포그 노드는 일반적으로 에지에서 데이터를 수집해야 하는 시나리오와 수천 또는 수백만 개의 장치에서 나온 데이터를 분석하고 마이크로 밀리초 단위로 작동하는 시나리오에서 가장 큰 가치를 가집니다. 이러한 시나리오에서 다양한 네트워크는 포그 노드 내에서 센서를 비롯해 계층의 최고 수준까지 통신할 수 있도록 지원합니다.

네트워크는 통신 패턴이나 프로세스에 필요한 확장성, 가용성 및 유연성을 제공해야 합니다. 또한, 네트워크는 중요하거나 지연 시간에 민감한 데이터의 우선순위를 정하고 제공까지 보장하기 위해 필요한 모든 QoS를 제공해야 합니다. QoS를 보장하려면 가장 낮은 수준에서 QoS를 처리해야 합니다 (따라서 노드 뷰). 이를 통해 시스템 공급자(시스템 뷰)와 응용 프로그램(소프트웨어 뷰)의 보다 높은 수준의 뷰가 안정적인 기반을 바탕으로 구축됩니다.

다음 섹션에서는 포그 노드의 연결 및 통신 요구 사항에 대한 관점에서 다양한 네트워크 요소를 살펴보겠습니다.

Note: 배포 시나리오에 따라 액세스 지점, 게이트웨이 또는 라우터와 같은 네트워크 요소 내에 포그 노드가 존재할 가능성이 가장 높습니다. 아키텍처에서, 우리는 포그 노드의 배치에 관계 없이 네트워크 요구사항이 동일할 것이라고 가정합니다. 이는 배치에 따라 분명히 변경될 것이며 테스트베드 및 기타 개방형 구축을 통해 이를 구체화할 것 입니다.

5.5.1.1 Wired Connectivity

포그 노드의 네트워크 연결 모델은 노드의 목적과 위치에 따라 달라집니다. 예를 들면 다음과 같습니다:

  • 제조 공정 데이터를 수집하고 분석하는 데 사용되는 공장의 포그 노드는 대부분 유선 네트워크를 사용하여 상부 및 하부 레이어에 연결될 가능성이 큽니다.
  • 인사부를 수집하고 분석하는 데 사용되는 포그 노드가 무선 네트워크를 사용하여 센서에 연결될 가능성이 가장 큽니다.
  • 포그 노드 내의 내부 연결은 대부분 RDMA 및 기타 낮은 지연 시간 상호 연결 기술을 사용하여 연결될 수 있습니다.

포그 노드를 연결하는 데 사용할 수 있는 물리적 연결을 위한 많은 표준, 유형 및 인터페이스가 있습니다. 물리적 연결은 일반적으로 10Mbps에서 100Gbps 사이의 속도를 지원하는 하나 이상의 이더넷 링크이며, 다양한 도달 요구 사항을 충족하기 위해 구리선 또는 광섬유 링크에서 지원됩니다. 일반적으로 최대 100m 길이의 링크에 사용되는 구리 연결과 10Mbps에서 1Gbps까지의 지원 속도를 볼 수 있습니다.

더 빠른 속도와 더 긴 도달 거리가 필요한 연결의 경우, 광섬유 케이블을 사용할 수 있습니다. 광섬유는 다양한 파장과 전송 모드를 지원하여 필요한 거리와 용량을 지원합니다. 예를 들어 단일 모드 광섬유 케이블(단일 광선 사용)은 멀티모드 광섬유(다중 광선 및 다중 파장 사용)보다 더 먼 거리를 지원합니다.

포그 노드를 IoT 장치 또는 센서에 연결하기 위해 수직 또는 솔루션 의존적인(비 이더넷 프로토콜) 다양한 표준과 인터페이스가 있습니다. 예를 들어, 산업 환경에서는 포그 노드가 하위 계층 애플리케이션 및 프로세스와 통신하기 위한 CAN 버스 또는 기타 필드버스 표준을 지원해야 할 수 있습니다.

산업 자동화 사용의 경우 보장된 데이터 전송이 매우 중요합니다. 이러한 유형의 네트워킹(일반적으로 이더넷 사용)을 TSN(Time Sensitive Networking)이라고도 합니다. TSN은 표준 이더넷 환경에서 제어 트래픽의 우선 순위를 정하기 위해 표준 기반 시간 동기화 기술(예: IEEE 1588)과 대역폭 예약(클래스 기반 QoS)을 사용합니다.

Ethernet을 통한 산업 자동화, 자동차 또는 로봇 환경의 장치와 인터페이스하기 위해 포그 노드가 필요한 경우 TSN 지원이 필요할 수 있습니다.

5.5.1.2 Wireless Connectivity

무선 연결은 특히 사물 인터넷(Internet of Things)과 일반적으로 디지털 전환의 필수적인 부분입니다. 무선 연결은 유연성을 제공하고 효율성과 생산성을 향상시킵니다. 무선 인터페이스는 다양한 프로토콜, 표준 및 메커니즘으로 제공됩니다. 연결의 품질은 유연성, 이동성, 도달 범위, 가용성, 전력 제약 및 환경 또는 지리적 조건을 비롯한 여러 조건에 따라 달라집니다. 포그 컴퓨팅을 위해 계획된 다양한 IoT 애플리케이션의 경우, 무선 연결은 southbound 통신(센서 대 포그 노드)에 특히 유용하지만 fog node-to-fog node와 fog-to-cloud 에도 사용될 것입니다.

포그 노드에서 무선 지원은 다음과 같은 다양한 매개 변수에 따라 달라집니다.

  • 계층에서 기능 및 위치.
  • 이동성은 차량 포그 노드와 지리적으로 분산된 IoT 끝점을 지원하는 데 필수적인 자산입니다. 무선 인터페이스는 그것들을 연결하는 유일한 실용적인 방법입니다.
  • 배치 요구 사항을 만족시키는 데 필요한 범위.
  • 데이터 볼륨 (처리량) 및 속도 (데이터 전송 속도).
  • 다양한 유형의 안테나, 모듈 또는 송수신기를 지원하는 데 필요한 폼 팩터.
  • 포그 노드가 높은 속도로 계층의 다른 계층으로 업스트림하여 정보를 수신, 처리 및 릴레이할 것으로 예상되는 경우 에너지 소스(효율, 전달 및 소멸 고려 포함)는 중요한 설계 요소가 됩니다. 마찬가지로, 전송 및 처리 속도가 더 낮으면 배터리, 수확된 에너지 및 충전 가능 소스를 설계 매개변수를 이행하는 데 사용할 수 있습니다.
  • 무선 지원은 환경, 즉 간섭에 따라 크게 달라집니다. 예를 들어, 소음이 심한 환경이나 반사율이 높은 금속 표면 주변에 무선 기술을 배치하면 안개 노드에 필요한 성능에 영향을 미칠 수 있습니다. 이는 물리적 인프라 인증을 위해 포그 노드의 구조적 무결성이 안테나 부착물/케이블 부착물에 의해 손상되지 않도록 하는 해양 및 기타 영역에도 해당됩니다. 이러한 시나리오에서, 안전하고 신뢰할 수 있는 무선 통신은 필수적입니다.
  • 대부분의 경우 무면허 주파수를 사용하는 것은 비용이 낮거나 전혀 들지 않을 수 있는 반면, 면허 주파수를 사용하려면 일반적으로 주파수 범위에 액세스하기 위한 비용이 필요합니다.

무선 연결은 무선 WAN(WWWAN), 무선 LAN(WLAN) 및 무선 개인 영역 네트워크(WPAN)의 세 가지 주요 영역으로 분류될 수 있습니다.

Note: 무선 광역 통신망(WMAN)이라고 하는 통신 기술도 있습니다. 이러한 논의를 위해, 그리고 WWAN과 WMAN의 사용 사례의 상호 교환 가능한 특성 때문에, 우리는 WWAN을 양쪽의 상위 집합으로 사용합니다. Wireless WAN (WWAN): WWAN 기술은 대규모 지리적 구역 커버리지가 필요할 때 사용됩니다. 다양한 프로토콜과 표준이 있으며 동일한 네트워크 내의 다른 장치 또는 노드와의 통신을 지원하기 위해 포그 노드가 필요할 수 있는 다음 표준을 열거하고 있습니다:

  • 3G, 4G LTE, 5G 등 셀룰러 기술은 높은 데이터 전송 속도(1Gbps 이상)를 자랑합니다. 또한 더 많은(면허된 주파수로서) 비용이 들고 전력 효율성이 떨어집니다. 대부분의 이동통신은 제3세대 파트너십 프로젝트(3GPP)를 통해 표준화됩니다.
    • Note: 5G는 현재 셀룰러 시스템보다 더 빠른 속도, 더 높은 용량 및 훨씬 낮은 대기 시간을 보장합니다. 5G를 사용하면 두 자리 Gbps 속도(10+Gbps)를 제공할 수 있습니다. 5G는 사물인터넷(IoT) 솔루션 및 기기 채택률을 높일 것을 약속합니다. 자동차, 모바일 기기, 센서로부터 데이터를 집계하는 포그 노드는 5G를 지원해야 할 가능성이 높습니다.
  • 포그 노드는 southbound 트래픽이나 northbound 트래픽에 대한 셀룰러 기술을 지원하기 위해 필요할 수 있습니다. 포그 노드는 셀룰러 기술을 사용하여 센서 트래픽을 차단할 수 있습니다. 대부분의 유형의 모바일 포그 노드는 셀룰러 northbound 인터페이스를 사용합니다. 포그 노드에 물리적으로 연결되는 많은 소프트웨어 정의 무선 기술은 이러한 시나리오 요구 사항 중 일부를 해결합니다.
  • NB-IoT(Nortrow Band IoT)는 다양한 IoT 애플리케이션 및 요구사항을 충족하고 장기 및 저전력 요구사항을 약속하는 3GPP 표준입니다. NB-IoT는 아직 널리 보급되지 않았습니다.
  • 저전력 광역 통신망(LPWAN)은 데이터 전송률이 낮고 전력 효율성이 높으며 비용이 저렴합니다. 독점 LPWAN 구현은 LoRa Alliance 및 Sigfox와 같은 다양한 조직에서 테스트하고 있습니다. LPWAN은 현재 농경지 및 농촌 지역의 넓은 지역을 커버할 수 있는 능력 때문에 농업 분야에 대한 조사를 받고 있습니다.

Wireless LAN (WLAN): WLAN은 다양한 토폴로지 및 프로토콜을 활용하지만 WLAN은 WiFi와 동의어가 되었습니다. WLAN은 종종 건물이나 캠퍼스 내에서 더 작은 지리적 영역에 적합한 커뮤니케이션 선택입니다. 접근 지점의 수와 밀도 요건에 따라 WLAN은 경기장, 제조 공장, 정유 및 가스 정제소 및 현장에서 사용될 수도 있습니다. 다음은 포그 노드가 지원할 수 있는 WLAN의 몇 가지 예입니다:

  • WiFi(WLAN)는 IEEE 802.11 표준 그룹에 의해 정의됩니다. 이러한 표준은 구현된 환경에 대한 다양한 요구사항과 과제를 해결합니다. 몇 Mbps에서 여러 Gbps까지의 데이터 전송 속도를 지원합니다. 가장 일반적인 표준은 IEEE 802.11a, b, g, n 및 ac입니다. IEEE802.11ac은 IEEE 802.11 표준 시리즈 중 가장 최신의 것으로, 높은 밀도와 전송 속도를 지원합니다.
  • IEEE 802.11 작업 그룹은 특히 IoT 사용 사례에 대해 더 높은 용량, 밀도 및 속도에 대한 요구를 해결하기 위해 새로운 솔루션을 개발 중입니다. 예를 들어 IEEE 802.11ax는 802.11ac의 기능을 넘어서는 속도와 용량을 제공할 것으로 예상됩니다. 802.11ah는 낮은 전력 소비와 더 긴 범위가 필요한 IoT 사용 사례에 맞게 설계되었습니다. IEEE 802.11p는 차량 대 차량 인프라 통신 및 차량 대 로드 측 인프라 통신에 대한 표준을 정의합니다.
  • Li-Fi 같은 free space 광통신의 향후 개발은 포그 무선 네트워킹의 선택으로 유망합니다.

Wireless Personal Area Networks (WPAN): WPAN은 짧은 통신 범위, 낮은 전력 소비 및 낮은 비용으로 특징지어집니다. WPAN은 웨어러블 기기 및 홈 관리 시스템과 함께 사용할 수 있습니다. WPAN에는 다음과 같은 기술이 포함되어 있습니다:

  • Bluetooth : 근거리 통신으로 특징 지어 짐. 블루투스 SIG (Special Interest Group)에서 관리하는 사양 및 표준.
  • 적외선 (IR) : IR 광파를 통해 가시 광선 무선 통신으로 특징 지어 짐. IrDA (Infrared Data Association)에서 제공하는 사양.
  • 지그비 (ZigBee) : 저전력 소모, 단거리 (최대 100m, 적절한 환경 조건 제공) 및 낮은 데이터 전송 속도로 특징 지어 짐.
  • Z-Wave : 홈 오토메이션에서 주로 사용되는 RF 신호 및 제어로 특성화됩니다.
  • IEEE 802.15.4 (저속 WPAN)는 WLAN 사용 사례에도 적용됩니다. 또한 OSI 모델의 레이어 1과 레이어 2를 정의하는 표준이기도합니다.

Near Field Communication (NFC): NFC는 포그 노드가 매우 가까운 거리에서 통신해야하는 장치를 지원할 때 사용할 수있는 기술입니다. NFC 기술은 상당 기간 물류 및 공급망 솔루션에 사용되었습니다. 현재 소매, 농업 및 의료 분야의 마찰없는 솔루션을 포함 수직 시장에서 사용되고 있습니다. NFC를 활용하는 Passive RFID와 같은 솔루션은 자산 추적 및 물리적 액세스에 사용됩니다.

포그 노드에 대한 무선 연결을 통해 다양한 센서와 데이터가 처리될 노드로 유입될 수 있습니다. 노드 기능이 증가함에 따라, 아키텍처에서 보다 높은 수준의 보안 통신 기능을 활용할 수 있습니다.

5.5.1.3 Network Management

센서와 데이터 소스의 수가 증가함에 따라 모든 자산, 노드 및 리소스를 관리해야 하는 필요성이 커지고 있습니다. OOB(Out-of-Band) 네트워크 관리를 통해 지원되는 포그 노드 기능은 포그 노드의 리소스, 보안, 상태 및 환경의 변화하는 환경에 적응하는 기능을 관리하는 데 도움이 됩니다. 센서, 노드 및 네트워크 장치를 관리하는 데 사용할 수 있는 프로토콜과 메커니즘은 사용되는 통신 프로토콜과 연결 옵션 및 CPU/메모리 리소스의 가용성에 따라 달라집니다. 경우에 따라 별도의 관리 네트워크도 있습니다. 다른 경우에는 호스트 네트워크에서 관리 통신이 전송됩니다. 노드에는 여러 가지 방법으로 정보를 제공하고 지속적인 보안, 신뢰성 및 안전 작동을 보장하려면 이러한 항목과 관련 네트워크를 정교함과 단순성으로 모두 관리할 수 있어야 합니다.

5.5.1.4 Network Based Security Threats and Mitigation

포그 노드는 다음과 같은 다양한 네트워크 기반 보안 위협으로부터 보호해야 합니다.

  • Denial of Service attacks
  • Intrusion
  • DNS spoofing
  • ARP spoofing or poisoning
  • Buffer overflows

포그 노드는 이러한 유형의 공격으로부터 항상 보호 할 수 있는 것은 아닙니다. 그들은 네트워크나 주변 장치를 보호할 가능성이 높습니다. 포그 노드를 보호하는 데 도움이되는 네트워크 장치의 일반적인 예는 다음과 같습니다.

  • Firewalls for blocking unauthorized access.
  • Intrusion Prevention Systems (IPS).
  • Secure Remote Access using Virtual Private Networks.
  • Behavior-based anomaly detection appliances or software.

네트워크에 연결된 IoT 장치를 사용하는 대규모 DoS 공격의 여러 인스턴스가 포그 기반 네트워크 보안을 사용하여 훨씬 빠르게 탐지되고 잠재적으로 완화 될 수있었습니다.

OpenFog 아키텍처의 네트워크 및 데이터 보안 측면에 대한 자세한 내용은 10.1.3.1 절을 참조하십시오.

5.5.1.5 Network Design Considerations for Fog Nodes

포그 노드를 기존 브라운필드 또는 새 그린필드 네트워크 환경에 설치하는 경우 다음과 같은 설계 고려 사항을 고려해야 합니다:

  • 포그 노드 기능의 물리적 또는 가상 구현은 용량 및 정책 요구에 따라 다릅니다. 예를 들어 물리적 인프라의 소유권은 인프라 내에서 지원되는 가상 요소에 대한 액세스를 결정하는 요소가 될 수 있습니다.
  • 포그 노드-노드 통신 고려 사항:
    • Direct or indirect
    • 에너지 사용, 대역폭, 케이블 복잡성 및 비용에 영향을 미치는 임의의 두 노드 간 거리
    • 두 노드 간의 상태 보존 요구 사항 (백업 또는 고 가용성 시나리오에서)
    • 통신 인터페이스 및 프로토콜 유형
  • Capacity planning:
    • 시나리오를 위해 설계 할 때 종료 상태를 염두에 두십시오.
    • 새 트래픽 패턴이 포그 노드 및 네트워크에 미치는 영향 이해합니다.
  • 스트리밍 데이터 준비 :    * 예상 데이터 볼륨
  • 유지 보수 및 업그레이드 빈도
  • IT와의 컨버전스 : 노드 간 통신을 위해 이더넷과 IP를 선택하면 IT 환경과 쉽게 통합되고 시스템의 효율성에 기여할 수 있습니다.

5.5.2 Accelerators

기존 CPU 외에도 일부 포그 노드, 특히 향상된 분석 노드에는 표준 현재 서버 및 엔터프라이즈 CPU 칩이 제공하는 경제적(전력 또는 처리 효율성)을 초과하는 CPU 처리량이 필요합니다. 이 경우 프로세서 모듈 옆에 가속기 모듈이 구성되어 추가 컴퓨팅 처리량을 제공합니다. 다음은 몇 가지 예입니다:

  • 그래픽 처리 장치 (GPU)에는 수천 개의 간단한 코어가 포함되어 있습니다. 대용량 병렬 처리를 효율적으로 활용할 수있는 애플리케이션의 경우 크기가 훨씬 빠르고 전력 및 공간을 크게 절약 할 수 있습니다. 각 표준 CPU에는 여러 GPU를 장착 할 수 있습니다. 그러나이 기능을 구현하려면 전력 공급 및 노드에 대한 물리적 및 전기적 연결을 증가시켜 전체 노드 전력 소비를 증가시킬 필요가 있습니다.
  • FPGA (Field Programmable Gate Arrays)는 게이트 수준의 프로그래밍 가능한 하드웨어 리소스 모음입니다. 매우 특수한 문제를 매우 효율적으로 해결하기 위해 사용자 정의 논리 설계로 구성 할 수 있습니다. 그러나 배치에 따라 다른 가속기와 비교하여 전력을 추가로 낮추려면 추가로 낮은 수준의 지식 (예 : VHDL)이 필요할 수 있습니다. 많은 경우 FPGA는 개별 GPU에 비해 전력 효율성이 뛰어납니다.
  • DSP는 신호에서 작동하도록 최적화 된 특수 프로세서입니다. 일부 DSP는 일반적인 목적이지만 비디오 압축 및 조작과 같은 특수 기능을 위해 최적화 된 DSP도 있습니다.

특정 노드에 대해 가속기를 선택할 때 다음 사항의 균형을 유지해야 합니다:

  • 노드와의 인터페이스 (전기 처리량 및 전력 공급).
  • 다중 시나리오에 대한 일반적인 적용 가능성. 이는 새로운 사용 사례를 해결하기 위해 가속기를 변경하는 동적 능력(프로그래머빌리티 필러)을 의미합니다.
  • 동적으로 변화하는 요구 사항.
  • 환경적 제약.
  • 상위 레벨의 소프트웨어 프로그래밍 인터페이스 및 API 지원, 특히 가속기의 존재와 기능을 검색하는 데 필요한 오케스트레이션

프로그래밍 가능 필러는 주어진 문제를 해결하기 위해 정의된 방법에 있어 노드의 유연성을 의미합니다. 이 늦은 결합은 OpenFog 컨소시엄에 대한 관심 분야 중 많은 부분에서 특히 중요합니다.

5.5.3 Compute

점점 더 많은 데이터가 에지에서 처리됨에 따라, 네트워크의 실제 에지에서 컴퓨팅 요구사항이 증가할 것입니다. 에지에 일반적인 용도의 컴퓨팅이 계속 중요할 것입니다. 또한 이 컴퓨팅과 결합된 시스템 DRAM의 양이 더 많아질 것입니다. 컴퓨팅의 신뢰성과 정확성을 높이기 위해 ECC 메모리가 컴퓨팅에서 더욱 두드러지기 시작합니다. 포그 컴퓨팅의 또 다른 중요성은 배포 수명 주기가 더 길어질 수 있기 때문에 배포 수명주기 전체에 걸쳐 긴 수명과 컴퓨팅 성능이 충분하도록 계산되어야 한다는 것입니다. 컴퓨팅은 하나 이상의 멀티 코어 CPU로 구현될 가능성이 높습니다. 다른 아키텍처들이 존재하지만, 다른 아키텍처들을 고려할 때 프로그래밍 가능성의 균형을 맞추는 것이 중요합니다.

컴퓨팅 요소를 고려할 때 올바르게 작동해야하는 환경 조건을 이해하는 것이 중요합니다. 많은 포그 배치에서 컴퓨팅은 70도를 훨씬 넘어서서 계속 작동해야합니다. 사실, 100도까지의 가장 가혹한 환경은 전 세계적으로 흔하지 않습니다.

컴퓨팅 기능은 포그 노드에 대한 많은 요구 사항을 구체화합니다. 다음은 컴퓨팅 요구 사항의 몇 가지 예입니다:

  • 일부 멀티 테넌트 (multi-tenant) 설치는 전체 코어를 가장 중요한 각 응용 프로그램에 할당합니다. QoS를 보장하려면 이 기능이 필요할 수 있습니다.
  • 대규모 가상 메모리 공간을 관리하고, 멀티 테넌트(Multi-tenant) 환경에서 플랫폼을 애플리케이션 공간에서 격리하며, 애플리케이션을 서로 분리하기 위해 포그 메모리 관리 장치가 필요할 수 있습니다.
  • 각 CPU를 관련 가속기, 스토리지 및 네트워크 주변 장치와 연결하려면 포그에 고성능 I/O 하위 시스템이 필요합니다.
  • 일부 포그 노드 설계에서는 신뢰의 하드웨어 루트가 CPU 복합체 내에 위치하며, 코드 검증은 CPU가 서명을 확인한 후에만 수행됩니다.

5.5.4 Storage

포그 노드에는 많은 유형의 스토리지가 필요합니다. 포그 컴퓨팅이 계속해서 등장함에 따라 데이터 센터에서 일반적으로 볼 수 있는 스토리지 계층이 계층 전체에서 데이터를 수집하고 처리할 때 노드에서만 나타나는 스토리지 계층이 나타납니다. 여기에는 다음이 포함됩니다:

  • RAM Arrays: 데이터 센서로부터 만들어지는 노드는 해당 데이터에 가까운 실시간 동작에 작동할 필요가 있을 것입니다. RAM 어레이는 비휘발성 저장소에 액세스할 때 추가 대기 시간 대비 이러한 요구사항을 충족합니다. 또한 많은 포그 노드에는 특정 시나리오에 필요한 지연 시간 측면을 충족하기 위한 패키지 내 메모리도 있습니다.

  • Solid State Drive: 플래시 기반 스토리지는 안정성, IOP, 저전력 요구 사항 및 환경 견고성으로 인해 대부분의 포그 어플리케이션에 사용될 수 있습니다. 여기에는 PCIe 및 SATA 부착 SSD가 포함됩니다. 또한 새로운 프로그래밍 모델로 새로운 종류의 솔리드 스테이트 미디어가 등장하기 시작했습니다. 여기에는 3DXpoint 및 NVDIMM-P가 포함됩니다.

  • Fixed Spinning Disks: 비용이 많이 드는 대용량 스토리지 어플리케이션의 경우 포그 노드에 회전식 디스크가 포함될 수 있으며 때로 RAID 어레이의 중복 배열로 배열됩니다.

실제 선택한 저장 매체는 유즈케이스에 따라 달라집니다. 주어진 포그 노드 내에는 일반적으로 스토리지 옵션의 계층이 있습니다. 궁극적으로 스토리지 장치는 시스템의 비용, 성능(IOPS, 대역폭 및 지연 시간), 안정성 및 데이터 무결성 요구사항을 충족해야 합니다. 또한 포그 컴퓨팅의 스토리지 장치는 OpenFog 필러, 특히 보안 및 RAS 필러를 지원해야 합니다. 그러나 플래시 기반 스토리지 기술이 D램의 비용/바이트 및 액세스 대기 시간으로 계속 발전함에 따라 가장 큰 발전이 있을 것입니다.

저장 장치는 AES-256 및 TCG Opal 등과 같은 표준을 지원하여 암호화 및 키 관리 및 인증을 지원해야 합니다. 저장 장치는 미디어의 상태에 대한 실시간 정보와 조기 경고를 제공하고 자체 치유 속성을 지원해야합니다 . 마지막으로 가상화 된 포그 컴퓨팅 환경에서 저장 장치는 특정 응용 프로그램이나 가상 컴퓨터에 조정 가능한 저장소 리소스 (IOPS 또는 대역폭)를 제공하여 ID 기반 성능 할당을 지원해야합니다. 데이터 센터에서 볼 수 있는 물리적 보호 메커니즘이 더 이상 존재하지 않는 영역에 배치되기 때문에 대부분의 포그 배포에서도 데이터 암호화를 지원하는 것이 중요합니다.

5.5.5 OpenFog Node Management

OpenFog 노드 관리는 호스트 운영 체제에서 실행되고 있지 않은 관리 시스템을 의미합니다. 이러한 관리 시스템은 일반적으로 모든 전원 상태에서 포그 노드를 지속하고 관리할 수 있는 개별 관리 시스템입니다. 또한 하드웨어 플랫폼 관리 장치(HPM)라고도 합니다.

대부분의 포그 노드에는 노드 내부의 다른 구성 요소(예: 저장, 가속기 등)를 제어하고 모니터링하는 HPM이 포함됩니다. HPM은 일반적으로 메인 CPU 또는 마더보드에 있는 작은 보조 프로세서입니다. 온도·전압·전류·다양한 오류 등 변수를 추적하는 센서·모니터링 포인트가 다양게 있습니다. 이러한 수치는 외부 RAS 시스템에 주기적으로 보고할 수 있습니다. 심각한 오류가 감지되면 HPM 하위 시스템에서 경보 알림을 에스컬레이션할 수 있습니다.

HPM 시스템은 또한 포그 노드의 내부 구성을 제어하는 역할을 합니다. IP 주소 및 라인 속도와 같은 통신 매개변수를 설정할 수 있습니다. 새 하드웨어 모듈을 구성할 수 있습니다. 모듈이 고장 나면 모듈을 격리하고 기능을 복구할 수 있습니다. 또한 HPM 하위 시스템은 신뢰 체인의 신뢰할 수 있는 구성 요소와 협력하여 전체 노드에 대한 소프트웨어 업데이트를 안전하게 다운로드합니다. 주변 온도, 공기 흐름, 팬 속도(사용되는 경우), 공급 전압, 공급 전류, 습기, 캐비닛 도어 변조 등을 포함한 포그 노드 하드웨어의 물리적 작동과 관련된 센서도 HPM 하위 시스템을 통해 데이터를 전송합니다.

많은 배치에서 HPM은 주요 컴퓨테이션 요소와의 대역 외에서도 작동할 수 있기 때문에 자체 TPM을 갖추고 보안 부팅 프로세스를 거치게 됩니다. 다른 엔티티와 마찬가지로 HPM도 신뢰 HW 루트를 지원해야 합니다.

5.5.6 OpenFog Node Security

보안 관점에 설명된 바와 같이, 포그 노드의 필요성을 적절히 식별하기 위해 포그 구현의 보안 분석 및 위협 평가를 수행하는 것이 중요합니다. 이 작업이 완료되면 적절한 물리적 보안 조치, 신뢰 구축 및 유지 관리를 위한 최적의 방법, 그리고 포그 노드가 환경을 안전하게 관리하고 응답할 수 있도록 적용할 정책 유형을 결정하는 데 필요한 정보가 있어야 합니다.

5.5.6.1 Physical Security and Anti-tamper Mechanisms

포그 노드가 지원하는 물리적 보안 수준은 해당 장치의 보안 정책 및 위협 수준에 맞춰야 합니다. 이는 시스템 구성 요소에 액세스하는 것이 얼마나 어려운지와 시스템이 위반될 경우 어떤 결과가 초래되는지에 따라 달라집니다. 포그 노드의 위치와 해당 위치에서 사용할 수 있는 물리적 접근의 정도는 평가에 영향을 미칩니다. 쇼핑몰, 거리 코너, 전신주, 심지어 개인 차량에서도 개방된 공공장소에 위치한 포그 노드는 물리적 공격에 더 큰 기회를 제공할 것입니다. 참고: 이러한 기기에 물리적 보안을 제공하기 위한 산업별 표준 및 요구사항이 있을 수 있습니다. 이것들은 여기서 다루지 않습니다.

도난 방지 메커니즘의 목적은 공격자가 장치에 대해 승인되지 않은 물리적 또는 전자적 공격을 수행하지 못하도록 하는 것입니다. 안티 트랩 메커니즘은 다음 네 가지 그룹으로 나눌 수 있습니다.

  • Resistance
  • Evidence
  • Detection
  • Response

적절한 유지보수 조치가 안티 트랩 메커니즘으로 인해 노드를 손상시키지 않아야 합니다. 이 문제를 방지하기 위해 노드에 특수 유지 보수 모드가 설정되어 있을 수 있습니다. 이 모드는 유지 보수가 진행 중인 동안 무단 변경 응답을 비활성화한 다음 다시 사용하도록 허가된 엔티티가 구성할 수 있습니다.

5.5.6.2 Tamper Resistance

부정 조작 방지 기능은 특수한 물리적 구조 재료를 사용하여 포그 노드를 조작하는 것을 어렵게 만듭니다. 여기에는 인클로저, 잠금 장치, 캡슐화 또는 보안 나사와 같은 기능이 포함될 수 있습니다. 단단한 airflow 채널을 구현하면 (즉, 인클로저 내에 구성 요소와 회로 보드를 단단히 패킹 함) 엔클로저를 열지 않고도 노드 내부를 조사하기 위해 광섬유를 사용하는 것이 어려워집니다. 노드 뷰를 보면 SoC 제조업체가 활성화한 모든 인터페이스가 포함됩니다. 많은 제조업체들이 제조 모드 또는 테스트 모드라고 불리는 특수 작동 모드를 사용합니다. 이러한 작동 모드는 노드가 배포된 후 물리적 공격으로부터 변조되지 않도록 보호해야 합니다.

5.5.6.3 Tamper Evidence

변조 증거의 목표는 변조가 발생하면 가시적 증거가 남겨 지도록하는 것입니다. 탬퍼 증거 메커니즘은 최소한의 위험을 감수하는 사람 (예 : 결정되지 않은 공격자)에게는 주요 저지 요인입니다. 물리적 탬퍼링이있을 때 명확한 특수 씰 및 테이프와 같은 많은 종류의 탬퍼 증거 자료와 장치를 사용할 수 있습니다. 이전 예에서, 변조는 HPM에 통지하여 더 높은 수준의 관리 엔티티가 물리적으로 존재하지 않고 위조를 판단할 수 있도록 합니다.

5.5.6.4 Tamper Detection

Tamper 탐지란 시스템이 원치 않는 물리적 접근을 인식함을 의미합니다. 침입을 탐지하는 데 사용되는 메커니즘은 일반적으로 세 가지 그룹 중 하나로 분류됩니다.

  • Switches: 마그네틱 스위치, 수은 스위치 및 압력 접촉 장치와 같은 장치는 장치의 개방, 물리적 보안 경계의 침해 또는 특정 구성 요소의 이동을 감지합니다.

  • Sensors: 온도 및 방사선 센서와 같은 센서는 환경 변화를 감지합니다. 전압 및 전력 센서는 글리치 공격을 감지 할 수 있습니다. 이온빔은 집적 회로 내의 특정 전기 게이트에 집중하기 위해 고급 공격에 사용될 수 있습니다.

  • Circuitry: 니크롬 와이어 및 보드상의 특정 회로 또는 특정 회로를 감싸는 광섬유와 같은 회로는 래퍼의 펑크, 파손 또는 변경 시도를 감지하는 데 사용됩니다. 예를 들어, 니크롬 와이어의 저항이 변경되거나 광 케이블을 통해 이동하는 광 출력이 감소하면 시스템은 물리적 조작이 있다고 가정합니다.

  • Mesh enclosures: Gore의 Tamper Responsive Surface Enclosure는 포그 노드의 물리적 보안 경계를 보호하고 다양한 변조 증거 및 탐지 기능을 결합하도록 설계되었습니다.

이러한 모든 변조 감지 메커니즘은 일반적으로 하드웨어 보안 위반 신호가 트립될 때 보안 모니터에 신호를 제공합니다.

5.5.6.5 Tamper Response

조작 대응 메커니즘은 조작이 감지 될 때 취한 대책입니다. 이러한 이벤트에 대한 응답을 구성할 수 있어야 합니다.

  • Soft Fail: 민감한 데이터가 삭제되고 두 번째 인터럽트 신호가 보안 모니터로 전송되어 프로세서를 다시 시작하고 실행을 계속할 수 있도록 완료되었는지 확인합니다.

  • Hard Fail: Soft Fail을 위한 동작이 수행되고 캐시와 메모리가 제로화되고 시스템이 재설정됩니다. 더 낮은 결과와 더 높은 결과가 모두 가능할 수 있습니다. 가장 낮은 결과는 아무 것도하지 않거나 나중에 분석을 위해 이벤트를 기록 할 수 있습니다. 더 높은 결과의 예는 장치를 "bricking" 것일 수 있습니다. 즉, 모든 중요한 데이터, 캐시 및 메모리를 0으로 설정 한 후에는 노드를 다시 부팅 할 수 없으므로 교체해야 합니다.

조작에 대한 대응은 포그 구조의 상위 레벨에 의해 이해되고 계획되어야 합니다. 이러한 의존성은 시스템 구축에서 간과되는 경우가 많으며, 일반적으로 공격의 대상으로 사용됩니다. 따라서 노드 응답은 시스템 및 노드에서 실행되는 소프트웨어에 의해 이해되어야 합니다.

5.5.6.6 Establishing and Maintaining Trust
5.5.6.6.1 Trusted Computing Base

TCB (Trusted Computing Base)는 침입 시스템의 보안 정책 시행 능력을 손상시키는 플랫폼 하드웨어, 소프트웨어 및 네트워킹 구성 요소를 말합니다. TCB에 있는 구성 요소와 코드가 많을수록 버그와 보안 취약점이 없음을 보증하는 것이 더 어려워집니다. 공격 표면을 최소화하기 위해 TCB가 가능한 한 작아야 한다는 것이 바람직합니다. 그러나 때로는 특정 유스케이스를 충족시키는 데 필요한 시스템의 복잡성으로 인해 이를 달성 할 수 없습니다. 시스템의 나머지 부분으로부터 격리되고 보호된 여러 영역을 생성하는 것은 복잡한 시스템 환경 내에서 공격 표면을 줄이기 위해 더 작은 TCB를 생성하는 한 가지 방법입니다.

5.5.6.7 Hardware Root-of-Trust

TCB의 중심에 포그 노드의 보안이 신뢰의 근원입니다. 악의적 행위자가 조기 초기화 또는 부팅 프로세스를 하이 재킹할 수 있는 기회가 없어야 합니다. 보안은 회피 될 수 없도록 하드웨어에 고정되어야 합니다. 하드웨어 루트 (HW-RoT)는 포그 노드의 TCB에 대한 핵심 요소입니다.

5.5.6.7.1 Secure or Verified Boot (HW-RoT for Verification)

최소한, 포그 노드는 부팅 프로세스의 확인을 위해 HW-RoT를 지원해야 합니다. 보안 또는 확인된 부팅은 서명된 펌웨어 이미지, 부팅 로더, 커널 및 모듈을 로드하고 확인하기 위한 아키텍처입니다. TPM이있는 경우에도 TPM을 반드시 사용해야 하는 것은 아니라는 점에 유의해야 합니다.

확인 된 부팅에는 많은 구현이 있습니다. 프로세스는 불변의 ROM (Read Only Memory)에서 로드 된 코드로 실행을 시작합니다. 포그 노드의 컴퓨팅 엔티티는 암호로 서명된 이미지에서만 작동 할 수 있습니다. 보안 부트 구현은 본질적으로 독점적 일 수 있습니다. 시스템 설계자는 검증 된 부팅 구현의 보안 기능을 검증하고 기능을 검증 할 것을 권장합니다. 서명 방법을 우회 할 수있는 메커니즘이 없어야 합니다. 또한 HW-RoT가 검증되지 않은 코드를 실행하지 않는 것이 중요합니다. 여기에는 PCIe 장치의 옵션 ROM과 노드보기를 구성하는 기타 요소가 포함됩니다.

5.5.6.7.2 Trusted or Measured Boot (HW-RoT for Measurement)

신뢰할 수 있는 부팅은 더 높은 수준의 소프트웨어가 실행 중인 펌웨어가 안전한지 (프로그래밍으로 확인) 증명할 수 있기 때문에 보안 부팅과 다릅니다. TCG가 설명한 한 가지 예는 TPM을 사용하여 이 기능을 수행하는 방법을 정의합니다. 코드가 실행되면 TPM에 저장된 코드 모듈의 암호화 다이제스트를 생성합니다. 이러한 각 체인의 저장 공간에 사용되는 TPM 용어는 PCR(Platform Configuration Register)입니다. PCR은 특정 목적에 사용되는 단일 신뢰 체인으로 간주될 수 있습니다. 이는 많은 가능한 구현의 한 가지 예입니다. 다른 구현들은 여전히 존재하는 반면 다른 구현들은 미래 혁신에 의해 설명될 수 있습니다. 검증된 부팅의 경우 시스템 설계자는 기능을 검증하고 측정된 부팅 구현의 보안 강점을 검증하는 것이 좋습니다.

5.5.6.7.3 Securing the Boot Process

포그 노드에는 신뢰 루트를 안전하게 설정하는 방법이 있어야 하며, 해당 신뢰는 노드를 신뢰할 수 있도록 부팅 프로세스의 나머지 부분까지 인증 및 확장되어야 합니다.

포그 노드는 구성 요소가 실행되기 전에 펌웨어 및 시스템 소프트웨어가 변경되지 않았는지 확인하는 방법을 제공해야합니다. 이것이 달성 될 수 있는 다양한 방법이 있습니다. 이 요구 사항에 대해 선택되고 구현 된 솔루션은 보안 분석 및 위협 평가 중 조직의 결과와 일치해야 합니다.

5.5.6.7.4 Identification

포그 노드는 네트워크 내의 다른 엔티티에 대해 자신을 식별할 수 있어야 하며, 포그 노드로부터 서비스를 요청하는 엔티티는 포그 노드까지 자신을 식별할 수 있어야 합니다. 이 식별을 위한 가장 좋은 방법은 증명과 함께 불변성 식별자를 갖는 것입니다. 증명이란 원격 제3자 검증자에게 위조할 수 없는 일부 증거를 제공하는 시스템의 기능입니다. 포그 시스템이 프라이버시를 보존하는 동안 특정 시스템의 자격 증명을 검증하거나 입증할 수 있는 그러한 방법 중 하나는 DAA(Direct Anonymous Proxygence) 구현의 사용입니다.

5.5.6.7.5 Attestation

신뢰할 수 있는 프로세서를 사용하는 시스템의 보안은 증명(종종 원격 증명 또는 소프트웨어 증명)에 따라 달라집니다. 포그 컴퓨팅 계층에서 원격 증명 에이전트는 포그 시스템의 안정성과 보안 상태를 입증할 수 있습니다. 신뢰 체인을 만드는 데 사용되는 방법(즉, 측정되거나 검증됨)에 따라, 신뢰할 수 있는 환경에 따라 Remote 에이전트는 다양한 속성과 데이터를 확인합니다. 체인을 구축하기 위해 측정을 사용하는 시스템의 경우 원격 증명 에이전트는 특정 포그 노드에 대한 HW-RoT 측정 결과가 올바른지 원격으로 확인할 수 있습니다. 두 경우 모두 목표는 실행 중인 펌웨어 및 소프트웨어가 알려져 있거나 신뢰할 수 있다는 사실을 증명할 수 있는 것입니다. 특정 시스템에서 실행 중인 펌웨어가 증명에 실패하는 경우 이를 사용하지 않아야 하며 업데이트를 적용해야 합니다. 원격 인증에 사용할 수 있는 여러 구현 옵션이 있지만, OpenFog 컨소시엄은 TCG 및 여러 인터페이스에 걸친 원격 증명에 대한 기타 표준 기반 접근방식과 협력할 것입니다.

5.6 System Architecture View

OpenFog RA의 시스템 뷰는 플랫폼을 생성하기 위해 다른 구성 요소와 결합된 하나 이상의 노드 뷰로 구성됩니다. 일반적으로 포그 배치를 용이하게 하기 위해 이러한 시스템을 생성하는 이해관계자는 이 관점의 우려를 나타냅니다. 이후 이 관점은 시스템 설계자, 하드웨어 OEM 및 플랫폼 제조업체의 우려를 해결하기 위한 것입니다. 또한 지정된 시나리오에 대응하기 위해 생성한 시스템을 배포할 수 있도록 노드 뷰를 이해해야 합니다. 다음 다이어그램은 시스템 뷰의 시각적 표현을 보여줍니다. 우리는 노드 내에 포함된 노드의 단일 합성 이미지만 보여주지만, 중복이 필요하거나 다른 배포 요구 사항을 충족하는 시스템을 구축하기 위해 여러 노드를 가져오는 개념을 지원합니다.

5.6.1 Hardware Platform Infrastructure

포그 플랫폼은 내부 구성 요소에 강력한 기계적 지원과 보호를 제공해야 합니다. 먼저 노드 뷰에서 선택한 구성 요소부터 시작하여 시스템 뷰로 확장합니다. 많은 배치에서, 포그 플랫폼은 다음 절에서 설명한 것처럼 혹독한 환경 조건에서도 살아남아야 합니다. 포그 플랫폼 인클로저(시스템 아키텍처의 하드웨어 플랫폼 인프라라고 함)에 대한 일부 요구사항은 다음과 같습니다:

  • 현지 규정 및 표준 사례 준수.
  • 환경적 요인 (산업 또는 상업 온도 등급 부품)으로부터 보호.
  • 물리적 공격, 기물 파손 또는 도난에 대한 저항.
  • 허용 크기, 전력 소비 및 무게 특성.
  • 사람과 물건을 해가되지 않도록 보호하는 기능적 안전 요구 사항.
  • 내부 구성 요소의 기계적 지원
  • 내부 구성 요소의 냉각 관리.
  • 노드 레벨 모듈화 지원 및 여러 구성을 구축하고 수정할 수 있습니다. 여기에는 다양한 배포를 해결하기 위해 기능을 확장하는 기능이 포함됩니다.
  • 플랫폼의 사용 가능성 (서비스빌리티) 측면.
  • 포그 플랫폼이 전 세계에 배포되면서 수용 가능한 미학 및 기타 요소.
5.6.1.1 Environmental Conditions

많은 포그 플랫폼이 가혹한 환경 조건에서 전개될 것입니다. 즉, UL, CSA, ROHS 및 WEEE와 같은 다양한 국제 안전 및 환경 책임 표준을 준수하는 규격을 갖춰야 합니다. 안전 및 환경 요구사항의 예는 다음과 같습니다:

  • 산업, 자동차 및 군대와 같은 수직 산업에 필요한 온도 범위. 많은 시스템은 60도 이상의 온도에서도 작동 할 수 없습니다. 다음 온도는 일반적으로 표준으로 받아 들여지고 섭씨로 표시됩니다.
    • Commercial temperatures: 0~70
    • Industrial: -40~85
    • Military: -55~125
  • 습도, 충격, 진동, 오염, 지진 및 극한의 태양열을 포함한 환경적 위험.
  • IP 68 레벨까지 국제 보호 마킹 (IEC 표준 60529)
5.6.1.2 Thermal

배치에 따라 거친 위치 구축을 위한 포그 플랫폼이 환경적으로 밀봉될 수 있습니다. 그들은 안전한 내부 온도를 유지하기 위해 팬이나 다른 활성 요소를 요구하지 말아야 합니다. 공기 필터가 필요하지 않아야 합니다. 그러나 일부 고성능 포그 노드(특히 대형 가속기 어레이가 있는 노드)의 높은 전력 소모와 높은 패키지 밀도로 인해 동적 냉각 옵션이 허용됩니다. 강제 공기 냉각을 사용할 경우 미립자 오염을 줄이기 위해 공기 필터가 필요합니다. 임계 포그 노드의 팬은 이중화되어야 하며, 단일 팬에서 장애가 발생하더라도 포그 노드는 나머지 팬에서도 최대 용량을 유지할 수 있어야 한다. 열 전개 시나리오가 사용된 인클로저에 영향을 미칩니다. 전력 공급, 성능 및 열 방출에는 강한 상관 관계가 있습니다. 이는 전체 솔루션을 설계할 때 고려해야 합니다.

5.6.1.3 Modularity

대부분의 포그 노드는 모듈식 입니다. 더 작은 디자인에서, 모듈성은 일반적인 고정 구성 요소를 포함하는 마더 보드와 구성 가능한 구성 요소가 설치 될 수 있는 몇 개의 모듈 소켓으로 구성 될 수 있습니다. 대부분의 모듈러 시스템은 모듈성을 위한 기능을 절충해야합니다. 예를 들어, 모듈러 어댑터는 현장 업그레이드를 가능하게하기 위해 다른 인클로저를 사용해야 할 수도 있지만, 이 모듈성은 더 많은 서비스 수준을 제공 할 수도 있습니다.

구성 가능한 구성 요소의 예는 다음과 같습니다.

  • 빠른 CPU
  • 서로 다른 RAM 구성 요소
  • 다양한 스토리지 구성
  • southbound 바운드 에지 인터페이스를 모두 지원하는 구성 가능한 I / O 및 northbound 네트워킹 인터페이스.   * 구성 가능한 물리 계층 옵션을 사용하여 다양한 수의 유선 및 광 인터페이스를 포함한 네트워크 인터페이스.   * RS232, Modbus 등과 같은 사우스 바운드 인터페이스
  • FPGA 등을 포함한 가속기

적당한 크기의 포그 플랫폼은 마더보드의 백플레인으로 대체될 수 있으며, 보드를 백플레인에 설치하여 모듈화를 지원할 수 있습니다. 이는 일반적으로 가까운 에지 또는 내부 포그 플랫폼에서 볼 수 있습니다. 최대 규모의 포그 플랫폼은 대용량 블레이드 서버와 유사하며, 하이엔드 멀티 소켓 CPU 팜, 대형 GPU 어레이, 페타바이트급 스토리지, 수천 개의 I/O 링크 등 다양한 모듈을 지원합니다.

배포 시나리오에서 이러한 크기의 좋은 예로는 시스템 비전을 지원하는 데 필요한 포그 플랫폼입니다. 에지 근처의 훈련 시스템은 더 큰 포그 플랫폼을 이용하여 신경망을 훈련시킬 것입니다. 적당한 크기의 포그 플랫폼은 훈련된 모델을 채택하여 여러 비디오 스트림에 걸쳐 동적으로 이미지를 추론하거나 인식하기 위해 사용할 수 있습니다. 더 작은 포그 플랫폼이 카메라에 내장될 수 있고 내장형 가속기를 사용하여 단일한 카메라 피드의 이미지를 인식할 수 있습니다.

5.6.1.4 Module-Module Interconnect

모듈식 포그 플랫폼에는 내부 모듈 간의 상호 연결이 필요할 수 있습니다. 이러한 상호연결은 마더보드와 도터보드 또는 보드와 보드 사이에 백플레인을 통해 연결될 수 있습니다. 모듈-모듈 상호 연결에는 수백 GB/s가 필요할 수 있습니다. 운송 수단은 유선, 광학 또는 기타 수단이 될 수 있습니다. 모듈 사이의 연결을 패브릭이라고도 합니다.

가장 큰 포그 플랫폼에서는 한 개 또는 두 개의 패브릭 모듈을 중앙 허브로 사용할 수 있습니다. CPU, 가속기, 스토리지 및 네트워킹 모듈은 스타 토폴로지에서 스포크로 사용됩니다. 이상적으로는 이러한 상호연결 설비가 상호운용 가능한 하드웨어 생태계를 촉진하기 위해 PCI Express나 이더넷과 같은 개방형 표준을 준수해야 합니다.

5.6.2 Hardware Virtualization and Containers

하드웨어 기반 가상화 메커니즘은 포그 플랫폼을 구현하는 데 사용되는 거의 모든 프로세서 하드웨어에서 사용할 수 있습니다. 또한 시스템 보안에 중요한 역할을 할 수 있습니다. I/O 및 컴퓨팅을 위한 하드웨어 가상화를 통해 여러 기업이 동일한 물리적 시스템을 공유할 수 있습니다. 가상화는 또한 VM(가상 머신)이 설계상 사용하지 않아야 하는 지침이나 시스템 구성 요소를 활용하지 못하도록 하는 데도 매우 유용합니다.

컨테이너는 비교적 새로운 기술입니다. 컨테이너는 포그 컴퓨팅 환경 내에서 낮은 중량 격리 메커니즘을 제공할 수 있습니다. 격리 보증은 OS에 의해서만 이루어지며 실리콘에 완전히 기반을 두고 있지는 않습니다. 이렇게 하면 격리 요구사항이 실리콘에서 실리콘에서 실행되는 소프트웨어로 변경됩니다. 컨테이너 또는 VM을 분리하기 위해 사용하는 결정은 일반적으로 특정 사용 사례에 대한 보안 고려 사항을 기반으로 합니다. 우리는 소프트웨어 뷰에서 컨테이너에 대해 더 깊이 논의할 것입니다.

5.7 Software Architecture View

OpenFog RA의 소프트웨어 보기는 주어진 시나리오를 설명하는 시스템을 생성하기 위해 다른 구성 요소와 결합된 하나 이상의 노드 뷰로 구성된 플랫폼에서 실행되는 소프트웨어로 구성됩니다. 소프트웨어 뷰의 이해당사자에는 시스템 통합업체, 소프트웨어 설계자, 솔루션 설계자 및 포그 컴퓨팅 환경의 애플리케이션 개발자가 포함됩니다. 포그 플랫폼에서 실행되는 소프트웨어는 특정 배포 시나리오를 충족하는 데 사용됩니다. 강력한 포그 배치를 위해서는 포그 노드, 포그 플랫폼 및 포그 소프트웨어 간의 관계가 원활해야 합니다.

5.7.1 Software View Layers

아래 그림과 같이, 포그 노드의 소프트웨어는 플랫폼 하드웨어 계층 상단에 위치한 세 개의 계층으로 분리될 수 있습니다.

Application Services: 다른 두 계층이 제공하는 인프라에 의존하며, 특정 최종 사용 사례 요구 사항을 충족하고, 도메인별 요구 사항을 해결하는 서비스입니다.

Application Support: 자체적으로 유스케이스를 수행하지는 않지만, 여러 애플리케이션 서비스를 지원하고 지원하는데 도움이 되는 인프라 소프트웨어.

Node Management and Software Backplane: 노드 및 다른 노드 및 시스템과의 통신에 대한 일반 작동 및 관리 다이어그램의 IB는 In Band 관리를 나타냅니다. 일반적으로 소프트웨어가 관리 하위 시스템과 상호 작용합니다.

5.7.1.1 Software Backplane and Node Management
5.7.1.1.1 Software Backplane

소프트웨어 백플레인은 노드에서 소프트웨어를 실행하고 노드 간 통신(east-west 및 north-south)을 원활하게 하기 위해 필요합니다. 여기에는 다음이 포함됩니다:

  • OS: 가상화 계층 위에서 작동하고 애플리케이션 마이크로 서비스까지 확장하는 유니커널을 포함할 수 있습니다.

  • Software drivers and firmware: 하드웨어와 인터페이스하고 하드웨어를 활성화합니다.

  • Communication services: 통신을 활성화하고 소프트웨어 정의 네트워크 및 프로토콜 스택을 정의하는 데 도움이 될 수 있습니다.

  • File system software

  • Software virtualization: 소프트웨어 및 응용 프로그램 마이크로 서비스 실행을위한 하드웨어 기반 가상화 지원을 제공합니다.

  • Containerization: 소프트웨어 및 응용 프로그램 마이크로 서비스 실행을위한 OS 기반 격리 지원을 제공합니다.

소프트웨어 컨테이너는 소프트웨어 백플레인을 통해 실행되는 애플리케이션과 마이크로 서비스의 세분화된 분리에 좋은 메커니즘을 제공합니다. VM과 달리 소프트웨어 컨테이너에는 별도의 OS가 필요하지 않거나 포함되지 않는 경우가 많습니다. 컨테이너는 CPU, 메모리, 블록 I/O, 네트워크 등의 리소스 분리를 사용하여 운영 체제에 대한 애플리케이션의 뷰를 분리합니다.

컨테이너 내에서 애플리케이션을 구성하고, 리소스를 분리하고, 서비스를 제한할 수 있습니다. 여러 컨테이너가 동일한 커널을 공유하지만 각 컨테이너는 CPU, 메모리 또는 I/O와 같이 정의된 양의 리소스만 사용하도록 제한될 수 있습니다.

컨테이너는 고도로 분산된 시스템을 용이하게합니다. 단일 물리적 계산 노드, 여러 VM 및 여러 물리적 계산 노드에서 실행되는 응용 프로그램은 포그 컴퓨팅에 필요한 elastic compute 환경에 중요한 기능입니다.

소프트웨어 백플레인의 보안은 백플레인 위의 소프트웨어 계층에서 신뢰가 설정되는 구성 요소입니다. 백플레인은 노드와 플랫폼에 의해 설정된 신뢰 체인을 사용하여 애플리케이션 지원 및 서비스 계층의 검증 수단을 제공해야 합니다. 이 확인은 외부 시스템에 대한 원격 증명으로 확장될 수 있습니다.

컨테이너, 애플리케이션 서비스 및 마이크로 서비스를 안전하게 초기화하고 원하는 서비스를 제공하기 위해 소프트웨어 백플레인은 신뢰의 루트를 확장할 수 있어야 합니다. 소프트웨어 백플레인은 소프트웨어 스택의 상위 계층에서 신뢰할 수 있는 실행 환경 및 컨테이너의 생성 및 폐기를 관리하므로, 상위 계층이 엔티티를 확인할 수 있어야 합니다. 소프트웨어 백플레인은 다른 장치로부터 수신한 데이터를 기반으로 응답을 시행하는 정책을 정의해야 합니다. 이러한 정책은 특정 방화벽 규칙, 애플리케이션 혼합 및 설치된 패치를 사용하는 장치와의 통신만 허용하는 범위 내에서 한정될 수 있습니다. 또는 특정 OS 릴리스가 필요한 경우와 같이 더 개방적인 정책일 수 있습니다.

소프트웨어 백플레인 레이어는 thing-to-fog, fog-to-fog and fog-to-cloud 커뮤니케이션을 조율합니다. 이 계층은 모든 방향에서 통신을 보호하기 위해 데이터 기밀성 및 무결성 서비스를 제공해야하며 제공해야하며 연결 기반 및 연결 지향형 통신에 대해 각각 데이터 기반 및 피어 투 피어 인증을 적용해야합니다. 신뢰할 수 있는 컴퓨팅을 지원하는 데 필요한 원격 인증을 지원하기 위해 데이터 출처 및 대상에 대한 부인 방지 기능을이 계층에서 northbound로 제공 할 수도 있습니다. 이러한 서비스는 하드웨어 루트 트러스트에서 유지 관리되는 보안 관리에서 발급 한 보안 자격 증명에서 보안 및 신뢰성을 도출해야 합니다. 소프트웨어 백플레인의 모든 통신 (유선 또는 무선)은 기밀성, 무결성, 인증 및 부인 방지 서비스 [섹션 10.1.1]를 제공하기 위해 표준 암호화 기능의 기본 목록을 사용해야합니다. 성능상의 이유로 이러한 암호화 기능은 포그 노드에 설치된 Crypto Accelerator에 의해 수행되는 경우가 많습니다. 다음은 소프트웨어 백플레인의 추가 측면을 설명합니다.

  • Service discovery: 다중 포그 구현이 함께 이루어져야 할 때 필수적이며, 협력 정보 교환 및 컴퓨팅을 위해 임시 방식으로 다중 신뢰 경계를 작성할 수 있습니다. 일시적인 협업을 위한 포그 구축 사이에 신뢰 구축을 위해서는 잘 구축된 신뢰 프레임워크와 신뢰 제공자 서비스 그래프가 필요합니다.

  • Node discovery: 클러스터 된 배포에서 내부 포그 검색에 적용됩니다. 새로운 포그 시스템이 클러스터에 추가되면 클러스터의 존재를 브로드 캐스트하고 클러스터에 조인합니다. 이후부터 이 노드를 사용하여 워크로드를 공유할 수 있습니다.

  • State management: 상태 저장 및 상태 비저장 계산 모델을 모두 지원합니다. 상태 저장 계산 모델은 탄력적인 복제본 모델을 통해 상태를 외부화하거나 포그 클러스터 내에 상태를 저장할 수 있습니다. 데이터 손실을 방지하기 위해 동일한 엔티티의 여러 복제본이 동기화되도록 합의 알고리즘을 사용할 수 있습니다. 외부화 상태에는 잘 알려진 데이터베이스 및 스토리지 기술을 기반으로 실행되는 세션/상태 마이크로 서비스의 도움이 필요합니다.

  • Publication and subscription management: 패브릭 런타임 위에서 실행되는 애플리케이션 계층에는 이벤트 게시, 상태 변경 알림 및 메시지 브로드캐스트에 대한 인프라 지원이 필요합니다. 게시 및 구독 관리 메커니즘은 임시 구독 및 플러그형 통지 엔드포인트를 지원합니다. 런타임은 추상적으로 유지됩니다. 페이로드를 구성하는 애플리케이션 계층은 런타임 계층을 통해 대상 엔드포인트로 푸시됩니다.

5.7.1.1.2 Node Management (In Band)

관리에 대해 설명할 때 "노드"라는 용어에 시스템에 과부하가 걸리는 경우가 많습니다. 포그 내 대역 관리 계층은 포그 노드 또는 시스템의 하드웨어와 소프트웨어를 원하는 상태로 유지하고 가용성, 탄력성 및 성능을 위해 지정된 수준으로 작동하도록 해야 합니다. 다양한 기능으로 설계된 포그 노드를 지원하기 위해 관리 계층의 구성은 달라질 수 있습니다. 내장형 및 독립형 배포 모델의 경우 원격 위치에서 노드 관리를 처리할 수 있습니다. 포그 노드의 하드웨어 플랫폼 관리 하위 시스템은 이 노드 관리를 수행하기 위해 메인 프로세서의 소프트웨어와 결합됩니다. 다음은 각 포그 노드에 필요한 기능입니다.

  • Configuration management: 운영 체제 및 애플리케이션 지원 구성은 원하는 OS 상태와 애플리케이션 런타임을 유지하는 소프트웨어 에이전트를 통해 관리됩니다. 에이전트는 배포 비용으로서 노드 관리의 선택적 측면입니다.

  • Operational management: 인프라 모니터링을 담당하는 시스템 관리 인력 및 자동화 시스템을 위해 포그 노드의 작동 원격 측정 기능을 캡처, 저장 및 제공합니다. 이 정보에는 네트워크, OS 및 애플리케이션에서 생성된 네트워크 운영 이벤트 및 경보가 포함됩니다. 모니터링 시스템은 중요 경보에 대한 작동 워크플로우를 관리합니다. 이러한 경보의 업데이트 적용은 경보에 따라 자동화하거나 수동으로 수행할 수 있습니다.

  • Security management: 보안 관리에는 키 관리, 암호화 제품군 관리, ID 관리 및 보안 정책 관리가 포함됩니다.

  • Capacity management: 추가 컴퓨팅, 네트워킹 및 스토리지 리소스의 용량과 페이지를 워크로드의 요구에 따라 모니터링합니다.

  • Availability management: 중요 인프라는 소프트웨어 또는 하드웨어의 오작동이나 충돌 시 자동으로 복구되어야 합니다. 하드웨어 장애가 발생하면 워크로드가 다른 하드웨어 노드로 재배치됩니다. 소프트웨어 오류가 발생하면 VM 또는 컨테이너를 재활용할 수 있습니다. 지정된 시나리오에 대한 SLA를 충족할 수 있도록 충분한 예비 시스템 용량을 준비 상태로 유지해야 합니다.

5.7.1.2 Application Support

애플리케이션 지원에는 여러 애플리케이션(마이크로 서비스)에서 사용되거나 종종 공유되는 광범위한 소프트웨어가 포함됩니다. 애플리케이션 지원은 도메인이나 애플리케이션별로 다르지는 않지만 가상화, 하드웨어 등을 비롯한 기본 계층에 따라 달라질 수 있습니다. 아래 그림과 같이 배포 유형 또는 애플리케이션에 따라 여러 가지 형태로 지원 소프트웨어를 제공할 수 있습니다(예: 일부 노드의 일부 배포에서는 여러 애플리케이션 스토리지 데이터베이스를 사용해야 할 수 있음).

필수는 아니지만 애플리케이션 지원 계층 내의 요소는 소프트웨어 백플레인이 제공하는 것과 같이 어떤 형태의 가상화로 구현되는 경우가 많습니다. 예를 들어, 포그 노드 내의 여러 애플리케이션(아래 그림 참조)에 의해 사용되는 메시지 브로커 또는 NoSQL 데이터베이스는 독립적으로 컨테이너에 저장되고 해당 범위를 통해 지원 기능을 제공할 수 있습니다.

모든 지원 계층 기능의 컨테이너화 또는 가상화는 연결 해제, 추가 보안 기능을 제공하며 백플레인을 통해 지원 계층을 더 빠르고 쉽게 확장할 수 있습니다.

응용 프로그램 지원에는 다음이 포함됩니다.

  • Application management: 애플리케이션 지원 소프트웨어의 프로비저닝, 검증, 업데이트 및 일반 관리뿐만 아니라 애플리케이션 마이크로 서비스도 관리합니다. FPGA 및 GPU와 같은 가속기의 구성 이미지도 동일한 메커니즘으로 관리합니다. 애플리케이션 관리에는 다음이 포함됩니다.

    • Application provisioning: 네트워크 런타임에는 관리 시스템에서 애플리케이션 프로비저닝 요청을 수신하고 처리하는 프로비저닝 에이전트가 호스팅됩니다. 그런 다음 관리 소프트웨어는 애플리케이션 매니페스트를 사용하여 버전 이미지 저장소에서 올바른 이미지를 선택합니다. 프로비저닝 에이전트는 롤백 요청을 지원합니다.
    • Image (application bits) management: 패브릭 런타임 계층에는 패브릭 제어 인프라의 일부로 호스팅되는 이미지 관리 프레임워크의 지원이 필요합니다. 이미지 관리 인터페이스에는 신뢰, 멀웨어, 버전 관리 및 종속성 관리를 위한 이미지 확인이 포함될 수 있습니다.
    • Image verification: 패브릭 런타임은 기본적으로 안전한 것으로 확인된 이미지만 실행합니다. 이를 위해서는 패브릭 컨트롤러가 PKI와 같은 코드 인증 체계를 지원해야 합니다.
    • Version management: 이미지 관리 프레임워크를 사용하면 특정 버전의 이미지를 배포할 수 있습니다. 이미지 저장을 위한 CRUD(Create, read, update 및 delete) 기능은 롤백 시 이미지 저장소를 채우고 특정 버전을 프로비저닝하는 데 필수적입니다.
    • Transparent updates: 호스팅된 애플리케이션 엔드포인트의 상태 저장 또는 상태 비저장 동작에 따라 패브릭 런타임은 동일한 애플리케이션의 여러 인스턴스를 업데이트 영역으로 분산합니다. 이렇게 하면 런타임에서 한 번에 하나의 업데이트 영역을 방문하여 업데이트할 수 있으므로 전체 애플리케이션이 중단되지 않습니다.
  • Runtime engines: VM, 컨테이너, 플랫폼 런타임, 프로그램 언어 라이브러리 및 실행 파일은 애플리케이션 및 마이크로 서비스에 대한 실행 환경을 제공합니다. 예를 들어 Java Virtual Machine, Node.js(JavaScript 런타임), NET Framework, Python Standard Library 및 런타임 실행 파일이 있습니다.

  • Application servers: 마이크로 서비스 또는 인프라 또는 애플리케이션을 지원하는 다른 노드를 호스팅하는 애플리케이션 또는 웹 서버 예를 들어 Wildfly/JBoss, Tomcat 및 Zend Server가 있습니다.

  • Messages and events (buses or brokers): 메시지 및 이벤트 기반 애플리케이션 및 마이크로 서비스 통신 지원 (종종 메시지 지향 미들웨어, 메시지 브로커, 메시지 버스 등으로 분류 됨). 메시지 DDS, ActiveMQ 및 ZeroMQ가 그 예입니다.

  • Security services: 암호화 서비스, ID 브로커 등을 포함한 애플리케이션 보안 지원 애플리케이션 지원 계층 내의 보안 서비스에는 시스템 및 네트워크 이벤트 모니터링, 컨텐츠 필터링 및 부모 제어뿐만 아니라 패킷 검사, 침입 탐지 및 차단 시스템도 포함될 수 있습니다. 이러한 세부 사항은 보안 부록에 포함되어 있습니다.

  • Application data management/storage/persistence: 애플리케이션 데이터 변환 기능 및 스토리지로서, 메모리 내 캐시는 물론 내구성이 뛰어납니다. 영구 스토리지에는 SQL과 NoSQL 데이터베이스가 모두 포함될 수 있지만, 지연 시간 및 성능 문제를 해결하기 위해 메모리 내 데이터베이스 및 캐시와 같은 다른 형태의 내구성이 있는 스토리지를 고려해야 합니다. 예를 들어 SQLite(SQL), Cassandra & Mongo(NoSQL) 및 Redis 또는 Gemfire(메모리 내 데이터베이스)가 있습니다. 이 계층 내에서 고려할 사항은 다음과 같습니다:

    • Encoding/decoding/transcoding:
      • Decoding: 애플리케이션 계층 처리를 위해 바이너리에서 JSON까지. 예를 들어 OPC UA/DDS/LONWORKS 바이너리에서 JSON으로 프로토콜 변환이 가능합니다.
      • Encoding: 애플리케이션 계층 페이로드에서 바이너리로 전송. 예를 들어 JSON에서 OPC UA 바이너리로.
      • Transcoding: 데이터 구조를 동일한 계층 내의 한 형식에서 다른 형식으로 변환(아마 게이트웨이를 사용 중일 수 있음)
      • Encryption/decryption: 모션 중인 데이터와 미사용 데이터
    • Information persistence/cache
      • 구조화 및 비정형 데이터의 저장 사용     * 내구성/비 지속성 (예: 인 메모리, 로컬 디스크, 외부 저장 서비스)     * 인코딩/디코딩/트랜스 코딩 파이프 및 필터 프로세스로 플러그 가능     * 스트리밍 및 일괄 처리 모델 지원     * 멀티 테넌시 (예: 범위/프로파일 간의 정보 격리) 지원     * 저장 및 전달 기능
      • 디지털 미디어 콘텐츠 (예: 디지털 권한 관리, 삽입 추가)에 대한 특별 지원
  • Analytics tools and frameworks: 예로는 Spark, Hadoop 및 기타 MapReduce 유형의 기술이 있습니다.

5.7.1.3 Application Services Layer

포그 노드 애플리케이션은 구축, 사용 사례 및 리소스 가용성에 따라 크게 달라진다. 포그 컴퓨팅 애플리케이션은 느슨하게 결합된 마이크로 서비스 모음으로 구성되어 있다. 아래 그림에서 볼 수 있듯이, 이러한 서비스는 역할에 따라 계층으로 구분할 수 있습니다.

애플리케이션 지원 서비스와 마찬가지로 애플리케이션은 소프트웨어 백플레인에서 제공하는 컨테이너/가상 환경에서 실행될 수 있습니다. 이러한 응용 프로그램은 컨테이너 화되거나 컨테이너 엔진 (예: 런타임 엔진)에서 실행되거나 컨테이너 서비스에 배포 될 수있는 지원 계층 서비스 (예: 데이터베이스 또는 메시지 브로커)를 이용할 수 있습니다.

포그 커넥터 서비스는 건축 애플리케이션 계층의 "south side"에서 사용되며, IoT 사물의 방향에 있는 인터페이스입니다. 여기에는 Modbus 외와 같은 기존 운송 수단이 포함됩니다. 이러한 마이크로 서비스에는 선택한 에지 프로토콜을 사용하여 장치, 센서, 액추에이터 및 기타 플랫폼과 통신할 수 있도록 하는 일련의 API가 포함되어 있습니다. 포그 커넥터는 프로토콜 추상화 계층 위에서 작동하며 물리적 물질에 의해 생성되고 전달된 데이터를 공통 데이터 구조/양식으로 변환한 다음 이를 핵심 서비스로 보냅니다.

핵심 서비스는 기업과의 경계를 벗어납니다. 핵심 서비스는 에지로부터 데이터를 수집하여 클라우드와 같은 상위의 다른 서비스 및 시스템에서 사용할 수 있도록 합니다. 핵심 서비스는 종종 엔터프라이즈 및 기타 시스템 요청을 적절한 에지 리소스로 라우팅하고, 때때로 에지 장치에 대한 요청을 변환합니다. 이 변환은 높은 수준의 포그 컴퓨팅 서비스(또는 클라우드)에서 작동을 위한 에지 장치로 명령을 수신 및 변환하기 위한 API 집합이 포함된 안개 커넥터의 기능입니다.

지원 서비스는 로깅, 스케줄링, 서비스 등록, 데이터 정리 등과 같은 일반적인 소프트웨어 애플리케이션 작업을 제공하는 광범위한 마이크로 서비스를 포함합니다.

분석 서비스에는 사후 대응 및 예측 기능이 모두 포함될 수 있습니다. 에지에 가깝게, 포그 노드는 자연스럽게 더 반응성이 높은 서비스를 가질 것입니다. 처리 능력과 기능이 더 뛰어난(일반적으로 에지에서 멀리) 포그 노드는 기계 학습 및 기타 인지 서비스를 기반으로 한 더 많은 예측 능력을 가질 것입니다.

반응 분석은 원시 들어오는 데이터를 보고 예상된 표준을 벗어나는 변화를 모니터링합니다. 이는 다음을 포함하지만 이에 국한되지 않습니다:

  • 중요 이벤트 처리
  • 단순한 이상 탐지
  • 데이터 외부 경계 트리거링
  • 스트림 처리와 센서 융합
  • 감독/분산 제어
  • 상태 머신 및 상태 머신 엔진
  • 상태 기계를 움직이는 데 필요한 표현 언어 (SDK와 비교)
  • SDK 및 이벤트 처리 엔진에 규칙을 제공/업데이트하도록 설정된 API

예측 분석 (Predictive analytics)은 예측 분석 (forecasting analytics)으로 정의됩니다. 이는 다음을 포함하지만 이에 국한되지 않습니다.

  • 포그 노드 기계 학습은 일부 측면(예: 교육)이 클라우드에서 수행되는 포그 전용 또는 하이브리드 모델을 지원할 수 있으며, 보다 높은 처리 집약적 측면(추론 엔진)이 포그에서 실행됩니다. 모델을 클라우드에서 생성하여 포그노드 에이전트에 전달할 수 있습니다.
  • 노드 밖에서 실행 중일 수 있는 시스템 학습 또는 기타 예측 계층 분석 엔진에 연결합니다.
  • 일반적으로 단일 센서 또는 장치(센서 퓨전이라고 함)에서 파생될 수 없는 센서/장치 모음을 통해 유용한 인텔리전스 기능을 개발할 수 있습니다. 데이터는 병렬로 측정하는 유사한 센서(예: 보안 카메라 배열) 또는 서로 다른(그러나 상호 연관된) 파라미터를 모니터링하는 서로 다른 센서로부터 퓨전될 수 있습니다. 센서 융합은 인터넷 정보 등 노드 외부에서 안전하게 수집된 정보를 포함할 수도 있습니다.
  • 예측 및 기계 학습 알고리즘을 데이터 스트림, 모델 생성 등에 연결하는 방법에 중점을 둔 SDK 및 도구

통합 서비스를 사용하면 외부 포그 노드가 포그에서 수집 또는 생성된 관심 데이터를 등록할 수 있으며, 데이터를 제공해야 하는 위치, 시기, 방법 및 형식을 지정할 수 있습니다. 예를 들어, 클라이언트는 REST를 통해 모든 온도 관련 데이터를 지정된 주소, 매 시간마다 암호화되고 JSON 형식으로 전송하도록 요청할 수 있습니다. 통합 서비스는 클라이언트 등록 시 지정된 대로 파이프/필터 메커니즘을 사용하여 데이터를 전송할 수 있는 수단을 제공합니다.

사용자 인터페이스 서비스는 다음을 표시하는 데 사용되는 마이크로 서비스입니다:

  • 포그 노드에서 수집 및 관리되는 데이터
  • 포그 노드에서 작동하는 서비스의 상태 및 작동
  • 포그 노드에서 분석 처리 결과
  • 시스템 관리 및 포그 노드 작업

6 Adherence to OpenFog Reference Architecture

OpenFog 컨소시엄은 표준 개발 조직과 파트너십을 맺고 보다 심층적인 상호운용성을 촉진할 수 있는 세부적인 요건을 제공할 계획입니다. 새로운 표준을 제정하는 것은 길고 지속적인 과정이기 때문에 시간이 걸릴 것입니다. 이러한 세부 표준을 확정하기 전에, 컨소시엄은 구성요소 수준의 상호운용성과 궁극적으로 인증을 위한 토대를 마련하고 있습니다. OpenFog Testbed 작업 그룹은 기술 위원회와 함께 테스트베드 이니셔티브를 통해 보여질 아키텍처 원칙 및 다양한 뷰에 대한 OpenFog 준수에 대한 세부 정보를 제공합니다. 이들은 OpenFog RA를 지원할 수 있는 다양한 기술과 주어진 시나리오에 대한 전반적인 솔루션에 사용될 것입니다. 포그 솔루션의 일부로 활용되는 기술을 OpenFog Technology Ready라고 합니다.

시나리오에 대한 OpenFog 아키텍처 E2E 솔루션은 OpenFog Ready라고 부릅니다.

표준화에 앞서 컨소시엄은 기술 작업 그룹을 활용하여 OpenFog 또는 포그 컴퓨팅 구현을 주장하는 다양한 구현에 점수를 매깁니다. 이 채점 및 후속 항소 절차는 회원들에게 공개되며, 진보적인 포그 컴퓨팅 구현과 OpenFog 아키텍처 원칙 및 OpenFog 참조 아키텍처를 따르지 않는 구현을 강조하고 인식하기 위해 게시됩니다.

7 An End-to-End Deployment Use Case

앞에서 우리는 개발자, 설계자 및 설계자가 수직 시장 활용 사례를 위한 솔루션을 개발하기 위해 OpenFog RA를 사용하는 방법을 설명했습니다. 이어지는 장에서 OpenFog RA는 일반적인 포그 플랫폼의 세부 정보를 제공합니다. 이 섹션에서는 end-to-end 유스케이스를 다룹니다.

7.1 Airport Visual Security

공항의 시각적 보안(감시)은 포그 컴퓨팅에 대한 탁월한 엔드 투 엔드 시나리오를 제공합니다. 실시간 정보 수집, 공유, 분석 및 작업에 필요한 복잡하고 데이터 집약적인 요구를 보여줍니다.

먼저 여객의 여정을 살펴 보겠습니다.

  • 집과 공항에서 출발하는 드라이브
  • 장기 주차 시설
  • 공항 보안 검색 대에 가방 가져 가기
  • 가방을 스캔하고 체크인
  • 보안을 확인하고 탑승구로 이동
  • 도착시 가방 회수
  • 렌터카 대리점으로 이동; 공항을 벗어남

이 여행 시나리오는 문제가되지 않습니다. 하지만 우리가 이 시나리오에 어떤 종류의 위협이나 많은 위협을 도입한다면, 시각적인 보안 요구 조건은 훨씬 더 복잡해집니다. 예:

  • 공항에 들어가는 차량이 도난당했습니다.
  • 승객의 이름이 비행 금지 목록에 있습니다.
  • 승객은 공항 어딘가에서 짐을 부탁합니다.
  • 승객의 수하물은 비행편과 함께 도착하지 않습니다.
  • 수하물을 스캔하여 비행기에 실을 수 있지만 올바른 승객이 수화물을 픽업하지는 않습니다.
  • 사기꾼은 다른 승객 탑승권을 도용 (또는 전환)하고 다른 사람의 탑승권을 얻습니다.
  • 승객은 도착 터미널에서 다른 사람의 수하물을 가져갑니다.

이러한 가능한 위협을 포착하려면 두 공항(각 공항마다 수천 대의 카메라)에 걸쳐 광범위한 보안 감시 카메라 네트워크가 필요합니다. IP H.264 또는 H.265 카메라는 30fps(초당 프레임)에서 12Mbps를 생성하며, 카메라당 약 1TB를 보안 담당자에게 전송해야 합니다. 또는 비디오 스트림이 스캔 및 분석을 위해 로컬 시스템으로 전달될 가능성이 더 높습니다.

또한, 법 집행 기관에서는 출발지부터 도착지까지 승객의 여행에 관한 여러 시스템에서 출발하는 데이터가 필요합니다. 마지막으로, 이 모든 비디오와 데이터는 실시간 위협 평가 및 해결 시스템과 통합되어야 합니다.

7.1.1 Cloud and Edge Approaches

Edge-to-Cloud 디자인에서는 공항의 모든 카메라 (에지 장치)가 처리를 위해 클라우드로 직접 전송할뿐만 아니라 승객의 여행 기록에서 수집 한 기타 관련 데이터도 전송합니다.

Advantages Disadvantages
Edge-to-Cloud Approach 공통 위치에 공유 데이터 저장, 위협 예방 계획에 대한 과거 분석 대기 시간 (밀리초 동안 이미지 및 알림 권한을 처리할 수 없음), 높은 데이터 전송 비용, 항상 사용 가능한 클라우드에 대한 의존성
Edge-only Approach Low latency 공항 내 시스템 간 데이터 및 정보 공유 제한, 거의 실시간으로 공항간에 데이터를 공유하는 데 따른 제한 사항

이러한 두 가지 접근 방법 모두 장단점이 있습니다. 그러나 두 경우 모두 Edge-to-Cloud 및 Edge-Only의 단점은 포그 컴퓨팅의 요구 사항을 뒷받침합니다.

7.1.2 Fog Computing Approach

포그 컴퓨팅의 장점은 주어진 문제를 해결하기 위해 필요한 곳에 컴퓨팅을 삽입할 수 있다는 것입니다. 이 솔루션에 들어가기 전에 OpenFog의 주요 특징과 각 요소가 구체적인 사용 사례와 어떻게 관련되어 있는지 살펴보겠습니다.

4장에 자세히 설명되어 있는 OpenFog 필러는 공항 시각 보안 E2E 아키텍처 전반에 걸쳐 제공됩니다. 이러한 특정 배포 시나리오로 인해 특별한 주의가 필요한 것도 있습니다.

  • Security: 공항 시각 보안 시나리오는 물리적으로 분산된 포그 배포 시나리오 입니다. 그러므로, 물리적 소유는 우리의 보안 분석의 범위에 있습니다. 또한 개인 식별 가능 정보를 포함할 수 있는 많은 양의 데이터가 안전하게 보관되어야 합니다.

  • Scalability: OpenFog 구현 시 시스템 비용 및 성능과 관련하여 비즈니스 요구에 적응하려면 확장성이 필수적입니다. 새 공항 터미널, 게이트 또는 추가 센서 및 장비를 추가할 때는 솔루션의 확장이 필요하며 완전히 새로운 배포가 필요하지 않습니다.

  • Open: IoT 플랫폼과 애플리케이션을 위한 유비쿼터스 포그 컴퓨팅 환경의 성공을 위해서는 개방성이 필수적입니다. 독점적 또는 단일 공급업체 솔루션은 제한된 공급업체 다양성을 초래하여 시스템 비용, 품질 및 혁신에 부정적인 영향을 미칠 수 있습니다.

  • RAS: 솔루션의 다양한 측면은 기존 또는 새로운 리소스의 조정을 포함하여 안정적이고, 사용 가능하며, 서비스 가능해야 합니다. 새로운 객체 인식 모델이 시각적 분석을 위해 교육되므로, 이러한 추론 엔진 모델은 솔루션의 가용성에 영향을 미치지 않고 가까운 에지 장치에서 업데이트되어야 합니다.

  • Programmability: 시각 분석은 이러한 시나리오를 용이하게 하기 위해 활용되며, 따라서 하드웨어 프로그래밍을 활용합니다. 구현 시 FPGA와 같은 가속기를 사용하여 시나리오에서 보이는 대로 이미지에 대한 추론을 수행할 수 있습니다.

OpenFog 레퍼런스 아키텍처에는 공항 시각 보안 시나리오에 대해 OpenFog 구현을 지원하는 여러 계층, 관점 또는 크로스-커팅 관련 우려 사항 및 뷰가 포함됩니다.

이 시각적 보안 시나리오에서는 플랫폼, 데이터 분석, 성능 및 상위 레벨의 소프트웨어 인프라에 초점을 맞춥니다.

  • Performance: 적절한 정보를 처리하고 작업을 구현하기 위해 유용한 지연 시간에 민감한 정보를 제공할 시간을 포함해야 함을 나타냅니다.

  • Platforms: 시나리오에 대응하기 위해 각 포그 노드가 서로 통신하는 데 필요한 적절한 가속기 및 통신 인프라를 갖춘 올바른 하드웨어 플랫폼을 갖추어야 한다는 것을 나타냅니다.

  • Data Analytics: 개별 Fog 노드에서 이 정보를 처리할 때 가장 가까운 노드에서는 계층의 각 수준에서 더 높은 수준의 인텔리전스를 사용할 수 있습니다.

  • Software Infrastructure: 다양한 포그 노드 배포에 걸쳐 데이터, 인텔리전스 및 환경을 전환하고 보다 높은 수준의 컴퓨테이션을 수행할 수 있음을 나타냅니다.

포그 노드의 핵심 요소는 컴퓨팅, 스토리지, 네트워크, 가속기 및 제어로 볼 수 있습니다.

7.1.2.1 Functions of a Fog Node for Visual Security

Sensors, Actuators and Control

end-to-end 포그 컴퓨팅 구현에서는 네트워크 에지에 있는 센서부터 시작합니다. 앞서 우리는 공항 감시 설비의 카메라 수와 수천 대의 카메라에 의해 생성되는 데이터의 양에 대해 논의했습니다. 카메라 외에도, 위협을 예방하는 데 유용한 데이터를 수집하는 많은 다른 에지 장치들이 있습니다. 여기에는 다음이 포함됩니다:

Physical security sensors Gates, doors, motion detectors, etc.
Safety sensors 화재, 연기, 열 및 폭탄 센서. 참고 : 이러한 독립 시스템은 이더넷에 있거나 포그 노드 뒤에 배치 될 수 있습니다 (레거시 프로토콜 브리지에 대한 다음 절 참조).
Audio sensors and basic audio analytics 오디오 센서는 위협을 탐지하고 평가하는 데 중요한 음성 및 소리를 캡처 할 수 있습니다. 이 오디오 정보는 기본 오디오 분석 및 경보가 처리를 위해 계층의 상위 레벨로 전송되도록 전달할 수 있습니다.
RFID sensors RFID 센서는 여권 정보와 같은 승객의 정보를 수집하는 데 사용될 수 있습니다.

이러한 센서는 다양한 인터페이스를 통해 포그 노드에 연결됩니다. PCIe, USB, 이더넷 등과 같은 표준 개방형 인터페이스여야 합니다. 개방형 API도 지원해야 하지만 이들의 구현은 독점적일 수 있습니다. 이것은 개방성을 보장하기 위해 중요합니다. 연결한 후에는 상위 레벨의 소프트웨어에서 사용할 수 있습니다. 예를 들어, RFID 판독기는 이더넷이나 USB로 포그 노드에 연결됩니다. 포그 노드는 데이터를 활용하여 상위 수준의 엔티티에 제공할 수 있습니다.

Protocol Abstraction Layer (Legacy Protocol Bridge): 포그 컴퓨팅 솔루션에는 "greenfield" 배치가 필요하지 않습니다. 아날로그 카메라와 디지털 카메라가 혼합되어 있다고 가정합니다. 아날로그 피드를 변환하는 한 가지 방법은 가속기를 사용하는 것입니다 (저비용 FPGA가 좋은 구현 옵션을 제공함). 포그 노드는 다수의 센서를 가져 와서 센서 융합을 수행 할 수 있어야하며, 포그 노드에는 레거시 아날로그를 디지털로 변환하기위한 다양한 물리적 인터페이스가 있어야 합니다. 이러한 인터페이스에는 동축 케이블, USB, RS232, 오디오, PCIe 등이 포함되며 SPI와 같은 시스템 인터페이스가 포함됩니다. 시스템이 IP 네트워크에 직접 연결할 수있는 경우 RA는 소프트웨어 백플레인을 사용하여 상위 레벨 소프트웨어를 활용하는 센서 융합을 제공합니다. 현실은 개방형 인터페이스와 프로토콜의 많은 구현에서 약간의 차이가 있으므로 효과적으로 활용하기 위해서는 프로토콜 추상화 레이어가 필요합니다.

Network: 각 IP 연결 카메라 (및 기타 여러 센서)는 이더넷을 사용하여 포그 노드에 연결됩니다. 시나리오에서 카메라는 가장 많은 센서를 나타냅니다. 단일 포그 노드는 1Gb (카메라에서 노드로) 및 10/1Gb (fog-to-fog)로 상호 연결하여 4-8 개의 카메라 스트림을 집계 할 수 있다고 믿습니다. 포그 노드는 camera-to-node, node-to-node, node-to-cloud 통신을 지원하기 위해 최소 16개의 이더넷 포트가 필요합니다. 또한 1단계 포그 노드는 IP 및 비 IP 트래픽 (예 : BLE, Z-Wave 및 배지 리더 정보)을 수집하기 위해 여러 개의 비 IP 프로토콜을 지원할 수도 있습니다. 네트워크 및 포그 노드는 시간에 민감한 네트워킹 (TNS) / 결정성 있는 통신을 사용하여 통화 중이거나 시끄러운 네트워크에서 경고의 우선 순위를 지정합니다.

Accelerators: 시각적 보안 시나리오는 가속기를 포함 할 수 있는 많은 장소를 제공합니다. 위에서 설명한 것처럼 FPGA를 사용하여 아날로그 입력을 디지털 형식으로 변환 할 수 있습니다. 이 애플리케이션에서 FPGA는 기존 PCIe 인터페이스를 사용하여 노드에 연결될 수 있습니다. 또한 시각적 인식(표면, 물체 등)을 수행할 때 바로 연결이 역할을 합니다. AlexNet, GoogleNet, TensorFlow 및 기타 신경 네트워크를 사용하여 위협 요소와 일치하는 이미지를 가속할 수 있습니다. 이것은 보통 훈련된 모델에 기초한 추론 점수라고 합니다. 이 예에서 노드에 대한 권장 인터페이스는 아날로그-디지털 형식(대개 PCIe)에 대해 동일합니다. 따라서 시간이 지남에 따라 비용과 기술이 변화함에 따라 향후 FPGA를 업그레이드할 수 있습니다.

Compute: 포그 노드가 설치되면 상위 소프트웨어는 연결된 모든 센서 및 카메라에서 생성 된 데이터를 처리하는 기능을 이해해야 합니다. 압축을 카메라에 추가하여 카메라의 범용 계산 요구 사항을 줄일 수도 있습니다. 계층 구조의 다음 단계는 범용 컴퓨팅 리소스 또는 가속기를 사용하여 비디오 분석을 수행하려면 더 높은 처리가 필요합니다. 이 시나리오에서는 대부분의 컴퓨팅을 반드시 카메라에서 수행할 필요는 없으며 안개 노드에서 수행하는 것이 좋습니다.

Storage: 주어진 카메라 피드의 경우, 포그 컴퓨팅 디자인은 24시간의 롤링 데이터를 캡처해야합니다. 이를 위해서는 각 카메라 피드에 대해 1TB의 현지화 된 스토리지가 필요합니다. 이러한 장치에 대한 인터페이스는 SATA 또는 PCIe입니다. 매체는 플래시 기반 디스크 또는 회전 디스크입니다. 하나의 토폴로지에서 단일 포그 노드가 약 8개의 카메라 피드를 저장하는 역할을 수행 할 수 있습니다. 이것은 전통적인 네트워크 비디오 레코더 (NVR) 기능입니다.

일부 구현에서는 스토리지가 카메라에 상주합니다. 그러나 우리는 공항 시각 보안 시나리오가 포그 노드의 계층에 스토리지를 구성하는 것이 더 적합하다고 생각합니다. 이는 카메라 비용 절감 및 동일한 포그 노드의 NVR 기능과 비디오 분석 기능의 결합을 의미합니다. 그러나 이는 계층 구조의 다음 레벨에서 컴퓨팅 기능 요구 사항을 증가시킵니다.

Management (OOB): 포그 노드에 업데이트 가능한 펌웨어 및 소프트웨어가 있는 경우 설계에서 원격 업데이트를 지정할 수 있습니다. 이는 RAS 필러의 사용성 요건의 일부입니다. 또한 RA는 관리 엔티티가 전체 노드의 상태(최소적으로 정상 또는 실패한 상태)를 확인할 수 있는 메커니즘을 구현해야 합니다. 일반적으로 이러한 알림은 I2C 또는 SMBus 인터페이스를 통해 액세스할 수 있으며 관리 컨트롤러로 라우팅됩니다. 이 기능은 운영 체제에 대한 인밴드 인터페이스에서도 사용할 수 있습니다. 이를 통해 상위 레벨의 소프트웨어가 관리 하위 시스템과 인터페이스할 수 있습니다. RA는 현장 수리 또는 제거할 수 있는 모든 구성 요소에 이 인터페이스를 통해 액세스할 수 있는 상태 표시가 있어야 한다고 권장합니다.

Security: 노드에는 검증을 위한 하드웨어 기반의 불변 신뢰 루트가 있어야 합니다. 이는 공항에서 통신할 수 있는 에이전트가 양호한 펌웨어에서 작동하도록 하기 위함입니다. 또한 RA는 노드의 소프트웨어 및 펌웨어에 대한 증명을 제공하기 위해 측정에 대한 하드웨어 기반 신뢰 루트를 권장합니다. TPM 또는 펌웨어 TPM이 전체 하드웨어 기반 신뢰 루트에 영향을 미치지 않는 경우 이 기능을 지원할 수 있습니다.

7.1.2.2 System View for Visual Security

이 섹션에서는 포그 시스템 뷰의 구성요소가 상호 작용하여 이 엔드 투 엔드 유즈케이스를 지원하는 방법을 설명합니다.

System View Hardware Virtualization: 시각적 보안 예제에 사용되는 포그 노드 계층의 하드웨어는 가상화 기술을 지원해야 합니다. 또한 애플리케이션은 다양한 프로세스가 호스팅되는 계층 수준에 의존하지 않아야 합니다. 네트워크 계층의 포그 노드가 오버로드되거나 다운되면 시스템 수준 조정은 동일한 수준 또는 인접 레벨의 인접 노드로 책임을 이동합니다. 포그 시스템의 효율성과 유연성을 극대화하려면 처리, 가속기, 스토리지 및 네트워킹 기능을 모두 가상화해야 합니다. 가상화는 하드웨어에서 실행되는 소프트웨어 계층에 따라 컨테이너화의 측면도 포함할 수 있습니다.

System View Management: 관리 시스템의 정교함은 사용의 단순성과 균형을 이루어야 합니다. RA는 시스템의 모든 요소에 대한 설치, 구성, 작업, 모니터링, 문제 해결, 수리, 확장 및 폐로에 대한 네트워크 수준의 엔드 투 엔드 뷰를 해결합니다. 시스템 수준 노드 관리는 특정 포그 인프라가 처리할 수 있는 노드의 복잡성을 최소화하기 위해 가능한 한 자동으로 이루어져야 합니다. 이를 통해 솔루션의 전반적인 확장성을 높일 수 있습니다.

추가 관리에는 모든 시스템 관리를 담당하는 상위 레벨의 하드웨어 관리자가 포함됩니다. 관리 시스템은 모든 카메라, 스토리지 및 기타 하드웨어 자산의 상태를 모니터링합니다. 이 관리 기능은 소프트웨어 백플레인과 연결하여 전체 시스템 관리를 충족합니다.

System View Security: 시스템 레벨에서, 계층 구조의 모든 포그 노드는 네트워크가 안전하게 유지되도록 협력해야 합니다. 여기에는 다음이 포함됩니다:

  • 계층 구조의 상위 레벨에있는 노드는 하위 레벨 노드의 기능을 모니터링하여 진행중인 보안 위협이나 응급 보안 위협이 없는지 확인해야합니다.
  • 동일한 계층 수준의 피어 노드는 보안 위협을 탐지하기 위해 이웃 라우터를 모니터링해야합니다.
  • 모든 node-to-thing 및 node-to-node 통신 링크는 암호화되어 의심스러운 트래픽을 모니터링해야 합니다.
  • 변조를 포함하여 물리적 보안도 모니터해야합니다.
  • 시스템이 변경되면 적절한 보안 조치가 실행될 수 있도록 관리 서브 시스템에 통지해야합니다.
  • 노드 간의 통신 경로는 암호화되어야 합니다.
  • 시각적 보안 시나리오에는 개인 식별 정보 (PII) 캡처 기능도 포함되어 있으므로 모든 데이터 캡처는 안심하고 암호화해야합니다. 여기에는 end-to-end 네트워크 보안이 포함됩니다.

System View Network: 비주얼 보안 아키텍처의 노드를 상호 연결하는 네트워크 링크는 여러 유형의 트래픽을 전송합니다.

  • 가장 낮은 레벨은 인접한 근접 포그 노드의 상호연결 입니다. 이 링크는 일반적으로 1Gbs 또는 10Gbs에서 작동하는 직접 지점 간 이더넷 링크입니다. 모든 노드에서 퓨전된 센서 판독값의 합성 사진을 함께 연결합니다. 예를 들어, 지정된 포그 노드의 모든 카메라 이미지를 인접 포그 노드에서 선택한 카메라 이미지 중 일부와 결합합니다.
  • 또 다른 유형의 상호 연결은 각 근접한 포그 노드와 이를 제공하는 두 번째 수준의 포그 노드 사이에 있습니다. 이러한 링크는 일반적으로 가까운 포그에 의해 추출된 상위 수준의 메시지와 분석 데이터를 전달합니다.
  • 다른 상호 연결 유형은 두 번째 레벨 포그 노드와 세 번째 레벨 노드 사이에 있다. 세 번째 레벨 포그 노드는 전체 시각적 보안 구현을 위한 마스터 컨트롤러 입니다. 중복 링크는 로드 밸런싱 및 내결함성을 위해 제공됩니다. 이러한 링크는 상당한 트래픽 대역폭을 전달할 수 있으며, 킬로미터 길이(일반적으로 광섬유를 통해) 동안 실행될 수 있습니다. 일반적으로 10GE 또는 100GE IP 연결입니다.
  • 마지막으로, 3 단계 포그 노드와 클라우드 백본 사이에는 일련의 링크가 있습니다.

System View Accelerators: 여기서 연구된 공항 시각 보안 시나리오에는 수십만 대의 카메라가 포함될 수 있습니다. 이 각각은 수많은 조건을 감지하기 위해 실시간으로 세심하게 분석해야 하는 영상을 생성합니다. 첫 번째 응답자가 거짓 경보와 함께 스윕을 하거나, 더 심각한 경우 경보를 생성해야 하는 일부 위협 시나리오가 누락되지 않도록 시각 보안을 위한 분석의 정확성이 매우 중요합니다. 컴퓨팅 가속기는 이러한 강력한 계산을 빠르고 에너지 효율적으로 만듭니다. 가까운 포그 노드의 가속기(예: FPGA)와 포그 계층의 두 번째 및 세 번째 수준의 가속기를 더 큰 설계에 사용해야 합니다. 3단계의 가속기는 이미지 훈련(계측 인식)에 사용될 수 있고 1단계 포그 노드의 가속기는 훈련된 모델에 대한 추론을 위해 사용될 수 있습니다.

System View Compute: 범용 연산은 시스템 뷰의 모든 수준에서 필수적입니다. 이러한 계산 리소스는 일반적으로 멀티 코어 프로세서이며, 때로는 계층의 상위 레벨에서 멀티 소켓 서버로 구성되기도 합니다. 비디오 집약적인 애플리케이션의 성능 병목 현상을 방지하려면 각 포그 노드에는 상당한 메모리(수십GB에서 수백GB)가 필요합니다. 다음과 같은 경우 시스템 수준 컴퓨팅 리소스가 필요합니다.

  • 가속기에서 더 효율적으로 실행할 수 없거나 단일 스레드 성능이 높은 태스크(예: 제어 알고리즘 및 사용자 인터페이스) 실행
  • 포그 시스템의 네트워킹 기능 관리
  • 번호판 인식 시나리오 통합.
  • 다음은 일반적으로 예제에서 가속기에 오프로드 되지만 참조용으로 여기에 보관됩니다.
    • Facial recognition (얼굴 인식)
    • People counting (사람 카운팅)
    • Threat detection (위협 감지)

System View Storage: 포그 계층의 모든 레벨에 스토리지가 필요할 것입니다. 시스템이 정상적으로 작동하는 동안 일부 시각적 데이터가 계층의 낮은 수준에서 상위 레벨로 전송되고 결국 클라우드로 전송됩니다.

가까운 엣지 포그 노드의 저장 공간은 약 24시간 분량의 고해상도 비디오를 로컬로 유지할 수 있도록 크기가 조정되어야 합니다. 약 8대의 4K 해상도 카메라가 있는 일반적인 포그 노드의 경우 카메라당 압축 데이터 속도가 10Mb/s라고 가정하면 1테라바이트 미만의 스토리지가 필요합니다. 참고: 포그 노드의 비 카메라 센서의 데이터는 스토리지 요구 사항에 크게 영향을 주지 않습니다. 이 스토리지는 다양한 방식으로 구현될 수 있습니다(이 캡처 요구 사항을 충족하는 NVR 솔루션이 있음). 그러나 스토리지는 한정되어 있으며 RA는 단기적으로 문제를 해결하는 동시에 오래된 데이터를 보존해야 하는 필요성을 균형 있게 유지합니다. 이 경우 사용자가 명시적으로 이 동작을 선택하면 새로운 용도로 이전 저장 장치를 회수하는 메커니즘을 사용할 수 있다고 생각합니다.

이전 데이터가 각각의 니어 에지 포그 노드에서 덮어 쓰기되기 전에, 낮은 해상도 (예 : 720P 또는 480P)로 변환하고 데이터를 두 번째 레벨 포그 노드로 전달하는 것이 좋습니다. 두 번째 레벨 포그 노드는 지원하는 모든 니어 에지 포그 노드에서 이러한 다운 샘플링 된 스트림을 받아 들여 30일 동안 저장합니다 (이 시나리오에서). 이는 약 20TB의 저장 공간 (모든 비디오 스트림을 1Mb/s로 다운 샘플링한다고 가정)을 필요로 할 수 있으며, 2 차 레벨 포그 노드가 회전 디스크 및 RAID 어레이 기술을 사용하여 훨씬 더 큰 스토리지 어레이를 가질 것을 요구합니다. 세 번째 수준의 포그 노드는 기본적으로 큰 서버이므로 큰 데이터 스타일 저장 전략이 필요할 것입니다. 이 오래된 데이터를 포크 속에서 유지하면 클라우드 전송 비용을 줄일 수 있다는 이점이 있습니다. 다운 샘플링 된 데이터를 전송하기로 결정하면 4K 또는 1080P 이미지를 전송해야하는 경우보다 운송 비용이 적습니다. 앞에서 설명한 것처럼 PII (개인 식별 정보)의 물리적 도난 및 절충으로부터 보호하기 위해 저장 장치의 "데이터는 안정적으로"데이터를 암호화해야 합니다.

System View Hardware Platform Infrastructure: 하드웨어 플랫폼 인프라는 섀시, 백플레인, 전원, 냉각 운영 체제 및 관리를 비롯하여 하드웨어 및 소프트웨어 모듈을 연결하여 특정 포그 노드의 기능을 사용자 정의하는 공통된 인프라 구성 요소 집합을 갖추고 있습니다. 그런 다음 동일한 인프라 요소를 사용하여 중요한 컴퓨팅, 네트워킹 또는 저장소 요구 사항없이 가볍게 채워진 노드를 생성 할 수 있습니다. 동일한 요소가 완전한 장비를 갖춘 포그 노드에서도 사용될 수 있습니다 (더 큰 응용 요구를 지원하는 계층 구조에서 더 높을 수도 있음).

System View Protocol Abstraction Layer: 프로토콜 추상화는 포그 네트워크가 센서 및 액추에이터 또는 클라우드에서 사용되는 특정 프로토콜과 독립적으로 작동 할 수있게합니다. 적응 로직 (하드웨어 및 소프트웨어 모두)은 포그 네트워크 외부에서 사용되는 원시 프로토콜을 포그 계층 내의 내부 표준 프로토콜, 저장 형식 및 데이터 추상화 모델로 변환합니다. 이러한 추상화는 포그 컴퓨팅이 end-to-end 공항 시각 보안 시나리오에 필요한 다양성을 쉽게 지원할 수 있는 이유 중 하나입니다.

System View Sensors, Actuators and Control: 위의 센서, 액추에이터 및 제어 섹션에서 설명한 바와 같이 공항 시각 보안 시나리오와 관련하여 매우 풍부한 센서 및 액추에이터 세트가 있습니다. 센서 융합 기술을 사용하여 포그 계층은 많은 센서의 입력을 공항의 위협 상황에 대한 일관된 관점으로 모으게 됩니다. 동등하게 중요한 포그 계산은 신속한 응답에 필요한 낮은 대기 시간을 제공합니다. 대기 시간은 성능 아래에 설명되어 있습니다.

System View Performance: 탐지 지연 및 위협 분석이 용인될 수 없기 때문에 낮은 대기 시간은 포그 컴퓨팅의 핵심 속성입니다. 이러한 낮은 대기 시간을 달성하기 위해 분석 알고리즘은 정확도, 객체 데이터베이스 크기, CPU 사용률, 에너지 효율성 등과 같은 요소와 관련된 중요한 성능 요구 사항을 갖습니다.

System View Scale: 이 예에서 묘사 된 공항은 24개의 게이트가 있는 적당한 크기입니다. 포그 네트워크는 변화하는 공항 요구 사항을 지원할 수 있도록 확장됩니다. 예:

  • 작은 공항에서 허브 공항으로 동일한 포그 네트워크 디자인을 확장 할 수 있습니다.
  • 새로운 알고리즘이 지속적으로 도입되어 추가 연산, 가속기, 네트워크 및 저장 기능이 필요합니다. 포그 아키텍처는 인프라의 완벽한 교체없이 대부분의 모듈을 업그레이드 할 수 있도록 설계되었습니다.
  • Fog as a Service (FaaS) 모델을 사용하여 포그 계층 구조는 단일 한 집주인이 소유 한 단일 계층 네트워크 (예 : 공항 당국)에서 폭넓게 필요한 다양한 입주자를 지원할 수 있도록 확장됩니다.
7.1.2.3 Software Infrastructure View for Visual Security

아래 그림에서 볼 수 있듯이 포그 노드의 소프트웨어는 세 개의 레이어로 분리 될 수 있습니다. 노드의 일반적인 작동과 관리 및 다른 노드/시스템과의 통신을 용이하게하는 기능은 백플레인 및 노드 관리 레이어에서 찾을 수 있습니다.

자체적으로 유즈케이스를 수행하지는 않지만, 여러 애플리케이션 서비스를 지원하고 지원하는 데 도움이되는 인프라 스트럭처 소프트웨어는 애플리케이션 지원 레이어에 있습니다.

다른 두 계층에서 제공하는 인프라에 종속 된 서비스는 이러한 시각적 보안 시나리오와 같은 특정 사용 사례 요구 사항을 충족하고 응용 프로그램 서비스 계층에 도메인별 요구 사항을 해결합니다.

7.1.3 Application to Airport Visual Security

이제 우리 솔루션에 적용되어야하는 아키텍처의 여러 측면을 분석 했으므로 요구 사항과 가정을 더 자세히 조사 할 것 입니다.

다음 그림은 시나리오에 대한 공항 터미널의 간단한보기를 제공합니다. 출입구, 주차 구조물, 보안 스테이션 등이 있습니다. 자동차가 공항 소유지에 입장 할 때 번호판 인식과 같은 다양한 용도의 다이어그램을 참조 할 것 입니다.

우리는 또한 각각의 공항과 계층의 여러 레벨에 여러 포그 노드를 배치 할 것입니다. 전체 공항을 담당하는 포그 노드 (fog node)가 있을 수 있으며 시각적 보안 위임을 달성하기위한 시스템 간의 상호 운용성을 보장 할 수 있습니다. 공항이 표준화 된 정보를 공유 할 수 있도록하는 것도 중요합니다. 또한 각 포그 노드는 계층 구조의 다른 레벨에 연결될 수 있습니다. 이러한 포그 노드는 시나리오의 요구 사항을 충족시키기 위해 함께 작동합니다.

우리는 다음을 포함하지만 이에 국한되지 않는 여러 영역을 다루고 있습니다.

  1. 자동차가 공항 소유지에 입장 할 때 번호판 인식.
  2. 여객의 도착/출발    a. 승객이 차량을 나와 공항 시설로 들어갈 수 있는 주차장 구조물.    b. 도착은 또한 승객들이 공항 시설에 들어갈 수있는 장소이기도합니다.
  3. 여객이 신분 확인 및 탑승권을 제공해야하는 승객 보안 심사.
  4. 선별 된 승객이 게이트, 상점에 걸어 가서 공항을 떠날 수있는 터미널.

승객이 공항을 떠날 때 비행기가 착륙하고있는 공항에서 정보를 이용할 수 있어야 합니다. 다음 그림에서 포그 노드가 계층 구조의 상위 레벨에 표시됩니다.

다음은 시나리오에서 전개 될 다양한 물리적 포그 노드에 대한 설명입니다.

  • 라이센스 플레이트 인식 (LPR)을 위한 포그 노드:   * 공항 속성을 둘러싼 포그 노드. 이 예에서는 카메라 및 보안 장치입니다. 이 노드들은 본질적으로 얇아서 인접 포그 노드에서 보고합니다. 우리는 하나의 포그 노드로 4개의 비디오 스트림을 서비스 할 수 있다고 추정합니다.
  • 주차 구조 및 도착역 주변에 주둔하는 포그 노드:   * 이 노드는 비디오 카메라로 구성되며 LPR의 경우와 마찬가지로 시각적 분석을 위해 카메라가 포그 노드에 연결됩니다.
  • 도착 및 출발 지역 (안보 검진 직전)에있는 포그 노드. 이들은 주차 구조와 동일합니다.
  • 심사 과정을 지원하는 포그 노드   * 이 포그 노드는 수동 RFID 리더기와 다른 센서 및 카메라에 모두 연결됩니다.
  • 터미널에있는 포그 노드   * 이 노드는 카메라 및 추가 센서에 연결됩니다.
  • 비행기로가는 승객의 출입구를 볼 수 있는 포그 노드.   * 이 노드는 카메라 및 추가 센서에 연결됩니다.
  • 포그 노드 그룹을 지원하고 모니터하는 계층 포그 노드.
    • 이 포그 노드는 사전 처리 된 데이터를 처리하고 공항의 안전과 보안에 대한 전반적인 사명을 지원하는 높은 수준의 기능을 수행합니다.

실현된 솔루션의 완전한 표현은 모든 노드에서 실행되는 상호 연결성, 보안 및 소프트웨어를 포함합니다.

7.1.3.1 Machine Vision for Visual Security

포그 컴퓨팅은 계층 구조의 적절한 수준에서 이미지를 처리하고 분석을 위해 클라우드로 이미지를 보내도록 지시합니다. 이 특정 시나리오에서 LPR, 승객 추적, 사람 카운트 및 기타 용도에 대한 머신 비전 요구 사항을 해결하기 위한 좋은 메커니즘은 CNN (Convolutional Neural Network)을 사용하는 것입니다.

CNN을 다룰 때 훈련 시스템과 분류 시스템에 대해 토론하는 것이 일반적입니다. 교육 시스템은 CNN 네트워크 토폴로지를 구축하고 이미지 분류가 검증되는 가중치를 계산하는 데 사용됩니다. 가중치 또는 미세 조정 가중치를 조정하는 이 반복 프로세스는 분류에서 만족 할만한 수준의 정확성을 얻을 때까지 계속됩니다. 만족스러운 수준의 정확도 (최소 98%의 정확도)를 얻으면 토폴로지와 해당 가중치를 모두 대상 또는 분류 시스템 (일명 추론 또는 채점)으로 푸시합니다. AlexNet은 객체 인식을 위한 잘 알려진 CNN이며 1,000 개의 다른 분류를 만들기 위해 120만 개의 교육 이미지 세트를 사용합니다. 주어진 분류 횟수에 필요한 이미지를 추정합니다. 이미지 수가 많을수록 항상 교육을받는 것이 좋습니다.

차량이 다양한 차선을 통과 할 때 LPR 카메라에는 LPR 카메라와 조명이 있어 번호판 이미지를 캡처하여 포그 노드로 보낼 수 있습니다. 이 부분에는 여러 옵션이 있습니다. 카메라는 네트워크의 가장자리에서 더 많은 작업을 수행하는 차량 및 번호판 사진을 캡처하여 전송하거나 전체 비디오 스트림을 압축하여 추가 분석을 위해 포그 노드로 보낼 수 있습니다.

LPR 포그 노드는 번호판 이미지에 대한 교육을 받게되며 번호판이 캡처되면 포그 노드는 1) 지역화 2) 문자 세분화 및 3) 광학 문자 인식 (OCR)을 수행하여 번호판 상태를 결정합니다.

승객 인식은 훈련 시스템을 사용하여 이미지 데이터베이스를 기반으로 한 모델을 훈련시키는 것과 유사한 흐름을 따른다. 승객과 차량 모델은 새로운 분류되지 않은 이미지를 기반으로 빈번하게 업데이트되어야 시스템이 시간이지나면서 배우고 전반적인 정확도가 향상됩니다.

다음 다이어그램은 다양한 기관과 개인 회사간에 다양한 정보를 공유하는 방법에 대한 몇 가지 가정을 보여줍니다. 이것은 실제 시나리오의 단순화이지만 정보를 안전하게 공유 할 수있는 최적 시스템의 기본 요구 사항을 제공합니다.

7.1.3.2 Airport Passenger

흐름을 단순화하기 위해 이전에 보여준 교통 수단을 이용하여 공항을 이용하는 승객의 표준 사례부터 시작하겠습니다.

승객은 집을 떠나 공항으로 갑니다.

공항에 오는 차량을 감시하는 각 카메라 그룹과 관련된 포그 노드가 있습니다. 이 노드는 자동차 번호판 이미지 캡처, 비디오 분석 수행 및 드라이버가 공항 속성에 진입 할 때 운전자의 얼굴 캡처를 담당합니다. 포그 노드는 또한 RFID 판독기 및 기타 데이터 수집 장치 및 센서와 직접 인터페이스 할 수 있어 차량의 사람과 물체를 로컬에서 고성능으로 식별 할 수 있어야 합니다.

  • 데이터 보안 및 개인 정보 보호 문제는 네트워크 전체에서 해결됩니다. 카메라 펌웨어는 검증 및 선택적으로 측정을 위해 하드웨어 기반 신뢰 트러스트로 보호됩니다. 이렇게하면 처리 된 이미지가 알려진 구성에서 작동 중이며 변경되지 않은 하드웨어에서 가져옵니다.
  • 카메라에 저장된 시각적 이미지에 대한 개인 정보 보호 문제는 실제 저장된 상태에서도 모든 저장된 데이터가 검사되지 않도록 보호해야 합니다. 이 보호는 사람들의 이미지를 저장하는 데 사용되는 모든 데이터 링크 및 저장소에서 강력한 암호화를 사용합니다. 그것은 휴식과 운송 중에 암호화되어야 합니다.
  • 도난당한 차량이나 의심스러운 차량이 공항에 도착했을 때이를 감지하면 당국에 통보해야합니다.
  • 정확하게 탐지할 수 없는 이미지는 저장되어 재교육에 사용되어야 합니다.
장기 주차장의 승객 주차.

여객이 주차 차고를 모으는 차고 문 입구에서 카메라는이 End-to-End 시나리오에서 첫 번째 이미지와 영구 데이터 객체를 포착합니다. 다음 그림은 이 위협 시나리오에 유용한 정보를 수집하는 소프트웨어 응용 프로그램 및 에지 장치를 보여줍니다.

포그 노드 하드웨어 및 소프트웨어는 카메라 피드에서 비디오 분석을 수행합니다. 여기에는 계층의 포그 노드의 여러 계층으로 분할 될 수있는 이미지 처리 파이프 라인 또는로드 균형을 조정하는 여러 피어 노드가 포함됩니다. 포그 네트워크는 이미지를 처리하고 특정 사람이나 사물을 인식합니다. 예를 들어, "불량 차량" 목록에 있는 번호판이 감지되면 시스템은 이를 2초 미만의 지연 시간으로 발견하고 해당 정보를 트래픽 게이트를 제어하는 데 사용할 수 있습니다 (지연없이). 마찬가지로, 포그 네트워크는 안면 인식을 수행하고 비행 금지 목록에서 사람들을 탐지 할 수 있습니다. 대기 시간이 낮고 (자동 개찰기를 사용하는 등) 포그 노드의 로컬 처리 및 저장으로 승객의 개인 정보를 보호 할 수 있으므로 포그는 이 경우에 유용합니다.

포그 네트워크는 물체 (예 : 버려진 수하물)를 감지하여 신속하고 안전하게 대응할 수 있습니다.

이미지 프로세싱 파이프 라인은 포그의 분산 분석 기능의 예이며, 위 그림에 표시된 여러 단계의 카메라 이미지를 처리하고 아래에서 자세히 설명합니다.

  • Data Filter: 원시 센서 데이터를 캡처하는 다양한 포그 노드에서 들어오는 데이터를 정리하고 필터링합니다.
  • Anomaly Detection (기계 학습): 다양한 유형의 이상을 감지하고 비공식적으로 위험 평가 시스템에 제공하는 모델을 생성합니다. 예를 들어, 비행 금지 목록에 있는 사람을 발견하거나 포기한 수하물
  • 중요 이벤트 프로세서 (Critical Event Processor): 들어오는 데이터 플래그 이벤트를 모니터링하고 (포그 네트워크에 저장된 공항 정책에 따라) 중요한 이벤트를 모니터링하고 이를 Risk Scoring System으로 전달하는 규칙 엔진.
  • Risk Scoring System: 시스템에 알려진 차량, 승객, 수하물 또는 기타 단체에 대한 위험 점수를 생성합니다. 고위험 목표를 Decision Support System에 전달합니다.
  • Decision Support System: 위험 점수 시스템에서 고위험 대상을 받습니다. 자동으로 작업을 수행하거나 경고를 발생시킵니다.
  • 작동 액추에이터 (예 : 주차장 게이트, 개찰구, 경보 등).
  • 머신 비전에 대한 이전 섹션에서 설명한 에지 알고리즘을위한 교육 시스템.
상영 구역으로가는 도중에서 도착하는 사람을 입력하십시오.

공항 출입구에서 보안 시스템은 차를 세우고 사람들이 차에서 내리고 가방을 움켜 쥐고 공항에 들어가는 여러 대의 카메라가 있어야 합니다. 승객이 차를 주차하고 선발 지역으로 이동 한 후에도 가능합니다. 이 단계의 주요 특징은 승객 추적, 공항에서 공항으로, 공항 출발 지역을 거쳐 수하물 체크인까지 모든 것입니다. 로컬 포그 노드가이 단계를 효율적으로 구현하기 위해 센서 융합 및 데이터 검사/상관 관계를 수행하는 방법에 주목하십시오.

입구의 소프트웨어 구성 요소는 주차장 소프트웨어와 겹치는 부분이 많습니다. 그러나 더 많은 카메라가 있기 때문에 캡처 구성 요소의 인스턴스가 더 많습니다. 결과적으로 포그 노드 처리가 여기에서 훨씬 높습니다.

또한, 우리는 새로운 차량을 보았으므로 나쁜 차량 시스템을 재사용 할 것입니다. 승객이 차고에서 출입구로 갈수록, 얼굴 캡처 및 수하물 캡처 구성 요소는 소프트웨어 백플레인 및 관련 데이터 공유 소프트웨어 서비스를 통해 가입을 통해 얼굴 및 수하물 데이터 객체의 업데이트를 수신하게됩니다. 이러한 소프트웨어 구성 요소 각각의 여러 인스턴스가 소프트웨어 백플레인에서 지원됩니다. 포그 시스템의 민첩성은 이러한 종류의 재사용/다중 사용을 가능하게 합니다.

정교한 분석 시스템은 포그 계층에 의해 수집 된 모든 정보를 처리하고 이를 정상화 한 다음 추가 처리를 위해 계층의 상위 수준으로 보냅니다. 이러한 분석 알고리즘은 기계 학습 기술을 사용하여 끊임없이 변화하는 조건 및 위협 모델에 지속적으로 적응할 수 있습니다. 계층 구조의 각 레벨은 카메라 및 기타 센서의 입력을 공항에 대한 전체론적 관점으로 결합하고 더 집중된 형태로 보기를 더 소화시켜 궁극적으로 공항 보안 정책이 될 수있는 상위 레벨로 보내집니다. (차량이나 사람이 장벽을 통과하는 것을 거부하는 것과 같은) 필요한 모든 시행 조치가 수행됩니다. 이것은 처리 된 데이터가 지혜가되는 방식입니다.

노드에서 시각적 분석을 수행한 후 운전자, 자동차 상태 및 비행 상태에 대해 알게 된 정보를 교차 점검하고이 정보를 패키징하여 다음 단계에서보다 자세한 처리를 할 수 있습니다. 포그 네트워크는 보안 인원에게 경보가 필요한지 여부를 결정할 수 있습니다.

승객은 공항 보안 검색 대에 가방을 가져갑니다.

승객이 공항 소유지에 들어오는 동안 내내 얻은 다양한 정보가 모두 들어있는 데이터베이스를 만들어야 합니다. 여기에는 LPR 정보, 승용차 및 관련 인물의 이미지가 포함됩니다. 포그 네트워크는 이전에 처리 된 이미지 및 데이터베이스 항목에 수하물 영역, 얼굴 인식 및이 승객과 관련된 가방 스캔, 업데이트 된 티켓 정보 등과 같은 기타 데이터의 새로운 감시 이미지를 추가합니다.이 추가 정보를 사용하여 포그 네트워크 분석은 승객이 어디로 가야하는지 예측할 수 있고, 가방이 보이지 않는 곳에 인식되면 언제든지 연관 시키거나 다른 위험을 행동, 외모 등과 연관시킬 수 있습니다. 다양한 보안 카메라 이미지와 다양한 기타 출력 센서와 승객에 대한 정보의 데이터베이스는 포그의 고급 센서 융합 기능의 예입니다.

  • 위의 그림은 주차 공간에서 설명한 것과 유사한 기술을 사용하여 수하물 체크인 절차를 관리하는 포그 응용 프로그램의 소프트웨어 구성 요소 중 일부를 보여줍니다.
  • Vehicle Capture: 카메라 이미지를 라이센스 정보, 모델/모델 정보, 주차 장소로 변환하고 차고 문을 통해 들어온 차량의 고유 한 식별자로이 정보를 쌍으로 만듭니다. 다른 시스템이 id를 기반으로 raw 이미지를 요청할 수 있도록 API를 제공합니다.
  • 얼굴 캡처 (Facial capture): 카메라 이미지를 고유한 사람 식별자로 변환합니다. 다른 시스템이 id를 기반으로 raw 이미지를 요청할 수 있도록 API를 제공합니다.
  • 수하물 캡처 (Baggage capture): 카메라 이미지를 고유한 수하물 식별자로 변환합니다. 다른 시스템이 id를 기반으로 raw 이미지를 요청할 수 있도록 API를 제공합니다.
  • 데이터 퓨전 (Data Fusion): 차량 식별자를 주차 장소에 연결합니다. 사람을 차량 식별자에 연결합니다. 수하물 식별자를 사람 식별자에 연결합니다.
  • 검사기 (Checker): 나쁜 승객 이미지에 대한 얼굴 캡처 데이터 일치 시도
  • Alerter: 중앙 추적 시스템에 감지 된 가능한 문제를 알리는 책임이 있습니다.
  • 나쁜 승객 시스템 (Bad Passenger System): 당국 및 사람들이 비공개 목록, 체포 영장 등에서 감시하는 사람의 등록
  • 이 시스템의 데이터는 로컬에 보관되며 정기적으로 업데이트 됩니다.
가방을 스캔하고 체크인합니다.

카메라가 승객의 새로운 위치를 선택합니다. 수하물 정보가 업데이트되어 데이터베이스 레코드 항목에 추가됩니다. 이 데이터는 위험 분석을 위해 시스템의 다른 부분에있는 다양한 소프트웨어 구성 요소에 게시됩니다.

  • 그림은 수하물 검사 과정을 보여줍니다. 다수의 로컬 포그 노드는 각 보안 라인을 지원하며, 그 수는 컴퓨팅 요구에 따라 확장 가능합니다. 카메라, 밀리미터 파 머신 및 폭탄 센서 (스니퍼) 출력을 포함한 다양한 센서가 이전 단계의 모든 상황과 결합되어 매우 효과적인 검진 프로세스를 제공합니다.

이 단계에서 사용 된 구성 요소 중 일부는 다음과 같습니다.

  • Bomb Sensor (폭탄 센서): 폭탄 스니퍼 (bomb sniffer)로부터 데이터를 수집하고 상관 관계 및 결과적으로 모든 이벤트를 Data Fusion 시스템으로 전달합니다.
  • Facial Capture (얼굴 캡처): 카메라 이미지를 고유 한 사람 식별자로 변환합니다. 다른 시스템이 id를 기반으로 raw 이미지를 요청할 수 있도록 API를 제공합니다.
  • Mm Wave Screen: mm Wave Machine에서 데이터를 수집하고 이미지를 스캔하여 문제를 조사하고, 공항 스크리너에게 추가 검사를 알리고 상관 관계 분석 및 최종 조치를 위해 모든 이벤트를 Data Fusion 시스템에 전달합니다.
  • Behavior Monitor (행동 모니터): 다양한 카메라 피드를 사용하여 대기중인 사람들의 나쁜 행동을 모니터링합니다. 얼굴 및 승객 데이터와의 상관 관계 분석을 위해 모든 이벤트가 Data Fusion 시스템에 전달됩니다.
  • Baggage Capture (수하물 캡처): 카메라 이미지를 고유 한 수하물 식별자로 변환합니다. 다른 시스템이 ID를 기반으로 원시 이미지를 요청할 수 있도록 API를 제공합니다.
  • Data Fusion (데이터 퓨전): Baggage Capture, Behavior Monitor, Mm Wave Screen 알림 및 bomb sniffer 알림 근접과 관련된 승객을 연결합니다.
  • Checker (검수원) : Facial Capture 데이터와 Bad Passenger System 이미지를 대조하고 센서 시스템에서 경고를 전달합니다.
  • Alerter : 중앙 집중식 추적 시스템에 가능한 문제를 알릴 책임이 있습니다.
  • Bad Passenger System (나쁜 승객 시스템): 당국 또는 승객들의 비공개 목록, 체포 영장 등에서 감시하는 사람들의 등록. 이 시스템의 데이터는 현지에서 열리고 정기적으로 업데이트됩니다.
보안을 통해 체크인하고 탑승구로 가십시오.

이 단계에서 데이터 분석은 다양한 포그 노드로부터 충분한 정보를 생성해야합니다. 즉, 카메라 및 센서의 원시 데이터가 포그 네트워크에 의해 정보가 되는 단계를 거쳐 변환되고 이제는 승객은 수하물을 통제하고 보안 심사 정책에 따라 분석되었습니다. 포그 네트워크는 이제 승객과 관련된 신뢰할 수있는 위협이 있는지 자율적으로 판단 할 수 있습니다. 이 전체 과정은 수 밀리 초가 소요되며 몇 초가 걸리지 않습니다. 즉, 승객이 비행기에 입장 할 수 있도록 결정을 내리고 탑승원이 항상 소유하고 있음을 확인하고 비행기가 탑승 할 수 있도록 게이트 운영자에게 통보해야합니다.

시스템은 조종사에게 경보를 발령하거나 미래의 시나리오에서 자율적 계획을 탈피할 필요가 있습니다. 이는 포그 속에서 수행되는 전체 분석을 토대로합니다. 승객이 최소한의 위협을 가할 것으로 결정되면, 그의 경로에있는 모든 장벽이 1초 미만의 대기 시간으로 열리며 지체없이 비행기에 탑승 할 수 있습니다. 그가 위협을 가하기로 결정되면 몇 단계의 단계적 확대가 가능합니다. 시스템은 공항 당국에 경고 할 수 있습니다 (중앙 보안 통제 또는 육체적으로 밥에게 가장 가까운 경찰을 찾아 알려서). 회전 목마나 맘 트랩을 통과 할 수 있는 장벽이 그를 잡을 수 있습니다. 포그에 의해 탐지 된 치료 수준 및 공항 정책에 따라 다른 많은 완전 자동 또는 반자동 응답이 가능합니다.

  • 위의 그림은 Bob이 비행기 여행을 하면서 포그 네트워크가 걸리는 몇 가지 단계를 설명합니다.

시스템 구성 요소

  • Facial Capture (얼굴 캡처): 카메라 이미지를 고유 한 사람 식별자로 변환합니다. 다른 시스템이 ID를 기반으로 원시 이미지를 요청할 수있는 API를 제공합니다.
  • Behavior Monitor (동작 모니터): 다양한 카메라 피드를 사용하여 불량 행동을 모니터링합니다. 플래그를 올리는 모든 액션은 안면 및 승객 데이터와의 상관 관계를 위해 Data Fusion으로 전달됩니다.
  • Baggage Capture (수하물 캡처): 카메라 이미지를 고유 한 수하물 식별자로 변환합니다. 다른 시스템이 ID를 기반으로 원시 이미지를 요청할 수있는 API를 제공합니다.
  • Tarmac Capture: 항공기 및 활주로에서 비정상적인 행동, 보안 위반 및 항공기 손상 가능성을 모니터링하기 위해 다양한 카메라 피드를 사용합니다.
  • Data Fusion (데이터 퓨전): 수하물 및 행동 알림으로 게이트 영역의 승객을 (얼굴 인식으로) 연관시킵니다.
  • Airline Passenger Manifest System : 비행기 탑승 전 승객에 대한 데이터를 제공합니다.
  • Airline Passenger Baggage System (항공사 여객 수하물 시스템): 승객 수하물에 대한 데이터를 제공합니다.
  • Checker (검사기): 최종 조립 및 모든 사용 가능한 시스템 원본의 데이터 상관 관계.
    • 승객은 제공된 자격증 명과 일치하는 것으로 보이며 시스템을 입력 한 후 캡처 한 이미지와 일치합니다.
    • 승객 수하물은 시스템에 들어간 이후에 수거 된 수하물과 일치하며 일관되게 일치합니다.
    • 항공기가 위조 된 것으로 보이지 않습니다.
    • 승객이 공항 공간에 입장 한 이후 다른 시스템에서 경고 또는 문제를 발견하지 못했습니다.
  • Export: 모든 관련 승객 데이터를 목적지로 전송하는 책임 중앙 추적 시스템
  • Alerter: 중앙 집중식 추적 시스템에 감지 된 신호 문제에 대한 책임이 있습니다.
도착하면 가방을 꺼내십시오.

도착 공항의 보안 카메라에는 승객에 대한 데이터가 있습니다. 도착 게이트와 마찬가지로 일찍이 포그 컴퓨팅 네트워크는 승객이 도착했는지 여부를 판단하여 수하물을 회수합니다.

  • 승객이 목적지에 도착하면 도착 과정의 역순으로 진행되며, 위 그림에서와 같이 포그 기반 프로세스 중 많은 부분이 안전을 보장합니다.

프로세스 구성 요소에는 다음이 포함됩니다.

  • Facial Capture (얼굴 캡처): 카메라 이미지를 고유 한 사람 식별자로 변환합니다. 다른 시스템이 ID를 기반으로 원시 이미지를 요청할 수있는 API를 제공합니다.
  • Behavior Monitor (동작 모니터): 다양한 카메라 피드를 사용하여 비정상적인 동작을 모니터링합니다. 얼굴 및 승객 데이터와의 상관 관계 분석을 위해 모든 이벤트가 Data Fusion 시스템에 전달됩니다.
  • Baggage Capture (수하물 캡처): 카메라 이미지를 고유 한 수하물 식별자로 변환합니다. 다른 시스템이 ID를 기반으로 원시 이미지를 요청할 수있는 API를 제공합니다.
  • Data Fusion (데이터 퓨전): 수하물 및 행동 알림으로 게이트 영역의 승객을 (얼굴 인식으로) 연관시킵니다.
  • Checker (체커): 얼굴 수집 및 수하물 캡처 최종 데이터를 출발 공항에서받은 수신 (Import) 승객 데이터와 연관시킵니다. 원래 항공기에 탑승 한 모든 승객이 항공기를 빠져 나갈 것을 보장하고 모든 예상 수하물도 항공기에서 나옵니다.
  • Import: 출발지 중앙 추적/실행 시스템에서 목적지 중앙 추적/실행 시스템으로 모든 관련 승객 데이터를 수신하는 책임이 있음
  • Alerter: 중앙 집중식 추적 시스템에 감지 된 신호 문제에 대한 책임이 있습니다.

이 과정에서 공항 안의 많은 포그 노드와 서로 다른 두 공항의 포그 네트워크는 높은 성능과 높은 보안성을 가진 fog node-fog node 통신을 유지해야합니다. 이는 모든 노드의 보안성이 매우 높은 포그 인프라와 모든 node-node 트래픽에 강력한 암호화가 적용되었기 때문에 가능합니다.

렌트카 대행사에 계속 진행하십시오. 공항 출입 (허가 된 경우)

수집 된 데이터는 상호 운용성을 필요로 하므로 각 노드가 보다 높은 수준의 통찰력을 발휘하여 보호 할 수 있습니다. 많은 경우 승객의 여정을 통해 얻은이 데이터를 지방 정부 기관과 공유하여 가석방중인 경우 일정 기간 동안만 해당 국가에 체류 할 수 있는지 여부를 추적 할 수 있습니다. 렌트카 회사는 도착한 공항의 포그 시스템과 정보가 선택적으로 공유되기 때문에 위험도가 적습니다.

  • 승객의 여행에 관한 위의 시나리오는 포그의 주요 특성 중 일부를 보여줍니다. 포그의 분산 처리 기능과 계층 구조는 복잡한 분석 및 센서 융합 알고리즘을 지원하여 모양과 동작을 분석합니다. 포그의 대기 시간이 짧기 때문에 자신의 행동에 거의 즉각적으로 반응 할 수 있습니다 (예: 밀리 초 단위의 장벽 열기, 동일한 정교함의 클라우드 기반 처리가 몇 초 걸릴 수 있음). OpenFog 구현의 안전성이 높기 때문에 승객의 프라이버시가 유지되고 시스템 계층의 상위 레벨까지 가시성이 제한됩니다. 포그의 신뢰성은 포그 노드, 노드 간 링크 또는 클라우드에 대한 연결이 끊어 지더라도 시스템이 계속 작동 할 수 있게합니다. 포그의 대역폭 효율성은 비디오처럼 높은 대역폭 트래픽이 가장 유능한 링크만 트래버스하도록 보장합니다.

공항 시각 보안 시나리오에 적용된 이 상세한 사례는 OpenFog Reference Architecture의 주요 이점을 설명하기 위한 것입니다. 이는 유사한 도전 과제를 해결하기 위해 유사한 개념과 기법으로 포그 컴퓨팅을 적용하는 사람들을 위한 참고 자료로 사용하기 위한 것입니다.

8 Additional Opportunities

OpenFog 컨소시엄은 학계/연구 기관 및 산업 회원 들간에 긴밀하게 협력하고 있습니다. 이를 통해 컨소시엄은 학계의 연구 및 출판 포커스를 업계의 비즈니스 요구 사항과 함께 활용할 수 있습니다. 포그 컴퓨팅 연구의 추가 영역은 다음과 같습니다.

  • 포그와 클라우드 컴퓨팅 사이의 상호 작용 : 동적이고 안전한 이동 및 자원 공유.
  • 산업 협회의 기존 노력이 보장하지 않는 보안 개선.
  • 포그 컴퓨팅의 심화 된 관리 및 조정을 위해 향상된 기능이 필요합니다.
  • 클라우드를 필요로하지 않고 학습을 지원하는 포그 기반 교육.
  • Fog as a Service (FaaS) 모델의 전체 개발.
  • 아키텍터와 설계자가 주어진 구현 시나리오에 적합한 QoS를 달성하는지 확인하기위한 성능 모델링 및 측정.
  • 상호 운용성 향상을 위한 엄격한 요구 사항을 생성합니다.
  • 소프트웨어 정의로 구성된 포그 컴퓨팅의 자율적인 자치.
  • 보다 최적화 된 컴퓨팅 환경의 환경 영향.
  • 포그 아키텍쳐의 구현을 구체화하는 데 도움이 될 새로운 엔지니어 및 과학자를 위한 교육, 연구 및 개발 이것은 포그 컴퓨팅을 위한 소프트웨어 개발을 포함 할 것입니다.

9 Summary and Next Steps

OpenFog Reference Architecture (OpenFog RA)는 포그 컴퓨팅을 위한 개방적이고 상호 운용 가능한 아키텍처를 개발하는 기본 문서입니다. IoT, 5G, 인공 지능, 촉각 인터넷, 가상 현실 및 기타 복잡한 데이터 및 네트워크 집약적 응용 프로그램에서 상호 운용성을 가능하게하는 새로운 업계 표준을 만드는 첫 번째 단계입니다.

OpenFog RA는 스마트 도시, 스마트 에너지, 스마트 운송, 스마트 건강 관리 및 스마트 제조 분야의 고급 배치를 가속화하기 위한 협업, 개방 및 상호 작용 포그 시스템에 대한 업계의 약속을 나타냅니다. 8 개의 필러은 포그 공급 체인의 모든 부분에 대한 요구 사항을 설명합니다: 구성 요소 제조업체, 시스템 공급 업체, 소프트웨어 공급 업체, 응용 프로그램 개발자. OpenFog 컨소시엄은 개방형 아키텍처가 없으면 상호 운용성, 신뢰성 및 보안이 제한되어 채택이 늦어지고 기능이 제한 될 것이라고 생각합니다.

OpenFog Reference Architecture는 포그 컴퓨팅을 위한 업계 표준을 만드는 첫 번째 단계입니다. 오픈 포그 컨소시엄 (OpenFog Consortium)은 권장 표준에 대한 IEEE와 같은 표준기구의 세부 지침을 설정하고, 내년에 참조 아키텍처에서 주요 인터페이스에 대한 API를 지정합니다. 우리의 기술 커뮤니티는 후속 사양 모음, 아키텍처를 증명하는 테스트 베드 및 구성 요소 수준의 상호 운용성을 위한 새로운 사용 사례를 연구하고 있습니다. 결국,이 작업은 OpenFog Reference Architecture에 기반한 업계 요소 및 시스템의 인증으로 이어질 것입니다.

OpenFog 컨소시엄의 활동에 대한 자세한 내용은 www.OpenFogConsortium.org 를 방문하십시오.

10 Appendix – Deeper Security Analysis

이 부록에는 현재 OpenFog 컴퓨팅 환경에서 여러 가지 보안 측면에 대한 초기 논의가 포함되어 있습니다. 이 중요한 토론은 몇 가지 이유로 여기에 두었습니다. 첫째, 보안은 중요한 IoT 시스템 중 가장 큰 기술적 우려 일 것입니다. 따라서 우리는이 문서의 특별한 절에서이 문제를 논의하기를 원했습니다. 둘째, 토론에는 고도로 전문화 된 기술 세부 사항이 포함되어 있습니다.이 세부 사항은 문서 본문에 포함 된 경우 가독성에 영향을 줄 수 있습니다. 따라서 우리는 보안 전문가에게 가장 관심이있는 자료를 한 곳에서 수집하기로 결정했습니다.

향후 버전의 참조 아키텍처에는 성능, 관리 효율성, 데이터 분석 및 유사한 수준의 제어와 같은 아키텍처 설명의 다른 중요한 우선 순위 교차 설명 관점을 설명하는 부록이 포함됩니다.

10.1 Security Aspects

보안은 포그 컴퓨팅에 있어 중요한 관심사입니다. 기본적인 상호 운용성과 보호를 보장하기위한 공통의 보안 기준이 있어야한다고 강력히 믿습니다. 포그 컴퓨팅이 만족시켜야하는 지역 및 정부 요구 사항의 조합이 존재한다는 사실을 알고 있습니다. 다음 섹션에서는 오픈 포그 아키텍처의 보안 영역에서 통일 된 실행을 시도하면서 접근 방식의 다양성을 수용하기위한 예비 시도에 대해 설명합니다.

10.1.1 Cryptographic Functions

암호화는 기밀성, 무결성, 인증 및 부인 방지와 같은 보안 서비스를 구현하기위한 메커니즘을 제공합니다. 암호화 기능은 플랫폼 보안 프로세서 (PSP)에서 구현되어 암호화 키와 보안 정책을 보호 할 수 있습니다. 그러면 보안 키는 다른 개체를 보호합니다. 또한 암호화 기능을 사용하여 신뢰할 수있는 소프트웨어의 안전한 실행 환경을 제공하고 메모리, 저장소 및 통신을 보호 할 수 있습니다.

이 문서의 현재 버전은 모든 OpenFog 노드에서 사용할 수 있어야 하는 필수 표준 암호화 알고리즘의 초기 기본 목록을 설명합니다. 이 최소 집합의 알고리즘을 요구하는 것은 OpenFog 노드 간의 상호 운용성을 보장하기 위한 것입니다. 우리는 이 초기 목록이 전세계적인 상호 운용성을 가능케하는 능력면에서 제한적이라는 것을 알고 있습니다. 앞으로 OpenFog는 유럽, 중국, 일본, 미국 등 지역 표준 기관의 표준 알고리즘 집합을 포함하는보다 완벽한 목록을 개발하는 것을 우선 과제로 삼고 있습니다.

암호화 기능에는 세 가지 기본 유형이 있습니다.

  • 기밀 보호를위한 대칭 (또는 비밀 키) 암호;
  • 통신 당사자의 무결성 보호 및 인증을위한 암호화 해시 기능
  • 비밀 키 생성, 장기 보안 자격 증명 설정 및 부인 방지 서비스 제공을 위한 비대칭 (또는 공개 키) 암호.

NIST FIPS 140-2 명세 [ref-a]는 암호 모듈에 대한 보안 요구 사항을 정의합니다. 이 규격은 승인 된 암호 기능 목록과 규격에 부합하는 기능 수행을 검증하기위한 공식적인 절차를 다룬다. OpenFog Reference Architecture는 그 구성 요소 간의 기본 상호 운영성을 보장하기 위해 FIPS 140-2 승인 된 암호화 기능의 하위 집합을 채택합니다. 암호화 모듈의 공식 인증 (즉, FIPS 140-2 인증)은 각 공급 업체의 옵션으로 남겨 둡니다. FIPS 140-2의 중요성이 커짐에 따라 공급 업체는 자사 제품을 FIPS 140-2 인증을 받도록 권장합니다.

OpenFog 암호화 모듈은 최소한 다음 FIPS 승인 암호화 기능을 지원해야합니다 (MUST).

  • 대칭 키 암호    * AES (최소 128 비트 키 포함)    * 트리플 DES
  • 비대칭 키 암호
    • Z𝑝, Z𝑛* 기반 : DH, RSA, DSA
    • 타원 곡선 기반 : ECDH, ECDSA, ECQV
  • 암호화 해시 함수
    • SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256
  • 난수 생성기
    • 부록 C: FIPS PUB 140-2에 대한 승인 난수 생성기, 암호화 모듈에 대한 보안 요구 사항
  • 메시지 인증 코드
    • CCM, GCM, GMAC, CMAC, HMAC

FIPS 140-2 [ref-b]의 부록 A에 정의 된대로, 사용중인 암호화 알고리즘의 성공적인 차단 또는보다 강력한 컴퓨팅 기술의 이용 가능성으로 인해 NIST는 승인 된 암호화 기능 목록을 업데이트하는 지침을 제공합니다. 최신 지침에 대해서는 NIST의 "암호 알고리즘 및 키 길이의 사용을 전환하는 권장 사항" [ref-c]를 참조하십시오. 이 문서의 후속 버전에서는 모든 지역 암호화 알고리즘에서 작동하는 전환 방법을 고려합니다.

Note: 규정 준수는 보안이 아닙니다. FIPS에서 승인 한 암호화 기능 중 일부는 강도가 약한 것으로 간주 될 수 있으며 구현을 잠재적 위험에 노출되도록 남겨 둘 수 있습니다. 다양한 OpenFog 구성 요소의 설계에서, 구현을 위해 선택된 암호화 기능은 그들의 사용과 이해 관계자의 위협 평가에서 발견 된 결과와 일치하여야한다.

10.1.1.1 Crypto Accelerators

암호화 기능은 소프트웨어 또는 하드웨어 가속기에서 구현할 수 있습니다. 이러한 하드웨어 가속기는 시스템에 중요한 보안 기능을 제공하지만 장치 자체도 안전해야 합니다. 가상 환경에서 구현되는 경우 하드웨어 가상화 장치로 구현해야 각 가상 인스턴스에 고유 한 컨텍스트를 유지하면서 각 독립 실행 프로세스 및 VM에서 안전하게 액세스 할 수 있어야하며 각 주소 공간에 대한 액세스 보호를 제공해야 합니다 가상 인터페이스를 "소유" 합니다.

많은 플랫폼이 일종의 하드웨어 보안 프로세서 (예: TPM, PSP, 각 코어의 안전한 신뢰할 수있는 실행 모드)를 구현합니다. PSP 하드웨어는 본질적으로 플랫폼에 의해 신뢰됩니다. 이 보안 프로세서는 일반적으로 특정 작업을 수행하라는 요청 (예: 나중에 조회 할 수 있도록 측정 된 부팅 순서에 대한 기록 저장, 비대칭 또는 대칭 키 지정 자료의 안전한 저장 공간 제공, 주요 액세스 보호 제공, 암호화 및 해독 제공)에 응답합니다. 적은 양의 보안 자료, 내부의 TRD (True Random Number Generator) 등을 제공합니다. 그러나 이러한 보안 프로세서는 일반적으로 가상화되지 않으므로 가상 시스템에서 실행되는 OS에서 액세스 할 수 없습니다. 일반적으로 보안 프로세서는 OS와 일대일 관계를 맺습니다 (예: TPM은 단일 소유자 만 제공하며, 단일 스토리지 루트 키 및 패스워드, 단일 보증 키 및 단일 PCR 세트)를 사용하여 가상 환경의 하이퍼 바이저에서만 보안 프로세서 기능을 사용할 수 있습니다. 즉, 가상 시스템에서 실행중인 OS가 베어 메탈 환경에서 실행되는 보안 프로세서의 보안 스토리지 및 암호화 기능을 사용할 수는 있지만 이를 수행 할 수는 없습니다.

이에 대한 해결책은 가상 시스템의 많은 수 (설계보다는 사용 가능한 리소스로 제한되는 것이 바람직 함)가 가상 시스템과의 일대일 관계를 유지하도록 허용하는 가상 보안 프로세서 (예 : vTPM, vPSP)의 구현에 있습니다. 가상 플랫폼 보안 프로세서 (vPSP)가 할당됩니다. vPSP의 가상 구현은 VM과 PSP 모두가 가상화를 인식하지 못하도록하며 가상화 되지 않은 환경에서처럼 VM과 PSP를 모두보고 작동 할 수 있습니다. vPSP를 만들고 파괴하는 보호 된 관리 기능은 물론 vPSP에서 PSP의 전체 인터페이스 기능을 구현해야 합니다. vPSP를 구현하는 소프트웨어는 하이퍼 바이저와 게스트 모두에 통합되어야합니다. 게스트에서 API 호출을 입력하고 이를 인증 할 수있는 하이퍼 바이저 구성 요소에 전달하기 위해 프록시 드라이버가 필요합니다. 즉,이 VM이 해당 객체에 액세스 할 수 있습니까? 게스트의 프록시는 결과를 요청자에게 리턴해야 합니다. 게스트에 있는 vPSP의 동작은 물리적 PSP가 요청과 함께 표시 될 때의 동작과 동일해야 합니다. 요청은 필요에 따라 실제 PSP로 리디렉션되거나 에뮬레이션 될 수 있습니다. vPSP는 플랫폼 구성 상태를 보호하고 플랫폼 구성 상태, OS 및 응용 프로그램의 데이터 보호와 관련하여 증명을 제공하며 원격 인증을 용이하게합니다. 구현은 현재 PSP와 함께 작동하는 구현이 vPSP에서 계속 작동하는지 확인해야 합니다.

PSP 작업은 소프트웨어 구현의 성능 경로에서 절대로 발생해서는 안됩니다. 따라서 가상 구현에 의해 부과 된 추가 대기 시간을 최소화해야 합니다.

10.1.1.2 True Random Number Generator (TRNG)

TRNG는 어떤 유형의 물리적 소스에서 임의성 (엔트로피)을 추출한 다음 이를 사용하여 난수를 생성합니다. 물리적 소스는 엔트로피 소스라고도합니다.

거의 모든 암호화 프로토콜은 공격자가 알지 못하는 비밀 값의 생성과 사용을 필요로합니다. 예를 들어, 난수 생성기는 RSA, DSA 및 Diffie-Hellman을 비롯한 비대칭 (공개 키) 알고리즘에 대한 공용/개인 키 쌍을 생성해야 합니다. 대칭 및 하이브리드 암호 시스템의 키도 임의로 생성됩니다. RNG는 NONCE (salts) 값을 만드는 데 사용됩니다.

보안 프로토콜은 사용하는 키의 예측 불가능성에 의존하기 때문에 암호화 응용 프로그램 용 난수 생성기는 엄격한 요구 사항을 충족해야 합니다. 가장 중요한 속성은 RNG 설계를 알고있는 사람을 포함하여 공격자가 RNG 출력에 대해 유용한 예측을 할 수 없어야 한다는 것입니다.

하드웨어 난수 생성기의 주된 용도는 데이터 암호화 입니다. 예를 들어 데이터를 암호화하는 임의의 암호화 키를 만드는 것입니다. 컴퓨터는 일반적으로 "임의의" 숫자를 생성하는 데 사용되는 소프트웨어 프로그램인 의사 랜덤 넘버 생성기 (PRNG)에 대한 보다 안전한 대안입니다. PRNG는 결정적 알고리즘을 사용하여 숫자 시퀀스를 생성합니다. 이러한 의사 랜덤 시퀀스가 "무결성"에 대한 통계 패턴 테스트를 통과하지만 알고리즘을 초기화하고 이를 초기화하는데 사용되는 조건을 "시드"라고 부름으로써 출력을 예측할 수 있습니다. PRNG에 의해 생성된 일련의 수를 예측할 수 있기 때문에 의사 난수로 암호화 된 데이터는 잠재적으로 암호 해독에 취약합니다. 하드웨어 진정한 난수 생성기 (TRNG)는 예측할 수없는 일련의 숫자를 생성하므로 데이터를 암호화하는 데 사용될 때 최고의 보안을 제공합니다.

포그 시스템은 PRNG 솔루션과 달리 TRNG를 구현해야 합니다. 이 기능은 예를 들어 ISA 확장 또는 별도의 가속기 장치를 통해 구현 될 수 있습니다. 장치인 경우 보안 액세스를 유지하기 위해 여러 VM 및 컨테이너에서 보안 액세스를 허용하려면 하드웨어를 가상화해야합니다.

10.1.1.3 Secure Key Generation, Encryption and Storage

PSP는 인증서, 키 및 암호를 안전하게 보관할 수 있으므로 값 비싼 토큰이 필요하지 않습니다.

10.1.2 Node Security Aspect

앞의 그림은 4 개의 수평 "영역"으로 구분됩니다. 첫째, 하단에는 하드웨어 구성 요소 계층 (외부 장치 포함)이 있습니다. 하드웨어 가속기 (예: 사용 사례 요구 사항에 따라 다름)가 여기에있을 수 있습니다. SoC에있는 암호화 장치가 나와 있습니다 (외부 장치이거나 프로세서 ISA에 특수 명령으로 제공 될 수도 있음). 기타 일반 가속기도 여기에 표시됩니다. 시스템 mmu 및 iommu (단일 구현 또는 분할 일 수 있음)는 실제 코어와 함께이 레벨에 있습니다. 하드웨어 루트 트러스트 (HW-RoT)는 하드웨어 인프라의 일부이기도하며 온칩 또는이 기능을 제공하는 외부 장치에 내장 될 수 있습니다.

다음 레벨 업에는 시스템 펌웨어, 옵션 ROM 및 플랫폼 NVRAM이 있습니다. 이러한 구성 요소의 정확한 특성과 존재 여부는 플랫폼에 따라 다릅니다. HW-RoT와 트러스트 체인의 확장을 지원하려면 전원을 켠 후에 플랫폼에서 실행되는 첫 번째 코드 인 트러스트 된 시스템 ROM에 상주하는 불변 펌웨어 구현이 있어야합니다.

그 위에는 하이퍼 바이저 계층이 있습니다. 가상 장치 인스턴스 (예: 표시된 vSoC 장치)를 인스턴스화하고 관리하며 OAM (운영, 관리 및 관리) 시스템의 지시에 따라 가상 장치 인스턴스를 가상 시스템에 할당합니다. 또한 물리적 외부 장치를 나타내는 다른 가상 장치 (예 : vNIC)를 인스턴스화합니다. 이러한 가상 장치는 데이터 용 하이퍼 바이저 (예: sr-iov 준수 장치) 또는 소프트웨어 에뮬레이트 된 가상 인스턴스 (예: 공유되는 하드 디스크)를 바이 패스하는 하드웨어에서 완전히 지원할 수 있습니다. SMT (Simultaneous Multi-Threading)가 물리적 코어에 의해 지원되는 경우 하드웨어 스레드 일 수도 있고 아닐 수도있는 가상 코어는 추가 가상 코어의 표시를 허용합니다.

마지막 레이어는 VM이 인스턴스화되는 레이어입니다. 물리적 리소스는 하이퍼 바이저에 의해 여기 가상 리소스로 매핑됩니다. VM의 OS는 별도의 응용 프로그램 주소 공간 또는 [Linux] 컨테이너로 인스턴스화 할 수있는 응용 프로그램 주소 공간을 관리합니다.

레이어를 연결하고 신뢰할 수있는 구성 요소로 구성된 안전한 신뢰의 체인을 만드는 데 도움이되는 시스템 서비스를 제공하는 여러 가지 기능이 있습니다. 이들은 레이어 사이의 수직 화살표로 표시됩니다.

한 가지 예는 신뢰할 수있는 실행 환경을 인스턴스화하고 하이퍼 바이저에 서비스를 제공하는 "보안 엔진"입니다. 하이퍼 바이저는 해당 엔진을 가상화합니다. 하이퍼 바이저 계층에 표시된 vSE - 가상 보안 엔진은 각 신뢰할 수있는 VM에 에이전트가 상주합니다. 다른 하나는 VM을 포함하는 트러스트 체인을 구축하기 위해 펌웨어 또는 소프트웨어의 후속로드를 확인/측정하는 트러스티드 부트 펌웨어 및 소프트웨어입니다.

트러스티드 부트/트러스티드 로더 메커니즘은 트러스트 체인의 확장을 허용하는 트러스트 된 각 코드로드 (펌웨어 또는 소프트웨어)를 보장하기위한 것입니다.

선택적으로 신뢰할 수없는 소프트웨어를 VM에서 인스턴스화하여 신뢰할 수 없는 환경을 만들 수 있습니다. 이 구성은 신뢰할 수있는 환경에서 신뢰할 수 없는 자료를 테스트하는 데 유용 할 수 있으며 이전에 설명한 격리 및 기타 보안 메커니즘을 사용하여 보호됩니다.

RTIC 메커니즘은 10.1.2.1에서 더 자세히 설명됩니다. 하이퍼 바이저의 컨텍스트에 존재하며 실행 중에 수정해서는 안되는 메모리 영역의 상태를 모니터링합니다.

추상적인 포그 노드 시스템 다이어그램의 주변부는 물리적 보안 및 안티 탬퍼 메커니즘으로 구현 된 물리적 보안 및 안티 탬퍼 경계를 설명하는 데 사용되는 빨간색 선입니다. 우리는 그 토론으로 시작하여 루트 트러스트 토론으로 진행하여 거기에서 바깥쪽으로 작업 할 것입니다.

10.1.2.1 Run-time Integrity Checking (RTIC) and Introspection

보안 또는 측정 된 부팅으로 인해 안전하게 인스턴스화 된 소프트웨어에 버그, 감염 또는 실행 중에 손상되지 않은 상태가 유지되지 않습니다. 런타임 무결성 검사 (때때로 [Hypervisor] Introspection이라고 함)의 의도는 실행 중 이미지의 코드 및 정적 데이터에 대한 변경을 모니터링하고 감지하는 것입니다. 이는 코드 구조 및 정적 데이터 페이지가있는 곳에서 실행 전에 특정 RTIC 도구 세트를 실행하여 이미지 구조를 "이해"함으로써 수행됩니다. 하이퍼 바이저는 RTIC 메커니즘을 호스트합니다. 기본 가정은 하이퍼 바이저 자체가 신뢰할 수 있다는 것입니다. RTIC는 VM을 확인하는데만 사용됩니다. 사용 된 메커니즘은 페이지 테이블에 기록하지 않아야하는 페이지에 대한 쓰기를 감지하도록 페이지 테이블이 수정 될 때 대부분 수동적입니다. 승인되지 않은 수정을 감지하는 작업은 정책에 의해 이루어집니다. 일반적으로 VM은 종료됩니다.

이 방법의 기존 제품 구현은 없지만 적어도 하나의 구현이 KVM 및 Xen 하이퍼 바이저 모두에 대해 개발 중입니다.

이 문제를 부분적으로 해결할 수있는 다른 방법은 앞서 설명한 메모리 암호화입니다. 이것은 외부의 공격으로부터 암호화 된 "컨테이너"(Linux 컨테이너와 혼동하지 말 것)의 코드와 데이터를 보호합니다. 버그가 악용되거나 이전에 감염된 이미지가 유출 될 수도 있습니다. 이러한 "컨테이너"는 서비스나 데이터를 위해 컨테이너 외부로 나가야하는 경우에도 손상된 서비스에 취약합니다. 이러한 방식으로 코드 및 데이터 (정적 및 동적)를 보호 할 수 있지만 컨테이너 외부의 코드 또는 데이터 또는 데이터는 보호되지 않습니다.

이 문제에 대한보다 성숙한 해결책이있는 경우, 포그 노드는 노드가 손상되는 것을 방지하기 위해 RTIC 접근 방식을 구현해야합니다. 공격이 물리적 접근을 반드시 필요로하지는 않으므로 보호 지역에있는 노드보다 공공 장소에있는 노드에 더 유용 할 수 있습니다.

10.1.2.2 Debug, Performance Monitoring and Profiling Control

시스템 배포 후에는 모든 형태의 디버그 (하드웨어 및 소프트웨어 모두), 성능 모니터링 및 프로파일 링 제어를 해제해야합니다. 이러한 메커니즘은 보안 메커니즘을 제 위치에 배치하거나 미래의 측면 채널 공격을 허용하는 시스템 동작에 대한 통찰력을 얻기위한 기술을 제공하기 위해 물리적 액세스 또는 원격 액세스 (메커니즘에 따라 다름)를 통해 제 3자를위한 방법을 제공합니다.

현장에서 디버깅 또는 기타 모니터링 또는 프로파일 링 정보가 필요한 경우 정당한 직원이 특정 액세스 권한을 안전하게 제공 할 수있는 메커니즘이 마련되어 있어야합니다.

10.1.3 Network Security Aspect

OT 프론트 엔드 장비와 클라우드 컴퓨팅 데이터 센터간에 전개되는 퍼베이시브 컴퓨팅 인프라 스트럭처로서 안전한 OpenFog 플랫폼은 가용성이 높은 실시간 트러스티드 컴퓨팅 서비스를 제공 할 수 있을뿐만 아니라 동적 멀티 티어 방어 - 일상 생활에 필수적인 사이버 - 물리적 시스템을 보호하기 위한 심층적 전략 및 이중 임무를 수행하기 위해 OpenFog 플랫폼은 Network Security의 프로비저닝과 지속적인 보안 모니터링 및 관리의 지원을 통해 노드 보안 강화를 강화해야 합니다.

위의 그림은 보안 프로비저닝 및 보안 모니터링 및 관리와 세 가지 기능 계층 통신 보안, 서비스 보안 및 응용 프로그램 보안의 두 가지 운영면에서 종단 간 보안을 제공하기위한 아키텍처를 보여줍니다. 이 아키텍처는 ITU-X.805 권장 사항 [X.805]을 준수하며 Open Networking Foundation (ONF)에서 권장하는 SDN (Software Defined Networking) 아키텍처 [ONF / SDN]를 준수합니다. 다음 단원에서는 기능 계층에 대해 자세히 설명합니다.

10.1.3.1 Communications Security Layer

이 계층은 Device-Fog-Cloud Computing Hierarchy의 모든 엔티티 중 모든 물리적/가상 통신 채널에서 [X.800]에서 권장하는 다음 통신 보안 서비스를 구현합니다.

  • Confidentiality (기밀 유지)   * 연결 및 연결없는 데이터 기밀 유지   * 트래픽 흐름 기밀 유지
  • Integrity (무결성)   * 복구와의 연결 무결성   * 탐지를 통한 무 연결 무결성   * Anti-replay Protection (안티-재생 보호)
  • Authentication (인증)   * 연결없는 통신을 위한 데이터 원점 인증   * 연결 기반 통신을 위한 피어 엔터티 인증   * 인증 된 채널 액세스 제어
  • Nonrepudiation (부인 방지) (선택 사항)   * 원산지 부인 방지   * 목적지 부인 방지

Device-Fog-Cloud Computing 연속체에서 발생하는 통신은 세 가지 종류의 보안 통신 경로로 분류 할 수 있습니다.

  • Node-to-Cloud Secure 통신 경로
  • Node-to-Node Secure 통신 경로
  • Node-to-Device Secure 통신 경로

포그 노드는 종종 클라우드 서버의 프락시 엔드 장치로 연결된 프론트 엔드 장치를 프록시 서버로 모으고 클라우드 서버로 표현하기 때문에 프론트 엔드 장치와 클라우드 서버 간의 상호 운용성을 보존하기 위해 협력해야합니다. 다음 단락에서는 예상되는 기능과 각 종류의 경로에 대해 권장되는 방법을 강조합니다.

10.1.3.2 Node-to-Cloud Secure Communication Pathways

이러한 통신 경로를 보호하기 위해 포그 노드는 자신과 자신이 대표하는 프론트 엔드 장치를 대신하여 모든 X.800 통신 보안 서비스 (부인 방지 포함)를 구현해야 합니다. 강력한 인증 및 부인 방지 서비스는 포그 노드에 설치된 하드웨어 루트 신뢰도에서 파생 된 보안 자격 증명을 사용하여 구현되어야 합니다. 채널 접근 제어는 클라우드 서비스 제공자와 포그 노드 관리자간에 설정된 서비스 보안 정책에 따라 서비스 수준 계약의 일부로 시행되어야 합니다. 모든 암호 연산은 포그 노드에 내장 된 암호 가속기에 의해 수행되어야하고 암호 키는 보안 감시 및 관리 동작의 일부로 관리되어야 합니다.

이러한 경로는 클라우드 서버가 IoT 장치, 개인 모바일 장치, POS (point-of-sales) 터미널, 독립 실행 형 컴퓨터 및 서버를 포함한 프론트 엔드 장치와 통신하기 위해 사용하는 인터넷 통신 프로토콜 및 API를 보존 할 것으로 예상됩니다. 거의 모든 이러한 통신은 현재 다음 두 가지 프로토콜 세트를 통해 웹 서비스 트랜잭션으로 수행됩니다.

Applications Transaction Protocols Security Protocols
Enterprise Apps SOAP over HTTP WSS
Mobile/Personal Apps RESTful HTTP/COAP TLS/DTLS
10.1.3.3 Node-to-Node Secure Communication Pathways

분산 포그 컴퓨팅 플랫폼은 여러 인터넷 서브넷 또는 관리 도메인에 걸쳐있는 포그 노드의 계층 구조로 구성 될 수 있지만 이러한 포그 노드는 특정 목표를 달성하기 위해 서로 조정해야합니다. 트랜잭션 기반 클라이언트-서버 컴퓨팅 모델과 이벤트 기반 publish-subscribe 메시징 패턴에 기반한 노드 간 정보 교환은 모두 직접적이고 시기 적절한 상호 작용을 가능하게 하기 위해 구현되어야 합니다. 다음 프로토콜 제품군은 일반적으로 이러한 패러다임을 구현하는데 사용됩니다.

Paradigms Transaction Protocols Security Protocols
Client-Server SOAP, RESTful HTTP/COAP WSS, TLS/DTLS
Publish-Subscribe MQTT, AMQP, RTPS TLS/DTLS

node-to-cloud 경로와 마찬가지로 node-to-node 경로는 포그 노드를 통신 엔드 포인트로하여 부인 방지를 비롯한 모든 X.800 통신 보안 서비스를 구현할 것으로 기대합니다. 강력한 인증 및 부인 방지 서비스는 포그 노드에 설치된 하드웨어 루트 신뢰도에서 파생 된 보안 자격 증명을 사용하여 구현됩니다. 채널 접근 제어는 서비스 레벨 계약의 일부로 포그 노드 관리자간에 설정된 통신 보안 정책에 따라 시행되어야 합니다. 모든 암호 연산은 포그 노드에 내장 된 암호 가속기에 의해 수행되어야 하고 암호 키는 보안 감시 및 관리 동작에 의해 관리되어야 합니다.

10.1.3.4 Node-to-Device Secure Communication Pathways

종종 클라우드 서버의 프록시 역할을 하는 통신 노드는 프론트 엔드 장치가 사용하는 통신 프로토콜과 API를 보존해야 합니다. 불행하게도, 디바이스 통신 프로토콜의 선택은 상이한 애플리케이션 및 통신 매체간에 다양화 됩니다. 인터넷 (TCP/UDP/IP) 프로토콜 스위트의 적응을 통해 무선, 전력선 통신 및 산업 자동화 간의 프로토콜 컨버전스에 대한 노력이 이루어졌습니다.

대부분의 X.800 통신 보안 서비스는 (아마도 부인 방지를 제외하고) 잘 알려진 보안 프로토콜을 통해 유무선 이더넷과 인터넷 네트워크 및 전송 계층을 통해 구현 될 수 있습니다. 인터넷 프로토콜에 적합한 프론트 엔드 장치 중에서 프런트 엔드 장치에 발급 된 보안 자격 증명을 사용하여 강력한 인증을 구현할 수 있습니다. 채널 접근 제어는 포그 서비스 제공자에 의해 지정된 통신 보안 정책에 따라 시행 될 수 있습니다. 모든 암호화 작업은 프론트 엔드 장치의 암호화 가능 내장형 프로세서에서 수행 할 수 있으며 암호화 키는 보안 모니터링 및 관리 작업의 일부로 관리 할 수 있습니다.

그러나 인터넷에 익숙하지 않고 리소스가 제한적인 많은 프론트 엔드 장치 중에서 수동으로 설치된 키를 사용하는 대칭 암호와 같은 제한된 암호화 기능만 사용할 수 있습니다. 이러한 장치는 물리적으로 보호 된 환경에 설치해야하며 대부분의 X.800 통신 보안 서비스를 제공 할 수있는 하나 이상의 포그 노드에 하드웨어 연결을 통해 연결해야합니다.

포그 컴퓨팅을 더 자세히 조사 할 때 우리는 노드 간 통신 범위를 계속 확대 할 것입니다.

Layers Protocols
PHY & MAC Layer WLAN: 802.11
WPAN: 802.15
PLC: PRIME
Automation: CIP
Wireless Protocol Stacks WiFi
Bluetooth
ZigBee
Adaptation Layer WLAN/WPAN: 6LowPAN
PLC: PRIME IPv6 SSCS
Automation: EtherNet/IP
Transport/Network Layers UDP over IPv6
TCP over IPv6
uIPv6 Stack
Application Layer
(Publish-Subscribe Messaging)
CoAP
MQTT
AMQP
RTPS
Routing RPL
PCEP
LISP (Cisco)
Security 802.1AR – Secure Device Identity
802.1AE - Media Access Control (MAC) Security
802.1X – Port-Based (Authenticated) Media Access Control
IPsec AH & ESP, Tunnel/Transport Modes
(D)TLS – (Datagram) Transport Layer Security
10.1.3.5 Services Security Layer

이 계층은 전통적으로 다음과 같은 네트워크 보안 어플라이언스가 제공하는 정보 보안 서비스를 제공합니다.

  • Deep Packet Inspection (DPI)
  • 응용 프로그램 계층 프록시
  • 합법적인 메시지 차단
  • 침입 탐지 및 보호 시스템 (IPS/IDS)
  • 시스템/네트워크 이벤트 및 상태 모니터링
  • 콘텐츠 필터링 및 자녀 보호

또한 보안 서비스와 함께 번들로 제공되는 네트워킹 서비스를 제공 할 수도 있습니다. 예:

  • vRouters
  • WAN Accelerators
  • Network Address Translators (NAT)
  • Content Delivery Servers

전용 장치를 대체하기 위한 SDN (Software Defined Networking) 구현의 사용이 늘어남에 따라 이러한 "어플라이언스"는 가상 시스템 및 Linux 컨테이너의 소프트웨어 솔루션으로 점차 구현되고 있습니다. 위에 나열된 다른 어플라이언스와 함께 이 범주의 보안 어플라이언스는 일반적으로 NFV (Network Functional Virtualization) 또는 개별적으로 VNF (Virtual Network Functions)로 지칭됩니다. 이러한 VNF는 개별적으로 패키지 된 다른 서비스와 함께 서비스 기능 체인 (SFC)에서 함께 묶일 것이며 네트워크 서비스 헤더를 사용하여 선택한 서비스 기능 경로 (SFP)의 패킷을 라우팅 합니다.

대부분의 경우, 이러한 서비스 기능은 OpenFog 시스템에서 구현 될 것으로 믿어집니다. NFV 및 SFC 환경은 자체적 보안 문제 집합을 제시하고 이미 논의 된 많은 접근법을 포함하지만 아래에서 논의 할 몇 가지 새로운 과제도 소개합니다.

데이터 무결성 및 기밀성을 제공하고 유지하는 신뢰할 수있는 VNF 대 VNF 통신에는 플랫폼 하드웨어, 펌웨어 및 소프트웨어의 다양한 기능이 필요합니다. 하드웨어 루트에서 개발 된 신뢰 체인 이외에 다음과 같은 기능이 필요합니다.

  • 신원 확인을위한 VNF + CA 기반 보안 키 제공   * 가상 네트워크 기능 (VNFC)의 인증   * 비대칭 암호
  • 벌크 데이터 암호화   * 대칭 암호화
  • 안전한 영구 키 저장소   * 개인 키의 경우
  • 신뢰할 수있는 VNF 대 OAM / MANO 통신 (무결성, 기밀성)   * 안전한 소프트웨어 업데이트   * (위와 동일한 제공)
  • 증명   * 양 당사자는 안전한 상태에 있습니다.

추가 보안 고려 사항은 다음 영역에서 소개됩니다.

  • 서비스 오버레이 : SFF의 전송 전달   * SF / VNF간에 패킷 암호화 사용 SFF는 SF / VNF 끝점을 인증해야합니다.
  • SFC 사용 가능 도메인의 경계   * 신뢰할 수있는 사람을 경계에서 인증 : 스푸핑, DDoS 방지
  • 분류
    • OAM에서 분류 정책 인증 및 권한 부여
  • SFC 캡슐화   * 메타 데이터는 원본에 대해 인증되어야합니다.   * 민감한 메타 데이터의 선택적 공유 : 암호화 또는 변환

또한 NSH (Network Service Header)는 사전에 인증되지 않은 동적 관계를 작성하는 기능을 제공하며 SFF (Service Function Forwarder)가 구현할 수 있는 기능을 제공합니다.

  • 모든 서비스 기능 (SF) 또는 SFF는 즉시 서비스 기능 경로 (SFP)를 업데이트 할 수 있습니다.
  • SFP는 SFP에 SF를 두 번 이상 나열 할 수 있습니다.

게다가:

  • NSH에는 임의의 메타 데이터 필드 (고정 길이 또는 가변 길이)가 포함될 수 있으며 원래 분류 기준에 의해 추가되거나 SFP가 통과 될 때 SF 또는 SFF에 의해 추가 될 수 있습니다. 이것은 체인의 다른 SF에 유용 할 수있는 컨텍스트 정보를 전달하는데 사용됩니다.

이로 인해 또 다른 기밀 정보 및 개인 정보 보호 조건이 도입됩니다. 메타 데이터는 SFP의 구성 요소 중 하나가 필요로하는 모든 데이터를 포함 할 수 있으므로 하나의 SF에서 일부 필드를 선택적으로 숨기거나 암호화하는 방법이 명확하지 않은 경우 (패킷이 서비스 공급자, 고객 또는 부서를 통과 할 수있는 경우) 특정 정보가 독점적, 비밀 또는 민감한 것으로 간주되는 경계) 아키텍처는 아직 이러한 문제를 해결하지 못했습니다. 동적 인 알 수없는 당사자와 관련된 복잡한 문제입니다.

10.1.4 Data Security Aspect

시스템에 데이터가 있는 세 가지 일반적인 범주가 있습니다.

  • In memory during processing
  • 일종의 비휘발성 메모리
  • 네트워크 인터페이스에서 보내고 받은 메시지에서
10.1.4.1 Data in Use

데이터는 프로세싱 동안 메모리 시스템 계층 구조 (예를 들어, SRAM, DRAM, 캐시, 스왑 공간 등)에 상주한다. 키 자료, 개인 데이터, 회사 독점 데이터 및 일부 경우 독점 알고리즘과 같은 일부 데이터는 비밀로 간주되어 권한이 없는 당사자가 읽거나 변경하지 못하도록 보호해야합니다.

이미 논의 된 바와 같이, 메모리 관리 유닛 (예를 들어, mmu, iommu, smmu)은 메모리를 다른 어드레스 공간 (VM과 같은) 및 디바이스 (물리적 또는 논리적/가상)로부터의 무단 액세스로부터 보호하기 위해 사용될 수있다. 읽기/쓰기/no-execute 페이지 속성 비트는 주소 공간에서 제한된 액세스를 제공합니다 (하드웨어 리소스를 관리하는 OS 또는 하이퍼 바이저도 신뢰할 수 있다고 가정 함). 하이퍼 바이저는 다른 가상 컴퓨터의 실행 컨텍스트에 직접 영향을 줄 수 있는 하드웨어를 추상화하고 가상화함으로써 추가 보호 기능을 추가 할 수 있습니다.

스왑 공간에 상주하는 메모리도 보호해야합니다. 그 목적은 승인되지 않은 당사자가 디스크의 페이지에서 데이터를 읽지 못하도록 방지하는 것입니다 (예: 디스크를 제거하고 다른 시스템에서 읽는 것). 이것은 암호화를 사용하여 수행 할 수 있습니다. 전체 디스크 암호화는 비교적 낮은 오버 헤드에서이 기능을 제공하는 한 가지 방법입니다.

JTAG와 같은 외부 하드웨어 디버거 및 소프트웨어 디버거를 사용하여 메모리에 액세스하는 것은 현장의 프로덕션 시스템에서 실행 가능해서는 안됩니다. JTAG는 실험실이나 통제 된 환경을 떠날 때 항상 꺼야합니다. 디버깅이 필요한 경우 필드에 허용 된 경우에만 권한이 부여 된 사용자만 디버그 인터페이스를 사용할 수 있고 다른 모든 액세스에는 사용할 수 없도록 컨트롤해야 합니다.

Encrypted Memory

메모리 암호화는 실행 중 코드 및 데이터의 기밀성을 제공하는데 사용됩니다. 시스템의 나머지 부분이 손상된 경우에도 메모리의 비밀을 보호하는데 사용됩니다. 메모리 암호화는 CPU 패키지만 신뢰할 수 있는 것으로 간주된다는 사실을 기반으로 사용됩니다. 메모리는 신뢰할 수 있는 것으로 간주되지 않습니다. 부작용으로 해커가 실행중인 이미지에 코드를 삽입하는 것을 방지하여 코드가 손상되어 프로그램이 실패 할 수 있습니다.

메모리 암호화 체계는 일반적으로 속도 때문에 대칭 키 암호화를 사용합니다. 이 기능을 사용하려면 메모리 관리 하위 시스템에 상주하는 암호화 장치, 암호화 하드웨어를 관리하는 일부 운영 체제 지원 및 암호화 된 메모리와 관련된 키를 관리하는 방법을 비롯한 추가 하드웨어 지원이 필요합니다.

메모리 암호화는 비용이 들지 않습니다. 캐시로 가져와 캐시에서 다시 메모리로 쓰는 동적 decryption/encryption은 메모리 응답 시간에 영향을 줍니다.

메모리 암호화 기술에 대한 완전한 논의는이 백서의 범위를 벗어납니다. 그러나 이 기술은 포그 (fog) 컴퓨팅 환경에서 적어도 일부 데이터 클래스 및 일부 응용 프로그램에 확실한 보안 이점을 제공합니다. 위협 분석에 의해 정당화 될 경우 구현 될 수 있습니다.

10.1.4.2 Data at Rest

휴식시의 데이터란 하드 디스크 또는 SSD, USB 썸 드라이브, CD, DVD 등과 같은 일부 비 휘발성 저장 장치에 있는 데이터를 말합니다. 암호화는 데이터를 저장하는 최전선 방어 장치입니다. 다른 종류의 데이터 중에서도 개인 식별 정보 (개인 정보) 및 기타 기밀 정보 (기밀 유지)를 보호합니다. 올바른 키가있는 사용자에 대한 액세스를 제한하여 키가없는 사용자가 데이터에 액세스하지 못하게 합니다. 저장 매체가 어떤 식 으로든 물리적으로 손상되면 데이터에 대한 무단 액세스를 방지합니다.

또한 많은 컴플라이언스 요구 사항을 충족하고 저장 매체 폐기에 대한 우려를 없애고 무단 액세스로부터 데이터가 물리적으로 위장 될 위험을 없앱니다. 물리적 액세스 권한을 가진 사용자가 포그 노드에서 드라이브를 뺏기더라도 접속합니다.

자체 암호화만으로는 충분하지 않습니다. 키, 정책 및 인증서는 보안 저장소에서 적극적으로 관리되어야하며, 손상되지 않고 잘못된 침입자가 되지 않도록 해야합니다.

데이터베이스, 응용 프로그램 및 OS/파일 시스템 내에서 누가, 무엇을, 어디서, 언제, 어떻게 데이터에 액세스하는지 모니터링하는 프로세스를 마련해야 합니다. 민감한 정보에 대한 액세스와 무단 액세스 시도를 모두 모니터링 해야합니다. 모든 보안 이벤트는 OAM (Operations, Administration and Maintenance) 시스템에서 후속 분석 및 사용을 위해 기록되어야 합니다. 예를 들어 액세스 데이터를 사용하여 공격이 진행되고 있는지 확인할 수 있습니다. 정책은 OAM 시스템에 의해 지정됩니다.

휴지 메커니즘의 보안 데이터는 전원 켜기에서 부팅 단계, 하이퍼 바이저의 인스턴스화 (사용 된 경우) 및 VM의 운영 체제 및 응용 프로그램의 인스턴스화를 통해 안전한 트러스트 체인에 구축되어야합니다 (가상 환경이 사용됨).

일반적으로 데이터를 안전하게 보호하고 암호화하는 세 가지 방법이 있습니다.

Full Disk Encryption

일반적으로 전체 디스크 암호화는 소프트웨어 디스크 암호화 구현이 존재하지만 디스크 펌웨어의 하드웨어 기반 암호화 메커니즘을 사용하여 구현됩니다. 디스크에 기록 된 모든 데이터를 자동으로 암호화하고 디스크에서 읽은 모든 데이터를 자동으로 해독하여 작동합니다. 두 가지 작업 모두 올바른 인증 키를 가지고 있어야 합니다. 적절한 인증 키가 없으면 하드 드라이브가 제거 되더라도 동일하거나 다른 소프트웨어를 실행하는 다른 컴퓨터에서 읽을 수 없습니다. 풀 디스크 암호화의 장점은 소프트웨어나 OAM 시스템에 특별한 주의를 기울이지 않아도 된다는 것입니다. 소프트웨어 암호화가 사용되는 경우 운영 체제를 포함하여 하드 드라이브의 모든 항목이 암호화되므로 암호화/암호 해독 프로세스가 데이터 액세스 시간을 늘릴 수 있습니다. 풀 디스크 암호화는 공개적으로 액세스 할 수있는 위치 (예: 쇼핑몰, 램프 게시물, 거리 모퉁이, 길가, 차량 등)에 있는 포그 장치에 가장 유용합니다. 하나의 키가 전체 하드 드라이브를 암호화하는데 사용되기 때문에 OAM 시스템은 어떤 이유로 시스템이 작동하지 않고 데이터 검색이 필요한 경우 암호화 키 백업 메커니즘을 제공해야 합니다. 신중하게 관리되는 보안 백업을 사용할 수도 있습니다.

File System (and Database) Encryption

파일 시스템 수준 암호화는 별도의 키 기반 액세스 및 인증 메커니즘을 사용하여 파일 또는 디렉토리/폴더 단위로 특정 파일을 보호하는 방법을 제공합니다. 디스크 (또는 다른 미디어)에 저장된 개별 파일을 완전히 암호화 된 디스크에 액세스 할 수 있는 다른 응용 프로그램 (또는 사용자)으로부터 보호해야하는 경우에 사용됩니다. 사용중인 파일은 대칭 파일 암호화 키 (FEK)를 사용하여 암호화 됩니다. FEK는 소유자의 공용 키를 사용하여 암호화 됩니다. 암호화 된 FEK는 암호화 된 파일과 함께 저장됩니다. 파일을 해독하기 위해 파일 시스템은 먼저 소유자의 공용 키와 일치하는 개인 키를 사용하여 포함 된 FEK를 암호 해독합니다. 그런 다음 파일은 FEK를 사용하여 암호 해독됩니다. 전체 데이터베이스 또는 레코드의 개별 레코드 또는 필드도 암호화 될 수 있습니다. 파일 시스템 암호화는 동일한 VM에서 실행되는 응용 프로그램에서 사용하거나 독점적인 데이터 또는 다른 중요한 데이터나 개인 데이터가 들어있는 파일로 간주 할 수 있습니다.

File System Access Control Mechanisms

파일 시스템 액세스 제어 메커니즘은 사용자 ID 또는 그룹 ID별로 특정 파일 또는 파일 그룹에 대한 액세스를 제한하는 데 사용될 수 있습니다. 모든 최신 파일 시스템은 어떤 형태로든 파일 사용 권한을 구현합니다. 토론을 위해 여기에 Linux 파일 시스템이 사용되었습니다. 이러한 유형의 액세스 제어는 대부분 다른 시스템에서 유사합니다.

기본 파일 권한은 권한 유형을 사용하여 권한 그룹에 적용됩니다. 이것은 파일 시스템 사용 권한에 대한 완전하고 광범위한 논의가 아니며이 문서에서 논의 목적으로 사용되었습니다.

사용 권한 그룹 - 각 파일과 디렉터리에는 세 가지 사용자 기반 사용 권한 그룹이 있습니다.

  • owner: 소유자 권한은 파일 또는 디렉토리의 소유자만 적용됩니다. 그들은 다른 사용자의 행동에 영향을 미치지 않습니다.

  • group: 그룹 사용 권한은 파일 또는 디렉토리에 할당 된 그룹에만 적용됩니다. 다른 사용자의 작업에는 영향을 주지 않습니다.

  • all users: 모든 사용자 권한은 시스템의 다른 모든 사용자에게 적용됩니다. 일반적으로 가장 중요한 권한 그룹입니다.

권한 유형 - 각 파일 또는 디렉토리에는 세 가지 기본 권한 유형이 있습니다.

  • read: 읽기 권한은 사용자가 파일의 내용을 읽을 수 있는 권한을 말합니다.

  • write: 쓰기 권한은 파일이나 디렉토리를 쓰거나 수정하는 사용자 기능을 나타냅니다.

  • execute: 실행 권한은 사용자가 파일을 실행하거나 디렉토리의 내용을 볼 수 있는지 여부에 영향을 줍니다.

이러한 메커니즘은 사용자 ID 및 그룹 ID를 정의하는 운영 체제의 컨텍스트에서 중요한 컨트롤입니다. 일반적으로 관리자. OAM에서 작동하면 특정 OS 파일 시스템 환경에 대해 사용자 ID 및 그룹 ID가 설정된 경우 액세스 권한을 지정합니다. 이것은 주어진 포그 시스템에서 사용되거나 사용되지 않을 수 있습니다. 서로 다른 응용 프로그램이 동일한 OS (VM) 컨텍스트에서 실행되고 공유 파일 시스템의 데이터에 다른 액세스가 필요한 경우 (예: 일부는 읽기 전용, 다른 일부는 읽기 전용, 데이터를 작성하려면 읽기 전용) 중요 할 수 있습니다.

10.1.4.3 Data in Motion

전송중인 데이터라고도 하는 모션 데이터는 포그 노드 (또는 네트워크를 통해 이동하는 정보)와의 네트워크 인터페이스 (가상 네트워크 인터페이스 포함)에서 보내고 받는 패킷을 설명하는데 사용됩니다. 전송중 민감한 데이터나 개인 데이터에 대해 암호화를 구현해야합니다. VPN, SSL 및 전송 중에 일반 텍스트 형식으로 데이터가 손상되거나 보호되지 않도록하는 다른 기술을 사용합니다.

동작중인 데이터를 보호하려고 할 때 암호화를 사용하는 방법에는 암호화 된 연결을 사용하거나 암호화 된 파일을 사용하는 두 가지 방법이 있습니다.

암호화 된 연결은 전송할 정보의 암호화 상태에 관계없이 네트워크 연결을 통해 전송되는 모든 항목이 자동으로 암호화되는 연결입니다. 예를 들어, 이미 암호화 된 파일을 보내는 경우 전송 중 다른 키로 다시 암호화됩니다.

전송 중에 이미 암호화 된 파일을 사용하는 경우 모션에서 데이터를 유지하는 또 다른 방법이 안전합니다. 암호화 된 파일은 암호화 된 형태로 존재하기 때문에 항상 암호화되어 보호됩니다.

Reference

[IOT-A] EU IOT-A Terminology (http://www.iot-a.eu/public/terminology/copy_of_term)

[AIMglobal] Association for Automatic Identification and Mobility (http://www.aimglobal.org/)

[AutoI] Information Model, Deliverable D3.1, Autonomic Internet (AutoI) Project (http://www.autoi.ics.ece.upatras.gr/d/AutoI_Deliverable_D3.1_-_Information_Model.pdf)

[CCSDS 312.0-G-0] Information architecture reference model (http://cwe.ccsds.org/sea/docs/SEA-IA/Draft%20Documents/IA%20Reference%20Model/ccsds_rasim_20060308.pdf)

[COMPDICT-M2M] Computer Dictionary Definition (http://www.yourdictionary.com/computer/m2-m)

[E-FRAME] E-FRAME project, available (http://www.frame-online.net/top-menu/the-architecture-2/faqs/stakeholder-aspiration.html)

[EPCglobal] EPC Global glossary (GS1) ( http://www.epcglobalinc.org/home/GS1_EPCglobal_Glossary_V35_KS_June_09_2009.pdf)

[ETSI-ETR173] ETSI Technical report ETR 173, Terminal Equipment (TE); Functional model for multimedia applications (http://www.etsi.org/deliver/etsi_etr/100_199/173/01_60/etr_173e01p.pdf)

[ETSI TR 102 477] ETSI Corporate telecommunication Networks (CN); Mobility for enterprise communication (http://www.etsi.org/deliver/etsi_tr/102400_102499/102477/01.01.01_60/tr_102477v010101p.pdf)

[IEEE-1471-2000] IEEE 1471-2000, “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”

[ITU-IOT] the Internet of Things summary at ITU (http://www.itu.int/osg/spu/publications/internetofthings/InternetofThings_summary.pdf)

[ISO/IEC 2382-1] Information technology -- Vocabulary -- Part 1: Fundamental terms (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=7229)

[ISO 27001] ISO 27001: An Introduction to Information, Network and Internet Security

[OGS] Open GeoSpatial portal, the OpenGIS abstract specification Topic 12: the OpenGIS Service architecture (http://portal.opengeospatial.org/files/?artifact_id=1221)

[OASIS-RM] Reference Model for Service Oriented Architecture 1.0 (http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf)

[OECD2009]: "Smart Sensor Networks: Technologies and Applications for Green Growth”, December 2009 (http://www.oecd.org/dataoecd/39/62/44379113.pdf)

[Sclater2007] Sclater, N., Mechanisms and Mechanical Devices Sourcebook, 4th Edition (2007), 25, McGraw-Hill

[setzer-messtechnik] setzer-messtechnik glossary, July 2010 (http://www.setzer-messtechnik.at/grundlagen/rf-glossary.php?lang=en)

[TOGAF9] Open Group, TOGAF 9, 2009

[Wikipedia IN] Internet page on Wikipedia (http://en.wikipedia.org/wiki/Internet)

[ROZANSKI2005] Software Architecture with Viewpoints and Perspectives (http://www.viewpoints-and-perspectives.info/doc/spa191-viewpoints-and-perspectives.pdf)

[Wikipedia WI] Wireless page on Wikipedia (http://en.wikipedia.org/wiki/Wireless)

[IoT Guide] Internet of Things Guide (http://internetofthingsguide.com/d/cloud.htm)

[Nexsus] Nexus IoT Glossary (https://www.nexusgroup.com/en/glossary/?letter=C)

[UF IoT] Universal Framework IoT Glossary (https://universalframeworks.com/industrial-internet-of-things-i-iot-glossary/)

[AutoI] Information Model, Deliverable D3.1, Autonomic Internet (AutoI) Project (http://ist-autoi.eu/autoi/d/AutoI_Deliverable_D3.1_-_Information_Model.pdf)

[TOGAF9] Open Group, TOGAF 9, 2009

[Ref-a] - http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

[Ref-b] - http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

[Ref-c] - http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

Mobile Edge Computing: http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing

Industrial Internet Consortium: http://www.iiconsortium.org/

Open Connectivity Foundation: http://openconnectivity.org

Trackbacks 0 : Comments 0