IIoT를 위한 분류

왕은 고급 유리 의자에서 체스를 둡니다. 이거 기억하시는 분 계신가요?

대부분의 경우 이는 아마도 횡설수설일 것입니다. 하지만 나를 위해. 이 니모닉은 왕국, 문, 계급, 목, 가족, 속, 종과 같은 삶의 분류 체계를 기억하는 데 도움이 됩니다.

지구상의 생명체의 폭과 깊이, 다양성은 압도적입니다. 분류는 시스템 유형을 특성에 따라 논리적으로 나눕니다. 생물학의 과학은 좋은 분류 체계 없이는 불가능합니다. 이를 통해 과학자들은 식물과 동물을 논리적 유형으로 분류하고, 공통점을 식별하고, 생물 시스템의 전체 클래스를 이해하기 위한 규칙을 구성할 수 있습니다.

IIoT(산업용 사물 인터넷)의 폭과 깊이, 다양성 또한 압도적입니다. IIoT 시스템의 과학에는 유사하게 조직된 애플리케이션 유형 분류가 필요합니다. 그래야만 시스템을 구현하기 위한 적절한 아키텍처와 기술에 대해 논의할 수 있습니다.

첫 번째 문제는 최상위 부서를 선택하는 것입니다. 동물의 왕국에서는 대부분의 동물에 "육지, 바다 또는 공중" 동물이라는 라벨을 붙일 수 있습니다. 그러나 이러한 환경 설명은 동물을 이해하는 데별로 도움이 되지 않습니다. 고래의 "건축물"은 문어와 크게 다르지 않지만 곰과 매우 흡사합니다. 동물을 이해하려면 특성과 구조에 따라 구분해야 합니다.

또한 "의료, 운송 및 전력"과 같은 산업별로 응용 프로그램을 나누는 것은 유용하지 않습니다. 이러한 환경이 중요하지만 적용 가능한 아키텍처와 기술은 단순히 산업 라인을 따라 분할되지 않습니다. 여기서도 주요 과제를 정의하는 특성에 대한 더 깊은 이해가 필요하며 이러한 과제가 아키텍처를 결정합니다.

나는 이것이 강력하고 심지어는 충격적인 주장이라는 것을 알고 있습니다. 예를 들어, 각 산업의 맞춤형 표준, 프로토콜 및 아키텍처는 IIoT 시스템의 미래 아키텍처를 설계하는 데 유용한 방법이 아님을 의미합니다. . 그럼에도 불구하고 현장 시스템의 분명한 사실입니다. 엔터프라이즈 인터넷이 된 변환에서와 같이 일반 기술이 특수 목적 접근 방식을 대체할 것입니다. 이해도를 높이고 IIoT의 약속을 실현하려면 기존의 산업별 사고 방식을 버려야 합니다.

그러면 나눗셈에 무엇을 사용할 수 있습니까? IIoT의 곤충에서 파충류와 포유류를 구분하는 데 사용할 수 있는 특징은 무엇입니까?

사용할 수 있는 기능적 및 비기능적 요구 사항은 수천 가지가 있습니다. 동물과 마찬가지로 공간을 유용한 주요 범주로 나누는 몇 가지 요구 사항을 찾아야 합니다.

목표는 시스템 아키텍처를 결정할 수 있도록 공간을 나누는 것이라는 인식으로 작업이 단순화됩니다. . 따라서 좋은 구분 기준은 a) 모호하지 않고 b) 아키텍처에 영향을 미칩니다. 쉬워보일지 모르지만 실제로는 아주 사소한 일입니다. 그것을 할 수 있는 유일한 방법은 경험을 통해서입니다. 우리는 초기 단계에 있습니다. 그러나 상당한 진전이 우리 집단의 이해 범위 내에 있습니다.

거의 1000개에 가까운 실제 IIoT 애플리케이션에 대한 RTI의 광범위한 경험을 바탕으로 아래에서 몇 가지 초기 부서를 제안합니다. 최대한 선명하게 하기 위해 각 부문에 대해 "메트릭"도 선택했습니다. 물론 선은 그렇게 굵지 않습니다. 그러나 숫자는 명확성을 요구하며 이는 매우 중요합니다. 숫자 잣대가 없으면(미터 스틱?) 의미를 너무 자주 잃습니다.

