IoT 장치 용 개인 클라우드를 생성하려면 무엇이 필요합니까?


18

특히 "IoT"개념이 최근에 많이 떠 올랐기 때문에 이것은 내가 생각했던 주제입니다.

"IoT" 라고 말할 때의 의미부터 시작하겠습니다 . 나는 IoT라는 용어가 다른 것을 의미 할 수 있으며 때때로 잘못 사용된다는 것을 알고 있습니다. 그것은 명확하게 정의되지 않은 용어 일 수 있으며 그것이 정확히 무엇을 의미하는지에 대해 큰 토론을 이끌어 낼 수 있습니다. 저에게 IoT는 개념, 즉 다른 임베디드 장치 나 휴대 전화에서 인터넷을 통해 원격으로 임베디드 장치에 연결하는 기능을 정의하는 개념입니다 . 저것과 같이 쉬운.

이러한 맥락에서 연결의 목적은 중요하지 않습니다. 사무실의 한 장치를 집의 다른 장치와 연결할 수 있거나 휴대 전화에서 집의 한 장치에 인터넷을 통해 연결할 수있는 경우, 우리는 IoT 장치 (전화가 아닌 내장 된 장치) 에 대해 이야기하고 있습니다.

따라서 IoT의 의미에 동의 한 후 이제 달성하려는 내용을 설명하겠습니다.

내가 달성하려는 것은 정확하게 내가 IoT에 대한 정의에 기술 한 것입니다.

이더넷 또는 Wi-Fi로 인터넷 라우터에 연결된 하나 이상의 내장형 장치를 집에 있고 원격 위치의 다른 내장형 장치와 원격으로 연결할 수 있기를 원합니다 (원격으로 같은 네트워크에 있지 않음) 휴대 전화의 모니터링 앱을 사용하여 연결될 수도 있습니다.

예를 들어, 차고 도어 오프너에 연결된 온 / 오프 스위치 역할을하는 간단한 내장형 장치와 직장에서 책상에 큰 빨간 버튼 역할을하는 다른 내장형 장치가있어 책상의 빨간 버튼을 누를 수 있습니다. 차고 문이 열립니다.

또 다른 예는 우리 집의 온도를 모니터링하고 임계 값에 도달하면 경고를 보낼 수있는 ADC 기능을 갖춘 내장형 장치를 사용하는 것입니다. 알림은 간단한 안드로이드 앱이나 직장에 책상에 작은 화면이있는 다른 내장 장치로 수신 할 수 있습니다.

이 예제는 어리석은 것이지만 가능한 시나리오를 설명하고 내가 달성하려는 것에 대한 사용 사례를 설명하기위한 것입니다. 결국 아이디어는 동일합니다. 인터넷을 통해 하나의 임베디드 장치를 다른 임베디드 장치에 연결하십시오.

명확히해야 할 또 다른 사항은 이러한 장치 간의 데이터 교환이 매우 가볍고 매번 몇 바이트에 불과하므로 장치간에 수백 킬로바이트를 교환 할 필요는 없다는 것입니다.

또한 필자가 언급 한 "임베디드 장치"는 100MHz 또는 200MHz cortex-m4 마이크로 컨트롤러를 기반으로하는 단순하지만 성능이 뛰어난 장치입니다. 그리고 그러한 장치에서 실행되는 Linux 또는 복잡한 라이브러리가 없으므로 명확하게 설명해야합니다. 결국, 자원을 낭비하고 전구를 켜고 끄기 위해 Linux를 실행하는 강력한 프로세서를 갖출 필요는 없습니다 . 어쨌든 나는 BeagleBoard, Raspberry Pi 또는 이와 같은 다른 보드를 내장 장치로 사용할 계획입니다. 그 이상의 복잡성이 필요하지 않기 때문에 마이크로 컨트롤러 만 있으면됩니다.

IoT 플랫폼과 복잡한 솔루션에 대해서는 잘 모릅니다. 인터넷을 통해 하나의 임베디드 장치를 다른 임베디드 장치와 연결하는 방법을 찾기위한이 여정을 시작했을 때 IoT 서비스를 제공하는 두 사이트를 발견했습니다.

다음과 같은 IoT 클라우드 서비스가 있다는 것을 알고 있습니다.

몇가지 말하자면. 이러한 문제의 주요 문제는 비용과 복잡성입니다. 당신은 그 서비스를 얻기 위해 비용을 지불해야하며 또한 당신이 그들 모두를 필요로하는 경우, 그들이 가지고있는 모든 서비스와 API 및 아마도 나에게 필요하지 않은 다른 것들을 구현하는 방법을 배워야합니다. 장치간에 약간의 바이트를 교환 할 수 있습니다. 나는 그보다 더 단순한 것을 원합니다.

