Ignite | IoT 솔루션 전수는 아래 그림에 표시된 초기 솔루션 설계를 위한 주요 아티팩트를 정의한다. 우리는 분석, 예측, 계획, 기능 설계 아티팩트 및 기술 설계 아티팩트를 포함하는 아티팩트들의 차이를 논한다. 그들은 병렬로 생성될 수 있지만, 이 부분에 기술된 바와 같이, 종종 그룹화하는 것이 합리적이다.

Ignite | IoT 솔루션 전수가 제안하는 일부 아티팩트, 예를 들어 이정표 계획은 항상 IoT에 특화된 것은 아니다. 일부 아티팩트는 IoT 솔루션을 위한 제안된 수량 구조 또는 SOA 랜드스케이프 등 IoT에 특화된 확장자를 가지고 있다. 그리고 일부 아티팩트는 IoT 프로젝트 차원, IoT 솔루션 스케치, 또는 자산 통합 아키텍처 등 IoT 솔루션 설계를 위해 특별히 만들어졌다. 책의 이 부분에서는 우리는 어떻게 프로젝트 팀이 설계 단계에서 이러한 아티팩트로 작업할 수 있는지에 더 집중할 것이다. 이러한 이유로, 우리는 여기에서 사례를 먼저 제공하고, 다음 “빌딩 블록” 부분에서 더 공식적인 정의를 제공할 것이다.

전문화된 설계 아티팩트는 소프트웨어 설계에서 긴 이력을 가지고 있다. 특히, 합리적인 통합 프로세스 (RUP)는 소프트웨어 프로젝트의 서로 다른 관점과 단계에 대한 전문 소프트웨어 설계 아티팩트의 완전한 집합을 기반으로 한다. RUP는 과거에 너무 많은 아티팩트를 기반으로 하여 일부 비판을 받았다. SCRUM같은 민첩한 접근법은 종종 아키텍쳐 아티팩트보다는 사용자 스토리 같은 아주 기본적인 아티팩트에 의존하고 있다. 민첩한 관점에서 “코드는 진리이다”. Ignite | IoT 솔루션 전수는 두 극단 사이에서 균형을 유지하려고 한다. 우리의 경험에 의하면, 이는 특정 표준화된 아키텍처와 설계 아티팩트에 의존하는 데 매우 도움이 될 수 있으며, 다른 프로젝트 이해관계자들이 이해를 같이하도록 보장한다. 이를 위해, Ignite | IoT 솔루션 전수는 아티팩트가 충분히 가벼우면서도 충분히 표현 가능하다는 것과 다른 유형의 아티팩트들이 중복을 최소화하면서 서로 잘 통합된다는 것을 보장해야 한다.

                            Initial IoT Solution Design

첫 번째 Ignite | IoT 설계 아티팩트는 분석, 예측, 계획을 지원하기 위한 것이다. 초기 문제 설정 또는 경영 요약서는 종종 사업 모델에서 가져온 것이다 (Ignite | IoT 전략 실행 참조). 자세한 분석은 이상적으로 자산과 환경에 더 깊은 통찰력을 제공하는 현장 조사를 포함한다. IoT 솔루션 스케치는 한 페이지로 된 높은 수준의 솔루션 설계 제안 개요이다. IoT 프로젝트 차원은 프로젝트 자체 평가를 지원한다. 수량 구조는 사용자와 자산 등 주요 개체의 계획된 성장을 살핀다. 마지막으로, 이정표 계획은 프로젝트의 주요한 단계를 정의한다.

위에서 말한 것처럼, 문제 설정 및 경영 요약서는 종종 사업 모델 단계에서 비롯된다. 이상적으로, 이는 사업 이해관계자가 쉽게 이해할 수 있는 언어를 사용하여 IoT 솔루션 문제 영역과 비전의 설명 한 페이지를 포함한다. 또한 핵심 솔루션 요소의 간단하고 직관적인 도표 개요를 제공한다. 아래 그림을 예로 참조하십시오.

                                 Executive summary
                                 

프로젝트 맥락에서 이해관계자 분석을 위한 많은 모범 사례 체계가 있다 (예를 들어, 참조 추후결정). Ignite | IoT는 이해관계자 분석을 위한 IoT 고유의 체계를 기반으로 하며, 이는 원래 Heinz Derenbach 박사 (Bosch Software Innovations의 전 CEO)와 그의 팀에 의해 고안되었다. 이 팀에서 배운 한 가지 중요한 교훈은 대부분의 IoT 솔루션이 이해관계자와 연관된 네 개의 핵심 요소 - 자산과 해당 장치, 관련 기업의 서비스, 솔루션 사용자 및 파트너로 구성되어 있다는 점이다. 아래 그림은 IoT 솔루션의 네 가지 핵심 요소에 대한 개요를 제공한다.