IIoT 분류 제안

신뢰성 [측정항목:지속적인 가용성은 "99.999%" 이상이어야 함]

우리는 "높은 신뢰성"이라는 진부한 말에 만족할 수 없습니다. 거의 모든 것이 "필요"합니다. 의미를 가지려면 해당 안정성을 달성하기 위한 아키텍처 요구 사항에 대해 보다 구체적이어야 합니다. 이를 위해서는 장애가 얼마나 빨리 문제를 일으키고 그 문제가 얼마나 심각한지 이해해야 합니다.

우리는 신뢰성을 분류하는 가장 간단하고 유용한 방법이 "1년에 5분 동안 예상치 못한 고장의 결과는 무엇입니까?"라는 질문을 하는 것임을 발견했습니다. (여기서 5분/년을 선택하는 이유는 이것이 엔터프라이즈급 서버에 대한 "5-9s" 황금 사양이기 때문입니다. 많은 산업 시스템은 몇 밀리초의 예상치 못한 다운타임도 용납할 수 없습니다.)

이는 시스템 아키텍처에 큰 영향을 미치기 때문에 중요한 특성입니다. 짧은 시간에도 실패하지 않는 시스템은 중복 컴퓨팅, 센서, 네트워킹 등을 지원해야 합니다. 안정성이 진정으로 중요할 때 이는 곧 또는 아마도 핵심 아키텍처 동인이 됩니다.

실시간 [측정항목:응답 <100ms]

"실시간"을 특성화하는 방법은 수천 가지가 있습니다. 모든 시스템은 "빠르게" 되어야 합니다. 그러나 유용하려면 아키텍처를 구동하는 속도 요구 사항을 구체적으로 이해해야 합니다.

웹사이트에 대해 8초 이상 기다리기를 꺼리는 인간 사용자를 만족시킬 수 있는 아키텍처는 2ms 내에 응답해야 하는 산업 제어를 결코 만족시킬 수 없습니다. 우리는 응답 속도가 수십 밀리초(ms) 또는 마이크로초(µs)로 측정될 때 설계에 큰 영향을 미치는 "곡선의 무릎"이 발생한다는 것을 발견했습니다. 100ms를 선택하는 이유는 단순히 데이터 경로에서 서버나 브로커에 의해 부과되는 잠재적인 지터(최대 대기 시간)에 관한 것이기 때문입니다. 이보다 훨씬 빠르게 응답하는 시스템은 일반적으로 P2P 방식이어야 하며 이는 아키텍처에 막대한 영향을 미칩니다.

데이터 세트 규모 [메트릭:데이터 세트 크기> 10,000개 항목]

다시 말하지만, "노드" 수, 애플리케이션 수, 데이터 항목 수 등을 포함하여 수천 개의 차원을 확장할 수 있습니다. 이 모든 매개변수로 공간을 나눌 수는 없습니다. 실제로 그들은 관련이 있습니다. 예를 들어, 많은 데이터 항목이 있는 시스템에는 아마도 많은 노드가 있을 것입니다.

넓은 공간에도 불구하고 우리는 두 가지 간단한 질문이 아키텍처 요구 사항과 관련이 있음을 발견했습니다. 첫 번째는 "데이터 세트 크기"이며 곡선의 무릎은 약 10k 항목입니다. 시스템이 이렇게 커지면 모든 데이터 업데이트를 가능한 모든 수신기에 보내는 것이 더 이상 실용적이지 않습니다. 따라서 데이터 자체를 관리하는 것이 아키텍처의 핵심 요구 사항이 됩니다. 이러한 시스템에는 데이터를 명시적으로 모델링하여 선택적인 필터링 및 전달을 허용하는 "데이터 중심" 설계가 필요합니다.

팀 또는 애플리케이션 규모 [메트릭:팀 또는 상호 작용하는 애플리케이션 수>10]

우리가 선택하는 두 번째 척도 매개변수는 "프로젝트"의 팀 또는 독립적으로 개발된 응용 프로그램의 수이며 중단점은 약 10입니다. 많은 독립 개발자 그룹이 상호 작용해야 하는 응용 프로그램을 빌드할 때 데이터 인터페이스 제어가 상호 운용성 문제를 지배합니다. 다시 말하지만, 이는 종종 이러한 인터페이스를 명시적으로 모델링하고 관리하는 데이터 중심 설계의 필요성을 나타냅니다.

