KR101734743B1

KR101734743B1 - 하드웨어 컴포넌트들의 원격 제어를 위한 제어 시스템 및 방법

Info

Publication number: KR101734743B1
Application number: KR1020157023330A
Authority: KR
Inventors: 타미르 에이. 헤가지
Original assignee: 카타르 파운데이션
Priority date: 2013-02-13
Filing date: 2013-04-26
Publication date: 2017-05-11
Also published as: JP2016519344A; KR20150136059A; US20150378356A1; WO2014124701A1; GB201302534D0; WO2014124702A1; CN105122162A; WO2014124703A1; JP6382225B2; CN105122162B; US10152048B2; EP2956828A1; WO2014124704A1; WO2014124705A1

Abstract

제어 시스템은 제1 하드웨어 컴포넌트와 제2 하드웨어 컴포넌트, 및 하드웨어 컴포넌트들로부터 원격에 있는 서버를 포함한다. 서버는 인터넷을 통해 하드웨어 컴포넌트들에 접속되는 클라우드 내의 서버이다. 제어 모듈은 서버에서 실행 중인 서비스로서 구현되고, 제어 모듈은 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 하드웨어 컴포넌트들과 통신하도록 동작 가능하다.

Description

하드웨어 컴포넌트들의 원격 제어를 위한 제어 시스템 및 방법{A CONTROL SYSTEM AND METHOD FOR REMOTE CONTROL OF HARDWARE COMPONENTS}

본 발명은 제어 시스템 및 방법과 관련되는데, 보다 상세하게는 클라우드 기반 서버들과의 사용을 위한 제어 시스템 및 방법과 관련된다.

디지털 컴퓨터들은 1960년경 제어 시스템들에서 처음 사용되었다. 그 때 이후로 내내, 제어 시스템들의 진화는 컴퓨팅 디바이스들의 발전과 연관되어 왔다. 요즘, 자동화 시스템은 여러 개의 위계적 계산 및 통신 계층들을 수반하는 다중 계층 아키텍처(multi-tiered architecture)이다. 자동화가 모니터링, 감독 제어, 경보 관리, 이력화, 공장 레벨 관리, 및 기업 레벨 애플리케이션들과 같은 직접적인 자동 제어에 더하여 그 외의 더 높은 레벨 기능들을 제공함에 따라 자동화의 의미는 이제 자동 제어를 넘어서고 있다.

기존 기술을 이용하는 대규모 자동화 프로젝트는 매우 비용이 많이 들고 또한 시간 소모적인 노력이다. 이는 상당한 인간 엔지니어링 노력에 더하여 방대한 양의 하드웨어와 소프트웨어를 요구한다. 자동화의 초기 비용은 종종 모두 합하여 수천만 달러에 달한다. 덧붙여, 기존 자동화 시스템에서의 엄청난 투자로 인해 또 다른 자동화 제공자로의 스위칭은 보통 회피된다. 비용을 별문제로 하여도, 전체 자동화 시스템의 재배치는, 특히 실행 중인 공장들의 경우, 극도로 지루한 것이다.

본 발명은 개선된 제어 시스템 및 방법을 제공하도록 시도한다.

본 발명의 한 양태에 따르면, 제1 하드웨어 컴포넌트, 제2 하드웨어 컴포넌트, 하드웨어 컴포넌트들로부터 원격에 있는 서버 - 여기서 데이터가 하드웨어 컴포넌트들과 서버 사이에서 통신될 수 있도록 하드웨어 컴포넌트들은 서버와 통신 상태에 있음 - , 및 서버상에서 실행되는 서비스로서 구현되는 1차 제어 모듈 - 1차 제어 모듈은 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 하드웨어 컴포넌트들과 통신하도록 동작 가능함- 을 포함하는 제어 시스템이 제공된다.

바람직하게는, 하드웨어 컴포넌트들 중 하나는 센서이다.

편리하게는, 하드웨어 컴포넌트들 중 하나는 액추에이터이다.

유리하게는, 제1 및 제2 하드웨어 컴포넌트들은 단일 하드웨어 유닛에 통합된다.

바람직하게는, 1차 제어 모듈은 제어 시스템에서의 직접 제어 계층의 부분을 형성한다.

편리하게는, 1차 제어 모듈은 서버상에서 실행중인 알고리즘을 서비스로서 포함한다.

유리하게는, 하드웨어 컴포넌트들은 TCP(transmission control protocol)의 위에서 실행되는 필드 레벨 프로토콜을 사용하여 서버와 통신한다.

바람직하게는, 하드웨어 컴포넌트들은 Modbus/TCP 및 Profibus/TCP를 포함하는 그룹으로부터 선택되는 프로토콜을 사용하여 서버와 통신한다.

편리하게는, 하드웨어 컴포넌트들은 인터넷을 통해 서버와 통신한다.

유리하게는, 서버는 클라우드의 부분을 형성하는 서버이다.

바람직하게는, 하드웨어 컴포넌트들 중 적어도 하나는 클라우드에 직접적으로 접속된다.

편리하게는, 하드웨어 컴포넌트들 중 적어도 하나는 근거리 네트워크를 통해 클라우드에 접속된다.

유리하게는, 하드웨어 컴포넌트들 중 적어도 하나는 게이트웨이 서버를 통해 클라우드에 접속된다.

바람직하게는, 게이트웨이 서버는 하드웨어 컴포넌트들과 동일한 빌딩에 위치 설정된다.

편리하게는, 시스템은, 1차 제어 모듈을 모니터 및 제어하기 위해 사용자로 하여금 서버와 상호 작용하는 것을 가능하게 하기 위해 서버와 통신 상태에 있는 사용자 인터페이스를 더 포함한다.

유리하게는, 사용자 인터페이스는 PaaS(platform as a service) 또는 SaaS(system as a service)로서 구현된다.

바람직하게는, 하드웨어 컴포넌트들은 프로세스 변수를 출력하고, 시스템은 프로세스 변수를 1차 제어 모듈의 입력에 통신하는 피드백 루프를 포함하며, 여기서 시스템은 1차 제어 모듈과 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 프로세스 변수를 수정하는 지연 보상기 모듈을 더 포함한다.

편리하게는, 시스템은 프로세스 변수를 수신하는 제1 입력 및 기준값을 수신하는 제2 입력을 포함하는 비교기 유닛을 더 포함하며, 여기서 비교기 유닛은 프로세스 변수를 기준값과 비교하고 비교 값을 1차 제어 모듈의 입력에 출력하는데, 여기서 지연 보상기 모듈은 지연 보상 값에 의해 프로세스 변수 또는 에러 값을 수정한다.

유리하게는, 지연 보상기 모듈은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나 사이의 통신에 있어서의 왕복 시간 지연(roundtrip time delay)에 상응하도록 지연 보상 값을 선택한다.

바람직하게는, 지연 보상기 모듈은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나 사이의 통신에 있어서의 왕복 시간 지연과 동등하게 되도록 지연 보상 값을 선택한다.

편리하게는, 지연 보상 모듈은 스미스 예측기(Smith Predictor)이다.

유리하게는, 스미스 예측기는 1차 제어 모듈과 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 프로세스 변수 대신에 프로세스 에러를 수정한다.

바람직하게는, 시스템은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나 사이의 통신에 있어서의 왕복 시간 지연을 추정하도록 동작 가능한 지연 추정기 모듈을 더 포함한다.

편리하게는, 지연 추정기 모듈은 지수 가중 이동 평균 계산(exponential weighted moving average calculation)을 이용하여 지연을 추정한다.

유리하게는, 지연 추정기 모듈은 지수 가중 이동 분산 계산을 이용하여 지연 분산을 추정한다.

바람직하게는, 지연 보상기 모듈은 미리 결정된 시간 기간에 걸쳐 점차적으로 프로세스 변수를 수정한다.

편리하게는, 시스템은 서버상에서 실행되는 서비스로서 구현되는 2차 제어 모듈을 더 포함하고, 2차 제어 모듈은 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 하드웨어 컴포넌트들과 통신하도록 동작 가능하고, 여기서 각각의 제어 모듈은, 제어 액션들을 하드웨어 컴포넌트들에게 보내지 않는 대기 모드, 및 제어 액션들을 하드웨어 컴포넌트들에게 보내는 관여 모드(engaged mode)에서 동작하도록 구성되고, 여기서 각각의 제어 모듈은 다른 제어 모듈의 동작 모드를 검사하기 위해 통신하도록 동작 가능하고, 여기서 하나의 제어 모듈은 다른 제어 모듈이 관여 모드에서 동작중이지 않으면 관여 모드로 스위칭하도록 동작 가능하다.

유리하게는, 시스템의 초기화 시에, 1차 제어 모듈은 관여 모드에서 동작하고, 2차 제어 모듈은 대기 모드에서 동작한다.

바람직하게는, 시스템은 I/O(input/output) 인터페이스를 포함하고, 각각의 제어 모듈은 I/O 인터페이스와 통신하기 위해 접속된다.

편리하게는, I/O 인터페이스는, 각각의 제어 모듈이 마지막으로 관여되었고 하드웨어 컴포넌트들 중 적어도 하나에 제어 데이터를 통신했던 때로부터의 시간을 나타내는 시간 값을 기록하도록 동작 가능한 시간 기록 모듈을 포함한다.

유리하게는, 각각의 제어 모듈은 다른 제어 모듈의 시간 기록 모듈에 의해 기록되는 시간 값을 판정하기 위해 미리 결정된 샘플링 주기 동안 I/O 인터페이스를 폴링하도록 동작 가능하다.

바람직하게는, 1차 제어 모듈에게 제1 ID 번호가 할당되고, 2차 제어 모듈에게 제1 ID 번호보다 큰 제2 ID 번호가 할당된다.

편리하게는, 최저 ID 번호를 갖는 제어 모듈은 관여 모드에서 동작하도록 구성된다.

유리하게는, 시스템은 서버상에서 실행되는 서비스로서 구현되는 적어도 하나의 부가적 제어 모듈을 더 포함하고, 각각의 부가적 제어 모듈은 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 하드웨어 컴포넌트들과 통신하도록 동작 가능하고, 여기서 각각의 부가적 제어 모듈은, 제어 액션들을 하드웨어 컴포넌트들에게 보내지 않는 대기 모드 및 제어 액션들을 하드웨어 컴포넌트들에게 보내는 관여 모드에서 동작하도록 구성되고, 여기서 각각의 부가적 제어 모듈은 다른 제어 모듈들의 동작 모드를 판정하기 위해 I/O 인터페이스와 통신하도록 동작 가능하다.

바람직하게는, 적어도 하나의 제어 모듈은 다른 제어 모듈들 중 적어도 하나와 상이한 서버상에서 실행되는 서비스로서 구현된다.

편리하게는, 서버들은 서로 상이한 지리적 위치들에 있다.

유리하게는, 각각의 제어 모듈은 적분기를 포함하고, 각각의 제어 모듈은 그 적분기의 값을 다른 제어 모듈들에 통신하도록 동작 가능하며, 여기서 대기 모드에서 동작하는 각각의 제어 모듈은, 대기 모드에서 동작하는 각각의 제어 모듈이 관여 모드로 순조롭게 스위칭할 준비되도록, 그 적분기 값이 관여 모드에서 동작하는 제어 모듈의 적분기 값에 상응하도록 설정하도록 구성된다.

바람직하게는, 각각의 제어 모듈은 PID(proportional-integral-derivative) 제어기이다.

편리하게는, 대기 모드에서 동작하는 각각의 제어 모듈은 그 세트 포인트를 관여 모드에서 동작하는 제어 모듈의 세트 포인트와 동일한 값으로 설정하도록 동작 가능하다.

유리하게는, 1차 제어 모듈은 서버상에서 실행 중인 가상 머신에서 실행하는 서비스로서 구현된다.

바람직하게는, 각각의 다른 제어 모듈은 서버상에서 실행 중인 가상 머신에서 실행하는 서비스로서 구현된다.

편리하게는, 각각의 다른 제어 모듈은 서버상에서 실행 중인 각각의 별개의 가상 머신에서 실행하는 서비스로서 구현된다.

유리하게는, 각각의 다른 제어 모듈은 하나 이상의 별개의 서버들 상에서 실행 중인 별개의 가상 머신에서 실행하는 서비스로서 구현된다.

바람직하게는, 각각의 서버는 다른 서버들과 상이한 지리적 위치에 배치된다.

본 발명의 또 다른 양태에 따르면, 제1 하드웨어 컴포넌트 및 제2 하드웨어 컴포넌트를 제어하는 방법이 제공되는데, 방법은 하드웨어 컴포넌트들로부터 원격에 있는 서버상의 서비스로서 1차 제어 모듈을 실행하는 단계 - 하드웨어 컴포넌트들은 서버와 통신 상태에 있음 - , 및 하드웨어 컴포넌트들과 1차 제어 모듈 간의 데이터 통신에 의해 1차 제어 모듈을 이용하여 하드웨어 컴포넌트들 중 적어도 하나를 제어하는 단계를 포함한다.

바람직하게는, 하드웨어 컴포넌트들 중 하나는 센서이다.

바람직하게는, 1차 제어 모듈은 제어 시스템에서 직접 제어 계층의 부분을 형성한다.

편리하게는, 1차 제어 모듈은 서버상에서 실행 중인 알고리즘을 서비스로서 포함한다.

유리하게는, 하드웨어 컴포넌트들은 TCP의 위에서 실행되는 필드 레벨 프로토콜을 사용하여 서버와 통신한다.

유리하게는, 서버는 클라우드의 부분을 형성하는 서버이다.

편리하게는, 방법은 서버와 통신 상태에 있는 사용자 인터페이스를 제공하는 단계; 및 1차 제어 모듈을 모니터 및 제어하도록 서버와 상호 작용하기 위해 사용자 인터페이스를 사용하는 단계를 더 포함한다.

유리하게는, 사용자 인터페이스는 PaaS 또는 SaaS로서 구현된다.

바람직하게는, 하드웨어 컴포넌트들은 프로세스 변수를 출력하고, 방법은 피드백 루프를 통해 프로세스 변수를 1차 제어 모듈의 입력에 통신하는 단계를 포함하며, 여기서 방법은 1차 제어 모듈과 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 프로세스 변수를 수정하는 단계를 더 포함한다.

편리하게는, 방법은 프로세스 변수를 기준값과 비교하고 비교 값을 1차 제어 모듈의 입력에 출력하는 단계, 및 지연 보상 값에 의해 프로세스 변수 또는 에러 값을 수정하는 단계를 더 포함한다.

유리하게는, 방법은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나 사이의 통신에 있어서의 왕복 시간 지연에 부합하는 지연 보상 값을 선택하는 단계를 포함한다.

