KR102662252B1

KR102662252B1 - 자동화 목적들을 위한 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법

Info

Publication number: KR102662252B1
Application number: KR1020217018750A
Authority: KR
Inventors: 라이너 스히에코페르; 스테판 그림; 마야 밀리시치 브란트
Original assignee: 지멘스 악티엔게젤샤프트
Priority date: 2018-11-20
Filing date: 2018-11-20
Publication date: 2024-04-29
Also published as: CN112997170A; KR20210089772A; US20210405624A1; JP2022511420A; EP3861463A1; JP7317961B2; WO2020104019A1

Abstract

본 명세서에 설명된 바와 같이 데이터를 제공하기 위한 실시예들은 일반적으로, 온톨로지로의 OPC UA 데이터 모델의 변환을 수반한다. 그러한 온톨로지는 온톨로지로 조정된 정교한 표준 도구들을 사용하여 OPC UA 데이터 모델의 검증, 질의 및 분석을 위한 원하는 능력들을 용이하게 제공한다. 일 실시예에서, 시맨틱적으로 강화된 그래프-기반 데이터 모델, 특히 OPC UA 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법이 제안된다. 제1 단계에 의해, 데이터 모델의 노드들의 식별들이 리트리브된다. 후속하여 또는 동시에, 하나 이상의 노드들을 상호연결시키는 하나 이상의 레퍼런스들의 시맨틱 설명들이 리트리브된다. 이들 시맨틱 설명들은 생성될 타겟 온톨로지 내의 적어도 하나 이상의 술어들 및 하나 이상의 개념들(예컨대, 클래스들)에 의해 표현된다. 결국, 타겟 온톨로지는 시맨틱 온톨로지 언어에 의해 구조화되고 트리플 저장소로 출력된다.

Description

자동화 목적들을 위한 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법

본 실시예들은 자동화 목적들을 위한 데이터 모델(data model)을 온톨로지(ontology)로 변환하기 위한 방법에 관한 것이다. 더 구체적으로, 본 실시예들은 자동화 목적들을 위한 전용된 시맨틱적으로 강화된(semantically enriched) 그래프-기반(graph-based) 데이터 모델을 타겟(target) 온톨로지로 변환하기 위한 방법에 관한 것이다.

과거의 산업 자동화 시스템 컴포넌트(system component)들은 전통적으로, 액세스(access) 및 데이터 교환을 위한 표준 산업 프로토콜(protocol)들을 사용하여, 특수화된 네트워크(network)들에 의해 상호연결되었다. 현재 및 미래의 자동화 시스템들의 개발은 유연한 제조 시나리오(scenario)들의 실현을 목표로 하는 시맨틱적으로 강화된 정보를 교환하는 데 상당한 초점을 두었다.

산업 자동화 시스템들에서 여전히 존재하는 저-레벨(low-level) 신호 통신을 극복하기 위해, OPC UA라는 명칭의 프로토콜이 필드-레벨(field-level) 통신을 시맨틱(semantic) 레벨로 향상시키기 위해 제안되었다. OPC UA(개방형 플랫폼 통신 통합형 아키텍처(Open Platform Communications Unified Architecture))는, 특히 프로세스(process) 자동화에서 산업 데이터를 상호교환하려는 목적으로 제조자-독립적인 통신을 위한 OPC 파운데이션(Foundation)의 산업 표준 프로토콜이다.

OPC UA의 데이터 모델은 자동화 목적들에 전용되는 시맨틱적으로 강화된 그래프-기반 데이터 구조를 특징으로 한다. 그러나, OPC UA는 규격 문서들 내에서 시맨틱(semantic) 설명들을 표현하기 위한 개념들을 오히려 정의하며, 이는 공식적인 시맨틱 표현이 결여되어 있다는 것을 의미한다. 따라서, OPC UA의 사용은 그의 공식적인 시맨틱 표현의 결여로 인해 상당한 단점들을 겪는다:

- 제1 결점으로서, 검증 도구들에 의한 자동 프로세싱(processing)을 허용할 시맨틱 설명들에 대한 어떠한 규칙세트(ruleset)도 존재하지 않으므로, OPC UA의 데이터 모델들은 컴퓨터(computer) 시스템들에 의해 완전히 자동적으로 검증될 수 없다. 공식적인 정의 없이는 해결될 수 없는 다른 문제는 코어(core) OPC UA 표준 자체의 검증이며, 이는 또한 일치하지 않는 스테이트먼트(statement)들을 포함할 수 있다.

- 제2 결점으로서, OPC UA 데이터 모델 내에서의 질의는 복잡하다. OPC UA가 데이터 모델에 액세스하기 위한 질의 언어를 정의하지만, 특히 OPC UA의 데이터 모델 내에 산재된 시맨틱 설명들을 질의하기 위해 부과된 높은 복잡도로 인해, 질의 요청들을 구현하기 위한 프레임워크(framework)가 현재까지 존재하지 않는다.

- 제3 결점으로서, OPC UA에서의 공식적인 시맨틱들의 결여는 스킬-매칭(skill-matching), 데이터 마이닝(data mining), 모니터링(monitoring) 등과 같은 태스크(task)들에 대한 분석 프로세스들을 방해한다.

따라서, 시맨틱적으로 강화된 그래프-기반 데이터 모델들, 특히 OPC UA 내에서의 검증, 분석, 또는 질의를 용이하게 하는 한편, 그러한 데이터 모델들 내에서의 산재된 시맨틱 설명들의 복잡성들을 해소할 필요성이 존재한다.

고려된 데이터 모델에 대한 기존의 문제들을 해결하는데 있어 본 발명에 따른 하나의 예비 고려사항은, 모델 내에서의 시맨틱들의 산재된 속성이 공식적인 시맨틱 표현을 위해 변경되어야 한다는 것이다.

본 명세서의 실시예들은 일반적으로, 용어 및 개념들의 공식적인 시맨틱 표현 뿐만 아니라 이들 개념들 사이의 관계들로서 이해되는 온톨로지로의 데이터 모델의 변환을 수반한다. 온톨로지들은, 온톨로지의 공식적인 표현으로 조정된 정교한 표준 도구들을 사용하여 데이터 모델을 검증, 질의 및 분석하기 위한 원하는 능력들을 용이하게 제공한다.

