✎ ii.ignite_iot_솔루션_전수 [k-smartfactory]

추적:
*Enterprise-IoT
*Smart Machine 사례연구
*Middleware 사례연구
*AI·Big Data 사례연구
*IoT 사례연구
*Smart Thinks 사례연구
*정부정책동향 사례연구
*K-SmartFactory
*Hidden Champion
*카드뉴스
*국내외 동향 리포트
이 문서는 읽기 전용입니다. 원본을 볼 수는 있지만 바꿀 수는 없습니다. 문제가 있다고 생각하면 관리자에게 문의하세요.
==== II. Ignite | IoT 솔루션 전수 ====

Ignite | IoT 솔루션 전수는 IoT 제품 관리자, 프로젝트 관리자, 솔루션 설계자 및 기타 IoT 이해관계자를 대상으로 한 Ignite | IoT 방법론의 일부이다. 목표는 기술 독립적이며 재사용 가능한 오픈 소스 방법론의 형태로 이용 가능한 IoT 최고 사례를 만드는 것이다. 그리고 이는 프로젝트 템플릿, 체크리스트 및 솔루션 설계 청사진을 제공하여 IoT 프로젝트 설정 및 관리뿐만 아니라 IoT 솔루션 설계를 지원한다. 

IoT 프로젝트의 주요 특징은 제품 설계 및 제조, 내장형 하드웨어 및 소프트웨어, 로컬 및 원격 통신, 기업 어플리케이션 개발 및 통합, 교차 영역 보안 등을 통합하는 단일 프로젝트 내에서 매우 다른 여러 분야를 결합하는 경향이 있다는 점이다.

{{ :파트2_9번그림.png?300 |}}
                      Multiple dimensions of IoT project management

예를 들어, Part I에 제시된 eCall 솔루션을 살펴 보자. 자산의 관점에서, 이것은 현대 자동차의 상당히 복잡한 부품 구성표 (BOM)의 작은 부분에 불과하다. 그럼에도 불구하고 eCall 프로젝트 관리자의 관점에서, 자산 인터페이스를 관리하고 자산 구성 요소가 제대로 통합되어 있는지 확인하는 것은 중요하며, 이는 차 내에 텔레매틱스 제어 장치 (TCU)를 BOM과 제조 공정 모두에 통합시키기 위해 eCall TCU를 설치할 수 있는 알맞은 장소를 찾는 것을 의미한다. TCU와 소프트웨어는 개발 및 테스트에 필요한 매우 구체적인 기술로 기존의 내장 프로젝트를 대표한다. 필요한 모든 영역을 커버하는 이동 통신사 네트워크와 솔루션을 통합하고, 이 통신사 통합을 관리하는 것은 다른 기술을 필요로 하는, 작은 통신 프로젝트에 더 가깝다. 

마지막으로, 콜센터가 착신 전화를 관리하고, 그 전화를 적절한 기술을 가진 직원에게 돌리고, 다시 PSAP (공공 안전 답변 지점)로 전송할 수 있게 하는 백엔드 소프트웨어를 구현하는 것은 전통적인 기업 소프트웨어 프로젝트를 연상시킨다. 우리가 볼 수 있듯이, eCall 프로젝트와 같은 중간 정도로 복잡한 프로젝트는 여러 기술의 조합을 필요로 한다. 

현재, 이러한 유형의 여러 학문 분야에 걸친 프로젝트 관리에서 심층적 경험의 요구 수준을 충족하는 전문가의 수는 제한되어 있다. 성공적으로 텔레매틱스 및 M2M 프로젝트를 관리하고 현재 IoT 프로젝트에 대한 기술을 적용하기 시작한 전문가들이 그 예이다. 그러나, IoT가 더 광범하게 수용되도록 하기 위해서는, 더 많은 청중이 이를 경험해 볼 수 있도록 만들 필요가 있다. 이것이 Ignite | IoT 솔루션 전수의 목표이다. 우리는 IoT 프로젝트에 필요한 모든 다양한 기술과 학문을 통합하는 높은 수준의 방법론을 제공하고, 전문가의 경험과 우수 사례를 기록하기 위해 다른 분야의 전문가들과 협력하며, 이들을 방법론과 통합시키는 것을 목표로 하고 있다.
                      
{{ :파트2_10번그림.png?300 |}}                     
                              Ignite | IoT Solution Delivery

Ignite | IoT 솔루션 전수는 다음과 같이 나눌 수 있다.

•	IoT 솔루션 라이프사이클: 이 관점은 IoT 솔루션의 계획, 구축 및 실행에 초점을 맞추고 있다.

•	IoT 빌딩 블록: 이 관점은 IoT 프로젝트 차원, IoT 아키텍쳐 청사진, IoT 기술 프로파일 형태의 성공적인 프로젝트로부터 재사용 가능한 아티팩트를 포함하고 있다. 

•	IoT 프로젝트 DB: 이것은 IoT 솔루션 라이프사이클 및 빌딩 블록에 대한 모범 사례를 도출하기 위해 분석된 참고 프로젝트의 데이터베이스이다.

The IoT 솔루션 라이프사이클은 다음과 같은 구성 요소를 포함한다.

•	초기 프로젝트 설계: 이 설계 청사진은 IoT 기술 프로파일을 이용한 기술 선택, IoT 아키텍처 청사진을 이용한 솔루션 아키텍쳐, IoT 프로젝트 차원을 이용한 프로젝트 자체 평가를 포함하는 일반 IoT 빌딩 블록의 일부로 정의된 구성 요소를 기반으로 한다.

•	프로젝트 작업 흐름: 이 청사진은 일반적으로 IoT 솔루션 프로젝트에서 발견될 수 있는 최상위 작업 흐름을 정의한다. 각각의 작업 흐름에 대한 체크리스트는 작업 흐름들의 공통적인 의존성 목록과 함께 제공된다. 

The IoT 빌딩 블록은 다음과 같은 구성 요소를 포함한다.

•	프로젝트 차원: 이것은 공식적 프로젝트 요건의 전조이다. 프로젝트 차원을 프로젝트 자체 평가, 프로젝트 비교, 아키텍쳐 및 기술 선택 등을 위해 사용된다

•	아키텍쳐 청사진: 기존의 아키텍처 청사진들을 기반으로 (예: 서비스 지향 아키텍처(SOA) 등), 이들은 IoT 프로젝트에 필요한 새로운 아키텍처 관점을 추가하고 필요한 다양한 아키텍처 관점을 통합하기 위한 상부 구조를 제공한다.

•	기술 프로파일: 이러한 프로파일은 일반적으로 IoT 프로젝트에 필요한 가장 중요한 기술을 식별하고 설명한다. 이는 서로 다른 기술들의 전체 IoT 아키텍처에 꼭 들어맞는 위치를 설명하기 위해 IoT 아키텍처 관점을 활용한다. 마지막으로, 기술 선택 과정을 지원하기 위해 프로젝트 차원으로의 재연결을 시도한다.

{{ :파트2_11번그림.png?300 |}}
                           Organizational challenges
                           
이러한 질문에 기초하여, 운영 위원회는 각각의 IoT 기회를 관리하는 최선의 방법에 대한 결정을 내릴 수 있을 것이다. 전형적인 선택지는 내부 프로젝트, 외부 인수, 또는 자회사를 포함한다. 또한 매우 일반적인 방법은 이들의 혼합이며, 즉 큰 기업에 뿌리를 둔 사람들의 한 부분과 인수를 통해 들어온 사람들의 또 다른 부분으로 구성된 기업체를 설립하는 것이다. 또한, 제품 및 고객 기반보다는 인수 회사의 팀과 재능에 중점을 둔 회사 인수 전략을 설명하는 용어 "인수 고용"은 최근 인기를 끌고 있다.

특히 기존의 내부 조직을 활용하여 개발된 IoT 기회에 대해서는, 조직 구성에 세심한 주의를 기울여야 한다. 특히, 솔루션 팀과 기존의 자산 조직간의 인터페이스 및 관계가 필수적이다.  

Bosch에는 더 많은 사례들이 있으며, "유선형" 조직들이 사업 단위 수준으로 배열되어 있다. "이미 조직 내에 아이디어들의 소속이 있다면 더욱 쉽다"고 Silke Vogel은 말한다. "이 방법으로, 아이디어 구체화 및 사업 모델 개발을 담당하는 직원들은 프로젝트를 실행 단계로 이끌 수 있다."

IoT 최고 기관

회사가 IoT를 장기적인 변화로 볼 경우, 이 변화를 안내하고 촉진하기 위해 IoT 최고 기관 (CoE)의 설립을 고려해야 한다. CoE의 전형적인 기능 설명에 기초하여 [AE1], IoT CoE은 다음과 같다. 

•	지원: IoT CoE는 IoT 컨설팅 서비스의 제공을 통해 IoT 기회를 실현하기 위해 사업 분야를 지원해야 한다. 이 서비스는 IoT 사업 사례 작성, IoT 프로젝트 설정 및 IoT 프로젝트 실행 지도를 포함할 수 있다. 이 책의 저자로서 조금 편향되어 있긴 하지만, 이러한 서비스의 하나의 가능한 기반으로 Ignite | IoT 방법론을 당연히 추천한다. 

•	안내: IoT CoE는 필요한 기준, 방법론, 도구 및 지식 저장소를 정의하도록 도와야 한다. 이들 중 일부는 매우 수직적일 것이다. 그러나, 모바일 자산에 대한 원거리 통신 인프라 같은 것들을 설정하는 모범 사례와 같은 것들이 표준화 될 수 있다 (Ignite 기술 프로파일 사례를 참조). 

•	공유된 훈련: 교육 및 인증, 기술 평가, 팀 빌딩, 정형화 된 역할은 IoT 기능 개발에 적용될 수 있는 모든 확립된 방법이다. 

•	측정: IoT CoE은 변형 과정을 더 투명하게 하도록 돕는 IoT용 지표 및 성숙도 모델을 만들어야 한다.

•	관리: 그들은 프로젝트 간 조정 및 기타 자세한 관리 작업으로 운영 위원회를 지원해야 한다. 특히 연결된 IoT세계에는 항상 주의 깊게 관리되어야 하는 프로젝트 사이에 많은 상호 의존성이 있을 것이다. 

물론, 전용 IoT CoE을 실행하는 것은 상당한 투자이며, 많은 기업들은 다른 CoE 계획으로부터 혼합된 결과를 보고한다. CoE가 방해가 아닌 부가가치 프로젝트로 보여지는 것이 중요하다. 대개 CoE 구성에 대한 두 가지 선택지로, 지정된 CoE 자원 또는 운영 팀에 포함되지만 CoE 지원에 일정 비율의 시간을 소비할 수 있는 구성원과 가상의 CoE가 있다. 후자는 많은 경험과 실무 프로젝트 배경을 가진 CoE 전문가라는 이점을 가지고 있지만, 이러한 매우 존경 받는 전문가들은 종종 프로젝트 작업에 압도당해 자신의 파트 타임 CoE 역할을 충족하지 못한다는 단점이 있다. 

==== IoT 플랫폼 ====

마지막으로, IoT 여정에 착수한 기업들은 다른 IoT 프로젝트에 의해 공유될 수 있는 IoT 플랫폼의 설치 및 운영에 투자하는 것을 고려해야 한다. 이러한 플랫폼은 다음을 포함할 수 있다.

•	원격 자산 연결, 예를 들어 통신 사업자 또는 MVNO (모바일 가상 네트워크 운영자)의 M2M 플랫폼을 기반으로 (기술 프로파일의 M2M/IoT 통신 서비스 부분 참조).

•	IoT 어플리케이션 개발 및 실행 시간 (기술 프로파일의 플랫폼 및 실행 부분 참조)

•	IoT 데이터 관리 인프라 (기술 프로파일의 [빅] 데이터 및 프로세스 관리 부분 참조)

•	IoT 보안 인프라, 예를 들어 중앙 ID 및 인증 관리 (기술 프로파일의 보안 부분 참조)

•	표준, 예를 들어 통신 프로토콜 등

•	자산 인터페이스 저장소, 예를 들어 조직에서 중요한 역할을 하고 다른 종류의 장치 및 자산의 기능적·기술적 인터페이스를 설명하는 중앙 위키 

이론적으로, 이러한 IoT 플랫폼을 제공하는 것은 프로젝트를 순조롭게 시작할 필요가 있는 모든 사람들에게 다행스러운 일로 간주되어야 한다. 그러나, 우리는 확실히 이러한 중앙 플랫폼 방식에 내재하는 위험을 인식해야 한다. 이러한 위험 중 하나는 플랫폼이 실제로 작동하지 않을 수 있다는 것이다 (지나치게 구조화되어 있으며, 현장 테스트를 거치지 않았기 때문에). 또는 시간 내에 준비되지 않을 수 있다. 아니면 비효율적이고 조작하기 너무 어려울 수도 있다. 

이는 단지 중앙 플랫폼 개발과 관련된 실제 위험의 일부일 뿐이다. 반면 각각의 개별 프로젝트로 수행되어야 하는 경우, 프로젝트 팀이 절반의 시간은 제대로 맞출 수 없을 것이라는 실제 위험 또한 존재한다. 그래서 합리적인 방안은 최고의 플랫폼 방식을 개발하는 초기 프로젝트를 관찰하는 것이며, 일반화될 수 있는 이러한 프로젝트의 일부를 식별하는 것이다. 그래서 이것은 정말 성숙도 및 타이밍의 문제이다. 

==== 요약 및 결론 ====

우리가 처음에 설명한 바와 같이, 여기에 설명된 일부 과정과 방법은 매우 포괄적이며, 수직적인 요구와 개별 조직의 특정 상황에 적용될 필요가 있다. 일부 기업의 경우, 여기에 설명된 것처럼 상세한 사업 모델을 개발하는 정교한 방법은 지나친 것처럼 보일지도 모른다. 그러나 우리는 상당한 시간과 많은 반복을 소요하는 이러한 사업 모델 개발의 많은 사례를 보았다. 특히 기존의 복잡한 대규모 생태계에 포함될 필요가 있는 솔루션의 경우가 그러하다.

프로젝트의 조직 구조에는 특별한 주의가 필요하다. IoT 프로젝트는 거의 항상 다양한 기술을 가진 다문화 팀을 필요로 한다. "인터넷 캠프"와 "기계 캠프"를 정렬하는 것은 어려운 작업이다. MongoDB, Inc.의 이사 Joe Drumgoole는 한 가지 가능한 방법에 대해 다음과 같이 설명한다. "사물의 인터넷은 상호 작용하는 두 지역 사회 모두에 체계를 제공한다. [큰 회사들]이 두 세계 사이에 다리를 만들 수 있다면 그들은 성공할 수 있지만, 나는 성공은 파트너의 수가 적은 초기 에 올 것이라 생각한다. 인터넷 구성원으로 시작해서, 그들을 제조업체 구성원을 행동하도록 자극하기 위한 포장으로 사용한다."

고려해야 할 또 다른 중요한 것은 초기 단계의 스타트업 또는 프로젝트에 대한 사업 계획이 주요 변경 없이 첫 해를 살아남기는 거의 어렵다는 것이다. 그래서 민첩한 개발 방식 (이는 조직화되지 않거나 통제되지 않는다는 의미는 아니다)을 지원하는 것이 IoT 계획의 핵심 성공 요인이 될 것이다. 우리는 다음 부분 Ignite | IoT 솔루션 전수 방법론에서 이에 대해 더 자세히 다룰 것이다. 이 방법론은 IoT 프로젝트의 다음 단계를 지원하도록 설계되었으며, 이 프로젝트는 아이디어와 비전의 구현을 시작하기에 충분한 자금으로 전략 선택 과정을 완수하도록 관리되어왔다.  
                           
==== a. 계획/구축/실행 ====

물론 IoT 솔루션의 계획, 구축 및 실행은 솔루션마다 다르다. 그러나, 우리는IoT 솔루션 사이에 공통점이 있다고 믿으며, 이는 우리가 일반적인 방법론적 접근 방식이 어떠해야 하는지에 관해서 특정 가정을 할 수 있게 한다. 우리는 구체적으로 우리의 접근 방식을 논의하기 전에 우선 이러한 가정의 일부를 설명할 것이다.

==== 가정 ====

우리는 이미 이 책의 첫 부분에서 자산과 관련 백엔드 서비스 등에 초점을 맞춘 IoT 솔루션의 핵심 요소에 대한 기본 가정 중 일부를 논의했다 (서론의 “Enterprise IoT” 부분 참조). 우리가 만들고 있는 또 다른 핵심 가정은 IoT 솔루션 프로젝트가 초기 계획 단계를 포함하는 다른 프로젝트와 거의 비슷할 것이라는 점이다. 이러한 단계는 초기 출시 버전이 구축되는 단계와 솔루션이 작동, 관리, 향상되는 단계, 즉 계획/구축/실행 단계이다. 

프로젝트 팀은 주어진 상황에 따라 프로젝트 관리 방법을 선택할 것이다. 프로젝트 실행이 고정 가격에 기반하여 아웃소싱 될 경우, 기회는 더 전통적인 폭포수 모형에 적용될 것이다. 이 경우, RFI (정보 요청)가 "계획" 단계의 일부로 발부되며, 법적 구속력이 있는 RFP (제안 요청)이 뒤따른다. 또 다른 팀은 예를 들어 방법론으로 SCRUM을 활용하여, 민첩한 접근법을 적용하기로 결정할지도 모른다. 이 경우, 프로젝트의 자세한 사항은 사용자 스토리에 기초하며, 이는 빠른 실행을 위한 주요 투입을 구성하고 중앙 제품 백로그에서 관리된다. 이러한 사용자 스토리는 대개 상대적으로 상세하며 이상적으로 필요에 따라 생성된다. 그러나, 대부분의 민첩한 접근법은 또한 기능적, 구조적 관점에서 전체적인 솔루션을 설명하는 더 높은 수준의 설명서를 사용한다. 그래서, 어떤 의미에서, 민첩한 프로젝트는 “계획” 단계 (때로는 "스프린트 제로"로 알려진)를 포함한다. 선택된 민첩한 접근법의 종류에 따라, 프로젝트의 "구축" 및 "실행" 단계는 달라질 수 있다. 예를 들어, 일부 민첩한 프로젝트는 주요 발표에 집중하고 긴 테스트 단계를 포함하는 전통적인 접근법에 가깝다. 또한 이는 때때로 폭포수 모형(waterfall)과 민첩함(agile)의 조합인 "wagile"방식이라고 불린다. 다른 민첩한 프로젝트들은 빠른 결과가 지속적으로 배열되는 접근법을 매우 신중하게 채택하려고 시도한다. 

프로젝트 관리에의 또 다른 일반적인 접근법은 V-Model이다. 예를 들어 이것은 중부 유럽의 정부 운영 프로젝트에서 일반적으로 사용된다. PRINCE 2에서 합리적 통합 프로세스 (RUP)까지 다른 많은 접근법이 있다. 그러나, 우리는 보통 일반적인 계획/구축/실행의 관점이 서로 다른 접근법 모두에 적용될 수 있다고 말하는 것이 타당하다고 믿는다.  

{{ :파트2_12번그림.png?300 |}}
                          Ignite and different project approaches
                          
==== 취한 접근법 ====

프로젝트 관리를 위해 이러한 서로 다른 접근법을 모두 지원해야 할 필요성을 감안할 때, 다음 Ignite 방법론은 IoT 솔루션에 특화된 것에 초점을 맞추며, 프로젝트 관리자가 프로젝트 관리 모델을 선택해 솔루션과 결합시킬 수 있도록 한다. 

프로젝트 구조의 측면에서, Ignite 접근법은 아래 그림에서 보여지는 높은 수준의 구조를 기반으로 한다. 첫 번째로 우리가 볼 수 있는 것은 자산 자체와 IoT 프로젝트 사이에 차이가 있다는 점이다. 자산의 설계 및 제조는 IoT 솔루션 프로젝트의 범위 내에서 일반적이지 않다. 그러나, 자산과 IoT 솔루션 프로젝트에 대한 책임이 있는 조직 간의 인터페이스를 인식하는 것은 필수적이다. 하나 이상의 IoT 솔루션을 지원하도록 자산이 처음부터 설계되는 상황뿐만 아니라, IoT 솔루션이 자산의 초기 설계 ("개조") 이후 자산과 통합되는 상황에서도 이는 적용된다. 어느 경우에도, IoT 솔루션은 솔루션의 백엔드 서비스 인터페이스를 정의하는 특정 "자산 상의" 하드웨어 및 소프트웨어에 의존할 가능성이 높다. 
                          
{{ :파트2_13번그림.png?300 |}}                          
                                 Ignite project structure
 
Ignite | IoT 솔루션 전수의 또 다른 핵심 요소는 전형적인 프로젝트가 착수 단계와 주요 실행 단계를 가지고 있다는 가정이다. 사업 사례가 승인되고 조직이 원칙적으로 프로젝트를 진행하라는 명령을 내리면 착수 단계는 시작된다. 이 단계에서, 즉 자원의 증가 이전에, 보통 상대적으로 작은 팀이 프로젝트에 참여한다. 

다음은 주요 실행 단계이다. 이 단계에서의 Ignite 접근법은 우리가 “작업 흐름”이라고 부르는 개념을 기반으로 한다. 이는 주요 프로젝트에 걸쳐 적용되는 최고 수준의 구조이다. PMI의 측면에서, 작업 흐름은 작업 분류 체계 (WBS)의 최상위 작업 항목이 될 것이다. 우리의 경험에서, 용어 "작업 흐름”은 다른 모든 이해 관계자 및 종속성과 함께 IoT 프로젝트 관리의 매우 역동적인 특성을 더 잘 반영한다.

==== i. IoT 프로젝트 착수 ====

Ignite | IoT 프로젝트 착수 단계의 중요한 측면은 요건 분석이며, 이는 사업 모델 생성 단계에서 수행된 분석보다 더 면밀하다. 비교하자면, 요건 분석은 초기 솔루션 설계를 지원할 수 있는 수준의 세부 사항에 도달하기 위한 목적으로, 특정 사용자 요건을 깊게 살펴 본다. 프로젝트 착수는 일반적으로 각 분야의 전문가로 이루어진 작은 팀에 의해 수행된다. 특히, 팀은 전용 솔루션 설계를 가지고 있어야 한다 (사업 모델 생성 단계에 깊이 관여되지 않았을 수 있다). 또한, 팀은 광범위한 영역의 지식과 솔루션의 기능적인 측면에 대한 명확한 비전을 가진 사업 분석가를 포함해야 한다.

우리가 "두 세계의 충돌"에 대한 이전 논의를 기억한다면, 적합한 사업 분석가 및 솔루션 설계자를 찾는 것이 중대하지만 어렵다는 것을 알 것이다. 예를 들어, 사업 분석가가 일반적으로 자산에 대한 책임이 있는 사업 부문에서 올 경우, 서비스 관점에서 생각하기 어려울 지도 모른다. 반면, 서비스 중심의 사람이 이 역할에 선택될 경우, 그들은 자산 영역에서의 오랜 경험으로부터 비롯된 심층적인 영역 지식이 부족할지도 모른다. 어떤 경우에는, 따라서 상호보완적 배경을 가진 여러 전문가를 선택하여 IoT 프로젝트 착수 단계 팀을 구성하는 것이 유용할 수 있다. 

프로젝트 착수 팀은 이 단계에서 이해 관계자 분석, 환경 분석, 요건 분석, 위험 및 자원 평가 등 일반적인 많은 작업을 수행해야 한다. 다음에서, 우리는 어떠한 추가적인 IoT 고유의 측면이 이러한 표준 프로젝트 작업에 추가될지에 대해 설명할 것이다. Ignite | IoT 프로젝트 착수 단계의 최종 결과는 이전에 설명된 작업 흐름 구조를 기반으로 한 초기 솔루션 설계 및 프로젝트 구조이다.

{{ :파트2_14번_그림.png?300 |}}
                                 Project initiation
                                 
==== 1. 초기 솔루션 디자인 ====

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

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

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

{{ :파트2_15번그림.png?300 |}}
                              Initial IoT Solution Design

==== I. 분석, 예측, 계획 ====

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

==== 문제 설정/경영 요약서 ====

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

{{ :파트2_16번그림.png?300 |}}
                                   Executive summary
                                   
==== 이해관계자 분석 ====

프로젝트 맥락에서 이해관계자 분석을 위한 많은 모범 사례 체계가 있다 (예를 들어, 참조 추후결정). Ignite | IoT는 이해관계자 분석을 위한 IoT 고유의 체계를 기반으로 하며, 이는 원래 Heinz Derenbach 박사 (Bosch Software Innovations의 전 CEO)와 그의 팀에 의해 고안되었다. 이 팀에서 배운 한 가지 중요한 교훈은 대부분의 IoT 솔루션이 이해관계자와 연관된 네 개의 핵심 요소 - 자산과 해당 장치, 관련 기업의 서비스, 솔루션 사용자 및 파트너로 구성되어 있다는 점이다. 아래 그림은 IoT 솔루션의 네 가지 핵심 요소에 대한 개요를 제공한다.
                                   
{{ :파트2_17번그림.png?300 |}}            
                          Four key elements of an IoT solution
                          
우리의 경험에 의하면, 이 네 가지 핵심 요소와 그들 간의 상호 의존성을 확인하고 정의하는 것은 IoT 솔루션의 주요 측면과 이해관계자 분석을 위한 아주 좋은 출발점이 될 것이다. 어떤 경우, 이들 요소 중 일부는 일반적으로 그들 사이의 상호 의존성에 대한 상세한 조사 없이 이미 사업 모델 분석에 포함되었을 수도 있다.

==== 현장 조사 ====

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

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

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

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

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

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

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

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

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

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

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

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

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

{{ :파트2_18번그림.png?300 |}}
                              IoT Solution Sketch                                                 

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

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

==== 프로젝트 차원 ====

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

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

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

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

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

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

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

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

{{ :파트2_19번그림.png?300 |}}
                            IoT Project Dimensions
                            
==== 수량 구조 ====

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

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

{{ :파트2_20번그림.png?300 |}}
                                IoT quantity structure
                                
==== 이정표 계획 ====
 
마지막으로, 일반적인 프로젝트와 마찬가지로 IoT 솔루션 프로젝트의 초기 솔루션 설계는 이정표 계획을 포함해야 한다. 이 계획은 일부 정상적인 이정표와 일부 IoT에 특화된 이정표를 포함한다.

•	생산 또는 구매 의사결정

•	공급 업체 선정

•	시제품

•	모의/현장 테스트

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

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

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

==== II. 기능 설계 ====

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

==== 시작: 사례 및 UI/HMI 모형의 사용 ====

기능 설계를 만들기 위한 좋은 첫 단계는 가장 중요한 사용 사례에 대한 높은 수준의 분류를 정립하는 것이다 (엄밀히 말하자면, 초기 사용 사례 분류가 원래 분석의 일부로서 만들어져야 하지만 이것이 중요 설계 아티팩트이기 때문에 우리는 이것을 여기에 포함시킨다). 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 방법론은 디지털 모델과 해당 복원 과정을 정의하는데 충분한 시간과 자원을 투자할 것을 권장한다. 

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

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

•	등급

•	속성

•	제휴

•	집단

•	상속/전문화

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

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

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

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

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

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

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

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

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

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

{{ :파트2_22번그림.png?300 |}}                        
                               IoT domain model
                               
**자산 통합 아키텍쳐 (AIA)** 

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

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

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

**데이터 분배 Data Distribution**

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

영역 모형에서 확인된 각각의 개체에 대해, 이 작업은 개체들이 AIA어디에 존재하는지 확인하는 것이며, 이는 설계 (그린 필드)에 의해, 또는 그들이 이미 했기 때문에 (브라운 필드) 일어난다. 데이터 분배와 밀접한 관련된 것은 주요 비지니스 규칙의 분배이다.
                               
{{ :파트2_24번그림.png?300 |                              }} 
                               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는 더 시스템적인 관점을 취하며, 사용된 구체적인 기술에 대한 참조를 가능한 한 포함한다. 
                               
{{ :파트2_25번그림.png?300 |}}                           
                                  SOA landscape

==== III. 기술 설계 ====

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

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

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

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

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

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

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

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

•	개발 도구

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

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

•	자산에 위치 및 장착

•	분포된 센서 노드를 배치할 경우, 자산에 이러한 노드를 위치 및 장착
                            
{{ :파트2_26번그림.png?300 |}}         
                              Hardware design
                   
맞춤형 하드웨어 개발의 경우, 다음 수준의 하드웨어 설계 세부 사항은 주요 구성 요소, 즉 CPU, 메모리, 전원, 디지털 I/O, 통신 모듈 등을 다룬다. 아래 도표는 서론에서 기술된 바와 같이 eCall 서비스 텔레매틱스 장치의 메인 보드 설계 예시를 보여준다. 

{{ :파트2_27번그림.png?300 |}}
                     Detailed hardware design (source: peiker group)
                     
==== 기술 인프라 ====
 
기술 인프라의 설계는 개별 솔루션, 특히 사용된 네트워크 인프라에 고도로 특화될 것이다. Alcatel-Lucent의 예는 아래 그림에서 볼 수 있다 (참조 추후결정). 

{{ :파트2_28번그림.png?300 |}}
                                 Technical infrastructure
                                 
==== 2. 예시 – 센서 선택과 통합 ====

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 통해 데이터를 수신하고 처리 통제 시스템과의 연결을 가능하게 하는 와이파이로 변환된다.

==== 3. 생산 또는 구매 의사결정 ====

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

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

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

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

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

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

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

==== ii. IoT 프로젝트 구조 ====

초기 솔루션 설계가 완료되면, IoT 프로젝트 개시 단계에서의 최종 작업은 일반적으로 프로젝트의 조직 구조를 설정하는 것이다. 이것이 우리가 여기에서 설명하고자 하는 것이다. 

==== Conway의 법칙 ====

IT는 IoT에 중요한 많은 법칙, 특히 Moore와 Metcalfe의 법칙에 의해 통제된다. 덜 널리 알려졌지만 우리의 경험에서 매우 중요한 이 법칙은 1968년 Melvin Conway에 의해 제시되었다. 이 법칙에 따르면, 소프트웨어 시스템의 구조는 이를 생산하는 조직의 구조를 반영한다. 예를 들어, 세 개의 개발 팀이 IT 프로젝트에 참여하는 경우, 결과로 초래된 아키텍쳐가 세 가지 주요 구성 요소를 가질 가능성이 있다. 결과적으로, 목표가 세 가지 구성 요소로 아키텍처를 만드는 것일 경우, 프로젝트의 조직 구조는 세 개의 개발 팀으로 구성되어야 한다.

이를 염두에 두고, 프로젝트의 조직 구조는 생산 또는 구매 의사결정의 결과뿐만 아니라, 고려 초기 솔루션 설계의 결과를 고려해야 한다. 이는 다시 IoT 솔루션 프로젝트의 최상위 작업 흐름을 구성하는 방법에 대한 논의로 우리를 데려간다.

{{ :파트2_29번그림.png?300 |}}
                         Identifying the right workstreams
                         
==== IoT 프로젝트 작업 흐름 ====

Ignite |IoT 방법론은 최상위 프로젝트 구조로 작업 흐름의 개념을 사용한다. 이는 우리가 IoT 프로젝트처럼 많은 종속성을 지닌 복잡한 프로젝트의 경우, 전통적인 폭포수 모형 접근법을 사용하는 경우에도, 개시 단계 동안 완전하고 완벽하게 안정적인 작업 분류 체계 (WBS)을 마련하는 것은 불가능하다고 생각하기 때문이다. 작업 흐름의 개념은 이 프로젝트의 역동성을 더 잘 반영한다. 각각의 작업 흐름은 초기 솔루션 설계 (Conway의 법칙)로부터의 핵심 산출물 집합 (예를 들면 PMI [PM1]에 따라, 작업 패키지로 정의된)에 매핑되어야 하며, 팀과 팀/작업 흐름 관리자를 필요로 한다.
                         
{{ :파트2_30번그림.png?300 |}}           
                        Proposed IoT project workstreams
                        
일반화하는 것은 어렵지만, 우리의 분석은 위의 도표에 설명된 작업 흐름을 정의하는 것이 많은 IoT 프로젝트에 타당하다는 것을 보여 주었다.

1.	프로젝트 관리: PMI PMBOK [PM1]에 잘 정의되어 있지만 처음 6개의 작업 흐름에 걸쳐서 솔루션 아키텍처 관리를 통합할 필요가 있다. 

2.	크로스 커팅 작업: 보안, 자산 라이프사이클 관리, 솔루션 통합 및 테스트를 포함하는 다음 작업 흐름에서 종속성을 가지는 작업의 포함

3.	솔루션 인프라 및 운영: 어플리케이션 라이프사이클 관리 솔루션을 포함하는 솔루션 개발 및 운영에 필요한 하드웨어 및 소프트웨어 인프라의 설치 및 관리

4.	백엔드 서비스: 백엔드 서비스의 이행 및 운영, 기존 어플리케이션과의 통합 

5.	통신 서비스: 통신 인프라의 설치 및 관리  

6.	자산 상 구성 요소: 설계 및 제조 또는 자산 상 하드웨어의 구입 및 구현
 
7.	자산 준비: 자산 및 새로운 솔루션을 위한 환경의 준비

다음에서, 우리는 핵심 과업과 다른 작업 흐름과의 종속성을 고려하여, 독립적으로 각각의 작업 흐름을 살펴볼 것이다.

**프로젝트 관리**
 
폭포수 모형 또는 민첩한 접근법을 기반으로 하든 안 하든, 각 프로젝트는 효율적인 프로젝트 관리 과정을 필요로 한다. PMI, 즉 프로젝트 관리 기관은 프로젝트 관리의 핵심 요소를 정의한다. " A Guide to the Project Management Body of Knowledge (PMBOK)" [PM1]에서는 시작, 계획, 실행, 감시 및 통제, 마감을 다섯 가지 핵심 프로젝트 관리 과정으로 본다. IoT 솔루션 프로젝트에 동일한 과정이 적용된다. 표준 과정에 대한 자세한 내용은 PMBOK 가이드를 참조하십시오. 이 시점에서, 우리는 적어도 부분적으로 IoT에 특화되어 있다고 생각하는 특정 프로젝트 관리 작업을 강조하고 싶다. 프로젝트 계획의 경우 다음을 포함한다,

•	조달 계획: IoT 솔루션에 필요한 구성 요소 및 서비스를 조달하는 프로세스의 복잡성은 과소평가되어서는 안 된다 (예를 들어, 자산 상 하드웨어 및 통신 서비스). 따라서 이러한 프로세스는 그에 따라 일찍 시작되고 계획될 필요가 있다.

•	자원 계획: 우리는 이미 IoT 프로젝트의 주요 특징 중 하나가 내장형 소프트웨어에서 기업 소프트웨어로의 통신에 필요한 다양한 기술이라는 것을 알고 있다. 이는 자원 동원 과정을 어렵게 만들고 충분한 시간과 자원이 이 작업을 위해 계획될 필요가 있도록 만든다.

•	품질 관리: QM은 통신 서비스 품질, 평균 자산 상태와 같은 솔루션에 특화된 보고 항목을 포함해야 하는 솔루션을 보고한다

•	솔루션 아키텍처 관리: 이미 이상적으로 초기 솔루션 설계에 대한 책임이 있는 솔루션 설계자는 지속적으로 개인 작업 흐름에 의해 생성된 상세 설계를 검토하고 모든 다른 설계를 하나의 일관된 솔루션에 추가할 수 있도록 해야 한다. 이는 각각의 다른 작업 흐름의 설계적 정렬을 보장하기 위해 아키텍처 검토 과정의 설립을 필요로 한다.

•	인터페이스 관리: 다른 솔루션 구성 요소 및 작업흐름 사이의 효율적인 기술적 인터페이스 (소프트웨어, 통신 프로토콜, 하드웨어) 관리는 모든 분배된 시스템 프로젝트의 가장 중요한 성공 요인 중 하나이다. 우리는 다음 사항을 매우 권장한다.

o	모든 크로스 컴포넌트 인터페이스를 조정하고 지속적으로 다른 작업 흐름과 연락하는 것에 대한 책임을 맡는 특정 역할을 정립

o	각 인터페이스의 기술적, 기능적 설명을 포함하는 모든 크로스 컴포넌트 인터페이스를 수집하는 중앙 저장소를 구축. 그러나 도구의 과잉 사용을 피해야 한다. 중앙 인터페이스 저장소를 만들고 유지하기 위한 유연하고 가벼운 메커니즘으로 위키를 사용하십시오. 이는 REST 및 OPC에서 MQTT 및 CoAP까지 인터페이스들이 매우 여러 다른 종류들로 이루어지는 좋은 기회가 있다는 것을 고려하면, 특히 장치에 특화된 프로토콜과 관련이 있다. 

**크로스 커팅 작업**
 
그 이름에 충실하게, 크로스 커팅 작업 흐름은 보안, 자산 라이프사이클 관리, 솔루션 통합 및 테스트 작업 흐름 등 모든 다른 작업 흐름을 가로지르는 작업에 책임이 있다.

**보안**
 
모든 IoT 솔루션에 대한 보안의 중요성을 감안할 때, 그것을 최고 수준의 작업 흐름 그 자체로 만들자는 강력한 주장이 있다. 그러나, 보안이 각각의 다른 작업 흐름에 영향을 미치기 때문에, 우리는 실제 크로스 커팅 작업 흐름으로 취급되어야 한다고 생각한다.

IoT 보안의 기술적 측면들과 그들이 자산 상 구성요소, 통신 서비스, 백엔드 서비스, 인프라 등 다른 작업 흐름에 영향을 미치는 방법에 대한 더욱 자세한 설명은 조금 더 아래의 보안 기술 프로파일 부분을 참조해주십시오.

보안 작업 흐름의 관점에서, 보안이 단지 기술에 관한 것이 아님을 이해하는 것이 중요하다. 또한 보안은 여기에서 정의될 필요가 있는 모든 보안 정책 및 과정을 필요로 한다. 그리고 이 프로젝트는 솔루션의 보안을 보장하고 검증하기 위한 다음과 같은 전략을 정의해야 한다.

•	위험 평가: 이는 최우선 순위 위협과 가장 가능성이 높은 공격자의 프로파일을 식별하도록 해야 한다. IoT 솔루션의 경우, 이는 분명 자산 관련 영향 분석뿐만 아니라 자산 및 자산 관련 통신에 대한 공격을 포함한다.

•	보안 아키텍처: 다른 보안 메커니즘이 솔루션 아키텍처에 통합되는 방법을 보여주는 전문화된 아키텍쳐 관점.

•	보안 이행: 일반적으로 다른 모든 작업 흐름을 크로스 커팅하고 포함하는 보안 아키텍처를 이행하기 위한 작업 패키지를 포함한 세부 계획.

•	보안 테스트 및 검증: 보안 아키텍처 및 이행에서의 잠재적인 결함을 식별할 수 있도록 하는 전용 테스트 전략. 이는 외부 전문가를 필요로 할 수 있다.

**자산 라이프사이클 관리**
 
서론에서의 논의처럼, 많은 IoT 솔루션들이 자산 라이프사이클에 큰 영향을 미치며, 라이프사이클은 통합된 제품/서비스 설계, 제품 제조, 서비스 개발, 마케팅 및 영업, 유통 및 활성화, 서비스 운영, 원격 상태 모니터링, 솔루션 지원 및 제품 유지 관리 (원격 유지 보수 및 예방 정비 포함), 디지털 서비스, 재판매 및 은퇴에 이른다.

우리는 모든 작업 흐름을 포함하는 자산 라이프사이클 관리의 관점에서 솔루션을 찾을 책임이 있는 프로젝트 내 지정된 역할을 만들도록 권장하며, 이는 이 중요한 관점이 끝에서 끝까지 다루어지는 것을 보장한다.

자산 활성화를 예로 들어보자. 라이프사이클의 중요한 부분은 보통 자산 상 소프트웨어, 통신 서비스, 백엔드 서비스에 영향을 미친다. 그래서 최선의 해결책이 모든 작업 흐름을 통해 이행되는 것을 보장하기 위해, 중심화된 관점에서 이를 보는 것이 합리적이다.

**솔루션 통합 및 테스트**
 
마지막으로, 솔루션 통합 및 테스트는 또 다른 중요한 크로스 커팅 작업이다. 책임이 있는 사람 또는 팀은 핵심 출시 이정표, 인터페이스 버전, 준비 메커니즘, 프로세스, 끝에서 끝까지의 테스트 계획 등에 동의하기 위해 모든 다른 작업 흐름과 연락을 취하도록 요구될 것이다. 또, 이는 여느 큰 기업 IT 프로젝트와 너무 다르지는 않으면서, 테스트 계획과 자산 상 구성 요소를 통합해야 하는 복잡성이 추가된 프로젝트이다. 

현장 환경을 완전히 반영하는 테스트 환경을 만드는 것이 항상 가능한 것은 아니다. 당신이 1,000,000개의 장치를 관리하는 작업의 IoT 솔루션을 가질 경우, 1,000,000개의 테스트 장치로 이 솔루션을 테스트하는 것은 실현 불가능할 것이다. 대신, 실용적인 메커니즘이 제한된 수의 실제 장치를 사용하여 초기 통합 테스트의 완성을 가능하게 하도록 발견되어야 할 것이다. 부하 생성기는 1,000,000개의 장치로 시스템을 모의 실험하는데 사용될 수 있으며, 따라서 백엔드 시스템의 확장성을 테스트할 수 있다. 

마찬가지로, 효율적인 테스트 전략은 통신 서비스를 위해 고안되어야 할 것이다. 세계적인 출시를 계획하는 경우, 모든 위치를 테스트하는 것이 항상 가능하지는 않을 것이다. 이 경우, 테스트 팀은 합동 테스트 계획을 정의하기 위해 서비스 제공자와 함께 밀접하게 일하도록 요구될 것이다.

다시 이러한 종류의 통합 테스트는 보통 다른 모든 작업 흐름에 영향을 미치기 때문에, 크로스 커팅 작업 작업 흐름 하에서 이러한 작업을 집중화하는 것이 합리적이다. 

**솔루션 인프라 및 운영**
 
이 작업 흐름은 솔루션을 구축하고 테스트하고 운영하는데 사용되는 전체 인프라를 설정할 책임이 있다. 특히, 모든 기업 소프트웨어 프로젝트에서 발견되는 표준 인프라 설정 작업을 포함한다. 그러나, 이러한 표준 작업 외에도, IoT 솔루션에 특화된 많은 작업들이 있다.
 
표준 기업 어플리케이션의 경우, 필요한 다른 환경들, 보통 개발, 테스트/통합 및 생산에 합의하기 위해 이 작업 흐름은 긴밀히 협력하는 개발 프로젝트의 구성원과 운영 팀의 구성원을 필요로 한다. 그들은 또한 여러 개발 업데이트를 새로운 출시와 통합시키고 궁극적으로 생산 환경에서 새로운 출시를 이용 가능하게 만드는 필요한 관련 준비 과정에 동의해야 한다. 

구성 관리 및 출시 계획뿐만 아니라 정상 상태 및 운영 계획 또한 이 작업 흐름의 일부를 형성한다. 하드웨어 크기 조정 및 획득, 백업 관리, 보안 인프라 (방화벽, DMZ 등), 시스템 모니터링, 경보 관리, 확장성 계획, 가용성 관리 (예를 들어, 지역 회복력을 가진 각 주요/재해 지역), 고객 지원 센터 기능 등의 작업도 고려되어야 할 필요가 있다. 솔루션이 클라우드를 기반으로 하는 경우, 클라우드 인스턴스 상태 모니터링, 클라우드 SLA 관리, 클라우드-2-기업 어플리케이션 통합 또한 고려되어야 한다.

심지어 표준 프로젝트의 경우, 여기에 포함된 다양한 기술, 도구, 개념, 사람은 복잡한 시나리오를 구성한다. IoT 솔루션 경우, 이러한 솔루션의 고도로 분산된 특성 때문에, 당신은 이 모든 것 이상을 가진다.

이 작업 흐름은 모든 복잡성 속에서 어플리케이션 라이프사이클 관리 (ALM)가 백엔드에서 자산까지 일관되게 적용되도록 해야 한다. 이는 자산, 자산 모니터링, 자산에 의해 생성된 에러 및 경보 관리 등을 위해 필요한 소트프웨어 업데이트 인프라의 제공을 포함한다. 

또 다른 중요한 문제는 고객 지원 인프라에 관한 것이다. 대부분의 통신 사업자는 그들의 지원 팀에게 기본 장비 검사를 할 수 있는, 예를 들어 온라인 상태인지 여부를 검사하는 DSL 모뎀 "핑잉" 등의 특수 도구를 제공한다. 이 기능은 보통 고객 접촉 이력 등의 추가 정보를 제공하는 핵심 콜 센터 어플리케이션에 들어가 있다. 많은 IoT 솔루션이 이 작업 흐름에서 다루어질 필요가 있는 유사한 지원 기능을 필요로 할 것이다. 

IoT 솔루션이 예를 들어 원격 상태 모니터링 (RCM) 또는 예측 유지 보수 기능을 제공하여 기존의 현장 서비스 팀을 지원하도록 설계된 경우, 이 팀에의 기술적 훈련 제공도 매우 중요해질 것이다.

**백엔드 서비스**
 
백엔드 서비스 작업 흐름의 일반적인 작업 항목은 자산 및 자산 데이터, 솔루션에 특화된 프로세스의 이행, EAI (기업 어플리케이션 통합) 또는 SOA (서비스 지향 아키텍처)를 통한 기존 어플리케이션과의 통합을 위한 솔루션의 생성을 포함한다.  

전문 M2M/IoT 어플리케이션 플랫폼 (자세한 사항은 기술 프로파일 부분 참조)을 사용하는 경우, 당신은 이 플랫폼을 선택하고 획득하고 설치해야 할 것이다. 처음부터 시작하는 경우 프로세스는 몇 주가 걸릴 수 있으며, 특히 전략적 기술 결정일 경우 몇 개월이 걸릴 수 있다. 

목표는 모든 현장 자산의 중심적 대표를 포함하는 백엔드에 특정 단계을 구축하는 것이다. 이는 개별 자산 또는 자산 그룹을 위한 관리 기능뿐만 아니라 최신 자산 상태 데이터 및 상세한 자산 사건 이력을 포함한다. M2M/IoT 어플리케이션 플랫폼은 동떨어진 자산과 통신하고 지역적으로 자산 데이터를 관리하기 위한 방법 등 이러한 기능을 구현하기 위한 아웃 오브 박스 기능을 일반적으로 제공할 것이다. 이 플랫폼은 배치된 모든 자산 및 해당 상태에 대한 개요를 제공하는 관리 콘솔을 종종 포함한다.

백엔드 서비스 작업 흐름은 각 자산과 자산에 배치된 장치에 적합한 프로파일을 작성해야 한다. 그 다음, 프로파일은 플랫폼에서 이행되어야 할 것이다. 이는 예를 들어, 플랫폼에 의해 제공된 도구를 사용하여 수행될 수 있다.

대부분의 경우, 관리 콘솔은 최종 사용자에게 적합하지 않을 것이므로, 솔루션에 특화된 UI가 구현되어야 할 것이다. 이는 솔루션에 특화된 프로세스가 구현되어 있는 전문 어플리케이션의 일부가 될 수 있다. 이러한 프로세스는 대부분 기존의 많은 기업 어플리케이션과 통합되어야 할 것이다. 

예를 들어 카셰어링 서비스의 경우, 첫 번째 단계는 백엔드에서 동떨어진 자산 (이 경우 자동차)의 중앙 모델을 만드는 것을 포함한다. 그리고 카셰어링 고객을 위한 UI 및 어플리케이션의 구현으로 이어진다. 그 다음, 모바일 어플리케이션은 자동차가 지도에 가시화될 수 있도록 현재 차량 위치에 대한 데이터를 얻을 수 있는 중앙 자산 저장소에 접근한다. 또한 어플리케이션은 자동차 예약 기능을 지원할 필요가 있다. 결제 과정의 경우, 기존 어플리케이션과 통합된다. 웹 UI는 상세한 차량 사용 이력을 사용자와 콜 센터 직원들에게 제공한다. 이 데이터는 자동차 대여 과정의 시작 및 종료를 알리는 사건 등 차량에 내장된 장치로부터 수신된 사건에서 끄집어내진다.

또 다른 주요 업무는 일반적으로 사용자 관리 시스템과 솔루션의 통합을 포함한다. 가장 간단한 사례로, 이는 사용자 등록 및 로그인을 위한 웹 기반 솔루션을 필요로 한다. 위의 카셰어링 서비스 등 많은 예에서, 이는 더 복잡해질 수 있다. 예를 들어, 사용자의 운전 면허증을 확인하고, 자동차를 열기 위한 칩 카드를 발급하는 보다 정교한 등록 절차의 설정을 포함할 것이다. 

**통신 서비스**
 
자산 및 백엔드 사이에서 통신 서비스를 설정하고 관리하기 위한 작업 흐름의 구조는 많은 요인, 특히 요구되는 글로벌 커버리지, 최대 대기 시간 및 대역폭, 비용 등에 따라 달라질 것이다 
초기 솔루션 설계에 기초하여, 이 작업 흐름은 통신 서비스에 대한 최적의 설정을 알아내기 위해 더 심도 있는 분석을 완성하는 것에 관한 것이다. 이는 다음과 같은 작업을 포함할 수 있다.

•	예상 트래픽 프로파일과 백엔드 연결 및 위치를 포함하는 범위/서비스에 대한 자세한 요건을 수집

•	하드웨어 기능 분석, 지원된 통신 서비스를 기반으로 한 하드웨어 선택에 대한 가능한 지원, 모바일 네트워크와 로밍의 통합

•	통신 규제 및 특정 수직적 규제를 포함하는 출시 시장의 규제 상황 확인 (예를 들어, eCall 서비스에 대한 국가 별 규제)

•	데이터 크기, 필요한 회복력, 예외 처리 등 통신 행동과 네트워크에의 잠재적인 영향을 감시

이 정보는 올바른 기술과 통신 서비스 제공자를 선택할 토대를 제공할 것이다. 시간이 제공자를 고르고 서비스 계약에 대해 협상하는 데 필요한 시간은 과소평가되어서는 안 된다.

개발 단계에서는 서비스 제공자가 테스트 환경을 이용 가능하게 만드는 것이 중요하다. 전반적인 솔루션은 통신 서비스 제공자의 인프라에 통합되고 테스트되는데 필요할 것이다. 이는 예를 들면, 연결성 관리를 위한 작동자 전용 포탈을 사용하여 행해질 수 있다.

가동기간 동안, 같은 포탈이 제공 상태, 기기 데이터 사용, SIM상태, 네트워크 오류 등을 포함하는 통신 네트워크를 감시하고 관리하는데 사용될 수 있다.

Aeris의 Director of Sales Engineering인 Stephen Blackburn 과의 다음 인터뷰는 이 주제에 대한 더 가치 있는 통찰을 제공한다.

**Jim Morrish**: 솔루션의 모바일 통신 부분 계획과 시행에서 프로젝트 관리자의 체크 목록에 대한 주요 포인트는 무엇입니까?

**Stephen Blackburn**: 이 프로젝트 관리자는 모바일 통신 솔루션의 개발을 처음부터 끝까지 이끌고 작동하는 광범위하게 다양한 요소들을 이해하는 시야를 가지기 위해 이해와 통찰을 가져야 합니다. 그는 다음 고려사항들을 감독해야 합니다

1) 장보러 가는 사업 모델– 어떻게 회사가 그들의 고객을 변화시킬 것인가

2) 어플리케이션 통신 호출 흐름– 어떻게 기기가 네트워크와 상호작용할 것인가

3) 일반 작동 패턴과 무선 업그레이드를 포함하는 예상되는 사용 패턴의 정의 

4) 공급 체인 계획, 기기 제조의 고려, 통신사 네트워크상의 기기 공급, 제조과정 끝에서 통신 연결 테스트, 시장 목표에 대한 채널

5) 휴대 통신사 선택

6) 휴대 통합 (API 통합)

7) 다양한 RF 상태에서의 통신 연결 테스트를 포함하는 양단간 어플리케이션 테스트 계획

8) 기기 통신 증명

9) 이해되고 준비된 통신 지원 SLA 

10) 고객 지원 과정 정의와 지원 팀 훈련

**Jim Morrish**: 모바일 통신 작업 흐름과 다른 작업 흐름간의 주요 인터페이스, 즉, 자산 하드웨어, 보안 등은 무엇입니까?

**Stephen Blackburn**: PM은 어떻게 모바일 통신 계획이 다른 사업의 부분에 영향을 주는지에 대해 알고 있어야 합니다. 그래서 이들 다른 그룹들이 계획과 실행에 그들의 요구사항이 맞는가에 대한 보장에 더해 조언을 줄 수도 있어야 합니다. 주요 교차되는 영역은 포함합니다

•	규제 승인 

•	제조와 공급 체인

•	보안

•	IT 시스템

•	작동과 지원

•	재정

**Jim Morrish**: 솔루션 테스트, 특히 모바일 통신 부분에 대한 조언을 줄 수 있습니까? 어떻게 테스트가 이 종류의 환경을 변화시킵니까?

**Stephen Blackburn**: 포괄적인 테스트가 열쇠입니다. 제품의 핵심 기능을 테스트하는 것이 중요할 뿐 아니라, 솔루션이 LAN에 다양한 특성을 가진 휴대 네트워크에서 잘 작동하는가를 보장하는 것도 필수적입니다.

솔루션 테스트에 더해, 기기가 특정한 통신사 네트워크에 허락을 받기 위해 통신사 증명을 통과하려 한다면, 통신사는 당신의 기기가 네트워크상의 “좋은 시민”인지를 체크하려고 할 것입니다. 한 사례는 기기가 당신의 데이터 중심상의 어플리케이션 서버에 연결하는데 실패했을 경우의 재시도 알고리즘의 행동일 수 있습니다. 이 점에서 판독기는 “왜 통신사가 신경 써야 하지?” 라고 의문을 가질 수 있습니다. 그것은 통신사가 네트워크 용량, 그들 무작위 분산이 뒤따르는 네트워크에 사용자 접근을 상정하는 것을 위해 디자인하는 것입니다. 만약 모든 사용자가 네트워크에 동시에 접속하려고 한다면, 혼잡으로 인해 다른 사용자의 서비스 접근이 막힐 것입니다. 그러니 당신이 100,000혹은 수백만 개 기기의 거대한 롤아웃을 계획하고 있다고 상상해 보십시오. 만약 당신의 데이터 중심이 당신의 모든 배치된 기기들이 네트워크와의 연결을 동시에 잃는 중단사태를 경험하고 그것들이 모두 즉시 재시도하고 실패하고 다시 즉시 재시도하고 실패하기를 계속하여 동시에 지역 송신탑과 통신사 네트워크 인프라에 다른 사용자들에게 혼잡을 야기할 수 있는 부담을 줄 수 있습니다. 그러므로 무작위적 후퇴 알고리즘의 디자인과 사전 증명 테스트는 좋은 생각입니다.

솔루션 테스트는 보통 통제된 환경에서의 연구소 테스트를 포함하지만 그것이 후에 배치될 환경에서 솔루션을 테스트하는 현장 테스트 단계를 포함시키는 것도 중요합니다. 연구소 테스트 단계 동안 엔지니어들은 일반적으로 기기가 좋은 휴대 연결을 제공하고 무선 인터페이스에서 지속적인 데이터 비율을 달성할 좋은 신호 수준을 가지고 있다고 보장합니다. 이건 기본적인 테스트로는 좋지만 때로 현장에서 나타나고 낮은 대역폭과 긴 대기 환경을 만드는 나쁜 질의 신호 환경을 강요하는 부정적인 테스트 사례도 도입되어야 합니다. 근 실시간 통신을 요구하는 어플리케이션은 이런 환경에서는 적절히 작동하지 않을 수도 있으므로 어플리케이션을 디자인하고, 기술(2G, 3G, LTE 모든 다양한 대기 특징)을 선택하고, 어플리케이션을 테스트할 때 이를 고려하는 것이 중요합니다.

연구소 테스트가 끝나고 모든 것이 예측대로 작동될 것으로 추정되면, 기기가 예측대로 대부분 작동하리라는 고수준의 신뢰도가 있을 것입니다. 하지만, 연구소에서는 이루어질 수 없는 그런 5%의 테스트 사례가 있고 현장 환경에서 발견되는 사건의 합류지점만이 그런 사례를 드러냅니다. 그러므로 솔루션 개발을 설명하는 모든 사용 사례에 대해 생각하는 것이 중요하고, 그런 사용례를 테스트할 한정된 파일럿 배치에 대해 좀 더 생각하고 계획해야 합니다. 테스트 장소는 나쁘고 좋은 휴대 신호 질을 포함해야 한다. 작은 기기 인구에 대한 현장 테스트는 어떻게 기기 인구가 시작 후 행동할 것인지에 대한 조짐을 제공할 것입니다. 적절한 샘플 크기와 배치 환경 선택을 당신에게 제공하면 당신은 당신 기기의 오차범위내인 1%에 문제가 있을 때 같은 문제를 1%의 당신 기기에서 보게 될 것이다. 당신이 문제를 다룰 수 있고 수용 가능한 여지까지 문제 기기 수를 얻을 수 있다면 작동 후 문제 있는 기기의 비율이 관리 가능하게 남으리라는 높은 수준의 신뢰도가 있습니다.

**Jim Morrish**: 솔루현 배치와 예비단계에서 피해야 할 위험이 있습니까?

**Stephen Blackburn**: 배치 중에 일어날 수 있는 문제는 어플리케이션과 배치 모델 모두에 의존한다. 예를 들어, 기기가 소비자에게 가정에 배치되는 솔루션으로 팔리면 주택 소유자의 일부는 그 기기를 가정 내 가장 통신 전파 범위가 나쁜 곳(지하)에 둘 것이 분명합니다. 어디에 기기를 두어야 할 지에 대한 간단한 설명을 제공하는 것이 중요합니다. 예산 안에 있다면 사용자가 그것을 배치할 때 전파가 충분한 영역에 그것을 두어야 한다는 것을 알려주는 충분한 어떤 표지를 기기에 다는 것이 종종 가치 있을 것입니다.

다른 어플리케이션들은 기기가 맨홀처럼 기지국 전파 범위에 최적이 아닌 곳에 배치되는 것을 요구할 수도 있습니다. 이런 종류의 어플리케이션들은 일반적으로 현장 기술자들에 의해 설치되므로 그들이 그 지역에 걸친 네트워크의 신호 질을 측정할 수 있는 네트워크 스캐닝 도구를 장비하는 것이 중요합니다. 기술자들은 이것을 그 자리의 신호 질을 결정하고 최선의 장소를 정하는데 사용해야 합니다.

**Jim Morrish**: 가동 준비가 된 후에는 어떻습니까– 계획하는데 중요한 것이 무엇입니까?

**Stephen Blackburn**: 만약 솔루션이 파일럿 현장 테스트 단계를 완료했다면 작동 후의 주요 문제들의 위험은 크게 줄었을 것입니다. 하지만, 테스트 중에 당신이 문제가 없으리라고 확신했다 하더라도, 어떤 최종 소비자들이 “작동자 오류” 종류를 포함하는 문제를 겪을 수도 있습니다. 그러므로 적절한 지원 과정을 설치하고 소비자의 불가피한 호출을 다룰 지원 팀을 훈련시키는 것이 필수적입니다So it is essential to setup appropriate support processes and train the support team to handle the inevitable calls from customers.

지원 인력들은 일반적으로 제품 특징과 어떻게 그것들을 작동시키는가에 관해 훈련을 받지만 또한 지원팀(보통 2단계)이 어떻게 연결 문제를 진단할지를 훈련 받는 것도 매우 중요합니다. 이것은 가능하다면 가방에 풍부한 진단 도구가 있는 것이 큰 도움이 될 것입니다. 만약 당신의 2단계 엔지니어가 포탈에 로그인해 문제 있는 기기가 통신사 네트워크에 등록되었는지를 확인하고, 데이터 세션을 시작하고 그들은 최근 행동을 발견할 수 있다면, 그들은 즉시 조사를 문제의 뿌리에 집중하고 고객에게 빠른 피드백을 제공할 수 있을 것입니다. 만약 이들 도구들이 이용 가능하지 않다면 통신사에 전화하는 것이 도움이 되겠지만 일반적으로는 더 많이 느려질 것입니다.

**자산 요소**

초기 솔루션 디자인 단계에서의 입력에 기초해, 이 워크스트림은 자산 하드웨어와 소프트웨어의 디자인을 끝내는 것과 관련된다. 이는 하드웨어 제조, 지역 통신, 펌웨어와 소프트웨어의 선택과 실행, 통합과 테스트를 포함시킬 수 있다.

**자산 하드웨어**

이상적으로는, 게이트웨이와 다른 자산 하드웨어에 더해 요구되는 센서와 반응기는 이미 초기 솔루션 디자인 단계의 일부로서 확인되었다. 이 워크스트림의 일부로서, 추가 테스트와 평가는 일반적으로 모든 요소가 함께 적절히 작동함을 보장하기 위해 수행될 필요가 있을 것이다.
자가제조와 구입의 의사결정 결과에 따라, 외주 과정은 요구되는 하드웨어 부품의 외부 조달을 위해 시작될 수 있다. 대신, 하드웨어 제조와 테스트 과정으로 이어지는 하드웨어 디자인과 시제품과 과정을 시작할 필요가 있을 수 있다.

**자산 작동 시스템과 어플리케이션 컨테이너**

작동 시스템과 어플리케이션 플랫폼 혹은 커네이너의 선택은 하드웨어의 선택과 밀접한 관련이 있다. 많은 M2M/IoT 하드웨어 제공자들은 몇몇은 원격 관리와 원격 펌웨어 업그레이드가 가능한 백엔드 관리 서비스까지 지원하는 통합된 솔루션을 제공한다. 우리가 솔루션 인프라 워크스트림 하의 어플리케이션 라이프사이클 관리에 관련된 모든 작업을 그룹화했음에도 불구하고 이들 두 워크스트림에는 강한 의존성이 있다. 같은 것이 어플리케이션 어플리케이션 플랫폼에서 구동되는 소프트웨어 라이프사이클 관리에도 적용된다. 최종적으로, 로컬 데이터의 백업과 복원 기능의 실행은 이 점에서 다루어질 수 있어야 한다.

**자산 미들웨어**

만약 당신이 M2M이나 IoT 미들웨어를 사용하고 있다면, 이 미들웨어의 특정 자산 요소는 미리 설치되어 설정되어야 한다.

당신은 또한 이 미들웨어를 위한 통신 프로토콜과 보안 증명 관리 보장을 설치하고 설정할 필요가 있다. 이들 작업은 횡절 작업과 솔루션 인프라 워크스트림에 강한 독립성을 가질 수 있다.

유사하게, 어플리케이션 소프트웨어의 분배와 업데이트를 위한 로컬 과정은 테스트되고 솔루션 인프라 워크스트림이 제공한 백엔드 솔루션에 통합되어야 한다.

**기기 통합**

많은 사례에서, 자산 미들웨어는 하드웨어 전용 드라이버의 실행을 요구할 것이다. 그로 인해 여러 기기가 제공한 데이터와 서비스는 동종 포맷의 백엔드에서 사용가능해질 수 있다. 이들 로컬 드라이버와 프로토콜의 디자인과 실행은 과소평가되어서는 안된다.

또한 초기 솔루션 디자인 단계에서 이루어진 특정 인터페이스의 접근가능성에 대한 추정은 옳지 않을 수 있다. 만약 자산이 특정 인터페이스를 제공할 필요가 있다고 밝혀진다면 이 정보는 자산 준비 워크스트림으로 돌려보내질 필요가 있을 것이다. 예를 들어, 우리는 우리의 사례 연구중 하나에서 초기 디자인이 자산은 사례로 드러나지 않은 배터리 건강 데이터에 접근을 허용해야 한다는 가정에 기반함을 보았다. 이 특정 상황에서, 자산을 업그레이드하는 데에는 시간이 좀 걸리므로 차례차례 전체 솔루션의 롤아웃에 영향을 주었던 이 인터페이스를 제공할 수 있었다.

**자산 사업 논리**

자산 사업 논리의 실행은 이 워크스트림의 다른 주요 작업이다. 이는 낮은 수준의 내장 소프트웨어에서 지역 사업 규칙과 데이터 관리를 포함하는 복잡한 사업 논리까지 다양하다. Cisco 같은 회사들은 막대한 양의 데이터를 게이트웨이에 저장하고 지역적으로 처리할 수 있는 강력한 게이트웨이가 달린 “포그” 컴퓨팅 개념을 추진하고 있다. 이는 기능 디자인 과정에 대한 우리의 논의에 관련될 수 있다; 특히 자산 소프트웨어와 백엔드 간의 데이터와 논리 분배에 말이다. 기능 디자인이 초기 제안을 제공하는데 반해, 상세한 내용은 이 워크스트림에서 결정되어야 한다. 데이터와 논리 분배는 백엔드 워크스트림에도 영향을 주기 때문에, 밀접한 두 워크스트림 간의 상호작용이 요구된다. 또한, 우리는 중앙 인터페이스 관리를 프로젝트 관리 과정의 일부분으로 실행할 것을 추천한다 (아래를 보라).

**백엔드 통합**

자산과 백엔드를 통합하는데 있어, 요구되는 프로토콜은 자산에서 지역적으로 이용가능해야 한다. 예를 들어, 어떤 게이트웨이들에는 이것이 항상 주어지는 것은 아닐 수도 있다. 다른 중요한 작업은 적절한 증명과 승인 절차의 규정을 포함한다. 규칙상 사용자 관리는 또한 중앙 백엔드 기능과 동시통합될 필요가 있다.

**자산 준비**

서문에서 논했듯이, Ignite | IoT 방법론은 IoT 프로젝트가 만들어지고 있는 자산 솔루션을 담당하는 주요 조직으로부터 독립되어 시행된다고 가정한다. 이것이 자산과 IoT 솔루션 사이의 조직 인터페이스를 대표하기 때문에, 자산 준비 워크스트림은 매우 중요하다. 그것을 명쾌한 워크스트림으로 만들고, 누가 소유하고 누가 기여해야 하는지를 분명하게 확인하는 것이 중요하다. 기여는 일반적으로 자산 팀과 솔루션 팀 모두에게서 나온다. 전반적인 소유권은 이 두 팀 중 하나에 맡겨져야 한다.

자산 준비 워크스트림은 자산과 분석, (잠재적으로 통합된)디자인, 자산 제조, 솔루션 시행, 지원, 작동을 포함하는 솔루션의 전체 라이프사이클을 보아야 한다.

분석 단계 중에, 자산-그리고 잠재적으로 그 환경-은 안테나, 센서, 표지, 게이트웨이 등 같은 솔루션의 자산 하드웨어 부품을 도입하는 최선의 방법을 정하기 위해 분석될 필요가 있다. 이는 지역 버스 연결과 전력 공급에 대한 접근 같은 측면의 고려를 포함한다.

만약 솔루션이 전문화된 네트워크를 요구한다면, 이 네트워크의 설치를 위한 요구조건은 조사될 필요가 있다. 만약 솔루션이 실내 위치에서 표지(혹은 유사한)에 의존한다면, 표지 위치에 대한 정확한 위치의 데카르트 좌표가 포착될 것이다.

만약 자산이 밑바닥부터 디자인되거나 IoT 솔루션에 맞추어 수정된다면, 명쾌하게 정의된 기술적 인터페이스(하드웨어나 소프트웨어 수준에서)에 더해 디자인 단계에서 두 팀간의 밀접한 조정이 필요할 것이다

자산과 IoT 솔루션간의 통합이라는 면에서, 자산의 EBOM(Engineering Bill of Material)을 고려하는 것은 가치가 있다. 자산은 일반적으로 PLM(혹은 유사한) 시스템에 저장된 완전한 EBOM을 가진다. IoT 솔루션에 있어, BOM은 다른 부분들로 잘 구성될 수도 있다: 내장 하드웨어, 내장 소프트웨어, 백엔드 소프트웨어의 예처럼 말이다. 자산을 위한 EBOM은 최소한 내장 하드웨어에 대한 언급을 포함해야 한다.

결정은 자산의 제조 과정과 관련되어 이루어질 필요가 있다. 자산 하드웨어 부품이 자산 제조 과정의 일부로서 부착되었는가? 혹은 이들이 나중에 새로 장착되었는가? 어떤 경우에든 자산 부품의 공급은 공급 체인 과정에서 고려되어야 한다. 또한 특별한 조립 기능이 요구될 수도 있고 공급은 그것을 안전하게 만들기 위해 필요로 할 수도 있다.

새로 장착하는 접근법의 면에서, Purfresh 사례 연구는 흥미로운 예시를 제공한다. 이 사례에서, 전문화된 기기들(게이트웨이와 센서)은 화물선상에 새로 장착되어야 한다. Purfresh는 컨테이너 선이 솔루션이 설치될 항구에 정박하는 짧은 기간 내에 이 일을 수행하는 대리인을 다루는데 전문화된 과정을 준비한다. 이 과정이 지역 조립만을 포함하지 않고 활성화와 테스트도 포함한다는 것을 유의하라.

최종적으로, 많은 IoT 솔루션들이 판매 후 과정을 향상시키기 위해 디자인된다. 이는 원격 상태 감시, 예측 관리, 심지어는 디지털 판매 후 서비스(서론을 보라)까지 포함할 수 있다. 자산 준비 워크스트림은 새로운 능력과 매끄러운 도입에 관련된 조직 팀들을 훈련시키는 일을 책임질 필요가 있다 – 새로운 조직 단위를 만드는 점에서 필요하다면.

==== iii. IoT 와 Agile –Ignite Team에게 보내는 공개 서한 ====

IoT 프로젝트를 위한 계획/개발/가동에 대한 우리의 논의를 마무리 짓기 위해, 우리는 Managing Consultant at Holisticon AG인 Christian Weiss가 우리에게 쓴 공개 서한을 공유하고자 한다. 우리는 이것이 “두 세계의 충돌” 범주에 대한 매우 좋은 공헌이라고 생각한다.

Ignite | IoT 방법론의 친애하는 저자들에게,

내 불평을 시작하기 전에, 당신들이 처음으로 IoT 방법론을 출판할 수 있게 된 것을 축하하게 해달라. IoT 요구의 증가하는 중요성은 그런 방법론을 요구한다. 당신들의 책과 웹사이트는 매우 가치 있는 공헌이다.

하지만, 당신들의 접근법에 한 중요한 문젯거리가 있다 – 그리고 그것은 나에게 중요하다. 당신들은 맞게 말하고 있듯이, IoT 프로젝트들은 다원칙이고 그렇기 때문에 IoT 방법론은 다양한 기능과 원칙을 결합시켜야 한다. 가장 경험 많은 프로젝트 매니저들은 이것만으로도 큰 위험을 나타낸다는 것에 동의할 것이다. 거기에 더해, 현재의 IoT 프로젝트들은 보통 많은 새롭고 선도적인 첨단 기술을 다루어야 하며, 이는 프로젝트 위험을 더 증가시킨다. 물론 이들 큰 위험은 거대한 기회와 함께 온다; 하지만 그럼에도 이들 위험은 효과적으로 관리되어야 한다.

문제는 당신들이 계획/개발/가동 은유로 단순화시킨 내 의견이 IoT 프로젝트 관리에 대한 폭포 접근을 암시한다는 점이다. 공정하게 말하면, 당신들은 또한 서문에서 Agile이 IoT 프로젝트 관리자의 여러 옵션 중 하나라고 언급하고 있다. 하지만, 당신들은 그것을 뒷받침할 강한 사례를 만들지 않는 것 같다.

계획/개발/가동 은유는 추상적인 관리 수준에서는 유용할 수 있고 원칙적으로는 틀리지 않았다. 하지만, 나는 그것이 과도한 단순화이며 매우 위험한 것이라고 생각한다. 이 위험은 관리가 쉽게 IoT 프로젝트처럼 고위험이 깔려있는 완전하고 상세한 계획을 만들어 낼 영감을 얻고 그 계획을 단계적으로 실행하는 것만이 문제라는 것이다. 만약 이것이 방법론으로 만들어진다면, 나는 내가 여전히 이 접근법을 따르는 프로젝트를 발견하는 것에 놀라지 않을 것이다.

당신들의 계획/개발/가동 접근법 요약은 IoT 프로젝트가 다른 프로젝트처럼 초기 개발 단계에서 시작해 첫 출하 결과 단계로 이어지고 롤아웃과 유지로 이어진다고 묘사한다.

안돼! 그 짓을 그만둬! 단계는 항상 기간과 관련된다. 결과적으로, 계획 단계는 할 일이 계획하는 것뿐이고 개발하지 않는 기간으로 이해되어야 한다. 그리고 개발 단계는 할 일이 개발뿐이고 계획은 안 한다고 암시한다. 나는 이것이 당신들이 암시하는 바가 아니기를 정말로 바란다!!! 계획/개발/가동은 단계가 아닌 원칙으로 보여야 한다. 현실에서는 정말 끝까지 능동적으로 계획하기 때문이다. 그리고 개발 단계는 바라건대 또한 아주 초기부터 시작되어야 한다.

물론 Agile 접근 또한 단계를 알고 있다. 하지만 그 단계들(즉, 기간)은 실행되는 작업에 의해서는 그다지 정의되지 않는다. 대신에, 이들 단계들은 목표, 우선순위, 아티팩트의 종류, 팀 구조 등 다른 특징들을 통해 정의된다. 이것이 이들 단계가 Agile 접근법에서 다르게 불리는 이유이다.

또한 당신들의 서문에는 나를 거의 화나게 만든 다른 한 문장이 있었다: “고정 원가 프로젝트는 종종 폭포 접근을 사용한다”. 불행히도, 이 등치 “고정 원가=폭포”는 여전히 Agile과 고정 원가는 함께 할 수 없다고 주장하는 느림보들을 지원한다. 그건 내 의견과 경험상으로는 완전히 넌센스다!

오해하지 말라: 예산 디자인은 완전히 적합한 요구이다. 하지만, 고정원가는 세세한 디자인 선불을 마무리 짓는 문제가 아니라 프로젝트 전체에서 엄중한 우선 순위 매김의 문제이다. 그리고 이것이 바로 Agile이 투자된 것이다. 나는 그 반대를 주장할 것이다: 고정 원가 프로젝트에 Agile 접근법을 사용하는 것이 성공 확률을 크게 증가시킬 것이라고!

이제 충분하다: 여전히 폭포 접근법을 자주 사용하는 몇몇(특히 큰) 회사들이 그곳에 있긴 하지만 말이다. 하지만, 내 생각에 새로운 방법론은 세계의 개선을 목표로 해야 한다. 그러니 Agile을 IoT 프로젝트의 표준으로 만들지 않겠는가? 내 선의의 비판은 IoT에서 Agile을 지지하는 명쾌한 위치를 주장하는 반면, 당신들의 것은 누구에게나 모든 것에게나 열려있다. 그리고 당신들은 그래서는 안 된다: Agile 접근법은 위험을 관리 가능하게 하는 것을 목표로 한다. Agile의 강점은 바로 미지의 것이 많은 고도로 역동적인 상황에 있다– 그러니 IoT가 아니면 어디에 디폴트가 되겠는가?

나의 제안은: Agile을 Ignite의 디폴트로 하라는 것이다. 그리고 전통적 접근법도 지원되지만 IoT에서 추천되지는 않는다는 회고주의자들을 위한 각주를 달아라.

Best regards,

Christian Weiss

==== b. 블록 만들기 ====

IoT 솔루션 라이프사이클의 계획/개발/가동 관점에 대한 논의를 가졌으니, 우리는 이제 IoT 블록 만들기라고 부르는 것을 소개하고자 한다. 본질적으로, 이들은 우리가 이미 계획/개발/가동 관점의 일부로 보여주었던 어떤 아티팩트 종류의 정식 정의이다.

첫 블록 만들기는 IoT 프로젝트 차원이라고 명명된다. 이들은 정식 프로젝트 요구의 선도자격인 것이다. 프로젝트 차원은 프로젝트 자체 평가, 프로젝트 비교, 구조와 기술 선택 등에 사용된다.

다음 블록 만들기는 IoT 구조 청사진으로 구성된다. 현존하는 건축 청사진(서비스 기원 건축 같은)에 만들어, 이들은 새로운 IoT 프로젝트에 필요한 건축학적 관점을 더하고 요구되는 다양한 건축학적 관점을 통합시키는 상부구조를 제공한다.

세번째로, IoT 기술 프로필은 IoT 프로젝트에 요구되는 가장 중요한 기술을 확인하고 설명한다. 그들은 IoT 건축 관점이 이들 다른 기술들이 IoT 구조 전반에 들어맞는 곳을 설명하도록 개선하고 기술 선택을 지원하기 위해 프로젝트 차원으로 되돌린다.

마지막으로, IoT 프로젝트 DB는 IoT 사례 연구를 구조적인 방법으로 기록하는 것을 목표로 하는 계획이다. 그것은 여러 프로젝트의 핵심을 포착하고, 비교 가능하게 하며, 각각의 프로젝트로부터 학습하기 위해 프로젝트 차원을 사용한다.

{{ :파트2_31번그림.png?300 |}}
                             Ignite | IoT building blocks
                             
==== i. IoT 프로젝트 차원 ====

구조적 방법으로 IoT 프로젝트에 관한 정보를 포착하기 위해 Ignite | IoT 방법론은 5~10개의 부차원이 그룹당 달린(대략 총 40 부차원) 다섯 그룹의 IoT 프로젝트 차원을 정의한다. 각 차원에 Ignite | IoT 는 등급을 1에서 4까지 정의하고 각 등급에 정의를 부여한다.

다섯 주요 그룹은 자산과 기기, 통신과 연결성, 백엔드 서비스, 표준과 규정 준수, 프로젝트 환경이다. 다섯 그룹과 관련 차원의 개관은 아래 도표에서 찾아볼 수 있다.

{{ :파트2_32번그림.png?300 |}} 
                             IoT Project Dimensions
                             
각 IoT 프로젝트 차원은 1~4의 등급을 정의한다. 1은 프로젝트 관리자의 시점에서 낮은/단순한 을 가리키고 4는 복잡한/도전적인 을 의미한다. 다른 차원들에서는 질적 정의를 사용해야 하는 반면에 어떤 차원들에서는 여러 등급 수준을 수량화하는 것이 가능하다. 몇몇 예시들이 아래 스크린샷에 제공되어 있다.

{{ :파트2_33번그림.png?300 |}}
                           Project dimension scales
                             
기초적인 생각은 IoT 프로젝트 차원이 프로젝트 자기 평가를 수행하고, 다른 IoT 프로젝트들을 비교하고, 프로젝트에 쓰일 솔루션 건축과 기술을 선택하는데 사용되어야 한다는 것이다.

{{ :파트2_34번그림.png?300 |}}
                        Use cases for project dimensions
                        
프로젝트 자체 평가를 위해, IoT 프로젝트 차원이 들어있는 엑셀 템플릿을 the Ignite | IoT 웹사이트에서 다운로드할 수 있다. 프로젝트 관리자는 이 템플릿을 프로젝트 차원을 질문표처럼 사용할 수 있다. 최종 결과는 입력의 시각화를 제공하는 Kiviat 도표(혹은 “거미 도표”)이다. 이 과정은 프로젝트 관리자들이 그들의 프로젝트의 위험과 과제에 대한 더 나은 이해를 얻는데 도움이 될 것이다.

프로젝트 비교 목적으로 우리는 현재 우리가 프로젝트 차원 템플릿을 사용해 분석한 IoT 프로젝트 데이터베이스를 만들고. 이 데이터베이스는 또한 Ignite | IoT 웹사이트에서도 사용 가능하게 만들어졌다.

기술 선택 단계 지원을 제공하기 위해, 우리의 목표는 각 IoT 기술 프로필을 다양한 IoT 프로젝트 차원의 측면에서 기술의 적합성에 대한 논의를 통해 끝내는 것이다.

==== ii. IoT 건축 청사진 ====

이미 전에 계획/개발/가동 부분에서 소개했듯이, Ignite | IoT는 솔루션 건축을 다른 건축학적 관점에서 묘사하는데 사용되는 일련의 아티팩트에 의존한다. 다양한 아티팩트의 개관– 특히 기능적 기술적 디자인에서– 은 아래 도표에서 찾을 수 있다.
           
{{ :파트2_35번그림.png?300 |}}       
                          Key Ignite | IoT architecture elements
                                           
이들 몇몇 아티팩스 종류가 잘 알려진 보통 IT 프로젝트의 표준 아티팩트인 반면, 다른 것들은 IoT 프로젝트에서 쓰기 위해 특별히 개발된 전문화된 아티팩트 종류이다. 특히, Asset Integration Architecture (AIA)은 자산과 기기(“사물”)과 백엔드 간의 관계를 설명하는 것을 돕기 위한 Ignite | IoT 방법론의 일부로 정의된다. 이것이 다음 우리의 초점이 될 것이다.

==== 자산 통합 건축 ====

우리는 이미 서론에서 Asset Integration Architecture (AIA)에 대한 높은 수준의 개관을 제공했다. Enterprise IoT 맥락에서 AIA의 기초적인 발상은 대부분의 솔루션이 기업 어플리케이션이 제공하는 백엔드 서비스가 있는 연결 자산을 포함한다. 우리의 정의에 따르면, 자산은 차량, 기계, 건물 같은 기업에 대한 보통 주된 경제적 관심인 독립체이다. 자산에서, 우리는 다양한 종류의 기기, 센서, 반응기(창문을 열기 위한 전기모터) 등을 발견한다. 보통, 이들 기기는 또한 다른 속도로 모터를 작동시키는 것 같은 일종의 내장 전력 관리와 기기 통제를 가지고 있다. 많은 자산들은 또한 다양한 작업을 위한 여러 내장 컴퓨터 시스템을 가지고 있다. 예를 들면, 현대의 자동차는 50에서 80사이의 ECU(엔진 통제 유닛)들과, 동력 전달 장치(엔진, 트랜스미션, 구동 축, 차동 장치 등)를 관리하기 위한 유사하고 전문화된 마이크로 컨트롤러를 가지고 있다. 이것이 우리가 “자산 사업 논리”라고 부르는 것이다.

Enterprise IoT 솔루션에서, 한 전형적인 과제는 고정된 모바일 자산의 큰 무리를 관리하는 것이다. 이것은 보통 자산과 기업 사이에 논리적인 연결을 만들어내는 전문화된 단계를 사용하여 달성된다. 우리는 이것을 IoT 클라우드나 M2M 단계라고 부른다. 이 단계는 보통 게이트웨이와 소프트웨어 에이전트를 배치한다. 게이트웨이는 한편으로는 다른 자산 하드웨어 부품을 물리적으로 연결시킬 수 있고 모바일 혹은 위성 통신을 통해 기업 백엔드와의 원격 연결을 가능하게 할 수 있다. 소프트웨어 에이전트는 소프트웨어 기반 지역 통합 작업을 수행한다. 종종, 에이전트는 다양한 커넥티드 외래 기기들을 담아내는 지역 물체(“기기 프록시 물체”라고 알려진)를 만들어내며 그리하여 백엔드와 함께 한 외래 원격 인터페이스를 제공한다. 에이전트는 또한 사건 관리, 지역 사건 관리, 보안, 지역 소프트웨어 라이프사이클 관리 같은 추가적인 기능들을 제공한다.

대응되는 것은 기업 측의 IoT나 M2M 백엔드이다. IoT/M2M 백엔드는 일반적으로 기기 상태 정보와 사견 역사를 포함하는 원격 자산과 기기에 대한 정보를 관리하기 위해 데이터베이스를 시행한다. 이 자산 저장소는 IoT/M2M 백엔드의 중앙 기능이며 보통 사건 관리나 흐름 처리, 관리와 보안 확인, 특정 자산 지불 기능, 원격 소프트웨어 분배와 결합된다.

게다가, IoT/M2M 백엔드는 다른 종류의 미들웨어 기술을 ERP (Enterprise Resource Planning), CRM (Customer Relation Management), PLM (Product Lifecycle Management)같은 현존하는 백엔드 어플리케이션들을 통합시키기 위해 사용한다.

중요한 건축학적 결정은 새로운 백엔드 어플리케이션 논리가 IoT/M2M 백엔드나 현존 백엔드 어플리케이션 중 어느 것에 시행되어야 하는가 이다. 뒤에서, “IOT 기술 프로필” 부분에서 우리는 BPM (Business Process Management)이 양단간 IoT 과정을 더 투명하게 만들기 위한(“IoT 기술 프로필” 부분의 “미들웨어”를 보라) IoT/M2M 백엔드와 기업 어플리케이션 사이의 통합 층으로서 시행될 수 있는 접근법을 제안할 것이다.
                        
{{ :파트2_36번그림.png?300 |}}
                          Asset Integration Architecture
                          
==== AIA를 다양한 산업들로 지도화하기 ====

AIA의 한 중요한 이익은 그것이 다양한 산업에서 발견될 수 있는 고도로 다양한 많은 접근법에 대한 구조적 청사진을 제공한다는 점이다. 아래의 도표는 어떻게 AIA 지도가 다양한 산업 전문 접근법에 관한 지도를 그리는지에 대한 개관을 제공한다.
                          
{{ :파트2_37번그림.png?300 |}}                  
                          AIA mapped to different industries
                          
예를 들어, 자동차 산업에서는, 당신은 여러, 고도로 전문화된 EUC들이 동력 전달 장치에 분배된 것에서 건축학적 접근법을 보통 발견할 것이다. VCU (Vehicle Control Unit) 는 헤드 유닛으로 작용하고 엔터테인먼트 시스템 같은 다른 시스템들을 위한 중앙 통합 포인트를 제공한다. ECU와 원격 통제 TCU(Telematics Control Unit)이 대부분의 자동차에서는 명쾌하게 분리되어있기 때문에, 우리는 우리의 AIA의 게이트웨이 기능에 TCU 지도를 그렸다. TCU 사용 샘플은 백엔드에서의 차량 관리 솔루션이 될 것이다.

스마트 가정 분야라는 다른 예시를 들어보자. 블루투스, Z-WAVE, EnOcean, 와이파이를 온도 조절 장치나 창문 통제 장치 같은 다양한 지역 접속점에 연결하기 위해 사용할 수 있는 단일 기기에서 게이트웨이 기능을 더 발전된 지역 사업 논리와 결합시키는 중앙 스마트 가정 컨트롤러를 찾을 수 있는 것은 보통이다.

AIA에 쉽게 지도화될 수 있는 다른 사례는 제조업이다. 제조 부문에서, 예를 들어, 공장 제조 라인을 통제하기 위해, 당신은 산업 전기기계 과정을 통제하고 자동화하는데 사용되는 마이크로컴퓨터에 전문화된 프로그램 가능한 논리 컨트롤러(PLCs)를 일반적으로 발견할 수 있다.  그러므로 PLC는 기계에 배치되거나 밀접한 자산 논리일 것이다. SCADA 시스템(Supervisory Control and Data Acquisition)은 원격지시 기술을 원격으로 PLC들의 네트워크를 관리와 중앙 데이터 습득 서버를 백엔드에 제공하는 것을 개선시킨다.

우리가 볼 수 있듯이, Ignite | IoT 방법론에 의해 정의된 자산 통합 건축은 산업 전문 표준에 무관하게 통합 관점에 도움이 된다. 우리는 그것이 어떻게 사용되는지 아래에서 볼 것이다.

==== AIA 기반 IoT 건축 패턴 ====

엄밀히 말하면, AIA는 그 자체로는 건축이 아니라 오히려 IoT 건축 패턴이 관찰될 수 있는 건축학의 렌즈이다. 견고한 IoT 건축 패턴을 위한 몇몇 예시가 아래 도표에 나타나있다.

{{ :파트2_38번그림.png?300 |}}
                             AIA-based architecture patterns

오른쪽에서, 우리는 모바일 폰의 사례처럼 단순한 패턴인 기기 자체가 직접 백엔드에 연결되는 “Device2Backend”를 볼 수 있다. 그 다음에, “Peer2Peer” (혹은 “Device2Device”)가 기기가 각자와 직접 상호작용하는 패턴을 묘사한다. 다음, Next, “Local Hub” 패턴은 여러 기기의 스마트 가정 컨트롤러 같은 중앙 지역 허브를 통한 연결성을 묘사한다. “M2M” 건축 패턴은 중앙 백엔드에 연결된 여러 자산의 더 위계적인 관리를 묘사한다. 우리의 M2M의 정의와 일치하여, 이 종류의 솔루션은 원격 상태 감시(RCM) 같은 어플리케이션으로 한정되고 발전된 서비스를 제공하지 않는다. 그런 서비스들은 “Enterprise IoT” 건축 패턴에 추가된다.

==== 영역간 통합– 사물서브넷(다시) ====

서론에서 논해졌듯이, 많은 IoT 솔루션들은 더 자족적인 솔루션들을 시작할 것이다. 혹은 우리가 그들을 사물서브넷(SoTs)라고 부를 것이다. 차량 관리와 에너지 관리 솔루션 같은 다양한 SoTs를 통합하기 위해, 아래 도표에 묘사된 건축 옵션을 이해하는 것이 중요하다.

{{ :파트2_39번그림.png?300 |}}
                              Cross-domain integration options
                              
원칙적으로, 통합은 AIA의 어떤 층에서든 일어날 수 있다. 기기 수준에서, 통합은 블루투스 같은 어떤 종류의(보통 무선) 근거리장 통신 종류에서든 일어날 수 있다. 다양한 자산 마이크로컴퓨터 사이에서, 지역 버스 시스템은 통합에 사용될 수 있다. 게이트웨이는 또한 Car2Car 통합 시나리오 종류처럼 각자와 직접적으로 상호작용할 수도 있다. wot.io 같은 전문화된 통합 미들웨어 공급자는 여러 다양한 IoT/M2M 백엔드 플랫폼을 통합시킬 수 있다. 대신, 통합은 백엔드의 어플리케이션 수준에서 실제로 일어날 수 있다 –백엔드를 각자와 통합시키든(그리고 그렇다, 이는 EDI나 Electronic Data Interchange가 가까운 미래에는 사라지지 않으리라는 뜻이다) 혹은 기기들이 다른 백엔드(예를 들면, 클라우드 기반 스마트 가정 종류의 통합)와 상호작용해서 일어나든 상관없다.

==== iii. IoT 기술 프로필 ====

“IoT 기술 프로필” 부분은 IoT 솔루션에 종종 사용되는 다양한 기술들을 볼 것이다. 우리가 확인한 기술 프로필은 기기, M2M 하드웨어와 소프트웨어, M2M 백엔드 통신, 일반 미들웨어, 사용자 상호작용(웹, 모바일, 인간-기계 상호작용, 혹은 HMI), 보안, 우리가 플랫폼과 실시가능성이라고 용어를 만든 것을 포함하는 일곱 그룹으로 무리를 이루었다.
                          
{{ :파트2_40번그림.png?300 |}}
                              Technology profiles
                              
우리의 목표는 주요 기술들과 어떻게 그들이 Ignite | IoT 방법론에 묘사된 다른 개념들과 연관되는가에 대한 개관을 제공하는 것이다. 이는 프로젝트 관리자, 솔루션 설계자에게 다양한 기술과 프로젝트 프로필에 따라 언제 그들을 사용해야 하고 언제 사용하지 말아야 하는가에 대한 더 나은 이해의 개관을 제공하기 위해서이다. 우리는 아래 도표에 나타난 템플릿을 따르려고 시도했다. 하지만 실제로는, 그것은 정확히 같은 템플릿을 사용해 모든 기술 프로필을 설명하는 것이 불가능하다는 것을 증명했다. 기술들이 단순히 너무 다양하기 때문이다. 그럼에도, 요지는 어떻게 특정 프로젝트의 프로젝트 차원이 기술이 잘 들어맞을지에 대해 보여줄 수 있을지를 논하기에 앞서서, 기술, 근원적인 기술 건축, 어떻게 AIA에 들어맞는가에 대한 고수준의 개관을 제공하려는 것이다.

{{ :파트2_41번그림.png?300 |}}
                          Technology profile template
                          
==== 1. IoT 게이트웨이와 센서 네트워크 ====

이 부분은 지역 및 백엔드 통합을 가능하게 하는 자산 하드웨어를 IoT 게이트웨이와 관련 개념을 통해 다룬다. 이것이 널리 받아들여지는 표준이 거의 없는 너무 광대한 분야이기 때문에, 우리는 우선 아래의 AIA 그래픽에 나와있는 두 공통 시나리오를 정하려고 시도했다. 공동 자산 통합 위상은 포함한다:

•	IoT 적용: 보안카메라나 지적 전동 공구(Part III를 보라)같은 IP 가능, 지능적, 자족적인 적용. IoT 적용의 이들 종류는 어떤 IP 네트워크로든 직접, 일반적으로 전문화된 외부 게이트웨이를 통하지 않고 통합될 수 있다.

•	스마트폰&웨어러블(이 사례에서는 자산이 아니라 사람에게 “배치된”): 지역 처리 능력과 주변의 웨어러블 기기의 네트워크에 대한 연결성에 더해 이동통신 사업자를 통한 백엔드 연결성을 제공하는 스마트폰. 이는 때로 WPAN(Wireless Personal Area Network)라고 지칭된다.

•	산업&가정 게이트웨이: 이것은 백엔드에 무선의, 혹은 고정선의 연결성 중 하나를 준다. 그들은 또한 지역 통합 논리(표지/어댑터)와 지역 기기기에의 무선, 혹은 유선 연결성을 제공한다. 지역 기기들은 가정 적용(스마트 가정 게이트웨이의 경우)이나 센서(센서 네트워크의 경우)가 될 수 있다.

•	포그 컴퓨팅(Cisco가 만든 용어): 이는 게이트웨이가 막대한 지역 저장소와 컴퓨팅 능력을 추가하는 기본 게이트웨이 개념의 확장이다.

{{ :파트2_42번그림.png?300 |}}
                         IoT gateways and related concepts
                         
==== I. M2M/IoT 게이트웨이 ====

많은 M2M과 IoT 솔루션은 게이트웨이에 의존한다. 게이트웨이는 일반적으로 자산(최소한 우리의 Enterprise IoT 맥락에서는)에 배치되거나 밀접한 전문화된 컴퓨터이다. 게이트웨이는 다양한 기기들, 인터넷, 기업 네트워크에 연결성을 제공한다. 게다가, 게이트웨이는 보통 간단한 경유 논리와 더 복잡한 데이터 수집과 필터링에서 고도로 복잡한 자동화, 분석, 솔루션에 따른 적용 논리까지 지역 논리를 작동시킨다.

M2M/IoT 게이트웨이 중심 건축과 함께 일하는 것은 많은 이점을 갖는다:

•	다양하고 이질적인 기기들이 프로토콜 지도화와 지역 연결성을 위한 게이트웨이를 사용해 더 쉽게 통합될 수 있다
•	게이트웨이는 추상화를 제공하여 더 의미상의 풍부한 적용을 가능하게 한다
•	지역 사업 논리의 실행은 실시간 행동과 반응 시간의 감소를 가능하게 한다
•	게이트웨이는 안정성을 보장하는 수준의 자율화 시행을 돕는다. 예를 들자면 네트워크 문제 사건에서처럼 말이다.
•	지역 데이터 분석과 필터링은 네트워크 트래픽을 줄이는 것을 돕는다
•	게이트웨이는 전반적인 솔루션 보안을 향상시키는 지역 보안 솔루션을 배치할 수 있다
•	게이트웨이는 업계에서 지속적인 기업 정책을 보장할 수 있다
•	내장 하드웨어 사업 논리에서 게이트웨이 기능의 개발은 개별 라이프사이클을 가능하게 한다

오늘날 사용되는 많은 다양한 종류의 M2M/IoT 게이트웨이가 있다. 소비자 게이트웨이는 가정 에너지 관리에 더해 가정 자동화와 보안에 사용된다. 전문화된 상업 게이트웨이는 넓은 범위의 교통, 커넥티드 차량, 제조, 에너지를 포함하는 수직들에 이용된다.
Wyconn의 CEO인 Adi Reschenhofer는 말한다: //“대부분의 M2M/IoT 게이트웨이는 백엔드 연결과 지역 기기, 지역 컴퓨터, 저장 용량의 통합을 위한 무선이나 유선의 연결성 같은 공통 요소를 공유한다. 우리의 M2M/IOT 게이트웨이 매트릭스[see figure below]는 대부분의 일반적인 게이트웨이 종류와 그 주요 요소를 제공한다 .”//
                              
{{ :파트2_43번그림.png?nolink&300 |}}                                  
                   M2M/IoT gateway matrix from Wyconn
        
아래 부분에서, 우리는 현재의 경향과 게이트웨이 선택을 위한 추천을 보기에 앞서 M2M/IoT 게이트웨이의 주 요소들을 볼 것이다.

==== 지역 계산과 저장 ====

칩만이 매 세대마다 더 작아지고 더 강력해지는 것이 아니라 오늘날 우리는 터무니없이 작은 크기와 매우 싼 가격으로 이용 가능한 완전한 컴퓨터 시스템을 가지고 있다. 현대 스마트폰들은 어제의 고급서버 수준의 처리 능력과 저장 용량을 가지고 있다. Raspberry Pi 같은 놀라울 정도로 강력한, 신용카드 크기의, 단일 기판 컴퓨터가 이제 최저가로 사용 가능하다.

2014년의 Gartner 회의에서, 요령 있는 IT 연구 회사는 IoT 프로세서에 대한 예측을 발표했다. 우리는 배운 것을 아래 도표에 요약했다. 발표에서, Gartner는 IoT 가능 프로세서의 선적단위에 집중했다. 흥미로운 메시지는 그들이 실제로 더 강력한 가파른 증가를 32비트 마이크로 컨트롤러에서, 너 느린 성장을 8비트와 16비트 마이크로 컨트롤러에서 예측했다는 것이다. Gartner에 따르면, 내장 프로세서와 어플리케이션 프로세스는 IoT 처리 능력의 일부분을 오직 나타낼 뿐이다.
                   
{{ :파트2_44번그림.png?nolink&300 |}}                   
                Shipment predictions for IoT processors (based on presentation by Gartner)
                
일반적으로, 점점 전통적인 내장 시스템의 영역이 리눅스 기반 플랫폼 같은 고수준 시스템으로 대체되어가는 것은 흥미로운 일이다. 이는 풍부한 미들웨어 기능성(예를 들면, 통신 같은)을 요구하는 기능적으로 풍부한 솔루션에 대한 수요로 인해 추진된다. 고수준 솔루션은 낮은 수준의 내장 시스템을 개발하는기에는 극도로 비싸다. 아래의 그림은 대부분의 일반적인 IoT 플랫폼, 그 주 기술적 특징, 일반적인 사용례에 대한 개관을 제공한다.

Dr. Wehner, Jungmann & Wambacher GmbH의 Managing Director인 Roman Wambacher은 다음 설명을 제공한다: 리눅스와 윈도우 내장형 같은 완전한 OS 시스템은 이제 IoT 게이트웨이로 사용되지만 또한 자동차 인포테인먼트 시스템 같은 어플리케이션에도 사용된다. Intel Galileo같은 더 작은 발자국 시스템이나 VxWorks나 QNX 완전한 내장 OS 시스템은 종종 이질적인 기기와 전문화된 요구조건(기능적 안전, 실시간 요구, 임무 중요성)이 달린 복잡한 어플리케이션에, 그리고/혹은 넓은 범위의 내장 프로세서와 마이크로 컨트롤러에 대한 수요로 인해 사용된다. TinyOS, Contiki, RIOT 같은 가장 작은 내장 시스템들은 종종 동일 환경에서 한정된 지역 계산 자원으로 단일 목적 어플리케이션에 사용된다. 그들은 또한 센서 네트워크 내 센서 접속점에 사용된다. 마지막으로, 마이크로커널– 종종 커스텀 솔루션으로 시행되는– 은 단순 센서 접속점에 사용되며 일반적으로 크기, 비용, 에너지 소비에 최적화 되어있다.

{{ :파트2_45번그림.png?nolink&300 |}}      
                                  IoT application platforms
                                  
==== 지역 무선 연결성 ====

많은 게이트웨이의 주요 요소는 그들이 기기와 센서 접속점을 분산시키는 지역 무선 연결성을 가능하게 한다는 점이다. 대부분은 100미터 아래의 거리에 다리 놓는 것을 다루는 많은 다양한 표준과 기술이 있다. 주요 차이점은 거리/범위, 대역폭과 대기, 전력 소모, 비용이다. 아래 도표는 몇몇 주요 지역 무선 기술의 개관을 제공한다.
                                            
{{ :파트2_46번그림.png?nolink&300 |}}        
                                 Overview of key local wireless technologies                  
                                 
아래는 다양한 기술들의 매우 간단한 윤곽을 제공한다:

•	블루투스 저 에너지: 아마도 가장 큰 생태계(스마트폰, 타블렛, 등)의 기술. 낮은 전력, 좋은 범위, 적당한 데이터 비율

•	15.4: 스마트 에너지 같은 폐쇄 생태계에 사용되는 낮은 에너지 표준. ZigBee와 WirelessHART 같은 고수준 표준의 창설

•	ZigBee: 낮은 전력 소모에 대한 강한 집중. 스마트 미터, 가정 자동화, 센서 네트워크, 원격 통제 장치 등을 대상으로 함. 특히 배터리로 작동되는 기기에 유용

•	Wi-Fi: 널리 도입된, 고 데이터 전송률. 하지만 또한 높은 전력 소모와 상대적으로 복잡한 인프라를 요구

•	NFC: 낮은 전력이지만 매우 좁은 범위

•	IrDA: 좋은 데이터 전송률이지만 송수신선이 필요

==== 백엔드 연결성 ====

게이트웨이를 장거리 원격 백엔드에 통합시키기 위해, 게이트웨이들은 보통 위성통신, 통신사 네트워크(2G, 3G, 4G), 저전력 광범위 네트워크 Low Power Wide Area networks (LPWA), 대도시 영역 네트워크Metropolitan Area Networks (MANs), 혹은 고정선/전선 통신에 의존해야 한다. 이 영역 자체로 중요하고 복잡하기 때문에, 우리는 다음 기술 프로필에 이 부분에서 이 주제(M2M/IoT 통신 서비스)에 전념해야 한다.
                                                   
==== II. 센서 네트워크 ====
 
센서 네트워크는 많은 IoT 솔루션에서 중요한 역할을 할 것이다. 아래 그림에 도시된 바와 같이, 센서 네트워크는 일반적으로 백엔드 통신 (7)을 보장하고, 센서 또는 센서 노드의 로컬 네트워크를 통합하기 위해 지능형 게이트웨이 (4, 1)에 의존한다. 다수의 센서는 멀티 센서 장치에 통합되거나 추가 처리를 위한 로컬 게이트웨이로 데이터를 다시 전송하도록 로컬 무선 통신을 사용하는 센서 노드들로 물리적으로 배치될 수 있다. 멀티 센서 장치는 통상적으로 Arduino, FPGAs 등의 센서 통합 (2)에 특화된 기판을 사용한다. 다수의 센서가 직접 하나 이상의 로컬 버스 시스템을 통해 연결된다 (3). 로컬 무선 통신을 통해 (5) 무선 센서 네트워크가 다수의 센서 노드들 (6)을 연결한다. 
      
{{ :파트2_47번그림.png?nolink&300 |}}       
                                   AIA for sensor networks
                                   
우리가 볼 수 있도록, 대부분의 센서 네트워크는 지역 비즈니스 로직과 IoT 게이트웨이 (위에서 설명한대로)의 기능을 결합하는 로컬 구성 요소를 중심으로 만들어진다. 아래 그림은 이러한 지능형 센서 게이트웨이의 주요 구성 요소에 대한 개요를 제공한다. 

{{ :파트2_48번그림.png?nolink&300 |}}         
   Key features of an intelligent sensor gateway (Source: Bosch Connected Devices and Solutions)      
 
기술의 선택은 주로 일부 구체적인 요구 사항에 따라 달라지며, 심지어 이는 서로 모순될 수도 있다. 예를 들어, 시스템의 정확도에 대한 요구 사항은 비싼 센서 요소의 선택을 초래할 수도 있지만, 예산이 이를 허용하지 않을 수도 있다. 이러한 경우, 최선의 가능한 타협을 찾거나 그에 따라 요구 사항을 조정해야 한다. 당면한 작업에 따라, 일회성 투자는 (특히 소프트웨어 개발), 예를 들어 데이터 융합 수단과 매우 좋은 알고리즘에 의해 비용을 근거로 선택된 센서 요소의 한계를 피해서 작동함으로써, 단위 제조 비용을 감소시키는 데 도움이 될 수 있었다. 

물론, 센서 연결은 중요한 역할을 한다. 우리는 이미 위의 IoT 게이트웨이 부분에서 근거리 무선 기술의 일반적인 세부 내용을 설명하고 비교했다. 다음 표는 영역별로 그룹화되어 일반적으로 무선 센서 네트워크에 사용되는 연결 기술의 개요를 제공한다.

{{ :파트2_49번그림.png?nolink&300 |}}
                  Sensor connectivity (Source: Bosch Connected Devices and Solutions)
                
==== 센서와 센서 범주 ====

대부분의 센서는 하나 이상의 센서 요소를 포함한다 (요구되는 지표에 따라). 큰 생산량 (> 10,000)의 경우, ASIC (주문형 반도체)가 사용된다. 두 부분은 외부에 전기 및 전자 인터페이스와 패키지로 보관된다. 이 패키지는 장착에 사용된다 (보통 회로판에 납땜하여). 

자동차 산업과 같은 대량 생산 환경에서, ASIC는 주변 시스템 (센서 노드)에 의해 제공되는 구성에 따른 센서 요소를 제어한다. 또한 예를 들어 측정된 값을 선형화하고 편차를 보정하여, 센서 요소로부터의 데이터를 미리 처리한다. 센서는 일반적으로 I2C 또는 SPI와 같은 디지털 인터페이스를 사용하여 바깥쪽으로 (주변 시스템과) 통신한다. ASIC는 종종 다른 어플리케이션에 대한 서로 다른 운영 모드를 지원한다. 예를 들어, 현대의 가속도 센서는 매우 적은 전력 및 작동 대기 시간으로 실행되는 모드를 지원한다. 움직임 감지되는 경우 (가속도가 발생하기 때문에), 센서는 주변 시스템을 이를 알리는 메시지를 전송한다. 결과적으로, 주변 시스템은 가능한 한 오래 절전 모드로 남아있을 수 있고, 흥미로운 사건이 발생할 때에만 활성화된다. 

현대의 센서는 센서 요소의 증가를 포함한다. 오늘날 모든 세 개의 공간 축에 회전, 가속도, 자기장을 측정 할 수 있는 센서는 일반적이다. 각 축과 각 유형의 측정은 상응하는 자유도 (DOF)를 지닌다. 따라서, 고도로 통합된 센서는 9DoF 센서가 될 것이다. 

Bosch Connected Devices and Solutions의 센서 네트워크 전문가인 Stefan Schuster는 핵심 센서 범주에 대해 아래에서 설명한다. 

많은 IoT 어플리케이션은 특정 자이로스코프와 가속도 센서에서 동작 및 방향 센서를 필요로 한다. 자이로스코프는 세 개의 공간 축을 따라 시스템의 회전 (선회)을 측정한다. 하나의 축만을 측정하는 고도로 전문화된 센서와 달리, 소비자 기기의 센서는 일반적으로 세 가지 축을 측정한다. 소비자 기기에서 센서의 일반적인 측정 범위는 몇 100 °까지이다. 스마트폰은 이러한 센서를 위한 어플리케이션의 한 분야를 나타낸다. 예를 들어, 획득된 정보는 게임을 실행하는데 사용될 수 있다. 자동차 산업에서, 자이로스코프는 차량의 흔들림을 파악하고 필요한 경우 이를 수정하기 위해 사용된다 (ESP). 회전에 대한 정보는 공간에서 장치의 위치를 알아내기 위해 중력 가속도 (참조, 가속도 센서)에 대한 정보와 통합된다.

가속도 센서는 세 개의 공간 축을 따라 가속도를 측정한다. 이것은 중력 가속도 (지구의 중심 방향에서 1g)를 포함한다. 이 지표 또한 결정되면, 세 개 축의 가속도 센서는 어떤 방향이 "다운"인지 식별할 수 있다. 이는 스마트폰 및 태블릿에서 예를 들어 디스플레이 방향을 설정하는데 사용된다. 소비자 기기에서 이러한 유형의 센서의 일반적인 측정 범위는 모든 세 축에서 +/- 16 G이다. 산업 어플리케이션의 한 예는 사고 감지 (충격 센서)이다. 또한, 가속도 센서는 종종 위치 어플리케이션을 위해 사용된다. 그들은 일반적으로 MEMS 요소의 형태로 소비자 기기에 설치된다. 진동이 측정을 왜곡시킬 수 있지만, 또한 감지될 수도 있다 (센서 능력의 범위 내에서).

센서의 또 다른 중요한 범주는 자기장 센서와 관련이 있다. 이 센서는 설계에 따라, 모든 세 개의 공간 축에서의 자기장을 측정한다. 일반적인 측정 범위는 몇 uTesla에서 1000 uTesla까지이다. 비교의 방법으로 다음과 같은 시나리오를 생각해보자. 슈투트가르트 지역의 자기장은 약 50 uTesla이다. 자기장 데이터를 기반으로, 나침반이 구현될 수 있다. 그러나 높은 정확도를 달성하기 위해, 이 데이터는 중력 가속도 및 회전 장치에 대한 데이터와 결합된다.

이 센서의 가능한 어플리케이션은 나침반 기능, 전류 흐름으로 인해 발생하는 자기장의 검출 (예를 들어 장치의 전원이 켜져 있는지를 확인하기 위해), 또는 방향 및 위치를 변경하기 위한 자기 지문 등록을 포함한다. 

다음 범주는 환경 센서에 관한 것이다. 이 센서는 온도, 습도, 압력, 조명 또는 소음을 감지한다. 가스 또는 공기 중의 물질도 감지할 수 있다. 정확도를 높이기 위해, 상이한 센서 데이터가 종종 결합되고 비교된다. 예를 들어, 정확한 온도 측정은 정확한 상대 습도를 계산하는 필수 조건이다.
이들 센서는 예를 들어 집의 상태를 알아보기 위해 스마트 홈 영역에서 사용된다. 광 센서는 근접 센서로서도 사용될 수 있다. 예를 들어, 센서가 갑자기 가려지는 경우, 이는 스마트폰이 귀에 대어져 있다는 것을 나타낸다.

마이크는 잡음 이상의 것을 인식할 수 있다. 또한 특정 위치에서의 소음 수준을 파악하기 위해 간단한 센서로 활용될 수 있다. 그러나, 지표에 의해 제공된 정보의 수요가 증가함에 따라, 향상된 처리 동력 또는 마이크로프로세서 내의 해당 기능 장치는 곧 주파수 분석을 위해 요구될 것이다. 

마이크 및 광 센서는 여전히 디지털 인터페이스가 없는 아날로그 센서라는 것을 흔히 알 수 있을 것이다. 데이터는 이에 따라 다른 곳에서 처리되어야 한다.

==== 센서 융합 ====
 
현대 센서 네트워크는 종종 센서 융합이라고 알려진 기술에 의존한다. 센서 융합은 여러 센서로부터의 입력을 단일 디지털 모델에 융합하는 것을 말한다. 이 책에서 논의된 첨단 센서 융합의 한 예는 자율 주행이다 (IoT 어플리케이션 영역의 "커넥티드 카" 부분 참조). 이 예시의 경우, 카메라, 레이더, LIDAR와 같은 여러 센서로부터의 데이터는 다른 차량, 보행자 및 자전거 등의 개체를 포함하는 차량 주변 환경의 3D 모델을 만들기 위해 결합된다. 

==== 센서 네트워크 어플리케이션 영역 ====

Bosch Connected Devices and Solutions의 센서 네트워크 전문가인 Stefan Schuster는 스마트 홈, 스마트 웨어러블, 운송 및 물류, 산업 4.0 영역에서의 일반적인 센서 네트워크 사용 행태에 대한 다음과 같은 간단한 개요를 작성했다. 이러한 사용 행태는 특정 영역에서의 대표적인 개발을 위한 출발점으로 사용될 수 있다. 그리고 사용 행태가 새로운 기술이나 새로운 요구 사항 때문에 끊임없이 진화하고 있다는 것에 주목하는 것이 중요하다. 또한, 요구 사항은 개개의 경우에 더욱 최적화될 수 있을지 몰라도, 제조 업체의 플랫폼 전략은 미리 정의된 구성 요소로 만든 센서 노드들로 이어질 수 있다. 이는 구매, 제조, 노하우의 재사용 또는 소프트웨어 부품에 대한 규모의 경제로 개발 시간, 위험 및 비용을 절감할 수 있기 때문이다.

**스마트 홈에서의 센서 노드**
 
스마트 홈 영역은 문, 창문, 심지어 조명과 난방의 상태를 모니터링하고 그에 따라 적절하게 제어하는 솔루션이 포함되어 있다. 정보는 또한 사용자에게 전송되며, 사용자는 시스템을 구성하거나 직접 제어 명령을 사용하여 필요 시 개입할 수 있다.

이 영역에서 센서 노드가 충족해야 하는 요건을 다음과 같이 크게 분류할 수 있다.

•	우리가 초점을 맞추어야 하는 소비자 부문에서, 목표 비용은 매우 빠듯하고, 단위 수는 ‘중간’에서 ‘높음’이다. 제품 라이프사이클은 짧으며, 이는 소프트웨어 업데이트가 가능해야 한다는 것을 의미한다. 센서 노드는 가능한 한 눈에 띄지 않게 가정에 통합되어야 하므로, 그들은 보통 작아야 한다. 사용자는 설치가 용이할 것으로 기대하기 때문에, 통신은 무선으로 이루어져야 한다. 고객은 많은 정비 소요를 원하지 않기 때문에, 배터리 수명은 길어야 한다 (보통 2년). 배터리도 쉽게 사용할 수 있어야 하며, 표준 배터리 형식이 사용되어야 한다. 제조 업체의 전략에 따라, 다른 제조업체 시스템과의 상호 운용 가능성이 중요할 수 있으므로 표준 연결이 필요할 수 있다.

•	시스템은 약속대로 작동해야 한다. 그러나, 필수적인 기능적 신뢰성은 예를 들어 자동차 부품 시스템에 필적하지는 않는다. 목표는 보통 "충분히 좋은" 성능이다.

이러한 요구 사항을 기반으로, 다음과 같은 행태는 시작점으로 정의될 수 있다.

•	센서 요소가 기록해야 하는 데이터는 센서 노드의 의도된 사용에 의해 결정된다. 보통 필요할지도 모르는 추가 센서를 제공하는 것은 좋은 생각일 수 있지만, 향후 기능 향상을 감안해야 한다. 하나의 예는 온도를 측정하는 센서 노드에 가속도 센서를 포함하는 것이다. 향후 소프트웨어 향상에 있어서, 예를 들어 다른 활성화된 사이클 외부에서의 측정을 통해, 고객은 흔들림에 반응하는 센서를 갖도록 기능을 구현할지도 모른다. 센서에 대한 주요 우선 순위는 최소 소비 전력으로 필요한 수준의 정확도를 유지하는 것이다. 소프트웨어는 종종 정확도의 감소를 보완하기 위해 사용될 수 있다. 

•	최소 소비 전력이 반드시 활발한 작동 중 낮은 소비를 의미하는 것은 아니다. 대신, 센서가 가능한 한 오랫동안 절전 모드를 유지하고 등록된 실제 지표에 변경 사항이 생길 때만 완전히 활성화되도록 (예를 들어, 자이로스코프와 가속도 센서의 모션 활성화 비절전 모드) 종종 작동에 대한 지원을 포함한다.
 
•	마이크로프로세서는 처리 동력과 메모리에 대한 ‘낮음’에서 ‘중간’까지의 수요를 충족해야 한다. 일반적인 프로세서는 Cortex M3 또는 M4 core를 기반으로 하고 있다. M4는 디지털 신호 처리 (DSP) 장치를 구비하고 있어, 마이크로부터의 오디오 신호 분석 등 신호 처리를 포함하는 작업에서 선호된다. 일반적인 메모리 크기는 16~128 KB의 램과 64~512 KB의 플래시 메모리이다. 에너지 효율 또한 이러한 맥락에서 중요하다. 이는 일반적으로 작동 중 저전력 소비를 통해서뿐만 아니라, 마이크로프로세서의 매우 작은 부분만이 작동하는 모드를 지원할 때도 달성된다. 이 작은 부분은 데이터와 신호를 미리 처리한 후, 필요 시 전체 마이크로프로세서를 활성화 모드로 이동시킨다. Cortex M3를 기반으로 한 현대 마이크로프로세서는 이러한 모드를 셋, 넷 이상을 가지고 있다. 마이크로프로세서가 작업을 완료하기 위해 완전히 활성화되어야 하는 시간은 가능한 한 짧게 유지되어야 한다. 마이크로프로세서의 비절전 시간도 고려되어야 한다. 이는 짧은 사이클 타임을 보장하기 위해 가능한 한 짧아야 한다.

•	물론 알고리즘은 기능적 요건을 충족시켜야 하지만, 가능한 한 비용이 적게 들고 비용 효율적인 마이크로프로세서가 선택될 수 있도록, 에너지 효율에 최적화되어야 한다 (전자 부품이 가능한 한 자주 그리고 길게 전원이 꺼진 상태로 유지되도록).

•	DC/DC 변환기는 일반적으로 사용되며, 매우 효율적이다. 예산이 매우 빠듯할 경우, 선형 레귤레이터가 사용될 수 있다. 이는 효율적이지는 않지만, 시스템의 배터리 수명 비용 면에서 훨씬 저렴하다. 배터리는 보통 시장에서 쉽게 이용 가능하고 (즉 AA, AAA), 제한된 사용 공간에 적합한 종류에서 선택된다.
스마트 홈 분야에서 사용되는 무선 기술은 매우 다양하다. 대표적인 기술은 위의 무선 연결 표에 제시되어 있다. 데이터 전송률은 일반적으로 낮다. 에너지 효율 때문에, 되도록 적은 양의 데이터를 가급적 거의 전송하지 않는다. 이는 장치에서 되도록 멀리 있는 센서 데이터를 평가하고 높은 수준의 정보만을 전송해야 하는 알고리즘에 영향을 준다. (다음 예를 생각해보자. 알고리즘은 1초 간격으로 문의 가속도 및 회전에 대한 데이터를 수신한다. 그러나, 알고리즘은 데이터에서 “문의 개방” 사건만을 뽑아 전송하다. 이 사건은 훨씬 덜 자주 발생하고 심지어 한 자리 수의 비트로 전송될 수 있다.) 

와이파이는 2 년의 배터리 수명이 필요한 경우 배터리 작동에 실제 적합하지 않으며, 예외적인 경우에만 사용된다. 센서 노드에의 연결은 종종 블루투스 (특히 저에너지 "LE" 변종) 또는 ZigBee를 통해 이루어진다. ZigBee의 경우, 표준은 "문 개방/폐쇄" (참조, ZigBee Home Automation)와 같은 사건들을 명시하기에 충분하다. 반면 블루투스 LE의 경우, 이러한 명시가 높은 수준에 도달하지 못한다. 범위는 일반적으로 중요하지 않다. 그러나, 문제는 매우 두꺼운 콘크리트 (또는 유사) 벽으로 된 집, 또는 큰 집에서 발생할 수 있다. 이 경우, 대체 기술이 선택될 수도 있고, 중간 기착지를 이용할 수도 있다. (ZigBee는 각 노드가 다른 노드들 사이에 데이터를 주고받는 촘촘한 네트워킹을 지원하며, 따라서 전체적인 커버리지를 증가시킨다). 

호환성 요건에 따라, 사용되는 프로토콜은 LWM2M, 독점적 프로토콜, 또는 ZigBee로 명시된 상위 단계일 수 있다. LWM2M 및 양단간 IP 연결은 특히 개별 전송 기술에서 최대의 독립성을 보장하기에 적합하다.

**스마트 웨어러블**

이 영역은 예를 들어, 스포츠 장비에 내장되거나 신체에 직접 착용하는 센서 노드를 포함한다.

이러한 장치에 대한 수요는 스마트 홈 영역처럼 소비자 부문에서 비롯된다. 항목 당 목표 비용은 매우 빠듯하며, 단위 수는 ‘중간’에서 ‘매우 높음’이다. 구성 요소의 공간 요건은 중대한 요소이다. 장치는 일반적으로 배터리로 작동되기 때문에, 에너지 요건도 매우 중요하다. 그러나, 사용자는 보통 배터리 수명에 한계가 있다는 사실을 받아들이고, 이는 재충전 가능한 배터리를 이용함으로써 보완된다. 통신 요건은 일반적으로 짧은 전송 경로 (스마트 폰)로 특징지어 진다.  유사하게, 연결은 스마트폰, 전화에서 사용할 수 있는 무선 표준과 프로토콜에의 연결로 특징지어 진다. 기능적 관점에서, 데이터 수집에서의 사소한 실수가 매우 적고 낮은 비용을 위해 수용되도록 (예를 들어, 하루 중 손목 밴드의 녹음 기능 허용 오차), 요건은 종종 우선시된다. 업데이트 기능은 종종 제한된다. 새로운 기능은 센서 노드에서 구현되지 않고 백엔드 또는 스마트폰에 (앱으로) 추가된다. 그러나, 센서 노드에의 무선 업데이트가 증가하는 추세이다.

이용 가능한 공간 및 전력 요건은 센서 요소를 선택하는 중요한 기준이다. 대체로, 포함된 센서는 필요한 데이터를 수집하기 위한 것이다. 크로스 커플링 효과 때문에 더욱 평가하기 어렵고 데이터 수집에서 더 높은 허용 오차 폭이 발생할 수 있다는 사실에도 불구하고, 공간적 제한으로 인하여, 고도로 통합된 센서 요소 (9 DOF)를 사용하는 것이 좋을 수 있다.

마이크로 프로세서가 충족시켜야 하는 처리 동력 요건은 ‘낮음’에서 ‘중간’이다. 이용 가능한 공간 및 배터리 요건은 결정적 요인이다. SoC (system-on-chip) 시스템은 마이크로프로세서와 하나의 집적 회로 (IC)에서의 무선 연결을 결합시키므로, 이러한 경우에 중요한 이점을 제공한다. 일반적인 메모리 크기는 4-64 KB의 램과 16-256 KB 플래시 메모리이다.

선택된 마이크로프로세스는 공간, 비용 및 에너지 사용 요건으로 인해 보통 매우 작기 때문에, 알고리즘은 많은 양의 데이터가 사이클에 전송되는 방식으로 설계될 수 있다. (무선 전송 범위의 전력 소비는 특별히 중요하지 않은데, 이는 필요한 출력 영역이 일반적으로 낮고 배터리를 충전할 수 있기 때문이다.) 데이터는 스마트폰 또는 백엔드에서 평가된다. 더 많은 데이터가 거의 미리 처리되지 않고 전송될수록, 더 새로운 기능들이 업데이트를 통해 스마트폰 또는 백엔드에서 구현 될 수 있다. 그러나, 이 경우 특정 사용 사례에 크게 의존한다. 예를 들어, 단계 계측기는 확실히 센서 노드의 단계를 식별하고, 오직 스마트폰에만 사건 "단계"를 보고한다.

자산 통합 아키텍처가 몇몇 IoT 아키텍처 패턴을 정의한다는 것을 기억해내 보십시오. AIA에서, 이 영역 대부분의 사례는 게이트웨이의 역할을 하고 비즈니스 로직을 매핑하는 스마트폰과 함께 M2M 패턴에 의해 커버될 수 있다. 다수의 센서가 존재하고 아키텍처가 Device2Device 패턴을 기반으로 하는 경우, 센서들은 서로 연결된다 (인체 통신망).

배터리는 보통 매우 작고 최대 순간 전류가 제한되어 있기 때문에, 전력 요건과 과전류 및 최대 순간 전류는 설계 단계 동안 모든 구성 요소에서 고려되어야 한다. 전력 공급은 적절한 완충 장치를 제공할 필요가 있다.

블루투스 LE는 스마트폰의 광범위한 상호 운용성, 낮은 전력 요건 및 충분한 출력 영역 덕분에, 현재 이용되고 있는 지배적인 무선 연결 기술이다. 

**운송 및 물류**
 
이 영역은 저장 또는 운송되는 동안 컨테이너와 상자 등의 자산을 모니터링하는 데 사용되는 센서 노드를 포함한다. 그것은 위치 (실내 / 실외), 진동, 온도 등의 모니터링을 포함한다. 사용 사례에 따라, 기록된 데이터는 요청에 따라 또는 주기적으로 무선 전송되거나, 지속적으로 기록되고 직접 열람된다 (데이터 이력 기록 장치 사용 사례에서). 데이터가 직접 열람되는 경우 (USB 또는 유사한 장치를 통해), 무선 접속은 필요하지 않다. 전력은 일반적으로 배터리에 의해 제공된다. 신뢰성 요건은 일반적으로 높다. 모니터링되는 자산에 따라서, 많은 단위 수에 대한 단위당 저비용 또는 적은 단위 수에 대한 단위당 중간 비용 중 어느 한쪽으로 결정될 것이다. 배터리 사용 수명은 모니터링되는 자산의 사용 사례와 특히 시간의 길이에 크게 좌우된다. 공간 요건도 모니터링되는 관련 자산에 크게 좌우되지만, 일반적으로 중간 수준의 중요도를 지닌다. 환경적 영향에 기인하는 요건은 특정 환경에 따라 높을 수 있다 (예를 들어 극한의 온도). 

센서 요소의 선택은 모니터링되는 데이터에 좌우되며, 필요한 정확성 수준 또는 다른 요건에 대해 일반적으로 단언하는 것은 불가능하다. 모니터링되는 자산에 따라, 측정 범위는 보통 통상적인 소비자 어플리케이션에서 발견되는 범위 이상으로 확장된다 (예를 들어 냉각실에서의 상품 모니터링).

마이크로프로세서가 충족해야 하는 요건은 ‘낮음’에서 ‘중간’이다. 이들은 일반적으로 녹음 및 데이터 전송을 위한 어플리케이션이다. 데이터가 열람되기 전에 오랜 시간 동안 기록된 설계의 경우, 메모리 요건은 더 높다. 추가 메모리는 종종 이러한 경우에 사용된다. 자산이 모니터링되어야 하는 시간에 따라, 전력 요건은 결정적 요인이 되며 또한 마이크로프로세서 선택에 영향을 미친다.

많은 경우에, 알고리즘은 비교적 간단한 임계 트리거이다. 예를 들어, 모니터링되는 자산이 특정 기간 동안 특정 온도를 초과할 경우, 경보가 작동된다. 그러나, 사용 사례에 따라서 (움직임 감지 등), 알고리즘은 복잡할 수도 있다. 

데이터 전송은 사용 사례에 크게 좌우된다. 세 가지 일반적인 사례는 다음과 같이 구별될 수 있다. 

장치가 넓은 영역 내에서 (예컨대 옥외 등) 모니터링 될 필요가 있는 경우, 그리고 모니터링 중 데이터 전송이 우선시될 경우, GSM 기반 데이터 전송과 같은 기술은 유용하다. 이는 센서 노드를 매우 비싸게 만들고, 많은 양의 에너지를 소비하며, 전원 공급에 높은 수요를 초래하는 높은 최대 순간 전류를 가진다. AIA에서 이는 Device2Backend 패턴일 것이다. 

자산이 관리 가능한 통제된 공간에 있을 경우, 그리고 데이터가 모니터링 중에 전달될 경우, 와이파이 (낮은 에너지 효율을 갖는), BLE, LoRa, 또는 독점적 무선 표준과 같은 기술들이 보통 기존 인프라에 따라 사용될 수 있다. 게이트웨이는 또한 자주 사용된다. AIA에서 이는 기업IoT 패턴일 것이다. 

데이터가 모니터링 중에 전송되는 것이 아니라 필요에 따라 열람될 경우, 하나의 선택지는 케이블 기술을 사용하는 것이다 (예를 들어, 동시에 센서 노드를 재충전하는 데 사용될 수 있는 USB). 그 대신에, 단거리 무선 기술도 좋은 선택이 될 수 있다. BLE는 태블릿, 스마트폰, 또는 PC가 데이터를 열람하기 위해 사용될 때, 이러한 장치들이 폭넓게 지원되므로 특히 적합하다. 

**산업 4.0**

이 영역은 운송 및 물류 분야로 연결된다. 이는 중고 기계 및 장비뿐만 아니라, 재료 및 부품의 모니터링에 관한 것이다. 신뢰성 요건은 높다. 단위 수 당 비용 압박은 스마트 홈과 스마트 웨어러블의 영역의 소비재만큼 높지는 않다. 최소한의 설치 공간에 대한 필요성은 센서 노드가 설치될 위치에 달려 있지만, 우리는 여기에서 공간 요건을 ‘중간’으로 분류한다. 어플리케이션에 따라, 전력은 케이블을 통해 이용 가능할 수 있다. 그러나, 배터리는 일반적으로 이런 유형의 센서 노드를 새로 장착하는 데 필요한 노력을 최소화하기 위해 사용된다. 환경적 영향에 기인하는 요건은 매우 높다 (예를 들어, 극한의 온도, 오일 미스트 또는 진동을 포함하여). 

센서를 선택할 때, 보통 높은 수준의 신뢰도 및 정확도가 주요 결정 요인이다. 기계는 광범위 내장형 센서를 지닌다. 사용 사례와 이러한 센서들의 연결에 따라, 센서가 수집하는 데이터는 전체 솔루션이 전용 센서 노드 없이 달성될 수 있도록 활용될 수 있다. 그러나 솔루션을 새로 제공하는 경우, 설치될 센서 노드는 이후 유용해질 것이다.

마이크로 프로세서는 ‘중간’에서 ‘높음’의 요건을 충족시켜야 한다. 알고리즘은 매우 복잡해질 수 있으며, 높은 신뢰성은 상응하는 높은 메모리 및 처리 동력 요건과 함께 복잡한 소프트웨어를 필요로 한다. 센서 요소와 마찬가지로, 비용 압력은 적은 단위 수를 고려하면 높은 단위 수의 소비자 어플리케이션에서만큼 중요하지는 않다.

솔루션이 (특히 새로 제공된 솔루션) 완전히 무선으로 이루어져야 하는 경우에는 에너지 효율이 중요하다. 센서를 숨겨진 위치에 설치하는 경우, 배터리를 교체하는 것은 필요한 고장 시간과 작동 시간에의 영향으로 고비용 요인이 된다. 센서가 설치된 위치에 따라, 큰 배터리를 선택함으로써 긴 배터리 수명이 달성 될 수 있다.

알고리즘에 관해서는 많은 경우 에너지 효율 요건 및 이용 가능한 에너지에 좌우된다. 이러한 요건이 매우 빠듯할 경우, 상위 시스템과의 통신이 거의 필요하지 않도록, 센서 노드에서 데이터를 처리하는 것이 좋다. 예를 들어, 특정 마모 수준에 도달했을 때만 사건이 전송된다. 데이터 평가에서 유연성이 우선시되는 경우, 그리고 진동 데이터 등의 다른 정보가 백엔드로 전송되어야 하는 경우, 배터리 수명을 대가로 데이터 전송이 더 자주 일어나야 한다.

많은 경우에 무선 통신 환경에 유리한 조건을 제공하지 않기 때문에, 무선 연결은 산업 부문에서 매우 중요하다. 예컨대 LoRa 같은 기술은 여기에서는 유용할 수 있지만, 무선 표준은 아직 확립되지 않았다. 대부분의 기계 사업자 및 제조 업체는 보통 독점적으로 사용되는 필드 버스 시스템에의 연결을 원한다. 이는 이후 어플리케이션을 위해 특별히 개발된 적절한 게이트웨이를 이용하여 수행될 수 있다.  

==== III. 경향과 전망 ====

IoT 게이트웨이, 센서 네트워크 등의 전체 영역은 빠르게 변화하는 IoT 분야이다. 베를린에 위치한 openBerlin Cisco IoT Innovation Center의 CTO인 Mitko Vasilev와의 다음 인터뷰에서, 우리는 게이트웨이 기술의 일부 현재 동향에 대해 논의할 것이다.

**Dirk Slama**: Mitko, Cisco는 포그 컴퓨팅 방향에 대규모 지원을 하고 있습니다. 우리가 이 분야에 어떤 발전을 기대할 수 있습니까?

**Mitko Vasilev**: 우리는 우리의 사업 절차, 사회 소통, 개인적 삶을 최적화하기 위해 우리 환경을 디지털화하고 있습니다. 지수적 데이터 성장과 실시간 디지털화 요구는 인터넷이 끝나고 현실 세계기 시작되는 완전한 네트워크의 끝에 분배될 클라우드 기능성이 있는 추가적인 지능 층을 요구할 것입니다. 많은 주요 회사들이 “포그”라고 알려진 가장자리에 새로운 지능 층을 포함하는 공개 IoT 건축을 도입했습니다.
포그 층은 분산된 계산, 저장, 분석에서 패러다임 전환을 이끌 것입니다. 오늘날, 사업들은 일반적으로 다양한 서비스를 위한 분리된 기기와 다양한 소프트웨어 컨트롤러를 배치합니다. 포그 개념은 단일 분산 플랫폼에서 서비스, 조직화, 관리능력, 프로그램능력을 결합시킵니다.

포그 기반 건축은 Enterprise IoT와 Home IoT의 게이트웨이에서 어떻게 기기들이 연결되고 데이터가 처리되는지를 변화시킬 것입니다. 오늘날, 데이터는 공공 혹은 개인 클라우드에 보내지고, 처리되고, 저장됩니다. 그곳에서 데이터는 분석되고 명령이 그 정보에 대응하라는 기기로 다시 보내지고 그러면 오퍼레이터가 통지를 받습니다. 포그 컴퓨팅은 비용이 많이 드는 지속적으로 데이터를 단일 데이터 호수에 이동시키고 흐름 분석과 그대로인 데이터를 실시간 분석에서 데이터 포인트에 가까운 움직일 수 있는 데이터로 변화시킬 필요를 극복하도록 돕습니다. 새로운 방법론들이 새로운 사업 모델을 열어놓고 새로운 준수와 규제 정책에 부합되도록 돕고 있습니다. 이는 오늘날 IoT의 대량 도입을 가속시키는데 중요하며, 미래 성장에 요구되는 비용 효율이 높고, 측정가능하며, 안정적인 인프라를 제공할 것입니다.

**Dirk Slama**: 가정 게이트웨이에 잠깐 초점을 맞춰봅시다. 이 공간에서 무엇이 일어나는 겁니까?

**Mitko Vasilev**: 가정 IoT 게이트웨이는 생겨나고 있으며 사용되는 소프트웨어와 서비스 면에서는 다른 여러 흔한 하드웨어 플랫폼으로 계속 생겨날 겁니다. 근본적인 작동 시스템은 조직화와 기기 관리를 위한 많은 공개 커뮤니티 지원 도구와 결합된 오픈 소스 리눅스 시행 (대부분 Debian variations, Busy Box, 혹은 Yocto)에 일반적으로 기반하고 있습니다. 엔터테인먼트 가능 게이트웨이 분야의 현재 경향은 모든 기기에 대한 비디오 스트리밍, 가정 미디어 서비스, 통합된 가정 감시 관리 능력에 대한 큰 강조와 함께 계속될 것입니다. 게이트웨이는 기기들과 가정 내의 라디오와 IoT 통신 스택 (Bluetooth 저 에너지나 ZigBee와 Z-Wave 처럼 802.15.4 on 868 MHz/902 MHz ISM 밴드의 변형 같은)을 사용하는 통제 시스템과 상호작용할 필요가 있습니다. IoT 미들웨어 시스템은 환경감지 능력을 확장하기 위해 게이트웨이를 내장 센서나 주로 무선 기술로 연결된 센서와 함께 사용할 것입니다. 이는 IoT 어플리케이션이 완전히 개인화된 가정 경험을 제공하는데 필요한 데이터와 플랫폼을 제공할 것입니다. 일반 목적 CPU에 기반한 오픈 소스 하드웨어 플랫폼은 이들 어플리케이션을 비용과 사용 편의성 면에서 더 매력적으로 만들어 기온, 빛, 보안 시스템을 위한 컨트롤 기기 같은 개인화된 서비스의 대량 도입을 위한 길을 닦고 있습니다.

대부분의 게이트웨이는 여러 ISM(산업, 과학, 의학 Industrial, Scientific, and Medical) 라디오 밴드에 동시에(i.e. 169/433/868/902 MHz, 2.4 GHz, and 5 GHz) 연결성을 제공할 것입니다. 이는 커넥티드 사물이 밀집된 환경과 기가 비트 범위의 더 높은 데이터 통신 속도에 대한 대응입니다. 게이트웨이에 통합된 라디오는 이미 BLE, 무선, 새로운 표준기반 802.15.4 라디오와 단일 내장 칩간의 결합을 시작했고 이 경향은 더 큰 규모로 계속될 것 입이다. 여러 산업 연합이 지역 영역 연결성과 네트워킹과 소프트웨어 통신 수준 모두에서 IoT 게이트웨이와 가정 적용간의 정보 처리 상호 운용을 가능하게 하기 시작할 것입니다. 하지만 정보 처리 상호 운용은 여전히 가까운 미래에 극복되어야 할 주요 과제로 남아있습니다.

가정 IoT 게이트웨이의 어플리케이션 호스팅 능력은 새로운 “서비스로서의 플랫폼”(PaaS) 스타일 어플리케이션 인도를 커넥티드 가정에 향상된 최종소비자 경험으로 가능하게 할 것입니다. 게이트웨이, IoT Paas, IoT 클라우드에서의 미들웨어 소프트웨어 층의 결합은 개방된 양단간 수직 건축을 만들어낼 것입니다.

IEEE 표준 (기기 비준을 위한 802.1x, 무선 전파를 보호하기 위한 802.11i 등 같은)사이버보안 구조는 대다수의 가정 IoT 게이트웨이와 그에 연결되는 기기들에서 자동화될 수 있을 것이다.

멀티미디어 처리와 프로토콜 번역을 없애기 위해 일반 목적 CPU와 DSP와 결합된 SoC 서킷은 가정 IoT 게이트웨이에서 점점 흔해지고 있습니다.

**Dirk Slama**: 감사합니다! 그리고 기업 측에서는 어떻습니까?

**Mitko Vasilev**: Enterprise IoT 게이트웨이의 하드웨어 건축은 두 주요 CPU 건축으로 나뉩니다: 로우엔드를 위한 ARM기반CPU와, 특정 사례에서, 중간 범위 게이트웨이, 그리고 특정 중간 수준과 모든 고 수준 제품 라인을 위한x86기반 CPU로 말입니다. CPU건축의 통합은 플랫폼간 사업 어플리케이션 개발을 가능하게 할 것이고 가상 현실화 통합에 더해 네이티브 서비스를 단순화시킬 것입니다. 대부분의 게이트웨이는 이미 고도로 양단간 IoT 건축 보안에 최적화된 하드웨어와 소프트웨어 스택의 결합을 제공할 것입니다.

모놀리식 운용 시스템은 내장 하드웨어의 최적화 증가를 이루기 위해 가상 현실화될 것입니다. 현대Enterprise IoT게이트웨이에서, 다양한 하이퍼바이저 기술들 (KVM, WR 등 같은)이 만연한 멀티코어 건축들을 최적화하기 위해 사용될 것입니다. 기업 수준 지원을 받는 리눅스/유닉스 기반 운용 시스템은 유연성과 사업 어플리케이션 생태계로 인해 지배적으로 될 것입니다. 가장 최신의 게이트웨이 운용 시스템이 강요된 내장 환경의 사용을 최적화할 수 있는 역동적인 마이크로 서비스 (즉. 루팅, 보안, 컨텐츠 인도, 어플리케이션 컨테이너 호스팅 등)에 포함될 것입니다. 기업 시장에서는, 하드웨어 재생 사이클은 일반적으로 20+년의 범위 내에 있고 이는 더 특별히 만들어진 확장된 하드웨어 라이프사이클이 있는 IoT 하드웨어를 도입할 것입니다. 새로운 게이트웨이와 서비스의 주류 이용가능성은 단일 유연 건축을 복제할 특정 수직을 위한 특별히 만들어진 게이트웨이의 수요를 추진하고 있습니다. 참조 설계는 여러 그룹으로 주로 다양한 확인, 준수, 사업 요구사항들로 인해 구조화될 것입니다. 게이트웨이 모듈성은 유연한 IoT 개발을 위해, 그리고 다양한 인터페이스– IEEE 802.11, IEEE 802.15.4, Modbus, RS485/232 – 와 많은 다른 개방되고 소유된 연결에 대한 수요로 인해 커질 것이고 다가올 수십 년간 중요한 역할을 할 것입니다..

포그 컴퓨팅은 미들웨어 서비스와 분산 계산과 저장 용량이 모든 게이트웨이 범위에 걸쳐 가능해지게 할 것이다. 더 진보된 조직화와 관리 구조는 자원을 전체 기업 영역의 최첨단에서 최적화시킬 것이다. IoT 기업 어플리케이션을 위한 순수한 연결성 게이트웨이는 사물인터넷처럼 사업에 지장을 주는 경향이 요구하는 새로운 사업 모델 인프라를 제공할 수 없을 것이다.

지역 무선 연결성은 더 표준화된 ISM 밴드인 IEEE 802.11와 IEEE 802.15.4에 기반한다. 강한 기업 수준 사이버보안 정책 구조는 산업 보증 준수(802.1x, 802.11i, 등)를 보장하기 위해 모든 통신에 강요될 것이다.
지역 무선 연결성은 지배적인 낮고 중간 수준 IoT 게이트웨이에서는 Gigabit Ethernet으로 이동하고 있고 고급 게이트웨이에서는 다중 기기비트 인터페이스(2.5 Gbps, 5 Gbps, 10 Gbps)의 높은 도입율을 보인다. 다중 기가 비트 속도는 고속 IEEE 802.11ac 무선 인터페이스, 고속 처리량을 위한 사업 요구사항, 대역폭 요구 어플리케이션을 결합시키는 게이트웨이에서 필요해질 것이다. 속도는 통제 없이는 아무것도 아니며, 이 원칙은 또한 기업 네트워킹 영역에도 적용된다. 결정적인 네트워킹은 보증된 네트워킹 서비스를 제공하며, 한번 IEEE 시간 감지 네트워킹(TSN)에 기반하면, 그 기술은 Enterprise IoT 게이트웨이가 새로운 사용 사례와 제조, 자동화 등 같은 산업 수직을 위한 사이버보안 구조를 가능하게 할 것이다. 독점 결정적인 네트워크는 산업 소비자의 재생 사이클이 IEEE 표준에 기반한 개방 TSN 건축에 조정됨으로 인해 이후 10년간에 사라질 것이다.

Enterprise IoT 게이트웨이는 게이트웨이 자체의 복잡한 분석과 프로그램 가능 기능에 필요한 출력 능력을 제공하는 멀티코어 계산 효율 하드웨어 건축에 기반한다. 매우 많은 프로토콜 번역과 데이터 일반화 기능이 IoT 목적으로 특별히 만들어진 CPU와 소프트웨어 스택에 의해 하드웨어 가속이 될 것이다. 하이퍼비전은 포그 층에서의 보안 고립과 다양한 마이크로서비스에 더해 내장 하드웨어의 비용 최적화 사용을 위해 필요한 추상화 층을 제공할 것이다.

영구적인 저장 용량은 SSD 저장장치에서 테라바이트 수준으로 증가하여 분산 저장 층이 데이터 할당과 저장 운용을 최적화할 수 있게 할 것이다. 처리 전문 데이터의 다수는 기업 영역의 끝에서 흐름 처리되고 분산된 방식으로 포그와 클라우드 층 사이에 저장될 것이다. 흐름 분석은 데이터원에 밀접한 데이터에 행동하고 영업 부문과 클라우드 간의 잠재를 완화시키기 위한 원리를 제공한다.

IoT 미들웨어는 포그 게이트웨이에서 클라우드 층까지 이와 같이 데이터 제공, 어플리케이션, 정책, 분석, 사업에 걸친 향상된 사용자 경험을 조정할 것이다. 경량 분석 엔진은 게이트웨이 스택 안에 만들어지고 프로그램 되어 중앙집권화된 사업 지능 어플리케이션에 의해 REST API를 통해 통제될 것이다.

요소 관리 기능성은 진정한 소프트웨어 정의 네트워킹 건축에서 대부분의 기능들이 네트워크와 기기 컨트롤러에 추상화되어 가상현실화에 결부될 것이다. 통신을 위한 개방 프로토콜은 더 넓은 사업 기반 표준 MQTT, XMPP, AMQP, 그리고 특정 사업과 운용 수요에 봉사할 수십 가지의 도입으로 지배적이 될 것이다.

사물인터넷은 전례 없는 속도로 기업과 가정 네트워크의 디자인과 운용을 교란하고 있다. 개방된 표준 기반 건축으로 시작하는 것의 중요성은 오늘날 빠르게 미래에 사업의 성공을 보장하는 주요 요소가 되어가고 있다.

==== IV. 추천 ====

IoT 게이트웨이에 대한 이 부분을 프로젝트 관리자를 위한 일련의 행동 가능한 추천들로 결론짓기 위해, 우리는 두 전문가와 시행 측에서의 그들의 경험에 대해 이야기했다. 우리는 게이트웨이 판매 회사 측면부터 시작할 것이다: Adi Reschenhofer는 M2M/산업 인터넷 게이트웨이의 판매사인 Wyconn의 CEO이다.

**Dirk Slama**: Adi, 왜 게이트웨이가 IoT 프로젝트에서 중요한 역할을 수행합니까?

**Adi Reschenhofer**: 게이트웨이 기반 건축은 미래 IoT 프로젝트의 주요 접근법입니다. 게이트웨이 기반 건축은 보안, 첨단 기기 기능성, 게이트웨이 자체를 통한 프로토콜 같은 주요 프로젝트 요소를 업데이트하게 해 줄 것입니다.

**Dirk Slama**: 주문제작 요소를 게이트웨이에 시행할 최선의 방법은 무엇입니까?

**Adi Reschenhofer**: 특정 요소가 스마트폰에 필요하다면, 그저 앱을 앱스토어에서 다운로드하면 됩니다. 이것이 IoT 플랫폼이 가까운 미래에 제공할 수 있을 것입니다. IoT 프로젝트는 현재 주문제작 소프트웨어와 하드웨어 개발을 포함하지만, 이 발상은 가능한 한 상품화하는 것입니다. 이는 하드웨어가 곧 표준 기성 제품으로 이용가능해지리라는 것을 의미합니다. 소프트웨어 요소는 시장에서 구입될 수 있고 디자인된 게이트웨이에 분배될 수 있는 앱에 포장될 것입니다.

**Dirk Slama**: 보안은 어떻게 시행됩니까?

**Adi Reschenhofer**: IoT 프로젝트에서의 보안에 관한 우리의 어려운 문제는 게이트웨이와 다른 기기(사물)이 사용자 상호작용 없이 입증될 필요가 있다는 사실입니다. 이는 게이트웨이나 기기의 정체성이 제조 도중에든 혹은 이후 예비 과정에서든 세워질 필요가 있다는 것을 의미합니다. 네트워크의 끝부분에서 게이트웨이가 시행되게 하는 것은 보안 정책의 업데이트나 필요할 경우 전체 보안 알고리즘의 교환을 제공합니다.

**Dirk Slama**: 준비된 게이트웨이를 가지는 것의 다른 이점은 무엇입니까?

**Adi Reschenhofer**: 게이트웨이 기반 건축의 추가 이점은 원천에 가까운 데이터의 처리나 저장에 사용될 수 있고 대량의 데이터를 백엔드 시스템에 보내는 것을 피할 수 있는 자원을 포함합니다. 그에 더해, 단순히 앱을 개발하여 미래 요구사항에 적응할 가능성을 가지는 것은 시장의 시간을 가속시키는 큰 이익입니다.

**Dirk Slama**: 어떻게 프로젝트를 위한 올바른 게이트웨이 범주를 선택합니까?

**Adi Reschenhofer**: 잘 맞는 것을 찾는 것이 주요 과제입니다. 게이트웨이의 적절한 배열은 사용 사례에 의해 정해집니다. 컴퓨터와 인터넷 연결성은 비싸고 에너지를 소비하는 동인입니다. 계산과 연결성 수요 추정에 노력을 쏟는 것이 지속 가능한 솔루션을 시행할 열쇠입니다.

**Dirk Slama**: 어떻게 주문제작 게이트웨이와 기성품 게이트웨이 사이에서 결정합니까?

**Adi Reschenhofer**: 자가제조와 구입 결정은 특정 요구 표준 제품의 이용가능성에 기반합니다. 표준 게이트웨이가 당신에게 당신의 IoT 프로젝트에 요구되는 요소들을 제공할 수 있는 사례에서, 그것을 사용하는 것은 명백합니다. 이는 디자인, 개발, 테스트, 증명, 주문제작 기기 생산에 필요한 시간을 절약하게 해줍니다. 몇몇 사례에서, 시리얼, USB, 이더넷, 혹은 다른 포트 같은 하드웨어 모듈의 추가 같은 현존 제품에 대한 소수 적응은 또한 요구되는 솔루션을 인도할 수 있습니다.

특정 사례에서, 비 기술 요소는 의사결정과정에 영향을 줄 수 있습니다. 게이트웨이가 소비자 솔루션에 필요하다면, 브랜드 디자인은 매우 중요하고 가장 아마도 고객 인클로저의 결과가 나올 것입니다. 만약 당신이 게이트웨이를 현존하는 기계에 새로 장착하고 있다면 재디자인이 또한 필요할 수도 있습니다.

**Dirk Slama**: 관리가능성 면에서 주의해야 할 주요 측면이 무엇입니까?

**Adi Reschenhofer**: 당신은 기본적으로 당신의 솔루션이 완전한 솔루션 라이프사이클 즉, 계획/개발/가동을 지원한다는 것을 보장해야 합니다. 모든 단계에서, 관리 시스템은 완전한 가시성과 통제를 제공해야 합니다. 또한 CPU 사용, 메모리, 결함 없는 운용을 보장하기 위한 저장 사용 같은 게이트웨이의 중요 수치를 감시하는 것이 중요합니다. 관리 플랫폼은 또한 펌웨어와 전문 앱을 분산시키기 위해 사용됩니다.
판매 회사의 관점에서 이들 통찰을 만들면서, 우리는 또한 Managing Director of Dr. Wehner, Jungmann & Wambacher GmbH이며 컴퓨터 통신과 M2M에서 부티크 소프트웨어 회사에 강한 뿌리를 둔 고도의 전문가인 Roman Wambacher 와 대화했다. 아래 인터뷰에서, Roman은 우리에게 일반적인 프로젝트 관리자의 관점을 제공한다.

**Dirk Slama**: Roman, 게이트웨이 관점에서, 무엇이 복잡하고 광범위하게 배치된 자산의 M2M/IoT 프로젝트에 포함된 중요 과제입니까?

**Roman Wambacher**: 처음으로 떠오르는 것은 이질성입니다. 많은 우리 고객들은 수만 개의 자산을 실지에 수년간 배치해왔습니다. 우리가 관여한 많은 프로젝트들은 게이트웨이를 현존하는 제품 라인에 새로 장착해왔습니다. 매우 자주, 각각 다양한 제품 변종이 전 세계에 롤아웃된 복잡한 자산 클래스나 제품 종류의 다양한 생성이 있습니다. 이는 이들 제품에서 다양한 기기의 인터페이스가 매우 이질적이라는 것을 의미합니다. 우리는 종종 아주 많은 인터페이스를 다루어야 하고, 퇴보는 심지어 새로운 솔루션에게도 치명적입니다. 많은 고객들이 이미 실제로 사용되는 자산들에 초점을 맞추며 솔루션을 시작합니다. 이 방식으로, 그들은 커넥티드 자산의 큰 기초에 매우 빠르게 접근할 수 있습니다.

**Dirk Slama**: 그래서 당신은 어떻게 이 이질성을 다룹니까?

**Roman Wambacher**: 글쎄, 우리가 추천하는 하나는 우리의 고객들이 그들의 프로젝트 포트폴리오를 위한 전용 인터페이스 관리 시스템을 만들게 하는 것입니다. 이 시스템은 하드웨어와 소프트웨어 인터페이스를 프로토콜 수준과 기술적 수준에서 다루어야 합니다. 그것은 또한 버전차별전략, 제품 변종, 하위호환성을 고려해야 합니다. 밀접하게 관련된 문제는 제품 변종 관리에 관련됩니다. 오직 이를 중앙에서 다룸으로서 당신은 세계 M2M과 IoT 솔루션을 큰 규모로 다룰 수 있습니다. 예를 들어, 당신은 어떻게 특정 제품의 다양한 설정을 다룰지를 통제하는 중앙 구조를 필요로 합니다. 만약 당신이 이를 적절히 다루지 않으면– 자동화 방식을 통해 이상적으로– 비용 면에서 나중에 큰 타격을 받을 것입니다.

**Dirk Slama**: 데이터 이용가능성은 어떻습니까?

**Roman Wambacher**: 네, 그것은 또한 데이터 질만큼이나 중요한 문제입니다. 전IoT 세계에서 디자인되고 배치된 대부분의 제품은 단순히 이 문제게 관심을 둘 필요가 없습니다. 제품의 생명은 현장에서 고립된 삶입니다. 배터리 충전 수준을 예로 들어봅시다. 모든 가능성에서, 비개념 제품은 이 기능에 고수준 인터페이스를 제공할 노력을 쏟을 필요가 없습니다. IoT 세계에서는, 이 상황은 매우 다릅니다. 연료 소모나 작동 시간 같은 사물의 인터페이스는 갑자기 매우 중요해 집니다. 많은 프로젝트에서, 솔루션 측의 사람들은 그런 기초 자산 기능이 전혀 가능하지 않거나 요구되는 수준이 아니라는 것에 놀랍니다. 내장 소프트웨어 개발자가 커넥티드 세계에서는 자산이 일시적으로 작동 시간을 시작 시에 0으로 만들어 버리면 그게 문제가 될 수 있다는 사실에 대한 생각을 가지지 못할 충분한 가능성이 있습니다. IoT 세계에서 이는 즉시 드러납니다.

대신, 제품 확인 같은 것을 들어봅시다. 매우 적은 현존 제품 라인이 실제로 현장에서 자동화된 인터페이스나 전자 확인 판을 통해 자산을 특유의 방법으로 확인하는 일관된 방식을 가지고 있습니다. 그러므로 당신은 아마도 창의적이게 되고 이 문제를 솔루션 수준으로 이동시켜야 할 것입니다. 예를 들어 QR 코드나 비슷한 것에 기반한 짝을 이루는 방식을 사용하는 것처럼 말입니다.

**Dirk Slama**: 당신은 이런 종류의 솔루션을 어떻게 다룹니까?

**Roman Wambacher**: 당신은 이것을 제품 종류마다, 버전마다 구조적으로 다루어야 합니다. 제품에서 나온 모든 데이터는 제품 타입과 버전마다 승인되어야 합니다. 당신은 다양한 제품 버전이 가질 수 있는 “제품 건강” 같은 기초적인 것들의 많은 다양한 의미들에 놀랄 수도 있습니다. 통합 테스트는 매우 중요합니다– 당신은 충분히 이르게 시작할 수 없습니다. 그리고 물론, 당신은 현장 테스트를 행해야 합니다. 마지막으로, 당신의 프로젝트 계획은 예상외의 것을 제공해야 합니다. 특히 자산 면에서 변화를 요구하는 경우, 환경 같은 인터페이스 문제 수정의 복잡성을 과소평가하면 안됩니다.

**Dirk Slama**: 당신은 어떻게 게이트웨이를 선택합니까?

**Roman Wambacher**: 글쎄, 주문제작 게이트웨이 개발의 비용 때문에 기성품 게이트웨이를 사용하는 것은 항상 매력적으로 들립니다. 많은 경우에, 하지만, 그것은 피하기 어렵습니다. 일반적인 게이트웨이는 종종 너무 기능이 다양하고 그런 이유로 너무 비쌉니다. 혹은 다른 경우 특정 당신이 프로젝트에서 필요로 하는 중요한 인터페이스가 빠져있을 수 있습니다. 당신이 10,000개나 더 많은 게이트웨이를 필요로 한다면, 주문제작 솔루션을 택하는 결과가 될 가능성이 충분합니다.

**Dirk Slama**: 세계적 롤아웃에 어떤 것을 고려합니까?

**Roman Wambacher**: 글쎄, 이상적으로는 복잡성과 TCO를 줄이기 위해 단일 종류의 게이트웨이를 모든 나라에 원할 것입니다. 하지만, 많은 사례에서 여러 이유로 이는 가능하지 않습니다. 특히, LTE의 다양한 주파수라던가, CDMA 대 GSM 같은 국가 전용 기술 요구사항이 있습니다. 다양한 옵션을 지원하는 모뎀도 존재하지만, 이는 비용 면을 늘릴 것입니다. 당신은 다양한 게이트웨이 종류를 지원하여 발생할 수 있는 추가 비용을 과소평가하지 말아야 합니다. 그저 각 게이트웨이 종류와 각 새 버전에서 통과해야 할 정부 승인 과정을 생각해야 합니다!

**Dirk Slama**: 이 종류의 프로젝트에 포함되는 다른 비용 동인은 무엇입니까?

**Roman Wambacher**: 많은 사람들이 주요 비용 동인이 모바일 데이터 교환을 위한 통신 비용이라고 생각합니다. 하지만, 최소한 우리 경험상으로는 이는 보통 문제가 아닙니다. 더 큰 문제는 수동이고 비효율적인 SIM 카드 활성화/비활성화나 자산 설정 같은 게이트웨이 및 관련 문제 관리 과정에서 옵니다. 자산 설정은 특히 자동화될 수 없는 것이지만 이것은 개발 비용에 추가될 수 있습니다– 심지어 TCO 관점을 통하더라도 매우 타당합니다.

다른 비용 동인은 특성 크립입니다. 많은 자산에서, 게이트웨이의 라이프사이클은 자산 자체보다 훨씬 짧을 것입니다. 그러므로 게이트웨이의 최소한의 특성의 집중하고 차세대 게이트웨이가 어느 미래에 개발되리라고 믿어도 상관없습니다.

마지막으로 많은 회사들이 첫 출시 후 추가 개발 예산을 계획하지 않습니다. 하지만 우리 경험상, M2M/IoT 프로젝트 대부분은 끝나지 않는 이야기입니다. 그리고 이것은 긍정적인 것으로 받아들여질 수 있습니다. 만약 프로젝트가 성공적이라면, 새로운 부가가치 특성에 대한 지속적인 수요가 있을 것입니다.

==== 2. M2M/IoT 통신 서비스 ====

Enterprise IoT 프로젝트 관리자는 많은 불확실성에 직면할 것이고 어떤 두 Enterprise IoT 솔루션도 같거나 심지어는 비슷할 수도 없다. 하지만, 우리의 커넥티드 미래의 분석에 근본적인 한 개념이 있으니 바로 연결성의 필요이다. 동시에, 모든 Enterprise IoT 프로젝트 관리자는 어떻게 원격 자산이 더 넓은 기업 백엔드에 연결될 수 있을지에 대해 고려할 필요가 있을 것이다. 어떤 사례들에서, 적절한 통신 연결은 이미 제자리에 되어있을 것이나, 더 종종, Enterprise IoT 관리자들은 새로운 옵션을 생각할 필요가 있을 것이다.

이 부분에서 우리는 연결성을 원격 자산에 제공하여 이들 자산이 Enterprise IoT 솔루션에 통합될 수 있도록 하는 대안적인 접근법을 고려할 것이다. 근본적으로, 고려되어야 할 두 종류의 연결성이 있다: 관리되는 연결성과 관리되지 않는 연결성이다. 우리는 이 부분의 대부분을 연결성 관리에 바쳤다. 즉, 연결성은 서비스를 서드 파티로서 제공한다. Enterprise IoT 프로젝트 관리자는 물론 아날로그 기술을 배치하고 자신의 네트워크를 운용할 수도 있지만, 기술 부분과 관리 고려는 유사하다.

==== 서비스 개관 ====

우리는 여섯 개의 주요 M2M/IoT 통신 서비스를 정의했다:

•	휴대전화 Cellular (2G, 3G, 4G)\\ 
•	저전력 광범위Low Power Wide Area (LPWA)\\ 
•	도시 지역 네트워크Metropolitan Area Networks (MANs)\\ 
•	위성Satellite\\ 
•	고정선Fixed Line\\ 
•	전선 통신Power Line Communications\\ 
이들 기술은 연결성의 범위, 모바일 자산 지원 능력, 지원되는 데이터 처리량 수준 면에서 크게 다르다. 우리는 주요 고려사항을 아래 도표에 요약했다.

{{ :파트2_50번그림.png?nolink&300 |}}
              Key technical considerations of Managed Communications Services

이 모든 연결성 옵션에서, 아마도 가장 흥미로운 것은 무선 기술일 것이다. 일반적으로, 무선 기술은 상대적으로 동질의 연결성 환경을 지원(그리하여 모든 특정 종류의 원격 자산이 같은 기술 솔루션을 사용하여 연결될 수 있다)할 잠재력을 가지고 있다. 결국, 이는 상대적으로 중앙 위치에서 원격 기기로의 단순한 감시와 결함 해결을 허용한다.

근본적으로, 무선 통신 기술은 항상 데이터 처리 속도, 배터리 수명, 원격 기기 비용, 네트워크 비용, 물리 법칙 같은 상대적으로 제한된 제약들간의 타협이다. 다양한 무선 기술간의 주 차이점은 다른 방식으로 “최적화”되어왔다는 것이며 이들이 우리가 아래 탄환에서 논하고자 하는 차이점들이다:

•	휴대전화Cellular (2G, 3G, 4G, 5G): “모바일”은 현재 IoT를 광역 연결성 면에서 지배하는 기술이다. 현실적으로, 그것은 본질적으로 모바일 어플리케이션(차량 플랫폼과 eCall같은)의 영역을 지원할 수 있는 유일한 기술이다. 이 기술 그룹은 또한 매우 넓은 지리적 범위와 자연적 경계에 걸친 합리적인 수준의 동일성(잠재적으로 커넥티드 기기의 국제 “로밍”을 가능하게 하는)에 혜택을 준다. 데이터 처리 속도는 합리적이고 reasonable (240 kbit/s for 2G, 42Mbit/s for 3G, 326Mbit/s for 4G, and faster for 5G), 이 기술 그룹은 M2M/IoT 공간에 잘 자리잡고 있다. 그 중요성으로 인해, 우리는 이 챕터의 많은 남은 부분을 휴대전화 M2M 통신을 상세하게 논하는데 할당할 것이다.\\ 
•	저전력 광범위Low Power Wide Area (LPWA): 많은 방법에서, LPWA 네트워크는 모바일 네트워크와 매우 유사하지만, 매우 낮은 가격 포인트와 잠재적으로 더 긴 배터리 수명의 대가인 크게 타협된 데이터 처리 능력도 있다. 이들 기술 종류의 존재이유는 IoT에 연결될 압도적 다수의 자산들이 매우 적은 데이터를 드물게 만들어낸다는 사실에 있다. 배터리 수명은 단일 AA 셀을 동력으로 사용하여 10년을 넘게 연장될 수 있다. 그런 성능 봉투는 스마트 먼지의 일종으로 분산되어 사건을 10년까지 감시할 수 있는 산업 위치의 주위 보안 센서 같은 많은 가능성으로 통하는 문을 연다. LPWA는 현재 발생기 기술이지만 그런 기술들의 널리 퍼진 배치는 다가오는 미래에 기대될 수 있으며 또한 LPWA 종류 능력이 3GPP(휴대전화) 표준에 수년 안에 편입될 수도 있다.\\ 
•	도시 지역 네트워크Metropolitan Area Networks (MANs): 이 범주는 도시 환경에 배치될 수 있는 무선 기술의 범위를 포함한다. 일반적으로 배치는 한 광역 도시권에서 동질적이며 상대적으로 유비쿼터스이지만, 일반적으로 다양한 광역 도시권 사이에서 다양하다. 이는 스마트 도시 솔루션(통제되는 가로등, 교통 신호, 수집 거부)에 MAN 종류 솔루션을 특히 적합하게 만들지만, 단일(혹은 제한된 수의) 광역 도시권(들)의 한계를 넘어서면 덜 적합한 솔루션이다. 무선 MAN 기술은 LPWA와 동등한 기술에서 와이파이와 동등한 기술의 범위까지 기술 능력의 면에서 매우 상당히 다양하다.\\ 
•	위성Satellite: 위성은 모든 무선 연결성 솔루션 중에서 가장 유연하지만, 가장 비싸다. 그것이 위성 연결로 움직이는 “커넥티드” 자산에 다양한 MB 흐름을 지원할 수 있음에도, 그 비용은 대부분의 잠재적인 IoT 어플리케이션이 엄두를 못 낼 정도이다. 다른 최종 규모로, 현재 개발중인 잠재적으로 현재 2G(휴대전화) 모뎀 능력과 기준 소매가격에 맞는 위성 솔루션이 있다. 일반적인 규칙상, 위성은 “유일한 옵션”일 때나 IoT 기기를 연결하는 “최고의 옵션”이다. 사용 사례는 공해상의 냉동선 컨테이너(“냉장선”) 감시를 포함한다. 컨테이너 선이 지역 내장 연결성(2G 휴대전화)를 배치했을 것 같음에도, 그리하여 위성 통신의 비용은 여러 컨테이너들 간에 공유될 수 있다.\\ 

앞에서 언급했듯이, 고정된 연결성 옵션은 보통 훨씬 덜 흥미롭다. 우리는 고정 선과 전선 솔루션을 아래 문단에서 논한다.

•	고정선 Fixed Line: 만약 가능하다면, 고정선 솔루션은 원격 자산에 연결하는데 매우 좋은 옵션이 될 수 있다. 하지만 고정선 연결이 가능하지 않다면, 그 연결을 특히 IoT 자산에 배치하는 비용은 엄두를 낼 수 없을 정도이다. 고정선 인프라를 사용하여 자산이 연결된 사례에서, 원격 자산에의 실제 최종 연결은 Ethernet 연결이 되곤 하며, 그러므로 잠재적으로 극도로 높은 연결성 속도가 지원될 수 있다.\\ 
•	전선 Power Line: 이것은 일반적으로 전기 스마트 측정에만 적합한 매우 편한 통신 솔루션이다. 기술은 “신호”를 사실 전선 케이블인 “매개체”로 복합하여 작동한다. 이것은 솔루션을 배치하는 전기 유틸리티가 일반적으로 건물 전력 공급 장치의 두 “끝”(즉, 스마트 측정과 일치하는 전기 분배 서브스테이션)에 접속하기 때문에 전기 측정에는 잘 작동하지만, 전선의 다른 얼마 없는 전선의 잠재적 사용자들은 그런 접속을 즐긴다.\\ 

주요 휴대전화(2G, 3G, 4G) 기술에 다시 한번 집중하면, 근본적인 시장 구조 고려를 강조할 가치가 있다. 설립된 모바일 통신 시장은 고도로 진화되었으며, 많은 다양한 시장 위치를 가진 참가자를 포함한다. 두 주요 위치는 모바일 네트워크 오퍼레이터(MNO)와 모바일 가상 네트워크 오퍼레이터(MVNO)이다. (인간) 고객 관점에서, 이들 독립체들은 그들이 목소리와 데이터를 포함하는 모바일 통신 서비스를 제공할 수 있다는 점에서 매우 유사하다. 전통적인 통신 시장에서, 브랜드 고려(그리고 아마 MVNO의 편한 시장 위치) 외에는 MNO와 MVNO가 제공하는 제품과 서비스를 차별화할 여지는 거의 없었다. 하지만 기술 관점에서는, 다 MNO가 자체 라디오 접속 네트워크를 소유하고 운용하고 MVNO는 MNO가 소유한 RAN에 편승한다는 점에서 MNO와 MVNO는 상당히 다르다. 두 사례에서, 실제로 라디오 접속 네트워크를 제공하고 통화와 데이터를 나르는 것은 MNO임에도, MVNO의 경우 실제로 고객과 마주하는 독립체는 MNO외의 무엇이었다. 필수적으로, MVNO는 마케팅, 고객 획득, MNO가 제공하는 연결성의 청구와 도매에 집중했다. “가벼움”(이들 MVNO는 마케팅, 고객 획득, 청구 외에는 하는 것이 없다)에서 “무거움”(이들 MVNO는 또한 자체의 핵심 네트워크 요소를 만들고 소유한다)에 이르는 MVNO의 다른 “특색”도 있다.

이 시장 구조는 MNO와 MVNO가 연결 기계를 제공함으로써 M2M 세계에 이전되었다. M2M 공간에서의 주요 구별점은 운용하는 각 영역에서 한 MNO이상 MNO MVNO가 도매 관계를 설립할 수 있다는 것이다. 이 잠재적인 일대다 관계에는 두 주요 결과가 있다. 첫째는 MVNO가 잠재적으로 최고의 신호 강도를 특정 위치에서 제공하는 MNO를 선택하여 관리할 수 있는 각 연결을 위해 다른 MNO 회사를 어느 정도 선택할 수 있다는 것이다. 둘째 결과는 MVNO 제공 M2M 연결이 잠재적으로 더 나은 속도를 제공하는 MNO 네트워크로의 이행 면에서 좀 더 자유로울 수 있다는 것이다. 사실, 첨단 기술의 MVNO는 이제 전반적인 솔루션이 가상 공유 RAN으로 대부분 특징지어질 수 있는 다양한 파트너 MNO 네트워크와의 단일 연결의 연관성 면에서 유연성 수준을 제공한다. 하지만, 그 유연성에 지불되는 가격은 비용과 파트너 MNO인터페이스의 유연성과 동일성에 내포되어 있다. 어떤 M2M 어플리케이션에서, 이는 가치 있는 균형이 될 것이다. 다른 것들에서는 아닐 것이다.
                  
==== 모바일 M2M 통신 ====

다양한 M2M/IoT 통신 서비스에 대해 논했으니, 우리는 이제 더 자세하게 모바일 M2M 통신에 대해 볼 것이다. 이것이 원격 기기에서 오늘날 가장 널리 사용되는 복잡한 기술이며 앞으로 보게 될 미래에도 그러할 것이기 때문이다.

우리는 모바일 M2M 통신의 몇몇 기본적인 개념을 소개하면서 시작할 것이다. 우리는 그리고 많은 과제를 다룰 수 있는 M2M 통신 플랫폼의 사례를 가지고 공통 과제에 대해 논할 것이다.
이 부분의 나머지에서, 우리는 M2M을 모바일 M2M 통신을 가리키는 용어로 쓸 것이다. 서론의 M2M 대 IoT에 대한 논의도 보라.

**기본 요소**

모바일 M2M에서, 가장 중요한 요소 중 몇은 M2M SIM 카드, 이들 SIM 카드를 사용하는 통신 모듈, 통신 모듈을 사용하는 M2M 기기이다:

•	M2M SIM 카드: 구독자 확인 모듈, 혹은 SIM 카드는 어떤 모바일 기기가 네트워크에 접촉하고 서비스에 접속할 수 있는지를 구독을 통해 확인한다. SIM 카드는 표준 플라스틱 UICC 미니(2FF), 마이크로(3FF), 그리고 이제는 스마트폰 사용자에게 친숙한 나노(4FF) SIM, 회로판에 땜납 가능한 전기 부품인 더 전문화된 SON-8-chip 형성 요소를 포함하는 다양한 물리적 형태로 이용 가능하다. M2M 사용을 위한 SIM 종류 선택은 특정 어플리케이션에 의존한다. 주요 고려사항은 평생 필요와 SIM이 작동시켜야 하는 환경을 포함한다. 많은 M2M 어플리케이션의 서비스 생명은 정해진 표준 SIM 카드의 수명을 초과한다. M2M 시장을 위한 기복이 심한 SIM은 유용한 삶을 연장시키기 위해 더 많은 읽고 쓰는 사이클과 더 긴 데이터 보유를 지원한다. 이에 더해, SON-8 형성 요소는 일반적으로 온도와 진동에 대한 더 큰 탄성을 제공한다.\\ 
•	M2M 통신 모듈: 통신 모듈은 필수적으로 모바일폰이다. M2M의 초기에, 실제 전화가 사용되었다. 오늘날, 그것은 모바일 네트워크와 SIM이 제공하는 구독을 사용해 통신하는데 필요한 모든 조각을 담고 있는 작은 회로판이다. 사실상, 그것은 M2M 기기에 통합되어 완전한 통신 서비스를 제공하도록 디자인된 전문 모뎀이다. 통신 모듈은 지역 표준, 라디오 주파수, 지원될 모바일 기술의 세대를 고려하여 M2M 서비스들이 사용할 모바일 네트워크 종류들과 호환 가능해야 한다. 이것은 모듈의 가격, 네트워크 범위, 서비스 장수에 영향을 미치는 중요한 결정이다.\\ 
•	M2M 기기:  M2M 기기는 실제 세계에서 데이터를 처리하고 통신 모듈이 제공하는 서비스를 통해 백엔드 어플리케이션과 교환한다. M2M 기기들은 일반적으로 자동화 산업에서 장치나 통신 유닛에 사용되는 스마트 미터 같은 개별 어플리케이션 종류에 전문화 되어있다. 어떤 사례들에서, M2M 기기는 측정과 통제를 수행할 센서와 반응기를 담고 있으며 다른 것들에서는 그들과 지역 연결과 자동차를 위해 개발된 Controller Area Network (CAN)같은 전문 통신 프로토콜을 통해 통신한다.\\ 
M2M 통신 네트워크는 M2M 기기와 백엔드 간의 통신을 가능하게 한다. 중요한 요소들은 Radio Access Network (RAN), Mobile Core Network, Access Point Name (APN), Backhaul Connectivity를 포함한다:
•	라디오 접속 네트워크Radio Access Network: 라디오 접속 네트워크는 M2M 기기가 서비스를 얻기 위해 접촉하는 지역 모바일 네트워크가 소유한 기본 방송국들로 구성된다. 그 목적은 라디오 연결을 기기에 제공하고 트래픽을 M2M 서비스 통신 제공자에 속한 모바일 핵심 네트워크에 되돌리는 것이다. GeRAN (2G), UTRAN (3G), E-UTRA (4G)같은 몇몇 라디오 접속 네트워크의 세대가 흔히 사용된다.\\ 
•	모바일 핵심 네트워크Mobile Core Network: 핵심 네트워크는 M2M 통신 서비스 제공자(CSP)의 “가정” 네트워크에 있으며 고객의 백엔드 시스템과 기기들이 접촉하는 지역 모바일 라디오 접속 네트워크간의 허브로 작용한다. 핵심 네트워크는 트래픽을 강화하고 CSP가 청구를 수행하게 하는 사용기록을 만들어낸다. 그것은 또한 모바일 구독이 등록되는 위치이기도 하다. 그것은 개별 기기들이 목소리나 데이터 같은 특정한 서비스에 접속하도록 허용하며 또한 기기들이 접촉할 수 있는 라디오 네트워크를 통제한다. 기기가 라디오 접속 네트워크에 접속하려 시도할 때, RAN은 기기의 가정 모바일 핵심 네트워크에 기기 확인과 서비스가 접속이 허용되었는지를 체크하기 위해 접촉한다.\\ 
•	접속 지점 이름Access Point Name (APN):  APN은 M2M 기기가 모바일 데이터 연결을 수립했을 때 합류하는 가상 데이터 네트워크로 여겨질 수 있다. APN의 중요한 측면은 IP 주소 제도, 증명 구조, APN이 공공의 것이냐 사적인 것이냐를 포함한다. APN은 모바일 핵심 네트워크에 의해 관리되며 아마도 특정한 백홀 연결에 관련된다. 인터넷 APN 같은 공유된 APN은 많은 다양한 M2M 사업에 속하며 일반적으로 제한된 기능과 보안의 대가로 빠른 접속과 최소한의 구조를 제공하는 기기들에 의해 사용된다. 개인 APN은 개별 서비스에 목적 지향적이고 개인 IP 주소, 더 나은 보안, 다른 트래픽에서의 분리 같은 추가 기능을 제공한다.\\ 
•	백홀: 백홀 연결성은 트래픽을 모바일 핵심 네트워크와 백엔드 시스템 간에 이동시킨다. 기술적으로 모바일 핵심 네트워크의 일부가 아니라 그런 연결성이 보통 CSP에 의해 완전한 양단간 솔루션의 한 요소로서 제공된다. 여러 종류의 백홀이 개인 임차 라인에서 인터넷 의 터널 보안에까지 흔히 사용된다.
만약 SIM이 RAN과 다양한 모바일 네트워크 회사가 제공하는 핵심 네트워크를 로밍한다면, RAN은 “서빙 네트워크”의 일부일 것이고 핵심은 “가정 네트워크”의 일부일 것이다.

**과제들**

“M2M 통신은 매우 다양한 전통적인 모바일 통신의 특징들을 가지고 있다. M2M 사업과 통신 서비스 제공자들은 모두 새로운 상업 모델, 세계 서비스 관리, SIM 계획, 대규모 시스템 운용, 다양한 패턴의 트래픽 관리 같은 문제들을 다루어야 한다. M2M은 IT와 전통적인 모바일 통신 둘 다와 거리가 있으며 그 자체의 전문 방법론과 솔루션을 요구한다.” – Mike Prince, Principal Product Manager for M2M Platforms, Vodafone.

M2M 초기에, 많은 MNO가 M2M 연결이 단순한 데이터 연결일 것이고, “표준” 데이터 SIM과 계약으로 간주된 문제들 외에는 이 새로운 시장에 제공하기 위해 할 일이 거의 없다고 추정했다. Mike의 인용이 강조하듯이, M2M 시장의 현실은 더 복잡하다는 것이 증명되었다. M2M 연결과 인간 중심 목소리 및 데이터 연결간의 더 즉각적이고 큰 차이점이 아래에 나열되어 있다:

•	상업: 긴 기기 휴지 기간, 독특한 트래픽 패턴, 많은 M2M 사업의 매우 적은 수익으로 보아, 표준 모바일 관세가 M2M에 부적합함은 명백하다. 기기가 각국에 분배되는 곳인 국제 서비스는 다양하고, 로밍 비용에 특정 불확실성을 도입한다.\\ 
•	SIM 계획: SIM은 흔히 M2M 기기에 기기 자체의 생산 도중 투입되며, 더 익숙한 플라스틱 부품 보다는 종종 칩 기반 형성 요소를 사용한다. 첫 테스트 후, SIM은 기기가 공급 체인을 통해 운반되고 최종적으로 활성화되기까지의 연장된 기간 동안 휴면기에 들어간다. 특정 종류의 M2M 기기는 나중에 사용자 간에 재활용될 수도 있으며 이는 추가 휴지기로 이어진다. 이는 희소자원의 사용 대가를 조심스럽게 관리하고 최적화시켜야 하는 모바일 회사들에 어려움을 만들어낸다. 이 방법으로 표준 SIM을 사용하려고 시도하는 M2M 사업은 그들의 구독을 유지하기 위한 큰 복잡성과 비용에 직면한다.\\ 
•	규모: 어떤 M2M 사업은 기기들을 대량으로 배치하며 그러지 않았다면 그것들은 전례 없는 수백만의 기기에 가동되는 단일 서비스였을 것이다. 큰 규모의 M2M은 높은 수준의 자동화를 요구한다 Large-scale M2M requires a high degree of automation.\\ 
•	운용: 작동하지 않을 때 소유주가 가게에 다시 가지고 가거나 서비스 데스크에 전화할 수 있는 스마트폰과는 달리, 기계들은 독립적으로 작동해야 한다. 설치와 활성화는 고도로 자동화되어야 하며 모든 차후 고장발견은 현장 방문 비용을 최소화하기 위해 원격으로 이루어져야 한다.\\ 
•	트래픽 패턴: 기계들은 사람과 달리 다른 지역에서 하루의 다른 시간대에 작동한다. 그들은 고정되거나 혹은 고도로 모바일 일 수 있다. 각 기계 “대화”는 작은 양의 데이터를 포함할 수도 있지만 일이 잘못될 때 그들은 계속 시도할 것이다. 그 결과, 네트워크상의 M2M 트래픽은 다른 종류의 모바일 기기에 의해 생성된 매우 다양한 패턴을 따른다. 밀접한 관리가 네트워크가 과도한 트래픽 양에 도달하고 고객들이 비싼 청구서와 기기 불량에 직면하지 않도록 보장하기 위해 필요하다.\\ 
•	기기 유래 통신Device-Originated Communication: 모바일 데이터 통신의 연결은 네트워크보다는 기기에 의해 이루어진다. 이것은 고객 모바일 수요에 봉사하지만 M2M에서는 이는 백엔드 시스템이 데이터를 그들과 교환할 수 있기 전에 연결을 시작하는 것을 기기에 의존한다는 것을 의미한다.\\ 
•	보안: 기업들은 M2M을 중요한 사업 절차를 지원하기 위해 사용한다. M2M 어플리케이션들은 민감한 데이터나 통제 중요 인프라를 자주 다룬다. M2M 통신이 적절한 수준의 보안을 가지는 것은 필수적이며 위협 수준은 서비스가 살아있는 동안 증가하며 M2M이 수행하는 역할의 의식이 공격자들을 더 똑똑하게 만든다는 것을 명심하라.\\ 

이들 항목들을 넘어, 잠재적으로 M2M 솔루션의 세계적(혹은 다국적) 본성이 관세, 서비스 관리, “고객” 지원에서 큰 복잡성을 추진할 수 있다. Mike가 강조하듯, “전통적인 모바일 서비스가 강하게 개인의 본국과 관련되는 반면, M2M 서비스는 여러 지역, 심지어는 전세계에 걸쳐 작동할 것이 요구된다. SIM이 기기에 설치된 때에 그 운명은 종종 알 수 없다.”

**SIM 라이프사이클**

SIM은 M2M에서 이러한 중심적인 역할을 하기 때문에, M2M SIM 라이프사이클을 이해하는 것은 위에 설명된 문제 중 일부를 해결하는데 많은 도움이 될 것이다.

M2M SIM의 라이프사이클은 기존의 모바일 서비스에 사용되는 것과 매우 다르다. 기본 활성화 및 비활성화를 연관시키는 표준 상태 이외에도, 많은 다른 상태가 SIM의 라이프 활성 단계에서 더 세분화된 통제를 제공하기 위해 필요하다. 이러한 상태는 M2M 장치의 구축, 검사, 배송 및 사용 과정 동안 연결에 대한 제어를 자동화 하도록 돕는다. SIM 상태에 따라 요금을 다양하게 함으로써, 고객의 상황에 맞게 광고를 할 수 있다. 예를 들어, 정해진 사용량 또는 시간이 테스트를 위해 제공될 수 있다. 

{{ :파트2_51번그림.png?nolink&300 |}}
                           M2M SIM lifecycle (Source: Vodafone)
                           
**M2M 연결 관리 플랫폼**
 
위에 설명된 M2M 문제를 해결하기 위해, 사업자는 M2M 연결 관리 플랫폼을 효율적으로 사용해야 한다. 이러한 플랫폼은 일반적으로 클라우드 서비스로 제공되는 확장성이 뛰어난 다중 임대 시스템이다. 이들은 높은 수준의 셀프 서비스를 가능하게 하고 대용량 SIM와 장치를 제외한 관리에 최적화된다.

연결 관리 플랫폼은 M2M을 채택하는 기업의 위험을 감소 시키는데 중요한 역할을 한다. 아래 그림은 기본 M2M 요소와 연결 관리 플랫폼의 상호 작용에 대한 개요를 제공한다.
                           
{{ :파트2_52번그림.png?nolink&300 |}}
                   Overview of key M2M elements and M2M platform  

M2M 연결 관리 플랫폼은 다음과 같은 주요 특징을 포함한다.  

•	온라인 그래픽 사용자 인터페이스: 사용자가 그들의 서비스를 운영하고 관리할 수 있게 한다. 분명한 역할 및 권한 설명은 사용자에게 불필요한 복잡성을 피하면서 자신들의 작업을 수행하도록 필요한 기능에 대한 접근을 제공한다.\\ 
•	API: M2M 통신에 의존하는 끝에서 끝까지의 비지니스 프로세스를 지원하기 위해 고객 시스템의 통합을 허용한다.\\ 
•	주문 및 권한 설정: SIM 대량 주문의 효율적인 생성 및 시스템 구독의 대량 권한 설정\\ 
•	장치 시동: 장치와 통신하는 데 필요한 백엔드 시스템에 의해 적용될 수 있는 SMS트리거. 장치의 트리거로의 응답은 데이터 접속을 개시하는 것이어야 한다.\\ 
•	보안: 부정 사용에 대한 네트워크 리소스에 대한 접근을 제한하고 보호하는 조치. 지정된 M2M 네트워크 플랫폼과의 심층적인 통합은 철저한 보안을 제공해야 한다.\\ 
•	세션 관리: 접근 제어, 주소 할당 및 사용 할당량을 포함하는 데이터 세션에 대한 상세한 실시간 제어\\ 
•	분석 및 보고: 서비스 특성에 대한 그림을 그려보거나 특정 데이터 세트를 생성하기 위한 하나 이상의 장치에 관한 기록의 광범위한 검사\\ 
•	진단: 오류의 원인을 식별하기 위한 특정 장치의 동작에 대한 상세한 드릴다운. 실제 데이터 및 이력 기록 (예: 음성, 데이터, SMS 통신을 위한 프로토콜 추적) 또는 사전 테스트 결과를 조사할 수 있다. \\ 
•	알림: 고객 또는 서비스 제공 기관의 다른 사용자들에게 중요한 사건을 적극적으로 알림. 예를 들어, 사용 경고.\\ 
•	비지니스 규칙: 프로세스를 자동화하고 예외를 처리하는 데 사용할 수 있는 방법, 규칙 및 행동의 변경 가능한 툴키트.\\ 
•	감사 추적: 전체 감사 추적을 제공하기 위해 사건 및 변경의 이력 기록\\ 
•	평가 및 결제: 필요에 따라 서비스에 적용할 수 있으며, 전체 플랫폼 기능 집합을 설명하는 M2M 특화 요금\\  
•	수익 보증: 결제 확인을 허용하는 상세한 사용 기록\\  
•	온라인 지원: 발권, 문서, 도움말 및 사용자 포럼\\ 

다음 그림은 Vodafone이 M2M 연결을 관리하기 위해 고객에게 제공하는 포털 대시 보드의 스크린 샷이다. 

{{ :파트2_53번그림.png?nolink&300 |}}
                           Screenshot M2M Portal (Source: Vodafone)
                           
**MCS와 Ignite 자산 통합 아키텍쳐**

다음 그림은 MCS의 AIA를 설명한다. 

{{ :파트2_54번그림.png?nolink&300 |}}
                                           AIA for MCS

**권고 및 견해** 

지금까지의 논의를 기반으로, 이 부분은 M2M/IoT 통신 서비스의 미래 발전 궤도에 초점을 맞춘다. 우리는 시작하고 지금까지 (M2M) 플랫폼의 역할을 요약했다. 그 다음, 우리는 (IoT) 연결 플랫폼에 대한 “모범 사례"를 정의하고 IoT 연결 공간에 새로운 신흥 기술에 대해 설명한다. 우리는 연결 플랫폼 서비스 제공자의 권고로 끝을 맺을 것이다. 

**현재 (M2M) 플랫폼의 역할**

//"M2M 및 IoT 플랫폼의 주요 역할은 오늘날의 IoT 시장에 존재하는 마찰 수준을 감소시키는 것이다. 이 마찰은 높은 진입 비용, 특정 부분 표준화의 부족, 제한된 기술과 인식, 국가 및 지역간의 차이와 변화하는 시장 상황을 포함하는 광범위한 요인에 의해 생성된다. 결과적으로, CM 플랫폼은 M2M을 채택 기업에 대한 위험을 감소시키는데 중요한 역할을 담당한다”//고 Vodafone M2M Platforms의 Principal Product Manager인 Mike Prince는 말한다. 

지금까지 오로지 휴대 전화 기반 기술에만 초점을 맞춰온 연결 지원 플랫폼은 많은 M2M 및 IoT 솔루션의 성장에 상당한 기여를 하고 있다. 이는 특히 다른 유형의 연결이 휴대 전화로 연결된 솔루션 라이프사이클의 상이한 단계에서 필요로 되는 경우이다. 예를 들어 휴대 전화 연결의 중요한 시장인 자동차 산업에서, SIM 연결을 활성화하고 비활성화 할 수 있는 기능은 다양한 생산, 검사 및 출시 단계의 결과로 필요하게 된다. 

산업 버티컬의 M2M 요건을 해결하는데 있어서, M2M 솔루션의 설계, 개발 및 구축은 복잡한 IT 솔루션과 비교될 수 있다. 연결 지원 플랫폼의 사용은 기업이 연결 관리를 표준화하고, 솔루션 내에서의 기능을 확장할 수 있도록 한다. 현재의 제한 사항은 매우 적은 연결 지원 플랫폼만이 다른 연결 기술에 대해 유연 또는 적응할 수 있도록 설계되어 있다는 점이다. 어플리케이션이 개발된 후에는, 장치를 변경하거나 연결 기술을 추가하거나 새로운 데이터 모델과 새로운 어플리케이션 요건을 채택하고 통합하기 위해 상당한 시간, 노력 및 비용을 필요로 한다. 이는 일반적으로 연결 지원 플랫폼 기능의 제한된 재사용 또는 통합으로 특별히 설계된 여러 솔루션으로 이어진다. 

M2M 어플리케이션이 더욱 발전되고 복잡해지면서, IoT의 출현과 함께, 연결 플랫폼은 진화해야 할 것이다. 이전 연결 지원 플랫폼이 장치의 좁은 집합과 주로 휴대 전화 연결 옵션에의 접속을 허가 한 경우, 미래의 요건은 민첩성과 유연성의 증가로 특징지어질 수 있다.

우리는 이미 추상화가 M2M/IoT 어플리케이션 플랫폼의 새로운 다양성에서 선호되는 접근법이 된 것처럼 어플리케이션 개발에서도 유사한 경향을 보았다. 우리는 계속 증가하는 기술 불가지론으로 특징지어지는 연결 지원 플랫폼 공간에서 비슷한 발전을 기대한다. 이 추상화와 불가지론의 결합은 규모와 이질성 (장치 및 프로토콜의)이 더 적은 수의 플랫폼을 통해 관리될 수 있도록 한다. 또한 이는 개발자가 특정 통신 기술 또는 장치의 특성보다는 어플리케이션 개발에 더 집중할 수 있게 한다.

그러나 "기술 불가지론" 연결 지원 플랫폼의 간단한 아이디어는 여러 연결 옵션의 특성 관리에 관련된 복잡하고 어려운 작업이 허위임을 보여준다. 예를 들어, 컨테이너화물 추적을 위한 M2M 솔루션은 위성, 휴대 전화 및 단거리 연결 장치의 일부 조합을 필요로 할 수 있다. 단일 플랫폼 솔루션으로 상이한 연결 기술을 지원하는 기능은 기업 및 통신 사업자, 시스템 통합자, 그리고 M2M/IoT 어플리케이션 플랫폼 제공 업체에게 중요한 혜택 및 차별화 요인이 될 수 있다.

다른 연결 기술을 관리하는 것은 복잡한 작업이다. 다중 기술 연결 플랫폼의 제공자는 다중 결제와 실시간 데이터 및 조정 기능을 관리하고, 통신 기술의 범위에서 안전하고 회복력 있는 통신을 보장하는 상이한 프로토콜들에 걸친 작동의 어려움에 직면해있다. 각 연결 기술은 "제대로 작동"할 때마다 다르게 반응할 것이며, 오류 상태가 발생하면 다른 조치를 필요로 할 수 있다. 따라서, 다중 연결 기술을 끌어들여 잘 정의되고 관리된 연결 솔루션을 제공하는 능력은 상당히 경쟁력있는 차별화 요소가 될 수 있다. 기업의 경우, 이러한 솔루션은 새로운 연결 옵션을 통합하는 많은 어려움을 제거하며, 새로운 요금 및 결제 옵션의 문을 연다. 
                                           
**(IoT) 연결 플랫폼에 대한 “모범 사례” 정의**
 
12개 기술 및 상업 기능과 특징은 도시한 바와 같이 연결 지원 플랫폼에 대한 "모범 사례" 요소를 정의한다. 이러한 기능과 특징을 제공하는 것은 궁극적으로 연결된 장치들의 상당한 발전을 가능하게 하고, 향상된 ROI를 제공하여 시장에서의 마찰을 줄일 수 있을 것이다. 또한 이는 결과적으로 새로운 시장과 어플리케이션 개발 기회를 열 것이다. 이 공간에서, 기술 및 상업 기능과 특징은 밀접하게 관련되어 있으며, 지금은 하나의 포괄적인 연결 제안을 달성하는 쪽으로 수렴하고 있다. 

그러나, 나열된 "모범 사례"의 기능과 특징이 일반적으로 언급되는 휴대 전화 연결 지원 플랫폼의 기능 및 특징과 동일하지 않다는 것은 분명하다. 이러한 기능은 일반적으로 연결 권한 설정, 사용 모니터링, 네트워크 오류 해결을 위한 일정 수준의 지원을 포함한다. 대조적으로, 여기에 나열된 모범 사례는 일반적으로 높은 수준의 상용 어플리케이션 개발, 어플리케이션 관리, 이행 고려 사항을 다룬다. 궁극적으로, 연결 지원 플랫폼에 대한 모범 사례의 추구는 실제 다중 기술 연결을 제공하는 "연결 플랫폼"으로 재배치되는 결과를 낳을 것이다.   
                                           
{{ :파트2_55번그림.png?nolink&300 |}}  
         “Best Practice” elements of connectivity platforms (Source: Machina Research 2014)        

우리는 다음 표에서 이러한 "모범 사례"에 대해 더 자세히 설명한다. 첫 번째 표는 상업 모범 사례를 자세히 설명하고 있으며, 두 번째 표는 기술 모범 사례로 확장된다. 

{{ :파트2_56번그림.png?nolink&300 |}}
          Six commercial best practices for connectivity platforms (Source: Machina Research)    
          
{{ :파트2_57번그림.png?nolink&300 |}}        
              Six technical best practices for connectivity platforms (Source: Machina Research)      
              
**전망**
 
연결 공간에 대한 전망은 역동적이고 다양하다. 기존 기술의 향상과 진화, 새로운 기술의 도입과 주변 기술의 블러링을 포함하는 광범위한 발전이 예상된다. 우리는 다음 단락에서 시장의 이러한 경향에 대해 간단히 설명할 것이다.

기존 기술에서 가장 이목을 끄는 변화는 소프트 SIM의 도입이다. 특히, 이 발전은 "내장형", "구성 요소" 또는 “M2M-Form Factor” (MFF) SIM을 향한 물리적으로 제거 가능한 SIM카드의 진화를 나타낸다. 그리고 이는 더 견고하고 열이나 진동에 덜 민감하며, 특히 다른 장치에서 제거되거나 사용될 수 없기 때문에 보다 안전하다. 이러한 내장형 SIM카드는 또한 저렴해야 하며, 궁극적으로 공급 사슬을 단순화하는 데 도움이 된다. 

이러한 "소프트 SIM"은 무선 통신으로 (OTA) 휴대 전화 사업자에 의해 관리되며, 초기 연결 (사업자 간 로밍을 통해)을 가능하게 하는 "부트스트랩" 이동 통신사 배치 (IMSI 번호)와 함께 제공된다. 이러한 장치들이 그들이 활성화된 국가의 로컬 네트워크에 연결되면, 자동적으로 그리고 무선으로 새로운 IMSI를 구현하는 것이 가능하다. 그리고 이는 새로운 (로컬) 사업자 네트워크 상에 장치를 재배치 시킨다. 궁극적으로, 당신이 당신의 아이패드로 앱 스토어에서 휴대 전화 사용 시간을 살 수 있도록 하는 것이 소프트 SIM이다. 필연적인 "5G" 휴대 전화 기술은 이미 진행되고 있으며, 새로운 기능은 4G용으로 개발되고 있다. 그러나, 이번에는, 오늘날 휴대 전화 기술의 최근 일부 반복에 대해서 "더 빠른 것이 반드시 더 나은 것은 아닌" 듯하다. 현재 4G 및 5G에 대한 주요 추진력 중 하나는 저렴한 낮은 대역폭 연결의 개발이며, 이는 전력 소비의 관점에서 매우 밝다 (잠재적으로 매우 긴 배터리 수명을 가능하게 함). 

이 개발은 SIGFOX와 같은 새로운 기술로부터의 인지된 경쟁 위협에 응하여 특히 이동 통신 사업자에 의해 추진되어 왔다. 이러한 기술은 전국적으로 뛰어난 연결을 서비스로 제공하며 (당신이 이동 통신사에 기대할 수 있는 것처럼), 최소 비용 (하드웨어 장치의 비용)으로 AA건전지 하나로 최대 10년까지 사용할 수 있다. 이러한 최대 배터리 수명에 지불된 가격은 대역폭에서 나타난다. SIGFOX은 하루에 장치 당 144 개의 (짧은) 메시지만을 지원할 수 있지만, 많은 M2M 어플리케이션에게는 충분하고도 남는다. 다수의 다른 플레이어는 현재 매우 상이한 시장 진출 전략으로 이 공간에 등장하고 있다. 신흥 플레이어들은 M2M Spectrum, NWave 및 SemTech 등을 포함한다. 일반적으로, 이러한 새로운 공급자는 저전력 광역 (LPWA) 네트워크 제공자라고 불린다. Huawei는 Neul의 인수을 통해 가담했으며, 이들 기업은 이제 공동으로 “흠잡을 데 없는” Cellular IoT (“CIoT”) 솔루션을 개발하고 있다. 이 솔루션은 3G 및 4G 네트워크로의 데이터 트래픽 이동에 의해 해소되어온 오래된 GSM 스펙트럼에 LPWA 서비스를 구축하는 것을 목표로 한다.
여전히 적어도 특정 틈새 시장 내 인정된 (사실상의) 표준으로서의 인식을 갈망하며, 대기하고 있는 다양한 혁신적인 기술들이 있다. 이는 Zigbee, ZWave, VLC (Visual Light Communications 또는 Li-Fi) 그리고 변함없는 인기를 지닌 HALO (High Altitude, Low Orbit) 플랫폼 등을 포함한다. 

그리고 물론, 점점 더 많은 것들이 홈 영역 네트워크 (HANs), 차량 영역 네트워크 (VANs), 개인 영역 네트워크 (PANs)의 광범위한 채택을 이끄는 IoT에 연결될 것이다. 그리고 의심의 여지없이 우리가 잠재적으로 xANs라고 일컫을 수 있는 다른 많은 영역 네트워크들이 아직 상상되지 않았을 것이다. 그러나 결국 IoT의 매우 주변부에 있는 "것들"이 간헐적으로 연결되거나, 심지어 의미 있는 방식의 소통과는 대조적으로 단순히 "감지"될 것이다. 이는 주변의 기술들을 블러링하는 결과를 초래할 것이다. 특히 NFC (근거리 무선 통신)가 다양한 다른 기술들 (2D 바코드, RFID, WiFi 다이렉트 등)에 의해 대체될 수 있으며, 이는 주변 통신 기술로 불릴 수 있다. 

이러한 시장 발전은 Stream Technologies사의 CEO인 Nigel Chadwick와의 다음 인터뷰에서 더욱 분명히 나타난다. 
     
**Jim Morrish**: loT의 연결을 제공하기 위해 취했던 접근 방법을 설명해주시겠습니까?

**Nigel Chadwick**: 연결된 ‘사물’과 관련된 연결 계층이 포괄적이라는 것은 오랫동안 일반적이지만 잘못되게 받아들여졌습니다. 현실은 연결 계층이 복원력, 게다가 지상 수신 범위와 통신 프로토콜 ‘type’에 관한 조각과 같은 기술적인 변수의 측면에서 매우 차별화되어 있다는 것입니다.

궁극적으로, 우리는 loT가 Unified Access Connectivity Environment (U-ACE)라고 불리는 것에 의해 가장 잘 지원될 것이라고 생각합니다. 이와 같은 플랫폼은 무선 통신망(2G, 3G, LTE, CDMA), 위성 통신, wi-fi, 저출력 광범위 라디오 네트워크(예시로 LoRa)와 다른 것들을 포함한 다양한 연결 프로토콜에 적용될 수 있어야 합니다. 이것은 LPWA 네트워크 전송망 사업자와 기업들을 발전시키기면서도, 제삼자에게 연결된 사물들을 모니터하고, 관리하고 상품화하기 위한 강력하지만 간단하고 저비용인 빠른 전개 방법을 제공하기 때문에, 이미 설립된 무선 통신회사에 특히 가치가 있습니다. 

**Jim Morrish**: 이러한 접근과 오늘날 시장의 특징을 이루는 전형적인 접근의 가장 핵심적인 차이점은 무엇입니까?

**Nigel Chadwick**: 지금까지, loT를 위해 고안된 연결 ‘플랫폼’은 구체적인 전송망 사업자와 서비스 제공자에 한정되거나 전매된 것처럼 발전하고 이용되는 경향이 있습니다. 그들은 또한 대체로 하나의 단일한 무선 계층(주로 무선 통신망이나 일부 위성통신)을 관리하게 고안되고 만들어졌습니다. 

이러한 점을 바탕으로, 이전에 제가 설명한 통일된 연결 환경과 비교했을 때 여러 중요한 차이점이 존재합니다.

•	U-ACE는 기술에 상관없이 시스템을 사용 가능해야 하고 어떠한 종류의 무선 프로토콜과도 작업할 수 있도록 고안되어야 한다. 결국, 이것은 다수의 네트워크 연결 계층은 하나의 플랫폼으로부터 완전히 관리될 수 있어야 한다는 것을 의미한다. 그러므로U-ACE는 전 범위의 연결 타입과 지리적인 보급을 제공하는, 모두 다 해결 가능한 솔루션이 되며, 존재하는 통신회사의 ‘on-net’범위 밖의 강력한 연결 관리 툴의 확장을 지원할 수 있다. 이와 관련된 예를 들면 LPWA단일 통신회사의 관리 능력 확장, 혹은 위성 사업자의 무선통신 능력이 있다. 이것은 또한 연결 관리가 효과적으로 미래에도 경쟁력을 갖춘다는 것을 보장한다. \\ 
•	U-ACE는 우리가 ‘기술적으로 밝고 비침습적’이라고 칭하는 것 이여야 한다. API의 간단한 세트를 통하여 호스트 네트워크 연결의 ‘가상의 상태’는 실제 시간, 세세한 관찰과 각 연결의 관리를 제공하기 위해 근본적이나 외부적인 인프라에 의존하여 생성될 수 있다. 이것은 네트워크 사업자와 고객 조직 모두를 위한 시장에 최소의 시간을 발생하며 빠르고 저가의 배치를 가능하게 한다.\\ 
•	API의 사용은 또 다른 이유에서 중요하다. U-ACE는 연결 관리의 수직 체인내의 윗부분이든 아랫부분이든, 연결을 관리하기 위해 사용되는 어떠한 존재하는 플랫폼과도 공존할 수 있어야 한다. 이것은 플랫폼과 상호 작용하는 것들에 무선 연결의 확장과 단일 사용자 접속의 존재를 가능하게 한다. 그렇게 함으로써 다수의 플랫폼 견해와 모든 내재된 복잡함과 중복, 그리고 결부된 위험과 재원 가격의 결부를 피한다. \\ 
Stream Technologies사는 이런 U-ACE를 발전시켜왔습니다. 이것은 우리가 loT-X라고 부르는 플랫폼입니다. loT-X는 제가 이전에 설명하였던 이와 같이 Unified Access Connectivity Environment(U-ACE)라는 Stream의 비전을 반영하여 빠르게 생태계를 바탕으로 한 loT 연결로 진화했습니다. loT-X는 단지 연결 그 이상입니다. 기기 관리, 자료 교환 관리, 그리고 end-to-end loT 솔루션의 성공적인 이행과 때로는 대단히 중요한 다른 측면들까지 가능하게 하는 다른 플랫폼들을 포함하여 loT-X로의 통합이 늘어나고 있습니다. 지금까지 완료된 통합의 예시로는 ARM의 Mbed, ThingWorkx 그리고 wot.io가 있습니다. 이것은 기업들과 무선통신 사업자들(과 그들의 최종 소비자들)이 이미 loT-X에 내제하는 광범위하고 성장중인 생태계에 ‘연결’될 수 있다는 것을 의미합니다.\\ 

**Jim Morrish**: 단지 이것 자체로 이런 모든 기술 선택들을 관리하는 것이 큰 과제이지 않습니까?

**Nigel Chadwick**: Stream사는 진화론적인 방법으로 10년이 넘는 발전 기간 동안 계속 loT-X를 진화시켜왔습니다. 폭넓은 플랫폼 능력뿐만 아니라 측정적인 요구가 주어진 채, 제삼자 무선통신 네트워크에 통합하는 과정에서, 그리고 사용과 기능의 용이함에 관해 최종 사용자의 관점으로부터 어떻게 마찰을 제거할지에 대해 초점을 맞춰왔습니다. 회사는 연결 관찰, 관리, 그리고 청구서 발송을 자동화하는 완전히 발전된 플랫폼과 함께 소프트웨어 개발 회사인 상황으로 진화해왔습니다. 우리는 또한 우리가 다루는 무선 통신, 위성 통신, LPWA, 백홀 기반, 코딩과 같이 우리가 다루는 기반 시설과 핵심 무선 기술들 각각에 회사 내 전문가들과 함께합니다. 우리는 loT-X에 적응하기 위해 우리와 함께하는 통신 업체와 기업 조직들이 어떻게 수직적인 솔루션을 효율적으로 사용하여 가치 체인을 높일 수 있는지 파악하도록 그들을 돕기 위한 회사 내의 확립된 기술 전문가에 점점 더 의존할 수 있도록 2000년 이후로 최종 고객까지의 연결을 제공해왔습니다.

**Jim Morrish**: U-ACE가 특정 기기 연결의 한계와 고객들의 필요, 요구 사이의 중개에 어떻게 대처해야 합니까?

**Nigel Chadwick**: U-ACE는 어떠한 연결 프로토콜을 통해서도 데이터를 받아들일 수 있어야 하며 불가능한 상황이 없어야 합니다. 현재의 보급적인(그리고 다지 보급적이지는 않은) 프로토콜 대부분에 바로 구입할 수 있는 어댑터가 손쉽게 가능해야 합니다. 주어진 U-ACE는 오직 근본적으로 매우 제한적인 매개가 있는 통신 계층의 관리에 쓰이도록 만들어졌습니다. 

데이터는 어디서 왔는지에 상관없이 데이터입니다. Stream Technologies에서, 우리는 복잡성과 실패의 확률을 감소시키기 위해 모든 것을 최대한 간단하게 유지하려고 노력했습니다. 우리의 접근은 각 독립적인 네트워크들이 함께 일하도록 만들었다기 보다는 모든 네트워크들이 정의된 구조에 순응하도록 만들었습니다. 우리가 만들어온 것은 네트워크가 어떻게 작용해야 하는지 그리고 우리가 이 네트워크에 어떻게 적응해야 하는지의 추상적인 개념입니다. 이것의 혜택 중 하나는 새로운 네트워크가 설정되자 마자 즉시 우리의 모든 다른 서비스와 통합에 접근한다는 것입니다.
  
**Jim Morrish**: 전체적인 loT 생태계에서 가장 이상적인 고객(과 파트너)는 누구라고 생각하십니까?

**Nigel Chadwick**: 우리는 loT-X와 U-ACE가 넓은 범위의 기반에서 연결 소득을 가능하게 하고 Total Cost of Ownership(TCO)을 감소시키면서, 다양한 고객과 파트너를 위한 잠재적인 가치를 드러낼 가능성을 갖고 있다고 생각합니다. 이것은 기기나 사물 연결을 요구하는 상당한 수의 고객과 함께하는 loT 생태계의 다른 부분에서 System Integrator와 Solution Provider가 연결 계층에 적용되는 불확실성과 파편을 제거하면서 상당한 양의 마찰과 관성을 분명하게 제거할 수 있다는 것을 의미합니다. 규모, 지리적인 범위, 배치된 연결 종류의 관점에서 연결 요구의 범위가 클수록 위험과 가격의 관리가 증가하고, loT-X의 적합성이 증가합니다. 이것은 같은 이유로 기업에게도 똑같이 적용 가능합니다. 우리가 만든 생태계는 무선 통신, wifi, 위성을 포함한 통신 업체들에게 그들의 존재하고 있거나 미래의 최종 고객 수요를 위한 바로 준비가 되어있는 서비스를 제공합니다. loT-X를 사용하는 고객의 필요에 응답할 뿐만 아니라 생태계 진화의 결과로써, 추가의 서비스와 기술은 더 이상의 통합을 계속 할 것이고, 이런 발전은 생태계 내의 모든 어탭터와 사용자들을 위한 유연성과 선택권을 확대합니다. 모두가 혜택을 받습니다. 

**Jim Morrish**: 전체적인 시장이 어떻게 발전할 것이라고 생각하십니까?

**Nigel Chadwick**: 사물인터넷은 엄청난 양의 연결을 약속합니다. 최종 연결 지점의 규모 때문에, 그들의 필연적인 수익창출은 새로운 조직과 무리들 혹은 설립된 회사들뿐만 아니라 새로운 서비스 형태의 조직들로 구성된 동업관계를 이끌 것입니다. 이런 역동성은 잠재적인 가치의 이동과 System Integrator와 Solution Provider 타입의 조직뿐만 아니라 LPWA 솔루션, wifi와 케이블 오퍼레이터를 향한 권한 분산을 포함하여, 가치가 어디서 창출되는지에 관하여 바뀔 것입니다. 우리는 여전히 loT의 라이프 사이클의 매우 초기 단계에 있습니다. 

또한 아직 대중 세계에서 채택하진 않았지만 상당히 기대하고 논의되었던 소비자의 부문이 남아있습니다. 가정 보안, 개인적인 자산 관리, 건강들은 loT에 여전히 영향을 받는 거대한 시장입니다. 이런 부문을 위한 연결 관리는 다른 무선 계층을 거쳐 동등하게 요구될 것입니다. 보안, 안정성과 데이터 발송, 저장, 접근성 및 공유는 다시 한번 공통적인 영역에서 전통적인 기업들을 위협하고, 고객에게 지배권을 넘길 것 같은 새로운 회사와 기술의 진전을 이끄는 도전을 제안하며 우리의 안건을 움직입니다.   

최종적으로, 수많은 사물이 인터넷에 연결되려면 반드시 해야 하는 Total Cost of Ownership의 중요한 화제는 아마도 플랫폼 연결 관리가 나오는 데서 시작하는, 기본적인 서비스는 무료로 제공하고 추가 고급 기능에 대해서는 요금을 받는 freemium 모델과 같은 새로운 비즈니스 모델일 것이라고 예상합니다. 만약 TOC가 감소한다면, 연결 계층의 관리는 시스템과 프로세스의 자동화가 어느 정도의 가격 인하를 낳는 명확한 요소입니다. 반대로, Wi-fi (예를들어 광대역 연결로 이미 지불되고 사용될 때) 혹은 공공 LPWA 네트워크와 같은 현재의 무료 연결 선택권은 또한 동시에 개인적인 네트워크로 관리되기 시작할 수 있습니다. 그렇게 함으로써 수익 창출의 가능성을 도입합니다. 이것은 더 나아가 무허가 무선 영역 내 다수의 개인적 네트워크를 구성하는 새로운 전 국가적 네트워크의 발생이라는 다소 급진적인 개념을 소개합니다.

이러한 아이디어와 함께, 쉽게 네트워크를 관리하고, 연결을 관찰하며 사물로부터, 그리고 사물을 위한 연결에서 수익을 창출하는 능력은 놀라운 기회라는 것이 명확해집니다. 그리고 우리는 이 가능한 것의 시작 단계에 있습니다. 
                                      
**권장 사항**

결국, 이 장에서 논의의 핵심은 ‘서비스로서의 연결’ 개념과 이 과제를 지지하는 독립체들의 등장이다. 이것은 나타나고 있지만, 오래된 M2M 시장의 loT 시장으로의 전환으로써 특히 가치 있는 개념이다. 이것은 전반적인 기술에 상관없이 사용 가능하다는 불가지론과, loT을 특징짓는 관념과 함께 매우 일관된다. 

이것을 고려하여, M2M과 loT로부터 이득을 추구하는 기업들의 요구사항과 함께, 연결 지원 플랫폼 제공자들은 아래 사항을 추구해야 한다.

•	기업이 기기 및 연결을 관리하며 어플리케이션과 자료를 관리하고 발전시키기 위해, 민첩하고, 측정할 수 있으며 유연한 솔루션을 개발하고, 설계하고, 배치하도록 플랫폼을 고안하고 설계함으로써 M2M과 loT시장의 성장과 발전이 마찰되는 지점을 최소화하도록 노력하라.\\ 
•	기업이 end-to-end M2M과 loT 솔루션을 관리하고 배치하게 권장하고, 그것을 가능하게 하는 열려있고 통합적인 시스템을 개발하라.\\ 
•	기업의 발전하는 요구사항을 명심하고, 어떻게 플랫폼이 새로운 시장과 기회로 기업들이 전략적인 팽창을 할 수 있게 하는지 계속해서 분석하라.\\ 

최종적으로, 연결 지지 플랫폼의 등장이 상품 상태에 연결 공급을 밀쳐내지 않는다는 것은 강조할만하다. 현실에서, ‘모범 경영’모델을 앞서 보여준 12개의 기능 및 특징과 함께, 이 새로운 연결 플랫폼 모델은 시장에 중요한 첨가가 될 것이다. 연결이 상품이 되는 동안, 기술 불가지론의 등장, 서비스로서의 매끄러운 연결은 매우 가치 있는 과제가 될 것이다. 

우리는 Vodafone의 M2M 플랫폼 Principal Product Manager인 Mike Prince에게 이번 장의 도움에 감사의 말씀을 드린다.
                   
==== 3. [빅] 데이터와 프로세스 관리 ====

이 기술 개요의 첫 번째 파트는 주로 자산 관련 자료에 강한 초점을 맞춰온, loT내에서 관리되어온 다른 종류의 데이터를 살펴본다. 또한 우리는 어떤 데이터 관리 기술이 각 프로젝트의 시나리오에 적합한지 이야기할 것이다. 

두 번째 파트에서는 어떻게 프로세스 관리가 loT 솔루션의 기능적인 면을 간소화시키고, 활용하고, 부분적으로 자동화하는 역할을 할 수 있을지 살펴볼 것이다. 또한 어떤 종류의 프로세스 관리 기술이 loT내의 어떤 프로세스에 적합할지, 그리고 이것이 첫 번째 파트에서 소개된 다른 종류의 데이터와 어떻게 연관될 수 있을지 논의할 것이다. 특히, 어떻게 다른 종류의 loT 사건과 분석적인 결과가 프로세스를 발생시키거나 신호를 보낼 수 있을지 이해하고자 한다. 

==== I. [빅] 데이터 관리 ====

빅데이터는 가장 중요한 loT 실현 기술 중 하나로 여겨진다. 이 장에, 우리는 M2M과 loT 어플리케이션을 위한 빅(그리고 그다지 ‘크지’ 않은) 데이터 관리에 대해 이야기할 것이다. 이것은 복잡한 주제이고 두루 적용되도록 만든 해결책이 없기 때문에, 우리는 다른 복잡성의 시나리오부터 이야기해나감으로써 점차적으로 대화를 구성해나갈 것이다. 그러나, 이에 다다르기 전에, 우리는 빅데이터 동향에서 가장 존경받는 권위자인 Cloudera의 설립자이자 최고 전략 전략책임자인 Mike Olson과 얘기함으로써 발판을 마련할 것이다. 

**Dirk Slama**: Mike, Cloudera는 가장 널리 사용되는 빅데이터 체계 중 하나인 Apache Hadoo를 담당하고 있습니다. 당신이 본 것 중 가장 흥미로운 당신의 기술을 사용한 loT 사용 경우에 대해 설명해주실 수 있습니까?

**Mike Olson**: 그럼요. 당신이 CERN의 Large Hadron Collider(LHC)를 당신에 책에서 케이스 스터디 중 하나로 언급했습니다. 그리고 어떻게 LHC가 단지 광대한 양의 센서 데이터를 수집했을 뿐만 아니라, 실험으로부터 데이터를 위한 효과적이고 여러 단계로 작동하는 정보 루트를 만들어나가고 있는지도요. 밝혀졌듯이, Nebraska-Lincoln대학교에서 이런 작동 정보 루트의 2단계에서 적어도 연구 시설들 중 하나는 Hadoop을 이용하고 있습니다. 그들은 CERN에서 입자 충돌로부터 발생되는 방대한 양의 데이터에서 심화된 물리 분석을 이행하기 위해 이것을 사용하고 있습니다.

또한 많은 흥미로운 연구들이 존재합니다. 예를 들어, 스마트 그리드는 분명히 빅테이터 기술을 이용한 중요한 loT 어플리케이션입니다. 그리고 우리는 Hadoop이 많은 회사들에서 사용되고 있다는 것을 압니다. 좋은 예시는 Opower로, 그들의 자동계량으로부터 스마트 그리드 관찰 스트리밍을 사용, 관찰 및 분석하길 원하는 유틸리티에 그들의 서비스를 판매하고 있습니다. 자동 계량은 매 6초마다 관찰을 기록하고 있으며, 이는 수집하기 위해 사용했던 한달 마다 측정했던 것보다 대단히 많습니다. 이것은 그들이 하루 동안 요구되는 잘 정제된 신호를 성립한다는 것을 의미합니다. 그들은 심지어 세탁기를 켜거나 냉장고가 켜졌다는 것 같은 명확한 사건이 언제 발생하는지도 결정할 수 있습니다. 예를 들어, 그들은 실제 시간에서 요구를 관찰할 수 있고, 이런 관찰의 변동을 예측합니다. 이는 단지 스마트 그리드 활동에 기초하지 않고, 기창 예측, 보고 그리고 다가오는 기념일이나 이벤트에 기초하기도 합니다. 그들은 심지어 요구를 관리하기 위해 예를 들면 고객이 그들의 사용이 이웃의 비교되는 것을 알게 하고, 사람들이 경쟁을 하도록 유도하는 것과 같이, 게임화(gamification- 게임과 무관한 웹사이트나 어플리케이션에서 게임과 연관된 개념을 활용하는 것)를 이용할 수도 있습니다. 

매우 다양한 범위의 사용 케이스가 있지만, 보통 모든 이런 데이터들은 기계 도량에서 기계와 센서에 의해 발생합니다. 오래된 기술을 사용하여 이것을 모으고 분석하는 것은 도전입니다. 거대하고, 도량을 벗어난 기반은 이런 자료의 과정과 분석을 훨씬 저렴하게 만들어줍니다. 

**Dirk Slama**: 그래서, 이전 세대의 컴퓨터 사용과 데이터 관리에 의해 직면되지 않았던 어떤 도전을 loT가 선사합니까?

**Mike Olson**: 제 개인적인 견해는 우리는 오직 매우 이른 단계의 loT 데이터 흐름만을 보고 있으며, 이런 데이터 흐름들은 거의 압도적입니다. 한 달에 한번과 1분에 10번 읽은 것으로부터 스마트 그리드로부터 스트리밍되는 정보의 양을 생각해 봅시다. 이것은 한 달 동안 미터당 150,000배 많은 관찰 입니다. 이런 데이터 용량은 가속화되도록 보장되어 있습니다. 미래에, 우리는 더 많은 기기로부터 더 잘 정제된 데이터를 모으고 있을 것입니다. 

샌프란시스코 도시를 살펴보면, 일부 사람들은 도시 내에 스마트폰이나 차뿐만 아니라, 공기압, 온도, 진동 등을 측정하는 도시의 높은 빌딩들과 같이 많은 곳에서 사용하는 센서가 20억개라고 측정합니다. 현재 이런 센서에서 가장 흥미로운 점은 그들의 대부분이 네트워크에 연결되어있지 않다는 것입니다. 저는 앞으로 반 세기 내로 그들의 대부분이 네트워크에 연결되고, 그런 기기 들은 네트워크나 메쉬 연결 센서로 교환될 것이라고 생각합니다. 그리고 이것은 확실한 쓰나미 데이터를 가져올 것입니다. 그래서 이러한 데이터를 측정하고, 가공하고, 요약하고, 관리하고 분석할 수 있는 시스템을 고안하는 것이 IT의 큰 도전입니다. 우리는 우리가 보려던 것과 같은 정보의 호수를 한번도 본 적이 없습니다.   

**Dirk Slama**: 그래서, loT를 현실로 만드는 데이터 관리에 핵심 발전이 있을 것입니까?

**Mike Olson**: 우리는 오늘날 10년전에는 없던 계산 플랫폼과 도량을 넘어선 저장을 만들고 있습니다. 우리는 그것의 도량에서 정보를 모으지 않았고, 우리가 지금 하는 것과 같이 분석하려고 하지 않았기 때문에 그들을 필요로 하지 않았었습니다. 기계에서 발생한 데이터의 도래가 우리에게 어떻게 데이터를 측정, 저장, 가공해야 하는지 재고하게끔 하고 있습니다. 매우 대규모의 유사한 계산 시스템을 만드는 것은 현재 매우 흔한 일입니다. 우리가 만일 앞으로 5년에서 10년의 발전을 살펴본다면, 소프트웨어의 상태는 계속 개선될 것입니다. 우리는 더 나은 분석 알고리즘, 도량을 넘어선 저장 아키텍처를 갖고 있을 것이며, 적은 디스크 공간을 관리할 수 있을 것입니다. 왜냐하면 우리는 어떻게 데이터를 입력하고 복제해야 하는지 더 잘 알고 있을 것이기 때문입니다. 

그러나 제가 생각하기로 가장 흥미로운 것은 하드웨어에서의 발전입니다. 모바일 기기나 일반적인 환경에서 네트워크와 연결된 센서들의 계속 확산하거나 폭발적으로 증가할 것입니다. 이는 많은 양의 새로운 데이터를 생산할 것입니다. Intel의 Atom Chip-Line이나 다른 판매 회사의 비슷한 것들을 생각해 보십시오. 데이터 측정/저장/분석 면에서, 우리는 도량을 넘어선 기반이 더 잘 구축된 칩들을 볼 것입니다. 메모리 밀도는 당연히 증가할 것이며, 우리는 많은 어플리케이션에서 디스크를 대체하는 고체 드라이브를 사용할 것입니다. 칩의 단계에서 네트워킹 접속은 더욱 빠르고 흔해질 것이며, 주로 칩 레벨에서 가능한 전기를 이용한 네트워크를 대신해서 광학 저장을 사용할 것입니다. 메모리에 디스크인 저장에서의 상대적인 잠복은 이동할 것이고, RAM에 고체 상태의 디스크는 미래에 더 보편적인 방법이 될 것입니다. 광학 네트워크의 속도는 저장공간을 더욱 접근 용이하게 이동시킬 것입니다. 그래서 저는 하드웨어 단계에서 이전에 가능했던 그 어떤 것보다 더 많은 데이터와 함께할 소프트웨어를 실현할 많은 혁명을 보게 될 것이라고 생각합니다.

**Dirk Slama**: 빅데이터를 사용하는 loT 솔루션을 구축하고 싶은 회사들에게 가장 큰 위험 요소은 무엇입니까? 어떻게 이런 위험 요소를 경감시킬 수 있습니까?

**Mike Olson**: 데이터를 측정하고, 정제하고 분석하는 기반뿐만 아니라, 센서 네트워크의 도량을 넘어선 확산과 같은 종류의 데이터를 발생하는 기술은 새롭습니다. 우리의 경험은 이 개념의 작은 범위에서 입증에서 시작하는 것이 현명하다는 것이었습니다. 수백만 개의 기기를 대신해서, 아마도 수천 개의 기기에서 시작해 보십시오. 그리고 이를 처리할 수 있는 측정 및 정제 기반을 만드십시오. 이렇게 함으로써 당신은 이것이 잘 작동하는지 체크할 수 있으며, 어떻게 이런 시스템이 작동하고, 무엇을 할 수 있는지에 관해 당신의 사람이나 조직을 교육시킬 수 있습니다. 이것들은 새로운 기술이며 새로운 기술의 채택은 성공적인 배치를 위해 교육과 새로운 과정을 요구합니다. 무한한 범위의 loT를 실행하기 전에 작은 범위에서 이것을 배우는 것은 중요합니다.

우리는 loT기술에 매료된 많은 사람들과 이야기합니다. 그들은 그것 자체로의 빅데이터에 흥분합니다. 그들은 우리가 일하기에 좋지 않은 사람들입니다. 왜냐하면 그들은 근본적으로 사업적인 문제에서 동력을 얻지 않기 때문입니다. 당신이 loT가 왜 중요한지에 대해 생각하기 시작할 때, 이는 매우 중요합니다. 어떤 질문에 당신은 센서 데이터 스트리밍으로 답하고 싶습니까? 어떤 비즈니스 문제를 해결하고 싶습니까? 어떤 최적화를 만들어내고 싶습니까? 그리고 이런 문제들을 제기하기 위한 당신의 시스템을 고안하십시오. 저는 새로운 기술을 활용하고 싶은 엔지니어들의 ‘샤이니 오브젝트 신드롬’을 가진 사람들 중 하나이지만, 그런 프로젝트들은 보통 명확한 기준이 없기 때문에 실패합니다.  

**Dirk Slama**: 당신에게 빅데이터 기술을 사용할 때라고, 혹은 사용하지 말라고 말해주는 명확한 지표가 있습니까? 

**Mike Olson**: 만약 당신이 전통적인 거래 프로세싱이나 OLAP 작업량을 갖고 있다면, 우리는 당신에게 Oracle, SQL Server, Terra Date등을 가리킬 것입니다. 왜냐하면 이런 시스템들은 저런 형태에서 작업하도록 발전했기 때문입니다. 새로운 데이터 양이나 새로운 분석 작업은 빅데이터 기술이 가장 잘 적용될 수 있는 곳입니다. 목표가 ‘우리는 존재하던 기반을 치워 버리고 이것을 Hadoop으로 교체하고 싶어요’일 때, 우리는 보통 그런 기회를 떠납니다. 이런 것은 잘 적용될 수 없습니다. 만약 당신이 새로운 문제나 사업 추진, 그리고 새로운 데이터 양를 만나면, 이들이 가장 성공적인 경우입니다. 떼어내고 교체하고자 하는 거대하고 눈이 먼 욕구는 절대 성공하지 않습니다. 

**Dirk Slama**: 이런 지표들을 정량화할 수 있습니까? 빅데이터 기술을 요구하기 위한 데이터는 얼마나 커야 합니까? 

**Mike Olson**: 산업이 빅데이터에 대해 이야기할 때, 그들은 항상 양, 다양성, 속도에 대해서 이야기 합니다. 이것은 당신이 매우 큰 양의 데이터를 가질 수 있고, 당신이 절대 한번에 모아볼 수 없었던 매우 다른 종류의 데이터를 가질 수 있고, 혹은 당신이 격정적인 속도로 도착하는 데이터를 가질 수 있다는 것을 의미합니다. 우리가 볼 때 Vs에 적합하지 않지만, 당신이 반드시 이용해야 할 분석 알고리즘인 하나의 기준이 있습니다. 이것은, 당신이 데이터에 이행하고 싶은 계산 방식은 무엇인가? 입니다. 때때로 당신이 적당한 양의 데이터를 기반으로 매우 많은 계산을 필요로 한다면, Hadoop같은 도량을 넘어서는 기반은 타당합니다. 양, 다양성, 속도 혹은 컴퓨터를 사용한 복잡함 필요조건들 중 하나만 만족시키면 빅데이터 기반을 매력적으로 만들기에 충분합니다. 우리의 경험해서, 만약 당신이 저런 필요 조건들 중 두 개 이상을 갖고 있다면, 새로운 플랫폼은 치명적입니다.

**Dirk Slama**: 빅데이터와 loT의 이행과 전략을 개발하고 있는 독자들에게 해주고 싶은 충고가 있습니까?

**Mike Olson**: 함께 일하는 조직에 하는 제 일관된 충고는 사업을 위해서 성공적인 결과가 의미 있는 한, 두 개의 사용 사례를 갖고 적정한 범위에서 공격해 보라는 것입니다. 이로 인해 당신은 필요한 기술을 얻고, 기술이 실제로 문제를 해결해 준다는 것을 입증할 수 있을 것입니다. 한번 이를 해두면, 주어진 기반에서 큰 범위도 간단하게 일관적인 가격으로 적용되고, 성공적일 것입니다.

**Dirk Slama**: 누가 loT와 빅데이터로부터 가장 많이 그리고 적게 얻을 수 있는 위치에 있습니까?

**Mike Olson**: 제 진심 어린 확신은 데이터는 실질적으로 모든 인간의 노력 범주에서 변형된다는 것입니다. 그래서, 당신과 제 일생에서, 우리는 암을 위한 치료법을 찾을 것입니다. 왜냐하면 우리는 이전에 할 수 없었던 방법으로 유전적이고 환경적인 데이터를 분석할 수 있기 때문입니다. 농업 사회에서 깨끗한 물과 에너지의 생산과 분배로 우리는 70억 대신 90억명의 사람들에게 배급할 수 있는 더 조밀하고 나은 농작물을 키울 수도 있습니다. 모든 노력에서, 데이터는 효율성을 제공할 것입니다. 만약 기업들이 기회를 놓친다면, 그들은 경쟁에서 질 수도 있습니다.

최근 사생활과 Edward Snowden, NSA에 관하여 많은 논란이 있었습니다. 제가 가진 하나의 염려는 이런 예시들 때문에 우리가 부당한 반발을 가질 수 있다는 것입니다. 그러나 예를 들어 우리가 매우 정교하게 학생의 행동을 관찰할 수 있다면, 그리고 각 학생의 학습 양식에 맞춰 수업을 고안할 수 있다면 얻을 수 있는 장점에 대해서 생각해봅시다. 우린 그 어느 때보다도 빠르고 효과적으로 배울 수 있는 똑똑한 사람들을 갖게 될 것입니다. 우리가 가져올 건강관리의 질에 관해서 생각해 보십시오.  

사생활은 중요하고, 앞으로도 중요할 것입니다. 우리는 사생활을 타당하게 보장하는 정교한 정책, 의미 있는 법과 처벌이 필요합니다. ‘데이터 지니’는 병에서 나온 것 과 같습니다. 저는 우리가 이를 다시 되돌릴 수 있다고 생각하지 않습니다. 보통, 저는 데이터의 생산과 수집을 축소하기 위해 시도하는 것은 실수라고 생각합니다. 왜냐하면 저는 이것이 우리 사회에서 대단히 좋은 기회라고 믿기 때문입니다. 
                   
==== IoT 데이터 유형 및 분석 유형 ====

파트 2(“Ignite | IoT 방법론”)의 Plan/Build/Run 부분에서 다뤘듯이, 배포된 loT 어플리케이션 지형 내에서 다른 데이터 종류들 사이의 관계와 분배를 이해하는 것은 중요하다. 아래의 자료는 loT 환경 내에서 발견되는 가장 보편적인 데이터 종류의 개요를 제공한다. 멀리 떨어진 자산으로부터 오는 데이터는 보통 미터 데이터, 센서 데이터, 사건 데이터 및 비디오 데이터 같은 멀티미디어 데이터를 포함한다. 자산에 업로드된 데이터는 대부분 구성 데이터, 작업 지시, 기상 예측 같은 의사결정 맥락, 그리고 다양한 멀티미디어 파일을 포함한다. 말미에서, 멀리 떨어진 자산으로부터 오는 데이터들은 보통 정해진 loT나 M2M 데이터 저장소에서 관리된다. 이 저장소들은 미터 기록의 모음 같은 시간 연속 데이터뿐만이 아니라, 기본적인 자산 데이터와 기기데이터, 상태 데이터, 상태 변화 기록 등을 포함한다. 쓸만한 여러 종류들로 이루어진 기업 어플리케이션 지형의 경우와 같이, 일부는 불필요할 수 있는 자산 관련 데이터를 포함한 다른 어플리케이션이 대부분이라는 것은 아무런 가치가 없다. 예를 들어, ERP 시스템은 고객 계약 데이터를 비롯하여 판매 시간에 제품 배치에 관련된 모든 데이터를 포함한 Asset Master Data를 갖고 있는 경향이 있다. 하나 이상의 티켓 관리 시스템이 구체적인 자산에 관련된 고객 문의들을 포함한다. 이런 데이터들을 하나의 전체적인 자산의 관점으로 합치는 것은 보통 도전적인 일이다. 덧붙여, 다른 시스템들에는 고객 거래 기록, 고객의 사회적 데이터, 상품 데이터를 포함한 많은 관련된 데이터들이 있을 것이다.
                  
{{ :파트2_58번그림.png?nolink&300 |}}                   
                   Data & analytics in the context of Enterprise IoT                  
                   
이 데이터를 기반으로 효율적인 어플리케이션을 구축하는 것은 이질적인 기업 어플리케이션 랜드스케이프에서 만큼이나 어려우며, EAM (기업 아키텍처 관리), EAI (기업 어플리케이션 통합), SOA (서비스 지향 아키텍처), BPM (비즈니스 프로세스 관리)와 같은 잘 확립된 접근법을 통해 다뤄질 수 있다 [EBPM]. 이는 우리가 다음 장에서 살펴볼 내용이다. 

IoT 데이터를 이해하는 것은 효율적인 분석을 필요로 한다. 이는 우리가 다음에서 볼 것처럼, 빅데이터에만 적용되는 것이 아니다. 분석에는 다양한 유형이 있다. 일부 분석은 단순히 과거 사건을 검토하지만, 좀 더 향상된 분석 유형은 미래의 사건 및 발전을 예측하기 위해 과거 데이터를 활용하려고 시도한다. 
기본 분석은 다음을 포함한다. 

•	기술적 분석: “무엇이 일어나고 있는가?” (예: 엔진이 작동을 멈추었다)\\ 
•	진단적 분석: “왜 일어났는가?” (예: 결함 있는 볼트 때문에)\\ 

발전된 미래 지향적 분석은 다음을 포함한다. 

•	예측적 분석: “무슨 일이 일어날 것 같은가?” (예: 언제 엔진이 작동을 멈출 것 같은가?)\\ 
•	지시적 분석: “이러한 일을 미연에 방지하기 위해 무엇을 해야 하는가?” (예: 고장나기 전에 볼트를 교체한다)\\ 

모든 IoT 솔루션이 위의 데이터 유형과 분석 유형을 모두 활용하는 것은 아니다. 사실 데이터 관리 아키텍처 및 선택된 툴이 정말로 필요한 것에 한정되도록 하는 방법을 이해하는 것은 프로젝트 관리자에 매우 중요하다. 다음에서 볼 수 있는 바와 같이, 다른 기술들을 결합하는 좋은 방법이 있기에, 최소 기능 제품 (MVP) 철학으로 시작하는 것은 의미가 있다. 물론, 예를 들어 관계형 대 NoSQL에서 오른쪽 핵심 데이터 관리 기술을 선택하는 것은 신중한 분석에 기초해야 한다.

==== 네 개의 IoT 데이터 관리 시나리오 ====

Ignite | IoT 방법론을 사용하는 IoT 프로젝트 관리자가 데이터 관리를 위한 올바른 아키텍쳐와 기술을 더 쉽게 확인할 수 있도록하기 위해서, 우리는 네 가지 기본 시나리오를 정의했다. 우리는 점차적으로 IoT 데이터 관리 아키텍처와 기술의 다양한 옵션에 대한 논의를 구성하기 위해 이러한 시나리오를 사용할 것이다. 

시나리오 A는 비교적 간단하다. 필드에 적당한 수의 자산 (1~2천개의 자산)을 가정하며 각 시간과 자산 당 들어오는 사건의 수는 매우 적다. 분석은 기본적인 보고와 기술적인 분석으로 한정된다. 우리는 이 시나리오를 "기본 M2M"이라고 부른다.

시나리오 B는 필드에 수십만 개의 자산 및 자산에서 들어오는 많은 양의 데이터를 가진 실제 기업 IoT 솔루션을 가정한다. 이 프로젝트의 초기 초점은 자산으로부터의 데이터 스트림을 분석하고 중요한 사건에 "실시간"으로 반응하는 것에 있다 (완전한 실시간이 아닌 예를 들어 1초 이내). 우리는 이 시나리오를 "기업의 IoT 및 CEP"라고 부르며, CEP는 복잡한 사건 처리 (Complex Event Processing)를 의미한다.

시나리오 C는 오랜 기간 동안 대규모로 필드 데이터를 저장하기 위한 요건을 추가하는 시나리오를 토대로 한다. 기본적인 기술적 분석 및 잠재적으로 진단적 분석이 이 데이터에서 수행될 것이다.
시나리오 D는 시나리오 C의 연장선으로, 예측 및 지시적 분석과 같은 더 향상된 분석이 추가된다. 

모든 네 가지 시나리오의 요약은 아래 도표에서 찾을 수 있다. 

{{ :파트2_59번그림.png?nolink&300 |}}
                          Overview of 4 IoT data management scenarios
                          
==== 시나리오 A: 기본 M2M ====

시나리오A의 일반적인 어플리케이션은 모바일 산업 기계 집단 등에 대한 원격 장비 모니터링이다. 제한된 수의 상태 업데이트 및 사건은 시간이 지남에 따라 각 기계에 대해 예상된다. 기본적인 보고는 기계 상태 개요, 기계 활용 등을 보여줄 것이다. 아키텍쳐는 보통 비교적 백엔드가 간단할 것이다. 초기의 어려움은 대부분 자산의 통합 및 자산에 필요한 장치 인터페이스를 가지는 것에 초점을 맞출 것이다 (IoT 게이트웨이에 대한 기술 프로파일 논의 참조). 아래 그림은 시나리오 A의 AIA를 보여준다.
                          
{{ :파트2_60번그림.png?nolink&300 |}}
                          Architecture for data management in basic M2M

기술 선택의 관점에서, 어떤 데이터 저장소가 자산과 필드 데이터를 관리하기 위해 사용되어야 하는지, 그리고 어떤 인터페이스 기술이 원거리 자산을 통합하느데 사용되어야 하는지에 대한 두 가지 핵심 결정이 이루어져야 한다. 

데이터 저장소의 경우, RDBMS와 NoSQL를 포함하는 많은 상이한 옵션이 있다. 많은 일반적인 M2M 어플리케이션 플랫폼은 RDBMS 기술을 기반으로 하고 있으며, 이는 대부분의 경우 완벽하게 잘 작동한다. 하나의 장점은 백업 관리에의 보고로부터 관련 도구의 풍부한 생태계를 기반으로 한다는 것이다. 또한, 대부분의 조직은 RDBMS 기반의 솔루션을 구축하고 운영하는 데 필요한 기술을 지닐 것이다. 

그러나, 시간이 지남에 따라 시나리오가 확장될 가능성이 있는 경우, 예를 들어 조금 더 복잡한 어플리케이션이 개발되거나 분석 요건이 향후 좀 더 진보된 시계열 분석을 포함할 가능성이 있는 경우, 솔루션 설계자는 대신 NoSQL 데이터베이스를 고려하는 것이 낫다. 

두 번째 기술 결정은 자산의 통합과 그것으로부터 스트리밍되는 다른 데이터 및 사건의 관리에 관한 것이다. M2M 또는 IoT 어플리케이션 플랫폼이 사용되는 경우, 이 기능이 내장될 가능성이 높다. 맞춤형 발전의 경우, 여러 옵션이 있다. 아주 기본적인 어플리케이션에서는 어플리케이션 서버 또는 NodeJS와 같은 기본 사건 처리 기술이 사용될 수 있다. 정립된 메시징 및 대안 적으로 또는 추가로 사용될 수 있는 관련 기술의 부족함이 없다. 마지막으로, MQTT와 같은 일부 IoT에 특화된 메시징 솔루션이 등장하기 시작했으며, 이는 그들의 특정 성격 때문에 추가적인 혜택을 제공해야 한다. 아래 그림은 개요를 제공한다.

{{ :파트2_61번그림.png?nolink&300 |}}
                            Basic event processing technologies
                            
==== 시나리오 B: 기업 IoT 및 CEP ====
 
시나리오 B는 필드에서 훨씬 많은 자산을 다루고 있다고 가정하거나, 자산이 백엔드에 훨씬 많은 양의 데이터를 제공하고 있다고 가정하거나, 둘 모두를 가정한다.

이 시나리오에서 데이터 스트림에의 밀접한 모니터링이 종종 필요하며, 특정 유형의 상황에 신속하게 반응하는 능력 또한 필요하다. 대부분의 경우, 실시간으로 특정 패턴의 데이터 스트림을 분석할 필요가 있으며, 그 예로 온도의 급격한 증가를 들 수 있다.

이러한 경우에 매우 유용할 수 있는 하나의 기술은 복잡 사건 처리 (CEP)이다. CEP는 다수의 데이터 스트림으로부터의 데이터는 비지니스 수준에서 특정 의미를 갖는 패턴을 추론하기 위해 추적되고 분석될 수 있다. 빨간색으로 바뀌는 신호등과 동시에 도로를 건너는 보행자가 그 패턴의 예이다. 따라서, 하나의 흥미로운 CEP 사용 사례는 센서 데이터 융합의 영역에 있다 (IoT 게이트웨이 기술 프로파일 참조).  
CEP의 전반적인 목적은 관련 사건의 비즈니스 로직을 식별하고, (거의) 실시간으로 그들에 응답 할 수 있게 되는 것이다.

Oracle의 프로젝트 관리 감독자인 Robin Smith는 우리를 위해 다음과 같이 CEP의 기본 사건 패턴을 요약했다.

필터링 

•	데이터 스트림은 200F 미만의 온도 등 특정 범위에 대해 필터링된다. 
상관 관계 및 집계\\ 
•	스크롤링, 지난 3일간 평균 맥박수 등의 시간 기반 창문 지표 
패턴 맞추기 \\ 
•	15분 내에 일어나는 기계 사건 A, B, C 등 감지된 사건 패턴의 알림 
지리, 예측 모델링 및 그 외\\ 
•	지리적 움직임 패턴의 즉각적 인식, 데이터 마이닝 알고리즘을 사용하는 과거 비지니스 지능형 모델의 어플리케이션 

아래 그림은 CEP의 기본 원칙을 보여준다. 
                            
{{ :파트2_62번그림.png?nolink&300 |}}           
                                                      Basic principle of CEP                 

**사례: 지속적 문의 언어 (CQL)**

CEP에서 사건 흐름을 분석하는 잘 정립된 방법의 한가지 좋은 예는 표준 SQL 언어의 확장인 지속적 문의 언어 (CQL)이다. CEP을 지원하기 위해 시각적 모델러를 이용하는 많은 도구를 포함하여 많은 다른 방법이 있다. 우리는 기본 원리를 설명할 수 있도록 우리의 예로 CQL을 사용할 것이다. 

Oracle의 프로젝트 관리 감독자인 Robin Smith는 다음과 같이 CQL을 설명한다. 

•	CQL은 필터링, 분할, 집계, 상관 관계 (스트림에 걸쳐) 그리고 스트리밍 및 관계 데이터에 일치하는 패턴을 조회\\ 
•	CQL은 스트림의 개념, 관계와 스트림 사이의 매핑을 위한 사업자, 패턴 매칭의 확장을 추가하여 표준 SQL을 확장\\ 
•	원도우 사업자 (예를 들어 RANGE 1 MINUTE)는 스트림을 관계로 변환 

아래의 간단한 예는 선택된 스트림에 데이터를 전송하는 모든 온도 센서에 대한 마지막 순간의 평균 온도를 계산한다.

SELECT AVG(temperature) AS avgTemp, tempSensorId\\ 
FROM temperatureInputStream[RANGE 1 MINUTE]\\ 
GROUP BY tempSensorId\\ 

**CEP 및 IoT**

IoT의 맥락에서, CEP는 자산 또는 백엔드, 또는 둘 모두에 배치될 수 있다. 아래 그림은 후자를 보여준다. 자산에 CEP를 배포하는 것은 (경계가 흐려질 수 있기 때문에, 게이트웨이와 자산 상 비지니스 로직 모두를 포함하는 것으로 여기서 보여진다) 많은 사건이 지역적으로 이용되거나 (자산 자율성) 백엔드로 전달 (사건 전달)되기 전에, 미리 필터링되거나 결합 (센서 융합)될 수 있다는 장점을 갖는다. 또한, 상황에 맞는 데이터 (날씨 예보 등)는 의사 결정 과정에 보다 쉽게 추가될 수 있다.

{{ :파트2_63번그림.png?nolink&300 |}}
                               CEP and Enterprise IoT
                               
**사례 연구: Emerson**

Emerson은 제품을 제조하고 광범위한 산업, 상업 및 소비자 시장에 대한 엔지니어링 서비스를 제공하는 미국의 다국적 기업이다.

The Emerson Trellis™ 플랫폼은 재고 관리, 현장 관리 및 전력 관리를 결합한 데이터 센터 인프라 관리 솔루션이다. 이 솔루션은 저장 장치, 서버, 전원 시스템 및 냉각 장치에 연결하는 로컬 게이트웨이 기기를 사용한다. CEP는 데이터 집계, 필터링, 대규모 환경에서의 실시간 의사 결정을 지원하는 처리를 위한 이 솔루션에서 사용된다. 아래 그림은 솔루션 구조의 개요를 제공한다.

{{ :파트2_64번_그림.png?nolink&300 |}}
                                Emerson Trellis Platform (Source: Oracle)
                                
==== 시나리오 C: 빅데이터 및 기본 분석의 추가 ====

시나리오 C는 솔루션이 매우 큰 데이터 규모로 장기 자산 데이터 분석을 수행할 수 있어야 한다고 가정한다. 여기에서, 경계는 종종 명확하지 않다. 많은 CEP 시스템은 매우 큰 데이터 볼륨으로 확대될 수 있을 것이다. 그러나, 다음에서 볼 수 있는 것처럼, 빅 데이터는 볼륨 이상의 것이다. 

**빅데이터**

빅데이터에 대한 많은 서로 다른 정의가 있으며, 보통 지속적으로 진화하는 개념으로 이해해야 한다. 빅데이터는 일반적으로 정보를 이용하기 위한 의도로 저장되어 반 구조화, 구조화 및 비 구조화 된 매우 많은 양의 데이터를 의미한다. 빅데이터를 "빅데이터"라고 간주하도록 하는 특정 숫자가 있는 것은 아니지만, 일반적으로 페타 바이트, 아니면 엑사 바이트의 데이터를 의미한다. 이러한 ERP 및 CRM 등의 전통적인, 대규모 기업 어플리케이션은 보통 테라 바이트 수준에 아른다. 

빅데이터의 원동력은 전통적으로 구글, 페이스북 등의 대형 인터넷 기업이었다. 예를 들어, 구글의 엔지니어들은 데이터 및 문의가 수천 개의 서버에 분산될 수 있게 만드는 MapReduce의 초기 개념을 정교화했다. 야후와 같은 다른 회사와 함께, 이 개념은 지금 Cloudera (이 챕터의 시작 부분에서 인터뷰 참조)와 Hortonworks와 같은 스타트업 회사에서 지원하는 Hadoop이라는 오픈 소스 상품으로 구현되었다. 이 분야에서 틀림없는 선도 기업인 구글은 또한 Flume과 MillWheel을 기반으로 한 Cloud Dataflow와 같은 차세대 기술을 도입했다.

사용되는 기술에 관계없이, 빅데이터는 기존 RDBMS/OLAP 시장에 많은 변화를 가져왔다. 주요 변화 중 하나는 빅데이터가 고도로 구조화된 유형에서 완전히 비구조화된 유형까지, 많은 다른 유형의 데이터를 관리하는데 매우 적합해졌다는 점이다.

이 인프라를 기반으로, 예를 들어, 새로운 Data Lake 개념은 기업들에게 생각을 거꾸로 뒤집을 것을 제안한다. 먼저 데이터베이스 구조를 정의하고, 그 다음 이 구조에 맞는 데이터를 채우는 것이 아니라, Data Lake는 단순히 모든 종류의 데이터를 저장하고나서, 필요할 때, 필요한 형식으로 이 데이터를 활용한다.
Doug Laney (Gartner)는 많은 사람들이 가장 짧고 일반적인 빅데이터의 정의라고 생각하는 내용에 대한 설명을 처음 제공한 공로가 있다. 그 정의는 3 V로, 양 (volume: 많은 양의 데이터를 처리), 속도 (velocity: 거의 실시간으로 빠른 속도의 데이터 흐름을 처리), 다양성 (variety: 다양한 형태의 데이터를 처리) 이다. 어떤 사람들은 빅데이터 "V"에 변화성 (variability 또는 불일치)과 정확성 (veracity: 데이터 품질)를 추가하기도 한다.

**기본 분석**

빅데이터의 기본 분석은 일반적으로 기술적, 진단적 분석을 포함한다. 기술적 통계는 그룹화 또는 필터링된 데이터 세트에 적용될 수, 합계, 평균, 백분율, 최소 및 최대값, 간단한 연산을 포함한다.

어떤 사람들은 사업 분석의 80 %가 기술적 분석이며, 특히 소셜 미디어 분석이 그러하다고 주장한다 [LI1]. 예시는 페이지 뷰, 게시물 수, 언급, 팔로워, 평균 응답 시간 등을 포함한다.

많은 IoT 프로젝트의 탐구적 성격 때문에, 많은 프로젝트가 처음에 이러한 기술적 분석 (작동 장치의 MTBF (실패 사이의 평균 시간) 등의 통계 분석과 같은 것들에 대한)에 의존할 것이라 가정할 수 있다.
진단적 분석은 또한 기본 IoT 데이터 분석에 중요한 역할을 할 것이다. 몇몇 작동 장치에 문제가 발생한 경우, 신속하게 그것을 해결하기 위해 가능한 한 빨리 근본 원인을 식별할 수 있는 것이 중요 할 것이다. 

**문제 상황에의 NoSQL 추가**
 
비구조화된 빅데이터 저장소 외에도, 문서 지향의 NoSQL 데이터베이스 또한 IoT의 맥락에서 중요한 역할을 하기 시작한다. 다음에서 우리는 IoT, NoSQL, 빅데이터의 주요 측면을 MongoDB 의 CEO인 Max Schireson과의 인터뷰를 통해 논의해볼 것이다. MongoDB는 NoSQL 데이터 관리를 위한 오픈 소스 데이터베이스를 선도하고 있다..

**Dirk Slama**: 무엇이 오늘날의 IoT 현실에서 빅데이터를 만들고, 어떻게 NoSQL가 이에 적합하게 됩니까?\
 
**Max Schireson**: 지난 5년 동안, 우리가 지난 30년 동안 본 것보다 더 많은 데이터 관리에 발전이 있었습니다. 범용 컴퓨팅, 오픈 소스 기술 및 클라우드의 성장으로, 데이터를 수집, 저장, 처리, 분석하는 것이 매우 저렴해졌습니다.

이러한 발전은 작동 작업량을 제공하는 NoSQL 데이터베이스와 분석 작업량을 제공하는 Hadoop의 출현을 보았으며, 이는 일반적으로 기존 기술들을 보완합니다. 

데이터 저장 및 처리 요건처럼 확장성 벽에 충돌하는 대규모 웹 자산으로부터 등장한 이러한 많은 개념은 관계형 기술의 한계를 빠르게 성장시킵니다. 그들은 또한 그들 데이터의 대부분이 깔끔한 행과 열 형식에 적합하지 않아서, 쉽게 관계형 데이터 모델에서 표을 사용하여 관리할 수 없다는 사실을 발견했습니다. 어플리케이션 요건은 급진적으로 변화했고 정적 관계 스키마는 개발자의 민첩성을 방해했습니다. 이는 IoT에서 설계자와 개발자가 직면하고 있는 문제입니다. 자체 데이터 센터 또는 클라우드에서, 저가의 범용 서버와 로컬 스토리지의 집단에 NoSQL 데이터베이스와 Hadoop 클러스터를 확장할 수 있는 능력은, 설계자로 하여금 수십억 개의 센서에 의해 생성된 데이터 볼륨에 관한 문제를 해결할 수 있게 합니다. MongoDB에 의해 사용되는 문서 모델 등 새로운 데이터 모델은 설계자들로 하여금 사건에서 시계열 데이터, 지리적 좌표, 텍스트, 다형성 2진법 데이터까지 구조화된 데이터뿐만 아니라, 반구조화, 비구조화, 다형성 데이터 또한 저장 및 처리 할 수 있게 합니다. 

병렬 프로그래밍의 발전은 계산할 데이터를 이동하여 시간과 비용을 들이기 보다는, 데이터 계산 자체를 이동시켜 복잡한 알고리즘이 클러스터 주위로 분배되도록 하였습니다. 이것은 우리가 이전보다 빠르게 훨씬 더 많은 양의 데이터를 분석 할 수 있음을 의미합니다. 우리가 데이터를 저장, 처리 및 분석하는 방법에서의 이러한 근본적인 변화는 IoT에 데이터 관리를 위한 기반을 제공한다.

**Dirk Slama**: 최신 데이터베이스는 loT에서 무슨 역할을 합니까? 전통적인 데이터베이스가 여전히 맡고 있는 역할이 있습니까? 

**Max Schireson**: 오늘날의 많은 NoSQL 데이터베이스는 loT어플리케이션의 가동적인 부분을 담당합니다. 센서 데이터는 NoSQL 데이터베이스에 의해 수집되고 저장됩니다. NoSQL 데이터베이스 내에서 이것은 온라인 보고 대시보드에 제공하고 행동을 유발하기 위해서, 종종 어플리케이션 미들웨어 내에 만들어진 사업 규칙을 사용하여 조회되고 평가됩니다.

소매 업계에서의 예시를 살펴보면, 상점 내 신호의 네트워크는 상점 내 고객의 위치를 식별할 수 있으며 그들에게 공지를 전송합니다. 예를 들어, 사용자는 구매 목록을 자신의 스마트폰에 작성하고 이것을 운용 데이터베이스에 저장하는 상점 어플리케이션과 공유할 수 있습니다. 상점에 들어갈 때, 상점 어플리케이션은 고객에게 구매 목록에 있는 상품이 강조되어있는 지도를 보여줍니다. 구매 목록에 있던 상품 군이 진열된 위치에 다가가면, 어플리케이션은 고객에게 이것을 알리고 특정 브랜드를 추천해줍니다. 또다시, 그 추천 목록은 운용 데이터베이스에 저장됩니다. 계산하는 지점에서, 시스템은 RFID를 이용해서 장바구니에 있는 모든 물품을 자동적으로 인식하고 영수증을 만들며, 스마트폰으로 결제를 진행합니다. 계산 과정이 끝나면, 가게의 재고 시스템이 자동으로 갱신됩니다.

이 시나리오에서, NoSQL 데이터베이스는 실시간으로 가게 내 고객의 움직임을 저장하고 제품의 정보와 함께 추천을 제공합니다. 더 많은 전통적인 관련 데이터베이스가 청구서 및 송장 발부 관리를 위해 NoSQL 데이터베이스와 결합하여 사용될 수 있습니다. 그래서, 관련 데이터베이스는 종종 새로운 loT 어플리케이션에 통합된 말미의 기업 시스템에서 ‘기록 시스템’의 역할을 하기도 하며, 여전히 loT 어플리케이션에서 사용되고 있습니다. 

**Dirk Slama**: loT에서 Hadoop이 맡은 역할은 무엇입니까? 전통적인 EDW가 아직 역할을 보유하고 있습니까?

**Max Schireson**: 이는 예시를 통하여 가장 잘 설명됩니다. 위에서 언급한 소매상 사용을 진행할 때, 고객의 모든 행동은 NoSQL 데이터베이스 내에 저장됩니다. 그리고 나서, 소셜 미디어나 축적 고객 데이터로부터 의견을 구매하는 웹로그의 클릭 스트림같이, 다른 소스와 함께하는 데이터와 결합된 Hadoopd로 로딩됩니다. 이 모든 데이터 요소들은 고객이 다시 상점을 방문했을 때 실시간 추천을 제공하기 위해서, NoSQL 데이터베이스에 다시 로딩될 수 있는 심화된 행동 모델을 만듭니다.

관련된 데이터베이스처럼, EDW는 새로운 데이터 소스를 지원할 규모의 용량이 제한되어 있으며, 데이터 모델이 대답하기에 구체적으로 설계되어있지 않은 탐사적인 질문을 다루는 데에 효과적이지 않습니다. 이들은 EDW를 대체하기보다는 보조하기 위해 배치된 Hadoop에 의해 제기된 문제입니다.
Dirk Slama: loT데이터 라이프사이클을 관리하기 위해 이런 최신 데이터베이스와 Hadoop 기업 데이터 허브를 어떻게 통합했습니까? 

**Max Schireson**: loT 설계가 NoSQL데이터베이스나 Hadoop과 통합할 수 있는 데에는 구매 스크립트부터 상품화되고 지원된 연결기까지, 여러 방법이 있습니다. 후자의 예시는 Hadoop에 쓰인 MongoDB 연결기입니다. 이는 Apache Hadoop과 선두적인 산업 유통 모두에 적합합니다. Hadoop을 위한 MongoDB 연결기는 사용자들이 Hadoop플랫폼 및 그 기능과 함께 MongoDB 로부터 실시간 데이터를 통합하도록 해줍니다. 연결기는 Hadoop job(MapReduce, Hive, Pig, Impala 등)이 MongoDB로부터 데이터를 HDFS에 복제하지 않고 바로 읽도록 하여, Hadoop 데이터 소스로써 MongoDB를 제공합니다. 그렇게 함으로써, 시스템 사이의 데이터 TB를 이동할 필요가 없어집니다. Hadoop job은 필터로 질문을 통과하여, 모든 목록을 살펴볼 필요가 없고 프로세싱을 빠르게 만듭니다. 또한 MongDB의 문자와 공간 정보를 포함한 색인 기능을 이용할 수도 있습니다. 연결기는 Hadoop job이 존재하는 서류의 증가한 최근 정보를 포함하여 MongoDB에 되돌아가 기록되는 것을 가능하게 합니다. 추가로, MongoDB는 이것 자체로 Hadoop과 같은 물리적 클러스터에서 운영될 수 있기 때문에, 두 플랫폼 사이에는 아주 긴밀한 통합이 발생합니다. 

**Dirk Slama**: 이런 새로운 loT데이터 설계에서 스트림 프로세싱이 하는 역할이 무엇입니까? 여기서 성립된 CEP 개념이 어떻게 적용된다고 생각하십니까? 

**Max Schireson**:  센서, 기기 혹은 자산으로부터 스트림될 때, 존재하는 CEP뿐만 아니라 Apache Strom와 Apache Spark같은 스트림 프로세싱이 결과에 예민하거나 자동화된 행동을 유발하면서 loT데이터에 충돌할 수 있습니다. CEP는 일반적으로 패턴을 찾고 사업 규칙을 적용시키기 위해 데이터를 다수의 소스와 연결시키는, 잘 입증되고 발달된 기술입니다. 이 데이터와 규칙들은 운용 데이터베이스에 저장됩니다. Spark나 Storm같은 스트림 프로세싱은 더욱 최근 의 발달이며, 일반적으로 하나의 데이터 스트림을 작동시키고, 또 일반적으로 데이터, 규칙, 행동을 작동시킵니다. 모두 사용 사례나 개발자 기술에 따라서 loT에서 역할을 갖고 있습니다.

**Dirk Slama**: 통찰력을 얻거나 새로운 프로세스를 자동화시키기 위해 어떻게 loT데이터를 분석하십니까? Hadoop, 데이터베이스, 센서 데이터 스트림에서 이루어집니까?

**Max Schireson**: 이는 세가지 모두에서 이루어질 수 있습니다. 분석은 정보 루트를 가공하는 원 데이터를 사용한 데이터베이스에서 조정되는 실시간 프로세스나 항공(스트림)내의 데이터에 충돌할 수 있습니다. 또, 다양한 소스로부터 받아들여진 데이터를 저장하는 Hadoop에서도 충돌할 수 있습니다.

그래서 이전의 소매업 예시로 돌아가보면, 스트림 분석은 고객이 상점에서 나가는 것을 감지합니다. 데이터베이스는 고객의 상세 정보를 검색하고 이를 선호도나 상품 판촉에 맞춥니다. 고객의 활동과 구매는 추적되고, 데이터베이스에 저장된 후 이 새로운 데이터가 분석 모델을 조정하는데 사용되는 Hadoop에 로딩됩니다. 이 데이터는 다시 데이터베이스로 로딩되고, 고객이 재방문 했을 때, 더 적절한 제안이 제공됩니다. 

**빅 데이터 인프라 구축**
 
시나리오 C는 자산 데이터 스트림의 실시간 분석 대신, 이런 ‘수명이 짧은’ 데이터에 장기 패턴 분석을 수행하기 위해 데이터를 더 오래 유지하는 것을 원한다고 가정한다. 이 시나리오는 스트림 프로세싱과 결합된 빅 데이터 기반을 구축하는 것에 중점을 두고, 이 데이터를 분석하기 위해 사용될 수 있는 몇 가지 기본적인 알고리즘을 소개한다.

Pentaho의 최고 상품 책임자인 Christopher Dziekan은 설명한다. “모든 사람들은 종종 빅데이터의 세가지 V인 양, 다양성, 속도 (Volume, Variety, Velocity)를 지적하며 데이터 (혹은 빅 데이터)를 거대한 가치와 자산으로 바꾸는 것을 염려합니다. 이 V들은 구조적으로 변화를 추진합니다. 그러나, 기업들이 그들의 빅 데이터 기반을 제작하면서 더 많은 V들이 시행됩니다. 빅 데이터 기반은 처음 세 V에 필요한 반응이지만 정확성 (Veracity)과 가치 (Value) 또한 동등하게 고려되어야 합니다.” 빅 데이터의 모든 V를 포함하기 위해서는 큰 범위의 상품 배치를 가능하게 하는 구조와 방법론을 살펴봐야 한다.

정보를 전략적인 장점으로 바꾸려면, 사업 분석과 데이터 통합을 결합시키는 빅 데이터 ‘조직화’ 플랫폼이 필요하다. loT 기기로부터 발생된 데이터를 관련된 데이터와 새로운 데이터 소스 모두와 조합하면서 발전된 분석 기술이 적용된다. 영업부문과 운영상의 결정을 지지하면서 영향을 주려는 순간에 보편적으로 가능하도록, 플랫폼은 존재하는 IT 기반에 적합해야 하며 사업 어플리케이션에 연결되어야만 한다. 
loT 시스템과 적용하여 다른 사용자 집단의 분석적인 필요를 조사하면서, 우리는 어떠한 도구나 저장소도 완벽하게 모든 사용자의 필요에 맞지 않다는 것을 볼 수 있다. 일부는 전통적인 데이터 시장과 데이터 창고를 필요로 한다. 어떤 이들은 정제 공장에 덧붙여, 즉석 데이터 기반에 요구되는 ‘데이터 강’ 저장소를 필요로 할지도 모른다. 또 다른 이들은 기기 상태를 분석하고, 스트리밍 문의를 실행하고, 공지를 알리기를 원한다. 여전히 어떤 이들은 즉석 데이터 변형과 그들의 데이터 과학자들을 위한 특별한 도구의 배열을 필요로 한다.

이러한 다양한 요건을 감안할 때, 우리는 어떻게 모든 요구를 충족시키는 데이터 아키텍처를 구축할 수 있을까? 우선 우리는 전체 아키텍처를 관리할 수 있게 하는 도구의 집합 또는 플랫폼이 필요하다.

**Lambda 아키텍쳐**

하나의 엔진에 일부 이러한 요소를 결합하는 한 가지 방법은 Nathan Marz에 의해 도입된 Lambda 아키텍처라고 알려져 있다. Lambda 아키텍처는 기록 데이터를 모두 저장하는 "배치 층"과 실시간으로 데이터를 처리하는 "속도 층" 및 다른 두 가지 층을 모두가 조회되도록 허용하는 "서빙 층"으로 구성되어 있다. 

{{ :파트2_65번그림.png?nolink&300 |}}
                             Lambda Architecture (Source: Ricky Ho [RH1])
                             
우리는 모든 층이 잘 수행되기를 원하기 때문에, 이름 “배치 층”은 Pentaho의 James Dixon에 의해 만들어진 용어 "데이터 호수"로 여겨지는 것이 낫다 [FO1]. 그리고 속도 층은 "실시간 층"으로 생각되어야 한다.

Lambda 아키텍처는 IoT 시스템에 대한 데이터 아키텍쳐의 몇 가지 문제를 해결하지만, 명시 적으로 모든 기기의 상태를 저장하거나 조회할 수 있는 방법을 제공하지 않는다.

**IoT 데이터 아키텍쳐**

Lambda 아키텍처는 IoT 시스템을 만들기 위한 지도 원칙으로 사용될 수 있다. 

{{ :파트2_66번그림.png?nolink&300 |}}                             
             IoT and big data – integration perspective (based on input from Pentaho)
             
다이어그램에서 당신은 IoT 데이터 아키텍처가 실시간 층, 데이터 호수/기록 층, Lambda 아키텍처의 문의 층을 포함하고 있는 것을 확인할 수 있다. 또한 상태 층 및 융합/변환/정제/ 데이터 마트 층을 보유하고 있다.

Pentaho의 James Dixon은 그의 "상태의 조합" 개념에서 상태 층과 데이터 호수 사이의 중요성을 정교화했다. 이 주제에 대한 블로그 포스트에서 Dixon은 어플리케이션의 데이터의 주요/일반적인 영역뿐만 아니라, 초기 상태와 모든 속성의 변화를 포착할 것을 권장한다. 그는 모든 증가하는 변화 및 사건을 저장하여, 상태 로그의 각 자체 데이터 호수와 함께 여러 어플리케이션에 이 방법을 적용할 것을 주장한다. 이는 "상태의 조합"과 시간에 걸쳐 기업에서 (잠재적으로) 모든 비지니스 어플리케이션의 모든 영역의 상태를 포착하는 결과를 낳는다. 

이 접근법은 많은 상황에 적용될 수 있다. 예를 들어, 전자 상거래 업체는 과거에 어떤 특정 순간 동안, 몇 개의 쇼핑 카트가 열려 있는가, 그 안에는 무엇이 있었는가, 어떤 거래가 진행 중인가, 어떤 항목이 박스 포장되거나 이동 중인가, 무엇이 반품되었는가, 누가 일하고 있는가, 얼마나 많은 고객 센터 전화가 대기 중이고 진행 중인 것은 몇 개인가를 알아낼 수 있었을 것이다.  본질적으로, 이 방법은 추세 분석 및 규정 준수 등의 프로세스를 지원한다.

지금까지, Lambda 아키텍처 제품 또는 그것으로의 IoT 확장을 제공하는 어플리케이션 또는 도구가 만들어지지 않았다. 이는 IoT 구현 팀이 IoT 시스템의 능력, 효율성 및 효과성을 극대화하기 위해, 설계 시 고려해야 하는 것이다. 

==== 시나리오 D: 향상된 분석의 추가 ====
 
빅데이터 관리 및 IoT를 위한 인프라가 구축되고 나면, 다음 단계는 데이터가 분석되는 정교함의 수준을 증가시키는 것이다. 이는 예측적 진단적 분석을 포함한다. 진단적 분석이 최적화된 결과를 달성하기 위해 행동을 인도하려 시도하는 반면, 예측적 분석은 미래의 사건 및 발전에 대해 예측하기 위해 기록 데이터를 사용한다. 

많은 사람들이 실제로 IoT에서 이러한 매우 중요 시나리오를 참조한다. 특히, 산업 IoT 시나리오는 크게 예측적 요지 보수 등의 사용 사례로부터 이익을 얻는다. 

이러한 사용 사례들의 복잡성 때문에, 많은 기업이 필요한 사업과 이러한 사용 사례를 지원하는데 필요한 기술 자문, 데이터 분석 스킬을 결합하는 데이터 과학자처럼, 새로운 직업 역할을 찾고 있다.

예측적 분석은 모델링, 기계 학습 및 데이터 마이닝 등의 여러 상이한 기술을 포함한다. 

**기계 학습**

Tapio Torikka 박사는 Bosch Rexroth의 상태 모니터링 프로덕트 매니저이다. 다음에서 그는 [ML1]과 [ML2]를 기반으로 하는 예측적 분석의 중요 요소인 기계 학습에 대한 설명을 제공한다. 

기계 학습은 알고리즘이 예측을 위해 입력 데이터에 기초한 모델을 구축하는 인공 지능의 분야이다. 명쾌함 없이 프로그램된 지침은 영역 지식이 없거나 거의 없는 경우 문제가 해결될 수 있도록 하는 모델을 만드는 데 사용된다. 아래 그림은 기계 학습 알고리즘을 훈련하고 적용하는 과정을 도시한다. 데이터가 선택된 소스로부터 취득된 후, 예를 들어 그 데이터를 확장하고 누락 값을 입력함으로써, 데이터를 사전 처리해야 한다. 사전 처리 후, 특징 추출 단계는 후속 훈련 단계를 향상시키기 위해 데이터로부터 의미 있는 정보를 추출한다. 훈련 단계 동안 훈련 알고리즘은 자체를 향상시키기 위해 기계 학습 모델의 내부 파라미터를 조정하는데 사용된다. 원하는 정확성 또는 소정 트레이닝 시간에 도달하면, 모델을 저장되고 나중에 미지 데이터로 예측을 위해 사용될 수 있다.
             
{{ :파트2_67번그림.png?nolink&300 |}}
                           Machine learning (Source: Bosch Rexroth)
                           
학습 유형은 다음과 같다.

•	지도 학습\\ 
o	분류된 훈련 데이터가 분류 모델을 구축하는데 사용된다.\\ 
o	예시 어플리케이션: “보통”과 “스팸” 사이의 이메일 분류\\ 
•	자율 학습 \\ 
o	데이터 구조가 분류 없이 학습된다. \\ 
o	예시 어플리케이션: 신용 카드 사기 탐지 \\ 
•	준 지도 학습 \\ 
o	적은 양의 분류된 데이터, 많은 양의 분류되지 않은 데이터\\ 
o	예시 어플리케이션: 이미지 인식. 적은 양의 수동으로 분류된 인터넷에서 이용 가능한 이미지, 많은 양의 분류되지 않은 인터넷에서 이용 가능한 이미지 \\ 

분류된 예시 데이터 (제시된 입력 데이터에 대해 바라는 산출물)가 이용 가능할 때, 지도 학습은 선호된다. 분류된 데이터가 거의 없거나 사용할 수 없는 경우, 준 지도 학습 또는 자율 학습이 사용될 수 있다. 간단한 자율 훈련 과정은 아래 그림에 도시되어 있다. 알고리즘은 모델 (하늘색 원)에 의해 주어진 예측이 입력 데이터 (진한 파란색 원)와 일치하는 방식으로 그것의 파라미터 조정을 시도한다. 이러한 유형의 모델은 비정상행위 탐지에 사용될 수 있다. 즉 모델은 입력 데이터의 주어진 부분이 훈련 데이터와 동일한 구조를 나타낼지 예측할 것이다. 
                                        
{{ :파트2_68번그림.png?nolink&300 |}}       
                   Example for unsupervised training process (Source: Bosch Rexroth)       
                   
두 개의 구별되는 유형의 모형은 기계 학습 과정의 훈련 단계 동안 구축될 수 있다. 

•	분류: 기계 학습모델 (예측)의 산출물은 이산적이다 \\ 
•	회귀: 모델의 산출물은 연속적이다

분류기는 훈련 데이터에 제시된 것처럼 n 개의 카테고리로 데이터를 분리한다. 예를 들어, 이메일을 분류하도록 구축된 분류기는 내용에 따라 정상 또는 스팸 메일로 분류한다. 회귀 모형은 연속 신호, 예를 들면 정의된 목표 신호의 미래 값을 예측하는데 사용될 수 있다.

**사례 연구: 산업 어플리케이션 상태 모니터링을 위한 기계 학습**
 
다음 사례 연구는 Bosch Rexroth의 상태 모니터링 프로덕트 매니저인 Tapio Torikka박사에 의해 제공된다. 

상태 모니터링에서 기계의 상태가 수집된 센서 데이터에 기초하여 평가된다. 이는 사업자가 자산의 유지 보수 작업을 최적화하고 예기치 못한 중단의 위험을 줄일 수 있게 한다 (아래 그림 참조). 일반적으로 이러한 시스템은 연속적으로 작동된다 (이는 온라인 상태 모니터링으로 알려져 있다). 
                                             
{{ :파트2_69번그림.png?nolink&300 |}}                                
                       Machine condition monitoring (Source: Bosch Rexroth)
                       
산업 환경에서 기계는 매우 복잡하며, 그래서 자신의 건강 상태를 평가하는 것은 매우 어려울 수 있다. 많은 기계는 특정 어플리케이션을 위해 특별히 만들어지며, 따라서 고유한 동작을 나타낸다. 또한, 온도 변화 등, 소음, 진동 등 환경의 영향은 센서 신호에 영향을 미칠 수 있다. 설상가상으로, 산업 기계는 기계의 매우 동적인 생산 사이클의 결과로서 부분적으로 고주파 측정을 필요로 하기 때문에, 매우 많은 양의 데이터를 생산하는 경향이 있다. 이러한 특성은 수동으로 개별 센서 신호 또는 간단한 규칙을 검사하여 기계의 유지 보수 상태를 모니터링하는 것이 거의 불가능하다 것을 의미한다.

대용량의 데이터를 저장하는 것은 더 이상 문제가 아니며 사용 가능한 빅데이터 솔루션을 구현함으로써 해결될 수 있다. 훈련 데이터만을 기반으로 모델을 생성하는 기계 학습 알고리즘의 능력은 이러한 데이터를 합리화하는 데 더 큰 문제를 가져온다. 데이터 과학자는 데이터 전처리 및 학습 알고리즘을 위한 분석 파이프라인을 만들 필요가 있다. 또한, 그들은 영역 전문가와 함께 학습 목표를 정의하고 그 결과에 기초하여 작업 제안을 결정하는 책임이 있다. 기계 학습 알고리즘은 일반적으로 많은 연산력을 필요로 하므로 빠른 컴퓨터로의 접속은 중요하다. 

비정상행위 탐지는 데이터 소스에서 비정상적인 행동을 검출하는 일반적인 방법이다. 산업적 맥락에서, 이 방법은 결함이 있는 상태를 나타내는 정상 기계 작동으로부터의 편차를 감지하는데 사용될 수 있다. 비정상행위 탐지는 단지 하나의 기준 상태 (예를 들어, 정상 동작)로부터의 훈련 데이터를 필요로 한다.
실제 예에서, 광산 경영자는 광산에서 광석을 전송하는 데 사용되는 컨베이어 벨트의 Rexroth 구동 시스템의 상태를 모니터링하는 데 관심이 있었다. 이것은 경영자에게 중요한 자산이며, 중단 시간은 수익의 감소로 직결되므로, 항상 작동 중이어야 한다. 센서는 컨베이어 벨트 구동 장치에서 데이터를 수집하기 위해 설치되었다. 원격 빅데이터 시스템은 시스템으로부터 데이터를 저장하는 데 사용되고, 기계 학습 알고리즘은 기계의 일반적인 상태 (예측적 분석의 예)를 나타내는 지표를 생성하는데 사용되었다. 어떠한 고장 데이터도 시스템에서 이용할 수 없었고, 따라서 비정상행위 탐지 알고리즘은 정상적인 동작으로부터의 편차를 나타내기 위해 사용되었다. 

{{ :파트2_70번그림.png?nolink&300 |}}
                               System architecture (Source: Bosch Rexroth)
                               
웹 포털은 데이터를 보고 시스템을 모니터링하기 위해 사용되었다. 아래 스크린샷은 포털의 시각화 화면에서 가져온 것이다. 

{{ :파트2_71번그림.png?nolink&300 |}}                               
                          Example screenshot (Source: Bosch Rexroth)
                       
전기 모터 고장이 구동 장치에서 발생했다. 상기 이미지는 시간의 경과에 따른 비정상행위 탐지 알고리즘 (파란색)과 전기 모터 전류 (적색)의 결과를 보여준다. 전동 모터의 전류가 갑자기 추세에 큰 변화 없이 동작의 몇 달 후에 제로로 떨어진다. 다른 센서 신호들의 수동 분석은 시스템의 어떠한 고장도 나타내지 않았다. 이미지에서 알 수 있는 바와 같이, 청색 곡선 (비정상행위 탐지 알고리즘의 결과)은 모터가 고장나기 전에 정상 수준 (90-100)에서 상당히 벗어나기 시작한다. 이것은 복잡한 데이터 이해하기 위한 기계 학습 알고리즘의 능력을 나타낸다. 수동 데이터를 분석은 대용량의 데이터와 동시에 이용 가능한 모든 센서 신호를 평가하는 것의 복잡성 때문에 불가능한 작업이었을 것이다.

**사례 연구: 항공 엔진 분석**

다음의 사례연구는 Intel 사의 그래프 분석 부서에서 수석 선임 엔지니어이며 총괄 매니저인 Ted Willke로부터 제공되었다.

큰 데이터 시스템은 로그와 기계 원천 데이터로부터의 통계자료를 계산하기 위해 종종 사용된다. 이 정보는 엔지니어들과 데이터 과학자들이 작동을 감시하고, 실패를 확인하고, 수행 결과를 좋게 만들며, 미래 설계를 향상시키기 위해서 사용될 수 있다. 항공 엔진은 세계에서 가장 복잡한 기계 중 하나이다. 항공 엔진들은 물리학의 많은 관점을 하나로 합치고 극대화된 범위의 조건에서 운영해야만 한다 [LYYJL]. 항공 엔진들은 안전에 대한 걱정과 비행에 대한 방해가 발생하기 전, 진단법이 미리 잠재적 실패를 발견하기 위해 자주 관찰된다. 

전통적으로 엔진 상태에 대한 짤막한 묘사와 고장 코드는 비행 중에 얻어져 일지에 기록하고 감시를 위해 지상 기지로 보내진다. 그러나 데이터 전송과 큰 데이터 기술을 사용할 수 있는 규모를 모두 소화할 수 있는 IoT 시스템의 이용 가능성과 함께, 엔진 데이터는 오프-보드에서 넓은 차량 지상 기지로 전송될 수 있으며, 지속적으로 관찰될 수 있고, 깊은 통찰력으로 분석될 수 있다 [DSAR]. 같은 데이터의 전송은 지속적으로 같은 비행 조건 하 (고도, 속력, 기온, 운행 시간 등)의 같은 엔진에 의해 수집될 수 있다. 간단한 통계 자료는 엔진이 예상한 바대로 작동했는지 (설계 설명서와 비교하여) 알아내기 위해 이러한 시간의 연속에 기반을 둔 체 계산될 수 있다. 또한 터빈의 압력, 출구 공기 온도, 연료의 흐름 수준 등의 항목에 문제가 있는 것과 같은, 비정상적인 조건을 발견하는 데에도 간단한 통계 자료는 계산될 수 있다.

Category C 시스템은 변칙과 실패를 발견하는 것은 가능하지만, 결함을 따로 분리하고 높은 신뢰도와 정확성으로 결함 원인을 밝혀내는 것은 가능하지 않을 수 있다 [LYYJL]. 게다가 Category C 시스템은 더욱 분명한 변칙과 지속적인 심각한 결함으로 이어질 수 있는 약한 신호 (미세한 변칙)을 발견하는 것도 불가능할 수 있다. 이것이 기계 학습이 도입된 배경이다 (Category D 시스템). 기계 학습은 연구 (이 사례에서는 항공 엔진)에 기반을 둔 시스템 모델을 창조해 낼 수 있다. 그리고 나서 기계 학습은 시스템 행동을 예측하기 위한 모델을 사용할 수 있다. 기계 학습은 데이터 중심 접근 방법이다. 모델의 원형 (유전적 형태)은 선택돼 예측 정확성을 높이기 위해 "훈련된다". 모델에 의해 패턴은 학습될 수 있기 때문에, 흔한 훈련 과정은 투입물 (무엇을 예측의 기반으로 둘지)과 알려진 산출물 (무엇이 예측이 되었는지)의 쌍을 공급하는 것을 포함한다. 패턴이 학습된 후에는 정확한 예측이 가능하다. 엔진 진단법의 경우에는, 투입물은 엔진의 특징들을 가동하며 예측은 몇몇의 엔진 결함 코드 중의 하나일 수도 있다 ("정상적인" 한가지 코드).

한 가지 연구에서 [LYYJL], 49,900 비행 가치의 데이터는 8가지 엔진 측정으로부터의 1에서 9까지 엔진 결함 조건을 예측하기 위한 기계 학습의 능력의 결정하는 데에 도움이 되도록 분석됐다. 그 기술은 특정한 결함 코드를 유발하는 결함과 초기 결함의 존재를 발견하는 것이 가능한 것으로 보였다.

==== 결론 ====

이 사례 연구에서 살펴본 바와 같이 IoT에서의 데이터 관리에 관해서 매우 다양한 수준의 성숙도가 존재함을 알 수 있다. 우리가 강조한 4가지의 시나리오들은 상품 매니저가 어떤 컴퓨터 시스템의 구성과 기술 해결방안이 그들의 특별한 요구에 부합하는지 결정하는 데에 도움을 줄 것이다. 다음 장에서 우리는 첫째로 산업 어플리케이션에 대한 관점에서부터 기술적인 관점에까지 결론을 제공할 것이다.

**산업 4.0 관점**

Tobias Conz 씨는 Bosch Software Innovations의 산업 팀의 프로젝트 매니저이다. 그는 고급 IT 개념과 오늘날의 혹독한 IT 제조 환경의 교차점에서 일하고 있다. 그는 다음과 같이 그의 경험을 묘사하고 있다:
"제조업과 산업 4.0 분야에서의 데이터 관리는 특히 어렵습니다. 그 이유는 많은 제조업자들이 현재의 환경하에서는 변화가 쉽게 일어나지 않아 투자 주기를 10-15년으로 보기 때문입니다. 한가지 긍정적인 사실은 사실 많은 기계들이 이미 기계 조작을 위해 필요한 방대한 양의 데이터를 모으고 있다는 것입니다. 그러나 산업 4.0전에는 이러한 데이터가 바깥세상에서 실제로 사용 가능하도록 만들 수 있는 요건이 거의 없었습니다. 이것은 우리가 여러 다른 종류들로 이뤄진 인터페이스, 데이터 종류와 프로토콜, 다양한 소프트웨어 버전 등과 같은 일상의 문제를 다뤄야만 하는 매우 기본적인 데이터 통합 시나리오를 바라보고 있다는 것을 의미합니다.

대부분의 기계 데이터가 더 높은 수준으로 통합되지 않았었기 때문에, 통합에 대해 훨씬 이전부터 다뤄왔던 은행과 보험 회사들과는 다르게 우리는 이 공간 속에서 훨씬 높은 수준의 이질성을 찾고 있습니다.  
데이터 마이닝, 스트리밍 처리 과정과 같이 새로운 데이터 관리 개념은 물론 제조업과 산업 4.0이라는 맥락에서 매우 흥미로워 보입니다. 이 공간의 특수성에 의해, 우리는 이중의 전략을 추천합니다: 개인 기계 데이터는 어디서든 적용되어 사용될 수 있는 데이터 마이닝 측면에서는 귀중한 발굴 물이라고 할 수 있습니다. 하지만 이러한 목적을 위한 모든 기계의 통합은 거의 불가능합니다. 이것이 우리가 복수의 기계들의 처리 한도를 동시에 유효하게 만들 수 있는 근 실시간 스트리밍 처리 과정을 개발하고 있는 이유입니다. 우리는 이를 한 기계 종류마다 한 번에 하고 있습니다. 이는 어떤 기계 종류가 가장 잘 작동하는지 살펴보기 위함입니다. 가장 큰 어려운 점은 우리가 통합을 위한 시간과 비용 효율 방안을 찾아내야 한다는 것입니다."

**일반적인 추천**

MongoDB의 CEO로써 Max Schireson 씨는 떠오르는 IoT 공간에서뿐만 아니라 NoSQL와 일반적인 큰 데이터 기술의 전개에서도 큰 통찰력을 얻을 수 있었다. 아래의 인터뷰에서 그는 프로젝트 매니저를 위한 몇몇 소중한 추천을 제시하고 있다. 

**Dirk Slama**: 무엇이 큰 데이터와 loT 와 관련되어 가장 큰 위험 요소라고 할 수 있습니까? 또한 어떻게 회사들이 이러한 위험요소를 제한하고 회피할 수 있습니까? 

**Max Schireson**: loT와 큰 데이터는 현재 매우 큰 이슈가 되는 주제입니다. 따라서 프로젝트의 첫 번째로 사업 목표에 대해 생각하는 것보다 기술에 직접 뛰어드는 것이 더 쉬울 수 있습니다. 하지만 기술보다 훨씬 중요한 것은 여러분들이 사업이 무엇을 얻으려고 노력하는지 생각하며 이해관계자를 하나로 묶을 필요가 있다는 것입니다. 사업 부문, 당신의 고객들, 당신의 협력자들, 그리고 유용한 기술을 인도하기 위해 일 할 IT 팀들과 같은 이해관계자들 말입니다. 심지어 경쟁자들도 상호 연결성과 통합이라는 측면에서 보면 loT 환경 시스템에서의 중요한 요소가 될 수 있습니다. 여러분들은 loT 그 자체에 대해 언급하면서 이해관계자 특히 고객들을 찾아가서는 안될 것입니다. 여러분들은 loT가 인도할 수 있는 장점들에 대한 대화들의 큰 틀을 짜 볼 필요가 있을 것입니다.

프로젝트가 조직 내의 대부분 고위급에 대한 전략적인 지원 방안을 가지고 있는 것은 중요합니다. 또한 선구자들의 성공과 실패로부터 교훈을 얻기 위해 시간도 가져야 합니다. 탐험적인 자세를 가지는 것이 중요합니다. 미래 사업 모델이 어떤 형태를 띨지 예측할 수 있는 사람이 거의 없는 것처럼 인터넷의 초기 시대에 가장 성공적인 사업 모델이 어떤 현태를 예측한 사람이 거의 없었다는 사실을 기억하세요. 

당신은 기술 향상이 필요할 것입니다. 현재의 직원을 데리고 그들을 훈련시키는 방안이든 회사 밖의 제삼자의 전문 영향력을 이용하든 어떤 방안으로든 말입니다. 우리는 정의된 사용 사례를 가지고 있고 장치와 데이터의 부분집합을 위해 사용되는 시범 프로젝트를 시작할 것을 추천합니다. 평가하고, 최대한으로 활용하고, 다시 평가하고. 만약 프로젝트가 증명된 개념과 훈련된 직원들과 함께 성공한다면 더욱 야망을 가지셔도 될 것입니다.   

**Dirk Slama**: 누가 loT로부터 가장 혜택을 받을 수 있을까요? 혹은 누가 가장 손해를 볼 수 있을까요?
 
**Max Schireson**: 몇몇 사람들은 때때로 단순히 "어떤 것"의 발명자가 혜택을 볼 것이라고 생각합니다. 이것은 완전히 잘못된 생각이죠. 고객들의 행동을 감시해서 보험료를 최대한으로 할 수 있는 보험 회사나 식품의 생산에서부터 소비에 이르는 식품 공급 사슬을 최대한으로 활용할 수 있는 소매업자들을 생각해보세요. 경제학자들은 75%의 회사들이 회사의 고위급에 현재 loT를 도입할 계획을 세우고 있다고 추정하고 있습니다 [Ref2]. loT와 새로운 사업 모델을 만들 수 있는 데이터/통찰력을 사용하는 회사들과 이를 이용해 그들의 고객들에게 더 다가설 수 있는 회사들이 가장 많은 것을 얻어 갈 것입니다. 현실을 외면하는 기업들은 결국 도태되고 말 것입니다.

**Dirk Slama**: 큰 데이터와 loT의 적용을 위해 자신들의 전략을 개발하고 있는 독자들에게 한 말씀해주신다면

**Max Schireson**: 무엇보다 위에서 언급했던 토론 부분에 대해서 다시 말씀드리고 싶습니다. 팀이 그들이 사용하려고 계획한 기술들을 골랐다면 일반적인 최선의 방안들이 있을 것입니다. 그것들은 아래와 같습니다. 기술을 이해하기 위한 시간 (훈련, 독해, 그리고 회의)을 늘려주세요. 새로운 프로젝트의 개발을 돕기 위해 판매회사들과 서비스 공급자들로부터 자원을 사로잡으세요. 발전이 진행됨에 따라, 테크 토크, 해카톤, 프로젝트 위키 등과 함께 최선의 방안과 진행 상황을 공유하세요. 그리고 나서 복수의 프로젝트가 진행 중일 때 최선의 방안이 일상화되도록 CoE를 만들고 확장하세요. 이 공간에는 매우 많은 혁신이 진행 중이고 매우 많은 기술 선택이 존재하기 때문에 여러분은 여러분의 마음을 열 필요가 있습니다. 단지 당신의 ERP 플랫폼을 15년간 성공적으로 운영했기 때문에 데이터 관리 플랫폼을 선택하는 것은 좋은 생각이 아닙니다!      

==== II. IoT와 프로세스 관리 ====

loT 솔루션에 대해 이야기할 때 프로세스 관리는 아마 첫 번째로 언급되는 솔루션은 아닐 수도 있다. 이것은 많은 loT 프로젝트가 처음에는 자산을 얻고 연결된 장치들을 얻는데 어려움을 겪고 그리고 나서 백엔드에 기본적인 서비스들을 구축하기 때문일 것이다. 또한 이번 장에서 의논된 바와 같이 많은 프로젝트들은 국내로 들어오는 사건 흐름을 분석하고 관리하는데 혹은 기본적인 분석을 형성하는데 초점을 맞출 것이다. 하지만 우선 초기의 loT 해결 기능이 갖춰지고 연결 장치와 유입되는 데이터 측면에서 시스템이 규모를 확장한다면, 프로세스의 효율성은 결국 아주 중요한 주제가 될 것이다. loT 솔루션에 관해, 장치들과 자산으로부터 초래된 개인적인 사건들, 복합적이고 간접적으로 연관된 사건 (이전 장의 Complex Event Processing 참고)들을 가리키는 더욱 진보된 분석에 의한 결과에 의해 많은 사업 프로세스는 촉진될 것이다. 

예를 들어, 예측 보전에 대해 생각해보자. 논의된 바와 같이 Rexroth 사례 연구에서 정교한 기계 학습 알고리즘은 기계 고장이 임박한 사실을 나타내는 상황을 구별할 수 있도록 데이터 센서를 적용할 수 있다. 당신은 말 그대로 센서 네트워크 전문가와 데이터 과학자들이 이러한 유발점을 어떻게 확인할 수 있는지 몇 주간 머리를 맞대고 고민하는지 확인할 수 있을 것이다. 그러나 다음은 무엇일까? 유압식의 요소인 액체에서의 문제로 인해 ACME 광산의 컨베이어 벨트에서 87.25%의 확률로 다음 주의 월요일부터 수요일까지 고장이 발생할 것이라는 정보로 당신은 무엇을 할 수 있는가? 그리고 이러한 정보의 형태가 당신의 기계요소들을 사용하는 수만의 고객들에게 한 주에 수백 번 들어간다면 당신은 무엇을 할 것인가? 이것이 사업 프로세스 관리 (BPM)가 도입된 정확한 배경이며 이는 이러한 요구 사항들이 효과적으로 진행되며 현장 서비스가 가능할 뿐 아니라 활용될 수 있도록 보장하는데 도움을 준다고 할 수 있다.  

또 다른 예를 한번 들어보자. eCall 서비스는 우리가 이미 많이 다뤄본 부분이다. 그렇다. 처음 프로젝트가 초점을 맞춘 부분은 정확하게 잠재적인 고장 상황을 발견하고 또한 이런 정보를 처리할 수 있도록 콜 센터에 보내는 것이었다. 그리고 이것은 적어도 콜 센터 매니저의 관점에서는 정확히 BPM이 시작한 부분이다. 그들은 두 가지에 초점을 맞추었다: 첫째로 적절한 프로세스 실행. 이것은 조난 요청을 분류화하고 적합한 언어 기술과 함께 이를 콜 센터에 전송하는 것을 의미한다. 두 번째로 콜 센터 활용. 오늘날 대부분의 콜 센터는 다양한 서비스를 지원한다. 효율적인 콜-전송 프로세스는 비단 SLAs에 대한 보장뿐만 아니라 수익성을 보장하기 위해서도 매우 중요해졌다.     

예를 들어, 수십만의 네트워크 요소와 수백만의 고객들을 기반에 둔 큰 커뮤니케이션 네트워크를 설립하고 운영하고 있는 거대한 통신회사를 생각해보자. 통신회사를 운영하기 위한 TM Forum의 청사진인 eTom은 네트워크 관리에서부터 판매, 생산 활성화 그리고 고객 서비스 요청과 같은 고객 관련 프로세스까지 수백 가지의 비판적인 사업 프로세스를 구분할 것이다. 결국 loT는 그리 달라지지 않을 것이다.
따라서 BPM과 loT에 관해 우리 자신에게 질문해야 되는 흥미로운 질문들은 다음과 같다.

•	프로세스 자동화 관점에서 첫째로 다루어져야 할 loT 솔루션 상의 가장 비판적 프로세스를 우리는 어떻게 구분할 수 있을까?\\ 
•	자동화는 얼마에 가능해질 것인가(혹은 바람직할 것인가)?\\ 
•	언제 프로세스 자동화를 위해 BPM 툴을 사용해야 하는가? 또한 언제 하드 코드 사업 논리와 같은 다른 접근법들을 사용해야 하는가? \\ 
•	무엇이 이러한 프로세스의 본질인가? 예를 들어 조직화된 것, 조직화되지 않은 것 등 \\ 
•	장치에 대한 소프트웨어 프로비져닝과 관리는 BPM 프로세스인가 아니면 어플리케이션 특징인가?\\  
•	어떤 종류의 툴이 사용돼야 하는가? BPM 엔진, 작업 흐름 관리 툴, Jira와 같은 공동 작업 툴?\\ 
•	나의 loT 어플리케이션 플랫폼이 내장된 BPM 엔진을 가지고 있다면 이는 이점인가? \\ 
•	기술적인 통합은 어떤 형태를 띠는가 (Device2Process 그리고 Process2Device)?
 
이러한 질문들과 이에 대한 잠재적인 해답에 대해 좀 더 잘 이해하기 위해서 어떻게 프로세스 관리가 잠재적으로 loT 솔루션에 맞춰질 수 있는지 좀 더 자세히 살펴보자. 아래의 수치는 이전 장 (데이터 관리)에서의 AIA에 기반을 둔 AIA이다. 이는 결국 가장 중요한 것은 프로세스는 데이터, 사건들, 그리고 분석의 결과에 기반을 두어 작동돼야 하기 때문이다. 

아래에 있는 예시에서, 우리는 한편으로는 M2M/loT 어플리케이션 플랫폼 (다음 장 참조) 또 다른 한편으로는 현존하는 기업 어플리케이션 시스템 (ERP, CRM, PLM등) 사이의 BPM/작업흐름/사례 관리 요소를 배치하였다. 우리가 Device2Process와 Process2Device라고 부르는 패턴은 자산과 장치로부터 나온 투입물에 기반을 둔 새로운 프로세스를 시작하는데 책임이 있다. 똑같은 패턴은 만약 잠재적으로 프로세스 흐름을 바꿔야 하는 장치로부터 나온 연관된 사건들이 출현한다면 현존하는 프로세스의 예를 신호화할 책임도 있다. 이와 유사하게 프로세스는 분석 엔진의 결과에 의해 시작될 수도 있다. 이러한 사용 사례는 예측 분석 알고리즘이 기계 고장이 잘 발생하게 된다는 결론에 도달하고 이러한 상황을 다루는 고객 서비스를 가질 수 있는 프로세스를 시작하는 예측 보전이 될 수도 있을 것이다.

{{ :파트2_72번그림.png?nolink&300 |}} 
                 BPM, workflow, and case management in the context of the IoT
                 
==== 프로세스 다양성 ====

우리가 BPM, 작업 흐름, 사례 관리를 구분 짓고 있다는 사실을 주목해보자. 이것들은 복잡한 해결방안들에서 보통 다른 보조 프로세스 혹은 매우 다른 특징들을 가지고 있는 프로세스 부분이 있다는 사실을 다루기 위해 오랫동안 개발된 세 가지 다른 개념들이다. BPM은 ERP, CRM, PLM등과 같이 다수의 후방 시스템의 조직화를 포함하는 아주 강력한 프로세스 자동화로 여겨진다. 작업 흐름 시스템은 인간 작업 흐름에 좀 더 초점을 맞추고 프로세스 자동화에는 덜 초점을 맞춘다. 마지막으로 사례 연구는 유연한 작업 흐름 관리와 같은 데이터 중심적 ("사례 폴더") 관점을 더해주고 있다.

만약 당신이 토론의 도입부에서 다루었던 Distributed Assets Lifecycle 상의 loT의 영향력에 대해서 다시 생각해본다면, 다른 보조 프로세스의 본질을 이해하고 그들을 지원하기 위한 올바른 프로세스 관리 개념을 선택하는 것은 명백히 중요할 것이다. 예를 들어 loT 제품의 활성화는 BPM에 기반을 두어 이행될 수 있는 전형적인 고도로 자동화된 프로세스이다. 서비스 프로세스는 보통 많은 인간 간의 상호작용을 필요로 한다. 따라서 그들은 작업 흐름 관리에 의존할 것이다. 몇 가지 상황에서는 사례 관리는 지원 서비스의 흥미로운 부분이 될 수 있다. 이는 사례 관리가 관련된 데이터와 사례에 속한 맥락 정보를 수집하는 데에 매우 유용하기 때문이다. 예를 들어, 서비스 기술자는 고객 역사자료에 대한 세부적인 정보와 특정 제품에 대한 묘사를 제공하는 것뿐만 아니라 어떤 지원 운송수단과 어떤 지원 툴을 그들이 사용해야 하는지, 어떤 시간에 그들이 고객을 방문해야 하는지까지도 알려주는 정보 패키지를 얻을 수 있을 것이다.

{{ :파트2_73번그림.png?nolink&300 |}}
                           Example of complex process
                           
마지막으로 프로세스와 사건들 사이의 지도 제작은 꽤 복잡할 수도 있고 많은 유연성을 필요로 할 수 있다. 산업상의 컨베이어 벨트를 포함하는 시나리오를 기반으로 하는 위의 예를 한번 봐보자. 이는 이전 데이터 관리 장에서 확인한 Bosch Rexroth에서 제공된 사용 사례와 유사하다. 컨베이어는 백엔드에 기계 학습 접근법을 지원하는 센서를 구비하고 있다. 하나의 주요 구성 요소에 문제가 있다는 분석 엔진 신호와 이러한 부분이 2-3주 안에 고장 날 것을 암시하는 예상을 추정해보자 (1). 콜 센터 대리인이 고객에게 접촉하는 것과 다음 2-3주 내에 예약을 잡는 등의 일을 만들어내는 프로세스 (혹은 사례, 혹은 작업 흐름)는 착수돼야 한다 (2). 이제 고객 장소에 대한 상황이 더 악화된다고 추정해보자: 우리의 CEP (Complex Event Processing) 요소는 요컨대 예측된 것보다 훨씬 상황이 빠르게 악화되었다는 상황을 의미하는 일련의 사건들과 연관성이 있다 (3). 내부적인 규칙은 이러한 상황에 기반을 두어 컨베이어 벨트가 더 이상의 손상을 피하기 위해 즉시 중단될 것임을 결정한다 (4). 프로세스는 이제 반드시 콜 센터 대리인에게 비상조치에 대해 동의하기 위해 고객들에게 긴급하게 다시 연락하도록 충고해야만 한다 (5). 

이러한 시나리오는 매우 유연한 방식의 프로세스를 다룰 수 있는 loT 환경이 얼마나 중요해질 것인지 보여준다. 이것을 위한 한가지 좋은 방안은 Adaptive Case Management  (ACM)이라는 사례 관리의 가장 유연한 버전을 사용하는 것이다.

==== 전문가 의견 ====

아래 항목에서 우리는 Opitz Consulting에서 나온 Torsten Winterberg 씨와 이 주제에 대해 이야기를 나눠 볼 것이다. Torsten 씨는 이 책의 선임 격인 Enterprise BPM에 기반을 둔 BPM 방법론을 개발하고 유지하는 Enterprise BPM Alliance (www.enterprise-bpm.org)의 매우 활동적인 구성원이다.

**Dirk Slama**: Torsten 씨, loT 세계에 프로세스 관리를 적용하는 것이 왜 중요한지 저희에게 설명해 주실 수 있으십니까?
 
**Torsten Winterberg**: 효과적인 프로세스 관리는 당신이 loT 프로젝트에 대해 생각해 볼 때 처음으로 생각나는 것은 아닐지도 모릅니다. 사실, 수많은 Aris 프로세스 분석가와 당신의 Arduino 전문가들을 한 방에 같이 놓는다는 것은 좋은 아이디어가 아닐 수 있을 것입니다. 하지만 저는 후방 프로세스의 진화와 큰 통신회사들의 시스템으로부터 배울 수 있는 것이 있다는 것을 믿습니다. 그들은 지난 20여 년간 마지막 고객들이 사용한 수만의 원격 장치들을 다루는 방법을 학습해왔습니다. 그들의 사업 규모를 고려해 볼 때, 그들은 차라리 일찌감치 프로세스의 효율성을 검토할 수밖에 없었습니다. 이것은 판매와 상품 배열부터 상품 활성화 고객 서비스 프로세스에 이르기까지 매우 다양한 프로세스의 종류들을 포함합니다. 바로 지금, 대부분의 loT 계획은 실제로 통합 장치와 기본 서비스 기능을 이행하는 것과 같은 기본적인 문제 해결에 초점을 맞추고 있습니다. 그러나 이러한 계획들이 규모를 키워 가면 갈수록, 그들은 똑같은 문제에 직면할 것입니다. 그들의 관련 마지막 고객들뿐만 아니라 현장의 수많은 장치들을 관리하는 것은 프리 필터링 사건들과 다른 정보들의 효과적인 방법을 찾는다는 것을 의미합니다.  이것은 자동화된 의사 결정을 도와 사업 규칙을 효율적으로 사용하고 단지 자동화될 수 없는 그러한 문제들이 인간 지원 직원에 도달함을 확신하기 위함이라고 할 수 있습니다. 

**Dirk Slama**: BPM 사물의 측면과 장치 세계를 연결하는 가장 쉬운 방법은 무엇일까요?

**Torsten Winterberg**: loT 세계에서 자동화된 프로세스로부터 장점을 얻기 가장 쉬운 방법은 "흥미로운 시나리오"를 발견해내고 그러한 시나리오를 다루기 위한 프로세스를 직접적으로 적용하는 것입니다. 예를 들어 기온에 민감한 상품들이 저장되어 있는 몇몇의 창고들을 생각해 봅시다. 만약 기온 장치가 한계점을 초과한 사실을 발견한다면 이는 백엔드에 그 문제를 처리할 수 있는 프로세스를 유발할 수 있을 것입니다. 이러한 프로세스는 몇 가지의 사전 정의된 수단을 적용하는 방법으로 솔루션을 찾으려고 할 수 있습니다. 그것들이 실패한다면 사람들은 그 문제에 대해 살펴봐야 된다는 사실을 눈치챌 수 있을 것입니다. 이러한 과정이 훨씬 더 좋은 또한 훨씬 효율적인 작업 환경으로 이끌 것입니다; 고용자들은 아마 자동화된 문자 메시지 혹은 발생 전화와 같은 수단으로 편차에 대해 반응하면 될 것입니다.

**Dirk Slama**: 그렇군요. 매우 간단한 예시네요. 사실 좀 더 복잡합니다. 프로세스는 사례는 장치로부터 나오는 여러 가지 다른 들어오는 신호에 대해 반응해야만 할지도 모릅니다. Torsten 씨는 BPMN에 대한 이러한 문제점을 어떻게 해결할 수 있을까요?

**Torsten Winterberg**: 글쎄요. BPMN 엔진은 신호들을 다룰 수 있는 꽤나 괜찮은 내장된 메커니즘을 가지고 있습니다. 따라서 프로세스 사례는 많은 들어오는 사건들에 대해 대응할 수 있을 것입니다. 그러나 물론 문제를 다루는 이러한 방식이 BPMN의 전문 분야는 아닙니다. 프로세스 모델은 다른 사건들의 복잡한 사업 규칙을 통제하기 어렵게 만드는 많은 사건을 다루는 상징물들과 함께 오염되는 경향을 보이고 있습니다. 환경의 변화는 언제나 BPMN 모델의 변화를 필요로 하게 만들 것입니다. 요약해보면 이러한 시나리오의 복잡성과 환경의 변화에 대한 부족한 적응력은 BPMN 패러다임을 지나치게 긴장시키게 만들 것입니다. 그러므로 ACM이라고 불리는 BPM 규율을 사용하는 것을 저희는 추천합니다.

**Dirk Slama**: ACM의 의미에 대해서 좀 더 설명해주실 수 있으신가요? 

**Torsten Winterberg**: 간략하게 ACM은 Adaptive Case Management을 의미합니다. 그리고 프로세스 모델이 너무 복잡해졌을 때, 당신이 단순히 간단한 해피 패스 모델을 가지고 있지 않을 때 혹은 당신의 좋은 BPMN 모델을 오염시킬 수 있는 많은 수의 예외 "코드"를 다룰 때 BPMN의 매우 흥미로운 대책일 것입니다. ACM은 BPMN 활동 사이의 이행에 대한 요구를 제거하고 일련의 의사 결정 규칙에 대한 이행을 대체합니다. ACM은 귀납적입니다. 예를 들어 자동차 안에 있는 네비게이션 시스템처럼 목표는 확실하나 길(프로세스 그 자체)는 불확실하고 단계적 확대들로 가득 차 있습니다. 반면 BPMN은 사전 정의된 길과 함께 있는 철도 시스템처럼 보일 수 있습니다. 만약 당신이 지름길을 원하거나 새로운 길을 원한다면 당신은 현존하는 길이나 미리 지어진 새로운 길을 사용해야 할 것입니다. IT 세계에서 "구조화되지 않은 프로세스"란 ACM의 감각이라 할 수 있을 것입니다.

**Dirk Slama**: 그렇다면 ACM은 구조화되지 않은 프로세스에 사용될 수 있는 규율이라고 할 수 있군요. 그러면 이것이 loT에 대해서는 어떻게 도움을 줄 수 있을까요? 

**Torsten Winterberg**: "구조화되지 않은"이라는 용어는 보통 뭔가 혼돈 상태를 의미합니다. 하지만 여기서는 아니죠. 많은 프로세스들은 목표 중심적이거나 사례 중심적입니다. 그리고 지식 노동자들이 이러한 목표를 달성하기 위해 선택한 길은 보통 엄격하게 정의되지 않고 그들의 정보의 평가를 고려하는 것입니다. 예를 들어 의료 사례를 생각해봅시다: 환자는 병원에 들어올 것이고 몇몇의 장소에서 다양한 사람들의 전문지식에 의해 이동될 것입니다. 프로세스 관점으로 보면 환자는 병원에 들어오고 몇몇 구조화되지 않은 것들이 발생하며 최종 목표는 환자가 다시 병원을 떠나는 것이며 (물론 건강하게) 마지막으로 청구서가 보내지는 것일 겁니다. 

loT의 응급상황과 함께, 이러한 사례의 종류들도 진화할 것입니다. 원격 상태 모니터링은 환자 상태와 관련된 실시간 사건들과 같은 임상 사례들에 추가적인 투입물을 제공할 수 있을 것입니다. 사용 기반 보험 (UBI)은 보험 회사들이 미래에 보험 관련 사례들을 어떻게 다룰지에 대해 영향력을 발휘할 것입니다.

ACM에서 당신은 늘 그렇듯이 지식 노동자들이 "사례"를 살펴 보기 위해 사용한 당신의 포탈에  계기판을 가지고 있습니다. UI는 지식 기반 노동자들에 의해 실행될 수 있는 근본적인 지식 기반의 현재 상태에 의해 좌우되는 그러한 활동들을 강조하고 있습니다. 통합 플랫폼과 함께 하는 공동 작업에 있는 ACM 엔진은 다른 장치의 모든 종류의 들어오는 사건들을 쉽게 수집할 수 있습니다. 이와 같이 적응 가능한 변화를 의미하면서 이러한 사건들은 근본적인 지식 기반을 바꿀 수도 있고 바꾸지 못할 수도 있습니다. 따라서 몇몇 신호 사인은 " 녹색" 혹은 "적색"이 될 수 있으며, 들어오는 사건들에 영향을 주는 사업이 가져야만 하는 것에 따라 몇 가지 종류의 활동들은 가능하거나 불가능할 수 있습니다. 임상 사례에 대한 관계는 간단합니다. 메시지와 함께 각각의 장치들은 임상 기기 또는 다른 가치를 측정하고 의사로부터 적정한 반응을 의미하고 확정하는 임상 실험처럼 보일 수 있습니다.

**Dirk Slama**: 흥미로운 접근법이네요. 그런데 이러한 접근법이 BPM 세계에서 너무 복잡한 메커니즘을 소개하는 방법이 되지는 않을까요? 

**Torsten Winterberg**: 그럴 수도 아닐 수도 있다고 말씀드려야겠네요! 시스템의 유저에게 ACM은 삶은 훨씬 쉽게 만든다고 할 수 있습니다. 이는 작업의 초점이 사업 사례에 맞춰져 있고 프로세스에서 일하는 사람이 가장 효과적인 방향으로 프로세스를 수행할 수 있는 새로운 자유를 가지고 있기 때문입니다. 다시 한번, 당신이 네비게이션 시스템을 사용하는 방법과 이것을 비교해 보십시오. 목표는 타깃 주소에 접근하는 것이지만 당신은 가능한 최선의 길을 택할 수 있는 자유를 가지고 있습니다. 대부분의 경우에 이는 명령어로 번역된 길로 주어지겠지만 확실하지 않은 환경은 유연한 반응과 길의 변화를 필요로 할지 모릅니다. 이러한 "지식 노동자"측의 사용의 용이성은 ACM 엔진 사례를 설계하는 데 있어서 더 높은 복잡성을 필요로 할 것입니다. 그러나 오늘날의 ACM 엔진들은 사업 규칙 엔진들을 통합하고 있으며 이러한 근본적인 규칙들의 투명성을 통해 더 나아지고 있습니다. 그리고 이러한 사실은 이러한 복잡성이 더 이상 큰 장애물이 아니게 만들었습니다..

**Dirk Slama**: 우리는 ACM이 Device2Process 솔루션을 위한 매우 귀중한 접근법이라는 것을 배웠습니다. 하지만 그 반대는요? Process2Device와의 연관성도 찾아 볼 수 있을까요

**Torsten Winterberg**: 사례를 성공적으로 완성하기 위해서, 당신은 아마 사례 데이터 사례 상황 그 자체를 포함하는 바깥 세계를 다루게 될 작업을 수행할지도 모릅니다. 그것들은 대체로 명확하고 안정적이기 때문에 당신은 이러한 작업 뒤에 있는 작은 BPMN 프로세스를 사용할 것입니다. 한가지 예로 피 분석은 명확하지만 피의 가치와 관련하여 나온 결과와 필요한 반응들은 명확하지 않은 것입니다. 따라서 질문은 프로세스 (BPMN에서 실행 가능한)가 위의 예와 같이 당신의 Process2Device로서의 "어떤 것"과 교류하는 것인 가능한 지입니다. 이것이 함축적으로 의미할 수 있는 것은 무엇일까요? 우리는 이것을 밝혀내기 위해 해야 할 일이 여전히 몇 가지 남아 있다는 사실을 생각해 볼 수 있습니다. 물론 프로세스는 경고 가치의 한계점을 조정하는 것과 같은 어떤 것과 상호 교류할 수 있습니다. 그러나 우리는 프로세스가 아마 단순히 사건이나 메시지를 내보낼 것 같다고 생각할 것입니다. 그리고 나서 몇몇 다른 시스템 (loT 클라우드 같은)에 의해 소비되고 결국 개별 장치들과 상호 작용을 할 것이라고 생각할 것입니다. 상황은 앞으로 몇 년간 매우 빠르게 진화할 것이고 따라서 당신의 컴퓨터 시스템의 구성은 적응 가능해야 하기 때문에, 일반적으로 당신은 당신의 프로세스와 장치 세계 사이의 지나치게 가까운 결합을 원하지는 않을 것입니다.

요컨대, 수동으로 자료를 편집하기 위해서 너무 많은 데이터와 복잡성을 갖는 것은 분석하고 반응하는 것이며 목표 중심적이고 사업 프로세스 수행하기 위해 유연한 방법을 갖는 기원은 명확한 보조 작업과 장치들의 통합을 위한 BPMN의 보조 프로세스와 함께 ACM 접근법을 위한 탄탄한 사례들을 만들 것입니다. 우리는 이러한 통합된 접근법이 오늘날 BPM 이행의 많은 결점들을 해결할 수 있기 때문에 매우 기쁩니다. 현재 거기에는 많은 수의 여전히 예측하지 못한 새로운 사업 모델들을 기대하면서 또한 크고 새로운 전문가들이 대중 데이터의 이용 가능성을 통한 기회에 영향력을 발휘할 준비가 되면서 골드러시 분위기가 다분합니다.

==== 4. 사용자 상호작용 ====

이 부분은 아직 끝나지 않았고 다음 판의 책에서 통합될 것이다.

==== 5. 보안 ====

무서운 핵(hack)과 loT와 관련된 보안 침입에 대한 부족 현상은 없다. Stuxnet을 예로 들어보자. 이것은 보고된 바에 따르면 컴퓨터 산업 PLCs와 SCADA 시스템을 공격하기 위해 설계된 컴퓨터 웜으로써 이란의 핵 연구 프로그램에 의해 사용된 수 백 개의 원심 분리기를 파괴하기 위해 사용되어 지곤 했다 [ST1]. 아니면 환자들을 50피트 밖으로 보내버릴 수 있는 높은 볼트의 충격을 가능하게 만들었던 특정 종류의 심박 조율기의 핵(hack)을 고려해 보자 [DR2]. 아니면 Charlie Miller와 Chris Valasek이 어떻게 DEF CON 해킹 회의에서 전자 조종, 제동, 가속, 엔진 그리고 두 가지의 잘 알려진 자동차 종류들의 다른 특징들을 그들이 조종할 수 있는지 보여줬는지 살펴봐 보자. 우리가 만든 솔루션을 가까스로 보안 장치를 한다면 loT가 유일한 성공적인 방법이 될 것이라는 것은 꽤 명백해 보인다. 많은 사람들은 복잡하고 분배된 IT 시스템을 100% 안전하게 보호하는 것이 절대 가능하지 않을 것이라고 동의할 것이다. 따라서 생각할 수 없는 부분을 생각하고 결과를 미리 준비하는 것이 문제의 또 다른 부분이다.

loT 분야의 많은 선두 회사들이 loT 보안에 대해 매우 사전 대책을 강구하는 접근법을 취하고 있다. 예를 들어 Tesla Motors라는 전기 차 제조업체는 취약성 테스트와 그들의 차의 보안을 감독하기 위해 Kristen Paget라는 유명한 선량한 해커를 고용했다. 그의 첫 번째 작업으로, Paget은 차량을 조종할 수 있는 소프트웨어 상의 보안 취약점을 규명하는 데 필요한 더 많은 해커들을 고용하기 위해 Tesla 차량을 DEF CON 회의에 가져갔다 [DR1].

==== 보안 IoT 솔루션 ====

아래에서 우리는 loT 상의 다른 보안 개념들을 살펴봄으로써 토론을 시작할 것이다. 아래의 수치는 우리의 Asset Integration Architecture에게 주요 보안 개념을 보여준다. 각각의 것들을 우리가 앞으로 간단히 의논해 볼 것이다.

**자산 하드웨어 보안 (1)**: 보통 데이터 서버에의 물리적 접근을 막는 것은 상대적으로 쉽다. 하지만 자산들이 현장에서 효율적으로 사용되고 자산 하드웨어의 물리적 접근을 막는 것이 종종 불가능해질 것으로 보이기 때문에 loT에서는 상황이 매우 다르다고 할 수 있다. 여기서 한가지 중요한 접근법이 TPM (Trusted Platform Module)이다. 이것은 장치에 암호화 키를 통합함으로써 하드웨어를 보호하기 위해 설계된 암호 보조 처리기를 보안하기 위한 국제적인 기준이다. Escrypt [ES1]로부터 나온 CycurHSM 같이 Hardware Security Modules (HSM)은 자동차 산업에 종종 사용된다. HSM은 보통 CPU 코어, 다른 종류의 데이터 저장소, 메모리 보호 단위, 메모리 부호 매김 단계, 센서 그리고 암호화 액셀러레이터로 구성되어져 있다. HSM은 보통 결함을 발견하기 위한 활동적인 센서들과 글리치 공격과 같은 물리적 공격에 대한 대책을 지원할 것이고 사이드 채널 공격에 대항하여 더 강화된 암호화 이행을 이용할 것이다 [ES1]. .
자산의 효율적으로 배치된 보안 특징에 기반을 둔 소프트웨어는 방화벽, 포트 필터링, 신분 확인, 중요 요소 관리, 그리고 안티 바이러스 기능성들을 종종 포함한다. loT 상에서의 가동하는 기술에 대한 전통적인 서버 사이드 보안의 확장은 McAfee와의 전략적인 인수로 loT에서 그들의 결합된 역량을 매우 확장시킨 Intel 사와 같은 회사들에게는 매우 일반적인 전략이다.

**보안 의사소통 (2)**: 자산과 백엔드 사이의 의사소통 보안을 확인하는 것은 다는 아니더라도 많은 loT 솔루션을 위해 필수적이다. 대부분의 솔루션들은 어플리케이션 층 (Transport Layer Security 또는 TLS와 같은)에 또는 IP 프로토콜 층 (Internet Protocol Security 또는 IPsec 같은)에 있는 암호화 기술들을 활용한다. 이러한 기술들에서 한가지 중요한 차이점은 그들이 큰 규모의 장치를 위해 행정 수뇌부에 영향력을 미치는 방화벽과 횡단 NAT를 어떻게 다루는 가이다. 또한 암호화와 더해 Transparent Network Substrate (TNS) 기술들은 인증 부분을 다루고 있다.

**자격 관리 (3)**: 자격은 Transport Layer Security (TLS)의 중요한 부분이라고 할 수 있다. 자격증은 공개 키의 소유권을 입증하기 위한 전자적 문서이다. 자격증은 키와 그것의 주인 정체성, 그리고 자격증 내용이 올바르다는 사실을 증명하는 디지털 서명에 대한 정보들을 포함한다. 큰 규모의 loT 환경에서 효과적인 자격 관리는 필수적이기 때문에 자산들과 장치들은 그 자신들이 진짜임을 증명하고 백엔드에서 안전하게 의사소통할 수 있을 것이다.

**AAA (4)**: 종종 단순하게 AAA라고 불리는 입증, 허가, 그리고 회계업무는 어플리케이션에의 접근을 조종하고, 정책을 강화하고, 사용을 감사하기 위해서 설계된 틀이라고 할 수 있다. loT에서 이것은 매우 중요해질 것이다. 어떤 건설 장비의 조각이 건설 장소를 떠나도록 요청하고 있는가? 현재의 스케줄에 따르면 이러한 장비가 그렇게 하도록 허가하고 있는가? 만약 그렇다면, 그것이 남긴 것에 대해서 메모를 해보자. 

**백엔드 보안 (5+6)**: 마지막으로 우리는 백엔드와 사회 기반 시설에 대한 보안 장치를 강구해야만 한다. 이것은 Denial of Service (DoS) 공격, Intrusion Detection Systems (IDS), 방화벽, 패킷 필터링, 그리고 리버스 프록시에 대한 방지를 포함할 것이다. 

{{ :파트2_74번그림.png?nolink&300 |}}
                              Security concepts in the IoT – mapped to the AIA
                              
==== 보안 설계 ====

앞서 본 바와 같이, loT 시스템 보안에 사용될 수 있거나 사용되어야 하는 다양한 기술과 개념들이 존재한다. 솔루션 개발자의 관점에서 볼 때 중요한 것은, 보안은 시스템의 근본적인 부분에서부터 구축되어야 한다는 점이다. 이는 보안 설계 [SD1]라고도 한다. 보안 설계는 시스템에 대한 공격은 물론, 보안 취약점이 발견되었을 때 받게 될 영향을 줄인다. 또 다른 중요한 특징은 모든 것이 가능한 한 최소한의 권한만으로 수행된다는 것이다.

"loT 프로젝트 시작" 부분에서 우리는 교차 업무에 있어서 보안이 중요하다고 추천한다. 이를 분명히 하는 것만이 loT 프로젝트에 포함된 다른 모든 교차 업무의 보안 설계를 해낼 수 있는 방법이다.

==== IoT 보안 테스트 ====

우리가 보안 설계의 아이디어에 대해 믿는 만큼, 모든 loT 프로젝트는 확실한 보안 테스트 전략이 필요하다. 가장 좋은 방법은 보안 침투 테스트만을 위한 하나의 팀을 조직하는 것이다. 여기에는 두 가지 방법이 있다. 첫째는 시스템에 대한 전반적인 지식을 갖고 있는 팀 구성원에 의해 수행되는 화이트 테스트이고, 둘째는 좀 더 현실적인 시나리오를 위해서 시스템 내부에 대한 지식이 없는 외부의 제삼자에 의해 수행되는 블랙 테스트이다.

Open Web Application Security Project (OWASP) Top Ten은 웹 어플리케이션의 잠재적 리스크와 관련된 가장 인기 있는 목록이다. OWASP는 또한 연간 발생하는 보안 문제 top 10개의 목록도 발행하기 시작했는데 [OW1], 이 목록에 근거하여 InfoSec Institue는 loT솔루션을 위한 구체적인 테스트 전략을 제시하였다 [1S1]:

•	안전하지 않은 웹 인터페이스를 사용하는 loT 장치 테스트: OWASP에 따르면 다음과 같은 loT 장치의 경우, 각 장치가 제공하는 웹 사이트를 검색할 때 장치 별 표준 포트 스캐너를 사용하기를 추천한다.\\ 
	초기 설치 중에 변경되어야 하는 경우\\ 
	복잡한 비밀번호가 강요되는 경우\\ 
	교차 사이트 스크립팅을 검토하는 경우\\ 
	SQL 주입\\ 
	사이트 교차 요청 위조에 취약한 경우\\ 

•	인증/승인 부분이 취약한 loT 장치 테스트: 이는 다음과 같은 표준 테스트를 포함한다.\\ 
	설치 초기 비밀번호의 취약성 테스트\\ 
	비밀번호 완전성 인식 테스트(비밀번호를 입력하지 않았거나 모두 입력하지 않은 경우)\\ 
	(암호화되지 않았거나 불완전하게 암호화된 비밀번호를 찾는 경우에) 프록시와 스니퍼의 사용여부 테스트\\ 

•	안전하지 않은 네트워크 서비스를 사용하는 loT 장치 테스트: 이 테스트에는 Tenet, FTP, Finger, TFTP, SMB와 같은 중요 서비스를 찾기 위한 침투 테스트 툴(Nessus 또는 Open VAS)과 같은 포트 스캔 툴(Nmap)이 포함된다.

•	암호화 전송이 되지 않는 loT 장치 테스트: 커뮤니케이션을 적절히 암호화하는 기본 테스트

•	개인 정보 문제와 관련된 loT 장치 테스트: 개인 정보(ex.집주소), 금융 정보(ex. 신용카드번호) 건강정보 등

•	안전하지 않은 클라우드 인터페이스를 사용하는 loT 장치 테스트: loT솔루션의 백엔드 서비스는 타 웹 어플리케이션이 직면하는 문제와 같은 문제에 직면할 수 있다. 따라서 loT장치 테스트 역시 HTTPS사용 여부 체크, 사용자명 수집 또는 무차별 대입 시도와 같은 기본적인 테스트를 포함한다.

•	안전하지 않은 모바일 인터페이스를 사용하는 loT 장치 테스트: 몇몇 loT 장치는 무선 접속기기(WAPs)와 같이 작동하므로 보안테스트가 필요하다.

•	보안 설정이 불완전한 loT 장치 테스트: 비밀번호 정책 시행, 데이터 암호화, 그리고 접속 레벨의 다양화와 같은 기본적인 점검

•	안전하지 않은 소프트웨어/펌웨어를 사용하는 loT 장치 테스트: 이 테스트는 모든 원거리 소프트웨어 업데이트가 안전하게 암호화되었는지 확인한다. 이 테스트를 통해 loT 장치가 악성코드에 감염되는 것을 방지할 수 있다. 

•	물리적 보안이 취약한 loT 장치 테스트: 이 마지막 테스트는 저장매체의 제거, 저장된 데이터의 암호화, USB와 같은 포트의 물리적 보호, 분해 위험, 그리고 불필요한 포트의 불능화 등을 체크하는 것이다.

==== IoT 안전 프로그램 ====

위에 언급된 기술과 프로세스는 loT 보안에 있어 중요한 요소들이다. 그중 하나만으로는 보안이 유지되기 어렵다. 복잡하고 높은 수준의 보안이 요구되는 loT 솔루션을 개발하는 사람들은 특히 loT 안전 프로그램의 실행에 주목해야 할 것이다. I Am the Cavalry와 같은 조직을 예로 들어보자. I Am the Cavalry는 자동차의 산업분야의 컴퓨터 보안과 공공 안전의 교차점에 집중하는 작은 조직이다. 2014년 DEF CON 해킹 회의에서 공개적으로 그들은 5가지 자동차 사이버 안전 프로그램을 제시하였다 [FS1]. 이 프로그램은 다음과 같이 구성되어 있다.

안전에 기반을 둔 설계 (1): 이러한 프로그램은 안전한 소프트웨어 개발 라이프 사이클을 발행해야 하는데, 다음과 같은 주요 구성요소를 사용해야 한다. ISO, NIST와 같은 표준, 추적 가능한 하드웨어, 소프트웨어 공급체인.\\ 
타 그룹과의 협력 (2): 이 프로그램에는 타 그룹 연구진과의 합동 연구 결과를 공개하는 정책도 포함된다. 여기에는 버그 보고에 대한 "안전과 보상" 시스템을 통해 긴밀한 협업을 이끌어 내는 것도 필요하다.\\ 
증거 확보 (3): 차량은 안전 조사를 용이하게 하기 위해 임의 조작에 대한 과학적으로 탄탄한 증거 확보 기능을 지원해야 한다.\\ 
보안 업데이트 (4): 치명적인 버그에 대비하기 위해 즉각적이고 믿을 수 있으며 안전한 차량용 원격 소프트웨어 업데이트가 가능해야 한다. 이는 매우 중요하다. 왜냐하면 소프트웨어 사용이 증가하면서 더 많은 업데이트가 필요하게 되었고 수백만 대의 차량이 출고되는 만큼 리콜은 대안이 될 수 없기 때문이다.\\ 
분할과 고립 (5): 중요 시스템과 그렇지 않은 시스템을 나누기 위해 물리적, 논리적 고립과 같은 수단이 실행되어야 한다.\\ 

==== IoT 개인 정보 보호 정책 ====

 드디어, 우리는 loT 개인 정보 보호 정책을 살펴보게 될 것이다. 비록 이것은 정확하게 기술 프로파일이라고 할 수는 없지만, 악의적 공격을 막기 위해 탄생한 것이 보안이라는 점에서 볼 때 loT 솔루션 공급자는 개인 정보 보호 정책에 대한 정의를 우선 내릴 필요가 있다. loT 보안 연구소에서는 Google Nest 개인정보 보호정책을 만들었는데 이는 다음과 같이 정의된다 [IL1]:

•	개인 정보 보호 정책은 찾기 쉬워야 한다. 예를 들면 각 페이지마다 링크가 들어가야 한다. \\ 
•	개인 정보에 대한 요약은 사용자를 대상으로 하는 것이지 변호사들을 위한 것이 아니다. \\ 
•	개인 정보 보호 정책은 보안에 대한 것이어야 한다.\\ 
•	구매자가 개인 정보에 대한 사용과 보유를 결정할 수 있어야 한다. 즉, 누가 볼 수 있으며 얼마나 사용될 수 있는지는 구매자가 정해야 한다.\\ 
•	웹과 장치의 개인 정보 보호 정책은 분명하게 나누어져야 한다.\\ 
•	큰 데이터 시대인 만큼 데이터는 발표되기 전에 익명으로 만들어져야 한다.\\ 
•	개인 정보에 대한 접근은 Q&A 메일과 같은 방법이어야 한다.\\ 

많은 구매자들에게 있어 개인 정보 보호 정책은 제품을 사고 이용하려는 의지를 결정할 것이다. loT솔루션 공급자들은 이러한 정책들을 정의하고 실행하는데 큰 노력을 기울일 필요가 있다. 

==== 요약과 전망 ====

선두적인 보안 솔루션 공급업체인 ESCRYPT의 책임자 Thomas Wollinger 박사와의 대화를 통해 loT보안에 대한 전망을 들어보자.

**Dirk Slama**:  loT어플리케이션 보안 솔루션의 주요 요소에는 무엇이 있을까요? 

**Thomas Wollinger**: 암호와 관련된 기초적인 요소들이 loT 어플리케이션을 보호하는데 사용될 수 있겠습니다. 경우에 따라 다양한 보안 목적이 있을 수 있겠는데, 이를 따르는 것이 적절하겠지요. 예를 들면, 전송된 데이터에 대한 기밀 유지에는 데이터 암호화가 사용될 수 있겠습니다. 또한 어플리케이션은 데이터 조작으로부터 보호받을 필요가 있습니다. 이는 전자서명과 같은 메커니즘을 사용함으로써 가능합니다. 

모든 암호 관련 기초 요소는 어플리케이션의 라이프 사이클 내내 보안 키에 의해 관리되어야 합니다. 보안 키 관리는 필수적입니다. 보안 키는 무작위로 설정되어야 하며 그 분배와 저장 역시 중요합니다.

**Dirk Slama**: 이 모든 것이 오늘날 가능한 겁니까? 아니면 앞으로도 보완되어야 할 점이 있을까요?

**Thomas Wollinger**: 기술은 이미 갖추어져 있습니다만, 특정한 목적을 가진 loT 어플리케이션에 적응하기 위해선 조정이 필요합니다. 첫째로, 암호 기초 요소와 보안 키 길이와 같은 변수는 loT 플랫폼에 맞춰 세심하게 선택되어야 합니다. 대부분의 loT 플랫폼은 연산 능력과 메모리가 꽤 제한적입니다. 더욱이 loT어플리케이션은 PC와는 반대로 사용자 중심이 아닌 장치 중심 방식으로 작동합니다. 따라서 사용자 인증 대신, 장치 인증 방식이 사용되어야 합니다. 하지만 장치나 플랫폼에서 특별히 요구되는 것이 무엇이든지 간에, 보안이란 단순히 장치나 어플리케이션의 수명에 맞춰 더해질 수 있는 특성이 아닙니다. 정말 안전한 장치를 만들려면 라이프 사이클을 통틀어서, 이를테면 설계부터 시작해서 실행까지 모든 부분에 있어 보안을 신경 써야 합니다. 각 단계마다 보안 관련 적정 수준과 장애물이 있기 때문입니다.

**Dirk Slama**: 어떻게 프로젝트 책임자가 loT 보안을 단계적으로 다룰 수 있을까요? 체크리스트는 어떤 식일까요?

**Thomas Wollinger**: 일단 보안 분석을 수행하는 것이 중요합니다. 모든 가능한 보안 위협과 그에 따른 적절한 대안을 찾기 위해서지요. 이 분석을 통해 보안에 필요한 사항, 예를 들면 암호 기초 요소, 프로토콜, 변수 등을 끌어낼 수 있겠습니다. 그러면 이것들이 설계에 반영될 것입니다. 이어서 설계된 시스템이 실행되고 테스트 되겠죠. 코드 리뷰와 보안 테스트는 loT 시스템이 고객에게 전달되기 전에 의무적으로 시행되어야 합니다.

**Dirk Slama**: 프로젝트 책임자는 loT를 위한 보안 테스트를 어떻게 수행해야 합니까?

**Thomas Wollinger**: 보안 테스트는 어플리케이션 개발에 있어 필수적인 부분이 되어야 합니다. 게다가 개별 테스트, 통합 테스트, 퍼즈 테스트를 포함한 침투 테스트 또한 고려되어야 합니다.  

**Dirk Slama**:  절대적으로 안전한 솔루션은 없다고 가정했을 때, 긴급사태에 대한 대책은 어떠해야 합니까? 프로젝트 책임자는 솔루션을 시행하기 전에 무엇을 고려해야 할까요?

**Thomas Wollinger**: 목적을 확실하게 하기 위해서 그리고 오해를 피하기 위해서 말씀드리자면, 앞으로도 절대 100% 안전한 솔루션은 없을 겁니다. 소프트웨어에는 버그가 있을 수 있습니다. 몇몇은 찾기 매우 어려워요. 더욱이 미래에 새로운 취약점들이 떠오를 수 있습니다. 예를 들면 도서관에 버퍼 과부하가 걸리는 것처럼요. 그래서 시스템은 안전한 펌웨어 업데이트를 갖추고 있어야 합니다. 가장 편리하고 비용이 적게 드는 방법은 무선 업데이트입니다. 이때 장치가 읽어 들이기 전에 펌웨어가 인증되어야 합니다. 업데이트가 합법적인 공급자로부터 제공되었는지 확인이 되어야 악의적인 공격으로부터 방어할 수 있기 때문입니다. 다시 말씀드리자면, loT장치 보호에 있어서 암호 기본 요소와 보안 키 관리는 중요 요소입니다. 우리는 또한 자주, 말하자면 매년 전체적으로 보안 분석을 실행하기를 추천합니다. 이를 통해 가장 최근의 공격 벡터를 고려할 수 있습니다.

==== 6. 플랫폼과 가용성 ====

지금까지 우리는 M2M/IoT 커뮤니케이션 서비스, 데이터 그리고 loT 프로세스 관리, loT 보완 그리고 사용자와의 호환 등 loT 게이트웨이와 최신 장치에 대해 살펴보았다. 이 장에서 여러분은 위에 언급한 기술이 결합되어 탄생한 새로운 기술 및 플랫폼에 대한 관점을 넓힐 수 있을 것이다. 또한 이를 통한 loT솔루션의 확장과 가용성에 대해서도 살펴보자. 우선 우리는 클라우드와 loT 어플리케이션의 관계에 대해서 공부할 것이다. M2M/IoT 어플리케이션 시스템, 산업 데이터 수집 플랫폼 그리고 내부화 기술에 대한 논의는 그다음이다.

==== I. IoT와 클라우드 ====

IT업계에 종사하는 사람들은 loT와 클라우드는 불가분의 관계에 있다는 것을 알 것이다. 그러나 일반 사람들은 loT와 클라우드 사이에서 발생할 수 있는 프라이버시와 보안 문제를 걱정한다. 하지만 어떠한 경우에도 클라우드 방식의 도입은 loT 프로젝트에 있어서 가장 중요한 포인트이다. 왜냐하면 그것이 loT 솔루션의 설계와 실행 그리고 운영에 상당한 결과를 가져올 것이기 때문이다.

이 부분에 대해서 우리는 클라우드 서비스 산업의 개척자인 Salesforce를 주목할 필요가 있다. 1999년에 설립된 이 회사는 클라우드 CRM 시장을 조성하였고 15년에 걸쳐 사업을 40억 달러 규모로 성장시켰다. 앞서 우리는 기계 사회와 인터넷 사회에 대한 논의를 하였다. Salesforce가 판매와 서비스에 집중한 순수 인터넷 기반 솔루션에 집중하였던 만큼, 인터넷 사회의 청사진을 제공할 수 있을 것이다.
                              
{{ :파트2_75번_그림.png?nolink&300 |}}    
                                 AIA for the IoT and cloud       
                              
우리는 Salesfore의 전략 조사 부사장인 Peter Coffee 씨와의 작업으로 상당히 적절한 관점들에 관한 많은 것을 찾아내었다. IoT와 Ignite 자산 통합 구조에 관해 정리한 그의 견해를 위의 도표를 통해 확인할 수 있다. 복잡한 주제의 이해를 돕기 위해 클라우드/IoT 자산 통합 구조(AIA)의 가장 중요한 요소들을 숫자로 표시하였고, 이를 통해 아래의 인터뷰에서 필요한 정보를 쉽게 찾을 수 있다.         

**Dirk Slama**: 어떤 사람들은 클라우드가 집중화에 크게 기여한다고 주장합니다. 반면에 IoT에 대해서는 완전 반대로 몇 십억의 분산된 기기들에 거쳐 퍼져있는 데이터와 논리를 통한 분산화에 큰 역할을 한다고 하죠. 그렇다면 IoT는 클라우드를 없애버리는 건가요?   

**Peter Coffee**: 저는 클라우드가 집중화에 크게 기여한다고 생각하지 않습니다. 실제로 사람들이 로컬 문서 작업을 공동 문서 관리로 이동시키는 사례를 보면, 일정량의 집중화가 있었다는 건 인정하는 바입니다. 그건 맞는 말이지만 클라우드의 가장 중요한 측면은 아닙니다. 클라우드에 있어 가장 중요한 점은 획득되고 관리되어야할 물리적 자산 측면에서, 클라우드는 당신이 IT에 대해 더이상 생각하지 않아도 되도록 해준다는 것입니다. 클라우드는 어플리케이션 서비스를 수립하는 것에 관한 것입니다. 이는 어플리케이션 프로그래밍 인터페이스들(APIs)의 조율, 데이터 요청 그리고 고도로 장소 독립적인 방법에서 기계 전원을 사용하는 행위를 통해 이루어집니다. 우리가 일하는 방식은 완전히 분산되어 있습니다. 왜냐하면 이제는 모든것이 클라우드에서 추상화되고 분산되기 때문입니다. 예전에는 데이터 센터 바깥에서 무언가를 가져오는 것은 어려운 일이었습니다. 클라우드는 분산입니다. 따라서 이 관점에 의하면, IoT는 계속되는 분산화 노력에 대한 다음 단계일 뿐이죠! 

**Dirk Slama**: 그것에 대한 핵심 동인은 무엇인가요?

**Peter Coffee**: 과거에 컴퓨터는 희소했지만, 이제는 어디서나 찾을 수 있습니다. 또한 연결성은 희소했지만 이젠 어디에나 존재합니다. 오늘날 희소한 것은 데이터와 당신이 데이터를 공유하는 파트너에 대한 신뢰입니다. 오늘날 유효한 이슈는 바로 부가가치 또는 당신이 안전하게 데이터를 운영하면서 얻게될 가능성입니다. 기업 클라우드의 분야는 대규모 사업장과 정부기관에 서비스를 제공하는 것입니다. 그리고 그것은 동력, 공간, 네트워크 연결의 가능성이 허용하는 능력에 관한 전세계적 자원을 이용하면서 이루어집니다.   

**Dirk Slama**: 그렇다면 당신은 신뢰성에 대한 문제를 어떻게 생각하시나요? 

**Peter Coffee**: 그 문제는 데이터가 처음에 아무런 방어도 없이 만들어진다는 핵심에서 시작합니다. 데이터를 주변 세상으로부터 보호해줄 것은 아무것도 없으며, 이 사실은 데이터의 신빙성 등을 증명합니다. 우리는 데이터 베이스를 만들었습니다. 그곳에서는 완벽한 추적 가능성이 존재하지 않는 단 하나의 데이터 독립체도 찾을 수 없습니다. 각각의 독립체를 위해서 메타 데이터(3)와 같은 것을 이용할수 있도록 하는 것은 전통적 데이터 베이스와는 완전히 다른 것입니다. IoT의 관점에서 보자면, 이는 핵심 자산 마스터 데이터뿐만 아니라 자산과 관련된 고객과 같은 맥락 데이터에게도 적용됩니다. 그리고 그것은 우리의 멀티테넌시 능력(5)을 위한 기반이 됩니다. 안전하게 샌드박스된 동일한 시스템 안에서 안정적으로 수천 개의 역할들을 운영하는 능력은 우리같은 클라우드 솔루션에 대한 핵심 차별 요소입니다. 그리고 우리는 훌륭한 CRM이자 서비스 관리 플랫폼입니다. 그러나 멀티테넌시는 이것을 클라우드 안에서 가능하게 해주며 신뢰성 있는 데이터 관리의 기술적 기초를 제공합니다. 
      
**Dirk Slama**: 자산과 기기에서 가져온 데이터를 적절한 맥락에 놓는 것도 중요한 것인가요?

**Peter Coffee**: 맞습니다. 웨어러블 기기 회사인 Jawbone의 Andrew Rosenthal은 기기에서 데이터를 가져오는 것은 사실 흥미로운 것이 아니라고 말했습니다. 중요한 것은 그것을 맥략 안에 위치시키는 것입니다. 데이터는 당신이 그것을 이야기 주변에 놓기 시작할때 비로소 의미를 갖게 됩니다. 당신이 몇 발자국 걸었는지는 중요하지 않습니다. 당신의 부인과 비교했을 때 당신이 오늘 얼마나 많은 칼로리를 소모했는지 말할 수 있는 것, 그것이 이제 흥미로운 것입니다! 

**Dirk Slama**: 그러면 Salesforce의 IoT 전략은 무엇인가요? 

**Peter Coffee**: Salesforce는 혼합 전략 회사가 아닙니다. 우리는 항상 소프트웨어 회사가 아닌, 클라우드 서비스 제공자였습니다. 그러므로 우리의 사업 전환에 대해서는 논의할 필요가 없습니다. 우리는 클라우드로 태어났습니다. 최근 우리 회사는 MIT 테크놀로지 리뷰의 “가장 스마트한 회사 50” 중 Illumina, 테슬라 모토스, 구글 그리고 삼성과 함께 탑 5안에 뽑히기도 하였습니다. MIT가 우리를 이렇게 평가한 것은 우리의 도구들은 앞으로 기업들이 사물 인터넷에서 새로운 데이터를 통합할 수 있도록 돕는데 매우 중요한 역할을 할 것이기 때문입니다 [MI 1]. IoT는 엄청난 양의 다차원적인, 텍스처 데이터를 만들어낼 것입니다. 우리에게 이것은 굉장히 값진 기회가 되어 우리의 고객들이 그들의 고객이 스스로 고민하기도 전에 그들을 즐겁게 할 것을 찾아낼 수 있도록 도울 것입니다.    
 
그리고 우리는 물론 기기 회사도 아닙니다. 곧있음 애플 워치를 내놓을 애플을 예로 들어봅시다. 애플 워치는 각각의 데이터를 창출하는 어플리케이션의 생태계를 불러 일으킬 것입니다. 이것이 우리의 관심사입니다. 또 Scania의 예를 살펴봅시다. 그들은 최근에 트럭 운전자들에게 이동 거리, 연료 정보, 운전자 지원 점수를 제공하는 Scania 워치를 출시하였습니다 [SC1]. 이것은 브랜드 구축과 고객 충성도 측면에서 탁월하다는 점과 동시에 웨어러블 기술 가능성을 보여주는 훌륭한 예입니다. 모든 종류의 웨어러블과 통합할 수 있도록 하는 적절한 도구를 제공하는 것이 우리 IoT 전략의 핵심 분야입니다. 우리는 최근에 Salesforce 웨어 개발자 팩을 출시했는데, 이것은 Salesforce1 플랫폼에 연결할 수 있는 웨어러블 어플리케이션을 구축하고 디자인할 수 있는 도구들을 모은 것입니다.    

**Dirk Slama**: 그럼 산업 IoT는 어떻나요? 

**Peter Coffee**: 그 부분도 매우 중요합니다. 그러나 이것도 결국 자산과 기기로부터 가져온 데이터를 맥락에 맞게 위치시키고 서비스를 더하는 것으로 정리됩니다. 다시 말하자면, 데이터 수집, 분석, 요약 및 행동을 취하는 것은 새로운 개념이 아닙니다. 저는 석유 가스 산업에서 일한 적이 있는데요, 그곳에서 저는 정제 과정에서 첫번째 디지털 통제 시설이 등장하는 것을 1980년대에 목격하였습니다. 처음 시작은 매우 작은 데이터에 불과했던 것이 적절한 맥락을 더하면서 얼마나 많은 부가가치를 만들 수 있는지를 알면 당신은 놀랄 것입니다. 유전을 수백 개의 펌프로 채우고 수십 마일 밖으로 확산시키는 것. 펌프가 실제로 작동 하는지 여부를 아는 것이 가장 유용한 것입니다. 그래야 당신이 현장 작업자들에게 필요한 무언가를 하라고 지시할 곳의 방향을 알려줄 수 있을테니 말입니다. 또는 풍력 터빈 수리를 예로 들어 봅시다: 이는 100피트 높이의 타워를 올라가야 합니다. 따라서 두번 올라가야 하는 것보다는 처음부터 정확한 도구와 지시 사항을 가지고 올라가는 것이 좋을 것입니다. 

이것이 바로 우리같은 클라우드 기반 서비스가 IoT에서 할 수 있는 역할입니다: IoT에서 데이터를 과정들로 옮기고 그것을 맥락 안에 위치시키는 것 (4). 그래서 만약 텔레미터 데이터가 우리에게 풍력 터빈이 수리가 필요하다 말한다면, 우리는 작업 가능한 서비스 기술자를 찾고 그에게 어떤 장비를 가지고 가야할지 알려주며 수리 트럭 중에 어떤 것을 사용할지를 말해줄 수 있습니다. 이론적으로, 이러한 과정은 무언가가 고장나기 전에도 실제로 가능한 것입니다. 왜냐하면 고장은 고객에게 있어 한 번 일어나면 다시는 고쳐질 수 없는 경험이기 때문입니다. 그래서 수리 상황을 예측하는 능력을 개발하는 것 또한 중요해질 것입니다. 

**Dirk Slama**: 클라우드 어플리케이션 플랫폼의 어떤 특징이 이러한 IoT 시나리오를 가능하게 하는 건가요? 

**Peter Coffee**: 그건 전적으로 클라우드 엔진 APIs에 관한 것이라고 생각합니다 (6). 많은 클라우드 어플리케이션은 전통적으로 웹 기반의 UI에 설치되어 왔습니다. 이후에는 모바일 기능이 추가되었습니다. 그러나 많은 경우에 IoT에서 첫번째 접촉은 인간 사용자에 의한 것이 아니라 기계나 다른 종류의 자산에 의해 이루어집니다. 그렇기 때문에, 자산에서 나오는 데이터가 자동적으로 처리되는 것이 매우 중요합니다. 그리고 이때 클라우드 엔진 APIs로의 직접적인 접근이 필요합니다. Salesforce는 모든 클라우드 어플리케이션을 오픈 APIs로 이송하는 것을 2013년에 모두 완료했습니다. 이것을 통해 우리는 다른 종류의 어플리케이션들을 종합할 수 있는 모바일과 웹 UI를 개발할 수 있는 상당한 유연성을 확보할 수 있습니다 (7). 그리고 저는 이것이 IoT 준비의 측면에서 한 획을 그은 것이라고 생각합니다.  

**Dirk Slama**: 데이터 습득과 기기 통제를 위해 필요한 기술은 어떻나요? 

**Peter Coffee**: 저는 우리가 그 분야의 시장에 진출할 것이라 생각하지 않습니다. 우리는 시장 생태계에서 [최근 Digi에 인수된] Etherios와 같이 이러한 종류의 기술을 제공하는 많은 파트너들을 가지고 있습니다. 저는 또한 IoT가 아직 개발되지 않은 환경에는 적용되지 못한다는 것을 깨닫는 것이 중요하다고 생각합니다. 우리가 기존의 ERP 시장에서 시작한 상황과 비슷한 예로, 이것은 부가가치에 관한 것이지 대체에 관한 것이 아닙니다.   

**Dirk Slama**: 그러면 IoT 통합 레이어가 서비스로서의 플랫폼 (2) (Paas) 모델과 같은 것인가요? 당신의 회사와 같이 서비스로서의 소프트웨어 (1) (SaaS) 모델을 통합하는 그런 PaaS말입니다.

**Peter Coffee**: 네 맞습니다. “라스트 마일” 상황을 예로 들어보죠. 누군가 이것을 해결해야 하지만 그것은 항상 프로토콜 연결, 데이터 스트림 분석 등의 것을 수반하는 낮은 레벨의 통합물입니다. 그러나 기술 발전 덕분에 미래에는 라스트 마일 상황을 해결하는 것이 훨씬 쉬워질 것입니다. 과거에는 지역 사업자가 당신 집 지하실에 있는 케이블을 소유했었습니다. 그러나 요즘에는 매우 쉽게 전신주에 박스를 달아 필요한 대역폭을 인근 가정에 공급할 수 있습니다. 당연히 트럭과 컨테이너 선적은 또 다른 이야기입니다. 그래서 현재 맥락에서의 PaaS는 통합 관점에 해당합니다. 
 
**Dirk Slama**: 미래의 자산에 대해 당신은 어떤 종류의 로직을 가지고 계신가요? 클라우드는 어떤가요?
 
**Peter Coffee**: 저는 이것을 인간의 몸이 어떻게 작동하는지에 비교하고 싶습니다. 감각 뉴런은 혼자서 두뇌로 정보를 전달하지 않습니다. 근거리 척추 모토 뉴런이 거의 바로 반사 작용을 일으키죠. 그래서 만약 당신이 뜨거운 것을 만지면, 당신은 자동적으로 손을 뗍니다. 그러면서 당신의 두뇌는 맥락에 정보를 집어넣기 시작하여 비상 탈출 경로를 찾습니다. IoT의 경우, 우리는 씨앗 크기의 아주 작은 마이크로칩이 자산에 배치되었을 때 대단한 일을 하는 걸 보게 됩니다. 그러나 맥락에 정보를 집어넣는 것과 전략적 선택을 하는 것은 제가 항상 클라우드에서 보는 일들입니다.  

**Dirk Slama**: 그래서 물리적, 기술적 경계들 (9)이 계속 중요한건가요? 

**Peter Coffee**: 데이터와 로직 분포에 관한 결정을 내리기 위해, 잠복된 것과 특정 환경의 대역폭 제한을 이해하는 것은 매우 중요합니다.  

**Dirk Slama**: 시간 민감성은 곧잘 큰 이슈로 언급되곤 합니다. 실시간 조건에 맞게 고속 제조 로봇을 통제하는 것과 같은 어플리케이션이 클라우드 환경 밖에서 작동할 수 있다는 것은 말이 되지 않는 것 같습니다. 이 책은 광범위한 여러 단계의 아날로그/디지털 데이터 전환, 데이터 수집, 분산 그리고 분석 어플리케이션을 다루고 있습니다. 책에서 나온 CERN 케이스 연구를 예로 들어보죠. 클라우드라고 보기 힘든 또다른 예가 있을까요?  

**Peter Coffee**: 현 상황에서 봤을땐 그렇다고 볼 수 있겠지만, 저는 클라우드가 할 수 있는 것들이 물리적 거리나 규모의 경제 측면에서 관측되어선 안된다고 생각합니다. 우리는 끊임없는 기술 개발의 세계에 살고 있습니다. 현존하는 경계들은 매일 사라질 것입니다 (10)! 이러한 세계에서 클라우드는 늘 목표가 되어야 합니다. 그러므로 사일로가 기본값이 되는 대신, 클라우드가 기본값이 되어야 합니다. 

데이터가 시작되는 지점에서 당신은 그것을 로컬에서 처리할지, 버스, 한 건물 안의 로컬 네트워크에서 이용 가능하게 할지 결정할 수 있습니다. 또는 당신이 인터넷에 있는지 클라우드에 있는지에 따라 전세계에 있는 모든 기기들에게 데이터 이용이 가능하도록 할 수도 있습니다. 당신이 정확하고 신뢰성 있는 포맷에서 데이터를 가져온다면, 맥락 안에 위치시키는 가장 좋은 방법은 바로 클라우드입니다.
   
로컬에 배치시킬 수 있는 마이크로 클라우드 (8)가 요즘 떠오르는 컨셉인데, 그것을 예로 들어봅시다. 커넥티드 카에 관한 당신의 논의에서, 당신은 미래의 차량을 위한 샌드박스 어플리케이션 플랫폼을 말했습니다. 그것의 기초는 바로 인터넷 클라우드에 연결된 로컬 마이크로 클라우드일 것입니다. 

**Dirk Slama**: IoT 프로젝트 매니저와 오늘날 클라우드 전략에 대해 결정을 내려야하는 솔루션 설계자들에게 조언 부탁드립니다.
 
**Peter Coffee**: 오늘의 기술적 경계를 이해하세요. 그러나 당신의 시스템을 디자인하여 그 디자인이 예상하고 지금껏 지속되온 경계들의 이동을 가능하도록 만드세요. 당신의 디자인에 현재의 경계를 새겨넣는 것이 아닙니다. 무엇이 클라우드인지 아닌지의 질문에는 대답할 수 없습니다: 마이크로 클라우드, 개인 클라우드, 기기들로 된 집단의 클라우드들이 등장하고 있습니다. 이 모든 것들을 동일한 클라우드의 관점에서 생각하세요. 실로스를 만들지 말고 클라우드를 만드세요. 그리고 기존의 전략에서 떠나세요. 그러나 시간이 지나면 변화의 필요성이 사라질 것이란 기대를 하면서요.  

==== II. M2M/IoT 응용 플랫폼 ====

다음에 살펴볼 플랫폼 항목은 기초 M2M 솔루션과 더욱 향상된 IoT 매시업(mashup)의 개발과 작동을 가능하게 하는 플랫폼에 관한 것이다. M2M 솔루션은 보통 원거리 자산의 기초 감시과 관리에 초점을 둔다. 반면에 IoT 매시업은 의미상 더욱 풍부한 어플리케이션 로직을 더해주는 기능을 한다. 이러한 종류의 솔루션들은 다음 섹션(산업 데이터 인식 플랫폼)에서 다루도록 한다.   

{{ :파트2_76번그림.png?nolink&300 |}}
                         M2M/IoT application platforms – Mapping to AIA
                         
M2M/IoT 어플리케이션 플랫폼의 주요 목적은 개발 과정을 간소화하는 것과 별도의 설치나 구성이 필요없는(out-of-the-box) 기능을 최대한 많이 제공하여 어플리케이션 개발과 유지를 가장 효율적으로 이루어지도록 하는 것이다. 앞에 있는 도표는 그러한 플랫폼의 핵심 요소들을 보여준다:

1.	우리가 정의한 M2M/IoT 어플리케이션 플랫폼의 핵심은 백엔드와 행위자, 라이브러리, 인터페이스와 같은 것들의 자산 통합을 가능하게 하는 다른 기술들을 포함한다. 표준 자산통합아키텍처에서, 이들은 함께 중간 단계로서 늘 IoT 클라우드/M2M으로 불린다.\\ 
2.	자산 인터페이스의 정의: 이상적으로, 플랫폼은 일정한 방식으로 자산과 기기의 모든 기술적 인터페이스를 묘사한다. 이때 추상적 방식이 사용되는데 자산통합아키텍처의 모든 단계에서 사용될 수 있으며, 기기 통합부터 백엔드의 어플리케이션 개발까지를 포함한다. \\ 
3.	백엔드는 보통 중앙 데이터베이스를 보관한다. 또한 모든 자산 관련 데이터를 관리하는 저장소와 분산된 자산을 관리하는데 도움을 주는 서비스 세트를 포함한다. \\ 
4.	자산 통합 기술 세트는 정교화된 행위자 기술들, 충분히 강력하지 않은 하드웨어를 위한 기초 라이브러리, 자산의 직접 통합을 위한 원거리 인터페이스를 포함한다. \\ 
5.	MQTT, CoAP, XMPP 그리고 자산과 백엔드 사이의 원거리 통신을 가능하게 하는 많은 기타 프로토콜 등의 각종 프로토콜들을 지원한다.  \\ 
6.	IoT 어플리케이션 개발과 데이터, 백엔드 서비스들을 지원하는 매시업 기능들.  \\ 

==== 자산 및 기기 인터페이스 관리 ====

로만 웜바쳐씨가 게이트웨이와 센서 네트워크 장의 권고의 말에서 언급하였듯, 이질성을 관리하는 것은 현장에 다양하면서 많은 유형과 수준의 자산을 가지고 있는 모든 회사가 다루기 힘들어하는 문제 중 하나일 것이다. 이러한 문제를 해결하기 위해, 대부분의 플랫폼들은 표준 형식을 지원하는데 이는 자산과 기기 인터페이스를 정의하고 관리하는데 도움을 준다. 이것은 플랫폼 그 자체에게도 중요한 것이다. 왜냐하면 자산과 기기 인터페이스를 정의하기 위한 표준화 매커니즘은 자산 관련 UI를 통하여 자산 통합부터 자산 데이터 지속까지 플랫폼의 모든 요소가 적절히 작동한다는 것을 보장하기 때문이다.   
                         
{{ :파트2_77번그림.png?nolink&300 |}}
                        Sample model of asset and device interface definitions
                      
앞에 있는 도표는 일반 기기와 자산 모델에 의해 지원되어야 하는 주요 요소들을 보여준다:

•	자산과 기기는 명료하게 모델화되어야 한다: 집합 위계 (자산별 다중 기기, 자산 그룹 등)의 정의를 가능하도록 하는 것이 필요하다. 이전의 예시에서 보았듯, “관리된 독립체(Managed Entity)”는 자산과 기기의 공통 특징을 묘사하기 위해 사용되었다. \\ 
•	관리된 독립체의 이동 위치는 현재 위치에 대한 저장 데이터를 위해 쓰인다. 시간 스탬프는 이것이 언제 마지막으로 업데이트 되었는지 나타내기 위해 쓰인다. 이것은 이동 장비에게 있어 중요한 사항이다. 백엔드에서 이동 위치 정보는 일련의 시간 기록으로 저장되어 이동 자산의 움직임을 추적할 수 있도록 한다.  \\ 
•	사건은 자산 또는 기기에 의해 제출되어 오류 상황같은 것을 나타내도록 한다. 그리고 이는 다시 한 번 타임 스탬프로 기록되어 언제 사건이 제출되었는지 보여준다. 또한 완전한 추적 가능성을 보장하기 위하여 백엔드에서 일련의 시간 기록으로 저장된다.  \\ 
•	여러 속성들은 온도, 압력 등과 같이 각각 정의된다.\\ 
•	많은 자산은 데이터와 여러 파일들의 배치의 효율적 관리가 필요하다. \\ 
•	많은 자산은 또한 백엔드에서 원격으로 작동시킬 수 있는 여러 작업들을 보조한다; 예를 들면, “온도 올리기,” “압력 올리기”, “전원 끄기,” “재시동,” 등등.\\ 
•	마지막으로, 모델은 주로 역할 기반인 사용자 접근 권리를 반영해야 한다. 일례로, 최고 사용자 역할만이 재시동을 할 수 있는 권한을 갖는다. \\ 

많은 양의 계획들이 IoT의 자산, 기기의 인터페이스 정의를 위한 표준을 정의하기 위해 작업중이다. 예를 들면, IPSO 연합은 스마트 오브젝트의 IoT 기기간 상호작동성을 위한 사양을 정의해왔다. 그리고 OSGi RFC 196을 예로 들어 보자. 그것은 OSGi를 작동시키는 자바 동력의 게이트웨이를 위한 추상화 레이어 기기를 정의하는 것을 목표로 하고 있다. 또 다른 흥미로운 사례는 최근 이클립스 재단에서 있었던 Bosch 소프트웨어 이노베이션의 Vorto 프로젝트이다. Vorto는 기기와 자산을 위한 메타 정보 모델을 정의하기 위해 노력해왔다. 뿐만 아니라, 코드 생성기 지원이나 인터페이스를 제작 및 관리하는 오픈 소스 툴세트, 이러한 것들을 저장 및 관리하는 정보 모델 저장소를 목표로 하고 있다. 

더 높은 레벨의 인터페이스 정의에 관한 모든 분야는 IoT에 있어 상호작동성을 가능하게 하는 가장 중요한 요인이 될 것으로 보인다. 더 나아가 IoT 전반의 성공에 있어서 매우 중요한 역할을 할 것이다. 늘 그래왔듯, 우리는 전세계가 하나의 통일된 표준에 동의할 것이라 기대하지 않는다. 그러나 소량이어도 여러 수직적 어플리케이션 영역에 있어 널리 받아들여지는 표준에 동의하는 것 자체는 큰 도움이 될 것이다. 

==== M2M 백엔드/IoT 클라우드 ====

M2M 백엔드 (오늘날 IoT 클라우드로 주로 부름)는 보통 자산 관련 데이터의 중앙 관리를 제공할뿐만 아니라 현장에서 자산이 관리 감독되기 위한 일반 지원 기능들을 제공한다. 주요 기능들은 다음과 같다: 

•	자산 데이터베이스 또는 저장소: 자산 정의, 설정 데이터, 상태 정보, 시간 기록 데이터 (예를 들면, 사건 히스토리, 미터 정보 등등)를 저장한다. 데이터베이스 개요는 일반적이어야 하고 일반 자산 인터페이스 정의에 관한 여러 다양한 버전을 지원할 수 있어야 한다. 이는 이전 장에서도 논의된 내용이다. \\ 
•	자산 관리 감독 UI: 관리자를 위한 일반 UI는 자산 건강 및 히스토리를 포함한 모든 등록 자산의 개요를 제공한다. 자산 관리 UI는 로컬 자산 데이터 베이스 또는 저장소에서 데이터를 읽고, 사용자로 하여금 자산에서 직접 읽은 새로운 내용에 기반하여 가치 업데이트를 할 수 있도록 한다. 만약 자산이 작업들을 지원한다면 (이전 섹션에서 논의한 자산 인터페이스 참고), UI는 가능한 모든 작업들을 리스트로 보여주고 사용자가 작업들을 원활히 불러올 수 있도록 해줄 것이다.\\ 
•	보고 기능과 대시보드: 기초 서술적 분석 기능은 이론적으로 평균 기계 건전성 등과 같은 맞춤형 대시보드에서 이루어진다. \\ 
•	알람 관리: 이론적으로 보았을 때, 시스템은 스크립팅이나 비지니스 규칙 기반의 매커니즘을 제공해야 한다. 비지니스 규칙 기반 매커니즘이란 특정 사건이나 알람의 정의를 허용하는 기능을 한다. 예를 들면, 정기적인 핑 메시지에 기계가 15분 이상을 소요한다면 관리자에게 텍스트 메시지가 가도록 하는 상황을 규칙으로 정의할 수 있다. \\ 
•	원격 접근: 많은 자산들은 현장 진단을 위한 원격 로그인 매커니즘의 몇 가지 형식을 제공할 것이다. 이 플랫폼은 원격 진단 도구와 방화벽에 친화적인 원격 접근을 지원할 것이다.\\ 
•	내용 분산: 많은 자산들은 각종 내용에 대한 정기적인 업데이트가 필요하다. 업데이트가 필요한 내용의 예로는, 설정 파일, 테스트 데이터, 문서, 로컬에 배치되어야 하는 디지털 마케팅 담보물들이 있다. 
•	소프트웨어 분산: 플랫폼은 안전하고 효율적인 관리와 펌웨어의 분산, 시스템 업데이트 작업, 어플리케이션 로직을 지원할 수 있어야 한다. \\ 
•	안전성 관리: 이는 인증서 관리와 함께 사용자와 역할 관리 (또는 외부 시스템과의 통합), 사용자(또는 역할)와 자산(혹은 자산의 특정 데이터나 기능) 사이의 승인 배정 관리를 포함한다. \\ 
•	로그인과 추적: 모든 행동은 효율적이고 투명한 방식으로 완전히 로그인 되어야 한다. \\ 
•	자동화: 플랫폼은 API와 스크립팅 엔진 보조를 이용하는 것과 같은 자동화를 위한 지원을 제공해야 한다. 예를 들면, 1만개의 원격 자산이 특정 설정 파일의 올바른 버전을 가지고 있는지 수동적으로 확인하는 것이 아니라, 간단한 스크립트가 이러한 업무를 자동화할 수 있도록 해야한다. \\ 

==== 자산 통합 ====

백엔드와 자산의 통합을 위한 다양한 전략들이 존재하지만, 주요 내용은 아래와 같다:

•	행위자 기반 통합 (주로 상대적으로 강력한 게이트웨이와 결합됨): 이는 자산의 정교화된 통합과 비지니스 로직의 배치를 가능하게 한다.\\ 
•	로컬 라이브러리: 자산에서 덜 강력한 하드웨어만 사용가능한 경우, 많은 플랫폼들은 라이브러리(예를 들면, c/C++ 또는 자바 스크립트에서)를 제공할 것이다. 이때 라이브러리는 백엔드의 맞춤 통합을 허용하여 고도의 최적화를 가능하게 한다.이러한 라이브러리들은 백엔드에 의해 지원되는 원거리 인터페이스를 이해하고 백엔드에 의한 로컬 인터페이스를 지원할 것이다. 그러나, 이들은 많은 경우 훨씬 간단하며 인터페이스의 부분 집합만을 지원하기도 한다. \\ 
•	인터페이스 기반 통합: 몇몇 경우, 앞에서 언급한 두 접근 방식 중 하나를 이용하는 것은 말이 되지 않거나 불가능한 때가 있다. 만약 백엔드가 공개 표준에 기반하여 잘 기록된 온라인 인터페이스 세트를 지원한다면, 다른 방식을 통한 자산 통합 또한 가능해진다.  \\ 

하드웨어의 엄청난 가격 하락과 자산 서비스에 대한 요구의 지속적 증가와 함께, 행위자 기반 접근은 IoT에서 상당한 잠재력을 지닐 것으로 보인다. 스마트홈은 통합 목적의 자산 기반 행위자 기술의 초기 도입과 로컬 비지니스 로직의 공급이 있었던 분야이다. 미래에 행위자 기반 접근이 필요할 다른 분야는 자동차 산업이다. 커넥티드 카 장에 소개된 오픈카 어플리케이션 플랫폼에 관한 내용을 찾아보기 바란다.  
이런 종류의 행위자 소프트웨어가 지원해야하는 중요 기능은 아래와 같다: 

•	어플리케이션 샌드박스: 어플리케이션이 서로 또는 환경과 방해가 될 경우 로컬 어플리케이션들을 수행할 안정적인 환경\\ 
•	기기 추상화 레이어: 로컬 기기와의 통합을 위한 지원은 필수적이다. 이 과정에서 추상화 인터페이스 정의를 보여주는 것, 백엔드에 의해 습득된 인터페이스를 보조하여 자산 상태 데이터를 읽고 자산에 관한 작업을 수행하는 것 등의 활동이 수반된다. \\ 
•	백엔드에서의 소프트웨어 분산 매커니즘을 위한 상대로서 관리 행위자\\ 
•	중요 프로토콜, 다른 기기 종류와 근거리 무선 통신, 백엔드 통신을 위한 지원\\ 
•	백엔드에서 동일한 기능과 함께 호환 가능한 사용자와 역할 관리\\ 
•	로컬 데이터 수집과 필터링 (게이트웨이와 센서 네트워크 장에 나온 포그 컴퓨팅(fog computing)에 관한 논의 혹은 데이터 관리 장에 있는 복잡한 사건 처리에 관한 섹션 참고) \\
•	백엔드에서의 자동화와 유사한 로컬 자동화\\

행위자 기술을 위한 가장 고급의 공개 표준은 아마도 OSGi일 것이다. OSGi는 어플리케이션 격리, 자원 할당, 어플리케이션 생애주기 관리, 어플리케이션 의존 관리 등을 위한 매우 정교화된 지원을 제공한다. 

==== IoT 어플리케이션과 매시업 ====

지금까지, 우리는 주로 자산 통합, 자산의 원격 감시, 자산에서 전달된 상황에 대처하는데 필요한 특징들에 대하여 주로 다루어왔다. 그러나, 우리는 기초 M2M에서 기업 IoT를 구별할 풍부하고 새로운 어플리케이션들을 실제로 구축하기 위한 기능들을 어떻게 가능하게 할지에 대해서는 이야기하지 않았다. 운이 좋게도 대부분 플랫폼들은 기본 설정을 통해서 공개 인터페이스와 그러한 어플리케이션들을 구축하는데 사용되는 API의 세트를 제공한다. 그리고 IoT 어플리케이션과 매시업의 빠른 개발을 가능하게 해줄 제품들도 곧 이용할 수 있게 되는데, 이러한 제품들은 기초 M2M플랫폼 (또는 사용되는 용어에 따라서 “IoT 클라우드”)의 통합을 사용한다. 

아래의 인터뷰에서 볼 수 있듯이, ThingWorx의 CTO인 Rick Bullotta씨는 이것에 대해 굉장한 열정을 가지고 있다.

**Dirk Slama**: IoT에서 어플리케이션이 가능해지는 것에 대한 미래를 어떻게 보시나요?

**Rick Bullotta**: 우리는 이것을 기기/기계 클라우드와 어플리케이션 구현 레이어라는 두가지 다른 단계로 바라봅니다. 우리의 많은 글로벌 고객들이 벌써 커넥티드 기기를 가지고 있는 걸 발견할 수 있습니다. 얼마나 많은 기기들이 실제로 다이얼-인 모뎀과 기타 기술들을 통해 연결되어있는지 알면 당신은 매우 놀랄 것입니다. 우리는 어플리케이션 구현 레이어가 다른 기기의 클라우드와 함께 작업할 수 있는 방식으로 우리의 플랫폼을 설계해왔습니다. 이는 고객의 선택과 다른 비즈니스 단위에서 다른 기술들이 쓰이는 현실을 지원하는 것에 관한 겁니다. 우리는 세계적 수준의 기기 클라우드를 제공하면서, “다른 것들과 같이 놀아보기”로 결정하였습니다. 어플리케이션 플랫폼은 또한 시스템과 관련된 사람들뿐만 아니라 기계를 모두 아우를 수 있어야 합니다. 

**Dirk Slama**: 그러면, IoT는 단순히 기계에 관한 것이 아닌거군요…

**Rick Bullotta**: 흥미로운 일을 하는 IoT 어플리케이션들은 다른 비즈니스 어플리케이션들 그리고 인간적 요소들과 함께 통합합니다. 이것은 어플리케이션 구현 플랫폼을 위해서는 꼭 가져야할 능력입니다: 예를 들면 ERP 시스템, CRM 시스템, 현장 서비스 관리, 날씨 데이터 그리고 에너지 가격 같은 자산을 불러오는 것, 어플리케이션 플랫폼 수준에서 구성가능한 기능을 만드는 것이 있죠. 구성은 사용자 인터페이스, 분석, 비지니스 절차에서 응용 가능합니다. 

**Dirk Slama**: 이러한 접근 방식이 가지고 있는 강점과 잠재적 한계에 대해서 이야기 해봅시다.

**Rick Bullotta**: 예를 하나 들어보죠: 저는 집에 있는 스마트 청소기를 통제할 수 있는 소비자 기기가 필요합니다. 그건 매우 집중된, 1차원적인 어플리케이션이죠. 그렇게 복잡하지는 않습니다. 많은 회사들이 어플리케이션을 만드는 표준 개발 도구를 이용하는 그들만의 엔드투엔드(end-to-end) 기술들을 개발하고 있습니다. 제 생각으로, 전통적인 개발 접근이 작동하지 않는 순간은 복잡성이나 다른 시스템 또는 데이터와의 통합이 발생하는 때입니다. 더 자세한 예로는, 어플리케이션이 원래부터 역동적이거나 당신이 새로운 서비스나 기능을 추가하고 싶을 때, 그것을 다른 고객이나 이용 용도에 따라 조정하고 싶을 때, 매우 반복적인 개발 접근을 원할 때라고 보면 됩니다. 어플리케이션 개발을 위해선 다른 모델들이 필요합니다. 가장 첫 번째로 기억해야할 것은 만약 자주 바꿔야할 필요가 없는 고정적인 어플리케이션이라면, 당신은 이용할 수 있는 다양한 선택지를 가지게 된다는 것입니다. 만약 그것이 매우 역동적인 어플리케이션이거나 계속해서 새로운 기능들을 추가하는 비지니스 모델일 경우, ThingWorx같은 환경은 생산성 측면에서 초기의, 진행중인 이점들을 많이 제공합니다. 우리는 그러한 기준에 맞는 상당한 양의 IoT 어플리케이션들을 찾아왔습니다. 

**Dirk Slama**: 결론을 내리자면, IoT 플랫폼의 주요 조력자는 무엇이 있나요? 

**Rick Bullotta**:  기기에서 클라우드까지 강력한 별도의 설치 및 구성이 필요없는(out-of-the-box) 기능으로 시작해야 합니다. 그리고 다른 사람들이 당신의 플랫폼을 강화하고 확장시킬 수 있도록 해야합니다. 다른 사람들이 혁신할 수 있도록 하세요. 다른 사람들이 혁신적인 솔루션을 만들어낼 수 있도록 하세요. 그러나 그들이 개발 환경, 운송, 보안 그리고 우리가 제공하는 높은 수준의 서비스를 도울 수 있도록 해야 합니다. 사람들이 그들의 알고리즘, 비지니스 로직, 연결기, 사용자 인터페이스 구성요소들을 연결하도록 해야 합니다. 이건 양자택일의 상황이 아닙니다. 만일 사람들이 그들의 고유한 지적 재산을 통합하기 위해 우리의 소프트웨어 개발 키트를 사용하기 원한다면, 우리는 그들에게 지속 가능한 방식 및 우리가 이전에 이야기했던 빠른 구성이 가능한 방식으로 사용하도록 허락할 것입니다. 

**사물부분망 통합**

서론에서 논의하였듯, 많은 기업 IoT 솔루션은 상대적으로 잘 정의된, 가끔은 닫힌 생태계나 사물부분망 (SoTs)에 초반 집중할 것이다. SoTs 내부에서 또는 SoTs 사이의 통합은 IoT 진화에 있어 중요한 도전 중 하나가 될 것이다.

이 내용을 다른 차원에서 논의하는 회사들이 많이 있다. 그 중 하나는 뉴욕에 기반한 스타트업 회사인 woit.io이다. 이들은 사업 기회를 열기 위하여 기기, 데이터 서비스와 데이터 주인 사이의 상호연결성을 돕는 것을 목표로 하고 있다. 이 회사는 사실 데이터 서비스를 제공하지는 않지만, 3자 데이터 서비스를 활용하는 최종 소비자와 연관된 기술적, 법적, 사업적 절차를 간소화하기 위해 노력한다. 소비자 입장에서 보았을 때, woit.io는 IoT를 위한 salesforce.com처럼 보이려고 노력한다. 기술적 백엔드 관점에서 보자면, Object Management Group의 DDS 기준과 매우 유사하다 (더 자세한 사항은 아래를 참고). 이 회사가 추가하고자 한 주요 가치는 법적, 사업적 체계를 개발 및 유지하는 것 또한 salesforce.com의 상품 진열장과 데이터 서비스 파트너와의 기술적 통합을 지원하는 데 존재하는 차이를 메꾸는 것에 있다. 다른 방식으로 놓고 보자면, 이 기업은 비지니스 간소화 기능을 기준으로 경쟁한다. 한편 기술적 기능을 뒷받침 하는 것은 시장에서의 경쟁을 통과한 예선 통과자라 할 수 있다. 

wot.io의 설립자이자 회장인 Allen Proithis와의 아래 인터뷰는 이런 흥미로운 시장 포지셔닝에 대해 좀 더 자세히 탐구한다.

**Jim Morrish**: wot.io는 IoT 공간에서 꽤나 신입 진출자입니다. 회사 창립의 계기와 당신이 보았던 기회의 특징을 설명해 주실 수 있나요?  

**Allen Proithis**: IoT의 멋진 기회들에 참여하기 원하는 거의 대부분의 사람들은 어느 면에서 모두 고생을 합니다. IoT 주도의 상품, 서비스, 가격 효율성을 완전히 실현하는데에 겪는 이런 고생은 가치를 생산하려는 참가자들에 의해 그리고 성공적인 업무 관계를 정의하기 위해 해결되어야 하는 기술적, 사업적, 법적 마찰에 의해 유발됩니다. 우리는 이러한 마찰들을 상당수 제거하였습니다.

**Jim Morrish**: 예시를 좀 들어주세요.
 
**Allen Proithis**: IoT 솔루션을 위해 누구에게 연락해야할지, 어느 판매자를 고를지, 위험, 비용, 시간 고려를 포함한 거대한 고객 통합을 어떻게 정당화해야할지의 내용으로 우리의 고객들이 고생하는 것을 종종 봅니다. IoT 데이터에 가치를 더하는 회사들은 시장에 접근하는데에 어려움을 겪습니다. 이러한 어려움의 이유로는 광범위한 시장 세분화, 복잡한 통합 조건들 그리고 동일한 데이터에 다른 가치를 더하기 위해 필요한 다른 회사들과의 관계 유지의 어려움이 있습니다. 그리고 전문적 서비스를 판매하고자 하는 시스템 적분 회로망(systems integrators)은 대부분의 작업이 맞춤형인 분야의 거래에서 손해를 보고 있습니다. 성공적인 SI는 가장 큰 가치를 더할 수 있는 분야에 초점을 두고 상품화할 수 있는 솔루션의 부분들과 파트너를 맺을 것입니다. 

**Jim Morrish**: 그렇다면 당신은 표준화나 많은 IoT 업자들이 이미 그러한 인터페이스를 구축하고 있다는 간단한 사실이 이러한 문제를 조만간 해결할 것이라 보시나요? 

**Allen Proithis**: IoT가 우리의 일상에 미칠 영향과 새로운 상업적 기회의 두 측면에서 모두 엄청날 것이란 것은 널리 알려져 있습니다. 반면에 잘 알려져 있지 않은 것은 IoT의 미래가 순탄하진 않을 거란 점입니다. 좀 더 자세히 말하자면, 우리는 IoT 개발의 다음 단계가 공공 데이터 표준, 데이터 서비스 공공 제공자와의 연계, 데이터 소스의 공공 소유권 또는 데이터 소유자들 사이의 공동 노력에 의해 이루어질 것이라 생각합니다. 또한 그것은 우리가 ‘사물 부분망’이라 명명하기도 한, 상대적으로 촘촘하게 통합된 커넥티드 기기의 섬들로 특징지을 수 있습니다. 이러한 커넥티드 기기의 섬들 사이 연결과 인터페이스는 이들 내부의 연결과 인터페이스보다는 훨씬 느리게 발전할 것으로 예상됩니다. wot.io는 바로 여기에서 등장합니다. 우리는 ARM의 mbed 플랫폼 또는 ARM mbed 사물 부분망을 Rackspace 또는 스케일 DB 또는 스트림 테크놀로지와 빠르게 연결합니다. 예를 들면 말이지요. 
  
**Jim Morrish**: 그러나 Object Management Group이 데이터 분산 서비스(DDS) 표준과 상당히 비슷한 무언가를 하고 있지 않나요? 

**Allen Proithis**: 실시간 발행-구독 (RTPS) DDS는 wot.io의 메시지 버스와 어댑터의 골조와 유사합니다. 우리는 다른 Pub/Sub 스트리밍 프로토콜(AMQP, MQTT, XMPP, Kafka, Pubnub과 같은 클라우드 서비스까지)을 위한 어댑터를 만들긴 하지만, 우린 RTPS DDS를 위한 수송 어댑터를 만들 것이며 메시지 경로 세계에 다리를 놓을 것입니다. 그러나 wot.io는 메시지 경로에 관한 것이 아닙니다. 메시지 경로는 다른 일들을 실현하기 위한 보조 서비스입니다… wot.io는 커넥티드 기기 플랫폼을 위한 데이터 서비스 교환에 관한 것입니다. 데이터 서비스는 통합된 어플리케이션으로서 커넥티드 기기 플랫폼에서 가져온 데이터를 작업합니다… 그리고 물론 우리는 이러한 것들을 이루기 위해 발행구독 SOA를 사용합니다. 

**Jim Morrish**: 그건 마치 Rackspace의 시장처럼 들리는데요?

**Allen Proithis**: 맞습니다. Rackspace는 관리된 어플리케이션을 제공합니다. 그러나 그들은 엄청난 공학기술 없이 커넥티드 기기 플랫폼의 데이터에 작동하거나 가치를 더할 수 있는 데이터 서비스와 통합할 수는 없습니다. wot.io와 Rackspace는 협력사입니다. 우리는 Rackspace의 인프라에 우리의 데이터 서비스를 배치시킬 수 있을뿐만 아니라, Rackspace의 시장에서 서비스 통합을 할 수도 있습니다. 

**Jim Morrish**: 그러면 간단히 요약하여 wot.io의 일은 무엇인가요? 

**Allen Proithis**: wot.io는 커넥티드 기기 플랫폼을 위한 데이터 서비스 교환입니다. 우리는 고객들이 커넥티드 데이터에서 빠르고 유연하게 사업 가치를 뽑아낼 수 있도록 돕습니다. 우리의 솔루션은 개별 기술과는 독립적입니다. 또한 칭찬이 자자할 뿐만 아니라 사물 인터넷과 M2M분야에서 이미 활약중인 기관 전용 판매 플랫폼과도 독립적입니다. 사실 제가 이전에 언급했던 이러한 사물 부분망의 많은 경우는 서로 연결됨으로써 이득이 됩니다. 그리고 이러한 점은 wot.io와 같은 몇몇 시장 참여자들이 그러한 연결을 만드는데 집중할 수 있도록 합니다. 개별 사물 부분망 각자가 그들 자신만의 쌍방 관계를 구축하도록 만드는것 대신 말이지요. 이런 방식을 통해서 얻을 수 있는 규모의 편익은 많이 존재합니다. 그러나 실제로 이러한 연결을 구축하는 것은 데이터 서비스 공급의 유동성에 관한 더 넓은 개념으로 향하는 첫번째 단계입니다. 이것이 바로 우리가 wot.io를 데이터 서비스 교환, 즉 DSE로 정의하는 이유입니다. 

**Jim Morrish**: 그 말씀은, 이러한 서비스의 잠재적 고객들과 데이터 서비스 공급자 사이를 연결하는 것과 관련된 마찰을 줄이라는 건가요? 

**Allen Proithis**: 맞습니다. 사물 부분망의 모든 연결점을 구축해오면서, 데이터 서비스 교환은 고객들에게 이미 DSEs 생태계에 통합된 파트너들이 제공하는 서비스 범주로의 접근을 제공하도록 이론적 포지셔닝이 되어있습니다. 하나의 사례로, DSE는 Volt, Hadoop, Cassandra, SAP 또는 MongoDB 데이터 서비스 또는 심지어 이러한 것들의 하이브리드 결합체로의 접근성을 제공할 수 있습니다. 그리고 이들은 모두 기본적으로는 선통합 및 기성품 형식의 상업적 패키지로 이루어집니다. 이를 데이터 서비스 제공자의 관점에서 본다면, 어플리케이션은 IoT 기회의 핵심에 있는 것입니다. 모든 커넥티드 기기는 가능한 여러 개의 관련 어플리케이션을 꼭 갖고 있어야 합니다. 또한 이러한 어플리케이션의 개발과 데이터 분석, 데이터 마이닝 및 다른 데이터 서비스들과 같은 지원 기능을 공급하는 것은 많은 참여자들에게 현실적인 상업적 기회를 보여줍니다. DSE는 특수화되고 차별화된 공급자들이 잠재적 고객들과 맞닿을 수 있도록 도와줍니다. 

**Jim Morrish**: 더욱 차별화된 서비스의 더 자유로운 교환과 상호 연결이 앞으로 IoT를 특징지을 것이라 생각하나요? 

**Allen Proithis**: 우리는 M2M 시장에 관한 더욱 수평적인 관점이 지배적인 주제가 될 것이라 예측합니다. 지금까지 M2M 시장은 산업의 거대 기업들에 의해 장악되어 왔습니다. 2차 공급자나 소규모 참여자가 시장에 진입하면, 그들은 자연스럽게 특정 기능 개발을 통해 차별화를 찾아갈 방법을 모색할 것입니다. M2M과 IoT 도입의 대중 시장 단계는 더욱 차별화된 ‘수평 우선’ 접근의 성격을 지니게 될 것입니다.

**Jim Morrish**: 그럼 그것이 당신이 지원하고자 하는 원동력인가요? 

**Allen Proithis**: 맞습니다. wot.io 데이터 서비스 교환은 통합된 3자 데이터 서비스의 시장입니다. 이미 통합된 것에 의해, 우리는 개발자가 새로운 데이터 서비스와 통합에 관한 기술적, 사업적, 법적 측면에 집중하지 않아도 되며, 성공적으로 잘 될 것임을 말하고자 한 것입니다. 간단히 말하자면, 우리는 데이터 서비스 교환이 필요한 기초 보강을 제공할 독립체라 생각합니다. 그래서 미래의 M2M과 IoT 시장이 기능할 수 있도록 말입니다. wot.io와 같은 독립체들은 차별화되고 특수화된 공급자들이 손쉽게 더 크고 덜 차별화된 서비스 공급자에 연결할 수 있도록 또는 반대 방식으로 작용할 수 있도록 해줍니다. 이것은 차별화된 데이터 서비스와 플랫폼 참여자들의 생태계 구성으로 특징되는 IoT 개발의 한 단계로 진입할 것입니다. 마지막으로 IoT 시장에서 상품은 서비스보다 더 나은 것이며, 참여자들이 각자의 강점을 발휘할 때 시장은 전체적으로 강화될 수 있습니다. 

**오픈 소스**

이 분야에서 이용 가능한 여러 가지 다양한 상용 플랫폼과 함께, 오픈 소스 커뮤니티에는 많은 일이 일어나고 있다. 예를 하나 들기 위해, Eclipse 재단에서 현재 진행중인 갖가지 IoT 프로젝트에 대한 개요를 담고 있는 아래의 도표를 보도록 하자 (이 책에서 언급된 Ignite | IoT 방법론 또한 현재 Eclipse 재단에서 진행하는 공식 오픈 소스 프로젝트이다.). Eclipse Vorto 프로젝트는 IoT를 위한 인터페이스 정의를 관리하기 위해 설립되었다. 내장형 개발을 위하여 Eclipse는 c, C++, Lua를 위한 오픈 소스 개발 도구의 제공을 목표로 하고 있다. Kura 기기 게이트웨이는 흥미로운 오픈 소스 하드웨어 계획이다. 프로토콜 수준에서 Eclipse는 MQTT, CoAP, OMA LWM2M과 ETSI M2M을 벌써 지원하고 있거나 지원할 계획을 가지고 있다. 마지막으로 Eclipse는 서버 개발을 위한 오픈 소스 도구를 지원할 예정이다. 

{{ :파트2_78번그림.png?nolink&300 |}}
              Key IoT projects of the Eclipse Foundation mapped to the AIA
              
==== III. 산업용 데이터 인식 플랫폼 ====

산업용 데이터 인식과 통제 (IDAC) 시스템은 강력하고 헤드리스이며 분산된 시스템으로 감시와 통제를 통해 효율성을 증진시키기 위해 설계되었다. 고속 감시와 분석을 통하여 IDACs는 자산의 건강도에 관한 이해를 제공하여 실패를 예측하거나 작동하지 않는 시간을 줄여준다. 이런 시스템은 자산 통합 아키텍처 (AIA)의 모든 측면과 접속할 수 있다. 그리고 이를 통하여 빠르고 믿을 수 있는 의사결정을 위해 정보를 뽑아내는 상호연결 시스템의 방대한 네트워크를 구성할 수 있다. 스마트 그리드에서 스마트 기계까지, IDACs는 자산과 기업 수준에서 정보를 획득하고, 분석하며 소통한다. 내장된 이기종 처리를 통하여, IDACs는 어려운 실시간 결정을 100만분의 1초안에 해내고 시간, 네트워크 대역폭, 중앙 처리 동력을 절약한다. 감시뿐만 아니라 감시의 과정에서 얻은 정보를 기반으로, IDACs는 높은 수준의 빠른 통제를 수행하는데 필요한 입출력과 처리 능력을 가지고 있다. 이러한 능력들은 IDACs가 통제 순환의 속도를 늦추지 않고도 처리된 정보를 통제 시스템으로 획득, 분석 및 소통할 수 있도록 도와준다. 그 대가로 이 정보는 실시간으로 사용되어 통제 알고리즘과 유지 계획의 최적화를 통해 자산의 건강도, 효율성, 처리량을 개선할 수 있다.  

==== 기본 요소 ====

IDACs는 통일된 통합 개발 환경으로 함께 묶여진 몇 가지 하드웨어와 소프트웨어의 핵심 구성요소로 정의된다. 많은 자산들이 멀고, 평탄하지 않거나 심지어 위험한 환경에 위치하기 때문에, 이 하드웨어와 소프트웨어 솔루션은 내구성 있고, 믿을 수 있으며 홀로 작동 가능할 수 있어야 한다. 이를 통해 네트워크 소통의 손실과 같은 가장 최악의 조건에도 지속적인 통제와 감시를 보장할 수 있다. IDAC의 기초 구성요소는 다음과 같다: 

•	**이기종 처리**: 최고의 반응 시간과 처리량을 얻기 위해서, IDAC 시스템은 많은 처리 옵션들을 결합하여 다양한 업무를 수행하는데 최적화할 수 있도록 한다. 이러한 처리의 구성 요소들은 다층-코어 프로세서, 디지털 신호 프로세서, 현장-프로그램작동 게이트 어레이 (FPGAs) 그리고 검색 표를 포함한다. 이러한 요소들은 각각 다른 방법들을 이용하여 정보를 저장 및 처리하여 다양한 업무에 적절하도록 만든다. 고속 평행 프로세싱과 같은 낮은 수준의 업무는 이런 업무에 최적화된 FPGA로 옮겨질 수 있다. 소통과 소프트웨어 건설같은 높은 수준의 업무는 프로세서에서 실행될 수 있다. 각 요소는 사용자-프로그램작동이 가능해서, 하드웨어는 기성품 솔루션으로 맞춤 디자인의 유연성을 달성하기 위하여 갖가지 다양한 방식으로 결합될 수 있다. 맞춤 디자인에 대해 좀 더 간단히 말하자면, 이런 요소들의 많은 경우가 칩 위의 시스템(SOC)으로 알려진 개별된 칩으로 통합되어왔다. 그들은 많은 종류의 처리 요소들을 통합하기 때문에, IDACs는 핵심 구성요소의 변경 없이 시각, 움직임 또는 인간 기계 인터페이스 (HMI) 시스템으로 설정될 수 있다. 그러므로 이러한 IDAC 시스템은 종종 하드웨어 기능을 정의하는 소프트웨어라는 의미에서 “소프트웨어 정의”로 묘사되곤 한다. \\ 
•	**소프트웨어와 운영 시스템**: 사물 인터넷은 시스템 설계에 많은 양의 복잡도를 추가하여 효율성을 유지하기 위하여 모든 방식에서의 간소화를 하는 것이 가장 중요해졌다. 하드웨어를 자각하고 있는 통합 소프트웨어 패키지를 갖는 것이 이런 복잡성을 줄이기 위한 핵심이다. 이 소프트웨어는 낮은 수준의, 낮은 가치의 업무를 추상화하여, 사용자는 많은 어플리케이션에 거쳐 이용될 수 있는 재사용 가능한 코드의 기본 토대를 형성할 수 있다. 소프트웨어와 하드웨어가 함께 묶여있는 경우, 하드웨어는 최상위 코드 재사용과 함께 최신의 처리 요소로 업그레이드될 수 있다. 보안은 사물 인터넷에 의해 제기된 또다른 해결 과제이다. 세계의 거의 모든 곳에서 자산이 조작 가능해지면서, 보안에 대한 필요성은 증가하였다. 이를 해결하기 위하여 IDACs는 IT 친화적인 운영 시스템에 기반을 두고 있다. 이 시스템은 적절히 사용자를 확인 및 인증하고 시스템 완전성을 유지하며 시스템 가능성을 최대화하기 위하여 안전하게 공급 및 설정될 수 있다. 또한 IDACs는 공개 OS에 기반할 수 있어 전세계의 개발자들은 함께 내장형 보안의 최신형을 개발한다. \\ 
•	**입력/출력 (I/O)**: 효율성을 위하여, IDACs는 가능한 가장 정확하고 효율적인 방식으로 자산으로부터 정보를 공급받고 자산에게 정보를 제공해주어야 한다. 이 방식은 보통 센서와 작동기의 네트워크를 통해 이루어진다. IDAC 시스템의 I/O는 진짜 세상의 신호를 디지털 세계에서의 처리를 위한 것으로 바꿔주는 수단을 제공한다. 그리고 이 과정은 아날로그에서 디지털로, 디지털에서 아날로그로 바꿔주는 변환기를 통해서 이루어진다. 처리가 중요하듯, 계산도 I/O 가 데이터를 생성하는 것만큼 중요하다. 이러한 이유로 IDAC의 I/O는 굉장히 정확하고 빠른 샘플 및 업데이트 속도 (>1kS/s)를 구현하여 자산 수행에 있어 매우 높은 정확도와 충실도를 가능하게 한다. 이러한 속도가 필요한 공동 어플리케이션은 샘플 속도가 매초 수백 킬로-샘플에 다다르는 회전 기계류의 조건 감시에 관한 것이다. I/O는 모듈화되어 오면서 단일 IDAC 시스템은 상당히 다양한 자산과 변화하는 센서 조건에 적응할 수 있게 되었다. I/O 모듈은 넓은 범위의 신호 조절을 특징으로 하여 자산에 의해 요구되는 어떠한 센서로든 맞출 수 있도록 한다. 다양한 방식으로, I/O는 자산과 처리 사이에서 아날로그와 디지털 모두의 방식으로 움직인다. \\ 
•	**커뮤니케이션**: 자산과 처리 레이어 사이의 커뮤니케이션과 더불어, 이더넷 기반의 커뮤니케이션 프로토콜은 자산 시스템을 다른 자산들이나 기업과 소통할 수 있도록 해준다. 과거에 이러한 프로토콜들은 개인 제조업자에게 소유권이 주어져 방대한 자산의 네트워크를 유지하기 어려운 환경이었다. IDACs는 많은 커뮤니케이션 프로토콜들을 지원하는 방식으로 이런 문제를 해결한다. 하지만 더 나은 간소화와 수행 증진을 위한 보편 커뮤니케이션 표준의 문제는 여전히 존재한다. 

아래의 도표는 IDAC의 주요 특징을 우리의 자산 통합 아키텍처로 안내한다
              
{{ :파트2_79번그림.png?nolink&300 |}}
                           Key elements of an IDAC mapped to the Ignite AIA
                           
==== 어플리케이션 ====

많은 어플리케이션은 I/O와 처리를 필요로 한다. 다음 부분에서 우리는 IDACs가 성공적이었던 세 가지 종류의 어플리케이션에 대해 다루도록 한다:

•	**조건 감시**: 조건 감시는 자산들을 감시하는 것으로 실패를 예측 및 방지하여 계획에 없는 정전을 방지하고 기기 능력을 최적화하며 수리 시간을 줄일 수 있도록 한다. 이것은 IDAC 시스템에게 본직적인 어플리케이션이다. 동력 발전에서 산업 제조업까지, IDACs는 데이터를 취득하고 처리하기 위한 환경설정이 가능하여 자산의 실패를 예측 및 방지할 수 있도록 한다. 관련 사례 연구 참고: Remote condition monitoring of London Underground track circuits\\ 
•	**스마트 기계**: 스마트 기계는 변화하는 조건과 업무에 적응할 수 있도록 해주는 내장형 지능을 가지고 있는 고성능 기계이다. 이들은 많은 모양과 크기로 제작되며 다양한 이질적 특징을 종종 통합하기도 한다. 그 특징으로는 움직임, 시각, 커스텀 프로토콜, HMI, 통제 그리고 감시가 있다. IDACs는 처리와 I/O 측면에서 굉장히 쓰임새가 많기 때문에, 이들은 스마트 기계를 만들 수 있는 플랫폼에서 개별 플랫폼을 제공할 수 있다. 관련 사례 연구 참고: Viewpoint systems improves gear finishing using a real-time control system\\ 
•	**스마트 그리드**:  동력의 경로를 변경하고 동력의 질을 향상시키며 자가치료가 가능하도록 하기 위해, 변화하는 그리드 조건에 맞게 반응하는 전자 그리드를 제작하는 것은 현실이 되고 있다. 스마트 그리드와 관련 표준들을 진화하여 이러한 변화된 조건들을 충족시키고 있다. IDAC 시스템은 스마트 그리드 뒤에 있는 핵심 기술들 중 하나이다. 왜냐하면 IDAC 시스템은 능력을 처리하면서 I/O를 가지고, 변화하는 동력 기준에 적응하고 동력 계산을 수행하기 위해 필요한 구조를 개방하기 때문이다. 관련 사례 연구 참고: Increasing power service reliability and energy security with MicroGrids\\ 

==== 예시 ====

IDAC 시스템의 한가지 사례는 NI의 CompactRIO 시스템이다. LabVIEW 재구성 I/O (RIO) 아키텍처에 의해 작동되며, CompactRIO는 프로세서, 사용자-프로그램가능 FPGA 그리고 모듈 I/O를 LabVIEW 통합 개발 환경과 결합한다. 시스템의 기능이 매우 다양하기 때문에, CompactRIO는 개방되고 소유권이 존재하는 프로토콜과 소통하여 기존의 시스템과 결합하거나 독립 솔루션처럼 작동할 수 있다. CompactRIO 하드웨어의 소프트웨어 디자인의 기능은 개방된 실시간 Linux 운영체제에서 실행된다. 이 운영체제는 시스템이 감시와 통제 솔루션을 함께 또는 각각으로서 주문제작 되도록 해준다. 

IDAC 시스템의 다른 예는 커스텀 하드웨어와 고성능의 프로그램가능한 자동화 조절기 또는 이 두가지 시스템의 혼합에서 찾아볼 수 있다. 

==== 차별화 ====

•	**무선 센서 네트워크 기술**: IDAC와 무선 센서 네트워크 (WSN) 기술은 모두 감시 활동에 쓰일 수 있지만, 수행과 채널 수치에 따라 차이를 보인다. WSN 접속점들은 상대적으로 느린 속도(<1 kS/s)의 정기 간격을 두고 몇몇 채널에서 데이터를 얻는다. 그리고 중요하지 않은 처리들을 수행하여 그 데이터를 심층 처리를 위한 중앙 프로세서에 보낸다. 이러한 시스템은 빠른 선택을 요구하지 않는 고정적인 환경을 감시하는데 아주 적합하다. 반면에, IDAC는 1 MS/S까지 되는 속도로 수백 개의 채널들을 처리할 수 있다. 그리고 더욱 심층적인 처리를 수행하고 변화를 감지하면 이를 보고한다. 결과적으로 IDAC는 더욱 역동적인 시스템을 감시하기 위해 설계되어, 빠른 선택을 위한 자산 기반 처리를 해낸다. 이러한 두가지 기술을 함께 이용하면, IDAC를 중앙 허브로 사용하여 데이터를 수집 및 처리하고 WSN 연결점들은 메인 어플리케이션 보조에 사용할 수 있다.\\  
•	**프로그램화 가능한 로직 조절기**: IDAC와 프로그램화 가능한 로직 조절기들 (PLCs)은 통제를 위해 쓰일 수 있지만 다른 기능을 수행한다. PLC는 상대적으로 느린 순환 속도 (<1 kHz)에서 작동하고 간단한 통제 업무를 위해 설계되었다. 사용자는 시각, 움직임 또는 맞춤 프로토콜과 같은 더 고급화된 기능을 위해서 다른 시스템을 추가적으로 사용하여야 한다. 반면에 IDAC는 높은 순환 속도 (>100 kHz)를 가지고 있으며 더 고급화된 통제 알고리즘, 시각, 움직임 그리고 맞춤 프로토콜을 다룰 수 있다. PLC는 산업 기준을 제공하며 프로그램하기 쉽고 간단한 업무에 사용된다. 그러나 고기능 통제나 다른 업무를 통합하는 좀 더 복잡한 기능을 위해서는, IDAC가 훨씬 유용하다. 이 두가지는 종종 함께 짝지어져 서로 소통하면서, PLC는 메인 통제 순환을 담당하고 IDAC는 특수화된 업무를 맡는다.\\ 

아래의 표는 IDAC, 무선 센서 네트워크 그리고 PLC의 주요 차이점들을 정리한 것이다. 

{{ :파트2_80번그림.png?nolink&300 |}}
                            Comparison of IDAC, WSN Nodes and PLC
                           
==== 추천 ====

IDAC 시스템을 고려할 때, 현재와 미래 수요 모두를 염두에 두어야 한다. 누구도 미래를 예측할 수 없지만, 대비하는 것이 중요하다. 블랙박스 솔루션이 아마도 오늘날의 과제를 해결할 수도 있겠지만 그것은 미래의 변화하는 표준, 센서, 어플리케이션에 대한 유연성이 없다. 이들 항상 변화하는 변수에 적응하기 위해 개방된 플랫폼에 대해 유연성이 있는 IDAC를 선택하라. 아니면, 간단한 펌웨어와 부품을 업데이트하는 대신 전체 시스템을 교체하게 될 것이다.

==== 전망 ====

산업 부문에서 사물인터넷이 마주할 가장 큰 도전은 오늘날의 고성능 기계와 네트워크 수요를 충족시키고 이더넷 기술이 내일의 수요를 충족시키도록 발전시킬 수 있는 대역폭과 결정론을 가진 개방된, 세계적인, 이더넷 기반 통신 프로토콜의 결여이다. 이들 수요를 충족시킬 수 있는 한 기술이 시간감지 네트워크(TSN)이다. 전기 전자 엔지니어 기관The Institute of Electrical and Electronics Engineers (IEEE)은 IEEE 표준 802.1을 이들 요구사항에 맞추기 위해 TSN 태스크 그룹을 형성했다. 이들 표준이 당신의 어플리케이션을 충족시키는 것을 보장하기 위해 여전히 할 일이 많다 – IEEE와 산업 인터넷 컨소시엄 같은 기관이 당신의 목소리를 듣고 관여하게 하려면.

우리는 **National Instruments**의** James Smith**와 **Brian Phillippi**에게 **산업 데이터 취득 플랫폼에 관한 이 챕터에 대한 기여에 감사**한다.
                           
==== IV. 무선 실내 위치 측정 ====

설치된 GPS 시스템은 위치측정, 특히 계속 증가하는 모바일 최종 기기의 유행과 관련되어 방대한 가능성을 연다. 자동차 내비게이션이나 상품 수송 차량 추적에서 이들 기기의 사용은 이제 일상적인 일이다. 하지만, 여전히 빌딩 안이나 거치 협곡의 예시처럼 GPS 기반 위치 측정이 작동하지 않는 “GPS 거부 지역”으로 알려진 환경이 있다. 이것이 많은 부분들이 오늘날 실내와 실외 모든 지역에서–공항이나 회사 부지 같은 큰 인프라 매끄러운 위치 측정에 대한 증가하는 수요를 경험하고 있는 이유이다. 무선 통신 기술의 사용과 지속적인 개발은 위치 측정 범위의 이러한 간격을 좁히는 다양한 WI-FI 기반 실내 위치 측정 솔루션의 발생을 가능하게 했고 모든 수준의 가치 체인에 새로운 기회와 추가 부가 가치를 만들어냈다.

==== 실내 위치 측정 시스템의 부문간 어플리케이션 ====

실내 위치 측정 솔루션은 전통적인 GPS 기반 시스템이 건물과 큰 인프라 안에서 전파 차단과 반사로 인해 사용될 수 없을 때 이용된다. 실내 어플리케이션에서는, Wi-Fi, 광학 센서, 동작 센서 같은 다른 기술이 작동하게 된다. Wi-Fi 기반 실내 위치 측정 시스템의 어플리케이션의 다양한 분야들은 스포츠, 보안, 생산, 계획, 자동차, 건강관리, 엔터테인먼트의 전체 가치 체인을 뒤덮는다.

산업 4.0의 맥락에서, 예를 들면, 모든 수준의 가치 체인에 걸친 실내 위치 측정 시스템을 통한 인프라, 절차, 제품의 통합된 포착과 네트워킹 덕분에 새로운 기회들이 나타나고 있다. 사물인터넷은 산업 4.0의 필수적인 전제 조건이다. 그것은 절차, 작업 처리 속도 향상, 산업과 기업 안전의 증가로 거두어질 새로운 잠재적인 혜택을 가능하게 할 것이다.

제조 부문에서의 실내 위치 측정은 사람이나 차량이 기계 근처 같은 특정 영역에 있는지를 체크할 수 있게 하는 geofencing 같은 개념의 적용을 가능하게 할 것이다. 당신은 또한 특정 영역의 사람이 그곳에 있을 자격이 있는지 확인할 수 있다. 이는 작업 과정상의 투명성과 안전을 보장하는 면에서 특히 유용하다.
실내 위치 측정 시스템의 다른 적용은 화물 운반대, 제품, 포크 리프트, 심지어는 사람까지 실시간으로 위치 측정이 가능함으로 인한 자동 위치 측정계획 과정의 최적화이다. 이는 개별 위치에서 여러 위치에 걸쳐 그들을 더 안전하게 만듦에 더해 속도 상승, 연결, 계획 과정의 향상을 가능하게 한다. 마지막으로, 완전한 위치 측정 솔루션은 새로운 서비스를 위한 길을 포장한다.

실내 위치 측정 시스템은 또한 공항 같은 대규모 인프라에서의 합동 및 작동 안정성을 지원한다. 충돌한 뻔한 사고 같은 중요한 상황들이 중앙에 수집된 위치 데이터를 사고와 재앙적 상황을 방지하기 위한 카메라 감시와 결합시켜 기록될 수 있다. 추가 적용 시나리오는 공항에서 승객과 피고용인, 혹은 피고용인과 방문자의 회사 부지에서의 위치 측정이다.

스포츠 분야에서– 예를 들면 풋볼에서– 실내 위치 측정 시스템은 시합을 분석하고 수집된 데이터를 처리하고 위해 사용된다. 스포츠 활약을 운동선수의 생체 데이터와 연결시켜, 훈련 전략과 시합은 객관적으로 평가되고 최적화될 수 있다. 예들 들어, 실내 위치 측정 기술이 기반한 기술적 원조는 시각이 손상된 사람들에게 훈련 프로그램과 매일의 이동성과 접속가능성을 지원할 수 있다. Fraunhofer Institute for Integrated Circuits IIS가 시각이 손상된 사람이 그 사람이 정해진 경로를 벗어났을 때 촉각과 청각 경고 신호와 지시를 전송하기 위한 착용하는 센서 벨트를 사용하는 위치 시스템을 개발하고 있다.

주변 보조 생활(AAL)의 맥락에서, 실내 위치 측정 솔루션은 나이든 사람, 장애인, 수발이 필요한 사람을 지원하기 위함과 동시에 완전한 위치 측정 범위를 Wi-Fi와 블루투스를 통해 보장하기 위해 개발되고 있다. 어플리케이션 영역에서, 전문가들은 지적 환경 및 다양한 구성요소와 솔루션의 매끄러운 통합을 만들어내고 있다. 이는 의료 환경 감시와 geofencing 을 가능하게 할 것이다. 추락 같은 특정 사고는 그러므로 감지될 수 있고 간병인이 인지할 수 있다. 다양한 전파 탐지 기술은 매우 다양한 보조 시스템에 사용되어 사람들이 굉장히 늘어난 정도로 독립적인 삶을 살게 하고, 건강과 삶의 질 전반을 향상시킬 수 있다. Fraunhofer IIS 의 연구자들은 생체 기능을 감시하는 시스템이 위급 시에 사람들의 위치를 잡는데 도움이 된다고 주장했다.

공공 운송 분야에서, 센서 융합을 통한 위성 위치 측정(GPS)와 Wi-Fi 위치 측정, 동작 센서의 지능적 결합은 집집마다 내비게이션을 가능하게 할 수 있다. 특히, 이는 승객이 버스, 트램, 기차, 지하철 시스템을 갈아탈 때 그들의 방향을 찾기 쉽게 해준다.

==== 실내 위치 측정 솔루션의 다양한 요구 ====

그들이 매우 넓은 범위에 적용되기 때문에, 다양한 실내 위치 측정 솔루션은 각 분야의 적용에서 신뢰성과 사용자 친화성을 보장하기 위해 다양한 요구를 만족시켜야 한다. 정확성과 이용 가능성은 전통적인 GPS 기반 솔루션이 작동하지 않을 때 이용되는 이들 시스템에 특히 중요하다. 이용가능성은 기본적인 주어진 위치를 확인하는 가능성에서 모든 영역에 걸쳐 정해질 수 있는 정도의 정확성까지 다양한 수준에 걸친다. 이용가능성은 계획, 생산, AAL 같은 영역에서 개인과 회사 모두에 가장 중요하다. 그에 더해, 기술적인 구분이 인프라 기능의 면에서 만들어진다. 한 옵션은 Wi-Fi 네트워크에 기반한 박물관 안내 시스템에서 볼 수 있는 기기가 스스로 위치를 측정(자체 위치)할 수 있게 하는 인프라이다. 대안으로, 데이터가 중앙에 수집되고 처리되면 인프라가 기기 위치를 측정할 수 있다(원격 위치). 가시선과 라디오 파 전송이 빈번히 장애물(기계 같은)이나 딱딱한 벽에 방해되기 때문에 영역의 크기와 물리적인 특징은 큰 인프라, 계획, 제조에서 중요한 역할을 한다. 마찬가지로, 특정한 실내 위치 측정 솔루션은 위치 측정될 물체의 수와 속도, 혹은 측정 대상이 물체인지 사람인지에 기반하여 정해질 수 있다. 위치 측정 시스템에서 센서 기술의 결합은 생체 데이터를 감시하고 추락을 감지하듯 개인을 지원할 필요가 있는 스포츠와 AAL 시스템에 특히 유익하다. 이 맥락에서, 의료 지원을 위한 온도 데이터 같은 추가 센서 데이터를 위한 전송 속도와 빈도는 특정 사용자의 수요에 따라 정해질 수 있다. 실시간 분석 시스템을 사용하는 것 또한 특정 사건–비상사태 알람으로 경고되는-에 적절히 대응하기 위해 필요할 수 있다. 다른 중요한 문제들은 송신기 형태 및 무게에 더해 배터리 수명을 포함한다. 이들 속성이 어플리케이션에 의존하는 다양한 고려에 종속되어있기 때문이다. 실제로, 다양한 상황에서, 전송기 작동은 효과적인 실내 위치 측정 시스템의 개발에 중요하다. 거기에 더해, 위치 잡는 속도와 빈도 모두 어플리케이션에 따라 다양할 수 있기 때문에 업데이트률은 적절한 적용을 위해 최적화되어야 한다. 목표가 고객 요구에 맞추어진 실내 위치 측정 솔루션을 위한 가능한 한 최선의 디자인을 달성하는 것이므로, 비용 문제와 이용 가능성 모두 시행에 감안되어야 한다. 실내 위치 측정 시스템에 놓인 상당한 수요를 만족시키기 위해 Fraunhofer IIS는 이들 기기 기술들을 결합시키고 더 발전시키기 위해 작업 중이다.

==== 기술적 토대 ====

위에서 논한 실내 위치 측정 기술은 다양한 기술들을 물체나 사람의 위치를 알아내기 위해 사용한다. 다음은 가장 중요한 실내 위치 측정 기술과 이들 기술이 제공하는 가능성에 대한 개관을 제공한다.

**개관**

전계 강도 측정-박물관 같은 건물 안에서 작동하며 Wi-Fi나 블루투스 네트워크 같은 현존 인프라를 사용하는-은 전계 강도 분산을 측정하고 그것을 데이터베이스에 저장된 전계 강도 지도와 위치를 계산하기 위해 비교한다. 여러 측정기의 정확도를 가진 이들 시스템은 박물관이나 쇼핑 몰에서 안내와 정보 시스템에 사용될 수 있고 혹은 구조대원의 안전을 위기 상황에서 보장하기 위해 사용될 수 있다. 신호등 솔루션은 또한 블루투스 저전력(BLE)이나 RFID(Radio-Frequency Identification) 같은 단거리 라디오 시스템을 사람이나 기기가 위치한 영역을 알아내기 위해 사용하여 위치 잡기를 가능하게 한다. 이는 쇼핑몰에서의 도난 방비와 내비게이션에 유용하다.

각도 측정 기술에서, 전송기의 위치는 안테나 배열에서의 라디오 신호 발생각에 기반하여 미터 단위 정확도로 계산된다. 이 시스템은 구조대의 위치를 측정하거나 공항에서 보안 어플레키이션을 위해 사용될 수 있다.

주행시간 기반 전파탐지법은 라디오 신호가 전송기와 수신기 사이를 이동하는 시간 간격을 측정하여 위치를 알아낼 수 있게 한다. 센티미터 단위 정확성을 제공하는 위치 잡기 솔루션은 스포츠와 차량을 위한 위성 내비게이션(GNSS)에 사용된다.

센서 네트워크는 가까운 관계를 센서 접속점 간의 관계나 거리를 측정하기 위해 사용하고, 자신의 위치를 위치가 알려진 접속점에 기반하여 계산한다.

**비교**

다양한 위치 측정 기술은 결합될 수 있으며, 이는 그들이 내부 센서 기술과 사건 감지 같은 다른 기술과 기법의 지원을 받을 수 있다는 것을 의미한다. 시스템 결합은 높은 정확성, 신뢰성, 이용 가능성을 보장한다. 환경 모델은 또한 경로 계획 같은 어플리케이션에 유용한 위치 주변을 포함한다. 기법에 의존하여, 위치 잡기 데이터는 어떤 것이 있는 위치와 움직이고 있는 목적지와 속도로 구성된다. 사용되는 센서 기술에 의존하여, 사람들의 생체 기능이나 기기의 기능성 또한 전해질 수 있다.

==== Wi-Fi 기반 실내 위치 측정의 미래 ====

전반적으로, 실내 위치 측정의 전체 영역은 이제 내부 공간을 정복하기 시작한 전도 유망한 트렌드이다. 기본 실내 이용 가능성에 더해, 주요 관심사 중 하나는 특히 정확성 면에서의 성능 향상이다. 한 중요한 목표는 위치 측정을 가능한 한 작은 인프라를 사용하거나 심지어는 인프라를 전혀 사용하지 않고 달성하는 것이다. 이는 매끄럽고 신뢰성 있는 물체의 위치 측정을 실내와 실외 모두에서 가능하게 할 것이다. 널리 퍼지는 스마트폰의 이용가능성과 직거래 같은 새로운 시장의 발전 결과로 인해, 우리는 매끄러운 실내/실외 위치 측정과 내비게이션이 이후 수 년 안에 가능해지리라는 것을 예측할 수 있다. 통합의 측면에서, 중심 역할은 한편으로는 질이 높아져가는 고급 센서와, 다른 한편으로는 이들 센서의 대규모 물량에 의해 수행된다. 다른 유망한 접근법은 “유사위성”의 사용에 관련된다. 이들 “유사 위성”은 위성 신호를 건물 안에서 증폭시켜 일반 GPS 수신기를 통해 실내 위치 측정을 가능하게 하는 전송기이다. 추가로, 우리는 증가하는 소형화된 위치측정 부품들이 기기, 인프라, 차량에 표준으로 통합되어 서로 소통 가능하게 하리라고 예측한다. 이는 새로운 표준, 프로토콜, 인터페이스가 탄생하게 한다. 증가하는 표준화, 통합, 네트워킹은 기술 성능을 향상시키고 새로운 어플리케이션과 서비스-산업 4.0의 영역에서는 자동차들이 서로 연결되거나(Car2Car) 주차장이나 기계 같은 인프라와 연결되는(Car2X)-를 가능하게 할 것이다.
우리는 Fraunhofer IIS 의 Dr. Stephan Otto 에게 그가 이 챕터에서 무선 실내 위치 측정에 기여한 것에 감사한다.

==== 사례 연구: KLM ====

indoo.rs 와 협력하고 있는 KLM Royal Dutch Airlines은 암스테르담 스키폴 공항에서 환승 승객에 의해 사용될 그들의 KLM 앱을 실내 위치 잡기와 내비게이션 프로토타입 기능성 면에서 향상시켰다. iOS와 안드로이드에서 가동되는 그 어플리케이션은 사용자의 위치를 지도상의 점으로 보여주며 현재 위치에서 다음 게이트로 가는 경로를 보여준다. 그 어플리케이션은 또한 그곳으로 걸어가는데 필요한 시간도 계산해준다.

프로젝트의 주요 목적은 게이트 폐쇄 시간을 향상시키고 환승 시간을 추가 서비스를 고객에게 제공하여 단축시키는 것이다. 또한, 항공사의 고객에게 지도 지시를 제공하여, 그들의 도착 게이트에서 연결된 항공편으로의 여정이 훨씬 더 쉬워질 것이다.

전송 영역에서 정확한 위치 잡기를 가능하게 하기 위해, iBeacons가 KLM 키오스크에 설치되었다. KLM 앱을 폰에 설치한 고객이 iBeacon을 통과할 때, 경로 정보가 이용 가능하다면 푸시 알림이 스마트폰에 보내질 것이다. 만약 사용자가 이 정보를 좋다고 결정한다면, 앱은 열리고 현재 위치에서 다음 게이트로 가는 경로를 보여줄 것이다.

내비게이션 서비스는 애플과 안드로이드 앱 스토어에서 다운로드할 수 있는 최신 출시된 KLM앱에서 이용 가능하다.

==== 프로젝트 관리 측면 ====

프로젝트 특유의 과제는 아래와 같이 요약될 수 있다:

•	스키폴 공항에 위치한 솔루션은 BLE 신호등이 환승 구역에 설치되는 것과 사용자의 스마트폰에서 나온 이들 신호의 수신을 요구한다. 역사적으로, 블루투스는 배터리 소모로 유명했다. 그래서 KLM은 앱 사용자들이 내비게이션 기능을 사용하면서 블루투스 4.0(블루투스 저전력(BLE))을 켜두지 않는 것을 우려했다. 또한 모든 사용자가 BLE를 표준으로 지원하는 스마트폰을 소유하지는 않는다.\\ 
•	후자의 제약은 시간이 지나 새로운 스마트폰 세대가 BLE를 표준으로 지원하게 됨에 따라 무관해질 것이다. 새롭고 떠오르는 기술이 옛 기기들과 약간의 호환성 문제를 겪는 것은 흔한 일이다. 초기 블루투스 버전과 비교하면, 블루투스 4.0은 매우 낮은 전력 소모가 특징이다(예를 들면, iBeacon은 한 배터리로 4년간 켜놓을 수 있다). 새 스마트폰에서 가능한 블루투스 연결을 가지는 것은 초기 블루투스 버전에 비해 전체 배터리의 오직 작은 부분만을 차지한다. BLE의 핵심 혜택에 대한 설명은 블루투스 기반 솔루션에 대한 반대를 넘어서는데 도움이 된다.\\ 
•	작은iBeacon은 전송 영역의 KLM 키오스크에 설치되었다. 흥미롭게도, 신호는 이들 키오스크를 지나가는 사람들의 호기심을 끌었고 때때로 제거되거나 치워졌다. 공항에서의 iBeacon 설치는 프로젝트가 공항이 아닌 항공사와 협력하고 있었기 때문에 다양한 이유로 여러 제한에 종속되어 있다 그러므로, 신호는 아무 장소에나 설치되지 못하고 KLM 키오스크(예를 들어, 더 높은 곳)에 설치된다. 작은 iBeacon 기기는 분실을 방지하기 위해 접착제로 확고히 고정되었다.\\ 

==== 학습과 Best-Practice ====

여러 이해당사자가 공항의 사업 운용 환경(예를 들면, 공항 오퍼레이터, 항공사)에 관련되어 있다. 성공적인 공항 내 실내 내비게이션 시스템은 다양한 참가자들의 협력을 요구한다: 기술 회사, 건축설비 관리사, 승객 서비스.

모든 건물은 고유의 특징을 가지고 있으며 이들은 BLE 신호의 설치에서 고려될 필요가 있다. 공항들은 365일 1년 건축 부지로 간주될 수 있다: 외관과 공항 영역의 배열이 계속 진행 중인 변화(임시 진급, 추가 스탠드 등)에 종속된다. 블루투스 신호는 단열과 흡수 재질의 물체에 영향을 받는다. 이런 이유로, 신호등은 고도의 가시성이 보장되는 장소에 설치되어야 계속 변화하는 환경의 영향이 최소화될 수 있다.

포함된 높은 수준의 혁신은 IoT 프로젝트와 계획이 시장의 사용자들이 그런 기술들의 잠재력에 대한 교육을 받는 것을 요구당한다는 것을 의미한다. 오직 그때 운용자와 사용자가 가치를 완전히 인식할 수 있다.

우리는 **indoo.rs**의 **COO**인 **Bernd Gruber**에게 이 **사례 연구에 대한 지원에 감사**한다.

==== c. IoT 기회 관리 ====

보통, 한 발상이 첫 품질 관문을 통과한 뒤에는, 투자하기에 매력적인 견고한 사업 사례 문서를 만든다는 목표를 위해 작은 팀이 발상의 개선과 입증을 위해 소집된다. 일반적으로, 작은 팀은 결정을 내릴 투자 위원회에 발표하기 전에 IoT 사업 모델에 수주, 혹은 수개월간 공을 들인다. 만약 모든 IoT 계획이 유사한 IoT 사업 모델 접근법을 따른다면, 다양한 제안들을 비교하고 순위 매기기가 더 쉬울 것이다.

Bosch에서는, IoT 사업 모델을 개발하는 프로젝트 팀들은 영역 전문가, 사업 모델 코치, 마케팅 컨설턴트같은 다양한 능력을 가진 피고용인을 포함한다. 이 조직상 파견과 발상에 관해 처음부터 열정적인 리더를 모두 가지는 것은 매우 중요하다. 다른 성공요인은 “podular” 조직 구조이다. Silke Vogel은 설명한다 그것이 의미하는 바를: “자주적으로 참여하는 고도로 동기부여되고 열정이 있는 팀 멤버다. 그들은 더 결정적인 힘을 가지고, “사내기업가”방식으로 행동하며, 고객에 더 가깝다. 또한 대기업의 확립된 구조와 경쟁력에서 혜택을 받는다.. 이는 그들이 더 빠르고 효율적이 되게 만든다.”

==== 사업 모델 개발 ====

확립된 사업 모델 캔버스는 실제로 특정한 IoT 사업 모델을 다루지는 않기 때문에, Bosch의 팀은 사업 모델 개발을 위한 IoT 전문 접근법을 개발해왔다. Bosch Software Innovations에서 이 팀의 관리자인 Veronika Brandt:// “복잡한 가치 체인의 파트너 생태계 복잡성 같은 IoT 전문 측면을 다루는 것은 IoT에 매우 중요하다. 이는 사업 모델이 분명히 연결된 파트너 가치 제안을 필요로 한다는 것을 의미한다. 다른 IoT 전문 측면은 커넥티드 사물에서 나온 데이터와 이 정보로 만들어진 서비스의 사용이다. 이 때문에, 우리는 Osterwalder canvas 의 확장인 IoT Business Model Builder 를 개발했다. 기회 관리 단계에서, 그것은 사업 모델의 구성요소를 정의하는 과정에서 가이드로 작용한다. 보통, 입력은 다듬어진 발상이며 출력은 사업 사례이다.”//

{{ :파트2_5번그림.png?300 |}}
          IoT Business Model Builder (Source: Bosch Software Innovations, 2015)

**IoT Business Model Builder**의 주요 구성요소는 다음 부분에 정의된다. 집을 짓는 것처럼 우리는 바닥부더 시작한다:

•	전략 묻기: 이 단계는 사업모델의 기초를 세우고 IoT 전략이나 기업의 ioT 비전의 지지를 보장한다. 이는 강령에서 사업 모델의 목표를 정의하고 그 중단기 목표의 윤곽을 그린다. “미래보장”의 수행은 어떻게 사업 모델이 미래 과제를 다룰 것인지를 나타내어야 한다. 이는 어떻게 핵심 기능(사업 모델이 모방되는 것을 어렵게 하는)과 미래 변화에 대한 반응성 같은 차별성의 개발을 조성할 것인지에 대한 생각들을 포함한다. 전략 묻기는 또한 제공된 것에 대한 짧은 설명을 포함한다.

•	가치 제안: 고객을 위한 공급의 매력을 향상시키기 위해, 타겟 그룹을 분할하고, 가치 제안을 다듬고, 고객 채널을 정하는(애프터 세일즈의 의식부터 고객 여정에서의 모든 접점에서의 고객을 위한 인터페이스) 믿을 수 있다고 증명된 접근법이 채용될 수 있다. IoT 솔루션들이 종종 강한 파트너 생태계에 의존하기 때문에, 가치 제안은 파트너를 고객과 같은 정도로 존중해야 한다. 첫째, 파트너가 이미 정해지지 않지 않은 이상(전략 파트너십이나 관계가 존재하지 않는다면), 그들의 역할은 정해질 필요가 있다(정보 제공자, 브로커 사업자). 그리고, 우리는 각 파트너 역할(혹은 후보)의 파트너 가치 제안의 윤곽을 그리며 “그들에게 어떤 이익이 있는가”를 정할 필요가 있다. 마지막으로, 예를 들면(고객이 채널로 정해질 수도 있다) “다른 파트너들과 마찬가지로” 파트너 채널이 정해져야 한다.

•	고객 여정: 고객의 관점에서 양단간 솔루션을 설명하는 것은 고객이 적절하다고 생각하는 제공된 것의 요소를 강조하는데 도움이 된다. 여기, 제공된 것의 실제 사용자/고객에 집중하는 것은 만약 이것이 당신의 고객이나 고객의 고객이라는 것과 상관없이(B2B2C 솔루션에서) 적절하다. 고객 여정을 정의하는 것은 다른 긍정적 효과가 있다: 그것은 고객이 확인해온 모든 적절한 채널을 확실하게 하고 이들은 여정의 모든 단계에서 애프터 세일즈를 인지하며 고객 접점에 봉사한다.

•	부가가치: 한번 솔루션이 정해지면, 부가된 가치는 실증될 수 있다. 부가 가치의 핵심 요소는 이해당사자 네트워크다. 이는 관련 당사자(기업, 파트너, 고객)를 접속점으로 보여주고 가치와 서비스 흐름을 이들 접속점 사이에서 보여주는 플로우 차트에 보통 묘사된다. 네트워크의 구성 요소는 당사자의 능력이다: 그들은 솔루션을 지원할 수 있는 기술, 자원, 노하우의 혼합이다. 능력 자산은 어떤 접속점이 특정 서비스를 인도하는데 가장 적합한지 정하는 것을 돕는다. 한번 네트워크가 정해지면, 이 접속점이 무슨 커넥티드 사물을 관리하는지, 어떤 부가가치 정보(혹은 커넥티드 사물에서 나온)를 인도하는지, 어떤 서비스를 인도하는지가 각 접속점에서 잡혀야한다.

•	사업 사례: 한번 부가가치가 정해지면, 사업 사례를 계산하기는 쉽다: 가장 가격에 관련되는 측면은 부가가치 단계에 나타나고 추정 이윤은 고객과 파트너 가치 제안에서 취해져야 한다. 관련된 정당한 접근법은 네트워크에 관련된 모든 당사자를 가로지르는 솔루션 소유권의 총 비용(TCO)을 계산하고 이해당사자간에 공평한 방식으로 수익을 배치하는 수익 모형을 정하는 것이다. 이는 모든 관련 당사자 간 투명성을 요구하며 이는 IoT 생태계에서 신뢰와 전략적 파트너십의 중요성을 다시 한번 강조하는 것이다. 사업 사례 계산에 사용될 수 있는 여러 기술과 견본이 있지만, 우리는 모든 IoT 계획을 통틀어 사업 모델을 쉽게 비교할 수 있게 해주는 조화를 추천한다.

•	사업 영향과 차후 사업 모델: 우리의 다이어그램에서 집의 굴뚝은 사업 사례와의 결합에서 보아야 할 사업 모델의 두 금전적 효과를 나타낸다. 예를 들면, 만약 사업 사례가 장래성이 있는 것 같지 않지만 회사가 사업 모델을 새 시장에 진입하거나 새 기술에 접근하기 위해 시행할 필요가 있다면, 이들 전략적 측면은 기록되어야 한다. 두번째 굴뚝, “차후 사업 모델”은 매우 IoT 특유의 것이다: 사업 모델을 정하고 커넥티드 기기로 모든 관련 데이터를 얻었을 때, 팀들이 어떻게 데이터를 개선할지(가령, 새로운 부가가치 정보와 결합시키거나)에 관한 새로운 발상을 내놓고 새로운 서비스를 만들어내는 일은 매우 흔하다. 어떤 발상들은 같은 사업 모델안에서는 개선될 수 없고 분리된 사업 모델에서 개발이 가능하다. 하지만, 그들은 자신들이 만들고 있는 사업 모델을 볼 필요가 있다.

**파트너 생태계**

IoT 파트너 생태계 개발에 관한 다음 조언은 Bosch Software Innovations 의 Director Partner Management 인 Anuj Jain에게서 나온 것이다:

IoT 가치 체인은 길고 넓며, 물리적 자산, 운영 서비스, 디지털 서비스를 망라한다. IoT 계획을 주요 고려사항은:

•	주어진 현재 능력을 실제로 인도할 수 있는 가치 체인의 요소는 무엇인가?
•	IoT 가치 체인 생테계에서 하나의 요구를 통제할 수 있는가?
실제로, 어떤 개별 회사가 IoT 가치 체인의 모든 측면에 전문화되는 것은 가능하지도 합리적이지도 않다. IoT 계획에서, 바른 전략은 비전, 열정, 목적을 공유하는 파트너 생태계이다. 이는 합리적인 비용으로 IoT 프로젝트의 성공에 필수적인 요소인 전문가 노하우와 전문기술에 빠른 접근을 허용한다. 잘 만들어진 파트너 생태계는 시장에 시간을 가속시키고, 각 이해당사자의 투자회수(ROI)를 향상시키며, 고객 경험을 개선한다. 그것은 또한 고객에게 그들의 투자가 전체 가치 체인에서 지속적인 지원과 혁신을 가질 것이라고 보장한다.

역사적으로, Daimler, Airbus, Microsoft, IBM 같은 오직 큰, 자리잡힌 베히모스가 파트너 생태계를 만드는 데 노력했다. 이들 사례에서, “베히보스”는 일반적으로 막대한 영향력을 행사하고 종종 생태계의 성격을 결정하는 생태계의 중심이었다. IoT는 부가가치 파트너 네트워크 및 조직 협력의 생태계를 대중화하고 있으며 이느 경쟁우위를 가져올 것이다. 대기업과 작은 기업 모두 유기적으로 떠오르고 더 평등하고 협력적인 파트너로 이끄는 더 확산된, 덜 중앙집권적인 생태계에서 성공적으로 일하고 있다.

성공적인 생태계의 대중적인 몇몇 사례를 보자:

•	가장 먼저 떠오르는 것은 애플과 음악 산업의 예이다. 음악 산업은 자산(음악 저작권)을 보유한다. 스티브 잡스는 음악을 팬들에게 제공할 합법이며 감당할만하고 쉬운 방법을 제공할 기회를 발견했다. 애플은 플랫폼을 만들어냈고 잘 운영했다(운영 서비스와 디지털 서비스). 애플은 생태계를 통제하는데 성공했다.

•	흥분되는 사례는DriveNow다. BMW 는 위대한 자동차(물리적 자산)를 제조한다. Sixt는 확장된 경험과 경쟁력을 차량 관리와 고객 관리(운영 서비스)에 가진다. 더 유연한 기반에서 자동차를 제공하는 개념이 만들어졌다. 두 조직이 플랫폼– DriveNow (디지털 서비스)을 개발하기 위해 손을 잡았다. 두 파트너는 눈 높이에서 일하고 있으며 파트너십에 크게 공헌하고 있다.

•	다른 흥미로운 생태계 전투는 자동차 인포테인먼트에 관련된 순간에 일어나고 있다. 이것은 전통적으로 OEM이 통제하던 고비용, 고이윤 장비이다. 그것은 OEM이 잃기를 원하지 않는 고객에게의 직접적인 연결을 허용한다. 그것은 도전과 기회에 관한 것이다. 구글과 애플은 그들의 커넥티드 서비스로 들어가 균형을 깨뜨렸다. 조정은 만들어지고 있지만 최종적인 안정된 생태계는 아직 확립되지 않았다.

고객들은 이제 그들이 조립해야하는 빌딩 블록의 모음이 아닌 양단간 솔루션을 찾고 있다. 고객들은 개방된 표준과 상호운용성을 기대한다. 고객들은 그들의 운용상의 필요성에 맞춰 진화하는 제품과 솔루션을 요구한다. 현재 우리는 IoT 기술의 사용에 관해서는 그저 표면을 긁고 있을 뿐이다. IoT 솔루션이 더 많은 가치를 최종 소비자에게 주기 위해 수평과 수직 모두로 계속 확장될 것이 기대된다. 파트너 생태계는 고객이 증가하는 복잡한 문제를 다루가 위해 더 깊은 산업 전문 지식과 산업 어플리케이션의 우물에 접근하는 것을 제공한다.

우리는 최근 소형 산업 전동 공구(물리적 자산)을 위한 ‘디지털 운용 서비스’를 향상시키기 위한 프로젝트에서 일하면서 이 상황을 접한다. 옵션은 이것을 폐쇄적으로 유지하거나 개방 표준으로 만들어 모든 제조사의 소형 전동공구와의 통합을 허용하는 것이었다. 우리는 산업 인터넷 컨소시엄에 이것을 소형 산업 공구의 테스트베드로 만들 것을성공적으로 제안함으로서 후자를 택했고 게다가 플랫폼을 개방했다. Bosch는 전반적인 솔루션에서 최상의 경쟁력을 가져오기 위해 Tech Mahindra, Cisco, Mongo DB, Dassault Systems과 함께 생태계를 확립했다.

생태계의 중요한 부분은 알맞은 파트너를 확인하는 것이다. 그런 생태계는 하청과 맞대고 이윤을 공유하는 것에 기초했을 경우에 가장 잘 작동할 수 있다. 이것은 각 이해당사자가 생태계에 대한 자신의 기여에 다른 생각을 가지고 있기 때문에 말처럼 쉽지 않다. 생태계 파트너 간의 상호 신뢰는 매우 중요하다. 고객 수준에서 협력하는 능력(사업 세계에서 가장 두려워하는 것)은 가장 가치있는 파트너십이다. go-to-marke 협력에서 요구되는 신뢰는 막대하다. 그것이 상대의 제품과 전문시술에 대한 믿음만이 아니라두 당사자가 상대가 상호 이익을 위해 일할 것이라고 믿기 때문이다.

우리가 앞에서 논한 “두 세계의 충돌”로 돌아가자. 제조업 진영과 인터넷 진영 중 어떤 진영에 당신이 속하는 가를 확인하는 것은 중요하다. 어떻게 이것이 현실적으로 능력 인도와 시장 접근으로 번역될 수 있는가? 우리는 핵심 능력에 집중하고 생태계의 유기적 개발을 허용해야 하는가? 혹은 중요한(아마도 통제하는) 역할을 형성중인 생태계에서 목표로 해야하는가? 우리는 어디서 시작해야 하는가? 우리가:

•	정확한 역할을 정해야 하는가?

•	법적 기초나 전략적 파트너십 협약을 확립해야 하는가?

•	새로운 제품 개발에 협조해야 하는가?

•	공동 시판 활동-공식 발표, 선구자적 리더십 이벤트, 온라인 회의 등을 시작해야 하는가?

IoT는 여전히 초기 단계에 있으며, 선행 투자를 요구하고, 즉각적인 수익 (다음 사분기라던가)은 얻을 수 없지만 대신에 좋은 장기 수익의 기초를 깔 수 있다. 대부분의 부분에서, 중간 관리 (단기간 수 지향)은 이 기대상의 부조화를 관리하기가 어려움을 발견할 것이다. 더욱이, IoT 프로젝트 기간은 다양한 수직과 수평에 걸친다. 여전히 그런 계획을 선도하는데 가장 적합한 그룹에 대한 명료성의 부족이 있으며, 많은 팀과 개인은 정치운동을 시작했다. 그런 파트너십은 이들 복잡성을 다루고 방향을 제시하기 위해 C수준 (어떤 때는 보드)으로 막대한 개입과 투자를 요구한다.

조직들은 그저 “당신을 사랑해”라고 말할 뿐인 협약 더미에 사인하는데 낭비할 시간이나 돈이 충분하지 않다. 성공적인 생태계는 높은 수준의 신뢰, 알맞은 소통 방식, 상호보완적인 기능을 포함한다. 극단적인 신중함이 그런 생태계를 설립하는데 요구된다.

**IoT 사업 사례 개발**

사업 모델의 모든 전략적 측면을 이해하는 것이 중요하지만, 많은 최고 중역들은 양적 관점, 즉, 견고한 사업 사례에 특정한 관심을 가진다.

{{ :파트2_6번그림.png?300 |}}
                             Business Case Context

사업 사례가 항상 진보적이기 때문에, 어떤 관리자들은 피고용인들이 엑셀에 기반해 작업한 성과에 냉소적인 시각을 가진다. 하지만 대부분의 관리자들은 이들 작업이 팀이 정말로 사업 모델의 상세한 부분에까지 모든 측면을 생각하도록 하는데 좋은 방법이라고 동의한다. 많은 예산 논의는 상세한 사업 사례 계산의 질뿐 아니라, 이 계산의 결과 팀이 제시한 단일 숫자에 의해서도 결정되어왔다. 이 맥락에서, 개발되고 있는 사업 사례의 범위를 이해하는 것은 특히 중요하다. 서문에 나온 자산과 IoT 솔루션간의 차이를 상기하라: 사업 사례가 완전히 자산에만 관련되는 것이든 IoT 솔루션에만 관한 것이든 이해하고 소통하는 것이 절대적으로 중요하다. 우리가 이미 많이 예시로 사용했던 eCall을 예로 들자: 당신이 eCall 서비스 만으로 얼마나 많은(혹은 적은) 돈을 벌 수 있는가에 대한 사업 사례를 계산하는 것인지 아니면 얼마나 많은(혹은) 적은 자동차를 eCall 서비스 제공(혹은 비제공)을 통해 팔 수 있을지를 계산하는 것인지를 이해하는 것이 중요하다. “지역” IoT 솔루션의 ROI는 항상 긍정적이지는 않다는 점을 명심하라. 많은 사례에서, 추가적 투자는 자산의 관점에서 “경쟁을 위한 비용”일 것이다.

IoT 솔루션의 지역 ROI에 대해 좀더 자세히 말해보자. 아래 그림은 일반적인 IoT 사업 사례 모델의 개관을 제공한다. 이 모델은 모든 IoT 솔루션이 자산 향상 (예를 들면, 자산 하드웨어)과 자산의 새로운 연결성을 개선하여 시행되는 서비스의 결합으로 구성되어 있다는 간단한 가정에 기반한다. 이 서비스는 완전히 자동화된 IT 서비스이거나, 사람이 조작하는 콜센터 같은 서비스 이거나, 둘 다일 수도 있다. 그래서 자연스럽게, 자산 향상과 서비스는 비용과 이윤 양쪽 측면 모두에 나타난다. 비용 면에서, 우리는 보통 자본 지출 (CAPEX)과 운용 지출 (CAPEX) 사이를 식별해야 한다. 반면 이윤 측면에서는 선행 투자 이익 (예를 들면, 하드웨어 판매나 서비스 가입 비용)과 순환수익 (예를 들면, 서비스 구독료)간을 식별해야 한다. 이 모든 것을 하나로 합쳐서 생각하는 것은 “지역” IoT 솔루션 ROI를 계산하는데 도움이 된다. 실제로 로켓 과학은 아니지만, 우리의 경험에서는 IoT 사업 사례를 팔 때는 그 주요 요소를 아래와 비슷한 방법으로 시각화시키는 것이 꽤 도움이 된다.

다음 시각은 아래 그림에 나와있는 전반적인 사업 사례이다. 다시, 이것은 자산 향상과 서비스 둘 다 보아야 한다. 하지만, 이 시각에서 우리는 또한 한쪽에서는 비용 절감과 작동 효율을, 다른 쪽에서는 차별화와 전략적 이익을 보아야 한다. 어떤 사례에서는, 이를 수량화하는 것이 가능할 것이다. 다른 사례에서는, 이 사례는 양적으로 논해질 수 없을 것이다. 어떤 사례든, 매우 구조적인 방법으로 전반적인 사업 사례들의 이들 다른 측면을 나타내는 것은 유용하다.

{{ :파트2_7번그림.png?300 |}}
                         Overall IoT Business Case

**사업 사례 과제**

처음 보기에는 분명하지 않지만 IoT 사업 사례에는 물론 많은 과제가 있다. 그의 경험에 기반하여, University of St. Gallen 의Felix Wortmann은 두 중요한 IoT 사업 사례 과제를 지적한다:

//“우선, IoT 하드웨어의 개발을 위한 고정 원가는 과소평가되어서는 안 된다. 이것이 전통적인 하드웨어 공동체에는 분명 새로운 것이 아님에도, 소프트웨어 배경을 가진 사람들은 종종 새로운 개발 방법론과 Arduino and Raspberry Pi 맥락에서의 최신 진보가 근본적으로 하드웨어 개발의 법칙과 경제를 바꾸었다고 생각한다. 그리고 Arduino sets이 50$ 미만으로 가능했던 사례처럼 오늘날 첫 프로토타입이 저 예산 하드웨어에서 실현될 수 있다. 하지만 그 분야에 실제로 배치될 수 있는 신뢰성 있는 하드웨어를 만드는 것은 여전히 매우 높은 관련 비용이 든다. 그것은 단순히 초기 디자인과 시제품화의 문제가 아니다. 테스트와 증명에 요구되는 투자와 IoT 능력을 실제로 통합시키는 비용 또한 고려되어야 한다. 이는 매우 초기에 첫 이윤이 생성되기 전에 발생하는 막대한 고정 원가를 고려해야 함을 의미한다. 이런 이유로 막대한 위험이 있는 것이다. 거기에 더해, 사업 모델은 종종 고정 원가에 대처하고 단위 원가를 가능하게 하기 위해 규모의 경제에 의존한다. 이런 생각들을 묘사하기 위해, 전기 자전거를 위한 보안 솔루션의 사업 사례를 예로 들어보자. 초기 가정은 센서가 자전거 외부에 간단히 부착될 수 있다는 것이었다. 하지만, 전반적인 사업 사례를 더 깊게 파고들어가자, 설득력 있는 사용 사례를 제공하고 수용 가능한 단위 원가를 성취하기 위해서는, 센서가 자전거의 전동장치 바로 안에 디자인되어야 한다는 것이 드러났다. 이는 초기 투자를 극적으로 증가시켰고 전반적인 사업 사례에 근본적으로 영향을 주었다.

둘째로, IoT가능 커넥티드 제품은 지속적으로 작동 비용을 만들어내는 백엔드 인프라를 요구한다. 이는 판매된 후에는 비용을 만들어내지 않는 비 커넥티드 제품과의 근본적인 차이이다. 그러므로, 커넥티드 제품의 작동 비용은 논의되어야 한다. 그들은 일시불 판매 가격으로 계산되거나, 진행 지불이 도입되어야 한다. 하지만, 이용 회수제나 구독 기반 모델은 보통 하드웨어가 작동하기 시작했을 때 심각한 고객 수용 문제에 직면한다. 소비자 맥락에서는 특히, 사람들은 커넥티드든 아니든 물리적 물체에 지속 지불을 하고 싶어하지 않는다. 이는 작동 비용이 판매 가격 안에 계산되어야 한다는 것을 의미한다. 위험 보험의 일종으로, 회사들은 계획적 구식화 같은 다양한 전술을 사용한다. 또한 회사들은 IoT 기반 제품이 제공자가 중앙 인프라를 중단하더라도 여전히 작동될 수 있다는 것을 보장하려고 시도한다. Philips Hue를 예로 들자: 이 커넥티드 전구는 필립스 백엔드가 없이도 로컬 게이트웨이 통제를 기반으로 작동하도록 디자인되었다. 이는 효과적으로 필립스에게 “우아한” 출구 전략을 위한 기회를 준다: 만약 고유의 백엔드 서비스를 중단한다면, 고객은 기능저하를 겪겠지만 제품은 여전히 작동한다.”//

이들은 그저 IoT 사업 사례 복잡성의 몇몇 예시일 뿐이지만 개발을 위한 구조적 과정이 유용한 이유와 특정 수준의 성숙도에 도달하는데 시간이 걸리는지를 보여준다.

==== 효과 & 위험 분석 ====

사업 모델과 특히 사업 사례가 미래 가치 흐름을 다루기 때문에, 그들은 불확실성에 종속된다. 의사 결정자의 투명성을 증가시키고 그런 불확실 요소들(예를 들면, 특정한 비용 추정이 매우 공허하다면, 이들 추정을 위해 다음 단계에서 제안을 요구하는 것이 도움이 될 것이다)을 다루기 위한 작업 필요성을 추론하기 위해 사업 모델의 불확실성도를 강조하는 것이 중요하다.

위험을 줄이는 유용한 도구는 시나리오 계획이다. 정해진 수치(즉, 사업 모델을 위해 추정된 타겟 그룹, 기간 등.)에 기반해, 다양한 미래 시나리오가 그려진다. 이는 트렌드나 원인-결과 관계에 기반하여 행해진다. 다음 단계에서, 계획은 어떻게 사업 모델이 가장 잘 미래 시나리오에 대응할 수 있을지를 정하기 위해 작업을 해야 한다. 전략적 맥락에서 영향과 가치를 만들어내는 사업 모델의 이런 요소들을 탐색하는 것이 중요하다. 다양한 미래 기회를 실행하기 위해, 약한 부분과 강한 요소는 밝혀져야 하며, 이는 미래에도 경쟁력이 있는 사업모델의 개발을 가능하게 할 것이다.

**종합해서 만들기: 사업 계획**

IoT 사업 모델 빌더에 기반할 수 있는 개발된 사업 모델을 가지면, 팀은 실행 가능한 사업 계획을 종합하여 만들 필요가 있다. 물론 이는 사업 모델의 많은 요소들을 재사용할 것이지만 계획 실행에 강하게 초점을 둘 것이다. 실리콘 밸리의 가장 존경 받는 벤처 자본 회사인 Sequoia Capital은 시작 시 다음 접근법을 추천한다 [SC1]:

•	목적: 사업을 단일, 평서문으로 정의하라

•	문제: 고객의 고통과 어떻게 오늘 대응하고 있는지를 묘사하라

•	솔루션: 당신의 솔루션이 어떻게 고객의 문제를 다루었는지를 보여주는 사용례를 제공하라. 제품의 물리적 위치를 묘사하라.

•	왜 지금: 당신의 솔루션 범주의 역사적 진화를 묘사하라. 오늘날 파괴를 가능하게 하는 요소들을 묘사하라.

•	시장 크기: 이용 가능한 전체 시장과 정확한 고객 프로필에 기반하여 당신의 솔루션이 목표로 하는 부분을 묘사하라.

•	경쟁: 주요 경쟁자를 묘사하고 경쟁우위를 비교하라

•	솔루션: 주요 지적 자산에 더해 형태 인자, 기능 요소, 구성과 개발 로드맵을 묘사하라

•	사업 모델: 이윤과 가격결정 모델, 평균적인 계좌 크기, 고객평생가치, 판매&유통 모델, 현재 고객 파이프라인의 설명(있다면)

•	팀: 새로운 사업을 위한 제안된 조직적 관리 구조

•	재정: 기되 대는(즉 3년) 이익과 손실 계획, 균형 시트와 현금 흐름 계획, 투자 요구사항
우리는 Sequoia Capital의 본래 리스트에 내부 프로젝트의 필요에 들어맞게 하기 위해 약간의 작은 변화를 가했다. 하지만 일반적으로는 “인터넷 캠프”의 지도를 따르고 내부 프로젝트 제안에 적용시키는 것이 좋아보인다. 많은 회사들은 이미 이 구조에 대조 검토되어야 할 프로젝트 제안을 위한 표준 템플릿을 가지고 있다.

==== 기회 선택 ====

다양한 IoT 투자 계획에 대해 사업 계획 발표를 들을 운영위원회에게 있어 주요 의문은: 어떻게 이들 다양한 기회들을 평가하고 우선순위를 매길 것인가? 기업 환경에서 일정량의 이면 영향력이 항상 있을 것이지만, 그것은 이상적으로 한 차트에서 여러 기회들을 계획하고 그들을 비교 가능하게 만드는데 유용할 것이다. 이 부분의 시작에서 정의된 대로, 기준평가가 전체 IoT 전략에 맞춰 조정되는 것이 중요하다.

“지역” 사업 사례 대 관련 자산의 전반적 경쟁력에 대한 IoT 솔루션의 기여에 대한 우리의 이전 논의를 감안하면, 이 두 관점을 IoT 포트폴리오 평가 차트(아래 그림의 예시)의 주요 차원으로 뽑는 것이 자연스러워 보인다. 누군가가 이 두 차원간에 적절한 균형을 잡으려 한다고 추정하면서, 그 차트는 또한 “IoT 투자 회랑”을 투자가 이상적으로 배치되어야 할 영역으로 정의한다. “정해진 시기 동안의 ROI”(혹은 경제 부가가치, EVA 같은 어떤 다른 경제 수단)가 보통 쉽게 수량화 가능한 반면, 전반적인 전략적 기여는 보통 수량화하기가 더 어렵다. 또한, 이것은 특정 자산 종류의 전반적인 가치를 회사에 포함시킬 필요가 있다. 회사 이익의 50%를 차지하는 주 자산 가치의 작은 전략적 증가는 낮은 전반적 이윤에 기여하는 틈새 자산 가치의 큰 전략적 증가를 쉽게 능가한다. 이 접근법에 포함되지 않은 다른 중요한 요소는 시장 압력, 즉, 얼마나 이 투자의 타이밍이 결정적인가다.

{{ :파트2_8번그림.png?300 |}}
                           IoT opportunity evaluation chart

이들 요소의 튼튼하고 신뢰성 있는 수량화를 만들어내는 것은 항상 어렵다. 또한 정치적 파워 플레이와 기업 의사결정 과정에 수반되는 다른 요소들의 중요성을 과소평가해서는 안 된다. 하지만, 여기서 설명된 접근법은 최소한 IoT 투자 결정 과정의 일정 수준의 투명성과 객관성을 만들어내는 데에는 도움이 된다. 그리고 다시, 최종 결과는 “IoT 투자 평가 차트”라고 불리지 않을 것이고 더 수직적으로 특정한 “커넥티드 차량 기회 평가 차트” 같은 것으로 불릴 것이다. 하지만 기본 원칙은 적용할 것이다.
ii.ignite_iot_솔루션_전수.1442449579.txt.gz · 마지막으로 수정됨: 2015/09/17 09:26 (바깥 편집)
문서 보기 이전 판 역링크
뒤로 미디어 관리자 맨 위로