첫 번째 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
                               

Stefan Schuster와 Julian Bartholomeyczik는 모두 Bosch Connected Devices and Solutions (BCDS)에서 일한다. BCDS는 혁신적인 연결 장치와 IoT 맞춤형 솔루션을 개발하고 판매하는 Bosch의 사업부이다. 다음의 설명은 IoT 센서 네트워크에 대한 솔루션 스케치 작성의 예시를 제공한다.

Dirk Slama: IoT 센서 네트워크에 대한 샘플 솔루션 스케치에 대해 우리에게 설명해주실 수 있을까요?

Stefan Schuster and Julian Bartholomeyczik: 물론이죠. 솔루션 스케치는 문제 공간 (프로젝트 작업 집합)과 솔루션 공간 (이 작업을 해결하는 기술 솔루션) 모두를 포함합니다. 솔루션 스케치를 작성하기 위한 두 가지 접근 방법으로, 하향식과 상향식 방법이 있습니다.

용어와 일반적인 접근 방법에 대해 간단히 살펴 봅시다. 예를 들어 우리는 어떻게 초기 단계에서 기계의 마모를 확인할 수 있는가? 와 같은 질문의 형태로 작업이 정해져 있는 경우, 하향식 절차라고 말합니다. 이 작업을 완수하는 기술 솔루션이 만들어지며, 구성 요소들은 그에 맞춰 설계되고 만들어 집니다.

상향식 절차에서 기술 솔루션의 구성 요소는 예를 들어 기존의 플랫폼, 센서, 또는 알고리즘의 형태로 이미 존재하고 있습니다. 이 프로젝트는 사실상 탐험입니다. 이 경우 전형적인 미결 문제는 다음과 같습니다. “우리가 이 데이터/센서를 이용하여 기계에서 감지할 수 있는 것은 무엇인가?”

프로젝트를 가속화하기 위해, BCDS는 센서 네트워크 개발 키트를 포함하는 플랫폼 구성 키트를 만들었습니다. 이 키트는 모든 종류의 다른 어플리케이션에 대한 광범위 센서를 포함하고 있습니다.

실제로, 프로젝트는 이러한 두 절차의 조합을 이용하여 만들어집니다. 예를 들어 플랫폼은 양 방향에서 접근할 수 있습니다. 플랫폼은 어플리케이션 프로젝트의 상위 집합으로서 위에서 아래로 설계되거나, 기존 기술 구성 요소의 집합으로서 아래에서 위로 설계될 수도 있습니다. 어플리케이션 프로젝트는 전부 하향식으로 솔루션을 정의하지 않습니다. 대신, 그들은 기존 구성 요소, 예를 들어 플랫폼을 사용합니다.

구체적인 예시를 들어봅시다. 우리가 효율적으로 유지 보수 기간을 계획하기 위해, 기계 회전 부분의 마모를 초기에 발견할 수 있도록 하고 싶다고 합시다.

첫째, 이 프로젝트는 가능한 한 독립적으로 정확하게 실행되도록 정의되어야 합니다. 하나의 실행 가능성을 너무 빨리 결정하는 것은 너무 이른 시기에 솔루션 공간을 좁혀버릴 수 있으므로 피해야 합니다.

기능적 요건 외에도, 솔루션 체계를 정의하는 시스템 요건도 지켜져야 합니다. 이는 비용 제한, 시스템 작동 환경, 기존 시스템의 인터페이스 설정을 포함합니다.

Dirk Slama: 그렇다면 좋은 요건은 무엇입니까?

Stefan Schuster and Julian Bartholomeyczik: 핵심 질문은 다음과 같습니다. 사용자가 시스템으로부터 배우고 싶어하는 것은 무엇인가? 시스템이 수행해야 하는 작업은 무엇이며, 언제 그리고 어떤 조건에서 수행해야 하는가? 기본적인 경제 조건은 무엇이며, 어떤 환경에서 시스템이 작동해야 하는가?

