IoTLinker

IoTLinker 소개

IoT Linker는 산업용 IoT 환경을 서로 쉽게 연결할 수 있도록 도와주는 IIoT 서비스 프레임 워크입니다. 라즈베리 파이 같은 소형 컴퓨터에서 동작 가능 하며 빠른응답을 지향 합니다. 룰 기반의 이벤트를 탐지 합니다. 탐지한 이벤트를 기반으로 실시간으로 액션을 발생하여 환경에 영향을 줍니다. 또한 사용자들이 쉽게 데이터를 분석 할수 있는 환경을 제공하는 것을 목표로 합니다.

IoTLinker 핵심 기능

• IoT Data Acquisition (데이터 수집)
• IoT Device Management (장치 관리)
• IoT Rule Engine (룰 엔진)
• IoT Event Management (이벤트 관리)
• IoT Action Management (액션 처리)
• IoT Data Analytics (데이터 분석)

IoTLinker Design Goals

1. Data Tag 기반 데이터 수집
2. 고속 데이터 수집 지원 (ms 단위 데이터 처리,수집된 배열 데이터에 대한 처리,이미지 데이터 처리)
3. 저사양 디바이스에서도 서버를 구축하여 언제 어디서나 디바이스간 연계가 가능한 마이크로 IoT 서버 구축 한다. (라즈베리파이)
4. 플랫폼은 최소 기능만 제공한다. (수집(Mqtt),장치 관리,처리(Context Engin),실시간 제공(Websocket),데이터 분석(분석),대쉬보드)
5. 쉽게 머신 러닝 플랫폼과의 연계한다.(데이터 분석이 용이)

주요 Package

• Context Package : Rule 룰을 이용해서 이벤트 검출을 수행하는 패키지
• Net Package : 외부 외부 인터페이스 패키지
• Database Package : 데이베이스 관련 패키지
• Messaging Package : 메시지 관련 패키지

사용 라이브러리 목록

Language

• Golang: https://golang.org/

Database

• MongoDB: https://github.com/globalsign/mgo.git

Messaging System

• nats :https://www.nats.io/

외부라이브러리

• paho: https://www.eclipse.org/paho/clients/golang/

Go 로 프로그램을 변경하면서 고려할만한 부분

1. 각 프로그램을 분리하여 시스템의 종석성을 줄인다. 메시지 큐나 이벤트 버스를 사용한다면 각 각 프로그램 중앙에 메시지 큐를 이용해서 데이터 공유 및 상호 작용 가능
2. Redis 에서 수행하던 Device & Tag 매칭 부분을 직접 몽고디비에서 수행하도록 수정 예정
3. Root/main.go 는 각 App 실행하는 역할 수행

Architecture

데이터 타입

DATA TYPE
BIT
NUMBER
ARRAY
STRING
JSON
IMAGE
GEO POINT

식별자 구조

Object	ID_TYPE
Location	LOCATION_ID
Devcie	UUID
TAG	TAG_NAME

기능

IoT Data Acquisition (데이터 수집)

MQTT 메시지 수집 지원

Modbus 메시지 지원

OPC UA 지원

MT Connect 지원

Coap 지원(미정)

사용자 정의 토픽 지정

• Redis를 이용한 사용자 정의 필요
• 테크및 디바이스의 토픽을 레디스에 저장하여 처리
• 디바이스 및 테그를 생성하면 토픽을 레디스에 저장한다.
• 토픽은 MQTT 연결시 구독을 등록한다.
• 메시지가 들어오면 해당 토픽이 메시지에 있는지 검사한다.
• 토픽을 검사하여 핵심 정보를 구한다. 디바이스 정보/ 테크 정보
• 해당 정보를 가지고 메시지를 처리 한다.

각 데이터 수집용 프로그램을 따로 만듬

• 서비스 포트, Queue 연결 정보, 인증 정보는 따로 받음 , 인증 정보는 Redis 를 이용해서 처리 가능

REDIS 활용

소문자만 사용 기본 TAG 키 tag 별 토픽을 레디스에 저장하여 캐쉬로 사용 아래의 데이터를 저장함 다른 프로토콜에서도 레디스를 이용하면 쉽게 디바이스에 접근 가능하다. (긍정적 고려 ) topic:<실제토픽> topic은 셋데이터 타입으로 저장하여 중복을 막는다. sadd,smember