일 실시예에서, 시맨틱적으로 강화된 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 컴퓨터로 구현되는 방법이 제안되며, 여기서 데이터 모델의 적어도 하나의 계층은 제1 메모리 유닛(memory unit)에 의해 제공된다. 데이터 모델은 속성들에 의해 설명되고 레퍼런스(reference)들에 의해 상호연결된 복수의 노드(node)들을 포함한다. 제1 단계에 의해, 데이터 모델의 상기 노드들로부터 식별들이 리트리브(retrieve)된다. 그에 의해, 각각의 식별은 REST(표현 상태 전달) 규칙세트를 따르는 URI 또는 고유 리소스(Resource) 식별자에 의해 표현되며, 즉 대체되거나 수정된다. 후속하여 또는 동시에, 하나 이상의 노드들을 상호연결시키는 하나 이상의 레퍼런스들의 시맨틱 설명들이 리트리브된다. 이들 시맨틱 설명들은, 생성될 타겟 온톨로지 내의 적어도 하나의 술어(predicate) 및/또는 적어도 하나의 클래스(class)에 의해 표현되며, 즉 대체되거나 수정된다. 결국, 타겟 온톨로지는 시맨틱 온톨로지 언어에 의해 구조화되고 트리플 저장소(triple store)로 출력된다.

다른 실시예에 따르면, 컴퓨터 실행가능 프로그램 코드(program code)가 저장된 데이터 저장 디바이스(device) 및 프로세서(processor)를 포함하는 변환 유닛이 제공된다. 데이터 저장 디바이스는 프로세서 내부 또는 외부에서 구현될 수 있다.

추가적인 실시예에 따르면, 컴퓨터 실행가능 프로그램 코드가 저장된 비-일시적인 컴퓨터-판독가능 저장 매체가 제공된다.

본 실시예들의 목적들 뿐만 아니라 추가적인 장점들은, 첨부된 도면과 함께 취해진 바람직한 실시예들의 다음의 설명으로부터 더 명백해지고 용이하게 인식될 것이며, 도면에서, 도 1은 OPC UA의 모듈식(modular) 구조에 따른 계층화된 아키텍처 프레임워크를 도시한다.

이제, OPC UA의 모듈식 구조에 따른 계층화된 아키텍처 프레임워크를 도시하는 도 1을 참조한다. OPC UA 프레임워크는 다음과 같은 계층화된 구조를 제공한다:

- 메타 계층(Meta Layer)(0) 상에서, 기본 엔티티(entity)들, 예컨대 노드 클래스들, 속성들, 레퍼런스들 등이 OPC UA 메타 계층 OML에 의해 정의된다.

- 가장 일반적인 OPC UA 코어 모델 또는 OPC UA 기본 계층 OBM은 OPC 파운데이션 자체에 의해 제공된다. 코어 모델 OBM은 기본 계층(1) 상의 기본 변수 타입(type)들, 서버(server) 타입들, 엔지니어링(engineering) 유닛들 등의 규격들을 포함한다.

- 위의 컴패니언 계층(Companion Layer)(2)에서, 적어도 하나의 소위 OPC UA 컴패니언 규격(CS1, CS2)은 OPC UA 모델을 확장하는 도메인(domain) 특정 모델들 또는 스키마(schema)들을 정의하는 데 사용된다. 하위 컴패니언 규격(CS1)은 토폴로지(topology) 요소 타입 정의를 포함할 수 있고; 상위 컴패니언 규격(CS2)은 스트림(stream) 타입 정의들, 또는 더 구체적으로는 CNC(컴퓨터 수치 제어) 머신(machine)에 대한 축 타입을 포함할 수 있다.

- 위의 확장 계층(3)은, 예컨대 디바이스 타입 설명들을 포함하는 디바이스 벤더(Vendor) 정보 모델(DVI), 머신 타입 설명들을 포함하는 머신 벤더 정보 모델(MVI) 및 프로세스 타입들 또는 공장 요소 타입들을 포함하는 머신 사용자 정보 모델(MUI)을 포함하는, OEM(오리지널 장비 제조사; Original Equipment Manufacturer)들에 의해 작성된 OEM 특정 스키마 확장들을 호스팅(host)하고 있다.

- 결국, 계층화된 모델의 상단 상의 인스턴스 계층(Instance Layer)(4)은 디바이스/자산 정보 모델(DIM), 즉 아래의 계층들(0, 1, 2, 3)에 정의된 스키마들에 기반하여 개별 디바이스들의 구성 및 데이터 아이템(item)들을 설명하기 위한 인스턴스 모델을 포함한다.

계층들(0,1, 2, 3, 4)에 수직인 OPC UA 정보 모델링(Modelling)(OIM)은 모든 계층들(0,1, 2, 3, 4) 전반에 걸쳐 OPC UA 데이터 모델의 일관성을 상징한다. 정보 모델들의 표현성은 일반적으로 하위 계층으로부터 상위 계층으로 증가한다.

아래에서 추가로 설명될 실시예들의 예상에서, 개개의 계층(0,1, 2, 3, 4) 내의 정보 모델들 또는 데이터 모델들을 개개의 온톨로지(ONT)로 변환하기 위한 변환 프로세스(TRF)는 도면에 도시된 바와 같이, 마찬가지로 모듈식 방식으로 유리하게 수행될 수 있다.

실시예들은 유리하게, 개개의 온톨로지(ONT)로 변환되기 위해 데이터 모델의 하나 이상의 계층들을 제공하는 것을 지원한다. 변환 프로세스(TRF)는 개개의 계층 상의 모듈(module)들 각각을 개개의 OPC UA 모듈들과 동일한 방식으로 서로를 임포트(import)하는 온톨로지(ONT)들로 변환함으로써 OPC UA 정보 모델들 또는 데이터 모델들을 변환한다. 일단 이러한 변환 프로세스(TRF)가 수행되면, 결과적인 온톨로지(ONT)들은 검증, 질의 및 분석의 목적을 위해 사용될 수 있다.