이 예시에서, 사용자는 시스템이 적시에 기계 마모에 대해 알려주길 원합니다. 기계는 산업 환경에서 작동됩니다. 우리는 처리 통제 시스템이 이미 존재하며, TCP/IP를 통해 접속될 수 있다고 가정합니다. 우리는 잠재 고객이 기계 모니터링에 기꺼이 지불하고자 하는 가격을 설정하며, 그 결과 센서 노드 제조 목표 가격이 €30가 됩니다. 시스템은 케이블을 사용하지 않고 연결되어야 하며, 배터리 수명은 1 년이 되어야 합니다.

기능 부품의 경우, 우리가 작업을 수행하기 위해 시스템에 필요한 데이터를 유도할 수 있는 이론이 정립된다. 이 예에서, 기계의 마모 및 눈물 이론 상태는 기계 침대에서 증가 진동을 통해 확인할 수 있다. 이론적으로 이런 종류의 보통 (기계 익숙한 즉 엔지니어) 도메인 전문가에 의해 정의된다. 이 예시에서, 이론은 기계의 마모가 기계판에서의 증가된 진동을 통해 확인될 수 있다고 말한다. 이런 종류의 이론은 보통 영역 전문가 (즉, 기계에 친숙한 엔지니어)에 의해 정의된다.

이상적으로, 이론이 먼저 입증되어야 합니다. 이 예시에서, 이는 두 기계를 측정함으로써 이루어집니다. 하나는 적절한 작업 조건에 있는 기계이고, 하나는 당신이 시스템을 확인해야 하는 조건 (부품이 마모되는지)에 있는 기계입니다. 이러한 유형의 입증 절차는 이론을 확인하고 (부품이 마모될 때 진동이 증가한다) 적절한 센서를 선택하기 위해 (센서를 이용하여 테스트 시행) 사용될 수 있습니다. 또한 장착 위치 또는 일련의 적절한 장착 위치가 이 단계에서 결정되도록 합니다. 이러한 위치로부터 다른 변수들은 액체 및 온도에 이용 가능한 공간과 저항 등으로 결정될 수 있습니다.

이론이 검증되면, 디지털 모델로 변환됩니다. 이 예에서 취해진 측정은 진동, 주파수, 마모 정도에 따른 파라미터 변화 정도에 대한 정보를 제공합니다. 이상적으로, 측정은 기계 간 변화를 알아내기 위해 여러 기계에서 취해집니다.

센서는 디지털 모델, 비기능 요건, 검증 프로세스로부터 얻은 경험에 근거하여 선택됩니다. 기존의 데이터 또한 활용될 수 있습니다 (예를 들어, 처리 통제 시스템은 이미 엔진의 회전 속도를 알고 있는가?). 따라서 데이터 수집 지점은 정확하게 명시됩니다. 그리고 최종 단계에서, 시스템은 이제 “솔루션 스케치”에 해당됩니다. 우리의 중점이 백엔드가 아닌, 여기 센서 관점에 있다는 것에 주목해 주십시오.

이 예에서 설계된 센서 시스템은 기계의 축 베어링 지점 가까이에 장착됩니다. 그것은 배터리에 의해 전원이 공급되며 무선으로 데이터를 전송합니다. 여기서 중요한 결정은 디지털 모델이 실행되는 장소와 관련된 것입니다. 다음은 두 가지 가능한 시나리오입니다. 첫 번째 시나리오에서, 모델은 센서 노드에서 실행됩니다. 이는 기계가 일정 마모 수준에 도달 할 때 간단한 메시지가 상위 시스템으로 전송된다는 것을 의미합니다. 두 번째 시나리오에서, 디지털 모델은 중앙 통제 시스템에서 실행되며, 이는 센서 데이터가 전송되고 마모가 상위 시스템에서 계산된다는 것을 의미합니다.

이 결정은 특히 다음 고려 사항에 의해 일어납니다:

