Dela via

Närvarosensorer (mänsklig närhet)

I följande avsnitt beskrivs riktlinjer för OEM-tillverkare som väljer komponenter, till exempel närvarosensorer för att stödja inkorgens enhetsupplevelser som beskrivs ovan. Den omfattar båda de allmänna kraven för alla sensorer utöver den specifika vägledningen för specifika enhetsupplevelser. Närvarosensorer är närhetssensorer av typen "Human". Granska enhetsupplevelser och villkor för närvaroavkänning innan du läser det här avsnittet.

Det här avsnittet är avsett att ge vägledning för OEM-tillverkare som vill installera närvarosensormaskinvara i ett system. Dessa riktlinjer representerar en minsta fungerande sensorkonfiguration. Microsoft uppmuntrar installation av maskinvara som överträffar standarderna här.

Intervallet, svarstiden, avståndet och kraften mäts inte av Microsoft, men OEM-tillverkare och ODM:er bör verifiera funktioner i enlighet med HLK-kraven. Om systemet rapporterar avstånd ska dess noggrannhet mätas.

Viktig designinformation och allmänna krav för alla mänskliga närvarosensorer

Om en närhetssensor stöder mänsklig närvaro måste den stödja identifieringstypen:

DEFINE_PROPERTYKEY(DEVPKEY_Sensor_HumanPresenceDetectionType,0xd4247382, 0x969d, 0x4f24, 0xbb, 0x14, 0xfb, 0x96, 0x71, 0x87, 0xb, 0xbf, 81); //[VT_UI4]

För närvarande finns definierade identifieringstyper nedan:

Användningsnamn Användningstyp Användningsbeskrivning
Identifieringstyp för mänsklig närvaro: Leverantörsdefinierad icke-biometrisk Salt Närvaro (av en eller flera personer) identifieras med hjälp av en leverantörsdefinierad men icke-biometrisk metod. Detta används för att ge positiv bekräftelse på att sensorn använder identifiering som inte är relaterad till biometri enligt definitionen nedan. Utan detta kan en värd inte anta att biometri inte används av enheten.
Typ av identifiering av mänsklig närvaro: Leverantörsdefinierad biometrisk Salt Närvaro (av en eller flera personer) identifieras med hjälp av leverantörsdefinierad mänsklig biometri. Detta är en samlingsterm för en mänsklig närvarosensor som använder biometri som inte redan definierats nedan.
Identifieringstyp för mänsklig närvaro: Ansiktsbiometri Salt Mänsklig närvaro identifieras genom sökning (till exempel av en videokamera med låg upplösning) efter mänskliga ansikten (till exempel genom att använda Viola-Jones objektdetektering). Det görs ingen åtskillnad mellan ansikten eller detektering av ansiktsattribut. Sådan identifiering liknar den för befintliga digitalkameror som kan placera en avgränsningsruta runt ett ansikte.
Typ av detektering av mänsklig närvaro: Biometriskt ljud Salt Mänsklig närvaro identifieras genom genomsökning (till exempel av en mikrofon) för mänskliga ljud (till exempel ett fördefinierat nyckelord, allmänt prat, höga ljud, klappning). Det går inte att skilja mellan röster eller användare eller identifiering av ljudegenskaper. Sensorer i den här kategorin bör rapportera "Present" i 10 sekunder efter en ljudhändelse som anger att en användare finns. Latenskrav för frånvaro mäts från slutet av den här perioden.

Viktigt!

Alla närvarosensorer måste korrekt rapportera identifieringstypen som beskrivs ovan.

Tips/Råd

Det här avsnittet är avsett att ge vägledning för OEM-tillverkare som vill installera maskinvara för mänsklig närvaro i ett system. Dessa riktlinjer representerar en minsta fungerande sensorkonfiguration, och Microsoft uppmuntrar till installation av maskinvara som överträffar standarderna här.

Krav för mänsklig närvarosensor i kategori 1 (biometrisk ansiktsigenkänning)