IoT Device Management (장치 관리)

IoT Rule Engine (룰 엔진)

Context Rule Linker Context Engin

실시간 룰 처리 엔진

스케줄링 룰 기능

• 일정 시간마다 룰 검사후 해당 이벤트 발생

Tag 별 룰 지정

룰별 도큐먼트 구성

WAITING 타임시리즈 룰 (들어오는 데이터의 순차적인 모량 평군 편차 등을 검출 하여 판별하는 룰 )

복합 룰 (복합적인 테그의 정보로 이벤트 판별 ->레디스를 이용하여 복합적인 테크 정보를 묶어서 저장)

머신러닝 모델 (머신러닝모델의 판별된 퓨처들을 복합룰을 이용하여 판별 )

• 텐서의 모델을 적용 할수 있는 프레임 워크 구축
• 오닉스 모델 지원(모델 데이터 ONNX)

IoT Event Management (이벤트 관리)

IoT Action Management (액션 처리)

Context Action

Message Section Action (MQTT,CoAP,REST,MODBUS,OPC_UA)

CANCELLED 일정 주기마다 파일 저장(정말 필요하진 의문 몽고디비에서 조회해서 보여주는게 더 효과적)

이벤트 발생(알람,경고,정보,사용자 지정)

Work Flow 지정(연속적인 순차적인 액션 처리,Context Cain)

IoT Data Analytics (데이터 분석)

센서 데이터 분석

• 핫 데이터 (많은 양에 데이터를 빠르게 인사이트 분석)
• 콜드 데이터 (데이터를 누적해서 데이터 분석)
• 스트림 데이터 분석 (실시간 통계 분석, 이동평균)

Common 기능

API 제공

REST API 제공

Swgger Api 문서화

대쉬 보드 제공

• Tag 별 위젯 타입
• 그룹 별 위젯 타입
• 카드 UI
• Websocket

파일 데이터 Export

보안

인증서 처리

Mqtt 보안

기본 모델 구성

User

• 사용자 수집 정보(메일 )
• 등급(admin,manager,customer)

Role

• manager,admin,costomer
• 소유권 개념이 필요
• Tag, Group , Device 오너 개념이 필요 하다.
• 향후를 위하여 구현을 미룸

Tag

• Tag 변경 이벤트를 감지하여 Bloker에 등록을 해제 하거나 등록 한다.
• Read/Write tag 지정
• 스카다와 유사하게 구성 하자(기존 PLC 데이터에 적합 하도록 구성)
• @listens_for(Image, ‘after_delete’) 참고
• 데이터 타입
• 테그 이름
• 디바이스에서 유일한 이름을 가짐
• Topic 을 가짐 레디스에 토픽을 등록 한다.

Location

• LocationType 지정
• 디바이스 위치
• 논리적 위치나 gps 정보 보유
• 빌딩 공장 위주

Device

• TAG가 존재하는 디바이스
• 하드웨어 및 소프트웨어
• 테크를 보유하고 있음
• UUID기준의 ID를 가짐: 022db29c-d0e2-11e5-bb4c-60f81dca7676
• 디바이스 타입은 정적으로 하는가 동적으로 해야하는가?

Context Rule

• Rule
• 실행 액션 N개
• 발생 이벤트 N개
• 룰 종류
• 룰은 데이터 타입 별로 정의
• 룰을 에서 Json 데이터를 유연하게 처리 하도록 구성 필요(스크립트 엔진)

  DATA TYPE	Rule
  All	기본 저장
  BIT	True/flas,On/Off
  NUMBER	</>,= , 범위내, 범위 밖 /
  ARRAY	합계/평균/분산/기울기/비트연산
  STRING	같다 / 다르다
  Json	속성 연산

Context Action

• 룰에 따라서 수행되는 액션
• 저장
• 메시지 전송
• 추가룰 지정
• 새로운 테크를 만들어서 레디스에 저장
• 연산 저장

Context Event

• 룰에 따라서 이벤트 발생
• 그룹에 따라서 이벤트 발생
• 타임 라인에 디스플레이 하기 좋은 구조를 가져야 함
• 이벤트 타입을 가진다. (알람,알림,정의,행위 )

