사물, 사물 템플릿 및 사물 형태를 사용하여 자산 모델링
사물은 속성 및 비즈니스 로직이 있는 물리적 장치, 자산, 제품, 시스템, 사람 또는 프로세스의 표현입니다.
하나의 동작을 한 번 정의하고 응용 프로그램 전체에서 재사용할 수 있도록 ThingWorx에서는 사물 템플릿 및 사물 형태를 제공하여 응용 프로그램을 모델링하는 작업을 용이하게 합니다. 사물 템플릿은 속성, 서비스, 이벤트 및 구독과 함께 사물에 기본 기능을 제공합니다. 사물 형태를 사용하면 단일 응용 프로그램의 자산 간에 속성을 재사용할 수 있습니다.
사물은 사물 템플릿의 기능을 상속합니다. 사물 템플릿은 사물 형태를 구현하여 하나 이상의 추가 특성을 파생할 수 있습니다.
최종 사용자는 응용 프로그램의 정보와 데이터 읽기/쓰기를 위해 사물과 상호 작용합니다.
사물, 사물 템플릿 및 사물 형태를 만드는 모범 사례
사물, 사물 템플릿 및 사물 형태를 만들 때 다음 모범 사례를 사용합니다.
• 사물, 사물 템플릿 및 사물 형태에 대한 이름 규약을 정의합니다. 다음 사항을 유념하십시오.
◦ 모든 엔티티에 표준 명칭을 사용하십시오. 예를 들어, 충돌 방지를 위해 엔티티 유형마다 고유한 네임스페이스 접두사를 사용할 수 있습니다.
◦ 엔티티에 의미 있는 이름을 제공하십시오.
◦ 작성하는 모든 엔티티에 대해 적절한 설명을 포함하십시오.
◦ 모호한 이름은 사용하지 마십시오.
◦ 가능하면 긴 엔티티 이름은 사용하지 마십시오.
• 만들고 수정하는 모든 엔티티에 태그를 사용합니다. 복잡한 응용 프로그램의 경우 동일한 응용 프로그램 또는 여러 응용 프로그램의 다양한 모듈을 구별하는 데 도움이 됩니다. 고객의 경우 동일한 ThingWorx 플랫폼 인스턴스에서 서로 다른 응용 프로그램의 엔티티를 구분하는 데 도움이 됩니다. 개발자는 ThingWorx Composer에서 엔티티를 빠르게 필터링하고 테스트를 위해 응용 프로그램의 모듈을 내보낼 수 있습니다. 특히 동일한 응용 프로그램의 서로 다른 모듈 간에 서로 다른 태그를 사용하려는 경우 태그에 대한 이름 규약을 설정하는 것이 좋습니다.
• 모듈의 동일한 엔티티를 프로젝트로 그룹화합니다. 각 모듈에는 고유한 프로젝트가 있습니다.
• 가능한 경우 사물 형태를 사용합니다.
 |