검증 목적들을 위해, 그래프-기반 데이터 모델로서의 OPC UA 그래프는 RDF 기반 타겟 온톨로지로 변환되며, 이어서 그 RDF 기반 타겟 온톨로지는 그래프-기반 데이터 모델을 검증하는 대신 표준 온톨로지 도구들을 사용하여 검증을 받는다. 이러한 검증 단계 이후, 검증 알고리즘(algorithm)들을 구현하기 위한 부가적인 노력 없이 종래의 추론기들을 사용하여 타겟 온톨로지의 일관성을 검사하는 것이 가능하다. 이러한 접근법은 또한, 타겟 온톨로지를 구축하는 데 사용되는 시맨틱 온톨로지 언어의 선언적 속성을 통해 자동 규칙 업데이트(update)들을 지원할 것이다. 도 1을 다시 참조하면, 이러한 검증은, 코어 규격 자체의 일관성을 보장하기 위해 기본 계층(1)에 대해, 코어 규격에 대해 새롭게 개발된 컴패니언 규격들을 검증하기 위해 컴패니언 계층(2)에 대해, 기본 스키마들에 대해 벤더 특정 확장들을 검증하기 위해 확장 계층(3)에 대해, 그리고 마지막으로, 주어진 스키마에 대해 인스턴스 모델을 검증하기 위해 인스턴스 계층(4)에 대해 행해질 수 있다. 모든 OPC UA 규칙들 및 또한 컴패니언 규격들에 의해 추가될 수 있는 모든 규칙들의 전체 커버리지(coverage)를 가능하게 하기 위해, 여러가지 상이한 추론 기술들, 예컨대 OWL(웹 온톨로지 언어; Web Ontology Language), SHACL(형태 제약 언어; Shapes Constraint Language) 등을 결합할 필요가 있을 수 있다.

질의 목적들을 위해, 실시예들은 유리하게, 공통 질의 언어(SPARQL)(SPARQL 프로토콜 및 RDF 질의 언어)를 사용하여 OPC UA 데이터 모델에 대한 용이한 액세스를 제공하는 것을 지원한다. 이를 위해, 실시예들은 타겟 온톨로지 내의 RDF 표현을 결과로서 보장하며, 이는 공식적인 방식으로 OPC UA 시맨틱들을 캡처(capture)한다. 다른 애플리케이션(application)들(예컨대, 모니터링, 인간 머신 인터페이스(human machine interface)들, 유지보수 등)에 대한 필수적인 데이터 포인트(point)들을 찾기 위해, 통상적으로 인스턴스 계층 상에서 질의가 발생한다. 그러나, 질의들은 확장 계층(3) 및 컴패니언 계층(2)에 대한 인트로스펙션(introspection) 목적을 위해, 그리고 추가로, 기본 계층(1)에 대한 검증들을 위해 또한 사용될 수 있다.

분석을 지원하기 위해, 실시예들은 유리하게, 공식적인 방식으로 OPC UA 컴패니언 표준들의 시맨틱들에 대한 액세스를 획득하는 것을 지원한다.

공식적인 액세스는 스킬 매칭, 온보딩(onboarding), 모니터링 등과 같은 사용 사례들을 가능하게 한다. 이는 컴패니언 계층(2)과 결합된 인스턴스 계층(4)에 특히 유용하며, 여기서 컴패니언 계층(2)은 주어진 도메인에 대한 표준화된 시맨틱들을 제공하고, 그에 의해 인스턴스 계층(4)은 이들 시맨틱들에 의해 태깅(tag)된 특정 값들을 제공한다. 컴패니언 계층(2)에 기반하여, 주어진 도메인에 대해 널리 수용된 표준화된 어휘(vocabulary)들에 의해 시맨틱 상호운용성이 달성될 수 있다. 공식적인 OWL 표현은 또한, 상이한 도메인들로부터의 2개의 개념들이 동일하다는 것(예컨대, 온도)을 의미한다는 사실을 표현하기 위해 상이한 OPC UA 컴패니언 규격들을 상호연결시키는 데 사용될 수 있으며, 이는 현재 OPC UA 자체에서 표준화되어 있지 않다.

확장-계층이 또한 분석을 위해 사용될 수 있으며, OPC 파운데이션의 공식적인 표준화 프로세스 없이 온톨로지들을 OPC UA에 쉽게 임포트하는 데 특히 유용하다. 온톨로지들의 그러한 임포트는, schema.org 또는 시맨틱 센서(sensor) 네트워크 온톨로지와 같은 기존의 온톨로지들을 사용하여 프로세싱될 수 있다.

다음에서, 개개의 계층(0,1, 2, 3, 4) 내의 데이터 모델들을 개개의 타겟 온톨로지(ONT)로 변환하기 위한 변환 프로세스(TRF)가 이제 더 상세히 개시된다.

실시예들의 제1 단계에 따르면, UPC UA 노드들의 식별들 또는 NodeID들이 리트리브되며, 각각의 식별은 REST(표현 상태 전달) 규칙세트를 따르는 URI(고유 리소스 식별자)에 의해 표현된다.

OPC UA 데이터 모델에서, 어드레스(address) 공간 내의 모든 엔티티는 노드이다. 노드를 고유하게 식별하기 위해, 각각의 노드는 3개의 요소들, 즉 NamespaceIndex, IdentifierType 및 식별자를 포함하는 NodeId를 갖는다.

NamespaceIndex는, 데이터의 전달 및 프로세싱을 촉진하기 위해 namespace 식별자 대신 온라인(online) 동작에서 OPC UA 서버에 의해 사용되는 인덱스(index), 일반적으로는 수치 값이다. namespace 식별자는 NodeId들의 식별자들을 정의하는 명명 기관, 예컨대 OPC 파운데이션, 다른 표준 기관들 및 컨소시엄들(consortia), 기본 시스템, 또는 로컬(local) 서버를 식별한다. NamespaceIndex는 그 개개의 namespace 식별자 또는 namespace URI(균일한 리소스 식별)와 함께 보관소에 저장된다. OPC UA 내의 이러한 보관소는 또한 namespace 어레이(array)로 지칭된다. IdentifierType은 식별자의 데이터 타입, 예컨대 수치 값, 스트링(string) 등을 정의한다. 식별자는 결국, OPC UA 서버의 어드레스 공간에서 노드를 식별한다.

