Meer informatie over tweelingmodellen en het definiëren ervan in Azure Digital Twins

  • Artikel
  • 17 minuten om te lezen

Een belangrijk kenmerk van Azure Digital Twins is de mogelijkheid om uw eigen vocabulaire te definiëren en uw tweelinggrafiek te bouwen in de zelf gedefinieerde termen van uw bedrijf. Deze mogelijkheid wordt geboden via door de gebruiker geleverde modellen. U kunt modellen zien als zelfstandige naamwoorden in een beschrijving van uw wereld. Azure Digital Twins worden weergegeven in de op JSON LD gebaseerde Digital Twin Definition Language (DTDL).

Een model is vergelijkbaar met een klasse in een objectgeoriënteerde programmeertaal, door een gegevensvorm te definiëren voor één bepaald concept in uw echte werkomgeving. Modellen hebben namen (zoals Room of TemperatureSensor) en bevatten elementen zoals eigenschappen, telemetrie/gebeurtenissen en opdrachten die beschrijven wat dit type entiteit in uw omgeving kan doen. Later gebruikt u deze modellen om digitale tweelingen te maken die specifieke entiteiten vertegenwoordigen die voldoen aan deze typebeschrijving.

Digital Twin Definition Language (DTDL) voor modellen

Modellen voor Azure Digital Twins worden gedefinieerd met behulp van Digital Twins Definition Language (DTDL).

U kunt de volledige taalspecificaties voor DTDL bekijken in GitHub: Digital Twins Definition Language (DTDL) - versie 2. Deze pagina bevat gedetailleerde DTDL-naslag en voorbeelden om u te helpen aan de slag te gaan met het schrijven van uw eigen DTDL-modellen.

DTDL is gebaseerd op JSON-LD en is computertaalonafhankelijk. DTDL is niet exclusief voor Azure Digital Twins, maar wordt ook gebruikt om apparaatgegevens weer te geven in andere IoT-services, zoals IoT Plug en Play. Azure Digital Twins DTDL versie 2 gebruikt (het gebruik van DTDL versie 1 met Azure Digital Twins is nu afgeschaft).

In de rest van dit artikel wordt samengevat hoe de taal wordt gebruikt in Azure Digital Twins.

Azure Digital Twins DTDL-implementaties

Niet alle services die gebruikmaken van DTDL implementeren exact dezelfde functies van DTDL. Er zijn enkele DTDL-functies die Azure Digital Twins momenteel niet ondersteunen, waaronder:

  • DTDL-opdrachten
  • Het writable kenmerk voor eigenschappen of relaties. Hoewel dit kenmerk kan worden ingesteld volgens DTDL-specificaties, wordt de waarde niet gebruikt door Azure Digital Twins. In plaats daarvan worden deze kenmerken altijd behandeld als beschrijfbaar door externe clients met algemene schrijfmachtigingen voor de Azure Digital Twins service.
  • De minMultiplicity eigenschappen en voor maxMultiplicity relaties. Hoewel deze kenmerken kunnen worden ingesteld volgens DTDL-specificaties, worden de waarden niet afgedwongen door Azure Digital Twins.

Een DTDL-model kan alleen compatibel zijn met Azure Digital Twins, maar moet ook voldoen aan de volgende vereisten:

  • Alle DTDL-elementen op het hoogste niveau in een model moeten van het type interface zijn. De reden voor deze vereiste is dat Azure Digital Twins model-API's JSON-objecten kunnen ontvangen die een interface of een matrix van interfaces vertegenwoordigen. Als gevolg hiervan zijn er geen andere DTDL-elementtypen toegestaan op het hoogste niveau.
  • DTDL voor Azure Digital Twins mag geen opdrachten definiëren.
  • Azure Digital Twins staat slechts één niveau van het nesten van onderdelen toe, wat betekent dat een interface die als onderdeel wordt gebruikt, zelf geen onderdelen kan bevatten.
  • Interfaces kunnen niet inline worden gedefinieerd binnen andere DTDL-interfaces; Ze moeten worden gedefinieerd als afzonderlijke entiteiten op het hoogste niveau met hun eigen ID's. Wanneer een andere interface die interface vervolgens wil opnemen als onderdeel of overname, kan deze verwijzen naar de id.

Overzicht van modellen

Elementen van een model

Binnen een modeldefinitie is het code-item op het hoogste niveau een interface. Dit type kapselt het hele model in en de rest van het model wordt gedefinieerd in de interface.