Mått Måttsystem Kommentarer
Sensorintervall .2m – 1.2m Obs! Detta är ett minsta livskraftigt intervall. Sensorer med bättre intervall tillåts. När den mäts direkt (definieras ovan) måste användaren kunna utlösa en aktivering på 1,2 m.
Sensorfördröjning – används <0,33 sekunder Det här kravet definierar tiden från den inbyggda programvarans igenkänning av mänsklig närvaro till det operativsystem som tar emot meddelandet. Svarstidskravet motsvarar en bildfrekvens på tre eller flera bildrutor per sekund. Det är känt att operativsystemet har variabel latens för uppvakning så snart signalen tas emot från sensorn.
Sensorsvarstid – vänteläge <1,0 sekund Det här kravet definierar tiden från den inbyggda programvarans igenkänning av mänsklig närvaro till det operativsystem som tar emot meddelandet. Svarstidskravet motsvarar en bildfrekvens på en eller flera bildrutor per sekund. Det är känt att operativsystemet har variabel latens för uppvakning så snart signalen tas emot från sensorn.
Sensorström – I bruk <80 mw för interna sensorer. För externa sensorer bestäms strömförbrukningen av bussens strömbegränsning. alla mått i genomsnitt. Observera att detta kan minskas till 25 mW i framtiden (2027+). Den här mätningen kapslar in hela sensorundersystemet, inklusive sändare, mottagare och eventuella lysdioder som endast används i enlighet med aktiverings- och låsscenarierna.
Sensorström – vänteläge <25 mw för interna sensorer. För externa sensorer bestäms strömförbrukningen av bussens strömbegränsning. alla mått i genomsnitt. Observera att det här är den maximala effektförbrukningen. Observera att detta kan minskas till 10 mW i framtiden (2027+).
Noggrannhet – avståndsrapportering +/- 5 cm Mäts vid 45 cm (12 tum), 75 cm (29,5 tum) och 120 cm (47,2 tum). Krävs endast om den här sensorn stöder avstånd.

Anmärkning

Ytterligare funktioner som utförs, till exempel GPIO-sammansättning, slutarkontroll eller andra som inte är relaterade till mänsklig närvaroidentifiering, kan inaktiveras för energimätningen.

Krav för sensor för mänsklig närvaro i kategori 2 (andra)

Mått Måttsystem Kommentarer
Sensorintervall .2m – 1.2m Obs! Detta är ett minsta livskraftigt intervall. Sensorer med bättre intervall tillåts. När den mäts direkt (definieras ovan) måste användaren kunna utlösa en aktivering på 1,2 m.
Sensorfördröjning <.25 sekunder Det här kravet definierar tiden från den inbyggda programvarans igenkänning av mänsklig närvaro till hid-drivrutinen som tar emot meddelandet. Det är känt att operativsystemet har variabel latens för uppvakning så snart signalen tas emot från sensorn.
Sensorström – i bruk <65 mw för interna sensorer; För externa sensorer bestäms strömförbrukningen av bussens strömbegränsning. alla mått i genomsnitt. Den här mätningen kapslar in hela sensorundersystemet, inklusive sändare, mottagare och eventuella lysdioder som endast används i enlighet med aktiverings- och låsscenarierna. Observera att detta kan minskas till 25 mW i framtiden (2027+).
Sensorkraft – Vänteläge <5 mw; För externa sensorer bestäms strömförbrukningen av bussens strömbegränsning. alla mått i genomsnitt. Detta mäts genom sensorns strömförbrukning när systemet är i vila i modern standby. Den här mätningen kapslar in hela sensorundersystemet, inklusive sändare, mottagare och annan maskinvara som endast används i enlighet med aktiverings- och låsscenarierna.
Noggrannhet – avståndsrapportering +/- 5 cm Mäts vid 45 cm (12 tum), 75 cm (29,5 tum) och 120 cm (47,2 tum). Krävs endast om den här sensorn stöder avstånd.

Anmärkning

Ytterligare funktioner som utförs, till exempel GPIO-sammansättning, slutarkontroll eller andra som inte är relaterade till mänsklig närvaroidentifiering, kan inaktiveras för energimätningen.

Enhetsintegrering

Sensorplacering är avgörande för att ge den bästa användarupplevelsen och ge en konsekvent mänsklig närvaroupplevelse mellan enheter.