바람직하게는, 방법은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나의 사이의 통신에 있어서의 왕복 시간 지연과 동등하게 되도록 지연 보상 값을 선택하는 단계를 포함한다.

편리하게는, 방법은 프로세스 변수를 수정하기 위해 스미스 예측기를 이용하는 단계를 포함한다.

유리하게는, 방법은 1차 제어 모듈과 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 프로세스 변수 대신에 프로세스 에러를 수정하도록 스미스 예측기를 이용하는 단계를 포함한다.

바람직하게는, 방법은 1차 제어 모듈과 하드웨어 컴포넌트들 중 적어도 하나 간의 왕복 통신(roundtrip communication)에 있어서의 시간 지연을 추정하는 단계를 더 포함한다.

편리하게는, 방법은 지수 가중 이동 평균 계산을 이용하여 지연을 추정하는 단계를 포함한다.

유리하게는, 방법은 지수 가중 이동 분산 계산을 이용하여 지연 분산을 추정하는 단계를 포함한다.

바람직하게는, 방법은 미리 결정된 시간 기간에 걸쳐 점차적으로 프로세스 변수를 수정하는 단계를 포함한다.

편리하게는, 방법은 서버상의 서비스로서 2차 제어 모듈을 실행하는 단계를 더 포함하고, 하드웨어 컴포넌트들은 서버와 통신 상태에 있고, 여기서 각각의 제어 모듈은, 제어 액션들을 하드웨어 컴포넌트들에게 보내지 않는 대기 모드 및 제어 액션들을 하드웨어 컴포넌트들에게 보내는 관여 모드에서 동작하도록 구성되고, 여기서 방법은 다른 제어 모듈의 동작 모드를 검사하기 위해 각각의 제어 모듈을 활성화하는 단계를 포함하고, 여기서 방법은 다른 제어 모듈이 관여 모드에서 동작중이지 않으면 하나의 제어 모듈을 관여 모드로 스위칭하는 단계를 포함한다.

유리하게는, 초기에 방법은 1차 제어 모듈을 관여 모드에서 동작시키고, 2차 제어 모듈은 대기 모드에서 동작시킨다.

바람직하게는, 각각의 제어 모듈은 I/O 인터페이스와 통신한다.

편리하게는, I/O 인터페이스는, 각각의 제어 모듈이 마지막으로 관여되었고, 제어 데이터를 하드웨어 컴포넌트들 중 적어도 하나에 통신한 이후의 시간을 나타내는 시간 값을 기록하도록 동작 가능한 시간 기록 모듈을 포함한다.

유리하게는, 각각의 제어 모듈은 다른 제어 모듈의 시간 기록 모듈에 의해 기록되는 시간 값을 판정하기 위해 미리 결정된 샘플링 주기 동안 I/O 인터페이스를 폴링한다.

바람직하게는, 방법은 1차 제어 모듈에게 제1 ID 번호를 할당하고 2차 제어 모듈에게 제1 ID 번호보다 큰 제2 ID 번호를 할당하는 단계를 포함한다.

편리하게는, 방법은 최저 ID 번호를 갖는 제어 모듈을 관여 모드에서 동작시키는 단계를 포함한다.

유리하게는, 방법은 서버상의 서비스로서 적어도 하나의 부가적 제어 모듈을 실행하는 단계를 더 포함하며, 각각의 부가적 제어 모듈은 하드웨어 컴포넌트들과 통신 상태에 있고, 여기서 각각의 부가적 제어 모듈은, 제어 액션들을 하드웨어 컴포넌트들에게 보내지 않는 대기 모드 및 제어 액션들을 하드웨어 컴포넌트들에게 보내는 관여 모드에서 동작하도록 구성되며, 여기서 방법은 다른 제어 모듈들의 동작 모드를 판정하기 위해 I/O 인터페이스와 통신하도록 각각의 부가적 제어 모듈을 작동시키는 단계를 포함한다.

편리하게는, 서버들은 서로 상이한 지리적 위치들에 있다.

유리하게는, 각각의 제어 모듈은 적분기를 포함하고, 방법은 다른 제어 모듈들에게 각각의 제어 모듈의 적분기의 값을 통신하는 단계를 포함하며, 여기서 방법은, 대기 모드에서 동작하는 각각의 제어 모듈이 관여 모드로 순조롭게 스위칭할 준비가 되도록, 대기 모드에서 동작하는 각각의 제어 모듈의 적분기가 관여 모드에서 동작하는 제어 모듈의 적분기 값에 상응하도록 설정하는 단계를 포함한다.

바람직하게는, 각각의 제어 모듈은 PID 제어기이다.

편리하게는, 방법은 대기 모드에서 동작하는 각각의 제어 모듈의 세트 포인트를 관여 모드에서 동작하는 제어 모듈의 세트 포인트와 동일한 값으로 설정하는 단계를 포함한다.

본 발명을 보다 용이하게 이해할 수 있도록 하기 위해, 그리고 이것의 추가 특징부들을 파악할 수 있도록 하기 위해, 본 발명의 실시예들이 첨부 도면들을 참조하여 예시 방식으로 하기와 같이 기술될 것이다:
도 1은 종래의 산업 자동화 시스템을 도시하는 개략도이고,
도 2는 본 발명의 실시예의 클라우드 기반 제어 시스템의 요소들을 도시하는 개략도이고,
도 3은 제어기들을 가상 머신들에 할당하기 위한 알고리즘의 의사 코드를 도시하고,
도 4의 (a) 내지 (e)는 본 발명의 실시예에서 인터넷 지연을 경감시키는 피드백 제어 루프들을 도시하고,
도 5는 본 발명의 실시예의 클라우드 기반 제어 시스템의 개략도이고,
도 6은 세 개의 별개의 클라우드 제공자가 제공되는 시스템들 상에서 서비스들로서 실행 중인 복수의 클라우드 기반 제어기들을 도시하는 개략도이고,
도 7은 본 발명의 실시예의 RCC(reliable cloud control) 알고리즘의 의사 코드를 도시하고,
도 8은 본 발명의 실시예의 순조로운 핸드오버 알고리즘의 의사 코드를 도시하고,
도 9는 본 발명의 실시예의 테스트 동안의 두 개의 클라우드 제어기의 위치를 도시하는 개략도이고,
도 10은 본 발명의 실시예들을 테스트하는 데 있어서 그에 대한 에뮬레이션이 사용되는 태양열 발전소 제어 시스템의 개략도이고,
도 11의 (a) 내지 (c)는 본 발명의 실시예의 테스트 동안의 태양열 집열기 각도의 플롯들을 도시하고,
도 12의 (a) 내지 (c)는 본 발명의 실시예의 테스트 동안의 태양열 발전소들의 제어의 결과들을 그린 그래프들이고,
도 13의 (a) 내지 (c)는 지연들이 도입될 때 본 발명의 실시예의 제어 시스템을 테스트한 결과들을 도시하는 그래프들이고,
도 14는 본 발명의 실시예의 지연 보상기를 이용한 성능 메트릭들을 요약하는 표이고, 및
도 15의 (a) 및 (b)는 순조로운 핸드오버를 갖는 RCC 알고리즘의 성능 및 순조로운 핸드오버를 갖지 않는 RCC 알고리즘의 성능을 도시하는 그래프들이다.

본 발명의 실시예는 클라우드 기반 자동화 접근법을 제안하기 위해 넓은 의미에서의 자동화를 사용한다. 본 발명의 실시예의 실현성(feasibility)을 입증하기 위해 산업 자동화의 예가 이하에 상세하게 설명된다. 자동화 시스템의 아키텍처 및 기능들이 정의된다. 그리고 나서, 본 발명의 실시예의 구현 및 평가에 사용되는 연속적이고, 규제적인 산업 프로세스들이 정의된다. 자동화의 의미는 자동 제어(automatic control)의 정의를 넘어서고 있다. 자동화는 직접적인 자동 제어 외에 여러 기능들을 제공하는 전체 아키텍처를 지칭한다.

자동화는, 산업 자동화, 빌딩 자동화, 고속도로 자동화, 및 가정 자동화를 포함하는 여러 애플리케이션 영역들을 갖는다. 아키텍처의 가장 낮은 계층에서, 센서들이 배치되어 제어될 필요가 있는 수량들(프로세스 변수라고 지칭됨)을 측정한다. 액추에이터들이 사용되어 프로세스 변수를 그들의 원하는 값들로 만든다. 프로세스 변수들의 예들은 빌딩 온도, 높은 제한 속도(high traffic speed), 및 산업용 보일러 압력을 포함한다. 한 레벨 위로 이동하면, 직접 제어기가 프로세스 변수에 대한 센서 측정값을 입력으로서 취하여, 필요한 액션을 컴퓨팅하고, 그의 액션을 액추에이터들에 출력한다. 직접 제어 외에, 사용자들은, 사용자가 프로세스 변수들을 편리하게 지켜볼 수 있는 모니터링, 직접 제어기들을 구성하는 감독 제어(supervisory control), 및 상이한 변수들을 데이터베이스 내에 로깅하기 위한 이력화(historization)와 같은 더 높은 레벨의 제어 관련 기능들을 필요로 한다. 복잡한 자동화 애플리케이션들에 대해 더 높은 레벨의 최적화 및 기업 레벨 관리가 요구된다.

산업 자동화는 가장 복잡한 아키텍처 중 하나이다. 도 1은 간략화된, 종래의 산업 자동화 시스템 아키텍처를 예시한다. 시스템은 여러 계층으로 위계적으로 분할되어 있다. 첫 번째로, 필드 디바이스들은 공장 프로세스 변수를 모니터 및 제어하기 위해 공장 내에 장착된 센서들 및 액추에이터들이다. 많은 I/O 카운트를 갖는 중간 규모 및 대규모 공장에 대해, 필드 레벨 네트워크가 사용되어 센서들 및 액추에이터들의 레벨에서의 더 나은 데이터 통신과 배선 관리(wiring management)를 제공한다. 데이터는 필드 디바이스와 제어실 내에 위치된 제어기들 사이에서 왔다갔다 한다. 두 번째로, 제어기들은, 직접 연속 또는 이산 제어, 안전 및 비상 정지(emergency shutdown)와 같은 필요한 제어 계산들 모두를 수행하는 특수 목적 소프트웨어 블록들을 실행하는 마이크로프로세서들이다. 단일의 제어기는 보통 프로세서 속도 및 샘플링 레이트 및 제어 루프의 복잡성에 따라 여러 개의 제어 루프를 처리할 수 있다.

세 번째로, 제어기들 외에 HMI(human-machine interface) 및 SCADA(supervisory control and data acquisition)이 있다. HMI/SCADA 스테이션들에 부가하여, 이력 장치(historian), 경보 관리자 및 다수의 다른 것들과 같은 다른 애플리케이션들이 전용 워크스테이션들 상에서 실행된다. 또한, 전략들을 제어하기 위해 필요한 임의의 변경들이 엔지니어링 워크스테이션들 상에서 구현된 다음 그로부터 배치된다. 모든 그러한 컴퓨터들은 제어 네트워크를 통해 제어기들에 접속된다.

네 번째로, 더 높은 레벨의 공장 최적화는 진보된 계산들을 수행하여 에너지 소비, 생산율, 또는 생산 품질과 같은 특정 목표들을 최적화하기 위한 최적의 공장 작동 파라미터들에 대한 의사 결정 보조(decision support)를 제공한다. 공장 레벨 최적화 워크스테이션들 및 서버들은 공장 네트워크로 지칭되는 전용 네트워크를 통해 HMI/SCADA 레벨에 접속된다. 최종적으로, 기업 레벨 관리는, 자산 관리 및 회계(asset management and accounting)와 같은 여러 기능들을 수행한다. 공장 최적화 목표들은 기업 레벨에서 수행된 분석에 기초하여 결정된다.

산업 프로세스는 원자재 및 에너지를 입력으로서 취하여 제품 또는 제품들의 세트를 생성한다. 원자재의 유형 및 재료의 흐름을 포함하는 여러 요인들에 기초하여, 산업 프로세스는 연속, 일괄 및 이산의 3개의 주요 클래스로 분류될 수 있다. 산업 공장들은 여러 산업 프로세스들로 구성된다. 공장들은 그의 프로세스들 중 지배적인 유형에 기초하여 분류된다. 예를 들어, 주로 연속적인 프로세스로 구성되는 공장은 연속 공장으로 분류된다. 일반적으로 말해서, 3개의 클래스 사이에 명백한 경계들이 존재하지 않지만, 분류화는 각각의 프로세스의 요건 및 그들을 제어하는 방법을 이해하는데 도움을 준다.

정유 공장들, 전기 발전소들, 및 원자로는 모두 연속 프로세스들의 예들이다. 그들은 모두 공통적인 여러 특성을 갖는다. 첫 번째로, 원자재가 석유, 물, 및 천연 가스와 같이 보통 유체 유형이다. 두 번째로, 재료의 흐름이 속도에 있어서 서로 다를 수 있으나, 연속적 요구를 충족하기 위해 항상 연속적이다. 세 번째로, 연속 프로세스는 통상적으로 매우 긴 또는 결정되지 않은 시간 동안 실행한다. 네 번째로, 프로세스 정지(process shutdown)는 발생 원가 및 재료의 손실로 인해 매우 바람직하지 않다. 프로세스가 정상 상태에 도달하여 유용한 제품을 생산하기까지 매우 긴 과도 시간, 예를 들어, 수 시간 또는 수일이 걸릴 수 있다. 이러한 과도 시간 동안에, 모든 재료들 및 에너지가 소비된다.

음식 산업은 일괄 프로세스가 심하게 이용되고 있는 예인 반면에 자동차 산업은 이산 프로세스들이 발생하는 예이다. 양쪽 경우들에서의 재료 흐름은 일반적으로 불연속적이다. 또한, 양쪽 유형들은 일반적으로 조립 지향적(assembly-oriented)이다. 그러나, 일반적으로 말해서, 일괄 프로세스들의 제품들은 그들의 원래 재료로 다시 분해되는 것이 불가능하지만, 이산 프로세스들의 제품들은 원래의 컴포넌트들로 분해될 수 있다. 일괄 프로세스들에 사용된 재료들은 유체 및 건 재료(dry material)의 혼합인 반면에 이산 프로세스들은 통상적으로 고체 부분들을 처리한다. 연속 프로세스들과는 달리, 일괄 및 이산 프로세스들 양쪽에는 끝이 있다. 일괄 프로세스들에서, 이것은 타임아웃 또는 종료 조건에 따라 발생하는데, 예를 들어, 빵은 한 시간 동안 또는 옅은 갈색 표면에 도달할 때까지 구워진다. 이산 프로세스에서, 프로세스는 제품이 완성되는 경우, 예를 들어, 자동차가 완전히 조립된 경우에 종료한다.