Een DTDL-modelinterface kan nul, één of veel van de volgende velden bevatten:

  • Eigenschap: eigenschappen zijn gegevensvelden die de status van een entiteit vertegenwoordigen (zoals de eigenschappen in veel objectgeoriënteerde programmeertalen). Eigenschappen hebben back-opslag en kunnen op elk moment worden gelezen. Zie Eigenschappen en telemetrie hieronder voor meer informatie.

  • Telemetrie: telemetrievelden vertegenwoordigen metingen of gebeurtenissen en worden vaak gebruikt om metingen van apparaatsensoren te beschrijven. In tegenstelling tot eigenschappen wordt telemetrie niet opgeslagen op een digitale tweeling; Het is een reeks tijdsgebonden gegevensgebeurtenissen die moeten worden verwerkt wanneer ze plaatsvinden. Zie Eigenschappen en telemetrie hieronder voor meer informatie.

  • Relatie: met relaties kunt u laten zien hoe een digitale tweeling kan worden betrokken bij andere digitale tweelingen. Relaties kunnen verschillende semantische betekeniss vertegenwoordigen, zoals contains ('floor contains room'), cools ('hvac cools room'), isBilledTo ('wordt gefactureerd aan gebruiker'), en meer. Met relaties kan de oplossing een grafiek van onderling gerelateerde entiteiten bieden. Relaties kunnen ook eigen eigenschappen hebben. Zie Relaties hieronder voor meer informatie.

  • Onderdeel: met onderdelen kunt u uw modelinterface bouwen als een assembly van andere interfaces, als u wilt. Een voorbeeld van een onderdeel is een frontCamera-interface (en een andere componentinterface backCamera) die worden gebruikt bij het definiëren van een model voor een telefoon. Definieer eerst een interface voor frontCamera alsof het een eigen model is en verwijs er vervolgens naar bij het definiëren van Telefoon.

    Gebruik een onderdeel om iets te beschrijven dat een integraal onderdeel van uw oplossing is, maar geen afzonderlijke identiteit nodig heeft en niet afzonderlijk in de tweelinggrafiek hoeft te worden gemaakt, verwijderd of opnieuw hoeft te worden gesrangeerd. Als u wilt dat entiteiten onafhankelijke bestaan in de tweelinggrafiek hebben, geeft u deze weer als afzonderlijke digitale tweelingen van verschillende modellen, verbonden door relaties.

    Tip

    Onderdelen kunnen ook worden gebruikt voor de organisatie, om sets gerelateerde eigenschappen binnen een modelinterface te groepen. In dit geval kunt u elk onderdeel zien als een naamruimte of map in de interface.

    Zie Onderdelen hieronder voor meer informatie.

Notitie

De specificatie voor DTDL definieert ook Opdrachten . Dit zijn methoden die kunnen worden uitgevoerd op een digitale tweeling (zoals een opdracht voor opnieuw instellen of een opdracht om een ventilator in of uit te schakelen). Opdrachten worden momenteel echter niet ondersteund in Azure Digital Twins.

Modelcode

Dubbeltypemodellen kunnen in elke teksteditor worden geschreven. De DTDL-taal volgt de JSON-syntaxis, dus u moet modellen opslaan met de extensie .json. Als u de JSON-extensie gebruikt, kunnen veel teksteditors voor programmeren basissyntaxis controleren en markeren voor uw DTDL-documenten. Er is ook een DTDL-extensie beschikbaar voor Visual Studio Code.

De velden van het model zijn:

Veld Beschrijving
@id Een id voor het model. Moet de indeling dtmi:<domain>:<unique-model-identifier>;<model-version-number> hebben.
@type Identificeert het soort informatie dat wordt beschreven. Voor een interface is het type Interface.
@context Hiermee stelt u de context voor het JSON-document in. Modellen moeten gebruikmaken van dtmi:dtdl:context;2 .
displayName [optioneel] Geeft u de mogelijkheid om een gebruiksvriendelijke naam voor het model te definiëren.
contents Alle resterende interfacegegevens worden hier geplaatst als een matrix met kenmerkdefinities. Elk kenmerk moet een ( eigenschap @type , telemetrie, opdracht , relatie of onderdeel)bevatten om het type interface-informatie te identificeren dat wordt beschreven, en vervolgens een set eigenschappen die het werkelijke kenmerk definiëren (bijvoorbeeld en om een eigenschap te name schema definiëren).

