Policy profile

디바이스 트윈을 통해 전달되는 Policy profile 을 처리하는 방법을 설명합니다. 서버 투 서버 인터페이스 방식에서는 사용되지 않으며, IoT hub 를 통할 때만 활용할 수 있는 기능입니다.

디바이스 트윈이란

GitBook

위 URL 에서 디바이스 트윈의 개념을 확인하시기 바랍니다.

디바이스 트윈 데이터

디바이스 트윈은 디바이스의 상태나 서버와 주고 받을 수 있는 메타 정보들을 모두 저장하고 있습니다.

• 디바이스 트윈 예시

{
    "deviceId": "aaa",
    "etag": "AAAAAAAAAAY=",
    "deviceEtag": "Nzg3MzM1OTQ=",
    "status": "enabled",
    "statusUpdateTime": "0001-01-01T00:00:00Z",
    "connectionState": "Connected",
    "lastActivityTime": "2021-05-12T00:56:43.0412162Z",
    "cloudToDeviceMessageCount": 0,
    "authenticationType": "sas",
    "x509Thumbprint": {
        "primaryThumbprint": null,
        "secondaryThumbprint": null
    },
    "modelId": "",
    "version": 56,
    "properties": {
        "desired": {
            "policy": {
                "ver": {
                    "maj": 1,
                    "mnr": 1
                },
                "fw": 1.5,
                "brate": 9600,
                "sec": 120,
                "devices": {
                }
            }
        },
        "reported": {
          ...
        }
        ...
    }
}

Policy profile

Policy profile 은 서버에서 IoT 디바이스가 동작하는 방법을 정의할 수 있는 체계입니다. Policy profile 은 디지털 트윈에 저장된 후 IoT hub 의 디바이스 트윈 기능을 통해 IoT 디바이스에 전달 될 수 있습니다.

디바이스 트윈에는 다른 정보들이 많이 저장되어 있는데, 이중 policy profile 로 사용되는 곳은 properties.desired.policy 입니다.

• Policy profile 의 기본 구조

"desired": {
    "policy": {
        "ver": {
            "maj": 1,
            "mnr": 0
        },
        "fw": 1.0,
        "brate": 9600,
        "sec": 120,
        "devices": {
        }
    }
}

각 필드에 대한 설명은 아래와 같습니다.

필드	설명
policy	child 의 object 를 파싱해서 펌웨어에서 처리합니다.
ver	Policy profile 의 버전을 나타냅니다. 펌웨어는 휘발성 메모리 공간에 현재 내가 실행되고 있는 policy profile 의 버전을 저장하고 있어야 합니다. 그 후 서버에서 디바이스 트윈이 변경되었다는 이벤트를 수신하면 이 버전 필드를 비교한 후 펌웨어가 동작하는 설정을 새로 업데이트 해야 합니다.
fw	펌웨어 어플리케이션의 버전 정보입니다. 서버에서 관리하기 위한 값이며 펌웨어에서는 무시할 수 있는 필드입니다.
brate	시리얼 통신에 필요한 baudrate 를 지정합니다. 디지털 컨트롤러(PLC)에 연결하는 IoT 디바이스의 경우 이 필드에 지정된 baudrate 로 디지털 컨트롤러(PLC)와 시리얼 통신하면 됩니다.
sec	데이터 수집 주기를 나타냅니다. 마지막 데이터 전송이 완료된 이후 이 필드에 지정된 시간동안 펌웨어 동작이 타이머 이벤트를 기다리거나 sleep() 하면 됩니다.
devices	IoT 디바이스가 여러 데이터 원천에서 데이터를 수집하는 경우 그 원천들을 구분하기 위해서 사용될 수 있습니다. 이 필드 아래에는 각 원천마다 어떤 deviceId 를 써야만 하는지 설정되어 있을 것이며, 각 원천마다 개별적으로 데이터를 만들고 전송해야 합니다. 데이터 원천이 나 자신 하나인 경우에도 이 필드는 값을 가질 수 있으며, 이 필드에 지정된 값대로 deviceId 를 설정하고 데이터를 보내야 합니다.

devices 필드 값을 사용하는 방법

• Policy profile 예시

"desired": {
    "policy": {
        "ver": {
            "maj": 1,
            "mnr": 0
        },
        "fw": 1.0,
        "brate": 9600,
        "sec": 120,
        "devices": {
          "sensor1": {
            "idx": 0
          },
          "sensor2": {
            "idx": 1
          }
        }
    }
}

예시에는 devices 아래에 2개의 JSON 객체 "sensor1" 과 "sensor2" 가 있습니다. 각각 idx 라는 필드를 갖고 있으며, idx 필드는 같은 policy profile 내에서 배열에 인덱싱하듯 0부터 시작하는 정수로 순서대로 지정됩니다.

펌웨어는 이 설정으로 2개의 IoT 디바이스 데이터를 만들어야 합니다.

{
  "serviceId": "1",
  "deviceId": "sensor1",
  ...
  "contents": {
  ...
  }
}

{
  "serviceId": "1",
  "deviceId": "sensor2",
  ...
  "contents": {
  ...
  }
}

Policy profile 의 sec 주기 마다 위 2개의 데이터를 각각 센서들로부터 얻어서 독립적으로 서버로 전송해야 합니다. 그리고 devices 아래에 있는 sensor1, sensor2 는 각각 deviceId 로 사용합니다.

MODBUS 네트워크가 구성되어 있고 단일 IoT 디바이스로 전체 네트워크에 엑세스 해서 데이터를 얻는 경우 개별 설비 별로 데이터 원천을 명확히 구분을 해야 그랜드뷰에서 제대로 데이터를 활용할 수 있습니다. 이와 같은 경우 devices 필드로 데이터 원천을 구분합니다.

sec 필드

sec 필드는 펌웨어 입장에서는 단순히 타이머를 기다리거나 sleep() 할 수 있는 값이지만, 전체 서비스 관점에서는 데이터를 수집하는 주기를 뜻합니다. 이 데이터 수집 주기는 사업적인 의사결정 통해 지정이 되는 부분으로, 아래 문서에서 더 자세한 내용을 확인하기 바랍니다.

데이터 전송 대상과 주기