http://developer.thingworx.com/core-concepts/

Edge

보통 디바이스나 센서와 같은 네트워크에 연결되어 있는 개체를 나타내지만, 연결되어 있는 센서나 디바이스 그 이상의 것을 의미합니다. ThingWorx에서 Edge란 센서, 디바이스 외에도 디바이스 클라우드, 플랫폼, 응용 프로그램, 웹 서비스, 산업 시스템, 사람 등등을 포함합니다. ThingWorx는 Edge에 연결하는 여러 가지 방법을 제공합니다.

Edge Connectivity

Edge를 Platform에 연결하기 위한 세 가지 주요 옵션이 있습니다. 하나는 서버에 http(s) 요청을 하는 dynamic REST API 입니다. Edge MicroServer와 SDK는 진정한 Edge Application이며, 이 두 개는 저마다 각각의 장점과 단점이 있습니다. 추가적으로, Extensions는 써드파티 시스템, 센서, 디바이스 클라우드, 프로토콜 등을 ThingWorx의 Thing으로 노출하는데 활용될 수 있습니다.

Edge Microserver (EMS)

EMS는 Windows 또는 Linux에 설치할 수 있는 사전 구축된 애플리케이션(pre-built application) 입니다. EMS는 REST API AlwaysOn protocol을 사용하여 원격 디바이스와 ThingWorx Platform의 다리 역할을 합니다.

EMS를 사용하면 속성, 이벤트, 서비스를 포함하는 원격 디바이스를 만들 수 있습니다. 또한, ThingWorx Platform과 모든 저장소(원격 디바이스의 로컬 네트워크에서 사용할 수 있는) 간의 파일 전송이 가능하도록 해줍니다. EMS는 AlwaysOn 연결을 통해 포트를 뚫을 수 있는 터널링을 제공합니다. 이를 통해 당신이 VNC를 통한 원격 데스크톱, 또는 SSH를 사용하는 원격 명령 프롬프트와 같은 원격 리소스에 접근할 수 있도록 해주며, 그렇기 때문에 당신은 방화벽 이슈에 대한 걱정 없이 원격 디바이스를 조작할 수 있습니다.

EMS에는 당신이 속성이나, 서비스, 그리고 이벤트를 Lua Script라고 불리는 스크립트 언어로 생성할 수 있는 부가적인 프로세스 매니저인 Lua Script Resource가 함께 제공됩니다.

SDK's

ThingWorx SDK를 사용하면 장치를 ThingWorx Platform에 연결하는 애플리케이션(응용 프로그램)을 만들 수 있습니다. 모든 SDK는 가볍고, 효율적이며 방화벽 친화적인 AlwaysOn 프로토콜을 이용하여 통신합니다. SDK는 ThingWorx Platform의 서비스를 실행할 수 있으며, 속성, 서비스, 이벤트를 가지고 있는 원격 Things를 생성할 수도 있습니다.

게다가, 대부분의 SDK는 ThingWorx Platform 과 디바이스 간에 파일을 전송할 수 있는API를 제공합니다. 대부분의 SDK는 원격 디바이스와 Thingworx Platform간의 터널링을 제공합니다. 이를 통해 VNC나 SSH와 같은 기술들을 사용하여 원격 디바이스에 접근할 수 있습니다.

ThingWorx SDK Platforms는 다음과 같은 것들이 있습니다.

C SDK
Java SDK
.NET SDk
iPhone Operating System (iOS) SDK
Android SDK

REST API

ThingWorx Platform은 웹 서비스를 사용하여 완전히 공개되므로, 모든 속성, 서비스, 서브시스템, function에 RESTful API를 사용하여 액세스 할 수 있습니다. 즉, 원격 디바이스는 일치하는 형식의 HTTP(Hyper Text Transfer Protocol) 리퀘스트를 사용해서 ThingWorx와 통합될 수 있습니다. 이런 응용 프로그램은 Thing의 속성을 변경하고, 서비스를 실행하고, 그 이상의 작업들까지 수행할 수 있습니다.