Voorbeeldmodel

Deze sectie bevat een voorbeeld van een basismodel, geschreven als een DTDL-interface.

Dit model beschrijft een Start, met één eigenschap voor een id. Het model Home definieert ook een relatie met een Floor-model, dat kan worden gebruikt om aan te geven dat een tweeling Thuis is verbonden met bepaalde Floor-tweelingen.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

Eigenschappen en telemetrie

In deze sectie wordt gedetailleerder ingaat op eigenschappen en telemetrie in DTDL-modellen.

Zie Eigenschap in de DTDL v2-specificatievoor een uitgebreide lijst met velden die kunnen worden weergegeven als onderdeel van een eigenschap. Zie Telemetrie in de DTDL v2-specificatievoor een uitgebreide lijst met velden die kunnen worden weergegeven als onderdeel van telemetrie.

Notitie

Het writable DTDL-kenmerk voor eigenschappen wordt momenteel niet ondersteund in Azure Digital Twins. Het kan worden toegevoegd aan het model, maar Azure Digital Twins dit niet afdwingen. Zie DTDL Azure Digital Twins voor meer informatie.

Verschil tussen eigenschappen en telemetrie

Hier zijn enkele richtlijnen voor het conceptueel onderscheid maken tussen DTDL-eigenschap en telemetrie in Azure Digital Twins.

  • Eigenschappen hebben naar verwachting back-opslag, wat betekent dat u een eigenschap op elk moment kunt lezen en de waarde ervan kunt ophalen. Als de eigenschap beschrijfbaar is, kunt u ook een waarde opslaan in de eigenschap .
  • Telemetrie lijkt meer op een stroom gebeurtenissen; Het is een set gegevensberichten met een korte levensduur. Als u het luisteren naar de gebeurtenis en acties die moeten worden ondernomen wanneer deze zich voor doen niet in stelt, is er geen traceer van de gebeurtenis op een later tijdstip. U kunt er niet meer naar teruggaan en later lezen.
    • In C#-termen lijkt telemetrie op een C#-gebeurtenis.
    • In IoT-termen is telemetrie doorgaans één meting die door een apparaat wordt verzonden.

Telemetrie wordt vaak gebruikt met IoT-apparaten, omdat veel apparaten de gegenereerde meetwaarden niet kunnen of niet willen opslaan. In plaats daarvan verzenden ze ze als een stroom 'telemetriegebeurtenissen'. In dit geval kunt u op geen enkel moment een query op het apparaat uitvoeren voor de meest recente waarde van het telemetrieveld. U moet naar de berichten van het apparaat luisteren en actie ondernemen wanneer de berichten binnenkomen.

Als gevolg hiervan gebruikt u bij het ontwerpen van een model in Azure Digital Twins de meeste gevallen waarschijnlijk eigenschappen om uw tweelingen te modelleren. Hierdoor hebt u de back-opslag en de mogelijkheid om de gegevensvelden te lezen en er query's op uit te voeren.

Telemetrie en eigenschappen werken vaak samen om gegevens van apparaten te verwerken. Omdat alle ingressen naar Azure Digital Twins via API's zijn,gebruikt u doorgaans uw ingress-functie om telemetrie- of eigenschapsgebeurtenissen van apparaten te lezen en een eigenschap in te stellen in Azure Digital Twins reactie.

U kunt ook een telemetriegebeurtenis publiceren vanuit de Azure Digital Twins API. Net als bij andere telemetrie is dat een korte gebeurtenis die een listener moet verwerken.

Schema

Volgens DTDL kan het schema voor eigenschaps- en telemetriekenmerken bestaan uit standaard primitieve typen, , , en , en andere integer double string boolean typen, zoals dateTime en duration .

Naast primitieve typen kunnen eigenschaps- en telemetrievelden deze complexe typen hebben:

  • Object
  • Map
  • Enum
  • (alleen telemetrie)Array

Dit kunnen ook semantische typenzijn, waarmee u aantekeningen kunt maken bij waarden met eenheden.

Eenvoudige voorbeelden van eigenschappen en telemetrie

Hier is een eenvoudig voorbeeld van een eigenschap van een DTDL-model. In dit voorbeeld ziet u de id-eigenschap van een Start.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

Hier is een eenvoudig voorbeeld van een telemetrieveld op een DTDL-model. In dit voorbeeld ziet u Temperatuur-telemetrie op een sensor.