Den idealiska placeringen är beroende av enhetens formfaktor och i samtliga fall bör OEM-tillverkare bestämma den bästa placeringen för sin enhet. För enheter med flera ställningar som 2 i 1 konvertibla bärbara datorer rekommenderar vi dessutom att sensorernas inbyggda programvara rapporterar datafältet isValid = false för hållningar där sensorer för mänsklig närvaro inte kommer att producera exakta mätningar (dvs. sensorn är inte riktad mot användaren eller hindras). Den verkliga optimala placeringen av sensorerna är vanligtvis på samma plan som displayen (mot användaren).

Se dessutom till att de olika konfigurationer som en enhet kan ta (tangentbordsläge i surfplatta eller bärbart läge till exempel) inte blockerar bländaren och inte korsar sensorns synfält.

Se slutligen till att sensorns synfält inte korsar någon bullrig ljuskälla (kamerablixt, tangentbordsbelysning och så vidare) eftersom dessa kan bidra till ytterligare brus eller dåliga avläsningar. Tänk på alla de olika konfigurationer som en enhet kan använda när du överväger synfält som korsar bruskällor av ljus- eller elektromagnetiska vågor.

Formfaktor Plats och överväganden för mänsklig närvarosensor
Tablett Placera den mänskliga närvarosensorn nära enhetens yta, inte i mitten, med korrekt avskärmning för att säkerställa korrekta avläsningar.
Konvertibel Använd din bästa bedömning för konvertibla stilsystem.
Clamshell Placera den mänskliga närvarosensorn på locket ovanför skärmen mot användaren (rekommenderas).
Allt-i-ett eller extern övervakare Placera den mänskliga närvarosensorn på enhetens framsida (till exempel ramområde) (rekommenderas).
Skrivbord Om du placerar den mänskliga närvarosensorn på chassit för en stationär dator rekommenderar vi att den placeras på toppen av chassit nära kanten. Det är bättre att inkludera närvarosensorn i bildskärmen eller ge en extern USB-dongel.

Närvarosensorer med hög svarstid

Framtida versioner av Windows 11 och senare kan ge stöd för icke-riktningsberoende sensorer och/eller sensorer med hög latens, till exempel sådana som använder Wi-Fi-radio för närvaroavkänning. För Inkorgslösningen i Windows rekommenderar vi inte att du använder det befintliga plattformsstödet för sensorer om de inte kan uppfylla de befintliga KPI:erna för sensorsvarstid. Ytterligare operativsystemegenskaper för inkorgen som justerar rullgardinsmenyer och valmöjligheter för användartimeout samt OEM-anpassningar baserade på rapporterad sensorsvarstid behöver implementeras innan stöd för dessa sensortyper kan tillhandahållas.

Tröskelvärde för avståndsidentifiering och tröskelvärde för avståndskänslighet

Sensorn bör använda tröskelvärdet för identifieringsavstånd när den identifierar användarens närvarotillstånd: UserPresent om avståndet är mindre eller lika med tröskelvärdet, UserNotPresent om mer. Sensorn måste rapportera ett nytt exempel när:

  • Användarens närvarotillstånd ändras.
  • Användarens engagemangstillstånd ändras, medan användaren ligger inom det intervall som anges i tröskelvärdet för identifieringsavstånd.
  • Ändringen i Avstånd är större än det aktuella tröskelvärdet för avståndskänslighet, medan användaren ligger inom det intervall som anges i tröskelvärdet för identifieringsavstånd.

För operativsystemets funktioner: Lås när du lämnar, adaptiv dimning och åskådardetektering

  • Adaptiv nedtoning använder samma tröskelvärde för avståndsidentifiering som Lock On Leave.
  • Tröskelvärdet för avståndsdetektering för åskådare är OEM-konfigurerbart. Standardvärde – 3000mm, minsta värde – 1 200 mm.
  • Tröskelvärde för avståndsidentifiering programmerat till sensorn är det största värdet bland aktiva lägen, där Onlooker >= LockOnLeave/AdaptiveDimming >= WakeOnApproach

Stöd och skiljedomspolicy för extern mänsklig närvarosensor

Externa mänskliga närvarosensorer som är integrerade i bildskärmar stöds av inkorgsfunktionen. Avsnitten nedan beskriver implementeringen, kraven och principen som tillämpas på externa mänskliga närvarosensorer. Andra typer av externa sensorer, till exempel fristående, stöds inte fullt ut eftersom formfaktorn och användningstypen är för varierande för att tillförlitligt stödjas. Det finns dock inget som uttryckligen förbjuder sådana sensorer, och det rekommenderas att leverantörer som är intresserade av att producera sådana sensorer når ut till sasensor@microsoft.com.