Four key elements of an IoT solution

우리의 경험에 의하면, 이 네 가지 핵심 요소와 그들 간의 상호 의존성을 확인하고 정의하는 것은 IoT 솔루션의 주요 측면과 이해관계자 분석을 위한 아주 좋은 출발점이 될 것이다. 어떤 경우, 이들 요소 중 일부는 일반적으로 그들 사이의 상호 의존성에 대한 상세한 조사 없이 이미 사업 모델 분석에 포함되었을 수도 있다.

초기 IoT 솔루션 설계의 일환으로, 우리는 현장 조사 실시를 강력하게 권장한다. 이는 이상적으로 자산이 제조되는 공장 또는 사용되는 장소 등 관련 현장에 실제 방문하는 것으로 시작한다. 이를 보완하기 위해, 자산의 다른 측면과 자산이 일반적으로 배치되는 현장 (해당하는 경우)에 대해서 전문가들과 함께 면접을 진행할 수 있다.

현장 조사 문서는 다음과 같은 모든 자산 및 현장 고유의 측면을 포함해야 한다.

• 자산의 유형 – 예를 들어, 정적/동적 자산

• 자산의 분류 – 산업 분야, 예를 들어 제조업 또는 CPG

• 자산의 가동 – 지능이 없는 자산 (맥주 통 또는 팔레트 등) 또는 지능이 있는 자산 (자판기, PLC, 자동차 등)

• 사업 운영 및 자산 라이프사이클

• 솔루션 통합 – 기본 또는 개조

• 자산 인터페이스 – ModBus, CAN 버스, MDB, 직렬 버스, GPIO 등

• 자산의 인터넷 연결 – 셀룰러, 이더넷, 와이파이 네트워크

• 자산의 환경적 조건 – 작동 온도 또는 자산 위치 등 (움직이는 컨테이너 또는 차량 내부, 공장, 소매점, 옥외 등)

• 전원 공급 요건, 센서 설치 요건

조사 결과의 일부는 나중에 IoT 프로젝트 차원에 통합될 수 있다 (아래 참조).

분석 결과에 기초하여, Ignite | IoT는 아래 그림에서 설명한 형식을 사용하여 높은 수준의 솔루션 스케치를 작성할 것을 권장한다. 이는 구조화된 형식으로 포착된 결과로, 종종 주요 이해관계자들이 참석하는 워크숍 중에 만들어질 수 있다.

                            IoT Solution Sketch                                                 

IoT 솔루션 스케치는 위의 “이해 관계자 분석” 부분에서 알아본 모든 네 가지 솔루션 요소를 포함하고 많은 중요 세부 사항을 추가한다. 예를 들어, 솔루션 스케치는 자산에서 백엔드까지 전송한 주요 사건 (또는 다른 주요 의사소통)을 식별하거나 정의하려고 시도한다. 또한, 핵심 UI, 사업 절차, 규칙 및 데이터 엔티티 (모두 리스트 형태로)를 포착한다. 게다가, 통합될 외부 파트너뿐만 아니라 데이터베이스 및 어플리케이션을 보여준다.

솔루션 스케치는 경영 요약서보다 더 자세하다. 그러나 핵심 개체에만 중점을 두며, 이러한 개체의 완전한 공식 목록을 제공하지는 않는다. 솔루션 스케치의 주요 목적은 솔루션의 범위를 좁히기 시작하고, 사업 및 기술 프로젝트 이해관계자들 간의 의사소통을 위한 공통의 기반을 만드는 것이다.

Ignite | IoT는 IoT 솔루션의 모든 중요한 측면을 포착하는 데 도움이 되는 일련의 IoT 프로젝트 차원을 정의한다. 현재 다섯 가지 주요 차원과 총 약 40개의 하위 차원이 있다. 다섯 가지 주요 차원은 다음과 같다.

• 자산 및 장치: 수와 자산 가치, 자산의 복잡성, 필수 자산 처리 능력, 하드웨어 요건 및 라이프사이클 관리 등의 측면을 포함

• 통신 및 연결: 기술, 대역폭, 지역 및 원격 통신 대기 시간에 초점

• 백엔드 서비스: 백엔드 사업 솔루션의 복잡성뿐만 아니라 데이터 관리의 특정 측면을 살핌

• 표준 및 규정 준수: 외부 프로젝트 환경과 연관

• 프로젝트 환경: 내부 프로젝트 환경을 검사

각 프로젝트 차원은 1 (단순)에서 4 (복잡)까지의 값의 정의뿐만 아니라, 1에서 4까지의 범위에 눈금을 부여 받는다. 이는 프로젝트 차원이 프로젝트 자체 평가의 시각적인 표현을 생성하는 데 사용될 수 있음을 의미하며, 아래 그림에 나타낸 바와 같이 Kiviat 다이어그램을 사용한 것이 그 예이다.