{
  "@id": "dtmi:com:adt:dtsample:sensor;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Sensor",
  "contents": [
    {
    "@type": "Telemetry",
    "name": "Temperature",
    "schema": "double"      
    },
    {
      "@type": "Property",
      "name": "humidity",
      "schema": "double"      
    }
  ]
}

Voorbeeld van complex (object)-type

Eigenschappen en telemetrie kunnen complexe typen zijn, waaronder een Object type.

In het volgende voorbeeld ziet u een andere versie van het model Start, met een eigenschap voor het adres. address is een object, met eigen velden voor straat, plaats, staat en zip.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": "Property",
      "name": "address",
      "schema": {
        "@type": "Object",
        "fields": [
          {
            "name": "street",
            "schema": "string"
          },
          {
            "name": "city",
            "schema": "string"
          },
          {
            "name": "state",
            "schema": "string"
          },
          {
            "name": "zip",
            "schema": "string"
          }
        ]
      }
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1",
      "properties": [
        {
          "@type": "Property",
          "name": "lastOccupied",
          "schema": "dateTime"
        }
      ]
    }
  ]
}

Voorbeeld van semantisch type

Semantische typen maken het mogelijk om een waarde met een eenheid uit te drukken. Eigenschappen en telemetrie kunnen worden weergegeven met een van de semantische typen die worden ondersteund door DTDL. Zie Semantische typen in de DTDL v2-specificatie voor meer informatie over semantische typen in DTDL enwelke waarden worden ondersteund.

In het volgende voorbeeld ziet u een sensormodel met een telemetrie van het semantische type voor Temperatuur en een semantische-type-eigenschap voor Vochtigheid.

{
  "@id": "dtmi:com:adt:dtsample:sensor;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Sensor",
  "contents": [
    {
      "@type": ["Telemetry", "Temperature"],
      "name": "temperature",
      "unit": "degreeFahrenheit",
      "schema": "double"      
    },
    {
      "@type": ["Property", "Humidity"],
      "name": "humidity",
      "unit": "gramPerCubicMetre",
      "schema": "double"        
    }
  ]
}

Relaties

In deze sectie wordt gedetailleerder ingaat op relaties in DTDL-modellen.

Zie Relatie in de DTDL v2-specificatievoor een uitgebreide lijst met velden die kunnen worden weergegeven als onderdeel van een relatie.

Notitie

De writable kenmerken , en minMultiplicity maxMultiplicity DTDL voor relaties worden momenteel niet ondersteund in Azure Digital Twins. Ze kunnen worden toegevoegd aan het model, maar Azure Digital Twins worden niet afgedwongen. Zie DTDL-Azure Digital Twins voor meer informatie.

Voorbeeld van een basisrelatie

Hier is een eenvoudig voorbeeld van een relatie op een DTDL-model. In dit voorbeeld ziet u een relatie op een startmodel waarmee deze verbinding kan maken met een Floor-model.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "contents": [
    {
      "@type": "Property",
      "name": "id",
      "schema": "string"     
    },    
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1"
    }
  ]
}

Notitie

Voor relaties @id is een optioneel veld. Als er @id geen is opgegeven, wijst de digital twin-interfaceprocessor er een toe.

Gerichte en niet-gerichte relaties

Relaties kunnen worden gedefinieerd met of zonder een doel. Een doel geeft aan welke typen dubbel de relatie kan bereiken. U kunt bijvoorbeeld een doel opnemen om op te geven dat een startmodel alleen een rel_has_floors relatie met tweelingen die Floor-tweelingen zijn.

Soms wilt u een relatie definiëren zonder een specifiek doel, zodat de relatie verbinding kan maken met veel verschillende typen tweelingen.

Hier ziet u een voorbeeld van een relatie op een DTDL-model dat geen doel heeft. In dit voorbeeld is de relatie voor het definiëren van de sensoren die een ruimte kan hebben en de relatie kan verbinding maken met elk type.

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": ["Property", "Humidity"],
      "name": "humidity",
      "unit": "gramPerCubicMetre",
      "schema": "double"
    },
    {
      "@type": "Component",
      "name": "thermostat",
      "schema": "dtmi:com:adt:dtsample:thermostat;1"
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:room:rel_has_sensors;1",
      "name": "rel_has_sensors",
      "displayName": "Room has sensors"
    }
  ]
},

Eigenschappen van relaties

