Architectuurbenaderingen voor IoT in een multitenant-oplossing

Multitenant IoT-oplossingen zijn in veel verschillende smaken en maten. Mogelijk hebt u veel vereisten en beperkingen, variërend van eigendom van de infrastructuur, tot isolatie van klantgegevens tot naleving. Het kan lastig zijn om een patroon te definiëren dat voldoet aan al deze ontwerpbeperkingen. Hiervoor moet vaak rekening worden gehouden met meerdere dimensies. In dit artikel worden verschillende benaderingen beschreven die vaak worden gebruikt voor het oplossen van multitenancy-overwegingen voor IoT-oplossingen. Dit document bevat voorbeelden van multitenant-architecturen die gebruikmaken van algemene onderdelen, volgens de IoT-referentiearchitectuur.

Belangrijke overwegingen en vereisten

Deze overwegingen en vereisten worden weergegeven in de volgorde waarin ze doorgaans worden geprioriteerd voor het ontwerp van een oplossing.

Governance en naleving

Governance- en nalevingsoverwegingen vereisen mogelijk dat u een bepaald patroon of een bepaalde set IoT-resources gebruikt. Niet alle IoT-services hebben dezelfde certificeringen of mogelijkheden. Als u moet voldoen aan specifieke nalevingsstandaarden, moet u mogelijk specifieke services selecteren. Informatie over governance en naleving wordt behandeld in een specifiek artikel over dat onderwerp.

Governance in IoT kan ook aanvullende vormen aannemen, zoals apparaateigendom en -beheer. Is de klant eigenaar van het apparaat of is de oplossingsprovider? Wie is eigenaar van het beheer van deze apparaten? Deze overwegingen en implicaties zijn uniek voor elke oplossingsprovider en kunnen leiden tot verschillende keuzes in de technologie, het implementatiepatroon en het multitenancypatroon dat u gebruikt.

Schaal wijzigen

Het is belangrijk om de schaal van uw oplossing te plannen. Schaal wordt vaak overwogen in deze drie dimensies:

• Aantal apparaten: Alle Azure-apparaatbeheerservices - Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) en Azure IoT Hub : hebben beperkingen voor het aantal apparaten dat in één instantie wordt ondersteund.

  Tip

  Raadpleeg de documentatie op grote schaal als u van plan bent een zeer groot aantal apparaten te implementeren.

• Apparaatdoorvoer: verschillende apparaten, zelfs in dezelfde oplossing, kunnen verschillende doorvoervereisten hebben. 'Doorvoer' in deze context verwijst naar zowel het aantal berichten gedurende een bepaalde periode als de grootte van de berichten. In een slimme oplossing zullen thermostaten bijvoorbeeld waarschijnlijk gegevens rapporteren met een lagere frequentie dan liften, terwijl in een oplossing voor verbonden voertuigen de cameragegevensberichten waarschijnlijk groter zijn dan navigatietelemetrieberichten. Als uw berichten worden beperkt met betrekking tot frequentie, moet u mogelijk uitschalen naar meer exemplaren van een bepaalde service, maar als ze worden beperkt met betrekking tot de grootte, moet u mogelijk omhoog schalen naar grotere exemplaren van een bepaalde service.

• Tenants: de schaal van één tenant kan klein zijn, maar wanneer dit wordt vermenigvuldigd met het aantal tenants, kan deze snel groeien.

Prestaties en betrouwbaarheid

Isolatie van tenants

Volledig gedeelde oplossingen kunnen luidruchtige buren hebben. In het geval van IoT Hub en IoT Central kan dit leiden tot HTTP 429-antwoordcodes ('Te veel aanvragen') die harde fouten kunnen veroorzaken die een trapsgewijs effect kunnen veroorzaken. Zie Quota en beperking voor meer informatie.