Genomförande

Externa mänskliga närvarosensorer ska exponeras för operativsystemet på samma sätt som en intern sensor, förutom att den DEVPKEY_Sensor_ConnectionType sensoregenskapen ska markeras som extern så att operativsystemet är medvetet om extern anslutning. Operativsystemet vet om sensorn är integrerad i en extern bildskärm via PLD-informationen som är associerad med sensorn. Vi rekommenderar starkt att sensorn exponeras som en HID-enhet så att inkorgens HID-klassdrivrutin används. Detta eliminerar behovet av att användaren installerar drivrutiner för att den externa sensorn ska bli i drift.

Den fysiska anslutningen mellan den externa sensorn och systemet ska vara en USB-anslutning separat från bildskärmsanslutningen. Det beror på att ingen av standardanslutningstyperna för visning, till exempel HDMI eller DisplayPort, stöder HID. Det kan vara möjligt för bildskärmen och sensorn att dela en anslutning via USB-C alt-mode och USB4, men inte alla användare kommer att ha åtkomst till sådana anslutningstyper och bör därför inte förlita sig på som den enda anslutningsappen för den externa sensorn.

Kravspecifikation

Externa mänskliga närvarosensorer måste uppfylla samma krav som interna mänskliga närvarosensorer och klara samma HLK- och manuella tester.

Hantera sensorer med olika funktioner

När det finns flera närvarosensorer med olika funktioner stöder till exempel sensor A endast aktivering vid närmande och låsning vid frånvaro, medan sensor B endast stöder anpassningsbar nedtoning. Sidan Inställningar visar funktionerna i den valda sensorn. Om sensor A väljs visas endast aktiverings- och låsknappar. Om sensor B väljs visas endast den anpassningsbara nedtoningsknappen.

Standardlogik för val av närvarosensor

Före och inklusive Windows 11 22H2 valdes den senaste anslutna sensorn som standard. Från maj 2023 kommer uppdateringen till Windows 11 22H2 och senare, och urvalslogiken illustreras enligt nedanstående.

Standardvalslogik för närvarosensor

Policy för Väcka vid ankomst, Lås vid avfärd och Åskådardetektion

Externa sensorer har prioritet framför interna sensorer och, när de är anslutna till systemet, ersätter de helt de interna sensorerna som inmatning för att aktivera och låsa. Prioritet innebär att när en extern sensor är ansluten blir den standardsensorn för systemet. Befintliga användarinställningar, till exempel timeout eller identifieringsavstånd, överförs till den externa sensorn.

Policy för skiljedomsförfarande för olika externa sensorkonfigurationer finns här nedanför.

Systemet har integrerad sensor Systemet har en extern sensor Skiljedomsprincip
Ja Ingen Om locket på systemet är stängt; onlooker, wake and lock inaktiveras och fungerar inte.
Nej Ingen Funktionen finns inte eller är inaktiverad.
Ja Singel Den externt anslutna sensorn blir den förvalda sensorn för betraktare, väckning och låsning. Användaren har möjlighet att konfigurera vilken sensor de föredrar i användargränssnittet för Windows-inställningar. Den här inställningen visas bara när det finns flera sensorer tillgängliga för systemet. Efter maj 2023-uppdateringen i version 22H2 eller senare följer markeringslogiken standardlogik för närvarosensorval.
Nej Singel Den externt anslutna sensorn används som standard.
Ja Flera Samma användaralternativ visas i användargränssnittet. Sensorn som senast var ansluten till systemet är standardsensorn tills användaren väljer ett annat alternativ. Efter maj 2023-uppdateringen i version 22H2 eller senare följer markeringslogiken standardlogik för närvarosensorval.
Nej Flera Samma användaralternativ visas i användargränssnittet. Sensorn som senast var ansluten till systemet är standardsensorn tills användaren väljer ett annat alternativ. Efter maj 2023-uppdateringen i version 22H2 eller senare följer markeringslogiken standardlogik för närvarosensorval.

Tips/Råd