Met DTDL kunnen relaties ook hun eigen eigenschappen hebben. Wanneer u een relatie in een DTDL-model definieert, kan de relatie een eigen veld hebben waarin u aangepaste eigenschappen kunt definiëren om de relatiespecifieke properties status te beschrijven.

In het volgende voorbeeld ziet u een andere versie van het model Start, waarbij de relatie een eigenschap heeft die vertegenwoordigt wanneer de gerelateerde Floor voor het laatst rel_has_floors bezet was.

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {
      "@type": "Property",
      "name": "address",
      "schema": {
        "@type": "Object",
        "fields": [
          {
            "name": "street",
            "schema": "string"
          },
          {
            "name": "city",
            "schema": "string"
          },
          {
            "name": "state",
            "schema": "string"
          },
          {
            "name": "zip",
            "schema": "string"
          }
        ]
      }
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:com:adt:dtsample:home:rel_has_floors;1",
      "name": "rel_has_floors",
      "displayName": "Home has floors",
      "target": "dtmi:com:adt:dtsample:floor;1",
      "properties": [
        {
          "@type": "Property",
          "name": "lastOccupied",
          "schema": "dateTime"
        }
      ]
    }
  ]
}

Onderdelen

In deze sectie wordt gedetailleerder ingaat op onderdelen in DTDL-modellen.

Zie Component in de DTDL v2-specificatievoor een uitgebreide lijst met velden die als onderdeel van een onderdeel kunnen worden weergegeven.

Voorbeeld van basisonderdeel

Hier is een eenvoudig voorbeeld van een onderdeel in een DTDL-model. In dit voorbeeld ziet u een Room-model dat gebruik maakt van een thermostaatmodel als onderdeel.

[
  {
    "@id": "dtmi:com:adt:dtsample:room;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Room",
    "extends": "dtmi:com:adt:dtsample:core;1",
    "contents": [
      {
        "@type": ["Property", "Humidity"],
        "name": "humidity",
        "unit": "gramPerCubicMetre",
        "schema": "double"
      },
      {
        "@type": "Component",
        "name": "thermostat",
        "schema": "dtmi:com:adt:dtsample:thermostat;1"
      },
      {
        "@type": "Relationship",
        "@id": "dtmi:com:adt:dtsample:room:rel_has_sensors;1",
        "name": "rel_has_sensors",
        "displayName": "Room has sensors"
      }
    ]
  },
  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:com:adt:dtsample:thermostat;1",
    "@type": "Interface",
    "displayName": "thermostat",
    "contents": [
      {
        "@type": ["Property", "Temperature"],
        "name": "temperature",
        "unit": "degreeFahrenheit",
        "schema": "double"
      }
    ]
  }
]

Als andere modellen in deze oplossing ook een thermostaat moeten bevatten, kunnen ze verwijzen naar hetzelfde thermostaatmodel als een onderdeel in hun eigen definities, net zoals Room dat doet.

Belangrijk

De onderdeelinterface (thermostaat in het bovenstaande voorbeeld) moet worden gedefinieerd in dezelfde matrix als alle interfaces die de interface gebruiken (Room in het bovenstaande voorbeeld) om de onderdeelverwijzing te kunnen vinden.

Model overname

Soms wilt u misschien een model verder specialiseren. Het kan bijvoorbeeld handig zijn om een algemeen model Room en gespecialiseerde varianten ConferenceRoom en ConferenceRoom and Wilt te hebben. Om specialisatie uit te drukken, ondersteunt DTDL overname. Interfaces kunnen overnemen van een of meer andere interfaces. U kunt dit doen door een veld aan extends het model toe te voegen.

De sectie is een interfacenaam of een matrix met interfacenamen (zodat de uitbreidbare interface kan extends worden overgenomen van meerdere bovenliggende modellen). Eén bovenliggend model kan fungeren als het basismodel voor meerdere uitbreidbare interfaces.

In het volgende voorbeeld wordt het startmodel uit het eerdere DTDL-voorbeeld opnieuw voorgesteld als een subtype van een groter kernmodel. Het bovenliggende model (Core) wordt eerst gedefinieerd en vervolgens bouwt het onderliggende model (Start) daarop voort met behulp van extends .

{
    "@id": "dtmi:com:adt:dtsample:core;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Core",
    "contents": [
        {
            "@type": "Property",
            "name": "id",
            "schema": "string"
        },
        {
            "@type": "Property",
            "name": "name",
            "schema": "string"
        }
    ]
}