In volledig multitenant-oplossingen kunnen deze effecten trapsgewijs worden gebruikt. Wanneer klanten IoT Hubs- of IoT Central-toepassingen delen, ontvangen alle klanten in de gedeelde infrastructuur fouten. Omdat IoT Hub en IoT Central vaak de toegangspunten zijn voor gegevens naar de cloud, zullen andere downstreamsystemen die afhankelijk zijn van deze gegevens waarschijnlijk ook mislukken. Vaak komt dit het meest voor wanneer een quotumlimiet voor berichten is overschreden. In dit geval is de snelste en eenvoudigste oplossing voor IoT Hub-oplossingen het upgraden van de IoT Hub-SKU, het aantal IoT Hub-eenheden of beide verhogen. Voor IoT Central-oplossingen wordt de schaal van de oplossing automatisch aangepast tot het gedocumenteerde aantal ondersteunde berichten.

U kunt tenants isoleren en distribueren over de IoT-besturings-, beheer- en communicatievlakken met behulp van het aangepaste toewijzingsbeleid van DPS. Verder kunt u, wanneer u de richtlijnen voor grootschalige IoT-oplossingen volgt, extra toewijzingsdistributie beheren op dps-load balancer-niveau.

Gegevensopslag, query, gebruik en retentie

IoT-oplossingen zijn meestal zeer gegevensintensief, zowel bij streaming als at-rest. Zie Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingen voor meer informatie over het beheren van gegevens in oplossingen met meerdere tenants.

Beveiliging

IoT-oplossingen hebben vaak beveiligingsoverwegingen op meerdere lagen, met name in oplossingen die zijn geïmplementeerd in een in de cloud gewijzigde Purdue Enterprise Reference Architecture of Industry 4.0-oplossingen . De ontwerpbenadering die hieronder is geselecteerd, heeft invloed op de netwerklagen en grenzen; zodra het fysieke ontwerp is geselecteerd, kan de beveiligingsmplementatie worden geselecteerd. Hulpprogramma's die in elke benadering kunnen worden gebruikt, zijn onder andere:

• Microsoft Defender voor IoT, een uitgebreide IoT-bewakingsoplossing die u moet overwegen, biedt een EIoT-licentie per apparaat en OT-sitelicenties voor elk klantapparaat en/of elke site. Afhankelijk van de methode die verderop in dit artikel is geselecteerd, is het microsoft 365-licentiescenario met de naam gebruikerslicentie mogelijk niet mogelijk. In dat geval zijn de licentieopties per apparaat en site beschikbaar. Dit zijn licentieopties onafhankelijk van Microsoft 365-tenantlicenties.

• Azure Firewall of een firewallapparaat van derden, waarmee u rekening moet houden bij het isoleren van de netwerklagen en het bewaken van netwerkverkeer. De exacte keuze van de aanpak is van invloed op waar workloads netwerkisolatie hebben versus een gedeeld netwerk, zoals hieronder wordt behandeld.

• Azure IoT Edge of Azure IoT Operations, waarmee u rekening moet houden als onderdeel van apparaatconnectiviteit met door Azure gehoste services zonder dat apparaten rechtstreeks toegang tot internet krijgen. Aangezien Azure IoT Operations op dit moment in preview is, wordt in dit document het gebruik van die aanbieding in het algemeen niet beschreven. In een toekomstige revisie van dit document wordt dit aangepakt.

De meeste van deze beveiligingsonderwerpen zijn van toepassing in een multitenant-oplossing die vergelijkbaar is met de manier waarop ze zich in één tenantoplossing zouden bevinden, met de variaties die zijn gekoppeld aan de geselecteerde benadering. Een onderdeel dat waarschijnlijk aanzienlijk verschilt in een algemene IoT-oplossing is de gebruikers- en toepassingsidentiteit. Architectuurbenaderingen voor identiteit in multitenant-oplossingen bespreken dit aspect van een algemene multitenant-oplossing.

Methoden om rekening mee te houden

Alle overwegingen die u normaal gesproken zou maken in een IoT-architectuur, voor alle primaire onderdelen (zoals beheer, opname, verwerking, opslag, beveiliging, enzovoort), zijn alle keuzes die u nog moet maken bij het uitvoeren van een multitenant-oplossing. Het belangrijkste verschil is hoe u de onderdelen rangschikt en gebruikt om multitenancy te ondersteunen. Veelvoorkomende beslissingspunten voor opslag kunnen bijvoorbeeld bepalen of u SQL Server of Azure Data Explorer wilt gebruiken, of misschien op de opname- en beheerlaag, moet u kiezen tussen IoT Hub en IoT Central.