연속적인 산업 프로세스들은 종종 고위험(high-risk) 및 고부담(high-impact) 프로세스들인 것으로 간주된다. 그들은 매우 긴 시간 기간 동안 연속적인 모니터 및 제어를 요구한다. 예를 들어, 전기 발전소를 고려하자. 열악한 제어로 인한 열악한 성능은 금전, 재료, 및 에너지의 측면에서 큰 손실을 야기한다. 또한, 그러한 프로세스와 연관된 안전성 위험은 심각할 수 있고, 단일 사고에도 다수의 생명 손실을 쉽게 야기할 수 있다.

본 발명의 하나의 실시예에서, 2개의 컴포넌트: (ⅰ) 클라우드 제어기들 및 (ⅱ) 제어 I/O(input/output) 인터페이스를 갖는 클라우드 서비스로서 피드백 제어가 구현된다. 제어기들은 PID(Proportional Integral Derivative) 제어기와 같은, 표준 제어기들의 수정된 버전들을 구현하는 소프트웨어 모듈들이다. 인터넷 지연, 패킷 손실, 및 고장들을 처리하고, 제어 이론적 성능 개런티가 달성되는 것을 보장하기 위해 수정이 행해진다. 하나의 실시예에서, 제어기들은 VM(virtual machines)들 상에 배치되고, 다수의 제어기는 동일한 VM 상에서 실행될 수 있다. 제어 I/O 인터페이스는 제어된 시스템 측에 위치된다. 제어 I/O 인터페이스는 제어 액션들을 수신하고 현재 프로세스 상태를 전송함으로써 클라우드 제어기들과 통신한다. 그리고 나서, 현재 상태가 다양한 센서들에 의해 업데이트되는 동안, 제어 액션들이 제어된 시스템의 액추에이터들로 중계된다.

네트워크화된 제어 시스템은 분산 제어 시스템의 한 버전으로서 간주될 수 있고, 여기서 프로세스 및 제어 데이터를 수송하기 위해 전용 필드 레벨 네트워크에 부가하여 또는 그 대신에 범용 통신 네트워크들(인트라넷 및 인터넷)이 사용된다. 통신 네트워크가 인터넷이면, 제어 시스템은 인터넷 기반 제어 시스템으로서 지칭된다. 인터넷 기반 제어 시스템들은 네트워크화된 제어 시스템들의 특수한 경우로 간주된다. 통상적인 분산 제어 시스템들은 전용 네트워크를 통해 결정론적 지연(deterministic delay)을 갖는 신뢰할만한 통신을 제공하는 한편, 네트워크화된 제어 시스템들은 지연 불확정성 및 덜 신뢰할만한 통신을 겪는다.

네트워크 지연들을 극복하기 위해 지연 보상기들이 제공될 수 있다. 대부분의 경우에, 포워드 및 피드백 경로들에서의 지연을 보상하기 위해 2개의 보상기들이 요구된다. 예를 들어, 인터넷 기반 제어 시스템의 피드포워드 및 피드백 방향들에서의 인터넷 지연을 보상하기 위해 2개의 예측 보상기들이 제공될 수 있다. 보상기들은, 인터넷을 통한 원격 제어기로부터 제어되는 시뮬레이션 및 실제 액체 레벨 규제 프로세스 양쪽에서의 랜덤 지연의 효과를 성공적으로 경감하기 위한 것으로 보여진다. 마찬가지로, 지연 보상은 액추에이터 노드에서의 버퍼 및 예측 제어기 노드에서의 상태 추정기를 통해 제공될 수 있다. 제어기는 여러 샘플링 주기들 동안 제어 액션들을 전송한다.

이와 같은 2개의 컴포넌트 보상 방법이 지연 효과를 경감하고 안정적인 제어 시스템을 제공한다. 그러나, 상업적 시스템에 그러한 접근법들을 채택하면, 여러 이유로 인하여 문제가 있다. 첫 번째로, 그러한 접근법들은 기존의 상업적 제어기들에 의해 지원되지 않는다. 두 번째로, 2개의 컴포넌트 보상기들을 구현하는 것은 추가의 하드웨어 및/또는 소프트웨어를 요구한다. 그러한 지원이 제어기-측 컴포넌트에 대해 비용 없이 또는 최소 비용으로 제공될 수 있더라도, 이것은 통상적으로 처리 능력(processing power)이 결여되는 프로세스-측 컴포넌트에 대한 경우는 아니다. 세 번째로, 클라우드 기반 제어기들의 경우, 컴퓨팅 기능들은 클라우드로 이동되어야 한다 - 이러한 컴포넌트들의 설계와 상충하는 요건들임 - . 본 발명의 실시예에서, 전체 왕복(round-trip) 지연을 보상하기 위해 단일 컴포넌트 보상기가 클라우드 내에서 호스팅된다. 보상기는, 그의 잠재력을 최대화하는, 현재 상용 제품(commercial off-the-shelf)인 제어기들에서 이용 가능한 피처들을 사용하여 구현될 수 있다.

1.1 일체형 클라우드 자동화 시스템

본 발명의 하나의 실시예에서, 자동화 시스템의 모든 컴퓨팅 기능들은 서비스로서 완전한 자동화를 제공하기 위해 클라우드로 이동된다. 센서들, 액추에이터들, 및 안전/비상 차단 제어 기능들과 같이 클라우드로 이동될 수 없는 특정 하드웨어 컴포넌트들이 있다. 도 2는 자동화 아키텍처의 일례를 예시한다. 이하의 설명은 이러한 아키텍처가 모든 레벨에서 모든 자동화 기능들을 달성하는 방법을 설명하고, 이러한 아키텍처와 도 1에 도시된 기존의 자동화 시스템 간의 주요 차이를 강조한다.

먼저, 필드(가장 낮은) 레벨에서 시작하면, 센서들 및 액추에이터들은 Modbus/TCP 및 Profibus/TCP와 같은, TCP 위에서 실행하는 필드 레벨 프로토콜들을 이용하여 클라우드에 접속된다.

하나의 실시예에서, 하드웨어 컴포넌트들의 전부 또는 적어도 하나가 클라우드에 직접 접속된다. 다른 실시예에서, 하드웨어 컴포넌트들의 전부 또는 적어도 하나가 근거리 네트워크를 통해 클라우드에 접속된다.

추가의 실시예에서, 하드웨어 컴포넌트들의 전부 또는 적어도 하나가 통신 서버를 통해 클라우드에 접속된다. 하나의 실시예에서, 통신 서버는 하드웨어 컴포넌트들의 근방에 또는 그의 위치에 위치 설정되고, 바람직하게는 하드웨어 컴포넌트들과 동일한 빌딩 내에 있다.

보안 및 메시지 레벨 스케줄링과 같은 진보된 기능들이 요구되는 경우에, 게이트웨이 서버는 이러한 목적을 위해 전용된다. 또한, 추가의 신뢰성을 위해, 게이트웨이 서버들을 복제하여 1차 서버 고장의 경우에 2차 서버가 상태 기반(stateful) 방식으로 승계할 수 있다.

두 번째로, 직접 제어 계층의 경우, 제어 알고리즘은 클라우드 서비스로서 실행된다. 기존의 자동화 시스템(도 1)에서, 제어기들은 센서들을 폴링(poll)하고 LAN을 통해 명령들을 액추에이터들에 전송한다. 반대로, 본 발명의 실시예에서, 인터넷을 통해 통신이 발생한다. 또한, 기존의 시스템에서, 제어 알고리즘은 제어실 내의 캐비넷으로 둘러싸인 실제 하드웨어 상에서 실행한다. 그러나, 본 발명의 실시예에서, 가상화가 더 많은 유연성 및 비용/시간의 절감을 제공하기 때문에, 제어기들은 VM(virtual machines)들 상에서 실행된다. 제어 알고리즘을 클라우드 내에서 실행하는 것은 인터넷을 통한 통신을 요구하며, 이것은 2개의 새로운 과제를 도입한다: VM 충돌 또는 링크 고장으로 인한 인터넷 지연 및 서비스 고장. 이러한 과제들을 대처하기 위한 새로운 알고리즘이 이하의 섹션 2.2 및 2.3에 설명된다.

세 번째로, 감독 제어, 인간-머신 인터페이스, 및 다른 제어실 애플리케이션들의 경우, 하나의 실시예에서, 이러한 애플리케이션들은 Paas 및 Saas(Platform and Software as a Service) 모델들을 통해 제공된다. 따라서, 엔지니어들 및 조작원들은 씬 클라이언트들을 통해 제어실 애플리케이션에 대한 액세스를 제공받는다. 기존의 자동화 시스템(도 1)에서, 제어실은 서버들, 워크스테이션들, 네트워크 스위치들, 및 케이블들로 채워진 복잡한 환경이다. 그러나, 본 발명의 실시예에서, 제어실은, 모든 복잡한 하드웨어가 클라우드로 이동된, 훨씬 간단한 하드웨어 상에서 실행하는 다수의 씬 클라이언트로 구성된 훨씬 깨끗한 환경이다. 결과적으로, 제어실 하드웨어 및 소프트웨어 배치는 훨씬 용이하게 되고 비용이 덜 들게 된다. 인프라스트럭처/애플리케이션 배치, 유지보수 및 업그레이드에 대한 요구 작업들(demanding tasks)은 엔지니어들 및 조작원들에게 더 이상 부담스럽지 않다. 결과로서, 그들은 자동화 기능들에 집중할 수 있다. 최종적으로, 필드 게이트웨이 서버와 유사한 방식으로, 제어실 중복 게이트웨이 서버(control room redundant gateway server)는, 보안 및 메시지 스케줄링과 같은, 진보된 기능들을 신뢰성있게 수행하도록 제안된다.

네 번째로, 공장 레벨 최적화 및 기업 레벨 관리의 경우, 하나의 실시예는 Saas 모델을 활용한다. 직접 및 감독 제어 계층들과는 달리, 공장 레벨 최적화 및 기업 레벨 관리 애플리케이션들은 그들의 적시성 및 신뢰성 요건들이 하위 레벨들보다 덜 엄격함에 따라 클라우드로 이동하는데 어려움이 덜하다. 예를 들어, 기업 사무실은 몇 분 또는 심지어 몇 시간 동안의 인터넷 서비스 단절을 잘 용인할 수 있다. 반면, 클라우드 기반 산업 제어기들에 대한 몇 초 길이의 인터넷 고장은 물리적 프로세스가 여러 스캔 기간에 제어되지 않은 채 방치되게 하고, 이것은 높은 안전 위험으로 이어질 수 있다.

클라우드 내측의 데이터 센터의 하이 레벨 조직화가 도 2에 도시되며, 여기서 다수의 서버가 가상 머신들을 실행하여 모든 레벨의 자동화를 처리한다. 각각의 자동화 계층에 속하는 애플리케이션들은 동일한 클라우드 서버(들) 상에서 실행하도록 그룹핑된다. 이것은 엄격한 요건은 아니지만, 이것이 보다 나은 데이터 센터 조직화를 가능하게 하므로 권장된다. 예를 들어, 직접 제어 레벨에 대한 적시성 요건들은, 해당 제어기들이 실시간 운영 체제 위에서 실행할 필요가 있다고 할 정도로 매우 엄격하다고 가정하자. 이 경우에, 모든 제어기들을 함께 실시간 운영 체제를 갖는 동일한 서버 또는 서버들의 그룹상에 있게 하는 것이 더 낫다. 애플리케이션 유형들을 혼합하면, 어렵고 및/또는 열악한 데이터 센터 관리를 야기할 수 있다. 서버들 사이의 통신은 고속 스위칭 기술을 이용하여 처리되고, 이는 도 1에 도시된 기존의 시스템들에 의해 사용된 4개의 네트워크를 대신한다. 본 발명의 실시예에서, 통신 인프라스트럭처를 배치, 배선, 유지 및 업그레이드하는데 수반되는 시간, 노력, 및 비용이 절감된다.

지능적 결정 지원을 통해 사용자가 자원을 선택, 할당, 및 관리하도록 서비스 인터페이스가 제공된다. 인터페이스는 도 2에 도시되지 않는다.

본 발명의 실시예는 자동화 시스템에 의해 요구되는 컴퓨팅 및 통신 인프라스트럭처의 일부 또는 바람직하게는 전체를 클라우드로 이동시킨다. 이것은 사용자가 그들의 자동화 시스템을 배치, 유지, 및 업그레이드하기 용이하고 비용이 덜 들게 한다. 또한, 본 발명의 실시예는 모든 가상 머신들이 상이한 제공자들에게 그룹-이전될(group-migrated) 수 있기 때문에 상이한 클라우드 자동화로의 스위칭을 지원한다.

본 발명의 실시예는, VM들에 대한 제어기들의 할당을 결정하는 이하의 단계들을 포함하는 방법을 포함한다:

1) VM 상에서 애플리케이션을 실행하여 각각의 애플리케이션에 대한 CPU 활용 u_i 및 대역폭 프로파일 b_i를 결정하고 소비된 대역폭 및 CPU 활용을 측정한다.

2) VM V_k에 의해 제공될 수 있는 최대 대역폭 B_k 및 CPU 활용 U_k를 결정한다.

3) 도 3에 도시된 할당 알고리즘에 기초하여 제어기 할당을 결정한다. 할당 알고리즘의 실행 후에, S_k는 VM V_k에 할당된 제어기들을 포함할 것이다.

도 3에 도시된 할당 알고리즘은 다음과 같이 요약될 수 있다: 각각의 애플리케이션에 대하여, 모든 이용가능한 VM들을 스캔하고, 스케줄링가능성(schedulability) 테스트(예를 들어, 레이트 모노토닉(rate monotonic))에 기초하여 CPU 활용을 수용할 수 있고, 애플리케이션에 의해 요구되는 최대 대역폭을 수용할 수 있는 제1 이용가능한 VM에 애플리케이션을 지정한다. 애플리케이션이 VM에 지정되는 경우, VM의 로딩(CPU 및 대역폭)이 업데이트된다.

도 3에 도시된 할당 알고리즘의 메인 루틴이 초기에 실행되어 VM 자원들을 제어기들에 할당한다. 새로운 제어기들이 실행시간에 론칭되어야 한다면, allocate() 루틴이 새로운 제어기 및 할당 S_k에 대해 호출된다.

1.2 인터넷 지연 경감

본 발명의 실시예는 제어기들을 클라우드로 이동시킴으로써 도입된 인터넷 지연들을 처리하는 방법 및 시스템을 제공한다. 종래의 피드백 제어 루프가 도 4의 (a)에 도시된다. 제어된 프로세스는 프로세스 변수라고 지칭되는 입력 및 출력을 갖는다. 프로세스 변수는 기준값 또는 세트 포인트라고도 지칭되는 원하는 값과 비교되도록 피드백된다. 세트 포인트와 프로세스 변수 간의 차이는 에러라고 지칭된다. 제어기는 에러를 입력으로서 취하고, 에러를 보정하기 위해 필요한 제어기 액션을 컴퓨팅한다.