OPC UA 규격들이 범시스템적(system-wide)이고 글로벌하게(globally) 고유한 식별자들(NodeId)을 보증(endorse)하지만, 하나 초과의 노드가 공통 식별자(예컨대, DisplayName, 설명)를 갖는 경우들이 존재한다. 따라서, 식별들의 리트리벌(retrieval)은 선택적으로, 공통 명칭을 갖는 별개의 시맨틱들을 명확하게 맵핑(map)하기 위해, 각각의 OPC UA 노드에 대한 브라우즈(browse) 명칭 또는 >>BrowseName<<의 리트리벌을 동반할 수 있다. 그러나, 일반적으로, OPC UA는 동일한 브라우즈 명칭을 공유하는 다수의 노드들을 허용한다. OPC UA에 따른 BrowseName이 모든 경우들에서 노드를 명확하게 식별하는 데 사용될 수 없지만(이는 상이한 노드들이 동일한 BrowseName을 가질 수 있기 때문임), BrowseName의 namespace는 노드의 콘텍스트(context), 예컨대 노드의 일부 속성들에서 일부 경우들에 BrowseName을 고유하게 만들기 위해 제공될 수 있다.

(NodeId에 기반한) 노드의 예시적인 식별은 다음과 같이 구조화되며:

NamespaceString/i=1:11111111111

여기서, >>NamespaceString<<은 namespace 식별자를 표현하는 스트링이다. 상기 스트링은 NamespaceIndex에 기반한 NamespaceArray로부터 수집되며, 여기서는 NodeId의 1의 수치 값을 갖는다. NamespaceString은 슬래시(slash) 또는 >>/<<로 끝나도록 요구된다. NodeId는 아래에서 추가로 설명되는 바와 같이 구성된다. NamespaceIndex i는 1로 설정되는데, 이는 이것이 NamespaceString과 동일해야 하는 로컬 서버에 대한 인덱스이기 때문이다. 예외는, 이러한 노드가 OPC UA 기본 모델(OBM)의 일부라는 것을 표시하는 제로(zero) 또는 >>0<<의 값을 갖는 NamespaceIndex이다. 그러나, >>NamespaceString<<이 NamespaceArray의 인덱스 1과 동일하면, 대응하는 NamespaceArray만을 생략하는 것이 허용된다.

적격(qualified) 명칭을 포함하는 노드의 추가의 예시적인 식별은 다음과 같이 구조화되며:

NamespaceString/QualifiedName.name

여기서, >>QualifiedName<<은 2개의 부분들, 즉 namespaceindex 및 명칭을 갖는 데이터 구조이다. NamespaceString은 NamespaceArray의 대응하는 엔트리(entry), 예컨대 http://opcfoundation.org/UA/ServerType에 기반한다.

질의를 포함하는 노드의 추가의 예시적인 식별은 다음과 같이 구조화되며:

<host>/i=1:11111111111/QualifiedNameString?ns=NamespaceStringArray

여기서, 시퀀스(sequence) >>?ns=NamespaceStringArray<<는 NamespaceArray 내의 Namespace에 대한 질의를 나타낸다. 이러한 경우, NamespaceString은 질의 인수 >>?ns=NamespaceStringArray<<에 기반하며, 여기서 질의 인수 내의 제1 엔트리는 NamespaceIndex 1을 나타낸다.

위에서 도시된 노드의 그러한 OPC UA 식별들은 REST 또는 표현 상태 전달 규칙세트를 따르는 URI에 의해 표현되어야 한다. 표현 상태 전달 또는 REST은 웹 서비스(service)들을 생성하기 위해 사용될 제약들의 세트(set)를 정의하는 소프트웨어 아키텍처 스타일(software architectural style)이다. REST의 제약들 중 하나는, 예컨대 인터넷 엔지니어링 태스크 포스(IETF; Internet Engineering Task Force)의 제안 RFC 3986(>>Requests for Comments<<)에 따른 URI들의 리소스들의 균일한 식별이다.

RFC 3986에 따른 URI의 예시적인 일반적인 예는 다음과 같이 구조화되며:

https://example.com:8042/over/there?name=gear#shaft

여기서, 시퀀스 >>https<<는 스킴(scheme)을 나타내고, 시퀀스 >>example.com:8042<<는 기관을 나타내고, 시퀀스 >>/over/there<<는 경로를 나타내고, 시퀀스 >>?name=gear<<는 질의를 나타내며, 시퀀스 >>shaft<<는 프래그먼트(fragment)를 나타낸다.

RFC 3986에 따른 URI의 OPC UA 콘테스트(contest)에 대해 특정한 예는 다음과 같이 구조화되며:

https://example.com:8042/vendorSpecific/V1.04/11111/i=111111111?qKey=qValue

여기서, 시퀀스는 >>https<<는 스킴을 나타내고, 시퀀스 >>example.com:8042<<는 기관을 나타내고, 시퀀스 >>/vendorSpecific<<는 경로 접두사를 나타내고, 시퀀스 >>/V1.04<<는 API(애플리케이션 프로그래밍 인터페이스; Application Programming Interface)의 버전(version) 또는 apiVersion을 나타내며, 이는 일반적으로 OPC 파운데이션에 의해 설정된다. 선택적인 시퀀스 >>/11111<<는 OPC UA 서버의 속성 값인 URI의 버전 또는 uriVersion을 나타낸다. 후자의 3개의 시퀀스들을 포함하는 스트링 >>/vendorSpecific/V1.04/11111/i=111111111<<은 경로로 지칭된다. 마지막으로, 시퀀스 >>?qKey=qValue<<는 키(key)(qKey) 내의 질의된 값(qValue)에 대한 질의를 나타낸다.

