﻿ [ 원 일민 칼럼 ] 산업 용 사물 인터넷 ( IIOT ) 과 INDUSTRIE 4 . 0 ( 3 ) | 아이 씨 엔 매거진 
 지난 3 월 전시회 와 세미나 를 하 면서 많 은 고객 들 이 IIOT ( 산업 용 사물 인터넷 , Industrial IoT ) 에 대한 기술 적 수준 이 높 아 졌 다는 것 을 느꼈 다 . 많 은 사람 들 이 IIOT 나 Industrie 4 . 0 의 필요 성 이나 그 적용 방 안 에 대해 실제 적 인 고민 을 하 기 시작 했 다는 것 이 다 . 아마도 다양 한 회사 에서 자사 제품 을 활용 한 적용 실적 을 발표 하 고 있 고 , 그 내용 들 이 다양 한 매체 를 통해 기사 화 되 면서 표면 적 으로 더 많이 접할 수 있 었 기 때문 이 라고 판단 된다 . 하지만 그 적용 실적 들 을 자세히 살펴볼 필요 는 있 을 것 같 다 . 많 은 경우 IIOT 제품 이나 솔루션 을 제공 하 는 회사 에서 시장 의 분위기 형성 이나 홍보 를 목적 으로 IIOT 와 의 연관 성 이 모호 한 프로젝트 를 마치 새로운 기술 이 적용 된 시스템 의 성공 사례 로 보도 하 고 있 는 경우 가 있 기 때문 이 다 . 또한 사용 자 의 입장 에서 는 보도 되 는 내용 만 으로 는 시스템 의 구조 나 주요 기능 들 에 대한 파악 이 어려운 경우 가 많 다 . 
 이런 이유 로 사용 자 는 시장 의 변화 를 감지 하 긴 하 지만 실제 적 으로 어떻게 변화 하 고 있 는지 , 이 를 위해 자신 의 회사 는 어떤 준비 를 어떻게 해야 하 는지 에 대해서 는 아직 도 많 은 의문점 을 가지 고 있 는 것 이 다 . 앞선 두 번 의 칼럼 에서 이더넷 ( Ethernet ) 기반 의 통신 과 MQTT ( Message Queue Telemetry Transport ) 와 OPC UA ( Open Productivity and Collaboration Unified Architecture ) 에 대해서 먼저 언급 한 이유 도 IIOT 를 준비 하 는 사용자 의 입장 에서 필요 한 기반 지식 이 라는 측면 에서 시간 을 할애 하 여 설명 했 던 것 이 다 . 이 를 기반 에 두 고 이번 시간 에 는 데이터 의 전송 방 안 에 대해서 생각 해 보 고자 한다 . 
 어떤 데이터 를 클라우드 로 전송 할 것 인가 ? 어떤 방법 으로 필드 데이터 를 클라우드 로 전송 할 것 인가 ? 현재 설치 되 어 있 는 시스템 을 기반 으로 구성 이 가능 한가 ? 투자 를 최소 화 할 수 있 는 방안 은 무엇 인가 ? 클라우드 로 전송 되 기 전 에 데이터 를 가공 하 여 사용 할 수 는 없 는가 ? 수 많 은 사용 자 들 로부터 이 와 같 은 질문 을 받 고 있 다 . 물론 이런 질문 을 할 정도 의 사용 자 라면 이미 IIOT 에 대한 기본 적 인 고민 이 있 었 다고 할 수 있 다 . 흔하 고 단순 한 질문 처럼 보이 겠 지만 시스템 에 대한 그림 을 그려 본 사람 이 라면 누구 나 가지 게 되 는 질문 들 이 다 . 궁극 적 으로 우리 가 말 하 는 스마트 팩토리 ( Smart Factory ) 는 무엇 을 하 기 위한 것 인가 ? 과연 어느 수준 의 시스템 이 면 이 를 잘 반영 하 고 있 다고 말 할 수 있 는 것 인가 ? 저 는 그 에 대한 답변 을 유명 한 영화 의 한 장면 을 예 를 들 어 설명 하 고자 한다 . 
 마블 의 유명 한 시리즈 중 하나 인 어벤저스 2 를 보 면 전투 에 참여 했 던 아이언맨 로봇 이 주인공 중 의 한 명 인 토니 스타크 의 빌딩 으로 복귀 하 는 장면 이 나온다 . 복귀 를 한 후 다른 로봇 이 전투 에 참여 했 던 로봇 을 스캔 하 여 고장나 거나 부서진 부분 을 확인 한 후 수리 를 하 고 이 들 로봇 은 다시 대기 장소 로 보내 진다 . 또 다른 장면 에서 는 로봇 이 폐기 된 부품 을 모아 또 다른 로봇 을 만드 는 장면 이 나온다 . 아마도 이 두 장면 이 현재 우리 가 추구 하 고자 하 는 스마트 팩토리 의 최종 목적지 이 지 않 을까 생각 된다 . 생산 라인 의 자동 화 설비 들 은 프로그램 되 어 진 대로 제품 을 생산 하 고 생산 중 자재 수급 이 필요 할 경우 AGV ( Automatic Guided Vehicle ) 가 자동 창고 에서 스스로 자재 를 반출 해 필요 한 위치 에 공급 한다 . 생산 설비 가 고장 났 을 경우 에 는 기기 간 의 통신 을 통해 고장 이나 파손 부위 를 확인 하 고 , 이 를 수리 로 봇 이 스스로 수리 하 거나 새로운 제품 으로 교체 하 는 시스템 이 IIOT 를 활용 한 스마트 팩토리 최종 모습 의 한 단면 일 것 이 다 . 
 물론 아직 은 현실 적 으로 불 가능 한 부분 이 있 다 . 예 를 들 어 , 고장 의 진단 은 자동 으로 가능 하나 고장 제품 의 교체 는 많 은 경우 사람 의 손 을 빌려야 한다 . 그리고 , 새로운 제품 이 연결 이 되 면 클라우드 와 의 통신 을 통해 기존 에 클라우드 에 저장 된 파라 메터 를 자동 으로 다운로드 받 아 즉시 구동 이 가능 하 게 할 수 있 다 . 하지만 이런 부분 들 또한 아직 준비 중 인 단계 이 다 . 그렇 다면 미래 의 Smart Factory 를 위해 우리 는 어떤 것 부터 시작 해야 하 는가 ? 앞서 언급 했 던 질문 에 대한 답변 을 하나 씩 찾 아 보 기 로 하 자 . 
 현재 우리 가 공장 에서 사용 하 고 있 는 시스템 을 간단 하 게 표현 하 면 아래 의 그림 과 같이 표현 할 수 있 다 . 제어기 를 중심 으로 하드 와 이어링 , 필드버스 또는 리얼타임 이더넷 ( Real - Time Ethernet ) 을 통해 로봇 , 서보 드라이버 , 인버터 , IO 디바이스 , 센서 , 액추에이터 등 이 연결 된다 . 이렇게 연결 된 시스템 은 제어기 의 명령 에 따라 동작 을 하 거나 로봇 처럼 별도 의 프로그램 에 의해 동작 을 하 다가 필요 한 경우 전체 시스템 을 제어 하 는 제어기 로부터 명령 을 받 아 다음 동작 을 수행 하 게 된다 . 이 와 같 은 현재 의 시스템 에서 발생 하 는 데이터 를 그림 의 상단 에 있 는 클라우드 로 올리 는 것 이 IIOT 활용 의 시작 이 다 . 현재 의 시스템 에서 데이터 를 클라우드 로 올리 는 가장 간단 한 방법 은 제어기 를 직접 클라우드 로 연결 하 는 것 이 다 . 제어기 가 PC 가 아니 라 PLC 혹은 DCS 라고 하 더라도 이더넷 포트 ( Ethernet port ) 또는 이더넷 모듈 ( Ethernet module ) 은 존재 한다 . 이 를 통해 클라우드 로 연결 하 는 것 이 가장 간단 한 방법 이 고 , 또한 투자 비용 도 가장 줄일 수 있 는 방법 이 다 . 
 엣지 게이트웨이 를 통한 리얼타임 팩토리 시스템 구성 방안 ( 이미지 . hilscher ) 
 하지만 몇 가지 제약 사항 이 따른다 . 현재 의 시스템 이 리얼타임 이더넷 을 사용 하 는 시스템 이 라는 가정 하 에 설명 하 겠 다 . 제어기 가 가지 고 있 는 각 필드 디바이스 의 정보 는 크 게 3 가지 이 다 . 첫 번 째 는 각 디바이스 가 가지 는 IO 데이터 의 Size 이 다 . Master 가 자신 의 네트워크 를 Configuration 하 기 위해서 는 각각 의 Slave 가 가지 는 입력 과 출력 데이터 가 각각 몇 바이트 인지 반드시 알 아야 한다 . 이 와 같이 각 필드 디바이스 의 IO Size 가 제어기 가 가지 는 첫 번 째 정보 이 다 . 두 번 째 는 특정 필드 디바이스 가 가지 는 파라미터 이 다 . 예 를 들 어 필드 디바이스 중 에 온도 제어기 가 있 다고 한다면 각 온도 제어기 의 설정 값 을 제어기 가 알 고 있 어야 한다 . 물론 온도 제어기 스스로 설정 값 을 저장 하 는 기능 도 있 지만 일반 적 으로 제어기 에서 각 디바이스 의 설정 값 을 저장 하 고 있 다가 필요 시 설정 값 을 디바이스 로 전달 한다 . 세 번 째 정보 는 각 디바이스 의 진단 정보 이 다 . 리얼타임 이더넷 통신 을 하 면서 각 디바이스 가 정상 적 으로 통신 이 되 는지 , 통신 이상 이 발생 했 을 경우 몇 번 Station 에서 발생 했 는지 어떤 종류 의 Error 가 발생 하 였 는지 와 같 은 진단 정보 가 제어기 의 세 번 째 정보 인 것 이 다 . 
 그렇 다면 이 세 가지 정보 를 클라우드 로 올려 주 면 IIOT 기능 을 충실히 따르 는 것 일까 ? 클라우드 에서 각 디바이스 의 IO Szie 나 설정 값 , 진단 정보 가 필요 할까 ? 이 정보 들 을 받 아서 빅 데이터 로 만드 는 것 이 유의미 한 것 인가 ? 일반 적 으로 제어기 가 가지 는 각 필드 디바이스 의 정보 양 은 최소한 으로 제한 을 하 는 경우 가 많 다 . 이 는 시스템 의 안정 성 과 관련 이 있 다 . 제어기 는 시스템 의 구동 을 효율 적 이 며 안정 적 으로 하 는 것 에 그 목적 이 있 다 . 제어기 가 처리 해야 하 는 정보 의 양 이 많 아 지 게 되 면 그 와 비례 하 여 프로그램 의 양 이 많 아 지 게 되 고 , 이 는 프로그램 의 Cycle Time 에 영향 을 주 게 된다 . 또한 필드 디바이스 가 기존 의 3 가지 정보 외 에 자신 의 CPU 온도 , Motor 의 온도 , 가동 시간 , 정지 시간 , 실제 구동 시간 , 대기 시간 등 제공 할 수 있 는 모든 정보 를 기존 의 리얼타임 이더넷 통신 라인 을 통해 실시간 으로 전송 하 게 되 면 통신 시간 또한 느려 지 게 된다 . 제어기 의 Cycle Time 과 통신 시간 이 느려 지 게 되 면 시스템 의 운영 에 영향 을 미치 게 되 고 , 이 는 불량품 의 발생 이나 생산량 의 저하 와 같 은 부작용 으로 이어진다 . 필드 데이터 를 클라우드 로 전송 하 기 위한 부수 적 인 기능 의 추가 로 인해 시스템 본래 의 목적 인 생산 에 지장 을 받 게 되 므로 주객 이 전도 되 는 결과 를 가지 게 되 는 것 이 다 . 
 기존 의 제어기 를 사용 하 여 클라우드 로 의 접속 을 구현 하 려고 한다면 먼저 어떤 데이터 를 클라우드 로 올릴 것 인지 선정 하 여야 한다 . 각 필드 디바이스 는 많 은 종류 의 부가 적 인 정보 를 제공 하 고 있 으며 , 이 모두 를 클라우드 로 전송 하 는 것 은 시스템 의 변경 없이 는 불 가능 하 다 . 어떤 데이터 를 수집 하 여 빅 데이터 화 한 후 어떤 결과 를 도출 하 려고 하 는지 먼저 결정 한 후 에 각 디바이스 들 로부터 추가 로 데이터 를 수집 해야 한다 . 또한 수집 되 는 데이터 의 양 으로 인해 시스템 의 제어 에 영향 을 주 지 않 는 통신 속도 를 찾 아야 한다 . 많 은 경우 디바이스 의 3 가지 기본 정보 외 에 추가 정보 는 데이터 의 사이즈 가 크 고 , 모든 디바이스 들 로부터 수집 되 어야 하 기 때문 에 그 총합 은 기존 데이터 용량 보다 훨씬 클 수 가 있 다 . 또한 수집 된 데이터 를 처리 하 기 위해서 프로그램 도 추가 되 어야 하 는데 , 프로그램 또한 Cycle Time 에 영향 을 주 지 않 는 범위 내 에서 늘려야 한다 . 기존 의 시스템 을 그대로 사용 하 여 투자 비용 을 최소 화 한다는 장점 이 있 는 반면 에 수집 할 수 있 는 데이터 의 용량 에 제한 이 있 다는 점 이 사용 자 에게 있 어서 단점 이 될 것 이 다 . 
 두 번 째 방안 은 필드 디바이스 를 직접 클라우드 로 연결 하 는 것 이 다 . 이 를 위해서 각각 의 필드 디바이스 는 IIOT 기능 , 즉 MQTT 나 OPC UA 와 같 은 프로토콜 을 채택 하 고 있 어야 한다 . 앞서 예 를 든 것 과 마찬가지 로 리얼 탕 미 이더넷 통신 라인 을 통해서 MQTT 와 OPC UA 를 즉시 사용 할 수 있 으므로 시스템 구조 상 에서 크 게 추가 되 거나 변하 는 것 은 없 다 . 다만 클라우드 로 연결 이 필요 한 필드 디바이스 의 변경 이 요구 된다 . 단순 하 게 설명 해서 필드 디바이스 에 IIOT 기능 을 부여 하 는 것 이 지만 이 는 결코 단순 한 문제 가 아니 다 . 각각 의 필드 디바이스 들 은 고유 의 기능 과 특성 을 가지 고 있 다 . 단순 한 IO Device 를 제외 한 단축 모션 제어기 , 서보 드라이버 , 온도 제어기 , 용접기 , 유압 또는 공 압 제어기 , 로봇 제어기 등 과 같 은 디바이스 들 은 해당 메이커 에서 IIOT 기능 을 제공 하 지 않 으면 사용 자 입장 에서 는 적용 이 거의 불 가능 하 고 , 다른 메이커 에서 해당 기능 을 가지 는 유사 한 제품 이 있 다고 하 더라도 그 제품 으로 의 전환 또한 간단 치 않 다 . 
 옵션 모듈 이나 옵션 보드 화 되 어 기존 제품 에 장착 하 여 사용 할 수 없 는 경우 에 는 클라우드 로 의 연결 이 필요 한 모든 제품 의 교체 가 요구 될 수 도 있 다 . 하지만 이렇게 하 면 제어기 가 데이터 를 수집 할 필요 가 없 고 , 표준 이더넷 TCP / IP 를 사용 하 기 때문 에 기존 시스템 의 속도 가 느려진다 거나 하 는 부작용 은 없 다 . 클라우드 와 필드 디바이스 간 에 어떤 데이터 를 공유 할 것 인지 에 대한 설정 을 하 면 자동 적 으로 필요 데이터 가 클라우드 로 전달 이 된다 . 이렇게 전송 되 는 데이터 는 클라우드 로 도달 되 기 전 에 가공 하 거나 먼저 사용 할 수 없 다는 단점 이 있 다 . 또한 모든 데이터 가 전송 되 기 때문 에 경우 에 따라서 불 필요 한 데이터 까지 모두 취합 되 고 이것 은 클라우드 저장 공간 의 비 효율 성 을 초래 할 수 도 있 다 . 
 마지막 세 번 째 방안 은 엣지 게이트웨이 ( Edge Gateway ) 를 사용 하 는 것 이 다 . 엣지 게이트웨이 는 IT ( 정보 기술 ) 영역 과 OT ( 운용 기술 ) 영역 의 양 끝단 에 위치 하 며 , 두 영역 을 연결 시켜 주 는 역할 을 한다 . 제품 에 따라서 수집 된 데이터 를 아무런 가공 없이 전송 하 는 역할 을 하 거나 별도 의 프로그램 을 통해 일부 데이터 의 가공 과 그 결과 에 따른 특수 한 동작 을 할 수 도 있 다 . 엣지 게이트웨이 를 사용 하 는 방 안 에 대해서 는 다음 시간 에 자세히 알아보 도록 하 겠 다 . 
 엣지 게이트웨이 
 이전 기사 엔 비디아 인공지능 시스템 을 가능 케 한 바이 코 솔루션 들 
 다음 기사 인 피니언 , 전력 반도체 생산 공장 건립 에 2 조 원 투자 
 [ # sps _ live ] OPC Foundation extends OPC UA including TSN down to field . .. 
 오 윤경 - 2018 - 11 - 29 
 The OPC Foundation launches an initiative to further enable OPC UA adoption throughout industrial automation by extending standardization and harmonization activities for OPC UA . .. 
 TI , ‘ 인터넷 - 온 - 칩 ’ 제품 으로 모든 기기 에서 와이파이 추가 … 사물 인터넷 지원 
 TI unlocks mmWave technology for worldwide industrial market through new 60 - GHz . ..