이 책의 제목은 Enterprise IoT이다. 그 이유는 사물인터넷의 더 큰 영역 안의 특정한 기업 솔루션의 부분집합에 초점을 맞추었기 때문이다. 우리의 의도는 새로운 카테고리를 만들어내는 것이 아니다. 이 분야에는 그런 것들이 시스코의 모든 인터넷, GE의 산업 인터넷, 독일 정부의 산업 4.0을 포함해 이미 충분히 많기 때문이다. 하지만 이런 책을 위해, 명료하게 정의된 초점과 명쾌한 이름을 주는 것도 도움이 되리라고 믿는다. 여기에서는Enterprise IoT의 기원과 그 정의를 설명하려고 한다.

기기와 프로그램을 연결시킨다는 발상은 새로운 것은 아니다. 특화된 통신 솔루션은 항상 존재해 왔다. 지난 10년간, M2M (Machine-to-Machine) 통신은 널리 확립되었고, 통신사들에 의해 이루어진 발전은 현존하는 모바일 네트워크를 개선할 새로운 방법을 모색하는 단계에 이르렀다. 그렇다면 M2M과 IoT의 차이점은 무엇인가? 이 질문에는 흑백을 가릴 수 있는 답은 없다.

                         From M2M to IoT
                         

다음 [MR13]의 발췌문은 우리가 가장 중요하게 생각하는 포인트를 요약한 것이다:

프로그램: M2M 프로그램은 기기들을 연결시키는 것들과 그와 관련된 것들이다. 예를 들면 스마트 미터와 스마트 미터링 프로그램을 들 수 있다. IoT 프로그램들은 잠재적으로 훨씬 복잡하며 복잡한 이벤트 처리와 데이터 분석을 특징으로 높은 레벨의 서비스를 제공한다.

유연성: M2M 프로그램은 특정 기능에 특화되어 매우 경직되어 있으나, IoT프로그램은 시간이 흐름에 따라 진화하는 잠재력이라는 측면에서 더 유연해질 필요가 있다.

구조: 많은M2M 프로그램들은 엄밀하고 불변하는 솔루션 구조에 배치된다. 반면에 IoT 프로그램들은 필요에 다라 분배되고 연합하는 처리, 저장, 질의장치가 특징이다. 본질적으로, M2M 프로그램이 배치될 때, 소프트웨어 엔지니어들은 솔루션의 전체 수명에서 어떤 과정이 진행될지에 대해 좋은 생각이 있을 것이다. 반대로, IoT 프로그램은 범위가 끝없이 확장되고 개인 프로그램은 종종 근본적인 데이터 공급에서 분리되므로, 같은 데이터 공급을 향상시킬 여러 IoT프로그램의 다른 측면들이 가장 효율적으로 다른 장소에 위치지어질 수 있다.

속도: 잠재적으로 전파와 처리의 지연을 최소화하여 더 나은 데이터 분석을 지원하기 위해 속도라는 측면을 강조하는 것은 가치가 있다. “속도”는 필요한 한 M2M 솔루션 안에서 디자인 될 수 있으며 프로그램들은 필요한 “속도”요구를 첫날부터 지원할 수 있다. 하지만 IoT 환경에서는 여러 데이터 공급의 전달과 처리에 필요한 속도의 필요성은 시간에 따라 진화하고 변화할 수 있다.

축: 논의는 이제 M2M과 IoT의 차이를 강조하는 쪽으로 이동한다: M2M 프로그램들은 산업 축과 기능적 역할이라는 맥락에서 고려되어야 하나, IoT 프로그램들은 그러한 한계를 초월해 교차 산업, 교차기능이 될 잠재력을 가지고 있다.