Bildskärmens orientering beaktas inte när man fastställer om sensorn som är integrerad på bildskärmen är användbar; det antas att sensorer fortfarande kan fungera normalt i sådana fall.

Princip för anpassningsbar nedtoning

Policy för skiljedomsförfarande för olika externa sensorkonfigurationer finns här nedanför.

Systemet har integrerad sensor Systemet har en extern sensor Skiljedomsprincip
Ja Ingen Om det finns en extern bildskärm utan en mänsklig närvarosensor och tillståndet "Dimma min skärm när jag tittar bort medan extern bildskärm är ansluten" är avstängt ELLER om systemets lock är stängt, inaktiveras Adaptiv nedtoning och fungerar inte.
Nej Ingen Funktionen finns inte eller är inaktiverad.
Ja Enkel/flera Interna och externa sensorer följer standardlogiken för val av närvarosensor (efter maj 2023 för version 22H2 eller senare). Signaler kombineras aldrig – endast en sensor väljs enligt logiken. För externa bildskärmar beror beteendet på växlingsknappen "Mörkna skärmen när jag tittar bort medan en extern bildskärm är ansluten".
Nej Singel Den externt anslutna sensorn används som standard.

Tips/Råd

Bildskärmens orientering beaktas inte när man fastställer om sensorn som är integrerad på bildskärmen är användbar; det antas att sensorer fortfarande kan fungera normalt i sådana fall.

Sensorer för virtuell mänsklig närvaro

Sensorer för mänsklig närvaro måste backas upp av en fysisk enhet. Med andra ord bör en falsk mjukvaruenhet inte exponeras som proxy för att kontrollera aktivering, lås eller anpassningsbar skärmnedtoning. Den här funktionen är endast avsedd att användas med fysiska scenarier. Avsikten med detta krav är att Närvarosensorer måste identifiera och referera till den fysiska miljön för att fastställa användarens närvarosignaler. Virtuella HID-sensorer kan implementeras om de aggregerar data från andra sensorer som mikrofonen eller andra användarindata och körs i ett avlastat kisel, till exempel en NPU eller MCU där bild- eller ljudmetadata inte är tillgängliga för program i operativsystemet. När det gäller kameran ska sensorer för virtuell närvaro INTE använda eller bearbeta bildmetadata i operativsystemet. OEM-tillverkare och IHV:er som implementerar virtuella sensorer som använder bild- eller metadata i operativsystemet tar på sig allt rättsligt ansvar för sekretessen för en sådan implementering.

Energikrav för närvarosensorer i detta white paper är avsedda för fysiska sensorer. För virtualiserade sensorer som kör en del av andra undersystem ärvs energikraven från det undersystem som de körs i. Till exempel bör en virtuell närvarosensor som körs på ett modernt väntelägessystem och som körs i det avlastade ljudundersystemet följa kraven som anges i Ljudundersystems energisparfunktioner för moderna standby-plattformar

Interaktion med kamerasekretess slutare och kill växlar

Det förväntas att sekretessavtryckaren inte stör sensorer för mänsklig närvaro om inte bildmetadata överförs till operativsystemet. I de fall där samma fysiska sensor används med Windows Hello (IR-kamera) eller den allmänna RGB-kameran rekommenderar vi att den mänskliga närvarosensorn exponeras via en separat fysisk sökväg från Internetleverantören (till exempel via en diskret NPU) där slutsatsdragningar och inga bildmetadata (inklusive ansiktssignatur) överförs till operativsystemet. Eftersom kamera kill-switchar ska fungera i bildsignalprocessorns inbyggda programvara, säkerställer en separat fysisk väg att kill-switchar inte stör funktioner för att detektera mänsklig närvaro. Om en separat fysisk sökväg inte används för en delad sensor anger kamerans HLK-vägledning att sekretessluckor fungerar på både RGB- och IR-sensorn och detta skulle störa mänsklig närvarofunktioner som resulterar i en dålig användarupplevelse eftersom Windows inte varnar användaren om att mänsklig närvaro blockeras. För närvarande rekommenderas inte att ha en delad väg mellan mänsklig aktivitet och internetleverantören. Men i de fall detta är nödvändigt skulle ISP stoppa HPD-identifiering (för batteribesparingar) och rapportera att HPD-sensorn inte är tillgänglig.