모든 커뮤니케이션이 HTTPS를 통하기 때문에, 일반적으로 integration(통합)은 방화벽 관련 문제가 발생하지 않습니다. The production ThingWorx Platform은 항상 HTTPS 리퀘스트를 수락하도록 구성되며, 이 접근을 막는 방화벽은 거의 없습니다. 그러나, REST API는 AlwaysOn 기술처럼 원격 디바이스의 지속적인 연결을 유지해주지는 못합니다. 이러한 사실은 여러분이 REST API나 AlwaysOn 기반의 솔루션 중 어떤 걸로 구현할지 결정하는데 영향을 미칠 수 있습니다. Communication은 transactional입니다. 즉, 원격 디바이스가 HTTPS 트래픽을 차단하는 방화벽 뒤에 있다면, 플랫폼은 요청(request)를 원격 디바이스에 보낼 수 없으며, 원격 장치에서 보낸 요청에만 응답할 수 있습니다.

AlwaysOn™ Protocol

AlwaysOn ™ 프로토콜은 플랫폼 확장이 필요 없는 ThingWorx의 native integration 기술입니다. AlwaysOn ™ 프로토콜의 주요 목적은 방화벽 친화적인 방법으로 원격 네트워크에 ThingWorx REST API를 복제하는 것입니다. AlwaysOn ™을 사용하여 전송된 데이터는 ThingWorx Info Table의 이진 표현으로 이루어져 있습니다. 이것은 암호화된 항상 열려있는 원격 애플리케이션으로의 WebSocket 연결을 제공합니다.

해당 애플리케이션에는 원격 속성, 이벤트, 서비스, 파일이 포함될 수 있습니다. 선택적으로, 원격 디바이스는 원격 디바이스나 원격 네트워크로의 원격 엑세스를 제공하기 위한 VNC나 SSH 연결로의 AlwaysOn ™ 액세스를 허용할 수도 있습니다. 이 연결은 방화벽 이슈를 피하기 위해서 WebSocket 연결을 통해 터널링합니다.

ThingWorx 플랫폼에서는, 'RemoteThing' thing template을 사용하고 원격 속성, 서비스, 이벤트에 바인딩하여 AlwaysOn ™ 디바이스에 접근합니다. AlwaysOn ™은 EMS와 SDK(ThingWorx Software Development Kit) 기반의 애플리케이션에 의해 구현됩니다.

Thing

Thing 은 물리적 사물의 디지털 표현입니다. Thing은 디바이스, 센서, 애플리케이션, 서비스, 사람, 또는 그 이상의 것이 될 수 있습니다. 이것은 속성(특성), 서비스(행동), 이벤트, 구독의 네 가지로 구성됩니다.

Data Modeling Principle (데이터 모델링 원리)

ThingWorx는 모델 기반 디자인 접근 방식을 사용하여 재사용가능한 빌딩 블록을 만들어 확장성과 유연성을 보장합니다.

모델(model)은 물리적인 솔루션 환경을 논리적으로 표현한 것입이다. 이것은 모델을 쉽게 감쌀 수 있는 REST API 세트를 통해 이용할 수 있습니다.

모델 구축 프로세스는 객체지향 설계와 유사합니다. 애플리케이션 개발자에게 공개하길 원하는 Thing의 상호 작용, 속성, 서비스, 이벤트를 정의하기 위해서 Things를 분해해야 합니다.

Thing-Centric Semantic Layer

ThingWorx는 전통적인 프로그래밍 방식으로 사용되지 않는 의미론적 레이어를 모델에 제공합니다.

객체 지향적인 Thingworx 모델은 당신이 공통적인 기능들을 고수준 객체로 나누는 것을 허락합니다. 이를 통해 기본 오브젝트의 비지니스 로직과 기능을 캡슐화하고 디지털 Thing의 기본 오브젝트를 상속 받을 수 잇습니다. 이 프로세스는 최종 사용자가 제품, 고객 또는 매출과 같은 공통된 용어를 사용하여 자발적으로 데이터에 액세스하는 데 도움이되는 데이터의 비즈니스 표현 역할을하는 의미 계층을 작성합니다. 모델의 의미는 강력한 형식의 잘 알려진 REST API 집합으로 제공됩니다.

ThingWorx Data Modeling

ThingWorx에서 IoT 솔루션을 구현하는 것은 솔루션의 Thing 중심의 관점에서 모델을 작성하는 것에서부터 시작합니다. ThingWorx 모델은 프로세스, 솔루션, 애플리케이션을 나타내는 Entity들의 집합입니다. Entity 타입에는 Thing Shapes, Thing Templates, Thing을 포함한 많은 것들이 있습니다.