Context Event History 구성

• 이벤트 처리 히스토리 저장

Context Action History 구성

• 액션 처리 히스토리 저장

UI (Vue.js)

Dashboard :대쉬 보드 구현은 최하위

• 복수의 대쉬 보드 구성 가능
• Layout 구성에 대한 방안 모색
• 사용자 구성 가능
• 산업용 구성에 적합하도록 구성
• SCADA 작화에 대해서 생각해 보자

TagWeget

• TAG별 위젯 지정
• 데이터 타입에 따라서 지정
• 객체는 모양을 지정하거나 복수도 지정

WegetGroup

• 복수의 위젯 구성
• 그룹 객체 지정(그룹 객체 모양도 여러가지 구성)
• 간단하게 보이는 뷰도 있었으면 한다. 클릭시 큰 화면을 보여줌(아이디어)

메시지 처리 프로세스

Celery 를 이용한 메시지 처리(해당 부분 변경 예정)

1. 주기적으로 데이터를 수집한다.
2. 동일 프로세스를 이용해서 데이터를 정지 없이 계속 수집한다.
3. 셀러리 모니터링 기능을 넣는다.
4. 셀러리에서 엑션을 추가하는 방식을 이용해서 Chain 형태로 데이터를 처리한다.
5. 그룹단위로 테크 처리
6. 이슈 클래스로 처리할 필요 있음

Linker Context Engine (룰 엔진 처리)

1. 레디스에 넣은 메시지를 메시지 처리 프로세스로 처리 한다.
2. 그룹단위 프로세스 테그 단위 프로세스
3. 해당 메시지의 속성을 값을 비교해서 처리 여부를 결정 한다.
4. 초기에는 해당 테크 기간 등을 지정하여 메시지러를 저장하도록 하자
5. 기간,Tag or Group 지정, 조건 지정 복수의 액션을 지정
6. 데이터 처리 기능을설계 필요

컨텍스트 처리 구조
리소스: Tag/ Group/ 데이터 (메시지)
조건 : < > = 기간
액션 : 파일저장

ActionAdapter: 필요한가?

Action 사용할수 있는 Adpter

• FilerAdapter
• RestAdapter
• MailAdapter

디바이스 별 커넥션 관리

• 디바이스 타임안웃 시간 동안 보유한 테그의 메시지가 없을 경우 TimeOut 으로 판별
• 디바의에 주기적으로 핑을 날려서 커넥션을 확인 (정상적인 작동이 어려움)

Celery Task 작업

• task Type 주기적인 작업
• 일회성 작업
• 일정 기간동안 유지되는 작업 ?? 가능한지 확인 필요
• 긴 시간이 걸리는 작업

message 수신

1. 레디스 큐를 갱신 한다.
2. 메시지를 수신하면 레디스에 넣는다. Set Json 형태로 넣는다.
3. 큐는 그룹 및 테크의 처리 방식에 따라서 처리 한다.
4. 데이터 처리 룰에 따라서 그룹이나 테그의 정보를 처리 한다. 아직 룰의 정보 처리 방식은 아직 미정

Websocket

• Dashboard Websocket 기능 추가

DATA Pub/Sub (TAG,DEVICE,History)

시작하기(튜토리얼 작성 )

설치하기 (Raspbarrypie,Ubuntu)

Service Application Start

• IoTLinker run

Redis Install

• http://redis-py.readthedocs.io/en/latest/

mosquitto Install

mosquitto start

mosquitto -v or service moquitto start 

MQTT

https://www.eclipse.org/paho/clients/python/docs/

Node-Red Install // 필요 한가?

Mongo DB

Mongodb Service Start

서비스 자동시작 systemctl enable mongod.service

서비스 수동 시작 sudo service mongod start

• use pyMongo
• use mongoengin
• http://docs.mongoengine.org/

디바이스 게이트웨이

• 각 노드들이 디바이스 정보를 게이트웨이에 등록하고 요청시 UUID 를 기준으로 제공한다.
• 디바이스 데이터 캐쉬 기능을 담당
• 각 노드를 네트워크로 구성하고 앞단에서 게이트 웨이를 통해서 여러 노드를 통합