내 자신의 "클라우드"를 구현해야하는 것이 간단하지 않으며 간결성을 위해 이러한 종류의 서비스를 사용하는 것이 더 낫지 만 어떻게해야하는지 알고 싶은 두 가지 주요 이유가 있다고 말할 수 있습니다. 나만의 IoT 서비스를 구현하십시오.

주된 이유는 내가 직접하고 싶어하기 때문입니다. 내 장치를 서로 연결하기 위해 타사에 의존하고 싶지 않으며 장치의 코드와 하드웨어를 개발할 예정이므로 IoT 장치로 연결하는 고유 한 수단을 만드는 것이 좋습니다.

두 번째 이유는 방법을 배우는 것입니다. 이를 달성하는 데 필요한 모든 것을 알고 IoT 세계에 대해 더 잘 이해할 것입니다.

또한 저는 C에 능숙하다고 말하고 싶습니다. 나는 직장뿐만 아니라 집에서도 일상적인 OS로 Linux를 사용하고 있습니다. 임베디드 장치를 위해 C로 구현하거나 Linux에서 목표를 달성하는 데 필요한 모든 것을 구현하기 위해 구현해야 할 것이 무엇인지 두려워하지 않습니다.

그래서 제 질문은 둘 이상의 임베디드 장치를 서로 데이터 교환을 목적으로 서로 연결할 수 있어야하고 구현 해야하는 곳은 무엇입니까?

이 질문 자체 서버에서 IoT를 만드는 데 무엇을 사용할 수 있습니까? 비슷한 것을 가지고 있지만 닫혀 있고 아무런 대답이 없으며 이미 존재하는 클라우드 인프라를 사용한다고 가정합니다. 그래서 그것은 도움이되지 않습니다.

이 글 은 클라우드에서 일반 데이터를 저장 / 전송 / 게시하기 위해 어떤 IoT 서비스를 사용할 수 있습니까? 비슷한 질문이 있지만 OP는 IoT 서비스를 명시 적으로 요구하고 있으며 피하려고합니다.


2
서버는 어떻게 "기존 클라우드 인프라"입니까? 서버는 컴퓨터 일뿐입니다. 클라우드 인프라는 훨씬 더 많습니다.
user253751

1
또한 유비쿼터스 IPv6를 사용하는 경우 중앙 서버 / 클라우드가 없어도 IoT 장치가 서로 직접 통신 할 수 있습니다.
user253751

답변:


10

어쩌면 나는 질문의 요점을 놓쳤을 수도 있지만, 이것이 대답에서 좋은 출발이라고 생각합니다.

최소한 세 가지가 필요합니다.

  1. 데이터를 집계하기위한 상시 가동 컴퓨팅 노드. 강력 할 필요는 없습니다. NAS에서 실행중인 프로세스 일 수도 있고 라우터에서 (이론적으로) 프로세스 일 수도 있습니다. 간단히하기 위해 라즈베리 파이라고 가정합니다. 또한 향후 지원하기로 결정한 멋진 무선 프로토콜도 제공 할 수 있습니다. 이론 상으로는 모든 노드가 인터넷에 노출 된 상태에서 피어 투 피어를 실행할 수 있지만이를 마스터로 지정하고 데이터 조합 및 게시 (앱 / 사용자)를 처리하는 것이 더 쉽습니다. 물론 허브도 노드가 될 수 있습니다. 특히 적당히 강력한 WiFi 노드를 사용하는 경우 특히 그렇습니다.
  2. 엔드 포인트가 데이터를 허브 노드에 제출할 수있는 적합한 소프트웨어 스택. 는 여기에 필요한 종류와이를 실행하는 OS입니다.
  3. 광범위한 인터넷에서 서버에 쉽게 액세스 할 수 있도록하는 DNS 및 포트 전달.

그런 다음 보안을 잊지 마십시오. 이렇게하면 홈 네트워크의 모든 것을 열어 공격 할 수 있습니다. 약간만있을 수도 있지만 위험을 알고있는 것이 좋습니다. 노력하고 돌볼 수는 있지만 실수를한다고 가정하십시오.


1
이것이 당신이 원하는 대답인지 확실하지 않습니다. 그래도 필요한 것을 해결하는 것이 도움이 될 것입니다.
Sean Houlihane

1
도와 줘서 고맙다!! 첫 번째 요점은 허브 나 게이트웨이가 필요하다는 것입니다.
m4l490n

