Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule użyto ontologii RealEstateCore opartej na języku DTDL dla inteligentnych budynków jako podstawy przykładów rozszerzania nalogów z nowymi właściwościami DTDL. Opisane tutaj techniki są ogólne i można je zastosować do dowolnej części ontologii opartej na języku DTDL z dowolną funkcją DTDL zgodną z usługą Azure Digital Twins (właściwość, relacja, składnik).
Standardowe ontologie firmy Microsoft, takie jak ontologia RealEstateCore oparta na DTDL, to doskonały sposób na rozpoczęcie tworzenia rozwiązania IoT. Ontologie branżowe zapewniają bogaty zestaw interfejsów podstawowych, które są przeznaczone dla Twojej domeny i zaprojektowane do działania bez dodatkowej konfiguracji w usługach Azure IoT, takich jak Azure Digital Twins.
Istnieje jednak możliwość, że rozwiązanie może mieć określone potrzeby, które nie są objęte dziedziną ontologii branżowej. Na przykład możesz połączyć cyfrowe bliźniaki z modelami 3D przechowywanymi w osobnym systemie. W takim przypadku można rozszerzyć jedną z tych nalogów, aby dodać własne możliwości, zachowując jednocześnie wszystkie korzyści wynikające z oryginalnej ontologii.
Hierarchia przestrzeni RealEstateCore
W ontologii RealEstateCore opartej na języku DTDL hierarchia przestrzeni służy do definiowania różnych rodzajów przestrzeni: pomieszczeń, budynków, strefy itd. Hierarchia rozciąga się od każdego z tych modeli w celu zdefiniowania różnych rodzajów pomieszczeń, budynków i stref.
Część hierarchii wygląda podobnie do poniższego diagramu.
Aby uzyskać więcej informacji na temat ontologii RealEstateCore, zobacz ontologię RealEstateCore opartą na języku definicji cyfrowych bliźniaków dla inteligentnych budynków w serwisie GitHub.
Rozszerzanie hierarchii przestrzeni RealEstateCore
Czasami rozwiązanie ma określone potrzeby, które nie są objęte ontologią branży. W takim przypadku rozszerzenie hierarchii umożliwia dalsze korzystanie z ontologii branżowej podczas dostosowywania jej do własnych potrzeb.
W tym artykule omówiono dwa różne przypadki, w których rozszerzenie hierarchii ontologii jest przydatne:
- Dodawanie nowych interfejsów dla pojęć, które nie są częścią ontologii branżowej.
- Dodawanie dodatkowych właściwości, relacji lub składników do istniejących interfejsów.
Dodawanie nowych interfejsów dla nowych pojęć
W takim przypadku chcesz dodać interfejsy dla pojęć potrzebnych dla Twojego rozwiązania, jakie nie są obecne w ontologii branżowej. Jeśli na przykład rozwiązanie ma inne typy pomieszczeń, które nie są reprezentowane w ontologii RealEstateCore opartej na języku DTDL, możesz je dodać, rozszerzając je bezpośrednio z interfejsów RealEstateCore.
W poniższym przykładzie przedstawiono rozwiązanie, które musi reprezentować "pomieszczenia fokusu", które nie są obecne w ontologii RealEstateCore. Pomieszczenie fokusowe to mała przestrzeń przeznaczona dla ludzi, aby skupić się na zadaniu przez kilka godzin naraz.
Aby rozszerzyć ontologię branżową o tę nową koncepcję, utwórz nowy interfejs, który rozszerza interfejsy w ontologii branżowej.
Po dodaniu interfejsu pomieszczenia fokusu rozszerzona hierarchia pokazuje nowy typ pokoju.
Dodawanie dodatkowych możliwości do istniejących interfejsów
W tym przypadku chcesz dodać więcej właściwości, relacji lub komponentów do interfejsów, które są częścią ontologii dotyczącej branży.
W tej sekcji zobaczysz dwa przykłady:
- Jeśli tworzysz rozwiązanie, które wyświetla rysunki 3D przestrzeni, które już posiadasz w istniejącym systemie, możesz skojarzyć każdego cyfrowego bliźniaka z jego rysunkiem 3D (według identyfikatora), aby po wyświetleniu informacji o przestrzeni rozwiązanie mogło również pobrać rysunek 3D z istniejącego systemu.
- Jeśli twoje rozwiązanie musi śledzić stan online/offline sal konferencyjnych, to możesz śledzić go do celów wyświetlania lub zapytań.
Oba przykłady można zaimplementować przy użyciu nowych właściwości: drawingId
właściwości, która kojarzy rysunek 3D z cyfrowym bliźniakiem i właściwością online
wskazującą, czy sala konferencyjna jest online, czy nie.
Zazwyczaj nie chcesz bezpośrednio modyfikować ontologii branżowej, ponieważ chcesz mieć możliwość uwzględnienia aktualizacji w rozwiązaniu w przyszłości (co spowoduje zastąpienie dodatków). Zamiast tego, tego rodzaju dodatki można wprowadzać we własnej hierarchii interfejsu, która rozszerza się z ontologii RealEstateCore opartej na DTDL. Każdy utworzony interfejs używa wielu dziedziczenia interfejsu w celu rozszerzenia nadrzędnego interfejsu RealEstateCore i interfejsu nadrzędnego z rozszerzonej hierarchii interfejsu. Takie podejście umożliwia korzystanie z ontologii branżowej oraz Twoich dodatków razem.
Aby rozszerzyć ontologię branżową, utwórz własne interfejsy, które będą wywodziły się z interfejsów w ontologii branżowej, i dodaj do swoich rozszerzonych interfejsów nowe możliwości. Dla każdego interfejsu, który chcesz rozszerzyć, utwórz nowy interfejs. Interfejsy rozszerzone są zapisywane w języku DTDL (zobacz DTDL dla interfejsów rozszerzonych w dalszej części tego dokumentu).
Po rozszerzeniu części hierarchii pokazanej powyżej rozszerzona hierarchia wygląda jak na poniższym diagramie. Tutaj rozszerzony interfejs przestrzeni dodaje właściwość drawingId
, która będzie zawierać identyfikator kojarzący cyfrowego bliźniaka z rysunkiem 3D. Ponadto interfejs ConferenceRoom dodaje właściwość online
, która będzie określała status online sali konferencyjnej. Dzięki dziedziczeniu interfejs ConferenceRoom zawiera wszystkie możliwości interfejsu RealEstateCore ConferenceRoom i wszystkie możliwości z rozszerzonego interfejsu space.
Nie musisz rozszerzać każdego interfejsu w ontologii branżowej, tylko tych, gdzie potrzebujesz dodać nowe możliwości. Jeśli na przykład musisz dodać nową funkcję, taką jak właściwość interfejsu Hallway, możesz rozszerzyć ten interfejs bez rozszerzania innych interfejsów, które również rozszerzają interfejs Room.
Relacje z interfejsami rozszerzonymi
Interfejsy rozszerzone mogą być również używane jako element docelowy dla relacji, nawet jeśli relacja jest pierwotnie modelowana w celu kierowania na interfejs podstawowy. Na przykład w ontologii RealEstateCore opartej na języku DTDL Interfejs Apartment zawiera relację o nazwie includes, która jest przeznaczona dla Interfejs Room (pokazany na poniższym diagramie). Pozwala to utworzyć graf pomieszczeń, aby stworzyć jego układ.
W oparciu o część hierarchii pokoju z poprzedniej sekcji, cyfrowy bliźniak apartamentu może zawierać bliźniaki typu pokój, a korytarz jest rozszerzeniem pokoju (więc apartament może zawierać korytarze). Oznacza to również, że apartament może zawierać rozszerzony korytarz z nieruchomością arterial
, ponieważ rozszerzony korytarz liczy się jako korytarz, ponieważ odwołuje się do oryginalnych relacji.
Korzystanie z hierarchii przestrzeni rozszerzonej
Podczas tworzenia cyfrowych bliźniaków przy użyciu rozszerzonej hierarchii Space, każdy model cyfrowego bliźniaka będzie pochodził z rozszerzonej hierarchii Przestrzeni (a nie z oryginalnej ontologii branżowej) i będzie zawierać wszystkie możliwości z ontologii branżowej oraz rozszerzone interfejsy poprzez dziedziczenie interfejsów.
Każdy model cyfrowego bliźniaka będzie interfejsem z rozszerzonej hierarchii, przedstawionym na poniższym diagramie.
Podczas wykonywania zapytań dotyczących cyfrowych bliźniaków przy użyciu identyfikatora modelu (operatora IS_OF_MODEL
) należy użyć identyfikatorów modelu z hierarchii rozszerzonej. Na przykład SELECT * FROM DIGITALTWINS WHERE IS_OF_MODEL('dtmi:com:example:Office;1')
.
Wkład w oryginalną ontologię
W niektórych przypadkach rozszerzysz ontologię branżową w sposób, który jest szeroko przydatny dla większości użytkowników ontologii. W takim przypadku rozważ wniesienie wkładu swoich rozszerzeń do oryginalnej ontologii. Każda ontologia ma inny proces współtworzenia, więc sprawdź repozytorium GitHub ontology pod kątem szczegółów współtworzenia.
Nowe interfejsy w języku DTDL
Kod DTDL dla nowych interfejsów, które rozciągają się bezpośrednio od ontologii branżowej, będzie wyglądać następująco.
{
"@id": "dtmi:com:example:FocusRoom;1",
"@type": "interface",
"extends": "dtmi:digitaltwins:rec_3_3:building:Office;1",
"@context": "dtmi:dtdl:context;2"
}
Język DTDL dla interfejsów rozszerzonych
Kod DTDL dla interfejsów rozszerzonych, ograniczony do omówionej powyżej części, wygląda następująco.
[
{
"@id": "dtmi:com:example:Space;1",
"@type": "Interface",
"extends": "dtmi:digitaltwins:rec_3_3:core:Space;1",
"contents": [
{
"@type": "Property",
"name": "drawingid",
"schema": "string"
}
],
"@context": "dtmi:dtdl:context;2"
},
{
"@id": "dtmi:com:example:Room;1",
"@type": "Interface",
"extends": [
"dtmi:digitaltwins:rec_3_3:core:Room;1",
"dtmi:com:example:Space;1"
],
"@context": "dtmi:dtdl:context;2"
},
{
"@id": "dtmi:com:example:ConferenceRoom;1",
"@type": "Interface",
"extends": [
"dtmi:digitaltwins:rec_3_3:building:ConferenceRoom;1",
"dtmi:com:example:Room;1"
],
"contents": [
{
"@type": "Property",
"name": "online",
"schema": "boolean"
}
],
"@context": "dtmi:dtdl:context;2"
},
{
"@id": "dtmi:com:example:Office;1",
"@type": "Interface",
"extends": [
"dtmi:digitaltwins:rec_3_3:building:Office;1",
"dtmi:com:example:Room;1"
],
"@context": "dtmi:dtdl:context;2"
},
{
"@id": "dtmi:com:example:FocusRoom;1",
"@type": "Interface",
"extends": "dtmi:com:example:Office;1",
"@context": "dtmi:dtdl:context;2"
}
]
Następne kroki
Kontynuuj pracę na ścieżce tworzenia modeli w oparciu o ontologie: Pełna ścieżka rozwoju modelu.