A school attendance and leave linkage-based in-school number counting method and system

Abstract

The present application relates to the technical field of campus attendance data processing, student in-out school state recognition and emergency counting information processing, and particularly relates to a school attendance and leave and leave linkage school number statistics method and system. The method comprises: receiving the in-out school direction event stream reported by the access control device or the student wearable terminal in a low-frequency trigger mode, generating an effective direction event sequence, a student list to be present and a statistical context; filtering the approved leave records based on the statistical context to generate an effective student list of the approved leave at the current statistical time; maintaining a direction state machine with the student ID as the key, generating an actual school collection and an actual leave collection; deducting the effective leave student list from the absence candidate collection to generate an abnormal absence list and label the reason; and generating a school number snapshot based on the actual school collection, the abnormal absence list and the reason label. The present application effectively improves the consistency of the school state statistics and the leave approval time range.

Description

Technical Field

[0001] This invention relates to the fields of campus attendance data processing, student entry and exit status recognition, and emergency count information processing, and particularly to a method and system for counting the number of students on campus that links arrival, departure, and leave requests. Background Technology

[0002] In the field of campus attendance data processing and student entry / exit management, existing solutions for tracking student arrival, departure, and leave status typically rely on access control devices, student terminals, student leave management systems, or academic affairs management systems to record entry / exit information and leave information respectively. While these solutions can handle basic processing such as attendance, check-out, leave application, leave approval, and headcount aggregation in typical scenarios, they are prone to limitations in scenarios where arrival / departure events and leave approval records are generated asynchronously. These limitations include inconsistencies in the timeframes of entry / exit records and leave records, discontinuities between the list of expected students and their actual attendance, and difficulty in distinguishing the reasons for abnormal absences.

[0003] Existing solutions often rely on single card swipe records, the most recent access control records, classroom attendance results, or fixed leave lists for processing. When students' status changes before or after the statistical time, such as arriving at school, leaving school, supplementing approval, withdrawing approval, or canceling leave, there is a lack of stable connection between school entry and exit records, approved leave records, and subsequent headcount summaries. This can easily lead to inconsistencies between absentee candidates and valid leave applicants, and cause different statuses such as legitimate leave, absence without return, and events with no valid destination to be mixed up in the statistical results.

[0004] For the joint processing of events related to students arriving at and leaving campus, lists of students expected to be present, and approved leave records, existing technologies still face challenges in synchronizing event status, leave time ranges, and statistical methods for student numbers. Therefore, it is necessary to address the issue of generating a snapshot of on-campus numbers with reason tags when events related to students arriving at and leaving campus and leave approval records are generated asynchronously, specifically within the context of linked statistics on student arrivals, departures, and leave requests. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for counting the number of students on campus that links arrival / departure with leave requests, including:

[0006] S100: Receive the arrival / departure direction event stream reported by the access control device or student wearable terminal in a low-frequency triggering mode, and obtain the student list data corresponding to the statistical time; verify, sort, and cache the arrival / departure direction event stream according to the student ID and the reporting timestamp, and generate a valid direction event sequence, a list of students who should arrive, and a statistical context;

[0007] S200. Based on the statistical context, obtain the approved leave records, filter by approval start time, approval end time, leave level and statistical time, and generate a list of students with approved leave that is valid at the current statistical time.

[0008] S300. Based on the valid direction event sequence, maintain the direction state machine with student ID as the key and perform state reduction to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set.

[0009] S400: Subtract the actual number of students in school from the list of students who should be present to generate an absence candidate set; subtract the list of students with approved leave at the current statistical time from the absence candidate set to generate an abnormal absence list, and label the reason based on the existence and direction identifier of the last valid event;

[0010] S500: Based on the actual number of students in school, the list of students with abnormal absences, and the reason tags, perform summary statistics by class and grade to generate a snapshot of the number of students in school.

[0011] Furthermore, each event in the outbound direction event stream includes a student ID, direction identifier, reporting timestamp, device identifier, and event reception time; the verification includes: marking events lacking a student ID, direction identifier, or reporting timestamp as invalid events; and writing the verified events into the event cache according to the student ID and reporting timestamp to generate the valid direction event sequence.

[0012] Furthermore, the low-frequency triggering method includes: the access control device or the student wearable terminal receiving the triggering order of the outer edge triggering area and the inner edge triggering area of ​​the school gate; when the triggering order is that the outer edge triggering area of ​​the school gate is triggered first and the inner edge triggering area of ​​the school gate is triggered later, an arrival direction identifier is generated; when the triggering order is that the inner edge triggering area of ​​the school gate is triggered first and the outer edge triggering area of ​​the school gate is triggered later, a departure direction identifier is generated.

[0013] Furthermore, the direction state machine includes an unconfirmed state, an on-campus state, a off-campus state, and a pending confirmation state; when the last valid direction state of the same student ID is "arrived at school", the student ID is assigned to the actual on-campus set; when the last valid direction state of the same student ID is "departed from school", and there is no valid direction event corresponding to the arrival direction identifier after the last valid event, the student ID is assigned to the actual departed from school set; when the direction identifiers of the same student ID have direction conflicts, the student ID is assigned to the pending confirmation set.

[0014] Furthermore, the approved leave record includes student ID, approval start time, approval end time, leave level, leave status, and approval version; the generation of the list of approved leave students valid at the current statistical time includes: filtering approved leave records whose approval start time is no later than the statistical time, whose approval end time is later than the statistical time, whose leave level meets the deduction conditions, and whose leave status has not taken effect; and writing the student ID from the filtered approved leave records into the list of approved leave students valid at the current statistical time.

[0015] Furthermore, the student list data includes student ID, class identifier, grade identifier, and statistical inclusion identifier; the generation of the list of students who should attend includes: filtering student IDs with the statistical inclusion identifier in the inclusion status from the student list data, binding the filtered student IDs according to the class identifier and grade identifier, and generating the list of students who should attend.

[0016] Furthermore, the reason label includes behavioral factors and device factors; when a student ID in the abnormal absence list has a last valid event, and the direction identifier of the last valid event is "leaving school", and there is no valid direction event corresponding to the direction identifier of "coming to school" after the last valid event, the reason label of the student ID is marked as behavioral factors; when a student ID in the abnormal absence list has no valid direction event in the statistics window, or the access control device or student wearable terminal associated with the student ID has a device malfunction, the reason label of the student ID is marked as device factors.

[0017] Furthermore, the snapshot of the number of students on campus includes the snapshot version, statistical time, class identifier, grade identifier, number of students who should be present, number of students actually on campus, number of students with valid leave requests at the current statistical time, number of students with abnormal absences, and distribution of reason tags; the summary statistics of classes and grades include: summarizing and statistically analyzing the actual number of students on campus, the list of students with valid approved leave requests at the current statistical time, the list of students with abnormal absences, and the reason tags according to class identifier and grade identifier.

[0018] Furthermore, the method also includes: obtaining a floor mapping; based on the floor mapping, associating the student IDs in the snapshot of the number of students enrolled with the floor identifiers to generate a regional inventory data package; and outputting the regional inventory data package to a fire evacuation inventory terminal.

[0019] Furthermore, a campus attendance statistics system that links arrival and departure with leave requests includes: an event access module, a required attendance list construction module, a whitelist construction module, a state machine reduction module, a difference calculation module, a reason label module, and a summary output module; the system is used to implement the method described in any of the above-mentioned embodiments.

[0020] The key innovations of this invention include:

[0021] (1) The event streams of the direction of arrival and departure reported by the access control device or the student wearable terminal are verified, sorted and cached according to the student ID and the reporting timestamp to form a valid direction event sequence. The direction state machine is maintained with the student ID as the key and reduced to generate the last valid event, the last valid direction state, the actual set of students on campus and the actual set of students leaving campus.

[0022] (2) Obtain approved leave records based on statistical context, and filter and generate a list of students with approved leave valid at the current statistical time according to the start time of approval, the end time of approval, the leave level and the statistical time; then deduct the actual on-campus set from the list of students who should be present to generate an absent candidate set, and deduct the list of students with approved leave valid at the current statistical time from the absent candidate set to generate an abnormal absent list.

[0023] (3) Based on the existence and direction identifier of the last valid event corresponding to the student ID in the abnormal absence list, the cause label is marked, and the actual school set, the abnormal absence list and the cause label are summarized and statistically analyzed by class and grade to generate a snapshot of the number of students in school.

[0024] The following are its main beneficial effects:

[0025] (1) To address the problem that existing school entry and exit records rely heavily on single access control records or the most recent record, resulting in discontinuous state connections, the arrival and departure direction events of student IDs are reduced by effective directional event sequences and directional state machines to form the last effective directional state, the actual school-attendance set, and the actual departure set, so that subsequent absence calculations have continuous state inputs.

[0026] (2) To address the inconsistency between the leave approval records and the time caliber for headcount statistics, the list of students with approved leave at the current statistical time is filtered by the start time of approval, the end time of approval, the leave level, and the statistical time. This list is then used as the deduction object in the candidate set of absentees, forming an abnormal absence list corresponding to the statistical time.