Vi rekommenderar starkt att alla fysiska slutare rapporterar sin status till operativsystemet via CT_PRIVACY_CONTROL (för UVC-enheter) eller KSPROPERTY_CAMERACONTROL_PRIVACY (om du använder AVStream- eller DMFT-drivrutin). Mer information finns i Avisering om kamerasekretesslucka.

Mer information om funktionerna i kamerasekretessluckor, kill-växlar och lysdioder finns på Kamera sekretesskontroller.

Interaktion med lysdioder för kamerasekretess

Det är Microsofts förväntning att kamerasekretess-lysdioder kan och bör förbli avstängda i de fall där inga bildmetadata överförs till operativsystemet. Det krävs att den mänskliga närvarosensorn inte fysiskt kan överföra ansikts- eller bilddata till operativsystemet. Detta kan åstadkommas med en mängd olika mekanismer, till exempel men inte begränsat till en dedikerad buss eller fysiskt separat väg från en kamera-ISP eller en säkring inom sensorn. Mer information om funktionerna i kamerasekretess-lysdioder finns i avsnittet Kamerasekretesskontroller .

Guide för implementering

Läsare av det här avsnittet (som har för avsikt att utveckla en närvarosensordrivrutin) bör bekanta sig med sensorernas drivrutinsdesignguide.

I maskinvara implementeras en mänsklig närvarosensor som en SensorType_Proximity, där DEVPKEY_Sensor_ProximityType är inställt på ProximityType_HumanProximity = 1.

Om sensorn använder biometri kan den finnas i SensorCategory_Biometric.

Bussanslutning för enheter

Det finns inga hårda krav utanför testerna i HLK (se nedan) på enhetsbussanslutningen. Det rekommenderar dock att systembyggare utnyttjar inkorgsdrivrutiner som är tillgängliga i Windows 11 där det är möjligt. Det finns till exempel en HID-drivrutin för inkorgen för I2C och en inkorgssensordrivrutin för HID-baserade enheter. Detta ger den fördel som Microsoft kommer att underhålla inkorgsdrivrutiner i Windows 11.

Strömhantering

Det här avsnittet innehåller en grundläggande översikt över energisparfunktioner för mänskliga närvarosensorer. Mer detaljerad information finns i Energisparfunktioner för sensorer.

Tips/Råd

Närvarosensorn är utformad för att fungera i moderna väntelägessystem. Ytterligare stöd för funktionen "wake on approach" för system utan modernt vänteläge har lagts till i uppdateringen från maj 2023 till Windows 11 version 22H2 och senare.

Ytterligare krav för HIDUSB-implementeringar

Artikeln Selektiv avstängning för HID via USB-enheter ger ett exempel på hur en OEM- eller IHV-INF refererar till den inbyggda INPUT.INF för att aktivera en annan funktion för selektiv avstängning. OEM:er och IHV:er kan göra något liknande i sina INF:er genom att referera till avsnittet som nämns ovan för att aktivera wake-on-touch.

För att förenkla denna INF kan OEM-tillverkare och IHV:er också överväga att skapa ett tilläggs-INF i stället. Se dokumentationen för Använda ett Extension INF-fil.

Om enheten har flera HID-samlingar, inklusive sensorsamlingar för mänsklig närvaro och icke-mänsklig närvaro, bör sensorns inbyggda programvara endast stödja att väcka från de mänskliga närhetssamlingarna. Om en sensor för icke-mänsklig närvaro också kan signalera väckning, kommer enheten fortfarande att föras tillbaka till D0 för att tömma strömmen.

Protokollimplementering (arkitektur på hög nivå)

Det här avsnittet kräver nödvändig information om drivrutinsimplementering för att rapportera en mänsklig närvarosensor till operativsystemet. Tekniskt sett görs detta genom att implementera en typ av mänsklig närhetsidentifiering för en närhetstypsensor i kategorin biometrisk sensor.

Diagrammen nedan visar hur data från sensorn flödar upp i stacken när funktionen fungerar. Externa övervakare använder de diagram som är märkta som "HID".