모든 Ignite | IoT 프로젝트 차원의 정의가 포함된 Excel 스프레드 시트는 온라인으로 이용 가능하다. 또한 다른 차원들의 보다 더 상세한 정의는 이후 “빌딩 블록” 부분에서 제공된다. 아래 그림에 나타난 바와 같이, 이 단계에서 프로젝트 차원의 주 목적은 프로젝트에 대한 그들 스스로의 평가 (자기 평가)를 수행하는 프로젝트 관리자를 도와 체크리스트를 제공하는 것이다. 결과는 솔루션 아키텍처 및 설계 결정을 위한 투입뿐만 아니라 중요한 영역과 프로젝트 위험을 확인하는데 사용될 수 있다. 또한, Ignite | IoT 팀은 현재 그들의 자기 평가 결과를 우리에게 제공 한 다양한 프로젝트의 데이터베이스를 구축하고 있다. 이는 프로젝트 관리자가 다른 사람들의 것과 자신의 프로젝트를 비교하고, 얻은 교훈으로부터 혜택을 누릴 수 있게 한다.

                          IoT Project Dimensions
                          

모든 솔루션 설계와 마찬가지로, IoT 프로젝트는 수량 구조를 필요로 한다. 수량 구조는 밀접하게 사업 이해관계자의 요구 사항에 부합되어야 하며, 주요 영역에 계획된 성장을 보여주어야 한다.

IoT의 관점에서, 이 영역들은 다음을 포함한다: 시간이 지남에 따라 자산의 수, 자산에서 백엔드로 보낸 사건의 수, 사용자 수 (총 사용자 수 및 동시 사용자 수), 연간 프로세스 인스턴스의 수 (자산 활성화, 사건 등 핵심 과정). 이 정보는 솔루션 설계자에게 매우 중요할 것이다.

                              IoT quantity structure
                              

마지막으로, 일반적인 프로젝트와 마찬가지로 IoT 솔루션 프로젝트의 초기 솔루션 설계는 이정표 계획을 포함해야 한다. 이 계획은 일부 정상적인 이정표와 일부 IoT에 특화된 이정표를 포함한다.

• 생산 또는 구매 의사결정

• 공급 업체 선정

• 시제품

• 모의/현장 테스트

• SOP /생산 시작 (하드웨어)

• 백엔드 솔루션의 초기 출시

마일스톤 계획을 구조화 할 때, 자산 구성 요소를 위한 하나와 백엔드를 위한 하나, 두 개의 별도 타임라인을 가질 수 있도록 할 수 있으며, 이는 이들간의 주요 의존성을 포함하도록 한다.

이 단계에서 Ignite | IoT 방법론에 의해 제안된 기능 설계의 세부 사항 수준은 RFP (제안 요청)에의 가벼운 응답에서 찾을 수 있는 것의 전형이다. 이는 특히 세부 요구 사항을 수집하고 관리하기 위해 준비된 제품 백로그로의 민첩한 접근법을 사용할 경우, 프로젝트 실행 단계를 시작하기에 충분해야 한다. 여기에 설명된 기능 설계는, 예를 들면 고정 가격 제안의 상세 요건을 충족하도록 의도된 것은 아니다.

기능 설계를 만들기 위한 좋은 첫 단계는 가장 중요한 사용 사례에 대한 높은 수준의 분류를 정립하는 것이다 (엄밀히 말하자면, 초기 사용 사례 분류가 원래 분석의 일부로서 만들어져야 하지만 이것이 중요 설계 아티팩트이기 때문에 우리는 이것을 여기에 포함시킨다). IoT 솔루션의 경우, 이러한 사용 사례는 종종 자산 라이프사이클을 좀 더 자세히 봄으로써 식별될 수 있다 (서론의 연결된 자산 라이프사이클 관리에 대한 설명 참조). 각 사용 사례 정의는 정립된 사용 사례 설계에 대한 모범 사례를 따라야 하며 (참조 추후결정), 관련된 이해관계자/역할과 활동에 대한 높은 수준의 설명을 제공한다.

대안적으로, 더 과정 지향적인 조직에서는 과정 중심 접근법이 사용될 수 있다. 이 경우 사용 사례 분류 대신에, 솔루션에 대한 과정 가치 사슬이 (다시, 아마도 자산 라이프사이클을 기반으로) 만들어질 수 있다. 선택된 과정의 경우, 예를 들면 ePC 또는 BPMN를 사용하여 과정 흐름도를 이용하는 것도 가능하다. 그러나 이 경우, 우리는 “행복 경로” 과정 흐름에 중점을 둔 상당히 높은 수준을 고수할 것을 권장한다.