• 센서 노드의 에너지 요건: 데이터를 전송하는 것은 많은 에너지를 필요로 한다. 센서 노드를 미리 처리하는 것은 데이터 전송 요구를 감소시킨다.

• 이용 가능한 처리 능력 및 데이터: 데이터 처리가 지정된 경제적 한계 내 센서 노드에 실현 불가능한 처리 능력을 필요로 할 수 있다. 다른 소스로부터 추가적인 데이터가 정확한 계산을 보장하기 위해 필요한 경우, 필요한 모든 데이터가 이용 가능한 곳에서 계산은 수행될 수 있다.

• 노하우 보호 및 공급 부문: 알고리즘이 보호될 필요가 있으며, 그것이 센서 제조자에 의해 만들어졌다면, 그 다음 노드에서의 실행이 일어날 수 있다.

이 예에서, 알고리즘은 모든 필요한 데이터가 이용 가능하고, 처리 능력이 낮으며 전지 수명이 필수적일 때, 센서 노드에서 실행됩니다.

Dirk Slama: 감사합니다. 마지막으로, 솔루션 스케치의 핵심 구성 요소들에 대해 간단하게 이야기해봅시다.

Stefan Schuster and Julian Bartholomeyczik: 주요 구성 요소는 실제 센서 요소인 마이크로프로세서와 무선 통신을 위한 요소입니다. 마이크 및 가속도 센서 테스트에 이어, 주파수 범위와 진폭을 결정한 후, 가속도 센서가 선택됩니다. 마이크로프로세서는 제조업체의 구성 키트 (플랫폼 전략, 상향식 절차 참조)로부터 선택됩니다. 그리고 그 차원은 알고리즘을 실행할 수 있고 일부 개선을 위한 공간이 여전히 존재하는 것입니다. 무선 연결은 범위 요건 및 배터리 사용 요건에 기초하여 선택됩니다. 블루투스 LE (BLE) 연결이 선택됩니다. 게이트웨이는 구현되어 BLE 통해 데이터를 수신하고 처리 통제 시스템과의 연결을 가능하게 하는 와이파이로 변환된다.

초기 솔루션 설계의 결과에 기초하여, 프로젝트 팀은 중요한 ‘생산 또는 구매’ 의사결정을 내려야 한다. 이 결정은 프로젝트에 큰 영향을 미칠 것이다. 한 가지 중요한 요인은 기업 가이드라인 및 정책에 관한 것이다. 또 다른 요인은 전략적인 프로젝트 목표 및 필요한 솔루션 구성 요소의 이용 가능성에 관한 것이다. 일반적인 IoT 프로젝트의 생산 또는 구매 질문들은 다음을 포함한다.

• 공통 규격품 (COTS) 솔루션: COTS 솔루션은 차량 관리, 차량 추적, 스마트 미터링 등의 측면에 이용 가능한가?

• 자산 상 하드웨어: 맞춤형 하드웨어 또는 표준 하드웨어가 사용되어야 하는가?

• 자산 상 소프트웨어: 우리는 사전에 통합된 운영 체제, 펌웨어, 어플리케이션 컨테이너 및 개발 도구를 사용해야 하는가? 아니면 맞춤형 솔루션을 선택해야 하는가?

• IoT 클라우드/M2M 미들웨어: 완전히 발달한 상업적 IoT 클라우드/M2M 미들웨어에 비해 가벼운 오픈 소스 체제를 사용하는 것의 장점은 무엇입니까?

• 무선 통신: 우리는 더 나은 글로벌 커버리지를 보장하기 위해 하나의 통신 사업자에 의존하거나 MVNO (모바일 가상 네트워크 운영자)와 일해야 하는가?

결과에 따라, 또 다른 관련 질문은 일반 계약자의 역할을 해야 하는 주체에 관한 것이다. 예를 들어, 기업 자체, 시스템 총괄자, 또는 통신 회사의 M2M 사업부가 될 수 있다.