시퀀스들을 식별하기 위해, 파서(parser)가 다음의 규칙들로 적용된다:

머신-판독가능 URI들 뿐만 아니라 인간-판독가능 URI들을 추론하는 것이 바람직하지만(이들 중 후자는 용이한 어드레싱(addressing)을 위해 나중에 사용될 수 있음), 이러한 목적은 타입들의 BrowseNames이 고유하다는 가정에 기반한다. 더 구체적으로, 동일한 BrowseName을 갖는 2개의 타입들을 정의하는 것은 허용되지 않을 것이다. 그러나, 그러한 제한은 일반적으로 OPC UA 내에서 요구되지 않으며, 각각의 경우에 보장될 수 없다. 적어도 이러한 고유성은 양호한 모델 관행으로 고려된다.

이러한 가정이 유지되지 않으면, BrowseName 대신 NodeId가 사용될 것이다. 더 나아가, StructureFieldNames 및 InstanceDeclarationBrowseNames이 유사한 제한들을 가져야 한다. 그러나, 이러한 경우, BrowseName은 여러 번 재사용될 수 있지만, 의미는 항상 동일해야 한다. 예컨대, BrowseName를 갖는 2개의 InstanceDeclaration들을 정의하는 것은 피해야 하며:

http://myNamespace.org/sensorValue

여기서, 하나의 경우에는 온도 그리고 다른 경우에는 압력이 어드레싱되는 반면, 이들 센서 값들 사이의 차이는 상이한 InstanceDeclaration들의 상이한 설명 속성들을 판독하는 것을 통해서만 인간에 의해 해석될 수 있다.

둘 모두의 경우들에서, 예컨대 다음과 같은 더 구체적인 BrowseName을 사용하는 것이 더 적절하다:

http://myNamespace.org/temperature

및

http://myNamespace.org/pressure

폴백 솔루션(fallback solution)은 BrowseName 대신 InstanceDeclaration의 NodeId를 사용하는 것이다. 일반적으로, 재사용된 BrowseNames에 대한 다음의 조건들이 고려되어야 한다:

- DescriptionName 및 DisplayName 속성들은 동일하다. 이것은 어쨌든 생성기 도구들에 대한 디폴트(default) 검사이다.

- 상이한 InstanceDeclaration들의 시맨틱들은 동일하다. 인간은 InstanceDeclaration들 둘 모두가 동일한 것, 예컨대 DescriptionName 또는 DisplayName 속성들이 상이한 경우들에서는 온도 값을 어드레싱한다고 가정할 것이다.

- BrowseName의 시맨틱들이 여전히 적용되는 한, DataType, ModellingRule, NodeClass, TypeDefinition 및 ReferenceType을 변화시키는 것이 허용된다. 예컨대, 하나의 경우에는 온도가 단순한 변수로서 노출되고, 다른 경우에는 복잡한 변수가 사용된다. 그러나, 통상적으로, 이들 개념들이 변화되어야 하면, 상이한 BrowseNames을 사용하는 것을 고려해야 한다.

요약하면, NodeID들(및 선택적으로는 브라우즈 명칭들)을 리트리브하고 이들을, REST 규칙세트를 따르는 URI에 의해 표현하기 위한 실시예들의 제1 단계는 단순히, REST 아키텍처 스타일을 따르는 웹-클라이언트(client)들에 의한 액세스가능성(accessibility)을 제공한다. 그 외에도, URI들은 인간들이 문자 그대로 판독가능한 포맷(format)으로 제공된다. 이러한 가독성은 유리하게, SPARQL 및 와 같은 지식 관리 시스템 도구들 및 온톨로지 편집기를 적용할 때 사용자 경험을 개선시킨다.

는 온톨로지들을 정의하고 수정하기 위한 그래픽 사용자 인터페이스(graphic user interface)를 특징으로 하는 자유로운 오픈 소스(open source) 온톨로지이다. 는 일관성을 검증하기 위한 그리고 온톨로지의 분석에 기반하여 새로운 정보를 추론하기 위한 연역적 분류기들을 포함한다.

실시예들의 제2 단계에 따르면, 타겟 온톨로지의 적어도 하나의 술어 및/또는 적어도 하나의 클래스에 의해 시맨틱 설명들을 표현하기 위해, 노드들 사이의 레퍼런스들의 시맨틱 설명들이 리트리브된다.

술어는, 월드 와이드 웹 컨소시엄(W3C; World Wide Web Consortium)의 규격들에 따라 리소스 설명 프레임워크(RDF)에서 데이터 모델에 의해 조직화된 온톨로지의 원자 데이터 엔트리(atomic data entry)인 시맨틱 트리플(semantic triple)의 일부이다. 트리플은 주어-술어-목적어 표현들의 형태로 시맨틱 데이터에 관한 스테이트먼트를 성문화(codify)하는 3개의 엔티티들의 세트이다. 트리플들은 일반적으로, 조직화되어, 트리플 저장소라는 명칭의 데이터베이스(database)에 저장된다.

실시예의 제1 단계가 노드 식별들의 맵핑으로 지칭되지만, 제2 단계는 온톨로지의 하나 이상의 술어들에 시맨틱 설명들을 맵핑하는 것을 목표로 한다. 맵핑은 구체적으로, OPC UA의 데이터 모델 내에 산재된 시맨틱 설명들을 리트리브 또는 파싱(parse)하기 위한 규칙들을 적용하는 것, 이러한 시맨틱 설명들을 공통 개념들로 분류하는 것, 및 분류된 개념들을 시맨틱 온톨로지 언어의 공식적인 데이터 표현에 포함시키는 것을 의미한다.

RDF, RDFS 또는 RDF 스키마로서의 다른 시맨틱 온톨로지 언어 중에서 바람직한 시맨틱 온톨로지 언어는 OWL 또는 웹 온톨로지 언어로 지칭되는 언어군에 의해 제공된다. OWL 언어군은 리소스 설명 프레임워크 또는 RDF에 따라 객체들에 대한 W3C의 XML 표준에 따라 구조화된다. OWL은 RDF와 결합하여, 온톨로지들을 작성하기 위한 지식 표현을 구현하는데 있어 광범위한 보급을 갖는다.