De meeste IoT-oplossingen passen binnen een hoofdarchitectuurpatroon. Dit is een combinatie van het implementatiedoel, het tenancymodel en het implementatiepatroon. Deze factoren worden bepaald door de belangrijkste vereisten en overwegingen die hierboven worden beschreven.

Een van de grootste beslissingspunten die moeten worden genomen, binnen de IoT-ruimte, is om te kiezen tussen een PaaS-benadering (platform-as-a-service) en paaS-benaderingen (platform-as-a-service). Zie IoT-oplossingsmethoden (Internet of Things) vergelijken (PaaS versus aPaaS) voor meer informatie.

Dit is het veelvoorkomende 'build vs. buy'-dilemma waarmee veel organisaties te maken hebben in veel projecten. Het is belangrijk om de voor- en nadelen van beide opties te evalueren.

Concepten en overwegingen voor aPaaS-oplossingen

Een typische aPaaS-oplossing die Gebruikmaakt van Azure IoT Central, als kern van de oplossing, kan gebruikmaken van de volgende Azure PaaS- en aPaaS-services:

• Azure Event Hubs als een platformoverschrijdende, hoogwaardige berichten- en gegevensstroomengine.
• Azure Logic Apps als een integratieplatform-as-a-service of iPaaS-aanbieding.
• Azure Data Explorer als een data analytics-platform.
• Power BI als visualisatie- en rapportageplatform.

In het vorige diagram delen de tenants een IoT Central-omgeving, Azure Data Explorer, Power BI en Azure Logic Apps.

Deze aanpak is over het algemeen de snelste manier om een oplossing op de markt te krijgen. Het is een grootschalige service die ondersteuning biedt voor multitenancy door organisaties te gebruiken.

Het is belangrijk te begrijpen dat er, omdat IoT Central een aPaaS-aanbieding is, bepaalde beslissingen buiten het beheer van een implementeerfunctie vallen. Deze beslissingen omvatten:

• IoT Central gebruikt Microsoft Entra ID als id-provider.
• IoT Central-implementaties worden bereikt met behulp van besturings- en gegevensvlakbewerkingen, die declaratieve documenten combineren met imperatieve code.
• In een patroon met meerdere tenants kunnen zowel de maximale knooppuntlimiet van IoT Central (die van toepassing is op zowel boven- als verlof) en de maximale structuurdiepte, ertoe leiden dat een serviceprovider meerdere IoT Central-exemplaren heeft. In dat geval moet u overwegen het patroon Implementatiestempel te volgen.
• IoT Central legt API-aanroeplimieten op, wat van invloed kan zijn op grote implementaties.

Concepten en overwegingen voor PaaS-oplossingen

Een op PaaS gebaseerde benadering kan gebruikmaken van de volgende Azure-services:

• Azure IoT Hub als het belangrijkste apparaatconfiguratie- en communicatieplatform.
• Azure IoT Device Provisioning Service als de implementatie van het apparaat en het eerste configuratieplatform.
• Azure Data Explorer voor het opslaan en analyseren van tijdreeksgegevens van warme en koude paden van IoT-apparaten.
• Azure Stream Analytics voor het analyseren van hot path-gegevens van IoT-apparaten.
• Azure IoT Edge voor het uitvoeren van kunstmatige intelligentie (AI), services van derden of uw eigen bedrijfslogica op IoT Edge-apparaten.

In het vorige diagram maakt elke tenant verbinding met een gedeelde web-app, die gegevens ontvangt van IoT Hubs en een functie-app. Apparaten maken verbinding met Device Provisioning Service en ioT Hubs.

Deze aanpak vereist meer inspanningen van ontwikkelaars om de oplossing te maken, te implementeren en te onderhouden (versus een aPaaS-benadering). Er zijn minder mogelijkheden vooraf gebouwd voor het gemak van de implementeerfunctie. Dit betekent dat deze aanpak ook meer controle biedt, omdat er minder veronderstellingen zijn ingesloten in het onderliggende platform.

Hoofdarchitectuurpatronen

De volgende tabel bevat algemene patronen voor multitenant IoT-oplossingen. Elk patroon bevat de volgende informatie:

• De naam van het patroon, dat is gebaseerd op de combinatie van het doel, model en implementatietype.
• Het implementatiedoel, dat het Azure-abonnement vertegenwoordigt voor het implementeren van resources.
• Het Tenancy-model waarnaar wordt verwezen door het patroon, zoals beschreven in Multitenancy-modellen
• Het implementatiepatroon, die verwijst naar een eenvoudige implementatie met minimale implementatieoverwegingen, een geode-patroon of een patroon implementatiestempel.

Patroon	Implementatiedoel	Tenancymodel	Implementatiepatroon
Eenvoudige SaaS	Abonnement van serviceprovider	Volledig multitenant	Eenvoudig
Horizontale SaaS	Abonnement van serviceprovider	Horizontaal gepartitioneerd	Implementatiestempel
Geautomatiseerde één tenant	Abonnement van serviceprovider of klant	Eén tenant per klant	Eenvoudig

Eenvoudige SaaS

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider	Volledig multitenant	Eenvoudig

De eenvoudige SaaS-benadering is de eenvoudigste implementatie voor een SaaS IoT-oplossing. Zoals in het vorige diagram wordt weergegeven, wordt alle infrastructuur gedeeld en is er geen geografische of schaalstempel toegepast op de infrastructuur. Vaak bevindt de infrastructuur zich binnen één Azure-abonnement.

Azure IoT Central ondersteunt het concept van organisaties. Organisaties stellen een oplossingsprovider in staat om tenants eenvoudig te scheiden op een veilige, hiërarchische manier, terwijl het basistoepassingsontwerp wordt gedeeld in alle tenants.

Communicatie met systemen buiten IoT Central, zoals voor gegevensanalyse op langere termijn, langs een koud pad of connectiviteit met bedrijfsactiviteiten, wordt uitgevoerd via andere Microsoft PaaS- en aPaaS-aanbiedingen. Deze aanvullende aanbiedingen kunnen de volgende services omvatten:

• Azure Event Hubs als een platformoverschrijdende engine voor berichten en gegevensstromen op bedrijfsniveau.
• Azure Logic Apps als een integratieplatform als een service of iPaaS.
• Azure Data Explorer als een data analytics-platform.
• Power BI als visualisatie- en rapportageplatform.

Als u de eenvoudige SaaS-benadering vergelijkt met het geautomatiseerde aPaaS-model met één tenant, zijn veel kenmerken vergelijkbaar. Het belangrijkste verschil tussen de twee modellen is dat u in het geautomatiseerde model met één tenant een afzonderlijk IoT Central-exemplaar implementeert voor elke tenant, terwijl u in het Eenvoudige SaaS-model met aPaaS een gedeeld exemplaar voor meerdere klanten implementeert en u een IoT Central-organisatie voor elke tenant maakt.

Wanneer u een gegevenslaag met meerdere tenants in dit model deelt, moet u beveiliging op rijniveau implementeren, zoals beschreven in architectuurmethoden voor opslag en gegevens in multitenant-oplossingen om de klantgegevens te isoleren.

Voordelen:

• Eenvoudiger te beheren en te gebruiken ten opzichte van de andere benaderingen die hier worden gepresenteerd.

Risico's:

• Deze benadering kan niet eenvoudig worden geschaald naar zeer grote aantallen apparaten, berichten of tenants.

• Omdat alle services en onderdelen worden gedeeld, kan een fout in elk onderdeel van invloed zijn op al uw tenants. Dit is een risico voor de betrouwbaarheid en hoge beschikbaarheid van uw oplossing.

• Het is belangrijk om na te denken over hoe u de naleving, bewerkingen, de levenscyclus van de tenant en de beveiliging van subvloten van apparaten beheert. Deze overwegingen worden belangrijk vanwege de gedeelde aard van dit oplossingstype op de besturings-, beheer- en communicatievlakken.

Horizontale SaaS

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider	Horizontaal gepartitioneerd	Implementatiestempel

Een algemene schaalbaarheidsbenadering is het horizontaal partitioneren van de oplossing. Dit betekent dat u een aantal gedeelde onderdelen en enkele onderdelen per klant hebt.