취한 접근법에 관계없이, 이 작품은 일반적으로 솔루션 설계자의 지원으로 팀의 사업 분석가에 의해 수행된다. 많은 사업 분석가 및 솔루션 설계자는 그들의 생각을 고도로 구조화하며, 구조화 된 접근법을 사용하여 기능 설계 과정을 시작하고자 한다. 그러나 기능 설계의 핵심은 최종 사용자 및 사업 이해관계자들과의 긴밀한 상호 작용이다. 그리고 이 집단 내에서, 우리는 종종 생각이 덜 구조화된 사람들을 찾을 수 있다. 종종 이 사람들은 추상적인 생각을 좋아하지 않으며, 예를 들어 UI 모형에 의해 제공되는 간단한 시각화를 선호한다. 이 집단의 많은 사람들이 어플리케이션 관점에서 생각하기 때문에, 이러한 관점에서 그들에게 말함으로써 효과적인 의사소통을 보장하는 것이 중요하다.

이것이 Ignite | IoT가 솔루션의 주요 사용자 인터페이스 (UI)와 인간 기계 인터페이스 (HMI)에 대한 초기 모형 생성을 권장하는 이유이다. 이 모형은 가벼우면서도 위에서 언급한 사용 사례 또는 가치 사슬 분석의 일환으로 확인된 주요 인터페이스에 초점을 맞추어야 한다. 모형은 아이디어 토론과 최종 사용자 및 사업 이해관계자의 요건 검증을 위한 이상적인 기반을 제공한다. 그들은 또한 중요한 데이터 엔티티, 사용 사례, 과정, 사건 등의 관점에서 전체 그림을 식별하고 포착할 수 있다. IoT 솔루션의 경우, 다음과 같은 모형은 일반적으로 다음과 연관된다.

• HMI: 자산 사용자 및 자산 관리자 인터페이스 (예를 들어 기계 HMI 디스플레이, 원격 웹 인터페이스, 자동차 내장 디스플레이 등)

• 최종 사용자 셀프 서비스 인터페이스: 사용자 계정 관리, 개인 사용 통계 등

• 과정 지원 인터페이스: 예를 들어 콜센터 직원을 위한 UI

• 파트너 인터페이스: 솔루션 파트너를 위한 UI, 외부 지원 제공을 위한 사건 관리

아마 위에서 설명한 모형 접근법은 매우 초기 단계에서는 구성되지는 않을 것이다. 이는 사용자 관점에 매우 중점을 두며 과정, 알고리즘, 블랙 박스 관점 같은 것을 본다. 이 때문에 Ignite | IoT 는 더 구조화되고 IoT에 특화된 설계 방식을 취하는 것을 권장한다 (다시, 분석 및 설계의 경계는 흑과 백이 아니다).

대부분의 IoT 프로젝트는 사업 모델의 핵심적인 부분이 되는 특정 이론을 발전시킨다. 예를 들어, CERN의 직원들은 아인슈타인까지 거슬러 올라가는 물리적 이론을 기반으로 대형 강입자 충돌기 (LHC)를 구축한다. 또는 구글과 Nest의 경우, 구글이 스마트 홈 기술 제공자 Nest의 인수를 통해 얻은 데이터 실행 가능 분석의 종류에 대한 가정을 했을 것이다.

이러한 이론의 한 가지 문제점은 입증될 때까지 아무도 확실히 알지 못한다는 것이다. 그리고 특히 사람들이 센서 데이터/빅 데이터에 의해 움직이는 IoT 세계에서 많은 이론과 사업 모델 가정은 수집한 데이터에서 학습함에 따라 시간이 지나면서 발전한다.

많은 IoT 프로젝트의 경우, 센서 데이터에 기반한 실제 세계의 디지털 모델 생성은 검증될 이론 및 가정의 기초가 된다. 디지털 모델의 신중한 설계 과정이 솔루션 설계 과정의 핵심인 이유이다. 사업 모델에서 만들어진 가정은 디지털 모델의 단위를 이끌어내야 할 것이다. 또한 다음과 같은 중요한 질문들에 대답할 수 있어야 한다.

• 어떤 데이터 엔티티를 수집해야 하는가?

• 얼마나 자주?

• 어떤 수준의 정확도로?

축구 게임의 예를 들자면, 비지니스 모델의 관점에서 우리는 충분한 각 게임의 결과를 수집하는 도박 기관이다. 누가 그리고 언제 골을 넣었는가와 같은 각각의 골에 대한 정보를 필요로 하지는 않는다. 우리가 축구 팀의 코치인 경우, 우리의 사업 모델은 우리가 지속적으로 팀 성과를 최적화 할 것을 요구한다. 그래서 이 경우 우리의 디지털 모델은 게임의 지속 기간 동안 각 선수의 위치를 추적하는 열지도에 가까운 것이다. 몇몇 팀은 이미 개별 선수의 성과 향상을 가능하게 하는 고정밀 위치 시스템 및 모션 캡쳐 기술을 이용하여 개별 선수의 상세한 움직임을 추적하기 시작했다. 3D로 시각화 할 때, 이 모델은 실제 게임과 매우 유사하게 보인다.

