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