[0027] (3) To address the issue of confusion in the statistical results regarding legitimate leave, absence from school, and events without valid direction, the cause label is marked by the existence of the last valid event and the direction identifier. In conjunction with the actual number of students on campus and the list of abnormal absences, a snapshot of the number of students on campus is generated, so that the summary statistics of classes and grades include the corresponding absence reason records. Attached Figure Description

[0028] Figure 1 A flowchart illustrating a method for counting the number of students on campus that links arrival at school, departure from school, and leave requests, provided as an embodiment of this application;

[0029] Figure 2This is a structural block diagram of an on-campus student attendance statistics system that links arrival and departure with leave requests, provided as an embodiment of this application. Detailed Implementation

[0030] Example 1: Refer to Figure 1 This is a flowchart illustrating a method for counting the number of students on campus that links arrival and departure with leave requests, provided by an embodiment of the present invention. The process may include at least steps S100-S500:

[0031] S100: Receive the arrival / departure direction event stream reported by the access control device or student wearable terminal in a low-frequency triggering mode, and obtain the student list data corresponding to the statistical time; verify, sort, and cache the arrival / departure direction event stream according to the student ID and the reporting timestamp, and generate a valid direction event sequence, a list of students who should arrive, and a statistical context;

[0032] S200. Based on the statistical context, obtain the approved leave records, filter by approval start time, approval end time, leave level and statistical time, and generate a list of students with approved leave that is valid at the current statistical time.

[0033] S300. Based on the valid direction event sequence, maintain the direction state machine with student ID as the key and perform state reduction to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set.

[0034] S400: Subtract the actual number of students in school from the list of students who should be present to generate an absence candidate set; subtract the list of students with approved leave at the current statistical time from the absence candidate set to generate an abnormal absence list, and label the reason based on the existence and direction identifier of the last valid event;

[0035] S500: Based on the actual number of students in school, the list of students with abnormal absences, and the reason tags, perform summary statistics by class and grade to generate a snapshot of the number of students in school.

[0036] S100: Receive the arrival / departure direction event stream reported by the access control device or student wearable terminal in a low-frequency triggering mode, and obtain the student list data corresponding to the statistical time; verify, sort and cache the arrival / departure direction event stream according to the student ID and the reporting timestamp, and generate a valid direction event sequence, a list of students who should arrive and a statistical context.

[0037] This step is executed by the event access module and the attendance list construction module. The event access module is deployed in the attendance backend server, access control gateway, or campus security management platform. The access control device and the student wearable terminal serve as the source of the event flow for the direction of arrival and departure from school. The access control device can be a card reader, a low-frequency triggering device, or an identification device bound to the direction of passage, located in the school gate passage area. The student wearable terminal can be an electronic student ID card, a wristband, or a student terminal with low-frequency triggering reception function. In this embodiment, the low-frequency triggering method refers to the access control device or the student wearable terminal receiving a low-frequency triggering signal during the arrival and departure from school to form a directional event, rather than continuously collecting student position coordinates.

[0038] The "to-leave-school" event stream consists of multiple "to-leave-school" events. Each "to-leave-school" event includes a student ID, a direction identifier, a reporting timestamp, a device identifier, and an event reception time. The student ID is used to match student IDs in the student list data; the direction identifier indicates the direction of arrival or departure; the reporting timestamp indicates the time when the access control device or the student wearable terminal generated the direction event; the device identifier records the device from which the event originated; and the event reception time records the time when the attendance backend server received the event. The direction identifier can be generated by the access control device's direction role or by the student wearable terminal receiving the trigger sequence of the outer and inner edge trigger areas of the school gate.

[0039] In one implementation, the school gate access area is configured with an outer edge trigger zone and an inner edge trigger zone. When the student wearable terminal first receives a low-frequency trigger signal from the outer edge trigger zone and then receives a low-frequency trigger signal from the inner edge trigger zone, the student wearable terminal generates an "arrival" direction identifier. When the student wearable terminal first receives a low-frequency trigger signal from the inner edge trigger zone and then receives a low-frequency trigger signal from the outer edge trigger zone, the student wearable terminal generates a "departure" direction identifier. The access control device can also configure inner and outer direction roles at the same access point, forming direction identifiers based on the card reading order or triggering order, and writing the direction identifiers into the "departure" direction event.

[0040] After receiving the departure direction event stream, the event access module first performs field validation on each departure direction event. The field validation includes student ID validation, direction identifier validation, and reporting timestamp validation. If any departure direction event lacks a student ID, direction identifier, or reporting timestamp, the event is marked as invalid and written to the invalid record area of ​​the event cache. If a departure direction event contains a student ID, direction identifier, and reporting timestamp, it is written to the valid record area of ​​the event cache. The event cache establishes event groups according to student IDs, and within the same student ID group, the departure direction events are arranged in ascending order of reporting timestamps to generate a valid direction event sequence.

[0041] In one implementation, the event access module records and merges duplicate events. Duplicate events refer to events where the same student ID, direction identifier, and device identifier are repeatedly reported within a preset time window, indicating the direction of arrival or departure from school. For duplicate events, the event access module retains the event with the earliest reported timestamp as a valid direction event and marks the remaining duplicate events as duplicate records. For events with the same student ID and opposite direction identifiers occurring consecutively within a short period, the event access module does not directly delete the event but retains its original fields and writes them to the event cache, where the subsequent direction state machine performs reduction processing for direction conflicts. The aforementioned duplicate event time window can be provided by a configuration item in the attendance backend server and is not fixed as a unique value in this step.

[0042] The student list data is provided by a student school information database, an academic affairs management system, or relevant school data. The student list data includes student ID, class identifier, grade identifier, and statistical inclusion identifier. In one embodiment, the student list data may further include name, accommodation identifier, floor identifier, campus identifier, and data version. The expected attendance list construction module reads the student list data at the statistical time and filters student IDs with the statistical inclusion identifier as "included" from the student list data; the filtered student IDs are bound according to the class identifier and grade identifier to generate the expected attendance student list. For student IDs with the statistical inclusion identifier as "not included," the expected attendance list construction module does not write them into the expected attendance student list but records them in the exclusion record of the statistical context.

[0043] The statistical timing can be triggered by a preset period, or by a request from a fire evacuation checkpoint terminal, an access control device event, or an approval change record. The statistical context records the time and data conditions for this statistical analysis, including the statistical timing, student list data version, event cache location, expected student list version, and statistical range. In one implementation, when the statistical request originates from a fire evacuation checkpoint terminal, the statistical context also records the requesting terminal identifier and floor mapping version; when the statistical request originates from a preset period, the statistical context records the period trigger identifier and the last statistical timing.

[0044] During on-site implementation, when students wearing student wearable terminals pass through the outer and inner trigger areas of the school gate, the student wearable terminals generate a "to / from school" direction event containing the student ID, direction identifier, and reporting timestamp, which is then reported to the attendance backend server via a wireless communication link. The event access module of the attendance backend server writes this event into the event cache according to the student ID; at the same statistical moment, the "should be present" list construction module reads student list data from the student school information database, filters and statistically counts student IDs with the inclusion identifier, and generates a "should be present" list. At this time, the valid direction event sequence, the "should be present" list, and the statistical context generated in S100 are saved to the attendance backend server. The valid direction event sequence is available for use by S300, the "should be present" list is available for use by S400, and the statistical context is available for use by S200.

[0045] S200. Based on the statistical context, obtain the approved leave records, filter by approval start time, approval end time, leave level and statistical time, and generate a list of students with approved leave that is valid at the current statistical time.

[0046] This step is performed by the whitelist construction module. The whitelist construction module is deployed on the attendance backend server and establishes a data interface with the academic affairs management system or a third-party leave approval system. S200 receives the statistical context generated by S100, reads the statistical time, student list data version, and statistical range from the statistical context, and uses the statistical time as the time benchmark for filtering approved leave records. The student list data version in the statistical context is used to match the student IDs in the approved leave records, and the statistical range is used to limit the class identifier, grade identifier, or campus identifier for this statistical processing.

[0047] The approved leave records include student ID, approval start time, approval end time, leave level, leave cancellation status, and approval version. The approval start time indicates when the leave record becomes effective; the approval end time indicates when the leave record ends; the leave level indicates whether the leave record is used for absence deduction; the leave cancellation status indicates whether the leave record has been cancelled; and the approval version records the versions of the same leave application during the addition, modification, cancellation, or cancellation process. The approved leave records can be returned by the academic affairs management system according to statistical time, or they can be read from local leave records by the whitelist construction module.

[0048] After obtaining approved leave application records, the whitelist construction module first matches these records with student IDs. For approved leave application records where the student ID does not appear in the list of students expected to attend generated by S100, the whitelist construction module adds them to the non-statistical range records and excludes them from the construction of the current list of approved leave application records valid at the current statistical time. For approved leave application records where the student ID appears in the list of students expected to attend, the whitelist construction module further filters by time and leave level.