이제, 도 4의 (b)에 도시된 바와 같이 제어기가 클라우드로 이동하였고, 인터넷이 프로세스와 제어기 사이에 있어, 양쪽 방향들에서의 루프에 영향을 준다. 첫 번째로, 제어기 액션은 피드포워드 지연이라 지칭되는 시간 지연 후에 프로세스에 도달한다. 두 번째로, 프로세스 변수는 피드백 지연이라 지칭되는 시간 지연 후에 클라우드 기반 제어기에 도달한다. 루프는 도 4의 (c)에 도시된 바와 같이 모델링될 수 있고, 여기서 P(z)는 프로세스 전달 함수이고, C(z)는 제어기 전달 함수이고, z^-k 및 z^-l은 각각 피드포워드 및 피드백 경로들 상의 지연들을 표기한다.

본 발명의 실시예는 도 4의 (d)에 도시된 바와 같이 세트 포인트의 진입시에 인위적인 지연 블록을 도입한다. 그러한 지연을 도입하는 것의 중요성이 이 서브섹션의 마지막에서 논의된다. 도입된 지연의 양은 피드백 경로의 지연의 양, 즉, z^-l과 같다. 간단한 블록도 대수(block diagram algebra)를 이용하면, 루프는 도 4의 (e)에 도시된 바와 같이 간략화될 수 있다. 이제, 클라우드 기반 제어 문제는 데드 타임(dead-time) 또는 전송 래그(transport lag)를 갖는 프로세스들을 제어하는 것과 같이 제어 이론에서 공지된 것으로 감소된다.

데드 타임을 갖는 프로세스는 내재적 지연을 갖는 프로세스이므로, 입력의 적용과 출력 상에서의 그의 효과 사이에는 시간 지연이 있다. 그러한 내재적 지연은 보통 재료가 액추에이터와 센서 사이에서 프로세스 내의 경로를 따라 순회하는(예를 들어, 컨베이어 벨트 또는 긴 파이프를 통해) 경우에 직면한다. 예를 들어, 섬유, 물, 및 필러(filler), 사이징(sizing), 염료(dye) 및 수지(resin)과 같은 첨가제들이 프로세스의 시작시에 모두 혼합되는 페이퍼 머신(paper machine)을 고려한다. 그리고 나서, 길게 생산된 페이퍼 시트(paper sheet)는, 그것이 비워지고, 건조되어 프로세스의 원단(far end)에서 측정될 준비가 될 때까지 긴 경로를 통해 기계적으로 풀링된다. 프로세스의 시작에서 준비된 재료 혼합을 제어하기 위해 센서 측정이 사용된다. 혼합의 적용 및 측정 사이의 긴 시간이 이 프로세스에 대한 데드 타임이다.

데드 타임을 갖는 프로세스를 보다 효과적으로 제어하기 위해, 제어기는 보통 지연 보상기와 결합된다. 여러 개의 지연 보상기들이 이러한 목적을 위해 제안되었다. 하나의 실시예는, 스미스 예측기(Smith Predictor)를 사용하는데, 이것이 가장 상용 제품 제어기들, 예를 들어, Siemens PCS 7 및 Invensys Foxboro I/A 시리즈임에 따라, 가장 널리 사용되는 보상기들 중 하나이기 때문이다. 스미스 예측기는 제어기를 설계하면서 지연 컴포넌트에 대한 정확한 지식을 요구하지 않는 것이 마찬가지로 중요하다. 먼저, 제어기는 어떤 지연에도 직면하지 않는 것처럼 설계된다. 그리고 나서, 지연이 측정되어 스미스 예측기를 조정한다. 이것은, 인터넷 지연이 동적으로 변경되고 지연들이 사전에 알려질 수 없기 때문에 클라우드 기반 제어기들을 설계하는 경우에 유용하다.

표준 스미스 예측기를 갖는 제어기는 다음과 같이 도출된다. 순수 시간 지연 z^-j에 선행하는 또는 그에 후속하는 비-지연 컴포넌트 P(z)로 구성되는 프로세스를 가정한다. 먼저, 지연이 없는 공장을 고려하고, 제어기 C(z)를 설계하면, 클로즈드 루프 전달 함수는

과 같이 된다.

목적은 공장 P(z)z^-j에 대한 제어기

를 찾는 것이므로, 클로즈드 루프 성능은

이고, 이는

에 대해 이하의 수학식을 풀어내는 것을 수반한다:

따라서, 새로운 제어기는 다음과 같이 주어진다:

제안된 클라우드 제어기가 도 5에서 도시된다. 이 도면은 2개의 메인 컴포넌트를 도시한다: (ⅰ) 지연 보상기를 갖는 제어기 및 (ⅱ)인터넷 지연 추정기. 지연 보상기를 갖는 제어기가, 수학식 3에 의해 설명된 제어기의 블록도인 점선 박스에 도시되지만, 결합된 피드포워드 및 피드백 지연들 z^k ^+l, 즉, 왕복 지연을 갖는다. 이것은 지연을 갖지 않는 프로세스 P(z)에 대해 설계된 원래의 제어기인 C(z)를 사용한다. 이것은 또한

로 표기되는 프로세스의 근사치를 필요로 한다. 실제로, 간단한 1차 또는 2차 근사가 충분하다. 제2 컴포넌트가 도 5의 검은색 박스에 도시되고, 이것은 프로세스와, 제어기가 상주하는 클라우드 사이의 왕복 지연을 추정한다. 왕복 지연이 지연 블록 z^k ^+l에서 사용된다. 본 발명의 실시예의 지연 추정기는 지수 가중 이동 평균(exponential weighted moving average)(EWMA)을 이용하여 인터넷 지연을

로서 추정하고, 여기서 D_i는 추정된 평균 지연이고, d_i는 이산 시간 순간(discrete time instant) i에서의 측정된 지연이다. 마찬가지로, 본 발명의 실시예는 지수 가중 이동 분산(EWMV)을 이용하여 지연 분산을

으로서 추정하고, 여기서 V_i는 이산 시간 순간 i에서의 추정된 분산이다. 지연 블록에서의 지연 값은

로 조정될 수 있고, 여기서 T_s 및 h는 평균보다 큰 지연 값들을 수용하는 양의 파라미터이다. 따라서, 추정기는 짧은 지연 스파이크들에 과잉반응하지 않으면서 지연의 변경들에 적응한다.

도 4의 (d)에 도시된 지연 블록을 다시 참조하면, 그러한 지연을 도입하는 것이 시스템의 동작에 대해 무의미하다. 첫 번째로, 대다수의 연속 제어 시스템들의 경우, 세트 포인트들은, 전체 시스템 수명에 대한 것이 아니라면, 과도하게 긴 기간동안 일정하게 유지된다. 그러한 상수 함수의 지연된 버전은 그 자신이 동일한 상수 함수이다. 두 번째로, 세트 포인트가 변경될 필요가 있는 경우에, 세트 포인트 변경이 종종 인간 조작원에 의해 수동으로 수행된다. 수십/수백 밀리초의 지연을 부가하는 것은 조작원 응답(노브 또는 소프트웨어 슬라이더에 도달하고 값을 업데이트하는데 수초)에 대해 무의미하다. 세트 포인트 변경이 감독 제어에 의해 자동적으로 행해지는 경우에 대해서도, 세트 포인트 값들은, 인터넷 왕복 지연보다 훨씬 긴 기간들 동안 보통 일정하게 유지된다. 세 번째로, 프로세스들이 적어도 수초의 시간 상수를 갖는 분산 제어 시스템 애플리케이션들의 경우, 그러한 세트 포인트 지연을 도입하는 것은 어떤 실제적인 성능 이슈도 도입하지 않을 것이다. 최종적으로, 완전히 다른 맥락에서, 세트 포인트 조작은 지연 경감 이외의 다양한 상황에 있는 것이다. 예를 들어, 세트 포인트 램핑(ramping)이 순조롭게 수행되고, 따라서, 급작스런 포인트 변경들의 바람직하지 않은 효과를 경감시킨다. 세트 포인트 램핑은, 세트 포인트가 램프 방식으로 이전 값으로부터 새로운 값으로 변경되는 과도 기간을 도입한다. 그러한 세트 포인트 램핑은 특정 시간 지연 후에 새로운 값을 유효하게 한다.

요약하면, 단일의 인위적인 지연 블록을 추가하면 어려운 클라우드 제어 문제를 데드 타임을 갖는 프로세스를 제어하는 문제로 변환한다. 후자는 스미스 예측기들을 사용함으로써 해결되었고 실제 수십 년 동안 사용되었다. 이것은 원래의 제어기의 설계를 변경하지 않고 또는 제어되고 있는 프로세스를 변경하지 않고 제어기들이 클라우드로 이동되는 것을 가능하게 한다.

2. 고장 처리

이 섹션은 제어기 고장 하에서의 정상 동작을 보증하는 분산 고장 허용성 알고리즘(distributed fault tolerance algorithm)을 설명하고, 시스템의 이론적인 성능이 분석된다. 이 섹션은, 대부분의 실생활 시나리오의 경우, 본 발명의 일 실시예의 알고리즘을 이용하는 클라우드 피드백 제어가 제어된 프로세스 동작에 대해서는 사실상 영향을 미치지 않는다는 것을 또한 보여준다.

대부분의 실제 시스템에서, 제어기 고장은 이중 중복성(double redundancy)에 의해 또는 미션-중대(mission-critical) 프로세스들에 대해서는 최대 삼중 중복성에 의해 처리된다. 고장 시에, 중복 제어기들은, 제어된 프로세스가 고장을 인식하지 못하게 하는 것을 목표로, 상태 기반 방식으로 승계한다. 통상적으로, 중복 제어기들은 가깝게 위치하며, 엄격하게 동기화된다. 따라서, 그들은 직접적인 링크를 통해 통상 수십 밀리 초 정도인 업데이트 기간을 갖는 제어 루프 상태를 용이하게 공유한다. 중복 클라우드 제어기들로부터 유사한 신뢰성을 제공하는 것은 상당히 어려운데, 그 이유는 제어기들이, 도 6에 제안된 바와 같은 상이한 인터넷 제공자들(멀티호밍(multi-homing))을 통해, 상이한 머신들 상에서, 바람직하게는 상이한 데이터 센터들에서 또는 심지어 상이한 클라우드 제공자들에서 통상적으로 실행될 것이기 때문이다. 상이한 머신들을 이용하는 것은 머신 고장을 허용하는 한편, 상이한 데이터 센터들(또는 클라우드 제공자들)에 걸쳐 복제하는 것 및 상이한 인터넷 제공자들을 이용하는 것은 인터넷 링크 고장과 같은 상황들에 대해 보다 큰 강건성을 부가한다. 부가적으로, 미세화된 클록 동기화 및 짧은 시간 척도에 대해 상태 일관성을 유지하는 것은 최선형(best-effort) 인터넷을 통해 통신하는 지리적으로 떨어져 있는 머신들에 대해서는 고비용이 소요되며 복잡하다.

제안된 피드백 제어 클라우드 서비스에서 신뢰성을 달성하기 위해서, 본 발명의 하나의 실시예는 모든 중복 제어기에 의해 비동기로 실행되는 분산 고장 허용성 알고리즘을 포함한다. 이 알고리즘은 RCC(Reliable Cloud Control)로서 공지되어 있다. RCC는 이중 또는 더 높은 중복성을 지원하며, 다음의 보증들을 제공한다:

● G1: 1차 제어기가 고장인 경우, 2차 제어기가 자동으로 핫 스와핑된다(hot-swapped). 이러한 보증은 더 높은 중복성에 대해 일반화가능하다. 예를 들어, 삼중 중복성의 경우에, 1차 및 2차 제어기가 고장이면, 3차 제어기가 핫 스와핑된다.

● G2: 고장인 1차 제어기가 복구되는 경우, 그것이 승계하여, 2차 제어기가 작동하지 않게 한다. 이러한 보증은, 비용 절감을 위해 2차 VM 및/또는 링크가 1차보다 더 낮은 품질을 갖도록 선택될 때에 바람직하다. 이러한 보증은 더 높은 중복성에 대해 또한 일반화가능하다.

● G3: 제어기들의 핸드오버는 바람직하지 않은 과도 응답 아티팩트들을 야기시키지 않으면서 순조롭게 수행된다.

RCC가 이러한 보증들을 제공하기 위해서, 시스템 상태는 투플 (a, u₁, u₂, u₃, ...)로서 정의되는데, 여기서 a는 액추에이터에 의해 실행된 최종 제어기 액션이고, u_i는 중복 제어기 C_i에 의해 수행된 최종 액션 이후로 경과한 시간이다. 모든 제어기에 보이기 위해서, RCC는 도 6에 도시된 바와 같은 제어 I/O 인터페이스 모듈의 메모리에 상태 투플을 저장한다. 상태 투플은 I/O 인터페이스가 첫 번째로 턴 온될 때에 초기화된다. 최종 액션 a는 프로세스 설계에 따라 임의로 초기화될 수 있다. 최종 액션 이후의 시간 u_i는 제어기 C_i가 결코 작동하지 않았음을 나타내기 위해 ∞로 초기화된다.

임의의 주어진 시간에, RCC는 단일의 제어기가 프로세스의 제어에 관여되게 하는 한편, 다른 제어기들이 대기(standby)(또는 백업)로 되게 한다. 대기 제어기는 여전히 프로세스 출력을 판독하고, 그 자신의 다음 액션을 준비하고 있지만, 보류하고 있다. RCC는, 각각의 샘플링 주기에서, 각각의 제어기 상에서 3가지 메인 스텝을 실행한다: 폴링(Polling), 컴퓨팅(Computing) 및 조건부 액팅(Conditional Acting).

폴링: 각각의 제어기는 센서 측정치와 함께 상태 투플에 대해 I/O 인터페이스를 폴링한다.

컴퓨팅: 상태 및 측정치에 기초하여, 각각의 중복 제어기는 다음의 것을 컴퓨팅한다:

(ⅰ) 제어기의 모드: 관여 또는 대기, 및

(ⅱ) 코어 제어 알고리즘을 실행하는 것에 의한 다음 고유 제어 액션.

조건부 액팅: 컴퓨팅 스텝에서 컴퓨팅된 제어기의 모드에 기초하여, 각각의 제어기는 그것의 액션을 프로세스에 송신할지 또는 그것을 보류할지를 결정한다. 단 하나의 제어기만이 액션을 프로세스에 송신하고 프로세스-유지 상태 투플을 업데이트하도록 제어기들의 액션들을 조정하기 위해서 조건이 이용된다. 다른 모든 제어기는 그들의 액션을 보류할 것이다.