사물 형태를 사용하여 속성 및 서비스를 정의하는 것이 좋습니다. 사물 템플릿에 속성과 서비스를 정의하면 해당 정의를 사물 형태로 이동하기가 어렵습니다.
|
◦ 사물 형태 수준에서 모든 속성, 서비스 및 이벤트를 정의합니다.
◦ 사물 템플릿은 사물 형태를 그룹화하고 상속을 지원하는 데 사용됩니다.
◦ 가능하면 사물 템플릿 및 사물에서 속성 또는 서비스를 구현하지 마십시오.
◦ 사물 형태 및 사물 템플릿에서의 서비스 재정의를 허용합니다.
◦ OOTB 사물 형태 및 사물 템플릿을 편집할 수 없는지 확인합니다.
◦ 지원되는 API를 식별하는 주석을 정의합니다. 이렇게 하면 업그레이드 시 서비스 및 속성이 유지됩니다.
• 사물 형태를 사용하여 특정 기능을 캡슐화합니다. 사물 형태를 사용하면 ThingWorx의 기존 사물 템플릿에 새 기능을 쉽게 추가할 수 있습니다. 사물 형태를 사물에서 직접 구현하지 마십시오. 사물 템플릿을 통해 사물의 사물 형태 특성을 상속합니다.
예를 들어, 사용자 정의 사물 템플릿 및 사물을 사용하여 자산을 구현한 경우 이러한 사물 템플릿에 사물 형태를 간단하게 추가할 수 있습니다. 그러나 속성 또는 서비스가 사물 템플릿에 직접 정의된 경우에는 사물 템플릿 또는 사물에 대해 기본 사물 템플릿을 변경할 수 없기 때문에 새 기능을 사용하기 위해 모든 자산을 다시 만들어야 합니다.
• 시스템 사물 템플릿에서는 사물을 직접 파생시키지 마십시오. ThingWorx에서 제공하는 기본 사물 템플릿에서 파생되는 사용자 정의 사물 템플릿을 만드는 것이 좋습니다. 이렇게 하면 추가 사물 형태를 구현하고 해당 사물 형태를 사물 템플릿에 추가하여 나중에 추가 기능을 추가할 수 있습니다.
• 응용 프로그램에 연결된 원격 장치가 여러 개 있거나 ThingWorx Edge Micro Server 또는 EDGE SDK를 사용하는 경우 GenericThing 사물 템플릿 대신 RemoteThing 사물 템플릿을 기본 사물 템플릿으로 사용합니다. 파일 전송 또는 터널링이 필요한지 여부에 따라 RemoteThingWithTunnels, RemoteThingWithFileTransfer 또는 RemoteThingWithTunnelsAndFileTransfer 사물 템플릿을 사용합니다. 바인딩되지 않은 원격 사물이 존재하는지 확인하는 스크립트를 통해 원격 바인딩을 추가하는 프로세스를 자동화하고 플랫폼에서 해당 사물을 자동으로 만드는 것이 좋습니다. 이렇게 하면 새 장치가 배송되어 생산 단계로 이동되므로 플랫폼에서 사물을 자동으로 만들 수 있습니다.
|
|
사물 또는 사물 템플릿을 만든 후에는 기본 사물 템플릿을 변경할 수 없습니다.
|
• 네트워크를 사용하여 사물 간의 관계를 정의합니다. 네트워크에서 사물은 다른 사물의 상위, 하위 또는 등위 사물일 수 있습니다. 이를 통해 계층 구조를 모델링할 수 있습니다.
지속 가능성 고려 사항
이 단원에서는 해당되는 기타 고려 사항에 대해 설명합니다.
• 보안
◦ 모든 사물, 사물 템플릿 및 사물 형태를 편집 불가능으로 설정했는지 확인합니다.
◦ 사물 템플릿 또는 사물 형태에 적절한 표시 유형, 런타임 및 디자인 타임 권한을 추가합니다.
◦ 사물 형태, 사물 템플릿 또는 사물에 대한 액세스 권한이 있는 사용자 조직, 사용자 그룹 및 사용자를 정의합니다.
• 업그레이드
◦ 프로젝트 및 태그를 사용하여 사물, 사물 템플릿 및 사물 형태를 구성합니다. 이를 통해 업그레이드를 위한 검색, 내보내기, 표시 유형 권한 수정 및 엔티티 식별과 같은 작업을 수행할 수 있습니다.
◦ 엔티티를 생성할 때 올바른 이름 규약을 사용하는지 확인합니다. 이렇게 하면 업그레이드하는 동안 엔티티의 이름 바꾸기 비용이 절감됩니다.
• 확장 및 사용자 정의
◦ 구성 요소 사물을 확장하려면 OOTB 사물 템플릿을 상속하는 하위 유형 사물 템플릿을 만듭니다.
◦ 확장 개발자의 지침에 따라 하위 유형 사물 템플릿의 서비스 및 특성을 재정의합니다.
◦ 새 사물 형태에 새 서비스 및 속성을 도입합니다.