dataesr/scientific-paragraphs-categorization huggingface dataset:
The solution of this cost program is the cost expression N × M. Our technique associates cost programs to miniSL functions by parsing the corresponding codes. In particular, we define a set of (inference) rules that gather fragments of cost programs that are then combined in a syntax-directed manner. As usual with syntax-directed rules, we use environments Γ, Γ ′ , which are maps. In particular, • Γ takes a service h or a parameter name p and returns a Presburger arithmetics expression, which is usually a variable. For example, if Γ(h) = X, then X will appear in the cost expressions of miniSL functions using h and will represent the cost for accessing the service. As regards parameter names p, Γ(p) represents values which are known at function scheduling time, • Γ takes counters i and returns the type Int.
n f i (e i )) is the union of the sets of variables var(e 0 ), • • • , var(e n ). The inference rules for miniSL are reported in Figure  2. They compute the cost of a program with respect to the calls to external services (whose cost is recorded in the environment Γ). Therefore, if a miniSL expression (or statement) has no service invocation, its cost is 0. Notice that in the rule [IF-EXP] we use the guard [ ¬ϕ ], to model the negation of a linear conjunctive constraint ϕ, even if negation is not permitted in Presburger arithmetic. Actually, such notation is syntactic sugar defined as follows: • let ¬ϕ (the negation of a Presburger guard ϕ) be the list of Presburger guards ¬(e ≥ e ′ ) = e ′ ≥ e + 1 ¬(e = e ′ ) = e ≥ e ′ + 1 ; e ′ ≥ e + 1 ¬(e ∧ e ′ ) = ¬e ; ¬e ′ where ; is the list concatenation operator (the list represents a disjunction of Presburger guards), • let ¬ϕ = ϕ 1 ; • • • ; ϕ m , where ϕ i are Presburger guards, then f (x) = e + ∑ i∈0.
In particular, the counter i is the first formal parameter of for ℓ ; the other parameters are all the variables in e, in notation var(e) plus those in the invocations C (minus the i). There are two equations for every iteration: one is the case when i is out-of-range, hence the cost is 0, the other is when it is in range and the cost is the one of the body plus the cost of the recursive invocation of for ℓ with i increased by 1. The cost of a miniSL program is defined by  [PRG]. This rule defines an equation for the function main and puts this equation as the first one in the list of equations. [EPS] Γ ⊢ ε : 0 ; / 0 ; / 0  [CALL] Γ(h) = e Γ ⊢ S : e ′ ; C ; Q Γ ⊢ call h(E) S : e + e ′ ; C ; Q [IF-EXP] Γ ⊢ E : ϕ Γ ⊢ S : e ′ ; C ; Q Γ ⊢ S ′ : e ′′ ; C ′ ; Q ′ if ℓ fresh w = var(e, e ′ , e ′′ ) ∪ var(C, C ′ ) Q ′′ = if ℓ (w) = e ′ + C [ ϕ ] if ℓ (w) = e ′′ + C ′ [¬ϕ] Γ ⊢ if (E) { S } else { S ′ } : 0 ; if ℓ (w) ; Q, Q ′ , Q ′′ [IF-CALL] Γ(h) = e Γ ⊢ S : e ′ ; C ; Q Γ ⊢ S ′ : e ′′ ; C ′ ; Q ′ Γ ⊢ if (call h(E)) { S } else { S ′ } : e + max(e ′ , e ′′ ) ; C + C ′ ; Q, Q ′ [FOR] Γ ⊢ E : e Γ + i : Int ⊢ S : e ′ ; C ; Q w = (var(e, e ′ ) ∪ var(C)) \ i for ℓ fresh Q ′ = for ℓ (i, w) = e ′ + C + for ℓ (i + 1, w) [ e ≥ i ] for ℓ (i, w) = 0 [ i ≥ e + 1 ] Γ ⊢ for (i in range(0,E)){ S } : 0 ; for ℓ (0, w) ; Q, Q ′ [PRG] Γ ⊢ S : e ; C ; Q w = var(p, e) ∪ var(C) main fresh Q ′ = main(w) = e + C [ ] Γ ⊢ (p) => { S } : Q ′ , Q [ ] if 2 (u, P, B) = P [ u = 1 ] if 2 (u, P, B) = B [ u = 0 ] For Listing 2, let Γ(IsPremiumUser) = K.
Then the rules of Figure  2  return the single equation main(K, P, B) = K + max(P, B) [ ] For 3, when Γ(m) = m, Γ(r) = r, Γ(Map) = M and Γ(Reduce) = R, the cost program is main(m, r, M, R) = for 2 (0, m, r, M, R) [ ] for 2 (i, m, r, M, R) = M + for 4 (0, r, R) + for 2 (i + 1, m, r, M, R) [ m ≥ i ] for 2 (i, m, r, M, R) = 0 [ i ≥ m + 1 ] for 4 ( j, r, R) = R + for 4 ( j + 1, r, R) [ r ≥ j ] for 4 ( j, r, R) = 0 [ j ≥ r + 1 ] The foregoing cost programs can be fed to automatic solvers such as Pubs  [1]  and CoFloCo  [4]. The evaluation of the cost program for Listing 1 returns max(P, B) because u is unknown. On the contrary, if u is known, it is possible to obtain a more precise evaluation from the solver: if u = 1 it is possible to ask the solver to consider main(1, P, B) and the solution will be P, while if u = 0 it is possible to ask the solver to consider main(0, P, B) and the solution will be B.
From APP to cAPP We now discuss the extension of APP that we plan to realise, where function scheduling policies could depend on the costs associated with the possible execution of the functions on the available workers. Before discussing the extensions towards cAPP, we briefly introduce the APP syntax and constructs, reported in Figure  3 , as found in its first incarnation by De Palma et al. [3]  The APP Language An APP script is a collection of tagged scheduling policies. The main, mandatory component of any policy (identified by a policy_tag) are the workers therein, i. e. , a collection of labels that identify on which workers the scheduler can allocate the function. The assumption is that the environment running APP establishes a 1-to-1 association so that each worker has a unique, identifying label.
Towards cAPP Our proposal to extend APP to handle cost-aware scheduling policies entails two major modifications: (i) extending the APP language to express cost-aware scheduling policies, (ii) implementing a new controller that selects the correct worker following the cost-aware policies. As far as (i) is concerned, we discuss at least two relevant ways in which costs can be used. The first one is a new selection strategy named min_latency. Such a strategy selects, among some available workers, the one which minimises a given cost expression. The second one is a new invalidation condition named max_latency. Such a condition invalidates a worker in case the corresponding cost expression is greater than a given threshold. We dub cAPP the cost-aware extension of APP and illustrate its main features by showing examples of cAPP scripts that target the functions in Listings 1-3.
-premUser : -workers: -wrk: W1 -wrk: W2 strategy: min_latency Listing 4: cAPP script for Listings 1 and 2. -mapReduce : -workers: -wrk: W1 -wrk: W2 strategy: random invalidate: max_latency: 300 Listing 5: cAPP script for Listing 3. In Listing 4, we define a cAPP script where we assume to associate the tag premUser to both the functions at Listing 1 and 2. In the script, we specify to follow the logic min_latency to select among the two workers, W1 and W2 listed in the workers clause, and prioritises the one for which the solution of the cost expression is minimal. To better illustrate the phases of the min_latency strategy, we depict in Figure  4  the flow, from the deployment of the cAPP script to the scheduling of the functions in Listings 1 and 2. When the cAPP script is created, the association between the functions code and their cAPP script is specified by tagging the two functions with //tag:premUser.
In this phase, assuming the scheduling policy of the cAPP script requires the computation of the functions cost, the code of the functions is used to infer the corresponding cost programs. When the functions are invoked, i. e. , at scheduling time, we can compute the solution of the cost program, given the knowledge of the invocation parameters. For instance, for the function in Listings 1, it is possible to invoke the solver with either main(1, P, B) or main(0, P, B) depending on the actual invocation parameter. Figure  4  illustrates this last part with the horizontal "request" lines found at the bottom. In particular, when we receive a request for the function at Listing 1, we take its cost program (represented by the intersection point on the left) and its corresponding cAPP policy to implement the expected scheduling policy.
e. , if we can consider the worker able to execute the function, given the invalidation constraints of the script). To illustrate this second occurrence, we look at the cAPP code we wrote for the map-reduce function in Listing 5, and we illustrate it using Figure  5. As seen above, we start (top-most box) from the deployment phase, where we tag the function (//tag: mapReduce) and we proceed to compute its cost program, obtaining the associated cost expression. Then, when we receive a request for that function, we trigger the execution of the cAPP policy, which selects one of the two workers W1 or W2 at random and checks their validity following the logic shown at the bottom of Figure  5 , i. e. , we solve the cost program and then compute the corresponding cost expression by replacing the parameters m and r with the latency to contact the Map and Reduce services from the selected worker, and possibly invalidate it if the computed value is greater than 300.
In the function's code, for simplicity, we abstract away the coordination logic between Map and Reduce (which usually performs a multipoint scatter-gather behaviour) by offloading it to external services (e. g. , a database contacted by the functions). These new strategy and invalidate parameters added for cAPP interact with the cost-inference logic presented in Section 3. As shown in Figure  4 , the definition of the strategy and invalidate parameters, as well as the cost inference, happen independently, when the cAPP script is deployed. A strategy indeed (e. g. , min_latency) is not tied to any specific cost expression. For example, the user can define the premUser policy (see the cAPP script on the right-hand side of Figure  4 ) before having deployed any function with that tag. When functions are deployed on the platform (centre and left-hand side of Figure  4 ), the cAPP runtime performs the inference of programs' costs.
Conclusion We have presented a proposal for an extension of the APP language, called cAPP, to make function scheduling cost-aware. Concretely, the extension adds new syntactic fragments to APP so that programmers can govern the scheduling of functions towards those execution nodes that minimise their calculated latency (e. g. , increasing serverless function performance) and avoids running functions on nodes whose execution time would exceed a maximal response time defined by the user (e. g. , enforcing quality-ofservice constraints). The main technical insights behind the extension include the usage of inference rules to extract cost equations from the source code of the deployed functions and exploiting dedicated solvers to compute the cost of executing a function, given its code and input parameters.
This assay detects 15 individual high-risk HPV genotypes in a single tube, including HPV 16, 18, 31, 33, 35, 39, 45, 51, 52, 53, 56, 58, 59, 66, and 68 (the same types as the Xpert HPV assay plus HPV 53). AmpFire uses the cyanine5 (CY5) uorophore for HPV 16, the carboxyrhodamine (ROX) uorophore for HPV18 and other high-risk HPV genotypes using the uoresce in amidites (FAM) uorophore, all combined with an internal control using the HEX uorophore. The Real-Time PCR was programmed using Bioer Real-Time PCR system for an isothermal reaction setting of 60°C while taking uorescence readings at the FAM/HEX/CY5/ROX channels once every minute for a total of 60 minutes. The thermocycling software system automatically reported the results of the cycle threshold values for each ampli cation curve in all uorescence channels.
However, it still faces challenges related to high variability in individual evaluations and subjectivity in SA measurement. SASHA_Q is a self-assessment questionnaire that includes questions about SA elements identified by air traffic controllers. It can be used to measure individual or team SA. The questionnaire's items are developed based on actual tasks, and the subjects provide self-assessment scores on a scale of 0 to 6, indicating the frequency of occurrence from ''never" to ''always". Jipp and Papenfuss  [11]  applied this questionnaire to validate SA measures for 12 professional tower controllers. However, this method requires more extensive demands and ordered data for statistical analysis. CARS is an observer rating technique comprising eight levels ranging from 1 ideal situation to 4 worst situation.
Initially designed for military cockpit simulations, SAGAT has been extended to applications in aviation, command and control, driving, energy, robotics, and submarine display design. SAGAT assesses different levels of situational awareness, including level 1 data awareness, level 2 meaning understanding, and level 3 near-term prediction. The SAGAT process involves using a graphical computer program to present queries and collect data. During the assessment, the interface is frozen at random time and the participant is asked questions related to the scenario. The participant's answers are compared with correct answers stored in the computer to determine their situational awareness at that specific point in time. The queries can be presented verbally, on paper, or through a computer or tablet interface.
SASHA_L (Situation Awareness for Human Automation Partnerships in the European ATM Questionnaire, Live) is yet another online detection technique specifically designed for air traffic controllers. It involves an expert who examines the controller's operational display and asks real-time questions related to situational awareness. VESARS (Virtual Environment Situational Awareness Scoring System) is an online probing software tool used to measure the situational awareness of individuals or teams in virtual and realistic training environments. It uses three metrics: real-time situational awareness queries for individual and team assessment, experts' real-time situational awareness behavior ratings for individual and team assessment, and experts' ratings for realtime situational awareness communication  [16].
It involves integrating data from various sensors, systems and sources, such as radar, GPS, cameras and databases. Through advanced data fusion algorithms and techniques, this method aims to extract relevant and meaningful information, reducing redundancy and improving the accuracy and completeness of SA. The use of KG and inference engines combined with ML modules has been applied in Single European Sky ATM Research (SESAR) as part of the AISA project  [29]. This project aims to develop an intelligent SA-aware system for exploring the distributed human-machine SA in ATC operations. Taking advantage of KG and inference engines, along with ML, the system enhances SA in ATC by improving the understanding and decision-making capabilities of controllers. Jiang  [33]  proposes a representation learning approach based on Graph Neural Networks (GNNs) that addresses the challenge of noisy KGs in AI agents.
(3) Machine Learning (ML) based SA enhancement techniques: ML techniques play a crucial role in enhancing SA by leveraging computational models and algorithms to analyze and learn patterns from data. ML algorithms can be trained on large datasets to recognize and classify patterns associated with specific SA elements or situations. They can also be used for real-time data analysis, anomaly detection, prediction and decision support, helping human operators maintain and  improve their SA. Interpretable Artificial Intelligence (XAI) is an approach that focuses on improving human understanding and the performance of the human-AI team by providing users with information about the behavior and decision-making processes of AI systems  [35]. XAI aims to make AI systems more transparent and explainable, allowing users to trust and collaborate effectively with AI systems.
The impact of these new technologies and systems on the assessment of situational awareness of the controller is significant. They offer improved functionality, increased efficiency, and enhanced decision-making support for air traffic controllers. These AI-based systems work by using advanced algorithms and machine learning models to process large amounts of data and provide real-time insights and predictions to controllers. Overall, the integration of AI techniques and advanced technologies into air traffic control holds great potential to advance the assessment of controller situational awareness, providing controllers with valuable tools and support to ensure safe and efficient air traffic management. (1) The SESAR AISA project focuses on enabling safe sharing of SA between humans and AI in ATM.
It enables better identification of potential risks and early detection of subtle signs of incidents through analysis of ATC big data, including information from written reports that were previously difficult to standardize. Using digital technologies and AI, future systems can be designed and operated with a more comprehensive understanding of their behavior. Historical data can be used to model the performance and interactions of these systems, leading to more robust designs and safer operations. In summary, the development of digitalization and AI in air traffic control offers opportunities to enhance safety by facilitating the sharing of SA between humans and automated systems. This collaborative approach, supported by advanced technologies, has the potential to improve risk assessment, early incident detection, and the overall effectiveness of air traffic management.
To achieve this, the project uses novel techniques, including the use of solution space graph metrics as input to ML agents. Using layered deep learning and reinforcement learning models, the system can learn from the data and optimize its performance over time. Innovative interface methods utilized in the project provide a means of effectively analyzing the consistency and transparency of the ML system, while also considering the complexity of air traffic. Real-time simulations are carried out to evaluate the performance of the system's and its impact on various aspects of ATM operations. (4) The TAPAS project, Towards an Automated and Explainable ATM System, focuses on exploring highly automated scenarios in air traffic management through the use of interpretable artificial intelligence prototyping and Visual Analytics (VA) techniques.
Additionally, CAST is an effective technique to evaluate the SA of a team, combining the flexibility of the team to adapt to dynamic environments with the process of achieving a higher SA of the team in an efficient manner. The emergence of AI technology has significantly broadened the scope of SA measurement methods. By combining semantic web and ontology information fusion techniques, multisource information data fusion methods, and machine learning methods, the accuracy and completeness of SA measurements can be improved, thus improving the team SA. In the field of ATC, the UTM, and AAM programs have encouraged the use of new mathematical algorithms and system implementations. Consequently, ATCos' SA measurements are now more likely to use advanced algorithms and machine learning models to process large amounts of data in order to provide more precise and predicted measurements.
III. ATCO'S SA BASED ON NEUROPHYSIOLOGICAL MEASUREMENTS The measurement of physiological indices, such as eye movement and EEG techniques, has been mentioned in Section II-A3. These techniques offer the advantage of objectively and accurately measuring SA. Furthermore, data recorded of eye movement and EEG provide information on the neurophysiological characteristics of the individuals, shedding light on the physiological mechanisms underlying cognition, emotion, volition, and behavior. This knowledge helps us to understand the abstract nature of the human mind. As the field of artificial intelligence has advanced, machine learning techniques applied to eye movement and EEG data have gained popularity among researchers. Both eye movement and EEG have shown exceptional performance in monitoring the state of controllers in ATC, including aspects such as emotion, fatigue, and workload.
B. ELECTROENCEPHALOGRAPHY Physiological indicators such as EEG, ElectroCardioGram (ECG) and skin conductivity are commonly used to assess the physiological status of individuals. EEG, specifically, captures the spontaneous and rhythmic electrical activity of brain cell populations and can be visualized in various forms such as waveforms(a), power spectra(b), spectral topography(c) and thermograms(d) (refer to Figure  4 ). EEG signals can be decomposed into four basic rhythms: delta, theta, alpha and beta. These wave signals provide information on the different levels of fatigue experienced by individuals. The advantage of EEG technology lies in its ability to directly record the electrical activity of the cerebral cortex, providing objective data on cognitive, emotional and fatigue levels through fourwave signals.
Additionally, the HAAWAII project has developed a new ML-based speech recognition framework to aid controller decision making. Many other SESAR projects, including MAHALO, TAPAS, and ARTIMA-TION, are focused on ensuring that AI-driven solutions are interpretable, transparent, and trustworthy. These projects also emphasize the protection of private datasets used in ML applications to encourage data sharing, as demonstrated by the AICHAIN project. The level of automation in air traffic management encompasses several key aspects: automation phase, automation system, system transparency, and automation trust.
VI. CONCLUSION This review explores in depth the theoretical development of individual and team SA and provides a comprehensive overview of the main measurement methods. Although SAGAT and SART methods are widely used in SA measurement, we also identified some limitations and challenges. With the rapid development of artificial intelligence technology, new SA measurement methods continue to emerge, including SA enhancement technology based on ML, fusion method using semantic network and ontology information, method combining inference engine and knowledge graph, and multi-source information data fusion method. The SESAR/NextGen research project clearly highlights the importance of these new measurement methods, providing valuable guidance for the future of complex air traffic management, and promoting further development of safety, efficiency, and intelligence.
V. PROPOSED SOLUTION Based on the methodology proposed by Pereira et al. [19] , we summarise our solution's architecture in the diagram depicted in Figure  6. The first step of the proposed solution consists of using a multi-objective algorithm to generate possible values for the parameters that represent the weights of the source repair (i. e. , SW1 and SW2) and local repair (i. e. , LW1 and LW2). Next, to access the quality of the values generated, we employed the NS2 platform to simulate the AODV protocol within the connectivity framework, incorporating the weight values derived from the multi-objective algorithm. Following this , a script was employed to parse the output files from each simulation, extracting the pertinent metrics Fill the archive until it becomes full using bestdominated vectors; Select the parent chromosomes in the population using a binary tournament; 14: Execute the crossover operator to parents, forming the new population; Combine the current population with the new chromosomes; 18: end while 19: return The set of non-dominated vectors in the external archive such as Delay, packet loss ratio (PLR), network route load (NRL), and energy consumption (EC).
All the problem-specific dependencies were modeled in the objective function class. In the jMetal framework  [59] , this class poses all the problem attributes such as the number of dimensions, search space range, and fitness function). When the optimizers generate a solution and need to evaluate its quality, they will call the objective function class, passing the solution array as an argument. Inside the function, a new NS2 simulation setup with be created using the values for SW1, SW2, LW1, and LW2 generated by the optimiser. Next, the NS2 simulation will be executed using the specifications described in Section VI and the values generated by the optimiser. Once the simulation finishes, the output files are processed using a script that evaluates the QoS metrics' value (e. g. , routing delay, energy consumption, packet loss, ratio, and route load).