하나의 실시예에서, RCC는 어떠한 클록 동기화도 요구하지 않는다. RCC는 그것의 샘플링 주기와 동등한 상대적인 데드라인을 갖는 주기적인 소프트 실시간 태스크이다. 결과적으로, 코어 제어 알고리즘은 모든 샘플링 주기에서 실행되고, 다음 주기의 시작 이전의 임의의 시간에 완료하도록 요구된다. 동일한 샘플링 주기 내에서 제어 액션을 지연시키는 것은 실행되는 제어 알고리즘을 방해하지 않는데, 그 이유는 프로세스가 여전히 샘플링 주기마다 하나의 액션을 수신할 것이기 때문이다. 이러한 2가지 이유로, 제어기들을 호스팅하는 VM들의 클록들을 동기화할 필요 없이, RCC는 모든 VM 상에서 비동기로 구동될 수 있고, 백업 제어기(들)는 1차 제어기가 시작된 이후의 임의의 시간에 시작될 수 있다.

2.1 상세 동작

도 7은 모든 제어기의 상부에서 실행되는 RCC의 의사코드를 도시한다. 맨 처음 사이클에서, RCC는 ID i를 초기화하고, 한번에 단 하나의 제어기만이 관여됨을 보증하기 위해 제어기 C_i에 대해 관여 임계치 D_i를 초기화한다. ID는 1차에 대해서는 1로 설정되고, 2차에 대해서는 2로 설정되거나 한다. 또한, 임의의 제어기 쌍(C_i, C_j)(여기서, i > j)에 대해, 관여 임계치들은 D_i > D_j ≥ T_s를 만족해야 하는데, 여기서 T_s는 샘플링 주기이다. 다음에, 모든 샘플링 주기에 대해 메인 스텝들이 실행된다. 폴링 스텝은 I/O 인터페이스로부터 다음의 변수들을 페치한다:

(ⅰ)

: 현재의 센서 측정치.

(ⅱ)

: 상태 변수 a, 즉 액추에이터에 의해 실행된 최종 액션의 표현.

(ⅲ)

:

가 상태 변수 u_i, 즉 C_i가 마지막에 관여된 이후로 경과된 시간을 나타내도록 하는 시간 카운터 어레이.

폴링 스텝이 예를 들어 링크 고장으로 인해 타임아웃되는 경우, 제어기는 그것의

플래그를

로 리셋한 이후에 현재의 샘플링 주기를 스킵한다. 의사코드에서의 이 라인은 아래의 섹션 2.2에서 제시되는 바와 같이 보증 G3에 관련된다.

다음에, 컴퓨팅 스텝이 제어기 모드를 결정한다. 주어진 제어기 C_i에 대해, 활동 상태에 있는 더 작은 ID를 갖는 다른 제어기 C_j가 존재하는 경우, C_i는 대기 모드에서 구동하기로 결정할 것이다. 한편, 모든 C_j에 대해(여기서, j < i), 최종 액션의 시기 u_j가 D_i보다 오래된 경우, C_i는 관여 모드에서 구동하기로 결정할 것인데, 그 이유는 모든 제어기 C_j가 고장이라고 그것이 가정하기 때문이다. 따라서, RCC는 더 낮은 ID를 갖는 제어기들에 대해

를 스캐닝하는 for 루프를 이용하여 플래그

를 평가한다. 다음에, RCC는 제어 알고리즘

을 실행하는데, 이는 통상적으로 센서 측정치

만을 요구한다. 그럼에도 불구하고, 일부 제어 알고리즘들에 대해, 보증 G3은 아래의 섹션 2.2에서 논의되는 바와 같이 더 많은 파라미터들을 전달하는 것을 지시한다.

마지막으로, 조건부 액팅 스텝은

플래그가

인 경우에는 컴퓨팅된 액션을 프로세스로 송신한다. 그것은 제로를 송신하여, 최종 액션 이후의 시간을 나타내는 카운터를 리셋한다. 그렇지 않으면,

플래그가

인 경우에는, 이 스텝은 어떠한 액션도 수행하지 않는다.

일반성의 손실 없이, 이하 RCC 하에서의 3개의 제어기 사이의 상호작용을 예시하기 위해 삼중 중복성 경우에 대해 포커싱한다. 1차 제어기의

플래그는 항상

인데, 그 이유는 그것이 최저 ID를 갖기 때문이다. 2차 제어기가 시간 카운터

을 폴링함에 따라, 그것은 1차 제어기가 활동 상태에 있는지를 계속해서 검사한다. 1차 제어기가 고장인 경우, 2차 제어기는

이 2차 제어기의 관여 임계치를 초과할 때 고장을 검출할 것이다. 이 경우, 2차 제어기에 대한

는 for 루프 전체에 걸쳐

에 있을 것이다. 따라서, 2차 제어기는 관여 모드에서 구동되고, 따라서 I/O 인터페이스에서의 그것의

엔트리를 리셋하여, 그것이 막 작동하였음을 나타낼 것이다. 3차 제어기가 1차 제어기의 고장을 또한 검출할 것이지만, 그것의 관여 임계치는 2차 제어기의 것보다 높다.

의 값이 3차 제어기의 관계 임계치와 교차하기 전에, 2차 제어기는 이미 작동하였을 것이다. 따라서, 3차 제어기가 다음의 샘플링 주기에서 상태를 폴링할 때, 시간 카운터

는 0 ≤ δ ≤ T_s가 되도록 3차 제어기의 관여 임계치보다 작은 δ로 증분되었을 것이고, 이는 3차 제어기에 대한

플래그가

로 되게 한다.

3차 제어기는 1차 및 2차 제어기 양쪽 모두가 이용가능하지 않게 되는 경우에 그리고 이러한 경우에만 관여될 것이다. 이것은 보증 G1을 처리한다. 1차 제어기가 고장으로부터 복구되는 경우, 그것은 프로세스에 대한 제어를 얻을 것인데, 그 이유는 그것이 항상 관여 모드에서 동작하여, 2차 제어기를 대기 모드로 강제할 것이기 때문이다. 1차 제어기에 대해

을 리셋하면, 2차 제어기는 2차 제어기의 관여 임계치보다 작은 시기를 갖는 최근의 1차 액션을 검출할 것이다. 결과적으로, 2차 제어기에 대한

플래그가

일 것이다. 따라서, 2차 제어기는 대기 모드에서 동작할 것이다. 더 작은 ID의 제어기가 고장으로부터 복구될 때에 임의의 2개의 제어기에 대해 동일한 논의가 적용된다. 이것은 보증 G2를 달성한다.

2.2 순조로운 제어기 핸드오버

제어기들 사이의 스위칭은 프로세스 출력에서의 "범프(bump)"를 초래할 것이며, 이는 보증 G3을 위반할 것이다. 이것은 원래 제어기 액션(original controller action)의 최종 값이 새로운 제어기 액션의 초기 값과 동등하지 않은 경우에 발생한다. 이것에 대한 주요 이유는 중복 제어기들이 반드시 동시에 시작되는 것은 아니라는 것이다. 적분기 컴포넌트를 갖는 대부분의 제어기에 있어서, 제어기들의 출력은 동일하지 않을 것인데, 그 이유는 그들의 적분 구간이 상이한 시작 시간을 갖기 때문이다.

클라우드 제어기들 사이의 순조로운 핸드오버를 달성하기 위해서, 본 발명의 하나의 실시예는 클라우드 제어기들에서 제어 이론으로부터의 무범프 전송(bumpless transfer) 개념을 이용한다. 무범프 전송은 본래 "수동" 제어와 "자동" 제어 간의 스위칭을 지원하도록 설계되고, 산업에서 이용되는 제어기들의 90% 초과를 구성하는 대부분의 상업적인 PID 제어기에 의해 지원된다. PID 제어기들에 대한 무범프 전송은 적분기의 초기 값을 조정하는 것을 통해 달성가능하다. 진보된 "자동" 제어기들에 대해 다른 무범프 전송 방법들이 제안되었다.

도 8은 2개 이상의 PID 제어기 사이에서 스위칭할 때 순조로운 핸드오버를 보증하는 도 7에 도입된 PID

함수의 순조로운 핸드오버 버전을 도시한다. 알고리즘은 임의의 제어기와 PID 제어기 사이에서 스위칭할 때 또한 작동한다.

도 8에 도시된 의사코드는 표준 PID 제어 알고리즘에 대해 순조로운 핸드오버 피처를 부가하도록 요구되는 수정에 대해 포커싱한다. 거의 모든 상업적인 PID 제어기가 이러한 수정을 구현하기 위한 지원을 제공한다. 이러한 지원은 상이한 문제에 대해 제공되지만, 그것은 본 발명의 실시예들의 클라우드 제어기들에 대해 순조로운 핸드오버를 또한 제공할 수 있다.

예를 들어, 2개의 PID 제어기, 즉 관여 모드에 있는 C_i, 및 대기 모드에 있는 C_j가 존재한다고 가정한다. 첫 번째 샘플링 주기를 제외하고는, 관여 제어기 C_i는 수정을 적용하지 않고 PID 제어 알고리즘을 구동하는데, 그 이유는 그것이 if 아래의 문장을 스킵하기 때문이다. 한편, 대기 제어기 C_j는 PID 적분기의 정규 값을, PID 알고리즘의 비례 액션(proportional action)(P) 및 미분 액션(derivative action)(D)을 뺀 이후에 (관여 제어기 C_i에 의해 컴퓨팅되는) 최종 제어 액션과 동등하게 함으로써 오버라이드한다. 이 스텝은 C_j의 적분기의 임의의 편차를 정정하여, 그것이 C_i의 적분기에 매칭되게 한다. 결과적으로, C_j의 출력은 항상 C_i의 출력과 동등할 것이다. 이러한 조건 하에서, C_i가 고장이고, C_j가 승계하는 경우, C_j는 C_i의 최종 액션과 동등한 액션에서 시작한다.

임의의 제어기는 그것의 초기 샘플링 주기에서, 즉 if 조건에 제시된 바와 같이 플래그

이

일 때, 그것의 적분기의 초기 값을 정정하도록 요구된다. 이것은 a < b인 경우에 현재의 관여 제어기 C_b와 복구된 C_a 사이의 순조로운 핸드오버를 가능하게 한다. 이것은 RCC가 도 7의 의사코드에서의 타임아웃 시에

플래그를

로 설정하기 때문이다. 관여 제어기 C_a가 링크 고장을 겪고, 그에 의해 폴링 스텝이 타임아웃되고, 백업 제어기 C_b가 스와핑되는 경우를 고려한다. 링크가 복구되면, C_a는 C_b와의 순조로운 핸드오버를 수행한 이후에 다시 승계하는데, 그 이유는 복구 시에 C_a의

플래그가 도 8에서

일 것이기 때문이다.

알고리즘은 다음의 시나리오들에서 적용될 수 있다:

● 클라우드 제어기들은 고신뢰성을 요구하는 시스템들에서 물리적 제어기들에 대한 백업의 역할을 한다. 이것은 모든 물리적 제어기를 복제하는 것과 비교하여 상당한 비용 절감을 달성할 수 있다.

● 클라우드 제어기들은 그들의 물리적 제어기들이 고장으로 인해 교체되거나 업그레이드되는 동안에 시스템들을 일시적으로 관리하기 위해 사용될 수 있다. 이것은 단기간 동안 필요한 클라우드 서비스들의 주문형 속성에 따른다.

● 클라우드 제어기들은 동일한 회사의 다수의 설비를 서빙하기 위해 사설 클라우드들에 걸쳐 배치될 수 있으며, 이는 모든 설비의 제어 기능이 가상화된 리소스들에 걸쳐 통합되는 것을 허용한다.

이들 시나리오들 각각에서,

플래그는 현재 프로세스를 제어하는 제어기에 대해

로 설정된다. 모든 다른 제어기에 대해서는 동일한 플래그가

로 설정된다. 제어기들을 스위칭하는 것이 필요할 때,

플래그들이 플립핑된다. 최근에 스와핑된 제어기는 최종 적용 액션과 동등한 액션에서 시작할 것이다.

2.3 형식적 인수들(formal Arguments)

이하, 클라우드 기반 제어기, 호스팅 VM, 호스팅 서버, 네트워크 스위치 및 인터넷 링크에 대하여 고장-정지 고장 모델(fail-stop failure model)이 설명된다. 다음의 설명은 보증 G1-G3을 형식적으로 증명한다.

정리 1. 제안된 RCC 알고리즘은, 적어도 하나의 링크를 통해 액세스가능한 적어도 하나의 동작하는 제어기가 존재하는 한, 제어 프로세스의 정상 동작을 보증한다.

증명. Ψ가 건강한 제어기들의 비공 세트(nonempty set)라고 가정한다. 또한, C_s ∈ Ψ은, 최저 ID s 및 가장 작은 관여 임계치 D_s를 갖는 제어기라고 가정한다. 건강하지 않은 모든 제어기 C_i ∈/ Ψ 그리고 i < s에 대해, 최종 액션 시기 카운터 u_i는 계속해서 증가할 것인데, 그 이유는 C_i가 상태 투플을 업데이트할 수 없기 때문이다. 그러므로, u_i 값들은 이들 모두가 C_s의 관여 임계치, 즉 D_s와 교차할 때까지 계속해서 증가할 것이다. 이것이 발생할 때, C_s가 관여될 것인데, 그 이유는

플래그가 컴퓨팅 스텝에서

로서 평가될 것이기 때문이다. 일단 C_s가 관여되면, 그것은 상태 투플에서의 그것의 최종 액션 시기 카운터 u_s를 리셋할 것이다. 활동 상태에 있는 다른 제어기들

은 리셋 이벤트를 관측할 것인데, 그 이유는 카운터 값이 그들의 관여 임계치 D_j보다 작기 때문이다. 결과적으로, 그들의

플래그가

로 설정되어, 그들이 그들의 액션을 보류하게 할 것이다. 그러므로, 적어도 하나의 동작하는 도달가능한 제어기가 존재하는 한, 정확히 프로세스를 관리하는 하나의 제어기를 항상 갖는다.

정리 2. 원래 제어 알고리즘이 고장이 없는 경우에 제로 오버슛(overshoot) 및 제로 정상 상태 에러(steady-state error)를 보증하면, RCC 알고리즘은, 하나의 동작하는 도달가능한 제어기가 존재하는 경우에, 고장 하에서 동일한 오버슛 및 정상 상태 에러 성능을 보증한다.

증명. 이산 시간 인스턴트 n = k에서 관여 제어기 C_i가 고장이라고 가정한다. 백업 제어기 C_j의 첫 번째 액션은 유한 개수의 샘플링 주기