다음에서, 하나 이상의 중간 대문자들을 갖는 복합 명칭들, 예컨대 복합 명칭 >>TypeDefinitionNodes<<은 OPC 파운데이션의 규격 >>OPC Unified Architecture<<에서 또는 OWL 규격에서 사용되는 권위있는 명칭들을 지칭하는 데 사용된다. 이들 권위있는 명칭들은 당업자에게 알려져 있는 것으로 가정된다. 따라서, 이하, 이들 권위있는 명칭들은 설명없이 도입된다.

다음의 OPC UA 레퍼런스들은 타겟 온톨로지의 적어도 하나의 술어에 의해 표현되거나 그에 맵핑될 적합한 시맨틱 설명들을 포함한다:

- TypeDefinitionNodes(VariableType, ObjectType)

- InstanceDeclarations

- BrowseNames 및 다른 속성들

- ReferenceType

- 어드레스 공간의 구조(예컨대, 뷰(view)들)

- DataTypes(예컨대, Structure-DataType)

다음 섹션(section)은 OPC UA 시맨틱들이 온톨로지 또는 OWL 클래스 개념으로 어떻게 변환되는지를 정의한다. OWL의 다음의 온톨로지 클래스 개념들은 맵핑에 적합한 OPC UA의 시맨틱들 내에 적절한 대응부들을 갖는다:

- 클래스 개념 >>Base<<는 OPC UA의 BaseNodeClass 및 각각의 구체적인 인스턴스 NodeClass의 슈퍼 타입(super type)으로부터 도출된다.

- 클래스 개념 >>DataType<<은 Root/Types/DataTypes 하에서 발견될 수 있는 DataType 계층구조와 동일하다.

- 클래스 개념 >>InstanceDeclaration<<은 대응하는 검증 규칙들을 이러한 개념에 추가하기 위한 헬퍼(helper) 개념이다.

- 클래스 개념인 >>MethodType<<은 모든 방법 시맨틱들을 커버(cover)하고 태깅하기 위한 헬퍼 클래스이다. 시맨틱들은 방법의 ObjectType 및 BrowseName에 기반하여 캡처될 수 있다.

- 클래스 개념 >>ObjectType<<은 Root/Types/ObjectTypes 하에서 발견될 수 있는 ObjectType 계층구조와 동일하다. 그러나, 객체 관련 InstanceDeclarations이 또한 이러한 계층구조에서 발견될 수 있다.

- 클래스 개념 >>ValueRankHelper<<는 대응하는 검증 규칙들을 이러한 개념에 추가하기 위한 헬퍼 개념이다.

- 클래스 개념 >>VariableType<<은 Root /Types/VariableTypes 하에서 발견될 수 있는 VariableType 계층구조와 동일하다. 그러나, Variable-InstanceDeclarations이 또한 이러한 계층구조에서 발견될 수 있다.

클래스 개념 >>InstanceDeclaration<<은 서브 클래스(sub class)들 MethodInstanceDeclaration, ObjectInstanceDeclaration 및 VariableInstanceDeclaration을 포함한다. OPC UA 규격들, 파트(part) 3, 챕터(chapter) 6.3.6에서의 InstanceDeclarations의 인스턴스들에 관한 제한들은 OWL DataProperty 제한들과 조합하여 OWL-클래스들 및 서브클래스(Subclass)-개념을 사용해서 모델링된다.

클래스 개념 >>DataType<<은 OPC UA 변수들 및 OPC UA 변수 타입들 또는 VariableTypes와 조합하여 DataTypes에 대한 제한들을 사용해서 구축된다. >>DataType<< 클래스 개념은, DataType-Field 제약들의 구조에 대한 제한들을 더 포함하는, 데이터 타입과 같은 DataType 필드 시맨틱들을 구조화하기 위해 OWL 객체 속성 제한들 및 OWL 통합 개념과 조합하여 OWL 클래스들 및 OWL 서브클래스 개념을 사용해서 구조화된다. 예시적인 데이터 타입은 32 비트(bit) 길이의 부호없는 정수 또는 UInt32이다.

클래스 개념 >>MethodType<<은 모든 InstanceDeclaration-Methods에 대한 최상위-레벨-개념이다. 방법들의 시맨틱 정의는 속성들과 비슷하다. 통상적인 방법들은 >>owning Object<< 및 할당된 BrowseName에 의해 정의된다. MethodType 개념을 구조화하기 위해 다음의 규칙들이 적용된다:

- 소유 객체에 관계 없이 동일한 BrowseName을 갖는 모든 방법 노드들을 하나의 개념에 맵핑하려고 시도한다. 이러한 규칙은 속성 BrowseNames와 유사하지만, 이러한 맵핑이 가능하지 않으면, 이접적(disjunctive) 개념들이 도입되어야 한다.

- 검증 목적들을 위해, 클래스 개념 >>MethodType<< 하의 서브타입(subtype)들이 도입되며, 서브타입들은 플레이스홀더(placeholder) 모델링 규칙에 기반한다.

클래스 개념 >>ObjectType<<은 OPC UA 개념의 시맨틱들을 캡처하고 대응하는 InstanceDeclaration 및 ModellingRules의 제한들을 할당하는 데 사용된다. ObjectType은 라벨(label)들, 코멘트(comment)들 등을 포함하는 주석 속성들로 이루어진다. 온톨로지에서의 클래스 개념은 OWL DataProperty 제한들 및 OWL AnnotationProperties와 조합하여 OWL 클래스들 및 OWL-서브클래스-개념을 사용해서 모델링된다. OWL DataProperty 제한들은 규격의 파트 3의 OPC UA 규격에서 공식화된 규칙들에 따라 모델링된다.

