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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 얼마나 자주?

• 어떤 수준의 정확도로?

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

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

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

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

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

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

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

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

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

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

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

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

                      Structured IoT analysis and design approach
                      

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

영역 모형

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

• 등급

• 속성

• 제휴

• 집단

• 상속/전문화

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

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

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

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

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

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

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

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

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

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

IoT domain model

자산 통합 아키텍쳐 (AIA)

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

                           AIA example: eCall service
                             

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

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

데이터 분배 Data Distribution

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

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

AIA and data distribution

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

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

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

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

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

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

SOA 랜드스케이프

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

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

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

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

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

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

SOA landscape