1
예, 하나 이상의 게이트웨이가 필요합니다. 하나의 노드 만있는 경우 이는 분명히 노드 일 수 있습니다. 내 답변을 약간 편집했습니다.
Sean Houlihane 2012

11

경량 디바이스 및 몇 바이트의 날짜 비율 은 이미 언급했듯이 MQTT 사용을 요구합니다 . 센서 노드는 MQTT 클라이언트 구현을 호스팅하기에 충분히 강력한 독립형 ESP8266 모듈을 기반으로 할 수 있습니다. 또는 이러한 모듈을 외부 마이크로 컨트롤러와 함께 AT 명령 제어 Wi-Fi 모듈로 간단히 사용할 수 있습니다.

4 kB의 플래시를 가진 Atmega48V를 사용한이 사람 과 같이 훨씬 덜 강력한 마이크로 컨트롤러에서 자체 MQTT 솔루션을 구현할 수 있습니다 .

Raspberry Pi를 대신 실행하는 것이 더 효율적이지만 컴퓨터에서 브로커를 호스팅 할 수 있습니다. 코딩을 좋아하는 경우 고유 한 MQTT 브로커를 구현할 수 있습니다. 개인적으로 나는 모스키토 가이 목적에 훌륭 하다는 것을 알았 습니다.

모든 센서 노드에 TCP / IP 연결이 필요하다는 단점.


배터리 친화적 인 솔루션은 LoraWAN 또는 ZigBee 지원 센서 / 액추에이터 노드를 사용하고 Raspberry / BeagleBone에서 게이트웨이를 구현하여 전화기 나 다른 장치에서 액세스 할 수있는 간단한 웹 서버도 호스팅 할 수 있습니다.


모든 경우에 허브, 게이트웨이 또는 서버를 사설 네트워크 외부에서 액세스 할 수있게됩니다. 이를 수행하는 더 많은 방법이 있으며 주요 관심사는 항상 보안입니다. 이것은 제 생각에 가장 위험한 부분입니다.

기본 요구 사항은 @Sean에 의해 잘 요약되어 있습니다.


귀하의 답변과 @Sean의 답변에 따르면 허브 또는 게이트웨이가 필요합니다. 이것이 꼭 필요한가요? IP 주소 또는 호스트 이름을 알고 노드에 직접 연결할 수 없습니까? 허브 나 게이트웨이를 피하려는 것이 아니라 필요한지, 왜 필요한지 이해하고 싶습니다. 도와 줘서 고맙다!!
m4l490n

Raspberry Pi가 "항상 켜져있는"장치로 훌륭하다는 것을 알고 있습니까? 네트워크 스토리지로 사용하는 Pi에 작은 HDD가 연결되어 있지만 주저하지 않고 항상 켜두십시오. 그렇게해도 괜찮을까요? (FWIW 나는 그것에 작은 방열판이 있습니다)
BruceWayne

1
@ m4l490n 허브 나 게이트웨이를 사용하면 더 간단 해집니다. 이 방법으로 포트 전달을 설정하거나 허브 또는 게이트웨이에 대해서만 설정해야합니다. 라우터 뒤에있는 모든 장치에 직접 연결하려면 예를 들어 각각 포트 포워딩을 설정해야합니다. 개인 네트워크에 더 많은 방법을 열면 더 많은 위험을 감수하고 더 많은 일을 할 수 있습니다.
Bence Kaulics


10

컨트롤러 / 허브의 필요성에 대한 이전 답변에 모두 의문을 제기했습니다. 일을하려면 규칙이 필요하다는 것을 고려하십시오. 큰 빨간 버튼을 눌러 차고 문을 열려면 일부 규칙에 따라 센서 (버튼)를 원하는 동작 (문 열기)에 연결해야합니다. 두 가지 방법이 있습니다. 버튼에 규칙을 직접 넣거나 별도의 컴퓨터에 규칙을 넣을 수 있습니다.

직접 솔루션에 대해 더 많이 생각해 봅시다. 차고 문에 대해 버튼을 가르치면 버튼은 내부적으로 규칙을 유지합니다. 버튼에는 차고 문의 ID가 필요하므로 차 고문을 교체하면 버튼이 작동하지 않습니다. 버튼이 책상 위에 있고 집에서 독점적 인 네트워크를 사용하는 경우 버튼은 집의 게이트웨이 주소와 문 주소를 모두 알아야합니다. 버튼은 문을 열도록 신호를 보내려면 특정 프로토콜을 알아야합니다. 모든 제조업체는 모든 도어 신호에 대해 알고있는 호환 가능한 버튼을 만드나요? 버튼을 다시 프로그래밍하지 않으면 버튼으로 다른 작업을 수행 할 수 없습니다. 버튼 칩에 플래시 프로그래머가 있습니까? 그 프로그래머가 다른 장치와 호환됩니까? 차고 문을 열고 5 분 후에 문을 닫으려면 버튼은 실시간 시계를 유지하는 모든 복잡성을 필요로합니다. 버튼으로 문 상태를 알 수 없으므로 문을 닫거나 열 었는지 알기가 어렵습니다. 그리고 버튼이 고장 나면 교체 버튼이 작업을 수행 할 수 있도록 규칙을 어떻게 백업합니까? 좋은 점은 저렴하다는 것입니다. 별도의 컴퓨터가 필요하지 않습니다.