클래스 개념 >>ValueRankHelper<<에 의해, OPC UA 노드들의 속성 ValueRank에 관한 제한들은 OWL DataProperty 제한들과 조합하여 OWL 클래스들 및 OWL 서브클래스 개념을 사용해서 OPC UA 파트 3, 섹션들 5.6.5 및 6.2.7에 따라 모델링된다. OPC UA 파트 3, 섹션 6.2.7 c)에 따른 하나의 예시적인 제약은 다음과 같이 판독된다:

ArrayDimensions 속성은, 그것이 제공되지 않았다면 또는 어레이 내의 엔트리의 값을 0으로부터 상이한 값으로 수정할 때 추가될 수 있다. 어레이 내의 다른 모든 값들은 동일하게 유지될 것이다.

이러한 제약은 정규 표현 또는 RegEx-pattern에 맵핑되며, 예컨대 다음과 같다:

클래스 개념 >>VariableType<<은 OPC UA 개념의 시맨틱들을 캡처하고 대응하는 InstanceDeclaration 및 ModellingRules의 제한들을 할당하는 데 사용된다. VariableType은 라벨들, 코멘트들 등을 포함하는 주석 속성들로 이루어진다. 온톨로지에서의 클래스 개념은 OWL DataProperty 제한들, OWL ObjectProperty 제한들 및 OWL AnnotationProperties와 조합하여 OWL 클래스들 및 OWL-서브클래스-개념을 사용해서 모델링된다. OWL DataProperty 제한들은 규격의 파트 3의 OPC UA 규격에서 공식화된 규칙들에 따라 모델링된다.

속성들은 다음의 맵핑 규칙에 의해 온톨로지에서 모델링된다. 속성들 및 그들의 BrowseNames, 즉 속성 BrowseName의 정의들은 각각의 고유한 Property-BrowseName에 대한 PropertyType의 서브개념(subconcept)으로서 도입된다. 이러한 일반적인 맵핑 규칙은, 동일한 BrowseNames을 갖는 속성들이 또한 대응하는 Property-BrowseName 개념에 맵핑될 것이라는 것을 보장할 것이다.

최상위-레벨 객체 속성 >>objectProperties<<는 sameIndividual 추론들을 시행하는 데 사용될 수 있다. 이러한 개념은 자신에게 어떠한 다른 시맨틱들을 할당되게 하지 않는다.

InstanceDeclarations의 BrowseName 및 StructureFieldName 개념에 관해, InstanceDeclaration의 각각의 BrowseName은 객체 속성에 맵핑될 것이다. 각각의 StructureFieldName은 Structure-DataType-Namespace의 namespace 및 FieldName을 갖는 스트링-부분을 가진 객체 속성에 맵핑될 것이다. Structure-DataType-Field의 설명은 rdfs:comment 주석에 맵핑될 수 있다.

ReferenceType 개념에 관해, OPC UA의 ReferenceTypes는 온톨로지의 객체 속성들에 맵핑될 것이다. 대칭적이지 않은 모든 레퍼런스들은 >>inverse<< 대응부를 가져야 한다. >>InverseOf<< 공리에 기반하여, 추론기는 명시적 모델링의 필요성 없이 양방향 레퍼런스들을 자동으로 추론할 수 있다. InverseName 속성이 특정되면, 상기 속성은 개념을 명명하기 위해 사용된다. InverseName 속성이 특정되지 않으면, 접두사 >>inverse<<를 갖는 ReferenceName(예컨대, inverseHierarchicalReferences)이 사용될 것이다.

역방향 레퍼런스들의 신뢰할 수 있는 추론을 보장하기 위해, HierarchicalReferences 트리(tree)가 완전히 미러링(mirror)되어야 한다. ReferenceType이 대칭적이고 계층적인 것으로 정의되면, 레퍼런스는 순방향 및 역방향 트리의 서브타입이어야 한다. 대칭적 레퍼런스들(즉, Symmetric-Attribute이 참(true)으로 설정됨)은 또한 SymmetricObjectProperty을 참으로 설정함으로써 반영될 것이다.

본 발명은 OPC UA 정보 모델들의 검증을 위해 이미 존재하는 시맨틱 웹 추론 도구들을 사용하는 것을 허용한다.

다른 장점은, 웹 온톨로지 언어들, 구체적으로는 OWL의 선언적 속성을 통해, 새롭게 추가된 규칙들이 코드 베이스(code base)를 수정하지 않으면서 프로세싱될 수 있다는 사실이다.

본 발명은 OPC UA 데이터 모델을 질의하는 것을 가능하게 한다. 현재, 이용가능한 OPC UA 데이터 모델을 질의하기 위한 어떠한 제품-준비 도구 구현도 존재하지 않는다. SPARQL 엔진(engine)에 의해 요구되는 RDF 트리플들을 포함하는 온톨로지를 생성하기 위해 본 발명에 따른 맵핑을 사용함으로써, OPC UA 데이터 모델들의 질의가 실현가능해진다. 그러나, OPC UA 노드들에 기반하여 트리플들을 생성하는 것만으로는 충분하지 않을 것이다. 본 발명은, OPC UA의 시맨틱들이 캡처되는 그러한 방식으로 트리플들이 생성되어, 질의들을 공식화하기 위한 노력을 상당한 크기만큼 감소시킬 가능성들을 제공하는 방법을 제공한다. 본 발명의 맵핑에 기반하여, 시맨틱 웹 전문가들 뿐만 아니라 OPC UA 전문가들은 질의들을 공식화할 수 있다.

본 발명은 추가로, OPC UA 데이터 모델을 분석하는 것을 가능하게 한다. OPC UA 시맨틱들의 공식적인 표현에 기반하여, 스킬-매칭, 기계류로의 디바이스들의 온보딩, 데이터-마이닝 등과 같은 태스크들을 행하는 것이 이제 가능하다.

첨부된 청구항들에서 인용된 요소들 및 특징들이, 마찬가지로 본 발명의 범위 내에 속하는 새로운 청구항들을 생성하기 위해 상이한 방식들로 결합될 수 있다는 것이 이해되어야 한다. 따라서, 아래에 첨부된 종속 청구항들은 오직 단일 독립 또는 종속 청구항만을 인용하지만, 대안적으로, 이들 종속 청구항들은, 독립적이든 또는 종속적이든, 임의의 선행 또는 후속 청구항을 대안적으로 인용하도록 이루어질 수 있고, 그러한 새로운 조합들은 본 명세서의 일부를 형성하는 것으로 이해되어야 한다는 것이 이해되어야 한다.

