Databus 대 데이터베이스:모든 IIoT 개발자가 물어야 하는 6가지 질문

산업용 사물 인터넷(IIoT)은 혼란스러운 용어로 가득 차 있습니다. 그것은 불가피하다. 컴퓨팅 및 시스템에서 익숙한 개념을 재사용함에도 불구하고 IIoT는 작동 방식의 근본적인 변화입니다. 근본적인 변화에는 근본적으로 새로운 개념이 필요합니다. 가장 중요한 것 중 하나는 "데이터 버스"의 개념입니다.

곧 출시될 IIC 참조 아키텍처 버전 2에는 "계층화된 데이터 버스" 패턴이라는 새로운 패턴이 포함되어 있습니다. 지금은 IIC 릴리스에 대해 더 말할 수 없지만 문서화 프로세스를 거치는 것은 명확한 정의를 도출하는 데 큰 도움이 되었습니다.

데이터버스 정의:

데이터 버스는 가상의 글로벌 데이터 공간을 구현하는 데이터 중심 정보 공유 기술입니다. 소프트웨어 응용 프로그램은 전역 데이터 공간의 항목을 읽고 업데이트합니다. 업데이트는 게시-구독 통신 메커니즘을 통해 애플리케이션 간에 공유됩니다.

데이터 버스의 주요 특성은 다음과 같습니다.

<올>

참가자/응용 프로그램이 데이터와 직접 상호 작용,

인프라는 데이터를 이해하므로 선택적으로 데이터를 필터링할 수 있으며

인프라는 데이터 흐름의 속도, 안정성 및 보안과 같은 서비스 품질(QoS) 매개변수에 대한 규칙과 보장을 부과합니다.

물론 새로운 개념은 질문을 생성합니다. 최고의 질문 중 일부는 대규모 데이터베이스 회사의 설계자에게서 나왔습니다. 우리는 일반적으로 네트워킹 또는 소프트웨어 설계자의 관점에서 데이터 버스 개념을 설명하려고 합니다. 그러나 데이터 과학이 더 나은 접근 방식일 수 있습니다. 데이터베이스와 데이터 버스는 결국 데이터 과학 개념입니다.

가장 일반적인 6가지 질문을 살펴보겠습니다.

질문 1:데이터버스는 데이터베이스(모든 종류)와 어떻게 다릅니까?

짧은 대답:데이터베이스 데이터 중심 스토리지를 구현합니다. 오래된을 저장합니다. 나중에 검색할 수 있는 정보 저장된 데이터의 속성을 연결함으로써. 데이터버스 데이터 중심 상호 작용을 구현합니다. 미래를 관리합니다. 필터링하여 정보 들어오는 데이터의 속성에 의해.

긴 답변:데이터 중심성은 다음 속성으로 정의할 수 있습니다.

<울>

인터페이스는 데이터입니다. 메시지, 개체, 파일 또는 액세스 패턴과 같이 해당 인터페이스에 인위적인 래퍼나 차단기가 없습니다.

인프라는 해당 데이터를 이해합니다. 이것은 필터링/검색, 도구 및 선택성을 가능하게 합니다. 데이터에서 애플리케이션을 분리하여 애플리케이션에서 많은 복잡성을 제거합니다.

시스템은 데이터를 관리하고 애플리케이션이 데이터를 교환하는 방법에 대한 규칙을 부과합니다. 이것은 "진리"의 개념을 제공합니다. 데이터 수명, 데이터 모델 일치, CRUD 인터페이스 등을 활성화합니다.

관계형 데이터베이스는 데이터 중심 스토리지 기술입니다. 데이터베이스 이전의 스토리지 시스템은 애플리케이션 정의(Ad Hoc) 구조의 파일이었습니다. 데이터베이스도 파일이지만 매우 특별한 파일입니다. 데이터베이스는 데이터를 해석하고 액세스 제어를 시행하는 방법을 알고 있습니다. 따라서 데이터베이스는 시스템에 대한 "진실"을 정의합니다. 데이터베이스의 데이터는 손상되거나 손실될 수 없습니다.

데이터베이스는 데이터 모델을 제어하는 ​​간단한 규칙을 적용하여 일관성을 보장합니다. 모든 사용자가 검색 및 검색할 수 있도록 데이터를 노출함으로써 데이터베이스는 시스템 통합을 크게 용이하게 합니다. 데이터베이스는 데이터 및 스키마 검색을 허용함으로써 정보 모니터링, 측정 및 마이닝을 위한 일반 도구도 사용할 수 있습니다.