[0049] The time filtering includes comparing the approval start time with the statistical time and comparing the approval end time with the statistical time; when the approval start time is not later than the statistical time and the approval end time is later than the statistical time, the approved leave record falls within the valid time range of the current statistical time. The leave level filtering includes matching the leave level with deduction conditions, which can be provided by the leave level configuration in the school's relevant data. For example, leave from school, sick leave, or personal leave can be configured to meet the deduction conditions, while temporary on-campus activity records can be configured not to meet the deduction conditions. The leave cancellation status filtering includes: when the leave cancellation status is ineffective, the leave record continues to participate in the list construction; when the leave cancellation status is effective, the leave record is not written into the list of students with approved leave valid at the current statistical time.

[0050] In one implementation, the same student ID corresponds to multiple approved leave application records at the same statistical time. The whitelist construction module selects records based on the approval version and approval update time; when the effective time ranges of multiple records overlap, the approved leave application record with the latest approval version is selected as the filtering object for the current statistical time; when multiple records have the same approval version but different leave levels, they are matched according to the deduction priority in the leave level configuration. The replaced approved leave application record is written to the leave record history area, and the approval version, approval start time, and approval end time are retained.

[0051] When the approved leave application records returned by the academic affairs management system have missing fields, the whitelist construction module processes them according to field type. Records lacking student IDs are not included in the list construction; records lacking approval start or end times are written to the pending confirmation record; records lacking leave levels are processed as leave levels not matching; records lacking leave cancellation status are processed according to the default leave cancellation status in the configuration item, and a field missing marker is written into the statistical context. In the case of interface timeout, the whitelist construction module can call the approved leave application records corresponding to the previous approval version and write the status of this call into the recalculation record; in another implementation, the current whitelist refresh can be paused and the list of approved leave students valid at the current statistical time of the previous version can be retained.

[0052] In on-site implementation, after the class teacher approves student leave records in the academic affairs management system, the approved leave records include the student ID, approval start time, approval end time, and leave level. When the statistical time is reached, the whitelist construction module reads the statistical time based on the statistical context formed in S100 and filters records whose approval start time is no later than the statistical time, whose approval end time is later than the statistical time, whose leave level meets the deduction conditions, and whose leave cancellation status has not yet taken effect. The filtered student IDs are written into the list of students with approved leave valid at the current statistical time. The list of students with approved leave valid at the current statistical time carries the list version, statistical time, and record source, serving as input for the differential calculation in S400.

[0053] S300. Based on the valid direction event sequence, maintain the direction state machine with student ID as the key and perform state reduction to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set.

[0054] This step is executed by the state machine reduction module. The state machine reduction module receives the valid direction event sequence generated by S100 and establishes a direction state machine instance using the student ID as the key. Each direction state machine instance corresponds to a student ID and records the direction event sequence, last valid event, last valid direction state, and state version for that student ID before the statistical time. The direction state machine includes an unconfirmed state, an on-campus state, an off-campus state, and a pending confirmation state. The unconfirmed state indicates that the current student ID has not yet formed a reducible valid direction event; the on-campus state indicates that the last valid direction state was "arrived at school"; the off-campus state indicates that the last valid direction state was "departed from school"; and the pending confirmation state indicates that there is a direction conflict or that the valid direction event cannot be directly reduced to the on-campus or off-campus state.

[0055] After entering the state machine reduction module, the valid directional event sequence is first grouped by student ID, and then read in ascending order of reported timestamps within the same student ID. For each student ID, the state machine reduction module performs state reduction starting from the first valid directional event corresponding to that student ID; when the on-campus direction identifier is read, the direction state machine is updated to the on-campus state, and the event is recorded as the last valid event; when the off-campus direction identifier is read, the direction state machine is updated to the off-campus state, and the event is recorded as the last valid event; when the same direction identifier appears consecutively for the same student ID, the state machine reduction module retains the later valid directional event as the last valid event and updates the state version.

[0056] When the last valid direction status of the same student ID is "arrived at school," the state machine reduction module adds that student ID to the actual school-attendance set. The actual school-attendance set has student IDs as members and may carry the direction identifier of the last valid event, the reporting timestamp, the device identifier, and the status version. The actual school-attendance set does not directly include the deduction results of student IDs from the approved leave list; the deduction of student IDs from the approved leave list is performed in S400.

[0057] When the last valid direction state for the same student ID is "departure," and there is no valid direction event corresponding to the arrival direction identifier after the last valid event, the state machine reduction module adds the student ID to the actual departure set. The actual departure set has student IDs as members and records the reporting timestamp and device identifier corresponding to the departure direction identifier. For student IDs that had a departure direction identifier before the statistical time but have an arrival direction identifier after the departure event, the arrival direction identifier appearing after the state machine reduction module is the last valid direction state, and the student is added to the actual on-campus set.

[0058] When a directional conflict occurs for the same student ID, the state machine reduction module adds that student ID to the pending confirmation set. The directional conflict may include the same student ID alternately displaying both arrival and departure directional identifiers within a short period, and the reporting timestamp order not conforming to the triggering order of the outer and inner edges of the school gate triggering area; it may also include the same student ID generating contradictory directional identifiers under different device identifiers. In one implementation, the state machine reduction module does not delete the original event for the directional conflict record, but instead writes the student ID, the reporting timestamp of the conflict event, and the device identifier into the pending confirmation set for cause labeling or subsequent review.

[0059] For late events, the state machine reduction module rearranges the sequence of valid directional events corresponding to the student ID according to the reported timestamp. A late event refers to a valid directional event whose reception time is later than the sorted position corresponding to the reported timestamp. After receiving a late event, the state machine reduction module reads the directional state machine instance for that student ID, re-executes the state reduction for that student ID according to the reported timestamp, and generates a new last valid event, last valid directional state, and state version. The recalculated actual on-campus set and actual off-campus set replace the set records corresponding to the original state version; the original state version is retained in the state record.

[0060] In the on-site implementation, student A passed through the outer edge triggering area of ​​the school gate at 7:45 and then entered the inner edge triggering area, generating an "arrival at school" event on the student's wearable terminal. At 12:10 on the same day, student A passed through the inner edge triggering area and then left to the outer edge triggering area, generating a "departure at school" event on the student's wearable terminal. When the state machine reduction module reads the valid direction event sequence of student A, it first updates his state to "on-campus," and then updates it to "departure at school" based on the departure direction event at 12:10. If there are no arrival at school events after 12:10, student A is written into the actual departure set. For student B, if his last valid direction state is "arrival at school," then student B is written into the actual on-campus set. The last valid event, the last valid direction state, the actual on-campus set, and the actual departure set serve as inputs for S400 to perform differential calculations and cause labeling.

[0061] In one specific embodiment:

[0062] In S300, based on the valid direction event sequence, a direction state machine is maintained using student ID as the key and state reduction is performed to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set.

[0063] This step is executed by the state machine reduction module, which receives the valid directional event sequence generated by the event access module, and simultaneously reads the statistical time, student list data version, and event cache location from the statistical context. The valid directional event sequence has been grouped according to student ID, and within the same student ID group, it is arranged in ascending order of the reported timestamp. The state machine reduction module establishes a directional state machine instance using the student ID as the key. Each instance independently records the complete directional event sequence, the last valid event, the last valid directional state, and the state version for that student ID before the statistical time. The directional state machine includes four states: unconfirmed state, indicating that the current student ID has not yet formed a reducible valid directional event; on-campus state, indicating that the last valid directional state was "on-campus"; off-campus state, indicating that the last valid directional state was "off-campus"; and pending confirmation state, indicating that there is a directional conflict in the directional identifier or that the valid directional event cannot be directly reduced to the on-campus or off-campus state.

[0064] Before initiating reduction, the state machine reduction module first groups the valid directional event sequences according to student IDs, and then reads events one by one within the same student ID in ascending order of reported timestamps. For each student ID, state reduction begins with the first valid directional event corresponding to that student ID. During the reduction process, the module reads the direction identifier and reported timestamp from each valid directional event. When the on-campus direction identifier is read, the direction state machine is updated to the on-campus state, and the event is recorded as the last valid event. When the off-campus direction identifier is read, the direction state machine is updated to the off-campus state, and the event is recorded as the last valid event.

[0065] For cases where the same student ID repeatedly displays the same direction identifier, the state machine reduction module retains the valid direction event with the later reported timestamp as the last valid event, updates the state version, and discards earlier duplicate events. To quantitatively describe the transition confidence between the on-campus state and off-campus state of the direction state machine, a Markov state transition confidence scoring mechanism is introduced: For each student ID, two consecutively reported valid direction events constitute a state transition pair. The direction identifier of the first event is recorded as the source of the direction state, and the direction identifier of the second event is recorded as the destination of the direction state. The state transition confidence from the source state to the destination state is calculated.

[0066] The state transition confidence score reflects the reliability of the change in directional state between two adjacent valid directional events. Its value is determined by the difference in the reporting timestamps of the two events, the consistency of the device identifier, and the stability of the student ID's historical directional state sequence.