이후에 프로세스에 도달할 것인데, 여기서 RTT_j는 C_j와 프로세스 사이의 왕복 인터넷 지연이고, D_j는 C_j의 관여 임계치이고, T_s는 샘플링 주기이다. 이 시간 동안, 제어 I/O 인터페이스는, m[k-1]인, C_i로부터 수신된 최종 액션을 적용하고 있고, 여기서 m[n]은 제어기 출력 신호이다. 다음의 설명은, m[k-1]이 유한 값이고,

샘플링 주기들에 대해 m[k-1]을 유지하는 것이 오버슛 또는 정상 상태 에러에 영향을 미치지 않는다는 것을 증명한다.

먼저, 다음의 설명은 m[k-1]이 유한함을 증명한다. 고장이 없는 경우에 관여 제어기 C_i가 제로 오버슛 및 정상 상태 에러를 보증한다고 고려하면, 프로세스 변수 y[n]은 그것의 초기 값으로부터 진동 없이 세트 포인트로 수렴한다. 세트 포인트 r[n]이 n > 0에 대하여 상수 함수이기 때문에, 에러 신호 e[n] = r[n] - y[n]은 그것의 유한한 초기 값으로부터 진동 없이 제로로 수렴하는데, 이는 E(z)가 안정된 비진동 폴들(stable, non-oscillatory poles), 즉 z-평면의 단위원 내부의 포지티브 리얼 폴들(positive real poles)을 갖는다는 것을 의미한다. 에러는 제어기에 대한 입력으로서 전달된다. 제어기 전달 함수 C_i(z)는 단위원 내부에 또는 단위원 상에 포지티브 리얼 폴들을 갖는다. 예를 들어, 실제로 가장 흔한 제어기인 PID 제어기는 단위원 외부에 어떠한 폴들도 갖지 않는다(z = 1에서, 즉 단위원 상에 단 하나의 폴이 있음). 따라서, M(z) = E(z)C_i(z)인 제어기 출력은 안정된 폴들을 갖고, z = 1에서 단위원 상에 최대 1개의 폴을 갖는다. 이것은 안정된 전달 함수(E(z) 및 C_i(z)의 다른 모든 안정된 폴)에 대해 단위 스텝 입력(z = 1에서의 폴)을 적용하는 것으로부터 기인하는 신호와 정확히 등가이다.

따라서, 제어기 출력 신호 m[n]은 그것의 유한한 초기 값으로부터 진동 없이 유한한 최종 값으로 수렴한다. 결과적으로, 핸드오버 동안 I/O 인터페이스에서 유지되는 신호 m[k-1]은 m[0] 및 lim_n→∞m[n] 사이에 있으며, 이 둘은 유한하다. 제어 액션의 최종 값이 프로세스가 오버슛하게 하지 않기 때문에, 중간 액션을 유지하는 것도 프로세스가 오버슛하게 하지 않는다. 이것은 대부분의 실제 프로세스가 개방 루프 안정 프로세스들이기 때문이다. 개방 루프 불안정 프로세스의 드문 경우에, 프로세스 측에서 적절한 보상이 가정된다. 백업 제어기 C_j가 제로 오버슛 및 제로 안정 상태 값을 생성하는 제어 알고리즘을 구동한다고 고려하면, 그것이 승계할 때, 그것은 프로세스 변수를 그것의 중간 값으로부터 진동 없이 그것의 원하는 최종 값으로 드라이브한다, 즉 제로 안정 상태 에러 및 제로 오버슛.

정리 3. 일 고장 하에서의 안정 시간(settling time) t_s에서의 최악의 증가는 백업 제어기 C_j의 관여 임계치 D_j 및 인터넷 왕복 지연 RTT_j에 의해 상한이 정해지고,

로 주어지는데, 여기서 T_s는 샘플링 주기이다.

증명. 이 증명은 관련 기술분야의 통상의 기술자에 대해 간단하다. 단순함을 위해, 최종 결과들은 유도 없이 제시된다. 일반성의 손실 없이, 단위 이득 시스템은 그것의 우세 시간 인스턴트(dominant time constant)에 의해 표현되고, 그것의 우세 시간 인스턴트의 10%마다 주기적으로 샘플링되는데, 이는 샘플링 주기의 설계에 있어서의 경험 규칙(rule of thumb)이다. 이러한 시스템의 스텝 응답은

로서 도출될 수 있다. 고장이 없는 경우의 안정 시간 t_s는 프로세스가 최종 값의 5% 내에 있는데 걸리는 시간으로서 정의된다. 고장이 없는 경우에 안정 시간 t_s0은 30 샘플링 주기로서 획득된다. 이산 시간 인스턴트 k > 0에서 고장이 발생할 때 유사한 분석이 이용된다.

고장 하에서, t_sf는 3개의 성분을 갖는다:

(ⅰ) t_s1 - 이 시간 동안, 초기 제어기 C_i는 그것이 고장을 갖기 이전에 프로세스 출력을 0으로부터 중간 값

로 드라이브함 -. 이것은

를 초래한다.

(ⅱ) t_s2: 이것은 C_j가 고장을 검출하고 고장에 반응하는데 걸리는 시간이다. 이 시간 동안, 제어기 출력은 m[k-1]에서 유지될 것이고, 프로세스 출력은 하한으로서의 α일 것이다(1차 래그(first order lag)로 인해, 프로세스는 실제로 β(여기서, 0≤α≤β≤1)로 증진될 것이며, 이는 보다 양호한 시나리오이다). 정리 2의 증명은

을 나타낸다.

(ⅲ) t_s3: 이 시간 동안, C_j는 프로세스 출력을 α로부터 0.95로 드라이브한다. 이것은

를 초래한다.

전술한 논의로부터,

라고 결론지어진다.

실제 프로세스들은 수초 정도의 시간 제약을 가지므로, 수백 밀리초 정도의 샘플링 주기를 갖는다. 결과적으로, 인터넷은 왕복 지연

(여기서, γ < 1)을 통상적으로 도입할 것이다. 지연 임계치를 2 샘플링 주기와 동등하게 설정하면, 안정 시간에서의 최악의 변화는

이다. 안정 시간에서의 1 샘플링 간격의 변화는 1/30 = 3.3% 증가에 대응하는데, 이는 작은 양이다. 고장은 안정 시간에서의 제로 변화를 생성하는 경우, 대부분의 프로세스가 그들의 대부분의 동작 시간 동안 안정 상태로 구동된다는 것은 주목할만하다.

정리 4. RCC 알고리즘은 제어기 복구 시에 프로세스 응답에서의 변화 없음을 보증한다.

증명. 제어기 C_j가 현재 관여된다고 가정한다. C_i(여기서, i < j)는 고장을 가졌고, 지금 복구된다고 가정된다. C_i가 더 작은 ID를 갖기 때문에, 그것이 관여될 것이고, 그것은 제어 I/O 인터페이스에 유지된 상태의 업데이트를 시작할 것이다. C_i가 돌아옴을 C_j가 검출하는데

샘플링 주기들이 걸릴 것이다. 이들 샘플링 주기들 각각 동안, 프로세스는 각각의 제어기로부터 하나씩 2개의 제어 액션을 동시에 수신할 것이다. 도 8에서의 순조로운 핸드오버 알고리즘 때문에, C_i는 C_j의 최종 액션부터 시작할 것이다. 이들 양쪽 모두가 작동하는 기간 전체에 걸쳐, 그들은 동일한 샘플링 주기 내에서 동일한 액션을 송신하고 있을 것이다. 그러므로, 응답은 단 하나의 제어기만이 관여되는 경우와 상이하지 않을 것이다. 이 주기 이후에, C_j가 대기로 스위칭됨에 따라 C_i가 완전히 승계할 것이다.

3. 평가

이 섹션에서는 제안된 클라우드-기반 제어 접근법의 성능이 엄격하게 평가된다. 아래의 설명은 본 발명의 실시예의 클라우드-기반 제어기들이 어떻게 8000 마일보다 멀리 떨어져 있는 산업 공장을 효과적으로 제어할 수 있는지를 보여준다. 아래의 설명은 또한 제어된 산업 공장의 순조롭고 신뢰할 수 있는 기능을 달성하기 위해 고장 시에 본 발명의 실시예가 어떻게 중복 제어기들 사이에서 동적으로 스위칭하고 큰 인터넷 지연을 경감할 수 있는지를 증명한다.

테스트를 목적으로, 본 발명의 실시예는 LabVIEW 소프트웨어로 구현되었는데, 이는 자동화 산업 및 실험실 테스트 양쪽에서 표준이다. PID 제어 방법은 단연 실제로 가장 흔히 사용되기 때문에 상기 접근법은 PID 제어 방법으로 평가되었다. LabVIEW PID 제어기는 아마존 클라우드2에서의 마이크로소프트 윈도우즈 서버 인스턴스들 위에 배치되었다. LabVIEW는 또한 북아메리카의 서해안에 위치한 서버에서의 중형 산업 공장을 에뮬레이트하는데 사용되었다. 공장 프로세스들 및 클라우드 제어기들 사이의 통신을 위해 LabVIEW에 의해 제공된 표준 Modbus/TCP 프로토콜이 사용되었다. 2개의 클라우드 제어기는 공장에서 가장 멀리 있는 (지연의 관점에서) 이용 가능한 아마존 클라우드(Amazon cloud) 위치들 상에 배치되었다: 도 9에 도시된 바와 같이 싱가폴 및 브라질 상파울루.

3.1 실험적 셋업

에뮬레이트된 산업 공장은 도 10에 도시된 태양열 발전소였다. 태양열 발전소의 동작은 4개의 메인 프로세스 사이클: 합성 석유 사이클(synthetic oil cycle), 솔트 사이클(salt cycle), 증기 사이클(steam cycle) 및 응결 사이클(condensation cycle)로 분리된다. 석유 사이클은 태양 에너지를 수집하는 반면, 솔트 사이클은 그것을 저장하여 추후에 펌핑한다. 증기 사이클과 응결 사이클은 증기 터빈을 동작시킬 책임이 있다. 석유 사이클은, 석유를 통과시키는 수평관(horizontal pipes)을 따라 태양의 열을 수집하는 태양열 집열기 미러(solar collector mirrors)에서 시작한다. 석유는 솔트 사이클 및 증기 사이클과 상호 작용하기 위해 2개 분기에서 열을 흡수하고 그것을 통과시킨다.

솔트 사이클은 2개의 모드: 열 저장 및 열 펌핑을 갖는다. 석유에 의해 흡수된 열이 공장을 구동하기 위해 요구량을 초과하면, 솔트는 차가운 탱크에서 뜨거운 탱크로 펌핑되어 과잉 열을 저장한다. 태양 에너지가 요구 레벨 아래로 떨어질 때마다(예컨대, 흐린 날씨), 솔트 흐름 방향은 반전되어 열을 석유로 펌핑한다. 석유는 물을 가열시켜 증기를 생성하기 위해 열 교환기로 펌핑된다. 천연 가스 가열기는, 태양 열과 솔트가 펌핑된 열이 요구 레벨 아래로 떨어지는 경우에, 증발 온도를 유지하는데 사용된다.

가압된 증기는, 전력 그리드에 접속된 전기 발전기를 구동하는 증기 터빈을 통해 공급된다. 마지막 사이클은, 효율적 증기 사이클에 필요한 터빈의 하류 측에서 진공 상태를 만들기 위해 요구된 스팀 응결이다.

태양열 발전소를 제어하기 위해, 도 10에 도시되는 9개의 제어 루프가 식별되었다: (ⅰ) 태양열 집열기 미러를 위한 3개의 각 위치 루프(three angular position loop), (ii) 3개의 흐름 제어 루프(three flow control loops); 석유 사이클을 위한 2개와 증기 사이클을 위한 1개, 및 (iii) 3개의 온도 제어기; 석유 사이클을 위한 1개와 증기 사이클을 위한 1개와 응결 사이클을 위한 1개. 간단함을 위해 (예컨대, 터빈을 위한) 부가적인 제어 루프는 도시되지 않는다.

성능 결과는 3개의 대표적인 제어 루프; 상기 3개 그룹 각각으로부터의 것으로 제시된다. 이러한 루프의 전달 함수들이 도출되었고, 그들의 PID 클라우드 제어기는 지글러-니콜스법(Ziegler-Nichols method)을 이용하여 설계되고, 시행 착오에 의해 미세 조정되었다. 각각의 제어 루프에 대해, 제어된 프로세스의 상태는, 적절한 액션을 컴퓨팅하여 그것을 해당 프로세스의 액추에이터에게 다시 보내는, 대응 제어기에 의해 주기적으로 샘플링 및 획득된다. 샘플링 주기는 통상적으로 프로세스의 지배적 시상수의 10%로 설정된다. 대부분의 연속적인 산업 프로세스는 0.5 내지 2.0 초의 범위 내에 있는 샘플링 주기를 갖는다.

평가시에 고려되는 제어 루프에 대해 지배적 시상수가 컴퓨팅되었고, 샘플링 주기는 적게 잡아도 최대 샘플링 주기가 1초인 시상수의 10%로 설정되었다. 더 작은 샘플링 주기는 더 빠른 응답을 요구함에 따라, 그들은 클라우드-기반 제어 접근법을 압박한다. 공장의 성능은 접근법에 대한 스트레스 테스트를 하기 위해 정상적인 인터넷 지연은 물론 에뮬레이트된 큰 랜덤 지연 하에 조사된다. 성능은 제어기 및/또는 인터넷 링크가 고장일 때 분석된다. 공장이 스텝 입력 또는 외란의 대상이 될 때, 가장 흔한 제어-이론적 성능 메트릭이 고려된다. 이러한 메트릭은: (ⅰ) 최대 오버슛 퍼센트(M_p): 최대 오버슛과 최종 값 사이의 정규화된 차이; (ii) 정상-상태 에러(es_s): 세트 포인트와 스텝 응답의 최종 값 사이의 차이; 및 안정 시간(settling time)(t_s): 최종 값의 5% 내에 머무르도록 응답에 의해 취해진 시간이다.

3.2 인터넷 지연 하의 성능

다음 섹션은 클라우드-기반 제어 접근법의 실현 가능성을 증명한다.

아래의 설명은 클라우드 제어기가 로컬 제어기와 동일한 성능을 산출한다는 것을 보여준다. 도 10에는 2개의 제어 루프: (ⅰ) AC1로 마크된 태양열 집열기 위치 설정 프로세스, 및 (ⅱ) TC1로 마크된 온도 제어 프로세스가 도시되는데, 여기서 솔트가 열을 저장 또는 펌핑하여 석유 온도를 조절한다.