보다 상세한 디지털 모델의 생성이 프로젝트 실행, 데이터 전송 및 운영 비용을 극적으로 증가시킬 수 있음을 유의해야 한다. 당신은 많은 사례에서 어떻게 매우 간단한 디지털 모델이 강력한 사업 모델을 만들 수 있는가에 놀라게 될 것이다.

설계 과정의 다음 질문은 데이터를 수집하는데 사용될 수 있는 시작 지점에 관한 것으로, 어떤 종류의 센서를 사용할 수 있는가? 그들은 어디에 위치될 수 있는가? 어떻게 원격으로 접근될 수 있는가? 충분한 전원 공급을 보장하는 가장 좋은 방법은 무엇인가? 등이다. 이를 간단한 축구 예시에 적용해 보면 다음과 같다. 어떻게 당신은 실제로 골이 득점했다는 사실을 포착할 수 있는가? 최근까지, 축구 리그들은 골 라인 기술을 거의 허용하거나 필요로 하지 않았다. 따라서 필요한 정보를 수집하는 직접적인 방법이 없는 경우, 당신의 선택지는 무엇인가? 당신은 큰 소리의 박수 또는 항의가 골을 나타낸다고 가정하고, 박수를 측정하기 위해 축구 경기장에 마이크 시스템을 배치할 수 있겠는가?

이는 다음 단계인 “복원” 단계로 연결된다. 우리는 센서로부터 수집된 데이터가 필요한 디지털 모델에 반드시 직접 매핑하지는 않는다는 것을 볼 수 있다. 이 경우, 우리는 이용 가능한 센서 판독 및 사건 등을 가져오는 과정을 수행하고, 사업 모델을 지원하기 위해 필요한 디지털 모델을 만드는데 이 데이터를 이용한다.

명백히 인위적인 예를 들자면, 위의 간단한 축구 시나리오의 복원 과정은 실제로 골을 득점할 팀을 결정하기 위해 홈에서 경기하는 팀에 대한 정보와 큰 소리의 박수 또는 항의에 대한 정보를 결합할 수 있다.

복원 과정의 보다 현실적인 예로, 위치 기반 쇼핑 추천을 위해 소매 상점에서 고객의 움직임을 추적하도록 표지를 사용하는 IoT 솔루션을 살펴 보자. 이 예에서, 복원 과정의 첫 번째 부분은 고객의 실제 3D 좌표에 특정 표지 정보 (거리, 표지의 위치 등)를 매핑하는 것이다. 다음 단계는 추천 엔진이 작업을 수행 할 수 있도록, 잠재적 관심 영역에 고객의 위치를 매핑하는 것이다.

이 복원의 극단적인 개념을 보여주고, 실제 이 개념의 사용하도록 했던 한 가지 예는 Part I에 설명 된 CERN/LHCb 사례 연구이다.

• LHCb는 낮은 수준의 아날로그 데이터를 얻기 위해 백만 개 이상의 센서를 배치한다

• 고도로 복잡한 여러 단계의 복원 과정이 이러한 아날로그 사건을 각 개별 센서의 3D 좌표와 결합하여 각 입자의 충돌을 유도한다

• 결과는 충돌 후 각 개별 입자 궤도의 3 차원 모형이다

• 충돌의 디지털 모델을 기반으로, 물리학자들은 입자 충돌에 대한 물리학 이론을 검증할 수 있다

이 예는 복원 개념이 IoT 세계에서 얼마나 중요한지 보여준다 (당신이 이것을 올바로 할 수 있을 경우, 분명히 노벨상을 받을 수 있다). 특히 더 복잡한 디지털 모델 및 센서 데이터에 의존하는 IoT 솔루션의 경우, Ignite | IoT 방법론은 디지털 모델과 해당 복원 과정을 정의하는데 충분한 시간과 자원을 투자할 것을 권장한다.

                      Structured IoT analysis and design approach
                      

솔루션 설계자가 디지털 모델 설계 및 복원 과정 사이에 좋은 조합이 있다는 것을 확신할 경우, 이들은 설계 과정의 다음 단계에서 추상적 개념으로 이 디지털 모델을 사용할 수 있다. 우리가 보는 바와 같이, IoT 솔루션의 디지털 모델은 여러 측면을 지닐 수 있다. 그 핵심에서, 우리는 사업 데이터 중심의 기술 독립적 통합 형태을 제공하는 영역 모형 (아래 참조)을 만들 것을 권장한다. 시간이 지남에 따라, 이 모형은 사건, 구성 요소, 과정 등을 포함하도록 갱신될 필요가 있을 것이다. 영역 모형부터 시작해 보자.