Binnen een IoT-oplossing zijn er veel onderdelen die horizontaal kunnen worden gepartitioneerd. De horizontaal gepartitioneerde subsystemen worden doorgaans gerangschikt met behulp van een implementatiestempelpatroon dat kan worden geïntegreerd met de grotere oplossing.

Voorbeeld van horizontale SaaS

Het onderstaande architectuurvoorbeeld partitioneert IoT Central per eindklant, die fungeert als de portal voor apparaatbeheer, apparaatcommunicatie en beheer. Dit wordt vaak gedaan op een zodanige manier dat de eindklant die de oplossing gebruikt volledige controle heeft over het toevoegen, verwijderen en bijwerken van apparaten zelf, zonder tussenkomst van de softwareleverancier. De rest van de oplossing volgt een standaardpatroon voor gedeelde infrastructuur, dat oplossing biedt voor hot path-analyse, bedrijfsintegraties, SaaS-beheer en apparaatanalysebehoeften.

Elke tenant heeft een eigen IoT Central-organisatie, die telemetrie verzendt naar een gedeelde functie-app en deze beschikbaar maakt voor de zakelijke gebruikers van de tenants via een web-app.

Voordelen:

• Over het algemeen eenvoudig te beheren en te bedienen, hoewel extra beheer vereist kan zijn voor onderdelen met één tenant.
• Flexibele schaalopties, omdat lagen zo nodig worden geschaald.
• De impact van onderdeelfouten wordt verminderd. Hoewel een storing van een gedeeld onderdeel van invloed is op alle klanten, hebben horizontaal geschaalde onderdelen alleen invloed op de klanten die zijn gekoppeld aan specifieke schaalexemplaren.
• Verbeterde inzichten per tenantverbruik voor gepartitioneerde onderdelen.
• Gepartitioneerde onderdelen bieden eenvoudiger aanpassingen per tenant.

Risico's:

• Houd rekening met de schaal van de oplossing, met name voor gedeelde onderdelen.
• Betrouwbaarheid en hoge beschikbaarheid worden mogelijk beïnvloed. Een enkele fout in de gedeelde onderdelen kan van invloed zijn op alle tenants tegelijk.
• Voor het aanpassen van gepartitioneerde onderdelen per tenant zijn devOps en beheeroverwegingen voor de lange termijn vereist.

Hieronder ziet u de meest voorkomende onderdelen die doorgaans geschikt zijn voor horizontale partitionering.

Databases

U kunt ervoor kiezen om de databases te partitioneren. Vaak zijn het de telemetrie- en apparaatgegevensarchieven die zijn gepartitioneerd. Vaak worden meerdere gegevensarchieven gebruikt voor verschillende specifieke doeleinden, zoals warme en archiveringsopslag, of voor informatie over de status van tenancyabonnementen.

Scheid de databases voor elke tenant voor de volgende voordelen:

• Ondersteuning voor nalevingsstandaarden. De gegevens van elke tenant worden geïsoleerd in exemplaren van het gegevensarchief.
• Problemen met lawaaierige buren oplossen.

Apparaatbeheer, communicatie en beheer

Azure IoT Hub Device Provisioning Service-, IoT Hub- en IoT Central-toepassingen kunnen vaak worden geïmplementeerd als horizontaal gepartitioneerde onderdelen. Als u deze aanpak volgt, moet u een extra service hebben om apparaten om te leiden naar de juiste Device Provisioning Service voor het beheer, de controle en het telemetrievlak van die specifieke tenant. Zie het technisch document over het uitschalen van een Azure IoT-oplossing ter ondersteuning van miljoenen apparaten voor meer informatie.

Dit wordt vaak gedaan om de eindklanten in staat te stellen hun eigen vloot apparaten te beheren en beheren die directer en volledig geïsoleerd zijn.

Als het communicatievlak van het apparaat horizontaal is gepartitioneerd, moeten telemetriegegevens worden verrijkt met gegevens voor de brontenant, zodat de streamprocessor weet welke tenantregels moeten worden toegepast op de gegevensstroom. Als een telemetriebericht bijvoorbeeld een melding genereert in de streamprocessor, moet de streamprocessor het juiste meldingspad voor de gekoppelde tenant bepalen.