태양열 집열기 위치 설정. 태양열 집열기는 무게가 1,000Kg인 이동 부분들을 갖는다. 구유형 미러(parabolic trough mirror)는 1m의 초점 길이를 갖는다. 집열기는 미러의 초점 축 주위를 회전한다. 기어 비(gear ratio)가 100인 기어박스를 갖는 큰 DC 모터가 집열기를 구동한다. 전달 함수는 θ(s)/V_f(s) = 0.1/(s³+18s²+80s+10)으로서 도출되는데, 여기서, θ(s) 및 V_f(s)는 각각 집열기의 각 위치(collector's angular position)의 라플라스 변환 함수(Laplace transform function), 및 DC 모터의 계자 회로(field circuit)에 인가된 전압이다. 이러한 전달 함수의 지배적 시상수는 7.77s이다. 그러므로, 750ms인 샘플링 주기가 선택되었다. 원하는 집열기 각 위치는 역코사인(cos(g) sin(a))으로서 도출되는데, 여기서, g는 태양의 고도각이고, a는 남쪽으로부터 측정된 방위각이다. 태양 각의 변화는 2012년 7월 1일에 1시간 동안 텍사스 휴스턴에서 에뮬레이트되었다. 원하는 집열기 각도는 오전 10:00와 11:00 사이에 44.3°(degree)에서 57.1°로 램프 방식으로 변한다. 집열기의 초기 위치는 0°였다. 바람 외란 효과(wind disturbance effect)는 오전 10:20과 10:40 사이에 에뮬레이트되었고, 이는 주기의 전반부에 증가하고, 후반부에 감소한다. 적용된 외란은 최고 7°까지의 충격을 갖는다. 외란 전달 함수는 θ(s)/D_f(s) = 75×10-⁵/(s²+7.6s+0.75)에 의해 근사화되며, 여기서 D_f(s)는 풍력 외란(wind force disturbance)의 라플라스 변환이다.

도 11은, 원하는 태양열 집열기 각도(세트 포인트)가 플롯되는 결과를 도시한다. 클라우드 피드백 제어기(클라우드 FB) 및 에뮬레이트된 프로세스와 동일한 기계에서 실행되는 제어기(로컬 FB)에 의해 달성된 각도들 양쪽은 원하는 세트 포인트에서 프로세스의 성능을 유지했다. 도 11의 (a)에서, 오픈 루프 제어기에 의해 달성된 각도는 바람 외란의 심각성을 증명하는 것으로 도시된다. 도 11의 (a)의 결과는 클라우드 제어기가 로컬 제어기와 동일한 것을 수행했다는 것을 명백히 도시한다. 도 11의 (b)는 과도 응답(transient response)을 설명하기 위해 처음 4분 클로즈업(zoon in)하는 반면, 도 11의 (c)는 바람 외란이 발생한 주기의 전반부를 클로즈업한다. 도면 양쪽은 제안된 클라우드 제어기(수천 마일 떨어져 배치됨)의 성능이 로컬 제어기의 성능과 구별이 되지 않다는 것을 확인한다.

석유 온도 조절. 상기 실험은 태양열 집열기 위치 설정 프로세스와 상당히 다른 온도 제어 프로세스 동안 반복되었다. 이러한 온도 제어 프로세스는 솔트가 열을 저장하는지 펌핑하는지 여부 및 석유 온도를 조절하기 위하여 저장될/펌핑될 열의 양을 결정한다. 도 10에서 TT1에 의해 측정된 온도는 전체 석유 사이클의 동작에 의존한다. 그 결과, 2개의 석유 열 교환기의 동작이 에뮬레이트되었다. 태양열 집열기는 부가적인 열 교환기로서 에뮬레이트되었다. 열 교환기는 20s와 30s 사이의 범위인 지배적 시상수를 갖는 전달 함수로 에뮬레이트되었다. 솔트 상호작용의 전달 함수는 O(s)/V_p(s) = 5/(25s+1)(3s+1)에 의해 주어지며, 여기서 O(s) 및 V_p(s)는 각각 출구 석유 온도 및 펌프 모터 드라이브에 인가된 전압의 라플라스 변환 함수이다. 1시간 동안의 일시적인 흐린 날씨 상태의 효과 또한 에뮬레이트되었다. 이러한 외란의 전달 함수는 시상수가 5분인 제1 주문 시스템으로서 근사화된다. 전체 프로세스의 지배적 시상수는 189s로서 컴퓨팅되지만, 시스템을 압박하기 위해 최대 샘플링 주기인 1s가 사용되었다.

도 12의 (a)는, 13:30과 14:30 사이에 일시적인 흐린 날씨 외란이 발생하는, 13:00과 15:00 사이의 2시간 기간의 결과를 도시한다. 도 12의 (a)는, 클라우드 제어기가 로컬 제어기가 한 것과 동일한 방식으로 세트 포인트에서 온도를 유지하는 한편, 온도는 오픈 루프 제어기 하의 세트 포인트로부터 현저하게 벗어난다는 것을 도시한다. 도 12의 (b)는 클라우드 및 로컬 제어기 양쪽이 외란을 잘 처리했음을 도시하기 위해 13:15와 14:00 사이의 기간을 클로즈업한다. 2개의 제어기에 의해 취해진 액션을 더 설명하기 위해, 도 12의 (c)는 흐린 상태에 의해 초래된 외란을 경감하기 위하여, 2개의 제어기가 솔트 흐름 방향을 반전시켜 열 저장에서 열 펌핑으로 스위칭하는 방법을 플롯한다. 도 12의 (c)에서 y-축의 네거티브 값은 열 저장을 나타내는 한편 포지티브 값은 열 펌핑을 나타낸다.

3.3 큰 인위적인 지연들 하의 성능

시스템의 견고성을 테스트하고 지연 보상기(delay compensator)의 효과를 보여주기 위해, 짧은 시상수로 프로세스를 제어할 때 큰 랜덤 지연이 인위적으로 삽입된다. (100, 70, 500) ms의 (평균 μ, 표준 편차 σ, 및 최대치 max)의 대략 값을 갖는 지연 분포를 사용했지만, x-축에 스케일링 인자가 곱해 져서 실질적으로 지연을 증가시킨다. 10, 20 및 40의 스케일링 인자는 확률 분포를 적절하게 스케일링하는데 사용되어, 곡선 아래의 면적이 1로 유지된다. 이러한 스케일링은 각각 (1, 0.7, 5), (2, 1.4, 10) 및 (4, 2.8, 20) 초의 (μ, σ, max) 값을 갖는 과잉 지연을 산출한다. 이러한 큰 지연은 클라우드 제어기와 에뮬레이트된 공장 동작 사이에 도입된다. 그러한 분포 하에, 패킷들은 변동성이 높은 지연의 대상이 되어, 패킷이 고장나게 한다. 이러한 지연은, 네트워크 링크의 고장 또는 복구로 인해 라우터들, 일시적 라우팅 루프 형성, 또는 라우팅 표 변화에서 혼잡이 발생할 때의 상황을 나타낼 수 있다.

도 10에서 FC3에 의해 마크된 물 흐름 프로세스가 평가되었다. 3s의 짧은 시상수가 가정되고, 300ms의 샘플링 주기가 이용된다. 삽입한 지연은 샘플링 주기보다 큰 자릿수이다. 각각의 지연 분포에 대해, 실험은 본 발명의 실시예의 지연 보상기와 함께 그리고 그것 없이 또 다른 것과 함께 수행된다. 우리의 지연 보상기에서의 지연 블록은

로 설정되는데, 여기서, Ts는 샘플링 주기이다. 그러므로, 고려 중인 3 지연 분포의 경우, 지연 블록은 각각 z-10, z-20 및 z-40으로 설정된다. 보상된 성능 및 보상되지 않은 성능은 기준선으로서의 제로-지연 경우와 비교된다. 보상된 경우에 대해, 각각의 실험은 10회 반복되고, 가장 나쁜 성능이 골라진다. 이러한 실험의 결과는 3개의 지연 분포에 대한 도 13에 도시된다. 도 13은, 더 큰 지연이 도입됨에 따라, "보상되지 않은(Uncompensated)" 클라우드 제어 루프는 오버슛하고(도 13의 (a) 및 도 11의 (b)), 결국 불안정하게 된다(도 13c)는 것을 도시한다. 반면에, 본 발명의 실시예의 지연 보상기는 명백한 오버슛이 없는 순조로운 응답을 유지한다.

도 14에 도시된 표 1은 본 발명의 실시예의 지연 보상기를 사용하는("보상되는") 성능 메트릭 및 그것을 사용하지 않는("보상되지 않은") 성능 메트릭을 요약한다.

최대 오버슛 및 정상 상태 에러의 관점에서, 보상된 제어기는 4개의 분포 전체에 걸쳐 동일한 성능을 유지했다. 다시 말하면, 시스템은 그러한 극단적 지연 상태에 시달리지 않았고 마치 지연이 없는 것처럼 수행되었다. 유일한 사소한 예외는, 실질적으로 0으로 간주되는, 0.3%로 나온, 마지막 분포(μ=4s, σ=2.8s, max=20s)의 최대 오버슛이다.

다른 한편으로, 보상되지 않은 제어기의 성능은 삽입된 지연이 상승함에 따라 계속 열화했다. 그래서, 그것은 지연이 없는 상태에서 제로 최대 오버슛 및 제로 정상 상태 에러로부터 이동되어, 마지막 지연 분포에서 불안정하게 되고, 이 때, (관찰할 수 있는) 최대 오버-슛은 170.9%로 크게 증가했고, 정상 상태 에러는 결정되지 않았으며, 따라서, 표 1에서 "undet" 엔트리가 되었다. 안정 시간은 보상된 제어기와 보상되지 않은 제어기 양쪽에 대해 삽입된 지연으로 증가한 한편, 보상된 제어기는 제3 및 제4 지연 분포(μ=2, 4s, σ=1.4, 2.8s, max=10, 20s)에서 상당히 더 잘 수행된다. 마지막 분포의 경우, 보상되지 않은 제어기는 불안정하고 결코 안정되지 않으므로, 표 1에서 "undet" 안정 시간이 되었다.

개요에서, 시스템은 극단적인 상태: 최대 20s의 극도로 큰 지연, 즉, 66 × 300ms인 샘플링 주기하에 세트 포인트(스텝 입력)에서의 갑작스러운 변화시에 테스트되었다. 그러한 극도로 어려운 상태는, 보상되지 않은 제어기 하에 발생한 제어된 프로세스를 불안정하게 한다. 그럼에도, 그러한 극단적인 상태하에서, 시스템은 단지 안정 시간을 증가시킴으로써 제어된 프로세스가 오버슈팅되는 것을 못하게 하거나 최종 값으로부터 벗어나지 못하게 한다. 그러나, 정상 상태에서, 실제-지연 실험에서는 흔히 있는 일이지만 안정 시간은 (제로가 아닌 경우) 미묘한 증가를 겪을 것이다.

3.4 고장 허용 및 순조로운 핸드오버

이 섹션은 클라우드-기반 제어기가 고장의 경우에 어떻게 순조로운 핸드오버를 달성할 수 있는지를 보여준다. 실제-지연 실험은 도 9에 도시된 바와 같이 위치한 2개의 중복 제어기에 의해 반복된다. 고장 시의 RCC 알고리즘의 시간 응답은 고장이 없는 것과 비교된다. 도 10에 도시된 물 흐름 프로세스(FT3, FC3)에 스텝 입력이 도입된다. 5s의 지배적 시상수가 가정되고, 그러므로, 샘플링 주기는 500ms이다. 스텝 입력은 t=0s에서 적용된다. 1차 제어기는 t=18s에서 그의 TCP 접속을 디스에이블함으로써 고장이 되고, 1차 제어기는 t=170s에서 동작으로 다시 복귀한다. 이러한 시간 인스턴트는, 과도 상태 동안 1개의 핸드오버 이벤트가 존재하고 정상 상태 동안 또 다른 것이 존재하도록 선택된다.

물 흐름 프로세스의 정규화된 응답이 도 14의 (a)에 플롯된다. 결과는, RCC 알고리즘이 고장 상태를 성공적으로 경감하고 성능은 고장이 없는 것처럼 나타난다는 것을 보여준다. 동일한 플롯이, RCC를 이용하지 않는 것의 효과를 보여주는데, 이는 응답이 고장으로 인해 지연되고 순조로운 핸드오버 메커니즘의 결여로 오버슛이 나타난다는 것을 보여준다. 2차 제어기의 관여 임계치는 4 샘플링 주기(2 초)로 설정되어, 안정 시간이 고장이 없는 78s로부터 RCC 처리된 고장 상태의 80s까지 2.6%만큼 증가한다.

순조로운 핸드오버 방법의 중요성을 설명하기 위해, RCC의 순조로운 핸드오버 특징이 디스에이블되는 동안 동일한 실험이 수행되고, 그 결과에 대한 플롯은 도 14의 (b)에 플롯된다. 순조로운 핸드오버 능력이 없는 제어기("RCC(S.H. 없음)")는 원하는 세트 포인트에 가까운 응답을 유지했다. 그러나, 그들은 핸드오버 이벤트 동안 2개의 범프를 프로세스 출력에 도입했다. 그러므로, 순조로운 핸드오버 특징은 고장 상태에서 순조로운 응답을 보증하기 위해 중요하다.

4. 결론(CONCLUSIONS)

자동 피드백 제어를 새로운 클라우드 서비스로서 제공하는 것은 산업적, 컴퓨팅 및 통신 시스템을 포함하는 많은 실용적인 시스템을 위한 여러 잠재적 이익을 갖는다. 클라우드 제어기는 비용 절감과 민첩성을 제공하면서, 기존 제어기를 대체하거나 그들을 위한 백업의 역할을 할 수 있다. 그러나, 적시에 신뢰할 수 있는 방식으로 데이터를 전달, 감지/액팅하는 것은 주요 과제이다.

본 발명의 실시예는 피드백 제어를 클라우드 서비스로서 제공하는 방법 및 아키텍처를 제공한다. 본 발명의 실시예들의 방법은: (ⅰ) 원래의 제어기 설계에 영향을 미치지 않거나 제어된 시스템으로부터 별도의 지원을 요구하지 않고 가변 인터넷 지연을 경감하고, (ⅱ) 고장 상태에서 백업 제어기를 자동으로 핫 스와핑하는 비동기 알고리즘을 통해 신뢰성은 추가하고, (ⅲ) 제어기들 사이에 순조로운 핸드오버를 보장한다. 모든 방법은 현재의 산업적 패키지에 의해 지원된다.

실험 결과는, 본 발명의 실시예가 로컬 제어기와 동일한 성능을 전달하기 위해 그들 모두를 경감시킬 때 제어된 시스템이 열악한 상태에 영향을 받지 않았다는 것을 보여준다. 그러므로, 피드백 제어 클라우드 서비스는 클라우드 컴퓨팅 모델에 의해 약속한 바와 같이 더 낮은 비용과 더 높은 민첩성을 위한 동일한 성능을 전달할 수 있다.

본 명세서에서, "포함하다(comprise)"는 "포함하다(include) 또는 구성된다(consist of)"를 의미하고 "포함하는(comprising)"은 "포함하는(including) 또는 구성되는(consisting of)"을 의미한다.

본 발명의 실시예들의 양태들을 구현하기 위해 이용가능한 기술들:

[1] T. Abdelzaher, Y. Diao, J. L. Hellerstein, C. Lu, and X. Zhu. Introduction to Control Theory And Its Application to Computing Systems Performance Modeling and Engineering. In Performance Modeling and Engineering, chapter 7, pages 185-215. Springer US, 2008.

[2] Introduction to Modbus TCP/IP (white paper). http://www.acromag.com/sites/default/files/Acromag_Intro_ModbusTCP_765A.pdf, 2005.

[3] M. Bandyopadhyay. Control Engineering Theory and Practice. Prentice-Hall of India, 2006.

[4] J. Bendtsen, J. Stoustrup, and K. Trangbaek.

Bumpless transfer between advanced controllers with applications to power plant control. In Proc. of IEEE Conference on Decision and Control, volume 3, pages 2059-64, Dec 2003.

[5] S. Bhattacharyya, A. Datta, and L. Keel. Linear Control Theory: Structure, Robustness, And Optimization. CRC Press, 2009.

[6] M. Bjorkqvist, L. Chen, M. Vukolic, and Z. Xi. Minimizing retrieval latency for content cloud. In Proc. of IEEE INFOCOM, 2011.

[7] Y. Chen, Z. Du, and M. Garcia-Acosta. Robot as a service in cloud computing. In Proc. of IEEE International Symposium on Service Oriented System Engineering, 2010.

[8] Z. Chen, L. Liu, and X. Yin. Networked control system with network time-delay compensation. In Proc. of Industry Applications Conference, volume 4, pages 2435-40, 2005.

[9] DS2 :Delay Space Synthesizer. http://www.cs.rice.edu/~bozhang/ds2/.

[10] L. Desborough and R. Miller. Increasing customer value of industrial control performance monitoring-Honeywell's experience. In Preprint of Chemical Process Control, 2002.

[11] V. Gabale, P. Dutta, R. Kokku, and S. Kalyanaraman. InSite: QoE-aware video delivery from cloud data centers. In Proc. of International Symposium on QoS, 2012.

[12] X. Gao and L. Schulman. Feedback control for router congestion resolution. In Proc. of ACM Symposium on Principles of Distributed Computing, 2005.

[13] M. Gopal. Digital Control Engineering. New Age International, 1998.

[14] M. Gopal. Control Systems: Principles and Design. Tata McGraw-Hill, 2006. Reprinted from the 2002 original.

[15] U. Herrmann, B. Kelly, and H. Price. Two-tank molten salt storage for parabolic trough solar power plants. Energy, 29(5-6):883-93, Apr 2004.

[16] S. Kumar, S. Gollakota, and D. Katabi. A cloud-assisted design for autonomous driving. In Proc. of SIGCOMM MCC workshop on Mobile Cloud Computing, 2012.

[17] Why Use LabVIEW? http: //www.ni.com/white-paper/8536/en.

[18] C. Lu, Y. Lu, T. Abdelzaher, J. A. Stankovic, and S. Son. Feedback control architecture and design methodology for service delay guarantees in web servers. IEEE Transactions on Parallel and Distributed Systems, 17(7), Sept 2006.

[19] K. Natori and K. Ohnishi. A design method of communication disturbance observer for time-delay compensation, taking the dynamic property of network disturbance into account. IEEE Transactions on Industrial Electronics, 55(5):2152-68, May 2008.

[20] P. Patras, A. Banchs, and P. Serrano. A control theoretic scheme for efficient video transmission over ieee 802.11e edca wlans. ACM Transactions on Multimedia Computing Communications and Applications, 8(3):29:1-29:23, Aug 2012.

[21] J. Rossiter. Model-Based Predictive Control: A Practical Approach. CRC Press, 2004.

[22] J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy, and V. Sekar. Making middleboxes someone else's problem: network processing as a cloud service. In Proc. of SIGCOMM, 2012.

[23] Smith Predictor for Control of Processes with Dead Times. http://support.automation. siemens.com/WW/view/en/37361207, 2009.

[24] G. Smaragdakis, N. Laoutaris, I. Matta, A. Bestavros, and I. Stavrakakis. A feedback control approach to mitigating mistreatment in distributed caching groups. In Proc. of IFIP-TC6 Conference on Networking Technologies, Services, and Protocols, 2006.

[25] O. Smith. Closer control of loops with dead time. Chemical Engineering Progress, 53(5):217-9, May 1957.

[26] Solar plots. http://www.solarplots.info/.

[27] H. Wade. Basic and Advanced Regulatory Control: System Design and Application. ISA, 2004.

[28] T. Wood, E. Cecchet, K. Ramakrishnan, P. Shenoy, J. van der Merwe, and A. Venkataramani. Disaster recovery as a cloud service: economic benefits & deployment challenges. In Proc. of USENIX Conference on Hot Topics in Cloud Computing, 2010.

[29] X. Xu. From cloud computing to cloud manufacturing. Robotics and Computer-Integrated Manufacturing, 28(1):75-86, Feb 2012.

[30] S. Yang, X. Chen, L. Tan, and L. Yang. Time delay and data loss compensation for internet-based process control systems. Transactions of the Institute of Measurement and Control, 27(2):103-18, June 2012.

[31] Y. Yang, Y. Wang, and S.-H. Yang. A networked control system with stochastically varying transmission delay and uncertain process parameters. In Proc. of IFAC, volume 16, 2005.

Claims

제어 시스템으로서,
제1 하드웨어 컴포넌트,
제2 하드웨어 컴포넌트,
상기 하드웨어 컴포넌트들로부터 원격에 있는 서버 - 필드 레벨 프로토콜을 사용하여 상기 하드웨어 컴포넌트들과 상기 서버 사이에서 데이터가 통신될 수 있도록 상기 하드웨어 컴포넌트들은 상기 서버와 통신 상태에 있음 - , 및
상기 서버상에 실행되는 서비스로서 구현되는 1차 제어 모듈- 상기 1차 제어 모듈은, 상기 제어 시스템에서 직접 제어 계층의 부분을 형성하고, 상기 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 상기 필드 레벨 프로토콜을 사용하여 상기 하드웨어 컴포넌트들과 통신하도록 동작 가능하고, 상기 하드웨어 컴포넌트들은 프로세스 변수를 출력하고, 상기 시스템은 상기 프로세스 변수를 상기 1차 제어 모듈의 입력에 전송하는 피드백 루프를 포함함 -
을 포함하고,
상기 시스템은:
상기 1차 제어 모듈과 상기 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 상기 프로세스 변수를 수정하는 지연 보상기 모듈; 및
상기 프로세스 변수를 수신하는 제1 입력 및 기준값을 수신하는 제2 입력을 포함하는 비교기 유닛
을 더 포함하고,
상기 비교기 유닛은, 상기 프로세스 변수를 상기 기준값과 비교하여 상기 1차 제어 모듈의 입력에 비교 값을 출력하고, 상기 지연 보상기 모듈은 상기 지연 보상 값에 의해 상기 프로세스 변수 또는 에러 값을 수정하며,
상기 지연 보상기 모듈은 상기 1차 제어 모듈과 상기 하드웨어 컴포넌트들 중 적어도 하나의 하드웨어 컴포넌트 사이의 통신에서의 왕복 시간 지연에 상응하도록 상기 지연 보상 값을 선택하는, 제어 시스템.
제1항에 있어서,
상기 1차 제어 모듈은 상기 하드웨어 컴포넌트들 중 적어도 하나를 연속적으로 제어하도록 동작 가능한 직접 연속 제어 모듈이고 직접 디지털 제어 모듈인 제어 시스템.
제1항에 있어서,
상기 하드웨어 컴포넌트들 중 하나는 센서 및 액추에이터 중 적어도 하나인 제어 시스템.
제1항에 있어서,
상기 하드웨어 컴포넌트들 및 서버는 클라우드 네트워크의 부분을 형성하는 제어 시스템.
제1항에 있어서,
상기 시스템은, 상기 1차 제어 모듈을 모니터 및 제어하기 위해 사용자로 하여금 상기 서버와 상호작용하는 것을 가능하게 하도록 상기 서버와 통신 상태에 있는 사용자 인터페이스를 더 포함하고,
상기 사용자 인터페이스는 Paas(Platform as a service) 또는 SaaS(System as a Service)로서 구현되는 제어 시스템.
제1항에 있어서,
상기 하드웨어 컴포넌트들은 프로세스 변수를 출력하고, 상기 시스템은 상기 프로세스 변수를 상기 1차 제어 모듈의 입력에 전송하는 피드백 루프를 포함하며, 상기 시스템은, 상기 1차 제어 모듈과 상기 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 상기 프로세스 변수를 수정하는 지연 보상기 모듈을 더 포함하는 제어 시스템.
제1항에 있어서,
상기 지연 보상기 모듈은 스미스 예측기(Smith Predictor)이고,
상기 스미스 예측기는 상기 1차 제어 모듈과 상기 하드웨어 컴포넌트들 사이의 통신에서의 지연을 보상하기 위해 지연 보상 값에 의해 상기 프로세스 변수 대신에 프로세스 에러를 수정하는 제어 시스템.
제1항에 있어서,
상기 시스템은, 상기 1차 제어 모듈과 상기 하드웨어 컴포넌트들 중 적어도 하나 사이의 통신에서의 왕복 시간 지연을 추정하도록 동작 가능한 지연 추정기 모듈을 더 포함하는 제어 시스템.
제1항에 있어서,
상기 지연 보상기 모듈은 상기 프로세스 변수를 미리 결정된 시간 기간에 걸쳐 점차적으로 수정하는 제어 시스템.
제1항에 있어서,
상기 시스템은, 상기 서버상에서 실행되는 서비스로서 구현되는 2차 제어 모듈을 더 포함하고, 상기 2차 제어 모듈은 상기 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 상기 하드웨어 컴포넌트들과 통신하도록 동작 가능하며, 각각의 제어 모듈은, 상기 하드웨어 컴포넌트들에 제어 액션들을 보내지 않는 대기 모드 및 상기 하드웨어 컴포넌트들에 제어 액션들을 보내는 관여 모드(engaged mode)에서 동작하도록 구성되고, 각각의 제어 모듈은, 다른 제어 모듈의 동작 모드를 검사하기 위해 통신하도록 동작 가능하며, 하나의 제어 모듈은, 다른 제어 모듈이 상기 관여 모드에서 동작중이지 않으면, 상기 관여 모드로 스위칭하도록 동작 가능하고,
상기 시스템의 초기화시, 상기 1차 제어 모듈은 상기 관여 모드에서 동작하고, 상기 2차 제어 모듈은 상기 대기 모드에서 동작하는 제어 시스템.
제10항에 있어서,
상기 시스템은 I/O(Input/Output) 인터페이스를 포함하고, 각각의 제어 모듈은 상기 I/O 인터페이스와 통신하기 위해 접속되고,
상기 I/O 인터페이스는, 각각의 제어 모듈이 마지막으로 관여되었고 상기 하드웨어 컴포넌트들 중 적어도 하나에 제어 데이터를 전송했던 때로부터의 시간을 나타내는 시간 값을 기록하도록 동작 가능한 시간 기록 모듈을 포함하고,
각각의 제어 모듈은 다른 제어 모듈의 상기 시간 기록 모듈에 의해 기록된 시간 값을 판정하기 위해 미리 결정된 샘플링 주기 동안 상기 I/O 인터페이스를 폴링(poll)하도록 동작 가능한 제어 시스템.
제10항에 있어서,
상기 1차 제어 모듈은 제1 ID 번호를 할당받고, 상기 2차 제어 모듈은 상기 제1 ID 번호보다 큰 제2 ID 번호를 할당받고,
최저 ID 번호를 갖는 제어 모듈은 관여 모드에서 동작하도록 구성되는 제어 시스템.
제1항에 있어서,
상기 시스템은
I/O 인터페이스 및
상기 서버상에서 실행되는 서비스로서 구현되는 적어도 하나의 추가 제어 모듈을 더 포함하고,
각각의 제어 모듈은 상기 I/O 인터페이스와 통신하도록 연결되고, 각각의 추가 제어 모듈은 상기 하드웨어 컴포넌트들 중 적어도 하나를 제어하기 위해 상기 하드웨어 컴포넌트들과 통신하도록 동작될 수 있고, 각각의 추가 제어 모듈은, 상기 하드웨어 컴포넌트들에 제어 액션들을 보내지 않는 대기 모드 및 상기 하드웨어 컴포넌트들에 제어 액션들을 보내는 관여 모드에서 동작하도록 구성되고, 각각의 추가 제어 모듈은, 다른 제어 모듈들의 동작 모드를 판정하기 위해 상기 I/O 인터페이스와 통신하도록 동작 가능한 제어 시스템.
제13항에 있어서,
적어도 하나의 제어 모듈은, 다른 제어 모듈들 중 적어도 하나와 상이한 서버상에서 실행되는 서비스로서 구현되고/구현되거나,
상기 서버들은 서로 상이한 지리적 위치들에 있는 제어 시스템.
제14항에 있어서,
각각의 제어 모듈은 적분기를 포함하고, 각각의 제어 모듈은 자신의 적분기의 값을 다른 제어 모듈들에 전송하도록 동작 가능하며, 상기 대기 모드에서 동작하는 각각의 제어 모듈은, 상기 대기 모드에서 동작하는 각각의 제어 모듈이 상기 관여 모드로 순조롭게 스위칭할 준비가 되도록, 자신의 적분기 값을 상기 관여 모드에서 동작하는 제어 모듈의 적분기 값에 상응하도록 설정하도록 구성되는 제어 시스템.
제14항에 있어서,
상기 대기 모드에서 동작하는 각각의 제어 모듈은 자신의 세트 포인트를 상기 관여 모드에서 동작하는 제어 모듈의 세트 포인트와 동일한 값으로 설정하도록 동작 가능한 제어 시스템.
제1항에 있어서,
상기 1차 제어 모듈은 상기 서버상에서 실행 중인 가상 머신에서 실행하는 서비스로서 구현되는 제어 시스템.
제13항에 있어서,
각각의 다른 제어 모듈은 하나 이상의 개별 서버들 상에서 실행 중인 가상 머신에서 실행되는 서비스로서 구현되는 제어 시스템.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제