> For the complete documentation index, see [llms.txt](https://metatron-grandview.gitbook.io/meatatron-grandview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://metatron-grandview.gitbook.io/meatatron-grandview/iotdevicedev/undefined.md).
# 펌웨어의 수명주기
IoT 디바이스에 탑재되는 펌웨어의 수명주기의 예시와 설명입니다.
IoT 디바이스는 Window 나 Linux 같은 고급 OS 위에서 실행될 수도 있을 것이며, 저수준의 RTOS 로 \
구현될 수도 있을 것입니다.
펌웨어가 실행되는 시점부터 어떤 일들을 순차적으로 수행해야 하는지 예시로 소개해드립니다. \
예시를 통하여 펌웨어를 어떤 방향으로 개발하면 될지 가늠하시기 바랍니다.
## 단계 별 부가 설명
### 통신 가능 여부 체크
디바이스가 인터넷 망에 연결되어 있는지 체크합니다. \
잘 알려져 있고 서비스가 안정적인 웹 사이트에 연결하도록 구현하는 것이 좋은 방법입니다. \
만일 통신이 불가능하다면 이후 과정은 의미가 없으므로 디바이스는 통신이 가능해질 때까지 \
대기 처리합니다. (몇 초 혹은 몇 분 주기로 다시 체크하도록 구현합니다.)
이후 API 호출, 데이터 전송 등 모든 과정에서 통신이 불가능한 상황이 올 수 있습니다. \
타임아웃 예외가 발생하면 이 단계로 돌아오거나 디바이스를 리부팅 시키는 것이 좋습니다.
공장 현장에는 전파 음영 지역이 존재할 수 있으며, IoT 디바이스 설치 위치에 따라 간헐적으로 \
인터넷 연결이 실패할 수 있습니다. \
이 경우 펌웨어는 통신이 재개될 수 있을 때까지 자동으로 대기와 재시도를 해야합니다. \
운영팀에서 디바이스의 통신 끊김에 대한 부분을 모니터링하고 있으며 현장 출동과 같은 조치가 취해질 수 있습니다.
{% hint style="info" %}
그랜드뷰의 인프라스트럭처는 인터넷 통신만 될 수 있으면 데이터를 보낼 수 있으며, 특정한 \
통신망을 사용하도록 제약을 갖고 있지 않습니다. 다만 사업 추진 방향에 따라 LTE 와 같은 \
통신망을 사용하도록 의사결정 될 수 있습니다.
{% endhint %}
### 하드웨어 식별자 추출
IoT hub 의 커넥션 스트링을 디바이스마다 하드코드 하는 것을 방지하고자 디바이스 마다 고유한 \
식별자 값을 IoT 플랫폼에 저장합니다. \
이 식별자 값은 이더넷 모듈이 있다면 MAC 주소가 될 수 있으며, 모뎀을 사용한다면 USIM 카드의 \
IMEI 값이 될 수 있습니다. 디바이스마다 중복되지 않을 수 있는 어떤 것이든 가능합니다.
디바이스 마다 고유한(unique) 식별자를 미리 서버에 등록하도록 요청해야합니다. \
서버에서는 식별자 정보를 실제 디바이스 메타 정보와 연결하여 저장하고 있어, 서버 API 를 호출하면 \
IoT hub 의 커넥션 스트링을 내려줍니다. \
이렇게 HTTP response 된 커넥션 스트링은 디바이스 펌웨어 변수에 저장 후 사용하면 됩니다. \
디바이스가 부팅 될 때마다 이 과정이 반복되도록 만들어야 합니다.
{% hint style="info" %}
PoC 환경과 같이 디바이스를 추가 설치할 요건이 없는 경우에는 이 과정을 건너뛰어도 됩니다.
{% endhint %}
### API 호출
하드웨어 식별자를 활용하여 IoT 디바이스가 연결할 IoT Hub 의 정보를 얻을 수 있으며, 이 때 디바이스가 \
사용해야하는 Service ID 값과 Device ID 값이 함께 전달됩니다. \
이 ID 값들은 데이터를 전송할 때 식별자로 부여해야 하므로, 서버에서 주는 ID 값들을 활용하여 데이터를 \
구조화 해야 합니다.\
하드웨어 식별자 추출 과정을 건너뛴 경우 이 부분은 구현하지 않아도 됩니다.
그리고 펌웨어의 버전 체크를 위한 API 를 호출합니다. \
서버에서는 서버에 등록된 펌웨어 버전과 다운로드 할 수 있는 URL 을 함께 리턴 해줍니다. \
펌웨어는 나의 버전과 서버의 버전을 비교하고, 서버의 펌웨어 버전이 더 높다면 다운로드 및 설치를 \
진행하면 됩니다.
버전 체크는 정수로 변환한 후 비교합니다. \
펌웨어가 나의 버전을 알고 있어야 하므로 비휘발성 메모리에 나의 버전을 기록해두고, 펌웨어 업데이트가 일어날 때 이 정보도 함께 업데이트 하십시오.
### 펌웨어 업데이트
펌웨어 파일을 다운로드 받고 디바이스를 재시작하면 업데이트 될 수 있도록 구현합니다. \
이때 구 버전 펌웨어 파일을 정리해서 저장 공간이 꽉 차는 일이 발생하지 않도록 주의합니다.
### 디바이스 트윈 수신
IoT 플랫폼에는 디바이스의 메타 정보가 디지털 트윈(digital twin)으로 저장되어 있으며, 이 디지털 트윈은 서버와 클라이언트가 동시에 참조합니다. \
클라이언트가 항상 서버에 접속되어 있을 수 없기 때문에 데이터의 변경은 비동기적으로 이루어집니다.\
\
예를 들어 저전력 센서 같은 경우 오랜 시간 sleep 하다가 깨어나기 때문에 서버에서 디바이스가 \
응답하도록 기다리게 하지 않기 위해 디지털 트윈만 참조합니다.
* **디지털 트윈을 사용하는 이유**
* 펌웨어를 configuration driven 으로 개발하기 위해.
* 멀리 떨어진 현장에 직접 방문하는 일을 최소화하고자 디지털 트윈을 사용하여 펌웨어의 \
설정사항들을 원격 관리 합니다.
이 디지털 트윈 개념을 IoT hub 에서 디바이스 트윈이라는 이름으로 제공하고 있습니다. \
펌웨어 시작 단계에서 디바이스 트윈을 수신하고 내부에 설정사항으로 저장합니다. 그리고 펌웨어는 \
서버의 설정이 변경되었을 때 비동기적으로 이를 수신하고 업데이트 할 수 있도록 개발합니다.
### 타이머
타이머는 데이터를 주기적으로 전송하기 위해서 펌웨어 동작을 일시적으로 멈추는 것을 말합니다. \
타이머는 마지막 전송이 끝난 시점부터 지정된 시간 대기하도록 구성합니다. \
\
짧은 전송 주기를 사용하는 서비스는 데이터 전송이 예상치 못하게 길어지는 상황에서 다음 타이머 \
이벤트를 제대로 처리할 수 없기 때문에 이전 타이머 발생 시점부터 대기하도록 구성하지 않아야 합니다.
데이터 전송이 끝난 후 설정된 시간 동안 sleep 하는 방식을 권장드립니다.
위 그림처럼 서버 전송이 끝난 이후 sec 만큼 대기시키면 됩니다.
### 데이터 수집과 정제
펌웨어는 서버에 전송할 데이터를 외부에서 읽어 와야 하며, 읽어온 데이터는 재처리가 필요할 수 있으므로 정제 과정을 거쳐 서버에 전송합니다.
외부에서 데이터를 읽어올 때 하드웨어 적인 문제가 발생하거나, 외부에 위치한 데이터 원천이 데이터 \
제공을 거부하거나 제때 응답하지 않는 문제 등 여러 예외 상황이 발생할 수 있습니다.
이와 같은 예외 상황의 경우 아래 가이드를 확인해 데이터에 수집 문제가 있었음을 명시하여 \
서버로 전송하시기 바랍니다.
{% content-ref url="/pages/-M\_SygQd7UGhK2-k6cKU" %}
[부가 정보를 전송하는 방법](/meatatron-grandview/iotdevicedev/extraopts.md)
{% endcontent-ref %}
데이터 정제/재처리는 여러가지 상황에 맞게 구현되면 됩니다.
* 센서에서 너무 많은 데이터가 발생하는데 이것을 조절할 수 없는 경우에 샘플링이나 aggregation 을 \
적용하여 일부 데이터를 뽑아서 주기적으로 서버에 전송하도록 합니다.
* little endian 을 사용하는 시스템에서 데이터를 읽은 경우 big endian 으로 변환합니다. \
그리고 소수점 처리 방식이 프로그래머마다 제각각인 디지털 컨트롤러(PLC)에서 데이터를 읽을 때 \
소수점으로 데이터를 변환하여서 서버에 전송해주어야 합니다.\
데이터 정제 과정에서 데이터 값이 변조/왜곡 되지 않도록 주의해야 합니다.
### 서버의 동기적 명령
서버에서는 디바이스가 연결된 것이 확실한 상황일 때 동기적인 명령을 디바이스에 송신할 수 있습니다. \
이 명령은 IoT hub 에서 직접 메소드(direct method)로 표현됩니다. \
직접 메소드를 받고 처리할 수 있도록 핸들러를 구현해야 합니다.
기본적으로 디바이스를 원격에서 리부팅할 수 있는 직접 메소드 수신 핸들러를 구현해야 합니다. \
디바이스가 정상적으로 데이터를 보내지 않고 있다고 판단 될 때 서버에서 디바이스를 원격에서 \
리부팅하는데 사용 될 것입니다.
{% hint style="info" %}
RTOS 와 같이 하드웨어 적인 방법 외 리부팅 할 수단이 없는 경우 이 과정은 생략합니다.
{% endhint %}