데이터베이스와 마찬가지로 데이터 중심 미들웨어(데이터 버스)는 전송된 데이터의 내용을 이해합니다. 데이터 버스도 메시지를 보내지만 매우 특별한 메시지를 보냅니다. 상태를 유지하는 데 특별히 필요한 메시지만 보냅니다. 명확한 규칙은 데이터에 대한 액세스, 시스템의 데이터가 변경되는 방식 및 참가자가 업데이트를 받는 시기를 제어합니다. 중요한 것은 인프라만 메시지를 보낸다는 것입니다. 응용 프로그램에서 시스템은 통제된 전역 데이터 공간처럼 보입니다. 애플리케이션은 연령 및 비율과 같은 데이터 및 데이터 "서비스 품질"(QoS) 속성과 직접 상호 작용합니다. "메시지"에 대한 응용 프로그램 수준 인식이나 개념이 없습니다. 데이터 버스를 사용하는 프로그램은 데이터를 읽고 쓰며 메시지를 보내고 받지 않습니다.

<그림>

데이터에 대한 구조 및 요구 사항에 대한 지식을 바탕으로 데이터 버스 인프라는 정보 필터링, 업데이트 수행 시기 또는 업데이트 여부 선택 등의 작업을 수행할 수 있습니다. 인프라 자체는 업데이트 속도, 안정성 및 피어 활성에 대한 보장된 알림과 같은 QoS를 제어할 수 있습니다. 인프라는 데이터 흐름을 발견하고 이를 애플리케이션과 일반 도구에 모두 제공할 수 있습니다. 분산 시스템에서 데이터 상태에 대한 이러한 지식은 "진실"의 명확한 정의입니다. 데이터베이스에서와 같이 인프라는 구조와 콘텐츠 모두에서 데이터를 다른 애플리케이션에 노출합니다. 이 액세스 가능한 정보 소스는 시스템 통합을 크게 용이하게 합니다. 또한 정보 흐름을 모니터링 및 보고, 메시지를 라우팅하고, 캐싱을 관리하는 일반 도구 및 서비스를 사용할 수 있습니다.

질문 2:"소프트웨어 응용 프로그램은 전역 데이터 공간의 항목을 읽고 업데이트합니다. 업데이트는 게시-구독 통신 메커니즘을 통해 응용 프로그램 간에 공유됩니다." 이것이 pub-sub 인터페이스를 통해 상호 작용하는 데이터베이스라는 의미인가요?

짧은 대답:아니요, 데이터베이스가 없습니다. 데이터베이스는 스토리지를 의미합니다. 데이터는 물리적으로 어딘가에 상주합니다. 데이터 버스는 "전역 데이터 공간"이라는 순수한 가상 개념을 구현합니다.

긴 대답:데이터 버스 데이터 공간은 미래 정보와 상호 작용하는 방법을 정의합니다. 예를 들어 "당신"이 교차로 컨트롤러라면 당신의 위치에서 200m 이내의 차량 업데이트를 구독할 수 있습니다. 이러한 업데이트는 차량이 접근하는 경우 귀하에게 전달됩니다. 다양한 방식으로 배송이 보장됩니다(0.01초 이내에 시작, 100x/sec 업데이트, 안정적 등). 데이터는 전혀 저장되지 않을 수 있습니다. (신뢰성과 같은 일부 QoS 설정은 일부 로컬 스토리지를 필요로 할 수 있습니다.) 데이터 공간은 정보가 지정되지 않은 경우에도 사용자가 지정하는 정확한 방식으로 정보로 채워지는 특별히 제어되는 데이터 개체 집합으로 생각할 수 있습니다. 일반) 데이터 버스에 의해 저장... 방금 전달되었습니다.

질문 3:"참가자/응용 프로그램이 데이터와 직접 인터페이스합니다." 그것이 무엇을 의미하는지 자세히 설명해 주시겠습니까?

"메시지 중심" 미들웨어를 사용하면 메시지로 래핑된 데이터를 다른 응용 프로그램으로 보내는 응용 프로그램을 작성합니다. 예를 들어 클라이언트가 서버에 데이터를 보내도록 할 수 있습니다. 양쪽 끝은 일반적으로 스키마와 같은 것을 포함하여 다른 쪽 끝에 대해 ​​알아야 할 것이 있지만 "0.01초 미만" 또는 "100x/초가 될 것"과 같은 데이터의 속성을 가정할 가능성이 있습니다. 또는 적어도 살아있는 또 다른 끝이 있다는 것을, 예를 들어 서버가 실행 중입니다. 이러한 모든 가정된 속성은 애플리케이션 코드에 완전히 숨겨져 있으므로 재사용, 시스템 통합 및 상호 운용성이 매우 어렵습니다.