본 발명이 다양한 실시예들을 참조하여 위에서 설명되었지만, 설명된 실시예들에 대해 많은 변화들 및 수정들이 이루어질 수 있다는 것이 이해되어야 한다. 따라서, 전술한 설명은 제한적이기보다는 예시적인 것으로 간주되는 것이 의도되며, 모든 등가물들 및/또는 실시예들의 조합들이 이러한 설명에 포함되도록 의도된다는 것이 이해된다.

Claims

자동화 목적들을 위한 시맨틱적으로 강화된(semantically enriched) 그래프-기반(graph-based) 데이터 모델(data model)을 타겟 온톨로지(target ontology)로 변환하기 위한 방법으로서,
제1 메모리 유닛(memory unit)으로부터 상기 데이터 모델의 적어도 하나의 계층을 제공하는 단계 － 상기 데이터 모델은 속성들에 의해 설명되고 레퍼런스(reference)들에 의해 상호연결된 복수의 노드(node)들을 포함함 －;
상기 노드들의 식별들 및/또는 브라우즈 명칭(browse name)들을 리트리브(retrieve)하고, REST 또는 표현 상태 전달 규칙세트(ruleset)를 따르는 URI 또는 고유 리소스(resource) 식별자에 의해 각각의 식별을 표현하는 단계;
상기 레퍼런스들의 시맨틱(semantic) 설명들을 리트리브하고, 상기 타겟 온톨로지의 적어도 하나의 술어(predicate) 및/또는 적어도 하나의 클래스(class)에 의해 상기 시맨틱 설명들을 표현하는 단계;
시맨틱 온톨로지 언어에 의해 상기 타겟 온톨로지를 구조화하고, 상기 타겟 온톨로지를 트리플 저장소(triple store)에 출력하는 단계를 포함하는, 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법.
제1항에 있어서,
상기 자동화 목적들을 위한 상기 시맨틱적으로 강화된 그래프-기반 데이터 모델은 OPC UA 데이터 모델인, 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법.
제1항에 있어서,
상기 시맨틱 온톨로지 언어는 RDF, OWL 및 RDFS(RDF 스키마(schema)) 중 하나인, 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법.
제1항에 있어서,
상기 URI는, 브라우즈 명칭, 디스플레이(display) 명칭 및 설명 속성 중 적어도 하나를 추가로 사용하여 상기 타겟 온톨로지 내의 상이한 인스턴스(instance) 선언들에 대해 고유하게 표현되는, 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법.
제1항 내지 제4항 중 어느 한 항에 있어서,
상기 타겟 온톨로지의 적어도 하나의 술어 및/또는 적어도 하나의 클래스에 의해 상기 시맨틱 설명들을 표현하는 단계는, 상기 그래프-기반 데이터 모델 내의 시맨틱 설명들을 파싱(parse)하고, 상기 시맨틱 설명들을 공통 개념들로 분류하며, 그리고 상기 분류된 개념들을 상기 시맨틱 온톨로지 언어 내의 공식적인 데이터 표현에 포함시키는 단계를 포함하는, 그래프-기반 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법.
변환 유닛으로서,
프로세서(processor); 및
컴퓨터(computer) 실행가능 프로그램 코드(program code)가 저장된 데이터 저장 디바이스(device)를 포함하며,
상기 컴퓨터 실행가능 프로그램 코드는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금,
제1 메모리 유닛으로부터 자동화 목적들을 위한 시맨틱적으로 강화된 그래프-기반 데이터 모델의 적어도 하나의 계층을 로딩(load)하게 하고 － 상기 데이터 모델은 속성들에 의해 설명되고 레퍼런스들에 의해 상호연결된 복수의 노드들을 포함함 －;
상기 노드들의 식별들 및/또는 브라우즈 명칭들을 리트리브하게 하고, REST 또는 표현 상태 전달 규칙세트를 따르는 URI 또는 고유 리소스 식별자에 의해 각각의 식별을 표현하게 하고;
상기 레퍼런스들의 시맨틱 설명들을 리트리브하게 하고, 타겟 온톨로지의 적어도 하나의 술어 및/또는 적어도 하나의 클래스에 의해 상기 시맨틱 설명들을 표현하게 하며;
시맨틱 온톨로지 언어에 의해 상기 타겟 온톨로지를 구조화하게 하고, 상기 타겟 온톨로지를 트리플 저장소에 출력하게 하는, 변환 유닛.
컴퓨터 실행가능 프로그램 코드가 저장된 비-일시적인 컴퓨터-판독가능 저장 매체로서,
상기 컴퓨터 실행가능 프로그램 코드는, 컴퓨터에 의해 실행될 때, 상기 컴퓨터로 하여금,
제1 메모리 유닛으로부터 자동화 목적들을 위한 시맨틱적으로 강화된 그래프-기반 데이터 모델의 적어도 하나의 계층을 로딩하게 하고 － 상기 데이터 모델은 속성들에 의해 설명되고 레퍼런스들에 의해 상호연결된 복수의 노드들을 포함함 －;
상기 노드들의 식별들 및/또는 브라우즈 명칭들을 리트리브하게 하고, REST 또는 표현 상태 전달 규칙세트를 따르는 URI 또는 고유 리소스 식별자에 의해 각각의 식별을 표현하게 하고;
상기 레퍼런스들의 시맨틱 설명들을 리트리브하게 하고, 타겟 온톨로지의 적어도 하나의 술어 및/또는 적어도 하나의 클래스에 의해 상기 시맨틱 설명들을 표현하게 하며;
시맨틱 온톨로지 언어에 의해 상기 타겟 온톨로지를 구조화하게 하고, 상기 타겟 온톨로지를 트리플 저장소에 출력하게 하는, 비-일시적인 컴퓨터-판독가능 저장 매체.