Stroomverwerking

Door streamverwerking te partitioneren, schakelt u aanpassingen per tenant in van de analyse binnen de streamprocessors.

Geautomatiseerde één tenant

Een geautomatiseerde benadering met één tenant is gebaseerd op een soortgelijk beslissingsproces en ontwerp voor een bedrijfsoplossing.

Elke tenant heeft een eigen identieke, geïsoleerde omgeving, met een IoT Central-organisatie en andere onderdelen die eraan zijn toegewezen.

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider of klant	Eén tenant per klant	Eenvoudig

Een kritiek beslissingspunt in deze benadering is het kiezen van welk Azure-abonnement de onderdelen moeten worden geïmplementeerd. Als de onderdelen zijn geïmplementeerd in uw abonnement, hebt u meer controle en beter inzicht in de kosten van de oplossing, maar moet u meer van de beveiligings- en governanceproblemen van de oplossing hebben. Als de oplossing echter wordt geïmplementeerd in het abonnement van uw klant, is de klant uiteindelijk verantwoordelijk voor de beveiliging en governance van de implementatie.

Dit patroon ondersteunt een hoge mate van schaalbaarheid. Dit komt doordat tenant- en abonnementsvereisten over het algemeen de beperkende factoren in de meeste oplossingen zijn. Isoleer daarom elke tenant om een groot bereik te bieden voor het schalen van de workload van elke tenant, zonder dat u hiervoor aanzienlijke inspanningen hoeft uit te voeren als oplossingsontwikkelaar.

Dit patroon heeft doorgaans ook een lage latentie, in vergelijking met andere patronen, omdat u de oplossingsonderdelen kunt implementeren op basis van de geografie van uw klanten. Geografische affiniteit maakt kortere netwerkpaden mogelijk tussen een IoT-apparaat en uw Azure-implementatie.

Indien nodig kunt u de geautomatiseerde implementatie uitbreiden ter ondersteuning van verbeterde latentie of schaal, door de snelle implementatie van extra exemplaren van de oplossing toe te staan voor een klant in bestaande of nieuwe geografische gebieden.

De geautomatiseerde benadering met één tenant is vergelijkbaar met het eenvoudige SaaS aPaaS-model. Het belangrijkste verschil tussen de twee modellen is dat u in de geautomatiseerde benadering met één tenant een afzonderlijk IoT Central-exemplaar voor elke tenant implementeert, terwijl u in de eenvoudige SaaS met eenPaaS-model een gedeeld exemplaar van IoT Central implementeert met meerdere IoT Central-organisaties.

Voordelen:

• Relatief eenvoudig te beheren en te bedienen.
• Tenantisolatie is in feite gegarandeerd.

Risico's:

• Initiële automatisering kan ingewikkeld zijn voor nieuwe ontwikkelmedewerkers.
• Beveiliging van referenties voor meerdere klanten voor implementatiebeheer op een hoger niveau moet worden afgedwongen, of de compromissen kunnen worden uitgebreid tussen klanten.
• De kosten zullen naar verwachting hoger zijn, omdat de schaalvoordelen van een gedeelde infrastructuur voor klanten niet beschikbaar zijn.
• Als de oplossingsprovider eigenaar is van het onderhoud van elk exemplaar, hebt u mogelijk veel exemplaren die u moet onderhouden.

De schaal van SaaS vergroten

Wanneer u de schaal van een oplossing uitbreidt tot zeer grote implementaties, zijn er specifieke uitdagingen die zich voordoen op basis van servicelimieten, geografische problemen en andere factoren. Zie Een Azure IoT-oplossing uitschalen ter ondersteuning van miljoenen apparaten voor meer informatie over grootschalige IoT-implementatiearchitecturen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

• Michael C. Bazarewsky | Senior klanttechnicus, FastTrack voor Azure
• David Crook | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

• John Downs | Principal Software Engineer
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Volgende stappen

• Bekijk de richtlijnen voor multitenancy en Azure Cosmos DB.
• Meer informatie over dynamische, warme en koude gegevenspaden met IoT in Azure.
• Raadpleeg de Azure IoT-referentiearchitecturen.