이 문서의 번역:

ii. IoT 프로젝트 구조

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

Conway의 법칙

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

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

                       Identifying the right workstreams
                       

IoT 프로젝트 작업 흐름

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

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

이 문서의 번역:
ⅱ.iot_프로젝트_구성.txt · 마지막으로 수정됨: 2015/09/17 09:18 저자 wikiadmin
CC Attribution-Share Alike 3.0 Unported
Powered by PHP Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Valid HTML5