Things는 속성 및 비지니스 로직을 갖춘 물리적 디바이스, 자산, 제품, 시스템, 사람, 또는 프로세스의 표현입니다. Things는 Thing Templates(상속)을 기반으로 하며 하나 또는 그 이상의 Thing Shapes(composition)을 구현할 수 있습니다. Thing은 고유한 속성, 서비스, 이벤트 및 구독을 가질 수 있으며, 다른 속성, 서비스, 이벤트, 구독을 Thing Template 과 Thing Shape에서 상속받을 수 있습니다.

Thing Shapes는 물리적 자산의 집합에서 공유되는 속성, 서비스, 이벤트, 구독으로 표현되는 특성의 집합을 제공합니다. Thing Shape는 모델의 객체 간 관계를 설명하는 콤포지션(구성)에 가장 적합합니다. Thing Shape는 하나 이상의 Thing Templates에서 상속될 수 있는 포함되어 있는 속성과 비지니스 로직의 재사용을 촉진합니다.

Thing Templates는 Thing 인스턴스가 실행될 때 사용하는 속성, 서비스, 이벤트, 구독과 관련된 기본 기능을 제공합니다. 모든 Thing은 Thing Template로부터 생성됩니다. Thing Template 또다른 Thing Template으로 확장될 수 있습니다. 새로운 버전의 제품을 출시할 때, 전체 모델을 재정의할 필요 없이 버전의 추가적인 특성만 간단히 추가하면 됩니다. 이 모델 구성은 자산(Asset)의 여러 수준의 일반화를 제공합니다. Thing Template은 Thing Shapes를 구현하여 하나 이상의 추가적인 특성을 끌어낼 수 있습니다. Thing Template을 변경하면, 변경 사항은 Thing Template을 구현하는 Thing으로 전파됩니다.

Things 는 속성과 비지니스 로직을 가지고 있습니다. 모델을 정의하는 프로세스에는 속성(Properties), 서비스(Services), 이벤트(Events)를 식별하는 작업 또한 포함됩니다.

Properties 는 당신이 필요한 입, 출력 형태의 Thing의 특성을 데이터 아이템으로 표현합니다. Properties는 단순한 스칼라가 될 수도 있고 복잡한 구조(예를 들어 문서나 JSON 객체 같은)일 수도 있습니다. Properties는 견고하고 탐색 가능한 API 구조를 제공하는 강력한 형식의 ThingWorx 시스템의 기초가 됩니다.

Services는 캡슐화된 비지니스 로직이며, 디지털 모델이 애플리케이션에 제공하는 기능입니다. 하나의 서비스는 계산이나 사용자 비지니스 로직을 수행합니다. 서비스는 클라우드에서, 엣지 디바이스에서, 또는 ThingWorx Server에서 실행될 수 있습니다. 서비스의 출력을 엣지나 다른 시스템에 노출시킬 수 있습니다. 당신은 기본으로 제공되는 서비스를 바로 사용하거나 사용자 커스텀 서비스를 작성해서 사용할수도 있습니다. 서비스는 잘 정의된 입력과 출력을 갖고 있습니다.

Events는 Thing이 제공하는 흥미롭거나 중요한 속성 상태입니다. Event는 기본적으로 트리거 서비스인 구독에서 일부 기능을 시작하는 초기자입니다. 이벤트는 반드시 모델에서 이벤트를 구독하는 구독자(subscriber)가 있어야 합니다. 구독자에게 데이키 패킷이 전송될 때 이벤트 구독이 시작됩니다. 아무도 이벤트에 가입하지 않으면(아무도 듣지 않으면), 아무 일도 일어나지 않습니다. ThingWorx의 이벤트 종류에는 표준 이벤트와 데이터 관련 패킷(related data packets)이 있습니다. 가장 일반적인 이벤트 타입은 Thing property와 관련된 데이터의 변경입니다. property를 정의할 때, property에는 많은 구성 요소가 있습니다. 모든 데이터 변경 이벤트는 미리 정의된 동일한 Data Shape으로 데이타 패킷을 보냅니다.