영역 모형

영역 모형은 새롭지도 않으며 IoT에 특화된 것도 아니다. 그러나, 이 모형은 IoT 솔루션 핵심 데이터 엔티티에 대한 사업 중심의 통합된 관점을 만드는 데 강력한 도구가 될 수 있다. 우리는 영역 모형에 매우 기본적인 UML 요소를 사용할 것을 권장한다.

• 등급

• 속성

• 제휴

• 집단

• 상속/전문화

IoT 솔루션의 핵심 개체를 식별하기 위한 좋은 출발점은 앞에서 설명한 이해관계자 분석의 4 가지 핵심 요소이다.

• 자산 및 장치: 하나의 개체와 다섯 가지 핵심 개체를 동일시한다. 자산 및 장치의 어떤 속성이 특히 중요한가?

• 최종 사용자: 사용자 및 자산 소유자, 백 오피스 직원 등의 전문화

• 기업: 예를 들어 자산과 사용자 사이의 관계를 정의하는 핵심 개체로서의 “리스”

• 파트너: 예를 들어, 사건의 할당,

넓은 차원에서, 영역 모형은 핵심 개체와 가장 중요한 관계에 초점을 맞추어야 한다. 무엇을 생략할지 아는 것은 때때로 핵심 개체를 식별하는 것만큼 까다로운 일이 될 수 있다. 이에 대한 조언은 다음과 같다.

• “1980년대 개체/관계의 바탕 화면”을 피해라 – 영역 모형은 일반적으로 15 ~ 30 개 사이의 개체를 갖는다

• 위에 설명한 바와 같이 간단한 UML을 사용해라

• 일정 수준의 “모호함” 허용: 이 NoSQL 데이터베이스 시대와 모든 유형의 데이터를 사전에 알 수 없는 IoT 같은 환경에서 특히 중요하다

우리가 볼 수 있는 바와 같이, 영역 모형의 주요 이점 중 하나는 다른 솔루션 단계들에 걸쳐 분포된 데이터의 시각적 표현을 생성하는 기능이다. SOA (서비스 지향 아키텍처)를 활용하여, 우리는 영역 모형에서 다른 구성 요소까지의 개체를 매핑할 수 있다.

IoT domain model

자산 통합 아키텍쳐 (AIA)

자산 통합 아키텍쳐 (AIA)는 명백하게 IoT 솔루션을 위해 개발된 설계 접근법이다. 높은 수준의 개념 설명은 서론에서 이미 제공되었다. 두 가지 주요 단계인 자산과 기업은 여기서 소개된다. 이 두 단계는 IoT 클라우드 (또는 M2M 플랫폼)을 통해 통합된다. 자산에서, 로컬 게이트웨이와 에이전트 소프트웨어는 자산의 일부를 구성하는 다른 장치들과의 통합을 허용한다. 게이트웨이는 또한 백엔드와의 연결을 보장한다. 백엔드에서, IoT 클라우드는 일반적으로 시스템에 등록된 모든 자산에 대한 정보를 포함하는 통합 데이터베이스를 가진다. IoT 클라우드는 이 정보가 자산으로부터의 실제 데이터와 동기화되는 것을 보장한다. IoT 클라우드 백엔드는 일반적으로 자산 및 장치에 특화된 데이터와 기능을 포함하며, 추가 사업 서비스를 제공하는 백엔드 어플리케이션과 통합되어 있다.

                           AIA example: eCall service
                             

위의 예는 eCall 서비스의 AIA를 보여준다. eCall 솔루션은 백엔드에 있는 콜 센터 어플리케이션으로 구성되어 있으며, 이는 소위 PSAP (공공 안전 응답 지점)와 통합된다. 백엔드는 또한 eCall 사건 처리 하위 시스템을 포함하고 있으며, 이는 잠재적인 충돌 상황에 있는 차량으로부터 사건을 수신한다. 이러한 사건들은 차내 TCU (텔레매틱스 제어 장치)에서 전송된다. TCU의 주요 목적은 게이트웨이로서 작용하는 것이지만, 또한 로컬로 실행되는 일부 제한된 비지니스 로직뿐만 아니라 솔루션의 일부를 형성하는 가속도 센서를 갖는다. 또한, TCU는 CAN 버스를 통해 에어백과 통합된다.

AIA의 주요 목적은 표준화된 방식으로 IoT 솔루션의 상이한 설계 요소를 제시하고, IoT 솔루션에 다른 설계 요소의 분배에 대한 정보를 제공하는데 사용될 수 있는 캔버스를 제공하는 것이다.