컨트롤러를 사용하면 상황이 다릅니다. 모든 센서의 모든 메시지가 컨트롤러로 전달됩니다. 각 센서는 간단합니다 : 신호를 컨트롤러로 보냅니다. 그런 다음 컨트롤러는 매우 복잡한 규칙에 필요한 모든 입력을 적용 할 수 있습니다. 햇빛 센서를 확인하고 실외 조명이 어두워지지 않는 한 실외 조명을 켜지 않거나 월의 평균 강우량이 평균 이상이고 현재 온도 인 경우 스프링클러를 작동하지 않을 수 있습니다 평균보다 5도 낮습니다. 컨트롤러는 상태를 추적 할 수 있습니다. "차고 문 닫기"버튼을 원하지만 "차고 문 열기"버튼은 원하지 않는 경우에 중요 할 수 있습니다 (집을 비울 때 문을 열고 싶지는 않지만 문이 닫히면 닫고 싶습니다) 실수로 열린 채로 있습니다.)

컨트롤러는 버튼을 듣는 방법을 알고있는 장치 드라이버와 문을 말하는 방법을 알고있는 기타 드라이버를위한 장소를 제공 할 수 있습니다. 컨트롤러는 버튼 안에 들어있는 작은 칩보다 새로운 장치 및 장치 유형으로 업그레이드 할 수 있습니다.

또한 컨트롤러는 특정 수준의 서비스를 제공하여 메시지 전달과 같은 인프라 작업에 대해보다 복잡한 논리를 가질 수 있습니다. 예를 들어, MQTT 프로토콜은 세 가지 다른 레벨을 허용합니다. 메시지를 한 번 전달하거나, 한 번 이상 볼 때까지 반복적으로 전달하거나, 한 번만 전달하십시오.

컨트롤러는 통신 게이트웨이와의 모든 메시징을 통합하여 외부 인터페이스를 사용할 수 있도록 구조적으로 논리적 공간을 제공합니다. 즉, 버튼과 휴대 전화 모두 신호를 보낼 수 있으며 규칙에 따라 차고 문을 열 수있는 규칙이있을 수 있습니다. 게이트웨이는 보안을 제공 할 수도 있습니다. 인터넷에 버튼과 차고 문을 둘 필요는 없습니다. 개인 격리 된 네트워크에 둘 수 있으며 게이트웨이를 사용하여 신호를 전달할 수 있습니다. 또한 컨트롤러는 시스템의 모든 규칙을 백업하기위한 단일 지점을 제공합니다.

컨트롤러의 단점은 지연 시간과 추가 복잡성입니다. 놀랍게도 컨트롤러는 비용을 눈에 띄게 올리지 않습니다. 원격 제어가 가능한 하나의 평균 전등 스위치 비용보다 Raspberry Pi에 컨트롤러를 구현할 수 있습니다. 비용만으로 아이디어를 할인하지 마십시오.


특히 허브 전체를 최대한 활용할 수있는 모든 IoT 장치에서 규칙 기반 기능이 필요한 경우 허브 또는 컨트롤러를 사용하는 것이 매우 바람직합니다.
m4l490n

따라서 올바르게 이해하면 복잡한 규칙이나 복잡한 IoT 장치 네트워크가 필요하지 않으면 피어 투 피어 연결을 가질 수 있으며 IoT 장치와의 상호 운용성이 없다고 가정합니다. 다른 브랜드 및 예를 들어 하나의 버튼은 항상 동일한 도어 오프너에 연결됩니다.
m4l490n

그렇지 않으면 더 많은 유연성과 기능이 필요한 경우 허브가 있어야합니다. 그 맞습니까?
m4l490n

예, 정확한 요약입니다. 사실상 모든 사람들은 일종의 허브 / 컨트롤러가 필요합니다. 상용 및 오픈 소스 허브에 대한 많은 옵션이 있습니다.
John Deters
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.