데이터 버스를 사용하면 소스 응용 프로그램에 대해 아무것도 알 필요가 없습니다. 데이터 요구 사항을 명확히 하면 데이터 버스가 이를 제공합니다. 따라서 데이터 버스를 사용하면 각 응용 프로그램은 데이터 공간과만 상호 작용합니다. 애플리케이션으로서 CRUD 인터페이스를 사용하여 데이터 공간에 쓰거나 데이터 공간에서 읽기만 하면 됩니다. 물론 해당 데이터 공간에서 일부 QoS가 필요할 수 있습니다. 초당 100배 업데이트된 데이터가 필요합니다. 데이터 공간 자체(데이터 버스)는 해당 데이터(또는 오류 플래그)를 얻도록 보장합니다. 해당 데이터의 중복 소스가 1개인지 27개인지, 네트워크나 공유 메모리를 통해 오는지, Linux의 C 프로그램인지 Windows의 C# 프로그램인지 알 필요가 없습니다. 모든 상호 작용은 데이터 공간에 대한 고유한 관점에서 이루어집니다. 예를 들어 수신자가 없는 공간에 데이터를 쓰는 것도 의미가 있습니다. 이 경우 데이터 버스는 QoS 설정에 따라 아무 작업도 하지 않거나 나중에 전달하기 위해 정보를 캐시할 수 있습니다.

데이터베이스 및 데이터 버스 기술은 모두 애플리케이션-애플리케이션 상호 작용을 애플리케이션-데이터-애플리케이션 상호 작용으로 대체합니다. 이 추상화는 절대적으로 중요합니다. 애플리케이션을 분리하고 확장성, 상호 운용성 및 시스템 통합을 크게 용이하게 합니다. 차이점은 실제로 중앙 집중식 데이터베이스에 저장된 오래된 데이터와 분산 데이터 공간에서 애플리케이션으로 직접 전송되는 미래 데이터의 차이입니다.

질문 4:"인프라가 이해하므로 데이터를 선택적으로 필터링할 수 있습니다." 관심 있는 "이벤트"에 등록할 수 있는 모든 pub-sub에 해당되지 않습니까?

대부분의 pub-sub는 매우 원시적입니다. 응용 프로그램이 "관심 등록"하면 모든 것이 해당 응용 프로그램으로 전송됩니다. 예를 들어 교차로 충돌 감지 알고리즘은 "차량 위치"를 구독할 수 있습니다. 그런 다음 인프라는 해당 메시지 내부의 데이터에 대한 지식 없이 위치를 생성할 수 있는 모든 센서에서 메시지를 보냅니다. "콘텐츠 필터링" pub-sub조차도 매우 간단한 사양만 제공하며 시스템이 모두에게 중요한 것을 미리 선택해야 합니다. 흐름을 실제로 제어할 수 없습니다.

데이터 버스는 훨씬 더 표현력이 뛰어납니다. 그 교차로는 "나는 나를 향해 10m/s로 움직이는 200m 이내의 차량 위치에만 관심이 있습니다. 차량이 내 사양에 떨어지면 1초에 200번 업데이트해야 합니다. 당신(데이터 버스)이 나를 보장해야 합니다. 이 알고리즘을 공급하는 모든 센서는 더 느리거나 더 빠르지 않은 빠른 속도로 데이터를 제공할 것을 약속합니다. 센서가 초당 1000번 업데이트되면 5번째 업데이트마다 저에게만 보내주십시오. 또한 현재 귀하가 실제로 연락하고 있는지 알아야 합니다. -가능한 모든 도로 접근 방식에서 항상 라이브 센서(최근 0.01초 동안 생성하는 것으로 정의) 모든 센서는 600개의 오래된 샘플(3초 분량)을 저장할 수 있어야 하며 필요한 경우 이전 데이터로 업데이트할 수 있어야 합니다. 그것." (이것은 DDS 표준의 20개 이상의 QoS 설정 중 일부입니다.)

기본 pub-sub의 경우 구독 응용 프로그램은 생산자의 실제 속성에 크게 의존합니다. 어떻게 해서든 자신이 살아 있고(!), 필요할 수 있는 정보를 저장하기에 충분한 버퍼가 있으며, 정보가 넘쳐나거나 너무 느리게 제공하지 않는다는 것을 믿어야 합니다. 10,000대의 자동차가 1000x/sec로 감지되고 있지만 200m 이내에 3개만 있는 경우 주의해야 할 3*200 =600을 찾기 위해 1초마다 10,000*1000 =10m 샘플을 수신해야 합니다. 활성 상태인지 확인하기 위해 모든 단일 센서를 초당 100회 핑해야 합니다. 다른 경로에 중복 센서가 있는 경우 모든 센서를 독립적으로 ping해야 하며 어떻게든 모든 경로가 포함되어 있는지 확인해야 합니다. 많은 응용 프로그램이 있는 경우 모두 독립적으로 모든 센서를 ping해야 합니다. 또한 생산자 등의 스키마를 알아야 합니다.