기기 데이터 검색 과제 [측정항목:>다변수 데이터 세트가 있는 기기 유형 20가지]

일부 IIoT 시스템은 런타임 전에 구성 및 이해될 수 있습니다. 이는 모든 데이터 소스와 싱크가 알려져 있다는 의미가 아니라 이 구성이 상대적으로 정적이라는 의미입니다.

그러나 IIoT 시스템이 기계 또는 장치의 랙과 랙을 통합하는 경우 작동 중에 구성하고 이해해야 하는 경우가 많습니다. 예를 들어, 플랜트 컨트롤러 HMI는 사용자가 모니터링할 데이터를 선택할 수 있도록 설치된 장치 또는 랙의 장치 특성을 발견해야 할 수 있습니다. "20"개의 다른 장치를 선택하는 것은 임의적입니다. 요점:랙의 장치에 대해 다양한 구성이 있는 경우 이 "내성"은 수동 체조를 피하기 위한 중요한 아키텍처 요구 사항이 됩니다. 이러한 특성을 가진 대부분의 시스템에는 20개 이상의 장치 유형이 있습니다.

분포 초점 [측정항목:팬아웃> 10]

단일 데이터 항목이 변경될 때 알려야 하는 데이터 수신자의 수로 "팬아웃"을 정의합니다. 많은 프로토콜이 단일 1:1 연결을 통해 작동하기 때문에 이는 아키텍처에 영향을 미칩니다. 대부분의 기업 세계는 종종 1:1 세션 프로토콜인 TCP를 사용하여 이러한 방식으로 작동합니다. 예를 들어 브라우저를 웹 서버에 연결하거나 전화 앱을 백엔드에 연결하거나 은행을 신용 카드 회사에 연결하는 것이 포함됩니다.

그러나 IIoT 시스템은 종종 더 많은 대상에 정보를 배포해야 합니다. 단일 데이터 항목이 여러 대상으로 이동해야 하는 경우 아키텍처는 효율적인 다중 업데이트를 지원해야 합니다. 팬아웃이 10개 정도를 초과하면 1:1 연결 집합을 관리하여 이 분기를 수행하는 것이 비실용적이 됩니다.

컬렉션 포커스 [메트릭:팬인이 있는 단방향 데이터 흐름> 100]

본질적으로 수집 문제에 국한된 시스템은 장치 간에 중요한 데이터를 공유하지 않습니다. 대신 상위 서버나 클라우드에 저장하거나 분석할 방대한 정보를 전송합니다.

이는 아키텍처에 큰 영향을 미칩니다. 수집 시스템은 종종 허브 앤 스포크 "집선 장치" 또는 클라우드 기반 서버 설계를 사용할 수 있습니다.

분류상의 이점

IIoT 분류 체계를 정의하는 것은 쉬운 일이 아닙니다. 이 블로그는 단지 표면을 긁는 것뿐입니다. 그러나 이점은 엄청납니다. 이러한 요구 사항을 해결하면 시스템 설계자가 프로토콜, 네트워크 토폴로지 및 컴퓨팅 기능을 선택하는 데 도움이 됩니다. 오늘날 우리는 올바른 디자인에 서버가 필요하지 않을 수도 있는 서버 위치 또는 구성과 같은 문제로 고민하는 디자이너를 봅니다. "실시간" 및 "사물"과 같은 오버로드된 용어는 실제 사용 사례가 겹치지 않고 기술 간에 엄청난 혼란을 야기합니다.

이제 Industrial Internet Consortium이 이 중요한 과제에 착수할 때입니다. 최신 작업 그룹은 이러한 가장 기본적인 비즈니스 및 기술 요구 사항을 명확히 하는 것을 목표로 이 문제를 해결할 것입니다. 바르셀로나에서 열리는 차기 IIC 회원 회의에서 이 그룹을 시작하는 데 도움을 주게 되어 기쁩니다. 관심이 있으시면 저([email protected]), Dirk Slama([email protected]) 또는 Jacques Durand([email protected])에게 연락하십시오. IIoT 전반에 걸쳐 광범위한 공동 경험을 공유하는 것으로 시작하겠습니다.