[0067] Formula ① is the expression for calculating state transition confidence. This formula maps the timing difference between adjacent valid direction events and device consistency to a confidence score in the range of 0 to 1:

[0068]

[0069] in, : No. The state transition confidence of each state transition pair takes a value range of . This value is calculated by formula ① and stored in the state transition confidence sequence in the orientation state machine instance. It is used to quantify the reliability of the state transition between two adjacent valid orientation events.

[0070] The Sigmoid function, its complete expression is: ,in The base of the natural logarithm ( This function is used to compress linear weighted sums to... The interval is derived from standard mathematical functions;

[0071] Time confidence weighting coefficient, with a range of values ​​of 100%. This coefficient is provided by a configuration item in the attendance backend server and is used to control the time difference. The contribution weight to the confidence level;

[0072] Equipment consistency weighting coefficient, with a value range of [value range missing]. This coefficient is provided by a configuration item in the attendance backend server and is used to control the contribution weight of device identifier consistency to the confidence level.

[0073] Historical stability weighting coefficient, with a range of values ​​of This coefficient is provided by a configuration item in the attendance backend server and is used to control the historical direction state entropy value. The contribution weight to the confidence level; , , The sum of the three is 1;

[0074] : Preset time decay constant, with values ​​ranging from real numbers greater than 0; this constant is provided by a configuration item in the attendance backend server and is used to adjust the decay rate of the confidence level due to the time difference;

[0075] : No. The difference between the reported timestamps of the subsequent event and the preceding event in each state transition pair, taking the value of a real number greater than 0; its calculation formula is: ,in and All of these are reporting timestamp fields in valid directional events, reported by access control devices or student wearable terminals;

[0076] : Indicator function, takes the value 1 when the condition in parentheses is true, and takes the value 0 otherwise; This function is a standard mathematical function used to convert logical judgments into numerical values ​​for weighted summation;

[0077] : The direction identifier of the previous valid directional event, with a value of (Indicates the direction to school) or (Indicates the direction of departure from the school); This value is directly extracted from the direction identifier field in the valid direction event sequence;

[0078] : The direction identifier of the next valid directional event, with a value of (Indicates the direction to school) or (Indicates the direction of departure from the school); This value is directly extracted from the direction identifier field in the valid direction event sequence;

[0079] Historical stability adjustment coefficient, taking values ​​that are real numbers greater than 0; this coefficient is provided by a configuration item in the attendance backend server and is used for adjustment. Sensitivity to the impact on confidence level;

[0080] : No. The entropy value of the corresponding historical direction state sequence for each state transition pair, taking the range of . Its complete formula is: Used to measure the student ID in the past The degree of confusion in directional markers during secondary valid directional events;

[0081] : The set of possible values ​​for the direction identifier , is a discrete set; this set is used to limit The range of summation in the calculation;

[0082] : Direction identifier in historical direction state sequence The frequency of occurrence, with a range of values. The calculation method is to divide the number of times the direction identifier appears in the historical sequence by the total length of the historical sequence. ,in The total number of valid directional events for this student ID within the preset statistics window, with a dimension of one;

[0083] The base of the natural logarithm. , is a standard mathematical constant, appearing in In the function's expression;

[0084] The independent variable of the Sigmoid function, specifically in formula ①, refers to... This linear weighted sum is obtained by summing the three weighted terms mentioned above.

[0085] The practical problem addressed by Formula ① is that during the state reduction process, due to signal jitter, repeated triggering, or timing deviations that may occur in access control devices or student wearable terminals, direct mechanical reduction according to the reported timestamp order may lead to frequent state jumps. The reliability of state transitions between adjacent events is quantified by state transition confidence metric, providing a reliable basis for subsequent reduction judgments.

[0086] For formula ① If two consecutive events originate from the same device identifier and have the same direction identifier, this item is set to 1, indicating that the device continuously reporting the same direction enhances the confidence of the state transition; if they originate from different device identifiers and have opposite direction identifiers, this item is set to 0, indicating that there is a potential direction conflict.

[0087] The values ​​of each pair of adjacent events calculated by formula ① The value is written into the state transition confidence sequence in the directional state machine instance corresponding to the student ID, so that it can be used to determine whether to perform a state switch during subsequent state reduction.

[0088] After obtaining the state transition confidence of each pair of adjacent valid directional events, the state machine reduction module processes the valid directional events corresponding to each student ID in ascending order of the reported timestamps, and determines whether to perform a state switch based on the current state and the state transition confidence.

[0089] For each student ID, the direction state machine starts from the unconfirmed state; when the direction identifier of the first valid direction event is read as "arrival at school", it determines... Is it greater than the preset state transition confidence threshold? If the value is greater than 0, the system switches from unconfirmed to on-campus status and records the event as the last valid event. If the value is less than 0, the system remains unconfirmed and the event is temporarily stored in the pending event buffer. When the direction identifier of the first valid direction event is "leaving campus," the system determines... Is it greater than If the value is greater than 1, the status will switch from unconfirmed to off-campus and the event will be recorded as the last valid event. If the value is less than 1, the status will remain unconfirmed.

[0090] When processing subsequent events, the directional state machine starts from the current state, based on the directional identifier of the newly read event and its corresponding... Perform a state update; when the direction state machine is currently in the "on-campus" state and the direction identifier of the newly read event is "arrived at campus," meaning the direction identifier has not changed, no state transition is performed; only the last valid event is updated to the current event and the state version is incremented; when the direction state machine is currently in the "on-campus" state and the direction identifier of the newly read event is "departed from campus," if the corresponding Greater than If the current state is not in school, the system will switch from the on-campus state to the off-campus state, updating the last valid event to the current off-campus direction event and the last valid direction state to the off-campus state, with the state version incrementing. If the direction state machine is currently in the off-campus state and the direction identifier of the newly read event is "arrived at school," then if the corresponding... Greater than If so, then the switch from off-campus status to on-campus status will be executed; when the corresponding Less than or equal to At that time, no state transition is performed, but the event is written to the pending confirmation event buffer, and the state version of the direction state machine corresponding to the student ID is marked as pending confirmation.

[0091] During the state reduction process, the state machine reduction module maintains the direction state machine instance for each student ID. This instance records the current direction state, the last valid event, the last valid direction state, the state version, and the event list in the event buffer to be confirmed.

[0092] When the same student ID has a directional conflict, that is, when the direction identifiers for arriving at school and leaving the city appear alternately in a short period of time, and the order of the reported timestamps does not conform to the physical triggering order of the outer edge triggering area and the inner edge triggering area of ​​the school gate, or when the same student ID generates contradictory direction identifiers under different device identifiers, the state machine reduction module will add the student ID to the pending confirmation set, and write the reporting timestamp and device identifier of the conflict event into the pending confirmation set record for cause labeling or subsequent review.

[0093] To quantify the severity of directional conflicts, a directional conflict degree index is introduced. This index measures the intensity of the alternation of directional identifiers in the effective directional event sequence within a preset time window before the statistical time for the same student ID. When the directional conflict degree exceeds a preset threshold, the state machine reduction module prioritizes classifying the student ID into the set to be confirmed.

[0094] The calculation of directional conflict degree utilizes the inversion number concept from topological sorting: valid directional events within the time window are sorted in ascending order by their reported timestamps, and their directional identifier sequences are taken. Count the number of inversion pairs in the sequence, where an inversion pair is defined as... and , For event pairs, the normalized number of inversion pairs is used as the quantified value of the directional conflict degree. Formula ② is the expression for calculating the directional conflict degree:

[0095] Formula ②:

[0096]

[0097] in, : Directional conflict degree, with a value range of This value is calculated by formula ② and is used to measure the intensity of the alternation of direction identifiers in the effective direction event sequence within the preset time window for the same student ID. It is directly used to determine whether the student ID has been written into the pending confirmation set.

[0098] : The total number of valid directional events for the same student ID within a preset time window, with a value range of . An integer; the value is the length of the time window provided by the statistical context. This is determined together with valid event records for that student ID in the event access module, specifically within the time window. Inside (of which) (For the statistical time) the number of valid directional events for that student ID;

[0099] : The forward position index of the valid directional event in the ascending sequence, with a value range of . An integer; this index is used to identify the first integer in the sequence. The position of each valid directional event after being sorted in ascending order by the reported timestamp;

[0100] : The backward position index of the valid directional event in the ascending sequence, with a value range of . An integer; this index is used to identify the first integer in the sequence. The positions of the valid directional events after being sorted in ascending order by the reported timestamp, and ;

[0101] : No. 1 in the sequence The direction identifier for each valid directional event, with a value of [value]. (To school direction) or (Direction of departure from school); This value is determined by the first valid direction event in the sequence. The direction identifier field for each event is provided;

[0102] : No. 1 in the sequence The direction identifier for each valid directional event, with a value of [value]. (To school direction) or (Direction of departure from school); This value is determined by the first valid direction event in the sequence. The direction identifier field for each event is provided;

[0103] Indicator function (as in formula ①) (for the same function), when and The value is 1 when the condition is met, and 0 otherwise; the input of this indicator function comes from the summation expression in formula ② and is used to count the number of inversion pairs.

[0104] : Normalization coefficient, where This is the total number of valid directional events as defined above; the coefficient is the maximum number of inversion pairs. The reciprocal of the number of inversions is used to map the number of inversions to Interval.

[0105] The practical problem addressed by Formula ② is that when the same student ID frequently enters and exits the school gate within a short period of time, the directional identifier sequence undergoes numerous alternations (such as arriving at school, leaving school, arriving at school, leaving school). This high-frequency jitter causes the directional state machine to repeatedly switch between the on-campus and off-campus states, reducing the stability and reliability of the reduction results. Formula ② addresses this by calculating the directional conflict degree. ,when Greater than the preset conflict threshold At this time, the state machine reduction module no longer uses the last valid direction state as the sole criterion for judgment, but instead includes the student ID in the set to be confirmed, ensuring the robustness of the reduction result.

[0106] Calculated by formula ② The value is directly used to determine whether the student ID has entered the pending confirmation set: if If the student ID is found to be false, it will be written into the pending confirmation set; at the same time, the reporting timestamp and device identifier of the conflict event will also be written into the pending confirmation set record.

[0107] After completing the reduction process of the orientation state machine and generating the orientation conflict degree After supplementing the confirmation set, the state machine reduction module maps the final directional state of each student ID to either the actual on-campus set or the actual off-campus set. For each student ID, if the last valid directional state of the directional state machine is the on-campus state, and the student ID is not included in the confirmation set, the state machine reduction module writes the student ID into the actual on-campus set. If the last valid directional state of the directional state machine is the off-campus state, and the student ID is not included in the confirmation set, and there is no valid directional event corresponding to the arrival directional identifier after the last valid event, the state machine reduction module writes the student ID into the actual off-campus set. For student IDs that have an off-campus directional identifier before the statistical time but an arrival directional identifier after the off-campus event, the state machine reduction module considers the subsequent arrival directional identifiers as the last valid directional state and includes the student ID in the actual on-campus set.

[0108] The actual on-campus set includes student IDs as members and carries the direction identifier of the last valid event, the reporting timestamp, the device identifier, and the status version. The actual off-campus set includes student IDs as members and records the reporting timestamp and device identifier corresponding to the departure direction identifier. The actual on-campus set does not directly include the deduction results of student IDs from the list of students with approved leave; the deduction of student IDs from the list of students with approved leave is performed in subsequent step S400. For the handling of late events, the state machine reduction module adopts a recalculation mechanism: a late event refers to a valid direction event whose event reception time is later than the sorting position corresponding to the reporting timestamp.

[0109] When the state machine reduction module receives a late event, it reads the direction state machine instance of the student ID based on the student ID of the late event, and re-executes all state reductions for the student ID according to the reported timestamp, generating a new last valid event, last valid direction state, and state version; the recalculated actual on-campus set and actual off-campus set replace the set records corresponding to the original state version, and the original state version is retained in the state record.

[0110] To quantify the impact of late events on the reduction result of the orientation state machine during recalculation, a late arrival state perturbation index is introduced. This index measures the probability that the insertion of a late event will cause a change in the last valid orientation state of the orientation state machine.

[0111] Formula ③ is the expression for calculating the degree of late-arriving state perturbation. This formula utilizes the state transition confidence sequence. Calculate the confidence increment for state reversal based on the insertion position of the late event:

[0112] Formula ③:

[0113]

[0114] in, : Degree of late-arriving state perturbation, with a value range of . This value is calculated by formula ③ and represents the probability that the last valid direction state of the direction state machine will be flipped after the late event is inserted. It is used to determine whether a complete recalculation is triggered.

[0115] The late event is located at its index after being inserted into the valid direction event sequence according to the reported timestamp, with a value range of [value range missing]. An integer; the index is determined by the reported timestamp of the late event. The sequence number of the event after insertion is determined by comparing it with the reporting timestamps of each event in the existing event sequence;

[0116] : The total number of valid directional events for this student ID before the late arrival event was inserted, with a value range of . An integer; this value is determined by the number of records of the student ID in the valid directional event sequence before the late event arrives;

[0117] : Summation and multiplication of index variables, with a range from arrive An integer; this index is used to iterate from the insertion position of the late event. End of the original sequence Each state transition pair;

[0118] : No. The state transition confidence of each state transition pair takes a value range of . This value is directly taken from the calculation result of formula ①, stored in the state transition confidence sequence in the orientation state machine instance, and used as one of the basic multipliers in the multiplication term of formula ③.

[0119] : No. Each state transition affects the corresponding delayed event's influence factor, with a value range of [value range missing]. Its calculation formula is: Used to quantify the time delay of late events on the first The degree of impact of each state transition on the confidence level;

[0120] The difference between the event reception time and the reporting timestamp for a late event, taking the value of a real number greater than 0; its calculation formula is: ,in The time when the attendance backend server receives the lateness event is recorded by the event access module. The reporting timestamp for this lateness event is generated by the access control device or the student's wearable terminal.

[0121] : Preset time constant, with values ​​ranging from real numbers greater than 0; this constant is provided by a configuration item in the attendance backend server and is used to control... right The decay rate;

[0122] Natural exponential function ,in The base of the natural logarithm ( This function is a standard mathematical function, used in formula ③ to calculate... The attenuation value;

[0123] : Event reception time for late events, with a value of a real number greater than 0; this field is recorded by the event access module when receiving the event and is used for calculation. ;

[0124] : The reporting timestamp of the lateness event, with a value of a real number greater than 0; this field is generated and reported by the access control device or student wearable terminal when a directional event is formed, and is used for calculation and determine the insertion position ;

[0125] The base of the natural logarithm. , is a standard mathematical constant, appearing in In the calculation formula.

[0126] Formula ③ addresses the practical problem that requires recalculating the entire state reduction process for a student ID after a late arrival event, but the cost of recalculation increases with the length of the event sequence; by calculating the late arrival state perturbation degree... It is possible to assess in advance the extent to which lateness events affect the reduction results, when Below the preset disturbance threshold In this case, the reduction result of the original state can be directly used without triggering a complete recalculation, thereby optimizing computational efficiency.

[0127] Calculated by formula ③ The value is used to determine whether to trigger a complete recalculation of the direction state machine for that student ID: if If so, then perform a full recalculation and update the state version; if If the event is late, it will only be appended to the event cache without triggering a recalculation.

[0128] After completing all the above processing steps, the state machine reduction module writes the reduction results into the persistent record of the directional state machine instance according to the student ID. Each record includes the direction identifier of the last valid event, the reporting timestamp, the device identifier, the state version, and the final direction state. The actual on-campus set and the actual off-campus set are stored in the memory cache of the attendance backend server as a set data structure and are synchronously written to the state reduction result area in the event cache; the set to be confirmed and its associated conflict event records are written to the unconfirmed record area in the event cache; the complete state history of the directional state machine instance (including the state reduction results of each version, the state transition confidence sequence, the direction conflict degree, and the late arrival state disturbance degree) is saved in the state record storage area for subsequent cause labeling, review, and recalculation refresh. The final output fields of the state machine reduction module include: last valid event (including direction identifier, reporting timestamp, and device identifier), last valid direction status, actual on-campus set (with student ID as a member, carrying last valid event information), actual off-campus set (with student ID as a member, carrying off-campus event information), set to be confirmed (with student ID as a member, carrying conflict event information), and state version.

[0129] In the above output, the last valid event, the last valid direction state, the actual set of students on campus, and the actual set of students off campus serve as inputs to the differential calculation module and the cause labeling module in the subsequent step S400, while the set to be confirmed serves as an additional input to the cause labeling module in the subsequent step S400.

[0130] Technical effects of this section: This step uses the four-state model of the direction state machine and the state transition confidence score to reduce discrete on-campus / off-campus direction events to verifiable on-campus / off-campus states. At the same time, it uses the direction conflict degree to suppress the interference of signal jitter on the reduction results, and introduces a late event recalculation mechanism and disturbance degree prediction. This not only ensures the accuracy and robustness of the direction state reduction at statistical time, but also optimizes the recalculation efficiency when out-of-order events arrive.

[0131] S400: Subtract the actual number of students in school from the list of students who should be present to generate an absence candidate set; subtract the list of students with approved leave at the current statistical time from the absence candidate set to generate an abnormal absence list, and label the reason based on the existence and direction identifier of the last valid event.

[0132] This step is executed by the difference calculation module and the cause labeling module. The difference calculation module receives the list of students who should be present generated by S100, the list of students with approved leave valid at the current statistical time generated by S200, and the actual number of students present at school generated by S300; the cause labeling module receives the last valid event and the last valid direction status generated by S300, and the list of abnormal absences generated by S400. The difference calculation module and the cause labeling module can be deployed in the same attendance backend server, or they can run as two separate processing modules, transmitting the calculation results through student IDs.

[0133] The list of students who should be present serves as the baseline list for this step, and the actual set of students in school serves as the first deduction target. The differential calculation module matches the list of students who should be present with the actual set of students in school based on student ID; when a student ID in the list of students who should be present exists in the actual set of students in school, that student ID is not written into the absence candidate set; when a student ID in the list of students who should be present does not exist in the actual set of students in school, that student ID is written into the absence candidate set. The absence candidate set includes student ID, class identifier, grade identifier, and the absence candidate generation time; in one embodiment, it also includes the last valid direction state and state version of the student ID in S300.

[0134] After generating the absence candidate set, the difference calculation module matches the absence candidate set with the list of students with approved leave requests valid at the current statistical time, using the student ID as the key. If a student ID in the absence candidate set exists in the list of students with approved leave requests valid at the current statistical time, the student ID is deducted from the absence candidate set, and the approval version, approval start time, approval end time, and leave level used for the deduction are recorded. If a student ID in the absence candidate set does not exist in the list of students with approved leave requests valid at the current statistical time, the student ID is added to the abnormal absence list. The abnormal absence list includes the student ID, class identifier, grade identifier, statistical time, and absence candidate source.

[0135] The cause labeling module reads the last valid event and direction identifier for each student ID in the abnormal absence list. When a student ID in the abnormal absence list has a last valid event, and the direction identifier of the last valid event is "leaving school," and there is no valid direction event corresponding to the "arriving school" direction identifier after the last valid event, the cause labeling module marks the cause label of that student ID as a behavioral factor. In this embodiment, the behavioral factor indicates that the abnormal absence item corresponding to the student ID has a record of a "leaving school" direction event, and no record of an "arriving school" direction event has been formed after the "leaving school" direction event.

[0136] When a student ID in the abnormal absence list has no valid directional events within the statistics window, or when the access control device or student wearable terminal associated with that student ID has a device malfunction, the reason label module labels the student ID as a device factor. The statistics window can be provided by the statistics context, for example, from the start time of the daily statistics to the current time. Device malfunctions can include the access control device not returning an event reception status, the student wearable terminal device identifier not matching in the device status record, consecutive missing events corresponding to the device identifier, or the difference between the event reception time and the reporting timestamp exceeding the configured value. In this embodiment, "device factor" indicates that the abnormal absence item corresponding to that student ID lacks a valid directional event or has a device-side malfunction record.

[0137] For student IDs written to the pending confirmation set by S300, if the same student ID is also included in the abnormal absence list, the reason label module can mark its reason label as pending confirmation and record the event reception time, reporting timestamp, and device identifier corresponding to the directional conflict. In another implementation, the reason label module first labels according to the rules of behavioral factors and device factors, and then writes the pending confirmation status as an additional label into the reason label distribution. For student IDs that have been deducted from the list of approved leave students valid at the current statistical time, the reason label module does not generate an abnormal absence reason label, but only writes the student ID into the valid leave deduction record.

[0138] In the on-site implementation, the list of students who should be present in a class includes student A, student B, and student C; the actual on-campus set generated by S300 includes student B; the difference calculation module subtracts the actual on-campus set from the list of students who should be present, generating an absence candidate set including student A and student C. If the list of students with approved leave currently valid at the statistical time generated by S200 includes student C, the difference calculation module subtracts student C from the absence candidate set, generating an abnormal absence list including student A. If student A's last valid event is a departure direction event, and there are no arrival direction events after that departure direction event, the cause labeling module labels student A's cause as a behavioral factor; if student A has no valid direction events within the statistical window, the cause labeling module labels student A's cause as an equipment factor.

[0139] The abnormal absence list and reason tags generated in this step are written to the statistics results area of ​​the attendance backend server. The student ID, class identifier, and grade identifier in the abnormal absence list serve as inputs for S500 to perform class and grade summary statistics; the behavioral factors, device factors, and pending confirmation status in the reason tags serve as inputs for S500 to generate the reason tag distribution. The absence candidate set, valid leave deduction records, and reason tag marking records can be bound and saved with the statistical context so that they can be retrieved by the recalculation and refresh module after approval change records arrive.

[0140] S500: Based on the actual number of students in school, the list of students with abnormal absences, and the reason tags, perform summary statistics by class and grade to generate a snapshot of the number of students in school.

[0141] This step is performed by the summary output module. In one embodiment, the summary output module and the recalculation refresh module are deployed in the attendance backend server; the summary output module receives the actual attendance set generated by S300, the abnormal absence list and reason tags generated by S400, and reads the class identifier and grade identifier from the student list data generated by S100. The attendance snapshot is a summary statistical result generated according to the statistical time, which includes the snapshot version, statistical time, class identifier, grade identifier, number of students who should be present, number of students actually present, number of students with valid leave at the current statistical time, number of abnormal absences, and distribution of reason tags.

[0142] The class and grade summary statistics first use the class identifier as the grouping field to count student IDs in the actual school attendance set, generating the actual number of students in the class; then, it counts student IDs in the list of students who should be present for the same class identifier, generating the number of students who should be present for the class; finally, it counts student IDs in the list of students with approved leave at the current statistical time who are bound to the same class identifier, generating the number of students with valid leave at the current statistical time for the class; and it counts student IDs in the list of students with abnormal absences who are bound to the same class identifier, generating the number of students with abnormal absences for the class. For reason tags, the summary output module counts separately according to behavioral factors, equipment factors, and pending confirmation status, generating the class reason tag distribution.

[0143] After completing the class summary, the summary output module then uses the grade identifier as the grouping field to summarize and statistically analyze the class summary results for multiple classes within the same grade, generating the actual number of students present at school, the number of students expected to attend, the number of students with valid leave requests at the current statistical time, the number of students with abnormal absences, and the distribution of grade-specific reason tags. The grade summary results and class summary results are jointly written into the on-campus student snapshot. The snapshot version in the on-campus student snapshot can be generated by combining the statistical time, student list data version, approved leave request record approval version, and status version, or it can be generated by the attendance backend server in an ascending sequence.

[0144] In one implementation, the summary output module obtains a floor map and associates student IDs with floor identifiers in the snapshot of the number of students enrolled with the floor map to generate a regional inventory data package. The floor map can originate from school-related data, dormitory management system data, or fire evacuation inventory terminal configuration data. The regional inventory data package includes floor identifiers, class identifiers, grade identifiers, actual number of students enrolled, number of students absent without leave, and a distribution of reason tags. After the regional inventory data package is output to the fire evacuation inventory terminal, the fire evacuation inventory terminal reads the inventory data for the corresponding region according to the floor identifiers.

[0145] For student IDs with missing floor mappings, the summary output module writes the student ID into the missing floor mapping record, and still writes it into the on-campus count snapshot according to the class and grade identifiers. If the same student ID has multiple floor identifiers, the summary output module selects the corresponding floor identifier according to the floor mapping version and the statistical range in the statistical context; if no match can be found, the student ID is written into the pending confirmation floor record. The above floor mapping processing does not change the original records of the actual on-campus set, the abnormal absence list, and the reason label; it only adds floor identifier associations when generating the regional inventory data package.

[0146] Upon receiving an approval change record, the recalculation and refresh module reads the student ID, approval start time, approval end time, leave level, or leave cancellation status from the record. It then uses the filtering rules of S200 to recalculate the list of students with approved leave at the current statistical time. Subsequently, it uses the differential calculation rules of S400 to refresh the list of students with abnormal absences and their reasons. Finally, it calls the summary output module to refresh the snapshot of on-campus attendance and the snapshot version. The approval change record can come from the academic affairs management system or a third-party leave approval system; the approval change type can include adding an approval, modifying an approval, withdrawing an approval, or updating the leave cancellation status. The recalculation and refresh module writes the snapshot version, approval version, and student ID before and after the recalculation into the recalculation record.

[0147] During on-site implementation, the fire evacuation count terminal initiates a count request at the statistical time. The attendance backend server's summary output module reads the actual attendance set generated by S300 and the abnormal absence list and reason tags generated by S400, summarizes and statistically analyzes them by class and grade, and generates an attendance snapshot. If floor mapping is also configured, the summary output module associates student IDs with floor identifiers, forms a regional count data package, and outputs it to the fire evacuation count terminal. If the academic affairs management system subsequently returns an approval change record for a student, the recalculation and refresh module refreshes the list of students with approved leave at the current statistical time based on the approval change record and regenerates the attendance snapshot for the corresponding class, grade, and floor.

[0148] The final snapshot of on-campus attendance generated in this step is saved on the attendance backend server and can be output to the fire evacuation count terminal, the gatekeeper smart terminal, or the campus management terminal. The snapshot version, statistical time, and class identifier in the on-campus attendance snapshot are used for subsequent queries and version matching; the number of abnormal absences and the distribution of reason tags are used for subsequent count records; the regional count data package is used by the fire evacuation count terminal to read count data by floor identifier. After the approval change record arrives, the recalculation and refresh module uses the current snapshot version as input to generate a new snapshot version and retains the recalculation record corresponding to the original snapshot version.

[0149] Example 2: Figure 2 This diagram illustrates a structural block diagram of an on-campus student attendance statistics system that links arrival / departure with leave requests, according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0150] Event access module 01 is used to receive the outbound / departure direction event stream reported by access control devices or student wearable terminals in a low-frequency triggering manner, and to verify, sort, and cache the outbound / departure direction event stream according to student ID and reporting timestamp, generating a valid direction event sequence and statistical context. Specifically, the event access module receives the outbound / departure direction event stream from the access control device or student wearable terminal. The event records in the outbound / departure direction event stream include student ID, direction identifier, reporting timestamp, device identifier, and event reception time. After receiving the event records, the event access module performs field verification on student ID, direction identifier, and reporting timestamp, writes event records lacking student ID, direction identifier, or reporting timestamp into invalid event records, and sorts the event records that pass the verification according to... Student IDs are used to create event groups, and within the same student ID event group, events are sorted according to the reporting timestamp. When the same student ID, the same direction identifier, and the same device identifier have duplicate reported event records within a preset time window, the event access module retains the event record with the earliest reporting timestamp and writes the remaining event records into the duplicate event record. The event access module encapsulates the event records after verification, sorting, and caching into a valid direction event sequence, and writes the statistical time, event reception time, event cache location, and event record status into the statistical context. The event access module provides the statistical time in the statistical context to the response list construction module, provides the statistical context to the whitelist construction module, and provides the valid direction event sequence to the state machine reduction module.

[0151] The attendance list construction module 02, connected to the event access module, is used to generate an attendance list based on the student list data corresponding to the statistical time, and bind the attendance list to the statistical context. Specifically, the attendance list construction module receives the statistical context from the event access module and reads the student list data based on the statistical time in the statistical context. The student list data includes student ID, class identifier, grade identifier, and statistical inclusion identifier. The attendance list construction module performs statistical inclusion identifier filtering on the student list data, and writes the student IDs with the statistical inclusion identifier in the inclusion status into the attendance list. The student ID is bound to the class identifier and grade identifier. When a student ID in the student list data is missing a class identifier or grade identifier, the expected attendance list construction module writes the student ID into the pending confirmation list record and retains the field values ​​in the original student list data. The expected attendance list construction module writes the list version, statistical time, and statistical range of the expected attendance list into the statistical context, so that the expected attendance list and the statistical context form a corresponding relationship. The expected attendance list construction module provides the range of student IDs in the expected attendance list to the whitelist construction module and provides the expected attendance list to the difference calculation module.

[0152] The whitelist construction module 03, connected to the event access module and the expected attendance list construction module, is used to obtain approved leave records based on the statistical context, and filter them according to the approval start time, approval end time, leave level, and statistical time to generate a list of students with approved leave valid at the current statistical time. Specifically, the whitelist construction module receives the statistical context from the event access module and calls the range of student IDs in the expected attendance list output by the expected attendance list construction module. The whitelist construction module obtains approved leave records from the academic affairs management system or a third-party leave approval system. The approved leave records include student ID, approval start time, approval end time, leave level, leave cancellation status, and approval version. The whitelist construction module matches the student IDs in the approved leave records with the expected attendance list, and removes students whose names do not match the expected attendance list. Approved leave records are written into the non-statistical range records; for approved leave records that match the student list, the whitelist construction module matches the approval start time, approval end time, and statistical time, and matches the leave level with the deduction conditions; when the approval start time is not later than the statistical time, the approval end time is later than the statistical time, the leave level meets the deduction conditions, and the leave cancellation status is not effective, the whitelist construction module writes the corresponding student ID into the list of approved leave students valid at the current statistical time; when there are multiple approved leave records with overlapping valid times for the same student ID, the whitelist construction module selects the corresponding record according to the approval version and writes the unselected approved leave records into the leave record history area; the whitelist construction module provides the differential calculation module with the list of approved leave students valid at the current statistical time and writes the list version into the statistical context.

[0153] The state machine reduction module 04, connected to the event access module, is used to maintain a direction state machine based on the valid direction event sequence, using the student ID as the key, and perform state reduction to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set. Specifically, the state machine reduction module receives the valid direction event sequence from the event access module and establishes a direction state machine instance according to the student ID. The direction state machine includes an unconfirmed state, an on-campus state, an off-campus state, and a pending confirmation state. Within the event group corresponding to the same student ID, the state machine reduction module reads the direction identifier according to the reported timestamp. When an on-campus direction identifier is read, the direction state machine corresponding to that student ID is updated to the on-campus state, and the event is recorded as the last valid event. When an off-campus direction identifier is read, the student ID is updated to the on-campus state. The corresponding direction state machine is updated to the "departed from school" state, and the event is recorded as the last valid event. When the last valid direction state for the same student ID is "arrived at school," the state machine reduction module writes the student ID into the actual school-attended set. When the last valid direction state for the same student ID is "departed from school," and there is no valid direction event corresponding to the "arrived at school" direction identifier after the last valid event, the state machine reduction module writes the student ID into the actual departed from school set. When the direction identifiers for the same student ID conflict, the state machine reduction module writes the student ID into the pending confirmation set and records the reporting timestamp and device identifier of the conflict event. The state machine reduction module provides the actual school-attended set to the differential calculation module, the last valid event and the last valid direction state to the cause label module, and the actual school-attended set to the summary output module.

[0154] The differential calculation module 05, connected to the expected attendance list construction module, the whitelist construction module, and the state machine reduction module, is used to deduct the actual on-campus set from the expected attendance student list to generate an absence candidate set, and to deduct the list of students with approved leave requests valid at the current statistical time from the absence candidate set to generate an abnormal absence list. Specifically, the differential calculation module receives the expected attendance student list from the expected attendance list construction module, the list of students with approved leave requests valid at the current statistical time from the whitelist construction module, and the actual on-campus set from the state machine reduction module. The differential calculation module uses student ID as the matching field to match the expected attendance student list with the actual on-campus set, and identifies students who are on the expected attendance student list but not on the actual on-campus set. Student IDs are written into the absence candidate set; the absence candidate set records student IDs, class identifiers, grade identifiers, and the statistical time; the difference calculation module then uses student IDs as the matching field to match the absence candidate set with the list of students with approved leave valid at the current statistical time, writes the student IDs that match the list of students with approved leave valid at the current statistical time into the valid leave deduction record, and writes the student IDs that do not match the list of students with approved leave valid at the current statistical time into the abnormal absence list; the difference calculation module passes the abnormal absence list to the reason labeling module, which labels the list based on the last valid event; the difference calculation module passes the abnormal absence list to the summary output module, which generates a snapshot of the number of students on campus.

[0155] The cause labeling module 06, connected to the state machine reduction module and the difference calculation module, is used to label causes based on the existence and direction identifier of the last valid event corresponding to the student ID in the abnormal absence list. Specifically, the cause labeling module receives the abnormal absence list from the difference calculation module and the last valid event, last valid direction state, and actual departure set from the state machine reduction module. The cause labeling module uses the student ID in the abnormal absence list as an index to read the last valid event and direction identifier corresponding to that student ID. When a student ID has a last valid event, and the direction identifier of the last valid event is departure, and there is no valid direction event corresponding to the arrival direction identifier after the last valid event, the cause labeling module is determined. The tag module labels the cause tag corresponding to the student ID as a behavioral factor; when there is no valid directional event for the student ID in the statistics window, or when there is a device malfunction in the access control device or student wearable terminal associated with the student ID, the cause tag module labels the cause tag corresponding to the student ID as a device factor; when the directional identifier corresponding to the student ID is written into the pending confirmation set by the state machine reduction module, the cause tag module writes the pending confirmation status into the tag record of the student ID; the cause tag module forms a cause tag record by combining the student ID, cause tag, the reporting timestamp of the last valid event, and the device identifier, and transmits the cause tag record to the summary output module; the cause tag module maintains an index relationship between the cause tag record and the statistical time of the abnormal absence list.

[0156] The summary output module 07, connected to the state machine reduction module, the difference calculation module, and the cause label module, is used to perform class and grade summary statistics based on the actual attendance set, the abnormal absence list, and the cause labels, generating an attendance snapshot. Specifically, the summary output module receives the actual attendance set from the state machine reduction module, the abnormal absence list from the difference calculation module, and the cause labels from the cause label module; the summary output module reads the class identifier and grade identifier from the list of students who should be present, and performs summary statistics on the actual attendance set, the abnormal absence list, and the cause labels according to the class identifier, generating a class summary result; the summary output module performs summary statistics on multiple class summary results according to the grade identifier, generating a grade summary result; the attendance snapshot includes snapshot version, statistical time, class identifier, grade identifier, expected number of students, and actual number of students present. The current statistical time includes the distribution of valid leave requests, abnormal absences, and reason tags. When obtaining floor mappings, the summary output module associates student IDs in the on-campus student snapshot with floor identifiers, generates a regional inventory data package, and outputs the regional inventory data package to the fire evacuation inventory terminal. When a floor mapping lacks a corresponding student ID, the summary output module writes the student ID into the floor mapping missing record and retains the class and grade identifiers of the student ID in the on-campus student snapshot. The summary output module binds the on-campus student snapshot to the statistical time in the statistical context and saves the snapshot version for subsequent approval change record triggering.

Claims

1. A method for counting the number of students on campus that links arrival and departure with leave requests, characterized in that, include: S100: Receive the arrival / departure direction event stream reported by the access control device or student wearable terminal in a low-frequency triggering mode, and obtain the student list data corresponding to the statistical time; verify, sort, and cache the arrival / departure direction event stream according to the student ID and the reporting timestamp, and generate a valid direction event sequence, a list of students who should arrive, and a statistical context; The low-frequency triggering method includes: configuring an outer edge triggering area and an inner edge triggering area in the school gate passage area; when the student wearable terminal first receives the low-frequency triggering signal from the outer edge triggering area and then receives the low-frequency triggering signal from the inner edge triggering area, it generates an arrival direction identifier; when the student wearable terminal first receives the low-frequency triggering signal from the inner edge triggering area and then receives the low-frequency triggering signal from the outer edge triggering area, it generates a departure direction identifier. S200. Based on the statistical context, obtain the approved leave records, filter by approval start time, approval end time, leave level and statistical time, and generate a list of students with approved leave that is valid at the current statistical time. The approved leave records include student ID, approval start time, approval end time, leave level, leave status, and approval version; the generation of the list of approved leave students valid at the current statistical time includes: filtering approved leave records whose approval start time is no later than the statistical time, whose approval end time is later than the statistical time, whose leave level meets the deduction conditions, and whose leave status has not yet taken effect; and writing the student IDs from the filtered approved leave records into the list of approved leave students valid at the current statistical time. S300. Based on the valid direction event sequence, maintain the direction state machine with student ID as the key and perform state reduction to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set. The direction state machine includes unconfirmed state, on-campus state, off-campus state, and pending confirmation state. The state reduction process includes: forming a state transition pair from two consecutively reported valid direction events of the same student ID, and calculating the state transition confidence. The state transition confidence is determined by the difference in reporting timestamps between the two events, the consistency of the device identifier, and the stability of the student ID's historical direction state sequence. When the state transition confidence is greater than a preset state transition confidence threshold, a state transition is executed, and the event is recorded as the last valid event. When the state transition confidence is less than or equal to the state transition confidence threshold, no state transition is executed, and the event is written to the pending confirmation event buffer. When the last valid direction state of the same student ID is "on-campus," the student ID is assigned to the designated school district. The actual set of students currently enrolled at school is defined as follows: When the last valid direction status of the same student ID is "leaving school," and there is no valid direction event corresponding to the "arriving school" direction identifier after the last valid event, the student ID is included in the actual set of students leaving school. When the direction identifiers of the same student ID conflict, the student ID is included in the set to be confirmed. The direction conflict includes: within a preset time window, the intensity of the alternation of direction identifiers in the valid direction event sequence of the same student ID exceeds a preset conflict threshold. The direction conflict degree is calculated based on the number of inversion pairs in the valid direction event sequence, and the inversion pair is defined as an event pair where the forward event is the "leaving school" direction and the backward event is the "arriving school" direction. When the direction conflict degree is greater than the preset conflict threshold, the student ID is included in the set to be confirmed. S400: Subtract the actual number of students in school from the list of students who should be present to generate an absence candidate set; subtract the list of students with approved leave that is valid at the current statistical time from the absence candidate set to generate an abnormal absence list, and label the reason based on the existence and direction identifier of the last valid event; The cause labels include behavioral factors and device factors. When a student ID in the abnormal absence list has a last valid event, and the direction identifier of the last valid event is "leaving school," and there is no valid directional event corresponding to the direction identifier of "arriving at school" after the last valid event, the cause label for that student ID is marked as a behavioral factor. When a student ID in the abnormal absence list has no valid directional event in the statistics window, or the access control device or student wearable terminal associated with that student ID has a device malfunction, the cause label for that student ID is marked as a device factor. S500: Based on the actual number of students in school, the list of students with abnormal absences, and the reason tags, perform summary statistics by class and grade to generate a snapshot of the number of students in school.

2. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, Each event in the event stream for the direction of departure from school includes a student ID, direction identifier, reporting timestamp, device identifier, and event reception time; The verification includes marking events that lack a student ID, direction identifier, or reporting timestamp as invalid events; The events that pass the verification are written into the event cache according to the student ID and the reporting timestamp, thus generating the valid direction event sequence.

3. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The low-frequency triggering method includes: the access control device or the student wearable terminal receiving the triggering order of the outer edge triggering area and the inner edge triggering area of ​​the school gate; when the triggering order is that the outer edge triggering area of ​​the school gate is triggered first and the inner edge triggering area of ​​the school gate is triggered later, an arrival direction identifier is generated; when the triggering order is that the inner edge triggering area of ​​the school gate is triggered first and the outer edge triggering area of ​​the school gate is triggered later, a departure direction identifier is generated.

4. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The direction state machine includes an unconfirmed state, an on-campus state, a off-campus state, and a pending confirmation state. When the last valid direction state of the same student ID is "arrived at school," the student ID is assigned to the actual on-campus set. When the last valid direction state of the same student ID is "departed from school," and there is no valid direction event corresponding to the arrival direction identifier after the last valid event, the student ID is assigned to the actual departed from school set. When the direction identifiers of the same student ID conflict, the student ID is assigned to the pending confirmation set.

5. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The approved leave records include student ID, approval start time, approval end time, leave level, leave status, and approval version; the generation of the list of approved leave students valid at the current statistical time includes: filtering approved leave records whose approval start time is no later than the statistical time, whose approval end time is later than the statistical time, whose leave level meets the deduction conditions, and whose leave status has not been effective; and writing the student IDs in the filtered approved leave records into the list of approved leave students valid at the current statistical time.

6. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The student list data includes student ID, class identifier, grade identifier, and statistical inclusion identifier; The generation of the student attendance list includes: filtering and statistically analyzing student IDs marked as included from the student list data, binding the filtered student IDs by class ID and grade ID, and generating the student attendance list.

7. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The cause labels include behavioral factors and device factors. When a student ID in the abnormal absence list has a last valid event, and the direction identifier of the last valid event is "leaving school", and there is no valid direction event corresponding to the direction identifier of "coming to school" after the last valid event, the cause label of the student ID is marked as a behavioral factor. When a student ID in the abnormal absence list has no valid direction event in the statistics window, or the access control device or student wearable terminal associated with the student ID has a device malfunction, the cause label of the student ID is marked as a device factor.

8. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 1, characterized in that, The snapshot of the number of students enrolled includes the snapshot version, the time of the statistics, the class identifier, the grade identifier, the number of students who should be present, the number of students actually enrolled, the number of students with valid leave requests at the current time of the statistics, the number of students with abnormal absences, and the distribution of reason tags; The class and grade summary statistics include: summarizing and statistically analyzing the actual number of students in school, the list of students with approved leave that is valid at the current statistical time, the list of students with abnormal absences, and the reason tags according to class and grade identifiers.

9. The method for counting the number of students on campus that links arrival and departure with leave requests as described in claim 8, characterized in that, The method further includes: obtaining a floor mapping; based on the floor mapping, associating the student IDs in the snapshot of the number of students enrolled with the floor identifiers to generate a regional inventory data package; and outputting the regional inventory data package to the fire evacuation inventory terminal.

10. A campus attendance statistics system that links arrival and departure with leave requests, used to implement the method described in any one of claims 1-9, characterized in that, include: The event access module receives the event streams of the direction of leaving school reported by the access control device or the student wearable terminal in a low-frequency triggering mode, and verifies, sorts and caches the event streams of the direction of leaving school according to the student ID and the reporting timestamp, and generates a valid direction event sequence and statistical context. The expected attendance list construction module generates an expected attendance list based on the student list data corresponding to the statistical time, and binds the expected attendance list to the statistical context; The whitelist building module obtains approved leave records based on the statistical context, and filters them by approval start time, approval end time, leave level and statistical time to generate a list of students with approved leave that is valid at the current statistical time. The state machine reduction module maintains the direction state machine and performs state reduction based on the valid direction event sequence, using student ID as the key, to generate the last valid event, the last valid direction state, the actual on-campus set, and the actual off-campus set. The differential calculation module deducts the actual number of students in school from the list of students who should be present to generate an absence candidate set, and deducts the list of students with approved leave at the current statistical time from the absence candidate set to generate an abnormal absence list. The reason labeling module labels reasons based on the existence and direction identifier of the last valid event corresponding to the student ID in the abnormal absence list. The summary output module performs class and grade summary statistics based on the actual number of students in school, the list of abnormal absences, and the reason tags, and generates a snapshot of the number of students in school.

Images