데이터 분배 Data Distribution

이제 우리는 영역 모형 및 자산 통합 아키텍처의 개념에 친숙해졌기 때문에, 우리는 데이터 분배를 다루기 위해 이 두 개념을 결합할 수 있다. 이는 모든 IoT 솔루션의 매우 중요한 측면이다. 순 데이터 분배 설계는 중요한 성능 문제와 불필요한 통신 비용을 초래할 수 있다.

영역 모형에서 확인된 각각의 개체에 대해, 이 작업은 개체들이 AIA어디에 존재하는지 확인하는 것이며, 이는 설계 (그린 필드)에 의해, 또는 그들이 이미 했기 때문에 (브라운 필드) 일어난다. 데이터 분배와 밀접한 관련된 것은 주요 비지니스 규칙의 분배이다.

AIA and data distribution

숙련된 솔루션 설계자는 일반적으로 데이터 및 비지니스 규칙 분배에 적용되는 주요 제약에 대한 훌룽한 개관을 가지며, AIA의 다른 단계들 간 대기 시간 및 대역폭, 로컬 스토리지 제한, 처리 제한 등이 있다. 이러한 제약들과 원본 분석으로부터의 수량 구조 정보 (예를 들어, 예상 자산의 수 등)를 결합함으로써, 데이터 개체와 AIA 규칙을 맵핑하여 데이터 분배 설계를 위한 초기 제안을 만들 수 있다.

예를 들어, 스마트 홈 솔루션이 실온 및 기상 예보에 기초하여 결정하는 중요한 비지니스 규칙을 필요로 한다고 하자. 이 경우, 솔루션 설계자에게는 두 가지 선택지가 있다.

• A (로컬 규칙): 정기적으로 스마트 가전기기에 일기 예보 데이터를 푸쉬하고 로컬 규칙을 실행

• B (백엔드 규칙): 결정이 필요할 때마다 백엔드로 현재 실온 데이터를 보내고 백엔드에서 규칙을 실행

‘옵션 A가 백엔드에서 가전기기로 일기 예보를 푸쉬하는 것의 결과로 얼마나 많은 데이터 트래픽을 발생시킬 것인가?’ 대 ‘옵션 B 가 가전기기에서 백엔드로 데이터를 푸쉬하는 것의 결과로 얼마나 많은 트래픽을 발생시킬 것인가?’로 상충관계가 분명하다. 고려해야 할 많은 요인으로 가전 제품의 수, 필요한 업데이트 빈도 및 날씨 예보를 위한 데이터 크기, 가전 기기당 평균 규칙 실행 횟수 등이 있다.

상대적으로 간단한 예제와 그 결과로 초래되는 복잡한 분석은 데이터 및 사업 규칙에 대한 효율적인 분배 설계가 IoT 솔루션의 성공에 중요한 이유를 명확하게 보여준다.

SOA 랜드스케이프

위의 논의와 밀접하게 연관되는 것은 소프트웨어 컴포넌트화라는 주제이다. 한번 과장해보자면, 서비스 지향 아키텍처 (SOA)는 긴 학습 곡선을 지나와, 지금은 많은 사람들에게 분배된 상이한 소프트웨어 시스템과 연관된 문제를 해결하기 위한 매력적이지는 않지만 필요한 접근법으로 보여진다.

SOA는 전형적으로 두 가지 관점, 기술 프로토콜 관점 (REST 대 Web Services)과 기능적 관점을 지닌다. IoT 기술 프로토콜 표준화의 전체 영역은 여전히 매우 역동적이기 때문에, 우리는 여기에서 후자인 기능적 관점에 초점을 맞출 것이다. (추후결정: 기업 SOA 및 기업 BPM 참조)에서 설명한 바와 같이, 기능적 관점은 UI, 프로세스 로직, 결합, 기본/데이터 중심 서비스 등의 기반 기술로부터 독립적으로 어플리케이션 사일로에 걸쳐 적용될 수 있는 SOA의 4 핵심 단계를 정의한다. SOA 관점을 통해 이질적인 어플리케이션 현황을 보는 것의 이점은 어떤 어플리케이션 사일로가 어떤 데이터와 어떤 과정을 소유하고 있는지 신속히 투명화한다는 점이다.

이것은 일반적으로 얻기 어려운 중요한 정보이다. 또한, 이 관점은 비기술적 수준에서의 소프트웨어 구성 요소 및 종속성을 확인하는데 도움이 된다. 이는 예를 들어 위의 데이터 및 논리 분배 논의에 흥미 요소가 될 수 있다. 설계 과정의 나중 단계에서는 핵심 소프트웨어 구성 요소 및 인터페이스에 대한 기술 독립적 문서화의 제공도 중요해진다. 많은 경우, 위키 기반 접근 방식은 연관된 오버헤드 때문에 기술적 SOA 저장소보다 선호된다.