Drivrutinstyp/sensorkapacitet Avståndskapabel hårdvara (+/- 5cm) Distance-Agnostic HW
HID: Enhet för mänskligt gränssnitt HID-baserat avståndskompatibelt dataflöde (rekommenderas) HID-baserat avståndsagnostikdataflöde
CLX: Windows-sensorklasstillägg CLX-baserat avståndskompatibelt dataflöde CLX-baserat avståndsagnostikdataflöde

HID-baserat avståndskapabelt flödesdiagram

CLX-baserat avståndskompatibelt dataflöde

CLX-baserat Distance-Capable dataflöde

HID-baserat avståndsagnostikdataflöde

HID-baserat Distance-Agnostic dataflöde

CLX-baserat avståndsagnostikdataflöde

CLX-baserat Distance-Agnostic dataflöde

Dataflöde på hög nivå

  1. Användaren ändrar inställningarna för aktivering eller lås via inställningsgränssnittet och kommuniceras till Windows-sensortjänsten.
  2. Windows sensortjänst startar den mänskliga närvarosensorn under vanlig drift eller modern viloläge för att övervaka uppvaknande och låsning.
  3. Mänsklig närvarosensor genererar ett nytt prov som innehåller mänsklig närvaro, detekteringsavstånd och är giltigt.
  4. Om systemet är i modernt vänteläge och det nya exemplet på mänsklig närvaro rapporterar att en människa inom det konfigurerade identifieringsintervallet skickar Windows-sensortjänsten en aktiveringssignal till Windows-strömstacken. Om systemet däremot är i normal drift och en människa inte rapporteras eller ligger utanför det konfigurerade identifieringsintervallet skickar Windows-sensortjänsten en timeout-signal till Windows-strömstacken.

Signaler om mänsklig närvaro

Signaler:

  • Signalen för närvaro av person – inträffar när sensorn rapporterar ett dataprovet med datapunkt för personnärvaro inställt på sant. Om systemet stöder uppmärksamhet ställs uppmärksamheten in på interaktiv/sann i det här tillståndet.
  • Användaren är närvarande men inte engagerad signal – inträffar i system som stödjer funktioner för uppmärksamhet när sensorn rapporterar ett dataexempel med fältet för mänsklig närvaro inställt på sant och sedan anges uppmärksamheten som oengagerad eller falsk.
  • Användaren visar ingen signal – inträffar när sensorn rapporterar ett dataexempel med det mänskliga aktuella datafältet inställt på false.
  • Okänd signal för användare – Signalerad när mänsklig närvaro är okänd. Detta kan inträffa om sensorn tas bort på ett felaktigt sätt eller om sensorn ännu inte har rapporterat ett giltigt mätvärde.

Obligatoriska HID-beskrivningar och toppnivåsamlingar

Om det implementeras, med någon av de HID-baserade arkitekturerna, beskriver följande avsnitt datafälten för att exponera närvaroinformation.

Mer information om hur du exponerar en enhet via HID finns i Sensorer HID-användning.

Mänsklig närvaro – närvarande (aktivering och lås)
Användnings-ID Kommentarer
0x04B1 HID_USAGE_SENSOR_DATA_BIOMETRIC_HUMAN_PRESENCE Användning för att exponera ett booleskt värde som indikerar närvaro. Ange värdet till "1" för att indikera mänsklig närvaro. Ange värdet till "0" för att indikera att det inte finns någon mänsklig närvaro.
0x04B2 HID_USAGE_SENSOR_DATA_BIOMETRIC_MÄNSKLIG_NÄRHETSOMRÅDE Används för att visa avståndsvärden i indatarapporten. Standardenheten är i meter, och exempelrapportbeskrivningen i det här dokumentet visar hur enheten kan rapportera millimeter. Detta görs till ett valfritt fält i en framtida Windows-uppdatering.

Anmärkning

Millimeterrapporten måste vara korrekt inom +/- 5000mm. Det rapporterade intervallet kan vara kontinuerligt eller i diskreta steg på mindre än 5000mm (dvs. 2000mm, 7000mm,..). Detta görs till ett valfritt fält i en framtida Windows-uppdatering.

Valideringsguide – Minimikrav och testning: Windows Hardware Certification Program (WHCP)

Det lägsta testet och kraven för att certifiera maskinvaran som kompatibel beskrivs i HLK-testerna (Hardware Lab Kit) i Specifikationer och principer för Windows maskinvarukompatibilitetsprogram.

  • Last updated on