{
  "@id": "dtmi:com:adt:dtsample:home;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Home",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {

In dit geval draagt Core een id en naam bij aan Start. Andere modellen kunnen ook het Core-model uitbreiden om deze eigenschappen op te halen. Hier ziet u een Room-model dat dezelfde bovenliggende interface uitbreidt:

{
  "@id": "dtmi:com:adt:dtsample:room;1",
  "@type": "Interface",
  "@context": "dtmi:dtdl:context;2",
  "displayName": "Room",
  "extends": "dtmi:com:adt:dtsample:core;1",
  "contents": [
    {

Zodra overname is toegepast, worden alle eigenschappen van de gehele overnameketen door de uitbreidingsinterface gebruikt.

De uitbreidingsinterface kan geen van de definities van de bovenliggende interfaces wijzigen; het kan er alleen aan toevoegen. Het kan ook een mogelijkheid die al is gedefinieerd in een van de bovenliggende interfaces niet opnieuw definiëren (zelfs niet als de mogelijkheden zijn gedefinieerd als dezelfde). Als een bovenliggende interface bijvoorbeeld een eigenschaps massa definieert, kan de uitbreidbare interface geen declaratie van massa bevatten, zelfs niet als het ook double een double is.

Best practices voor modellering

Bij het ontwerpen van modellen die de entiteiten in uw omgeving weerspiegelen, kan het handig zijn om vooruit te kijken en na te denken over de gevolgen van uw ontwerp voor query's. Mogelijk wilt u eigenschappen zo ontwerpen dat grote resultatensets worden voorkomen door het doorkruisen van grafen. U kunt ook relaties modelleren die in één query moeten worden beantwoord als relaties met één niveau.

Modellen valideren

Tip

Nadat u een model hebt gemaakt, is het raadzaam om uw modellen offline te valideren voordat u ze uploadt naar Azure Digital Twins exemplaar.

Er is een taalagnostische DTDL-validatievoorbeeld voor het valideren van modeldocumenten om ervoor te zorgen dat de DTDL juist is voordat u deze uploadt naar uw exemplaar.

Het DTDL-validatievoorbeeld is gebaseerd op een .NET DTDL-parserbibliotheek die beschikbaar is op NuGet als bibliotheek aan de clientzijde: Microsoft.Azure.DigitalTwins.Parser. U kunt de bibliotheek ook rechtstreeks gebruiken om uw eigen validatieoplossing te ontwerpen. Wanneer u de parserbibliotheek gebruikt, moet u ervoor zorgen dat u een versie gebruikt die compatibel is met de versie die Azure Digital Twins wordt uitgevoerd. Dit is momenteel versie 3.12.4.

Meer informatie over het validatievoorbeeld en de parserbibliotheek, inclusief gebruiksvoorbeelden, vindt u in Modellen parseren en valideren.

Hulpprogramma's voor modelleren

Er zijn verschillende voorbeelden beschikbaar om het nog gemakkelijker te maken om te gaan met modellen en ontologieën. Ze bevinden zich in deze opslagplaats: Tools for Digital Twins Definition Language (DTDL).

In deze sectie wordt de huidige set voorbeelden gedetailleerder beschreven.

Modeluploader

Wanneer u klaar bent met het maken, uitbreiden of selecteren van uw modellen, kunt u ze uploaden naar uw Azure Digital Twins-exemplaar om ze beschikbaar te maken voor gebruik in uw oplossing. U kunt dit doen met behulp van de Azure Digital Twins API's, zoals beschreven in DTDL-modellen beheren.

Als u echter veel modellen moet uploaden, of als ze veel onderlinge afhankelijkheden hebben die het ordenen van afzonderlijke uploads gecompliceerd maken, kunt u het voorbeeld Azure Digital Twins Model Uploader gebruiken om veel modellen tegelijk te uploaden. Volg de instructies in het voorbeeld om dit project te configureren en te gebruiken om modellen te uploaden naar uw eigen exemplaar.

Modelvisualiseerder

Zodra u modellen hebt geüpload naar uw Azure Digital Twins-exemplaar, kunt u de modellen in uw Azure Digital Twins-exemplaar weergeven, inclusief overname- en modelrelaties, met behulp van de Azure Digital Twins Model Visualizer. Dit voorbeeld heeft momenteel de status Concept. We raden de community voor digital twins-ontwikkeling aan om het voorbeeld uit te breiden en hieraan bij te dragen.

Volgende stappen