대조적으로 두 번째 경우의 애플리케이션은 관심 있는 정확히 600개의 샘플을 수신하며 각 경로에 대해 적어도 하나의 센서가 활성화되어 있다는 사실을 알고 편안합니다. 유량이 보장됩니다. 충분한 신뢰성이 보장됩니다. 총 데이터 흐름은 99.994% 감소합니다(600/10m 샘플만 필요하고 스마트 미들웨어는 소스에서 필터링을 수행합니다). 완전성을 위해 충돌 알고리즘은 센서 자체와 완전히 독립적입니다. 다른 교차로에서 재사용할 수 있으며 경로당 하나의 센서 또는 17개와 함께 작동합니다. 런타임 중에 네트워크가 너무 로드되어 데이터 사양을 충족하지 못하는 경우(또는 무언가가 실패하는 경우) 애플리케이션에 즉시 알림이 전송됩니다.

질문 5:데이터 버스는 CEP 엔진과 어떻게 다릅니까?

짧은 대답:데이터 버스는 기본적으로 분산된 개념으로, 간단한 사양과 일치하는 로컬 생산자로부터 데이터를 선택하여 전달합니다. CEP 엔진은 훨씬 더 복잡한 사양을 처리할 수 있지만 모든 데이터 스트림을 한 곳으로 보내야 하는 중앙 집중식 실행 서비스입니다.

긴 답변:CEP(복합 이벤트 처리) 엔진은 들어오는 데이터 스트림을 검사하여 식별하도록 프로그래밍한 패턴을 찾습니다. 이러한 패턴 중 하나를 찾으면 조치를 취하도록 프로그래밍할 수 있습니다. 패턴은 과거 데이터와 들어오는 미래 데이터의 복잡한 조합일 수 있습니다. 그러나 어딘가의 단일 CPU에서 실행되는 단일 서비스입니다. 정보를 전송하지 않습니다.

데이터 버스는 데이터 패턴도 찾습니다. 그러나 사양은 더 간단합니다. 생성되는 각 데이터 항목에 대한 결정을 내립니다. 작업도 더 간단합니다. 취할 수 있는 유일한 조치는 해당 데이터를 요청자에게 보내는 것입니다. 데이터 버스의 장점은 기본적으로 분산되어 있다는 것입니다. 검색은 잠재적으로 수백, 수천 또는 수백만 개의 노드에서 로컬로 발생합니다. 따라서 데이터 버스는 올바른 소스에서 올바른 데이터를 선택하여 올바른 위치로 보내는 매우 강력한 방법입니다. 데이터 버스는 가능한 모든 정보 소스에 대해 하나씩 해당 정보의 사용자가 자동으로 프로그래밍하는 분산된 CEP 엔진 세트와 같습니다. 물론 데이터 버스에는 스키마 조정, 중복 관리, 전송 지원, 상호 운용 가능한 프로토콜 등과 같은 패턴 일치 외에도 많은 다른 속성이 있습니다.

질문 6:DDS 표준과 데이터버스를 주도한 애플리케이션은 무엇입니까?

초기 응용 프로그램은 지능형 로봇, "정보 우위" 및 해군 전투 관리와 같은 대규모 조정 시스템에 있었습니다. 이러한 시스템은 구성 요소에 장애가 발생하더라도 안정성, 물리적 프로세스를 제어할 수 있을 만큼 빠른 데이터, 확장 가능한 선택적 검색 및 제공이 필요했습니다. 데이터 중심성은 실제로 애플리케이션 코드와 제어된 인터페이스를 단순화하여 프로그래머 팀이 시간이 지남에 따라 대규모 소프트웨어 시스템에서 작업할 수 있도록 합니다. DDS 표준은 원래 공급업체와 고객 모두에 의해 주도되었던 활발하고 성장하는 표준 제품군입니다. 의료, 교통, 스마트 시티, 에너지를 포함한 다양한 분야에서 많이 사용되고 있습니다.

지능형 소프트웨어가 IIoT를 휩쓸고 있는 방법에 대해 알아보려면 자동차 산업의 미래에 대한 백서 "자율주행 자동차의 비밀"을 다운로드하세요.