네트워크 대기 시간 및 대역폭 제한을 가진 분산 시스템에서 구성 요소 인터페이스 설계는 최대한 효율적이어야 한다. 분산 객체 컴퓨팅 (CORBA, DCOM, J2EE)으로부터의 경험은 복잡한 객체의 상호 작용 패턴이 대부분의 분산 시스템에 적합하지 않다는 것을 보여준다. 대신, 더 간단하고 편안한 서비스가 도입되었다. 아무것도 더 적용하지 않을 경우, 높은 대기 시간, 네트워크 서비스 중단 및 기타 문제 등의 측면들이 IoT의 개방성 때문에 하나의 요인 이상이 된다는 것을 고려하면, 같은 패턴과 제약은 IoT 소프트웨어 구성 요소 설계에도 적용된다.

따라서 Ignite | IoT는 SOA 아키텍처 설계에 대한 기존 모범 사례를 기반으로 하여 이를 IoT로 확장 할 것을 제안한다. SOA 관점에서, 자산에서 실행되는 어플리케이션은 어떤 다른 어플리케이션과도 다르지 않다. SOA는 기술 독립적 관점을 취하고 있기 때문에, 이미 이질적인 Java, COBOL 및 PL/1 코드의 SOA의 세계에 내장형 어플리케이션과 실시간 운영 체제를 추가하는 것은 아무런 영향이 없어야 한다. 아래 그림에서 알 수 있는 바와 같이, Ignite | IoT 는 오른쪽에 자산 부분을 추가하고 HMI (인간 기계 상호작용)를 포함하도록 UI 레이어를 확장함으로써, 익숙한 SOA 맵 도면으로 확장할 것을 제안한다 (추후결정: 기업 SOA 및 기업 BPM 참조).

이러한 유형의 SOA 맵은 IoT 솔루션의 일부로서 통합 또는 개발될 필요가 있는 주요 소프트웨어 구성 요소를 식별하는 것을 도와주어 매우 중요하다. SOA 관점은 SOA의 주된 초점이 주요 소프트웨어 구성 요소 및 그들의 주요 사업 기능을 투명하게 한다는 점에서 위에서 설명된 자산 통합 아키텍처 (AIA)의 관점과는 다르다. 여기에 제시된 SOA 관점은 기술 독립적이며, 사업 기능에 초점을 맞춘다. 반면 AIA는 더 시스템적인 관점을 취하며, 사용된 구체적인 기술에 대한 참조를 가능한 한 포함한다.

SOA landscape

마지막으로, 기술 설계는 솔루션의 소프트웨어 아키텍처, 하드웨어 설계 및 기술 인프라의 개요를 제공한다.

소프트웨어 아키텍쳐는 핵심 소프트웨어 구성 요소와 이들의 종속성을 정의해야 한다.

• 자산 상 OS/펌웨어, 어플리케이션 컨테이너, 미들웨어

• 백엔드 OS, 어플리케이션 컨테이너, 미들웨어 (전자 통신, BPM, BRM 등)

• 데이터베이스 기술 및 라이브러리

• ID 관리, 보안 기술, 인증서 관리 등

• 중요 소프트웨어 라이브러리 및 오픈 소스 구성 요소

• 자산 소프트웨어 업데이트 인프라

• 개발 도구

하드웨어 설계는 IoT 솔루션에 특화된 이러한 구성 요소, 보통 자산 상 하드웨어에 중점을 두어야 한다. 이 단계에서 일반적인 수준의 세부 사항은 다음을 포함해야 한다.

• 다음과 같은 요소로 구성된 게이트웨이 등의 자산 상 하드웨어: CPU, 메모리, 로컬 인터페이스, 셀룰러 모뎀, 지역 무선 연결, 안테나, 케이스, 분포된 센서 노드 등

• 자산에 위치 및 장착

• 분포된 센서 노드를 배치할 경우, 자산에 이러한 노드를 위치 및 장착

Hardware design

맞춤형 하드웨어 개발의 경우, 다음 수준의 하드웨어 설계 세부 사항은 주요 구성 요소, 즉 CPU, 메모리, 전원, 디지털 I/O, 통신 모듈 등을 다룬다. 아래 도표는 서론에서 기술된 바와 같이 eCall 서비스 텔레매틱스 장치의 메인 보드 설계 예시를 보여준다.

                   Detailed hardware design (source: peiker group)
                   

기술 인프라의 설계는 개별 솔루션, 특히 사용된 네트워크 인프라에 고도로 특화될 것이다. Alcatel-Lucent의 예는 아래 그림에서 볼 수 있다 (참조 추후결정).

                               Technical infrastructure