맥락: 위에서 언급한 유연성을 지원하기 위해서는, IoT 프로그램들이 의미상으로 풍족하고 관련된 맥락과 존재론이 명확해야 한다. 이는 데이터가 프로그램에 의해서 생성되고 특정한 프로그램과 알려진 시스템 환경에서만 의미를 가지는 M2M 프로그램의 경우와 다르다 . 구조: 이는 데이터의 구조에 대해 더 넓은 포인트를 도출해낸다. M2M에서 데이터는 고도로 구축되어있어(또한 잘 기록되어 있다. IoT 환경에서는, 개발자는 CCTV 자료나 크라우드소스 정보, 트위터스피에어서 나온 정보를 프로그램에 포함시키기를 원할 수도 있다. 이들 정보원들은 최대한 반구조화되어있고 최악의 경우에는 완전히 비구조적일수도 있다(개발자가 추출하기를 원하는 정보의 종류에 크게 의존한다).

성장: 관련된 차이는 M2M과 IoT 환경에서 예측될 수 있는 성장 속도에 있다. M2M 프로그램의 경우, 성장은 훨씬 예측가능하다. 일반적으로, M2M 솔루션은 특정한 시장, 일련의 물건들을 위해 디자인되며 통제가능한 시장에 상대적으로 예측가능한 방법으로 배치된다. M2M 솔루션에 의해 생성된 데이터는 일반적으로 기기수에 따라 선형으로 성장한다. 데이터량, 거래량, IoT환경에서의 프로그램들은 다양한 범위의 데이터원 사이에서 네트워크 효과에 의해 견인된다. 그에 다라, IoT 공간에서의 성장은 M2M 공간의 특징인 선형적이고 예측가능한 것 보다 더 지수적으로 예측된다

데이터 소유권: 마지막으로, 데이터 소유권이라는 주제도 다룰 가치가 있다. M2M연결 솔루션의 경우에서 데이터 소유권이 종종 불투명할 수 있는데 반해, IoT 환경에서의 데이터 소유권의 개념은 훨씬 더 복잡하다. 근본적으로는, M2M의 경우, 알려진 프로그램의 배경, 사용자, 규제의 요구사항 안에서 데이터의 프라이버시는 고려될 수 있다. 하지만, IoT의 경우 데이터는 동시에 예기치 못한 프로그램들에 의해 예기치 못한 장소에서, 그리고 예기치 못한 이익을 위해 잠재적으로 사용될 수 있다. 이는 IoT 대기업이 고객의 신뢰를 잃기를 원하지 않는다면 효과적으로 다루어야 할 중요한 측면이다.

위의 모든 포인트를 기반으로, [MR14] 는 “사물부분망(SoTs)”이라는 유용한 개념을 M2M에서 IoT로의 진화에 필요한 단계로서 소개한다. M2M 솔루션은 거의 바깥의 기기나 문제의 해결책과는 연결성이 적은 닫힌 환경인 “사물인트라넷”으로 간주된다. 자연스러운 다음 단계는 이런 솔루션들을 “바깥 세계”로 통합시키기 위해 어떻게 이들 사물인트라넷이 “가까운” 제품, 서비스, 그리고 물론 (다른) 사물인트라넷으로 여겨지는 것들과 통합될 수 있는가로 여겨진다.

우리는 이 개발 단계가 데이터원의 공동 소유권이나 데이터 소유자들 사이의 공통의 이유에 의해 추진될 것이라고 믿는다. 한 사례는 스마트 미터링 솔루션과 그 현장업무 솔루션간에 연결을 만드는 도구일 수 있다. 그 도구는 프로그램에 만들어내는 데이터에 더해 스마트 미터, 현장업무 능력, 그들을 지원하는 프로그램도 가지고 있기 때문에 그것을 해낼 수 있다. 즉, 시스템, 커넥티드 기기, 그리고 기업의 IT환경이 잠재적인 사물부분망으로 간주될 수 있는 것이다.

이들 사물부분망의 관계에서 고려해야하는 중요한 포인트는 그 고유한 능력, 완전한 사물인터넷보다도 훨씬 빠르게 개발하는 능력이다. 이는 주주들이 더 데이터를 공유할 용의가 있다는 것과 프로그램간 공유의 기술적 가능성이라는 두 사실에 기인한다.

다음 논리적 단계는 개념을 우리가 사물부분망이 잠재적으로 생기게 할 기기, 데이터원, 데이터 소유주의 공동체로 정의하는 데이터 공동체로 확장하는 것이다. 한 사례로는 공통의 플랫폼을 만들기 위해 합쳐진 자동화 빌딩 공급자들의 그룹이 있다.

SoTs가 미래 IoT로 가는 어떤 길에서든 중요한 단계라는 것은 명백하다. 우리는 SoT를 만들기 위해 표준화하려는 비슷한 동기를 가진 정해진 집단의 사람들을 설득하는 것이 상대적으로 쉬울 것이라고 믿는다. 하지만, IT와 관련된 산업들이 SoT가 생겨나게 하도록 충분히 표준화시키도록 설득하여 IoT로의 다음 단계로 나아가는 것은 훨씬 힘들 것이다.

        Evolution to the Internet of Things (Source: Machina Research)

간단히 말해서, Enterprise IoT는 발달된 M2M 솔루션과 사물부분망(고도로 발달된 SoTs를 제외하고) 모두에 초점을 둔다. 이는 아래 그림에 나타나 있다.

일반적으로 Enterprise IoT 솔루션은 한 종류의 물건에 집중한다. 하지만 가끔은 다른 판매사들의 다른 기기들에도 초점을 둘 것이다. Enterprise IoT 솔루션은 종종 단순한M2M 솔루션보다 더 존재론적 풍부함을 가질 것이다.

이 책에서, 일반적인 Enterprise IoT 솔루션의 범위는 이 솔루션을 다루는 한 기업에 명쾌하게 한정될 것이나 말미에는 완전한 솔루션을 제공하기 위해 다른 파트너들과 협조할 수도 있다. 이 점에서 Enterprise IoT은 모든 장치가 다른 장치와 직접적으로 혹은 클라우드를 통해 연결될 수 있는 완전한 IoT 비전보다는 더 한정적이다. 이는 많은 기업들이 더 강하게 통제할 수 있는, 단일 기업 타입의 IoT 솔루션들에 이후 몇 년 간 더 집중할 것이라고 우리가 느끼기 때문에 내린 의도적인 결정이다.

                Focus of Enterprise IoT
              

IoT 커뮤니티의 몇몇 사람들은 산업IoT(커넥티드 차량, 기계, 다른 산업 장비들)와 소비자 IoT(스마트 의류, 커넥티드 식기세척기 등)로 구별된다 [OR14]. 하지만 산업 IoT가 산업 IoT에만 집중한다고 하는 것은 지나친 단순화일 수 있다. 그것이 대부분의 주요 프로그램과 이 책의 Part II에서의 사용사례에서는 사실일지라도, 우리는 이 책의 주요 포인트가 일반적으로 단일 기업이 통제하고 뒤에서 더 자세하게 묘사될 특정한 구조적 패턴을 따르는 솔루션에 대한 집중이라고 믿는다. 이 두 기준은 소비자 IoT에서 나오는 많은 사례들에 의해서도 충족된다. 예를 들어, 앞 섹션에서 논의했던 이콜 서비스나 카 셰어링 시설을 보자.

Part II에서 보겠지만, 우리의 지금까지의 분석은 주로 커넥티드 차량, 스마트 에너지, 스마트 시티의 제조업과 산업에 주로 집중해 있었다. 이들 분야에서 얻은 교훈들은 Ignite | IoT 방법론의 현재 기반을 제공한다. 이 책의 1.0버전에서는 최소한 스마트 의류에 대한 사례 연구를 포함 시킬 시간이 없었다. 하지만, 우리는 만약 그것이 Enterprise IoT의 다른 적합한 후보일 수 있을지 호기심을 가질 것이다. 아마 다음 버전에서는 가능할 것이다,

Enterprise IoT의 개념을 더 견고하게 하는 것을 돕기 위해, 우리는 몇가지 유용한 정의를 아래에 포함시켰다. 아마 우리의 명명법에서 우리가 내릴 가장 중요한 결정 중 하나는 용어 “사물”을 빼는 것일 것이다, IoT는 모든 “사물”에 연결되도록 상정되어 있으므로 모순된 것처럼 들리겠지만. 하지만 우리의 경험에서, 기업의 사람들은 거의 사물에 대해 이야기하지 않는다. 그러므로 우리는 “자산”과 “기기”라는 더 흔히 사용되는 용어를 채택하기로 했다.

                     Enterprise IoT definitions

위의 그림은 Enterprise IoT 아래에 정의될 솔루션 시나리오의 주요 요소에 대한 개관이다.

• (1) Asset: 사업 용어에서 우리는 많은 물리적인 “사물”을 그 중요성을 강조하기 위해 “자산”이라고 부른다. 자산은 차량, 시설, 기계, 전동공구처럼 이윤을 생성하기 위해 혹은 회사의 활동을 돕기위해 생산되고 작동되며 관리되는 장비의 속성이나 조각이다. 자산은 일반적으로 기업의 사업모델의 중요한 부분이다. 기기(아래를 보라)가 IoT솔루션의 일부가 될 수 있는데 반해 자산 그 자체는 일반적으로 IoT솔루션의 일부로 간주되지 않는다는 점에 주의하라(최소한 Enterprise IoT의 맥락에서는).

• (2) 기기: 기기는 “사물”의 다른 중요한 종류이다. 일반적으로, 기기는 자산에 비해 경제적으로 덜 중요하고 물질적 측면에서는 매끈하다. IoT의 기기들은 주로 센서(열, 온도, 흐름, 등)와 작동기(전기모터나 유압 부품)를 포함한다. 우리의 Enterprise IoT 시나리오에서, 기기는 일반적으로 자산에 배치된다.

• (3)기업: “기업”은 Enterprise IoT 솔루션을 실행하는 전체의 조직적 범위를 가리킨다. 많은 사례에서, 이것는 예를 들면 차량 관리자나 제조업자 같은 자산을 작동시키는 것과 같은 기업이다. 이콜서비스 같은 사례에서 기업은 백엔드 서비스만을 가동시킨다. 기업들은 핵심 사업 과정을 지원하고 새로운 사업모델을 수립하고 고객과의 지속적인 관계를 창출하기위해IoT 솔루션의 도입을 늘리고 있다. 기업은 스스로의 자산을 작동시키고 다른 조직에 속한 자산에 서비스를 제공하기 위해 IoT를 사용할 것이다.

• (4) Enterprise IoT 솔루션: 자산과 그 기기를 백엔드 프로그램 서비스로 연결하는 IT 시스템.

o (4a) 백엔드 서비스: IoT 솔루션의 백엔드 서비스는 원격 모니터링과 기기 및 자산의 통제, 기기 관견 데이터의 수집, 다른 기업 프로그램과의 통합을 가능하게 한다(5).

o (4b) 백엔드 UI: 백엔드 서비스는 모든 자산 상태의 현재 동작상태를 보여주는 시각적 계기판처럼 일반적으로 웹 혹은 모바일 인터페이스를 사용자가 서비스와 상호작용하도록 제공한다.

o (4c) 원격 통신: 자산과 백엔드 서비스 간의 통신 원리. 예시는 모바일 네트워크, 위성 등.

o (4d) 자산의 HW+SW (Hardware + Software): 자산에 배치되는 솔루션의 하드웨어와 소프트웨어 부분. 자주, 자산의 하드웨어는 자산의 소프트웨어가 현지 통합과 원격 메세지를 가능하게 하는 현지 대리인으로 행동하는 것에 반해 현지에서와 원격에서의 통신을 가능하게 하는 게이트웨이의 형태이다. 예를 들면, 게이트웨이는 현지의 센서를 통합시키고 GSM 모듈을 백엔드와 원격으로 통신하기 위해 산업 버스를 사용한다. 많은 사례에서 게이트웨이/에이전트는 또한 지역에서 사용되는 여러 기기의 프로토콜과 백엔드 시스템이 지원하는 포맷간에 가교를 놓기 위해 번역과 지도제작 서비스를 수행한다. (4d)가 오직 솔루션 특화 HW+SW만을 지칭한다는 것을 유념하라: 많은 자산은 이미 현존하는 현지 사업 논리이되 솔루션이 아닌 것을 가능하게 하는 내장된 HW+SW를 가지고 있다.

o (4e) 솔루션 HMI: 어떤 IoT 솔루션은 또한 내장 디스플레이나 차량 공유 서비스 같은 솔루션 특화 인간-기계 인터페이스(HMI)를 포함한다.

• (5) 기업 프로그램과 (6) 파트너 시스템: 대부분의 IoT 솔루션은 ERP, MES, PLM, CRM , 유산 프로그램 등 많은 내외부(즉 파트너) 프로그램들을 통합시켜야 한다. 많은 사례에서 이런 프로그램들은 또한 자산에 관련된 데이터를 유지한다. 예를 들면, ERP 시스템은 차량 설정 데이터를 담고 있을 수 있고, 백엔드는 원격 차량 상태 데이터를 담고 있을 수 있다. 이들 여러 데이터원을 통합시켜야만 자산의 전체적인 견해를 얻을 수 있다.

아래의 그림은 Enterprise IoT 솔루션의 구체적인 예시이다. 그 솔루션은 비상 상황을 추적하고 다룰 수 있는 이콜 서비스이다. 관리되는 자산은 자동차들이다. 기업은 이콜 오퍼레이터이며, 이 사례에서는 보슈 시큐리티 테크놀로지이다. 그 솔루션은 통합된 가속 센서를 가진 내장된 컴퓨터 통신 통제 유닛(TCU을 포함하고 있다. 그에 더해, TCU는CAN 버스를 통해 자동차의 에어백에 통합되어 있다. 백엔드와의 통신은 GSM에 기초하고 있다. 주요 백엔드 서비스는 콜센터 프로그램이다. 이 프로그램은 지역 전화 관리 솔루션, 자동차 제조사에 의해 관리되는 차량데이터베이스, 사고 현장에서 가장 가까운 경찰서, 소방서, 구급차 서비스와 연결된 공공 안전 응답 포인트(PSAP)를 통합시킨다.

                       eCall example
                       

독자에게 이들 정의와 예시가 도움이 되기를 바란다. 이들은 책 전체에서 사용될 것이다. 특별히, 우리의 주요 구조 개념 중 하나인 자산 통합 구조(AIA)에 포함되어 있는 것을 보게 될 것이다. 사용 사례를 분석하기 위해 사용되는 이 개념은 Part II에서 정식으로 소개할 것이다 (“IoT Architecture Blueprints“를 보라).